Tecnologias para um blog simples no estilo de mur.ad

Esta pesquisa parte primeiro da aparência e do comportamento observados em mur.ad, e só depois escolhe a tecnologia. O objetivo não é copiar conteúdo nem presumir como o site foi construído, mas criar um blog com a mesma atitude: HTML direto, tipografia padrão do navegador, links azuis sublinhados, CSS inline mínimo, índice cronológico, artigos legíveis e RSS. Foram selecionadas apenas 18 opções — conhecidas e menos óbvias — porque, neste caso, uma lista curta e bem julgada é mais útil que um catálogo de centenas de geradores.

Resumo executivo

Recomendação principal: Eleventy (11ty). Ele se encaixa especialmente bem porque permite começar de HTML quase puro, acrescentar Markdown, uma coleção cronológica e RSS sem impor componentes, CSS, JavaScript no navegador ou um tema. O resultado final pode ser tão simples quanto o próprio mur.ad, enquanto a automação evita editar manualmente o índice e o feed a cada postagem. A documentação oficial confirma suporte a múltiplas linguagens de template, coleções e paginação; o feed é oferecido pelo plugin oficial RSS.

Alternativa mais simples de operar: Hugo. Um único executável, recursos de blog muito completos e RSS gerado por padrão tornam Hugo excelente se você aceitar aprender seus templates em Go. É a escolha mais segura para centenas ou milhares de textos, e pode produzir HTML absolutamente minimalista sem tema.

Alternativa sem ecossistema Node: Zola. Também é distribuído como executável único, tem Markdown, taxonomias, paginação e feeds integrados. É a melhor combinação entre pouca manutenção operacional e templates compreensíveis.

Opção deliberadamente artesanal: Pandoc + Make. Para dez ou vinte páginas, é atraente e transparente; porém, índice, tags, RSS e datas passam a depender de scripts seus. HTML manual é ainda mais direto, mas deixa de ser recomendável quando o blog cresce.

Para este projeto, SSI não é a solução principal e um CMS tradicional é excesso de infraestrutura. O conteúdo muda apenas quando você publica, portanto faz mais sentido gerar arquivos estáticos antes do envio ao servidor.

Ranking final

Metodologia e critérios

O site de referência foi aberto e inspecionado em navegador em 8 de setembro de 2026, incluindo página inicial, índice do blog e uma página de artigo. O HTML usa fonte serifada e links padrão do navegador, fundo branco e somente CSS inline mínimo: body { max-width: 700px; margin: 40px auto; padding: 0 20px; line-height: 1.6; }. Não foi encontrada folha CSS externa nem JavaScript próprio — apenas código da infraestrutura Cloudflare. O índice do blog é cronológico, com lista sem marcadores, datas cinza em 0.9em e link para RSS; os artigos usam headings, imagens e blockquotes. A home contém meta description, canonical e JSON-LD do tipo Person.

Não há metatag generator nem comentário que revele um SSG. Portanto, esses achados descrevem somente o resultado entregue ao navegador; a tecnologia de construção de mur.ad permanece não identificada.

Cada candidato recebeu avaliação por: capacidade de produzir HTML sem ornamentos; Markdown; templates; índice cronológico; RSS; tags; paginação; facilidade de build e deploy; dependências; curva de aprendizado; atividade pública do projeto; portabilidade; e custo de manutenção futura. A situação atual foi conferida em documentação ou repositório oficial. Recursos que só funcionam por plugin são descritos como tal.

Antes de escolher: SSG, SSI, CMS ou HTML manual?

SSG: gerar antes de publicar

Um Static Site Generator lê Markdown, dados e templates no computador ou em uma automação, produz arquivos HTML e então os envia ao servidor. O visitante recebe arquivos prontos: não há banco de dados, painel administrativo ou linguagem de servidor necessária. Isso reduz ataque, consumo e custo. Eleventy, Hugo e Zola pertencem a essa classe.

É a opção certa aqui porque o pequeno trabalho adicional no build compra quatro comodidades importantes: cada novo Markdown vira artigo, o índice se atualiza, tags podem ser geradas e o RSS não precisa ser editado à mão.

SSI: incluir fragmentos durante a requisição

Server Side Includes são diretivas simples interpretadas pelo servidor web — por exemplo, inserir o mesmo cabeçalho em diversas páginas. Podem servir em hospedagem Apache ou nginx configurada para SSI, mas não são um sistema de conteúdo: não convertem Markdown, não criam automaticamente arquivos de tags, paginação ou feeds. Também acoplam o site à configuração do servidor. Para este blog, SSI só faria sentido em um conjunto de páginas HTML manuais já existente.

CMS: montar páginas no servidor

Um CMS como WordPress normalmente oferece editor web, usuários, mídia, plugins, pesquisa e conteúdo dinâmico. É útil quando várias pessoas precisam publicar sem Git ou terminal. Em troca, exige atualizações, banco de dados, backup de aplicação e cuidados de segurança. Para um blog pessoal minimalista mantido por uma pessoa, é uma solução funcional, mas desproporcional.

HTML manual: o mínimo absoluto

Escrever index.html, blog/index.html e cada artigo à mão garante independência completa. A desvantagem aparece no segundo lugar em que o mesmo dado precisa ser copiado: título e data no artigo, índice e RSS. Pequenos erros e links esquecidos se acumulam. É aceitável para uma página pessoal quase parada; para um blog de verdade, um SSG pequeno preserva o espírito artesanal sem repetir trabalho.

As 18 opções avaliadas

1. Eleventy (11ty) — a recomendação principal

O Eleventy é um gerador em JavaScript/Node que transforma uma árvore de arquivos em outra. Aceita Markdown e várias linguagens de template, incluindo Liquid, Nunjucks e WebC; também permite usar HTML como template. Coleções agrupam e ordenam postagens, a paginação é nativa e o plugin RSS oficial gera e valida feeds.

• Por que combina: começa com HTML, não com um framework visual. Nenhum CSS ou JavaScript de cliente é obrigatório. Um layout de poucas linhas reproduz exatamente a simplicidade procurada.
• Blog: Markdown, frontmatter, coleções e paginação são diretos; RSS requer ativar o plugin oficial. Tags são normalmente modeladas com coleções.
• Build/deploy: requer Node durante o build, mas a saída é uma pasta de arquivos estáticos utilizável em qualquer servidor.
• Curva e manutenção: intermediária-baixa. A liberdade de escolher templates é ótima, mas cria decisões que Hugo e Zola já tomam.
• Limitação: a flexibilidade do ecossistema npm pode incentivar dependências demais. Para este projeto, use configuração curta e bloqueie versões no arquivo de lock.

2. Hugo — o pacote de blog mais completo

Hugo é escrito em Go e normalmente instalado como um executável. Conteúdo em Markdown, layouts, seções, taxonomias, menus, resumos e paginação fazem parte do núcleo. A documentação informa que o build gera RSS para home, seções, taxonomias e termos por padrão.

• Por que combina: um layout baseof.html, uma lista e uma página individual bastam; tema é opcional. O executável não vira dependência do servidor.
• Blog: é o conjunto nativo mais completo deste ranking: datas, rascunhos, tags, categorias, arquivos, paginação e RSS.
• Build/deploy: hugo cria public/; essa pasta pode ser servida por nginx, Caddy, Apache, object storage ou Pages.
• Curva e manutenção: instalação fácil; templates Go e o modelo de lookup exigem estudo. Depois de pronto, a manutenção é pequena.
• Limitação: para um site de cinco templates, a documentação extensa pode parecer mais complexa que Eleventy.

3. Zola — executável único e convenções sensatas

Zola é um SSG em Rust com templates Tera. Tem Markdown, seções, shortcodes, Sass, taxonomias e feeds. A configuração oficial permite paginar taxonomias e gerar feed por termo.

• Por que combina: não injeta frontend e dispensa runtime Node/Python no build. Os templates podem emitir HTML mínimo.
• Blog: Markdown, tags/categorias configuráveis, paginação e Atom/RSS estão integrados.
• Build/deploy: zola build produz public/; distribuição por binário facilita CI e Windows/Linux.
• Curva e manutenção: baixa a média. Menor ecossistema que Hugo, porém menos peças externas.
• Limitação: menos exemplos e integrações prontas; se o projeto virar aplicação, Astro terá mais alcance.

4. Lume — minimalismo moderno com Deno

Lume usa Deno e aceita Markdown, JavaScript/TypeScript e diferentes templates. Tags agrupam páginas; busca e paginação fazem parte do fluxo, e o plugin oficial de feed gera RSS ou JSON Feed.

• Por que combina: a filosofia baseada em arquivos e seus templates Vento/Nunjucks permitem HTML nu, sem bundle para o navegador.
• Blog: recursos essenciais são claros, embora RSS seja plugin.
• Build/deploy: Deno é necessário apenas na criação; a saída estática vai a qualquer host.
• Curva e manutenção: agradável para quem conhece JS/TS. Ecossistema menor que Node, mas o uso de URLs/import maps requer adaptação.
• Limitação: menos difundido; outra pessoa pode conhecer Eleventy ou Hugo mais rapidamente.

5. Astro — espaço para crescer sem sacrificar o HTML

Astro é um framework voltado a sites de conteúdo. Suas Content Collections carregam Markdown/MDX e validam metadados; há paginação estática e o pacote oficial @astrojs/rss. Uma página sem componentes interativos pode sair sem JavaScript de cliente.

• Por que combina: entrega HTML limpo e torna fácil acrescentar imagens otimizadas ou componentes mais tarde.
• Blog: coleções tipadas são excelentes; tags são consultas/rotas criadas pelo autor; paginação é nativa; RSS usa pacote oficial.
• Build/deploy: Node e npm/pnpm no build; saída estática independente, ou adaptadores se futuramente houver servidor.
• Curva e manutenção: média. É tecnologia a mais para a aparência atual, mas a melhor proteção caso o blog vire site rico.
• Limitação: componentes, integrações e TypeScript são distrações se a intenção for permanecer radicalmente simples.

6. Pelican — escolha natural em Python

Pelican é um gerador de blog em Python com Jinja2. Trabalha com Markdown e reStructuredText, cria páginas de autores, categorias e tags e oferece feeds e paginação configuráveis. A documentação estável consultada corresponde à linha 4.12.

• Por que combina: templates Jinja podem ser quase HTML puro e Python é comum em servidores e automações.
• Blog: muito completo; feeds, arquivos, categorias, tags, rascunhos e paginação já pertencem ao produto.
• Build/deploy: ambiente Python só no build; pelican content gera a saída estática.
• Curva e manutenção: baixa para quem conhece Python. Configuração extensa, mas madura.
• Limitação: para um blog mínimo, o arquivo de configuração e o tema inicial podem trazer mais estrutura do que o necessário.

7. Jekyll — previsível e amplamente documentado

Jekyll usa Ruby, Markdown e Liquid. Posts datados, layouts, coleções e tags/categorias são conceitos centrais; o plugin oficial jekyll-feed produz feeds e jekyll-paginate atende o modelo clássico de paginação.

• Por que combina: é fácil remover o tema e manter só layouts HTML. O formato _posts/AAAA-MM-DD-titulo.md é legível e portátil.
• Build/deploy: Ruby/Bundler durante o build; saída _site/. GitHub Pages o suporta, mas o resultado não depende dela.
• Curva e manutenção: documentação vasta; instalação Ruby no Windows costuma ser menos suave que binários Hugo/Zola.
• Limitação: feed e paginação dependem de plugins, e o ecossistema carrega convenções históricas.

8. Soupault — o “webmaster robô” para HTML

Soupault trabalha sobre a árvore de elementos HTML: pode gerar um site, transformar páginas existentes ou funcionar como pós-processador. Possui Markdown integrado e executáveis para Linux, Windows e macOS.

• Por que combina: é o candidato que mais respeita HTML como fonte, ideal para começar manualmente e automatizar índice, metadados e inclusões aos poucos.
• Blog: há blueprint oficial de blog, porém recursos são compostos por regras/plugins em vez das convenções prontas de Hugo.
• Build/deploy: executável local; saída estática universal.
• Curva e manutenção: conceito diferente, documentação menor e maior responsabilidade do autor.
• Limitação: brilhante para transformação de HTML, mas menos imediato para alguém que simplesmente quer escrever Markdown e publicar.

9. Nikola — um blog completo e multilíngue

Nikola é um gerador Python focado em blogs. O manual documenta Markdown/reStructuredText, índices, arquivos, tags, categorias e feeds; cada tag/categoria pode ter página e feed.

• Por que combina: gera HTML estático e permite tema próprio mínimo; lida bem com várias línguas e formatos de entrada.
• Build/deploy: Python no build, arquivos estáticos na saída.
• Curva e manutenção: o sistema é maduro, mas a configuração é grande e contém muitas capacidades irrelevantes para este projeto.
• Limitação: escolher Pelican costuma ser mais natural para um usuário Python que não precise dos muitos formatos e da internacionalização avançada.

10. Hexo — blog pronto no ecossistema Node

Hexo é um framework de blog em Node: escreve-se em Markdown e ele gera arquivos estáticos. Possui posts, páginas, rascunhos, arquivos e paginação; categorias, tags e feeds são atendidos por geradores/plugins, incluindo o gerador oficial de feed.

• Por que combina: criação e publicação rápidas; um tema próprio pode ser mínimo.
• Curva: baixa para começar, média para abandonar completamente as convenções de temas.
• Limitação: sua cultura privilegia temas mais elaborados. Para reproduzir mur.ad, Eleventy oferece menos coisas para desmontar.

11. Metalsmith — pipeline explícito em JavaScript

Metalsmith é um SSG extremamente simples e extensível para Node. Uma cadeia de plugins oficiais pode converter Markdown, criar coleções, permalinks e aplicar layouts em Nunjucks, Handlebars, Pug ou outras linguagens.

• Por que combina: nada visual é imposto e o pipeline fica completamente sob controle.
• Blog: Markdown, coleções e layouts são oficiais; RSS, tags e paginação demandam plugins ou código de montagem.
• Limitação: é uma caixa de ferramentas, não um blog pronto. Vale para quem aprecia construir a engrenagem; Eleventy chega ao mesmo resultado com menos decisões.

12. Pandoc + Make — artesanal, rastreável e Unix-friendly

Pandoc converte Markdown em HTML completo com --standalone e aceita templates personalizados. Make, just ou um pequeno script pode percorrer posts e gerar páginas.

• Por que combina: uma ferramenta universal, um template HTML e quase nenhuma abstração. Também aceita recursos ricos de Markdown.
• Blog: conversão e template são excelentes; coleção cronológica, RSS, tags e paginação não são produto pronto e precisam ser programados.
• Build/deploy: muito portátil em Linux; saída estática.
• Limitação: scripts caseiros viram um SSG próprio. Recomendado apenas se essa autoria fizer parte do prazer do projeto.

13. Hakyll — biblioteca para quem quer programar o gerador

Hakyll é uma biblioteca Haskell para criar sites estáticos e usa Pandoc para conteúdo. O tutorial oficial demonstra posts, templates, listas e feed.

• Por que combina: controle extremo e HTML final totalmente seu.
• Blog: tudo é expressável, incluindo tags e RSS, mas boa parte é código Haskell do projeto.
• Limitação: instalar toolchain e manter programa de build não se justifica sem interesse prévio em Haskell.

14. Bridgetown — sucessor moderno no mundo Ruby

Bridgetown é um gerador progressivo em Ruby, com Node para processamento frontend. Trabalha com Markdown, Liquid e componentes; a paginação é integrada.

• Por que combina: pode produzir uma versão muito simples hoje e crescer para componentes depois.
• Blog: coleções e paginação são fortes; feed depende de plugin/configuração.
• Limitação: duas toolchains e ambições de framework são excesso para uma página deliberadamente crua.

15. Cobalt — alternativa compacta em Rust

Cobalt é um SSG escrito em Rust, com Markdown, Liquid e recursos de blog.

• Por que combina: executável e modelo simples, sem frontend obrigatório.
• Blog: posts, dados e templates cobrem o essencial; ecossistema e documentação são menores.
• Manutenção: trate como opção de nicho e confira releases/compatibilidade antes de adotá-lo; não é a escolha conservadora deste ranking.
• Limitação: Zola oferece vantagens semelhantes com documentação e funções integradas mais claras.

16. Statiq Web — bom encaixe para .NET

Statiq Web é um framework/gerador estático sobre .NET e o pipeline Statiq. Converte Markdown, processa metadados e permite templates Razor.

• Por que combina: excelente se o restante da automação já é C#/.NET; saída totalmente estática.
• Blog: requer configurar pipeline ou usar bootstrapper; RSS, taxonomias e paginação são menos imediatos que em Hugo.
• Limitação: não adote uma toolchain .NET exclusivamente para um blog tão simples.

17. Franklin — para cientistas e usuários de Julia

Franklin.jl é um gerador em Julia voltado a sites técnicos, com Markdown estendido, equações e avaliação de código.

• Por que combina: pode produzir HTML enxuto e é atraente para anotações científicas.
• Blog: páginas e templates funcionam bem; um blog convencional e RSS exigem mais adaptação que as primeiras opções.
• Limitação: a inicialização/runtime Julia e o foco científico são injustificáveis se não fazem parte do seu trabalho.

18. HTML manual — a referência de simplicidade

Não é software, mas precisa permanecer na comparação. Uma pasta com documentos HTML válidos funciona em qualquer servidor e pode se parecer exatamente com mur.ad.

• Por que combina: controle, longevidade e zero dependências.
• Onde falha: cada publicação pede edição coordenada do artigo, índice e rss.xml; tags e paginação multiplicam essa repetição.
• Veredito: ótimo para a home e páginas institucionais; use Eleventy/Hugo/Zola para a parte repetitiva do blog.

Arquitetura mínima recomendada com Eleventy

Uma organização suficiente — sem framework CSS e sem JavaScript no navegador — seria:

blog/
├── package.json
├── eleventy.config.js
├── src/
│   ├── _includes/
│   │   └── base.njk
│   ├── posts/
│   │   └── 2026-09-08-primeiro-post.md
│   ├── index.njk
│   ├── blog.njk
│   ├── feed.njk
│   └── estilo.css          # opcional
└── _site/                  # saída gerada; não editar

O layout pode ser quase só o documento semântico:

<!doctype html>
<html lang="pt-BR">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{{ title }}</title>
  <link rel="alternate" type="application/rss+xml" href="/feed.xml">
</head>
<body>
  <nav><a href="/">início</a> · <a href="/blog/">blog</a></nav>
  <main>{{ content | safe }}</main>
</body>
</html>

Para uma aproximação fiel, este CSS reproduz as decisões essenciais observadas e ainda preserva o caráter mínimo:

body {
  max-width: 700px;
  margin: 40px auto;
  padding: 0 20px;
  line-height: 1.6;
}
img { max-width: 100%; height: auto; }

O img responsivo é uma recomendação desta pesquisa, não uma alegação sobre o código do site observado. O CSS pode ficar inline no <head> para manter um único documento sem requisição externa. Teste o resultado em celular e monitor grande antes de publicar.

Hospedagem barata, gratuita e independente

Como todos os candidatos recomendados geram arquivos estáticos, a hospedagem não precisa conhecer o gerador.

Sem depender de uma plataforma proprietária

• VPS existente + Caddy ou nginx: copie _site//public/ por rsync, SFTP ou Git. Caddy automatiza HTTPS; nginx é universal. Custo marginal praticamente zero se o servidor já existe.
• Hospedagem compartilhada: qualquer plano com acesso SFTP serve arquivos HTML. Não é preciso PHP ou banco.
• Servidor doméstico: funciona com proxy/túnel e backup, mas disponibilidade, IP e energia passam a ser sua responsabilidade.
• Object storage compatível com S3: bom para arquivos estáticos e CDN, porém domínio/HTTPS e cobranças de saída variam.

Serviços convenientes

GitHub Pages, GitLab Pages, Codeberg Pages, Cloudflare Pages, Netlify e similares podem hospedar gratuitamente projetos pequenos, sujeitos a termos e limites que mudam. A medida anti-lock-in é simples: mantenha fontes, configuração e build no seu repositório e confirme que a saída funciona em um servidor HTTP comum. Assim, migrar significa copiar uma pasta, não reescrever o blog.

Para máxima independência, faça o build localmente ou numa CI que você controla e publique somente os arquivos finais. Não vincule comentários, formulários ou identidade a APIs proprietárias sem necessidade.

Recomendações práticas

1. Faça um protótipo em Eleventy sem tema. Recrie apenas home, índice e um artigo. Se a configuração parecer natural, encerre a comparação e publique.
2. Teste Hugo e Zola somente como desempate. Hugo ganha se você quer tudo integrado; Zola ganha se prefere binário único e templates Tera.
3. Preserve o conteúdo como Markdown portátil. Use frontmatter pequeno: title, date, description, tags e talvez draft. Não grave dados essenciais apenas em plugins.
4. Trate RSS como parte do produto. Gere feed completo ou com bons resumos, adicione <link rel="alternate">, valide XML e teste em dois leitores.
5. Não instale um tema para depois desmontá-lo. Escreva um layout HTML próprio de 20–40 linhas. O estilo desejado é mais fácil de construir do zero.
6. Defina URLs estáveis antes de publicar. Uma forma segura é /blog/AAAA/MM/slug/ ou /blog/slug/. Mudanças futuras exigem redirecionamentos.
7. Automatize três verificações: links internos, build sem erro e presença do artigo no índice/feed.
8. Guarde a pasta de saída fora da autoria. Nunca edite _site/ ou public/ manualmente; elas devem poder ser apagadas e regeneradas.
9. Use HTML semântico e acessível. Mesmo sem CSS, inclua lang, viewport, texto alternativo, ordem correta de headings e datas em <time>.
10. Adie SSI, banco de dados e JavaScript. Acrescente-os apenas quando surgir uma necessidade concreta que HTML estático não resolva.

Decisão em uma frase

Escolha Eleventy sem tema, escreva em Markdown, gere HTML e RSS, e publique a pasta resultante no servidor que você já controla; se quiser evitar Node, use Zola, e se priorizar um blog completo com máxima maturidade operacional, use Hugo.

Conclusão

O traço decisivo de mur.ad não é um gerador específico, mas a recusa de tratar uma página pessoal como uma aplicação. O navegador já sabe renderizar títulos, parágrafos, listas, links, imagens e citações. A tecnologia escolhida deve automatizar a repetição editorial sem encobrir essa base.

Eleventy é a melhor escolha porque mantém HTML no centro e acrescenta somente as conveniências necessárias. Hugo e Zola são alternativas igualmente sólidas para quem prefere executáveis autocontidos. Astro é justificável apenas se houver plano concreto de evolução. CMS, SSI e frameworks de frontend não oferecem vantagem proporcional no escopo atual. O resultado recomendado é pequeno, rápido, acessível, fácil de fazer backup e transferível entre praticamente todas as hospedagens.

Fontes consultadas

• mur.ad — página de referência
• Eleventy — documentação oficial
• Eleventy — plugin RSS oficial
• Eleventy — paginação
• Hugo — documentação oficial
• Hugo — templates RSS
• Zola — visão geral
• Zola — taxonomias
• Lume — documentação
• Lume — plugin de feed
• Astro — Content Collections
• Astro — receita oficial de RSS
• Astro — paginação e rotas
• Pelican — documentação estável
• Jekyll — documentação oficial
• Jekyll Feed — repositório oficial
• Soupault — site e documentação oficial
• Nikola — documentação oficial
• Hexo — documentação oficial
• Metalsmith — guia oficial
• Pandoc — manual oficial
• Hakyll — site oficial
• Bridgetown — documentação oficial
• Cobalt — site oficial
• Statiq Web — documentação oficial
• Franklin.jl — documentação oficial
• Caddy — servidor de arquivos estáticos
• nginx — serving static content

Nota sobre atualidade

Pesquisa concluída em 8 de setembro de 2026. Versões, plugins, modelos gratuitos e situação de manutenção podem mudar; confirme-os nas páginas oficiais antes de escolher a pilha definitiva.