Hugo além do tutorial — o que me fez largar o WordPress depois de 20 anos
Índice
Já publiquei o passo a passo para montar este blog: repositório no GitHub, tema Terminal, deploy no Cloudflare, tudo documentado. Este post trata de outra coisa: quero explicar o que me fez sair do WordPress depois de vinte anos, o que mudou na web ao nosso redor e o que o Hugo oferece hoje para quem publica conteúdo.
O texto parte da minha experiência pessoal, mas traz dados e funcionalidades concretas. Serve tanto para quem conhece WordPress de cor quanto para quem está escolhendo uma plataforma pela primeira vez.
Vinte anos de WordPress (e por que eu não saía)
Comecei com o WordPress na versão 2.alguma coisa. Naquela época o software era pouco mais que um sistema de blog, mas tinha uma qualidade rara: funcionava: a pessoa instalava, escolhia um tema, escrevia, publicava. O ciclo era curto e gratificante. Para alguém que passava o dia inteiro em terminais e arquivos de configuração, ter um painel visual onde as coisas simplesmente aconteciam era um alívio.
O WordPress foi crescendo e eu fui crescendo junto. Aprendi a montar temas, a escolher plugins, a otimizar o banco de dados, a configurar cache, a lidar com atualizações que quebravam tudo e com as que não quebravam nada. Quando comecei a revender hospedagem pela PortoFácil, o WordPress era a resposta padrão para qualquer cliente que precisasse de um site. E funcionava, na maioria das vezes — ainda funciona, para ser justo.
Inércia tecnológica não vem da preguiça, mas sim da competência: quando você domina uma ferramenta ao ponto de resolver qualquer problema nela em minutos, trocar por outra significa aceitar semanas de incompetência voluntária. Eu sabia configurar Nginx para servir WordPress com os olhos fechados, diagnosticar um site lento olhando o slow query log do MySQL, qual plugin de cache usar e qual evitar. Todo esse conhecimento acumulado funcionava como um muro entre mim e qualquer alternativa.
Tentei o Hugo uma vez, anos atrás. Achei a documentação confusa, o sistema de templates pouco intuitivo e a falta de um painel de administração um retrocesso. Experimentei o Ghost também, que prometia ser o WordPress sem a gordura, mas trazia suas próprias desvantagens, incluindo o Node.js e uma assinatura mensal para a versão hospedada. Em ambos os casos, voltei para o WordPress em menos de uma semana, com a sensação confortável de quem confirma que já estava no lugar certo.
O problema é que o lugar certo mudou sem eu perceber.
A Internet morta e o custo de manter um servidor dinâmico
Em 2024, o tráfego automatizado na web ultrapassou o tráfego humano pela primeira vez. O relatório Bad Bot Report da Imperva registrou 51% de todo o tráfego vindo de bots. Em 2025, a Ahrefs analisou 900.000 páginas recém-publicadas e encontrou conteúdo gerado por IA em 74,2% delas. O cofundador do Reddit, Alexis Ohanian, declarou publicamente que a teoria da Internet morta “é real”. Não se trata mais de especulação, e nem sou só eu dizendo.
O volume de conteúdo sintético afeta diretamente quem mantém sites dinâmicos. Bots não se limitam a ler páginas: eles testam formulários de login, procuram plugins desatualizados, varrem diretórios em busca de arquivos expostos. Um WordPress padrão, com PHP, MySQL e meia dúzia de plugins, oferece uma superfície de ataque generosa para esse tipo de automação. Cada plugin é um ponto de entrada possível, cada chamada ao banco de dados é uma oportunidade para injeção de SQL. O wp-admin aberto na porta 443 é um convite permanente.
Quem administra WordPress profissionalmente sabe o peso dessa manutenção. Atualizações de core, de tema e de plugins precisam acontecer com frequência, e cada uma carrega o risco de quebrar algo. Monitoramento de segurança, firewalls de aplicação, backups diários, rotação de credenciais. Tudo funciona, mas tudo custa tempo e atenção constantes.
Um site estático elimina categorias inteiras de risco: não existe banco de dados para invadir ou código server-side para explorar, nem plugins de terceiros rodando com permissões elevadas. O servidor entrega arquivos HTML prontos, e nada mais. Quando o tráfego de bots maliciosos supera o tráfego legítimo na web aberta, reduzir a superfície de ataque a zero deixa de ser paranoia e passa a ser pragmatismo.
O Hugo que eu encontrei não é o Hugo que eu abandonei
Quando experimentei o Hugo pela primeira vez, o software gerava HTML a partir de Markdown e pronto. O sistema de templates era funcional, mas exigia paciência para entender a lógica do Go. A documentação deixava lacunas. A experiência inteira passava a sensação de uma ferramenta feita por desenvolvedores para desenvolvedores, sem muita preocupação com quem vinha de fora.
O Hugo de 2026 é outro software. O projeto acumula mais de 87.000 estrelas no GitHub e mantém um ciclo de releases frequente, com funcionalidades que teriam parecido absurdas cinco anos atrás.
O build continua rápido, mas a escala mudou. Um site com 10.000 páginas em Markdown compila em menos de 10 segundos. A versão mais recente suporta streaming builds, o que permite gerar sites com mais de um milhão de páginas sem estourar a memória. Para um blog pessoal isso é irrelevante, mas para documentação corporativa ou portais de notícias, muda o jogo.
O asset pipeline agora vem embutido. Processamento de imagens (redimensionar, cortar, rotacionar, ajustar cores, aplicar filtros, sobrepor texto e extrair EXIF), bundling de JavaScript com tree shaking e code splitting, processamento de Sass e suporte a TailwindCSS. Nada disso exige plugins externos ou ferramentas separadas no pipeline de build. Está tudo dentro do binário do Hugo.
Content adapters permitem puxar dados de fontes remotas e APIs diretamente no build. Isso significa que o site continua 100% estático depois de publicado, mas o conteúdo de origem não precisa estar todo em arquivos locais.
A instalação continua sendo um binário único, compilado em Go, sem dependências de runtime. Não precisa de Ruby, de Node.js, de Python nem de nenhum gerenciador de pacotes. É só faz download, colocar no PATH e tudo funciona, em qualquer sistema operacional.
Multilíngue sem plugin, sem gambiarra
No WordPress, publicar conteúdo em mais de um idioma exige instalar um plugin como WPML ou Polylang. Os dois funcionam, mas adicionam complexidade ao banco de dados, criam conflitos com temas e outros plugins, e cobram licenças anuais. A experiência de edição muda, porque o painel precisa acomodar seletores de idioma, traduções vinculadas e duplicações de páginas. Cada atualização do plugin carrega o risco de quebrar a relação entre as versões linguísticas do conteúdo.
O Hugo trata multilíngue como funcionalidade nativa. A configuração acontece no arquivo hugo.toml, onde você define os idiomas disponíveis, os parâmetros de cada um (título do site, subtítulo, rótulos de navegação) e os menus correspondentes. O conteúdo de cada idioma vive em arquivos separados dentro da mesma estrutura de diretórios. Um post em português fica em pt/post.md e a versão em inglês fica em en/post.md. O Hugo sabe que os dois arquivos são versões do mesmo conteúdo e gera automaticamente os links de alternância entre idiomas.
Strings de interface como “Leia mais”, “Posts recentes” ou “Voltar ao início” ficam em arquivos de tradução no diretório i18n. Você escreve a tradução uma vez e o tema aplica conforme o idioma da página. Não existe duplicação de templates nem lógica condicional espalhada pelo código.
O resultado é que adicionar um idioma ao site significa criar um bloco de configuração no hugo.toml, adicionar um arquivo de traduções e começar a escrever as versões traduzidas do conteúdo. Não existe plugin para instalar, licença para renovar nem banco de dados para manter sincronizado. Este post que você está lendo existe em português e em inglês, gerado a partir de dois arquivos Markdown no mesmo repositório, e o Hugo resolve todo o resto no momento do build.
Diagramas, fórmulas matemáticas e conteúdo técnico como cidadãos de primeira classe
Blogs técnicos precisam de mais do que texto e imagens. Dependendo no nicho, precisam de diagramas de arquitetura, fluxogramas, fórmulas matemáticas e blocos de código com syntax highlighting. No WordPress, cada uma dessas necessidades exige um plugin separado. Um para renderizar LaTeX, outro para diagramas Mermaid, outro para melhorar a exibição de código. Cada plugin traz suas dependências JavaScript, seus conflitos potenciais com o tema e suas atualizações periódicas.
O Hugo resolve a maior parte disso sem instalar nada. Syntax highlighting vem embutido no gerador, usando a biblioteca Chroma. O código é renderizado durante o build com as cores e a formatação corretas, sem carregar nenhum JavaScript no navegador do visitante. Isso significa que os blocos de código aparecem instantaneamente, sem aquele flash de texto sem formatação que acontece quando a biblioteca de highlight precisa processar a página no client-side.
Para diagramas, o Hugo suporta nativamente GoAT, que transforma blocos de texto ASCII em SVGs durante o build. Para quem precisa de diagramas mais elaborados, a integração com Mermaid funciona através de um render hook para code fences. Você cria um template pequeno em layouts/_markup/render-codeblock-mermaid.html, adiciona o script do Mermaid no template base, e a partir daí qualquer code fence marcado como mermaid no Markdown vira um diagrama renderizado na página. Flowcharts, diagramas de sequência, Gantt, diagramas de classe, diagramas de estado, tudo a partir de texto puro dentro do próprio conteúdo.
Fórmulas matemáticas seguem o mesmo princípio. O Hugo suporta tipografia LaTeX e TeX com renderização server-side via KaTeX. A fórmula é processada durante o build e entregue ao navegador como HTML pronto, sem depender de JavaScript para renderizar no lado do cliente.
O ponto em comum dessas funcionalidades é que o conteúdo técnico vive dentro do Markdown, junto com o texto, versionado no Git como qualquer outro arquivo. Não existe painel de configuração, não existe banco de dados guardando estado, e não existe risco de perder um diagrama porque um plugin foi desativado.
O que o Hugo não faz (e por que isso é uma vantagem)
O Hugo não tem painel de administração, sistema de login, nem gerenciamento de usuários, comentários nativos, formulários de contato nem carrinho de compras. Para quem vem do WordPress, onde tudo isso existe a um plugin de distância, a lista de ausências parece longa.
Cada uma dessas ausências é uma porta a menos na superfície de ataque do site. Sem painel admin, não existe endpoint /wp-admin para bots tentarem força bruta. Sem banco de dados, não existe SQL para injetar. Sem sistema de login, não existem credenciais para roubar. O site publicado é uma coleção de arquivos HTML, CSS e imagens servidos diretamente por um CDN. A complexidade acaba no momento do build.
Isso não significa abrir mão de funcionalidades dinâmicas e sim desacoplar cada uma delas do gerador de conteúdo. Comentários entram através de um serviço externo como o Isso, que roda em seu próprio servidor com seu próprio banco SQLite. Formulários de contato funcionam via Formspree ou serviços similares. Busca no site se resolve com Pagefind, que gera um índice estático durante o build e roda inteiramente no navegador do visitante, sem servidor de busca.
A diferença em relação ao modelo WordPress é que cada serviço externo é substituível de forma independente. Se o Isso parar de atender, você troca por outro sistema de comentários sem tocar no restante do site. Se o Formspree mudar os preços, migra para outro serviço de formulários. O site em si continua funcionando porque não depende de nenhum deles para existir.
No WordPress, desativar um plugin de cache quebra a performance. Desativar o plugin de SEO apaga os metadados. Desativar o plugin de segurança expõe o site. Os plugins formam uma cadeia de dependências onde cada elo sustenta o próximo. No Hugo, o site funciona com zero dependências externas. Tudo o que você adiciona por cima é opcional e descartável.
Para quem o Hugo não serve
Seria desonesto fechar este post sem falar das limitações. O Hugo atende muito bem quem publica conteúdo textual, seja blog, documentação ou site institucional. Fora desse escopo, a conversa muda.
Clientes não-técnicos precisam de um painel visual onde possam editar texto, trocar imagens e publicar sem abrir um terminal. O WordPress entrega isso nativamente. Com o Hugo, a alternativa mais próxima é um CMS headless como o Pages CMS ou o Decap CMS, que adiciona uma interface gráfica sobre os arquivos Markdown no repositório. Funciona, mas a experiência de edição nunca vai ser tão polida quanto o editor do WordPress. Quem não se sente confortável com Git, Markdown ou deploys automatizados vai precisar de suporte constante.
Sites que precisam de e-commerce nativo encontram no WooCommerce um ecossistema maduro, com gateway de pagamento, controle de estoque, cálculo de frete e emissão de nota fiscal. Replicar tudo isso em um site estático exige integrar múltiplos serviços externos (Snipcart, Stripe, APIs de logística), e o resultado final é mais frágil e mais trabalhoso de manter do que uma instalação WordPress bem configurada.
Projetos onde o conteúdo muda várias vezes por hora, como portais de notícias com redação ativa, sofrem com o ciclo de build e deploy do Hugo. Cada alteração exige um novo build e um novo deploy, e mesmo que o build leve segundos, o pipeline completo (commit, push, build no CI, invalidação de cache no CDN) adiciona latência. O WordPress publica na hora em que o autor clica em “Publicar”.
O WordPress continua sendo uma ferramenta excelente para os cenários onde brilha. O ponto deste post não é declarar um vencedor. É registrar que para blogs, sites pessoais, documentação técnica e publicações onde o autor controla o conteúdo, a equação mudou. O custo de manter um servidor dinâmico exposto na web de 2026, com seus bots, seus ataques automatizados e seu conteúdo sintético, precisa entrar na conta. E quando entra, o Hugo, com sua simplicidade e sua previsibilidade, se torna uma escolha difícil de ignorar.