Geradores de sites estáticos

TL;DR — Um gerador de sites estáticos cria todo o seu site como arquivos HTML simples antecipadamente. Assim, quando o Google chega, o conteúdo já está na página — sem esperar o JavaScript ser executado. É a configuração mais simples possível para SEO. O porém: o site só é atualizado quando você o gera novamente.

O que é um gerador de sites estáticos

A maior parte dos problemas de SEO com JavaScript se resume a uma pergunta: seu conteúdo realmente está na página quando um rastreador a busca ou só aparece depois que os scripts são executados? Um gerador de sites estáticos (SSG) evita essa questão por completo.

Um SSG pega seu conteúdo (geralmente escrito em Markdown) e seus templates e — no seu computador ou em um servidor de build — transforma cada página em um arquivo HTML pronto antes de qualquer visita. Depois, você envia esses arquivos HTML simples para uma hospedagem. Quando o Google, o Bing ou um leitor solicita uma página, recebe o HTML completo logo na primeira tentativa. Evidência desta afirmação A static site generator builds source content and templates into static files before requests are served. Escopo: Hugo as a representative static site generator. Confiança: alta · Verificado: 2026-07-14 Hugo documentation

Compare isso com um aplicativo JavaScript típico, em que o servidor envia uma estrutura quase vazia e o navegador monta a página depois. Com um SSG, não há nada para montar no navegador — isso já foi feito.

Por que isso é ótimo para SEO

• O conteúdo está no HTML bruto. Nenhuma etapa de renderização precisa funcionar para o Google ver seus textos e links.
• É rápido. Arquivos HTML simples carregam rapidamente, o que ajuda os Core Web Vitals.
• Há menos pontos de falha. Menos peças móveis significam menos maneiras de o conteúdo desaparecer da busca.

Os mais conhecidos

Há seis sobre os quais você ouvirá falar com mais frequência: Hugo, Jekyll, Eleventy, Hexo, Gatsby e Astro. Todos produzem HTML estático; eles diferem na linguagem em que foram criados e na quantidade de JavaScript adicional (se houver) que enviam ao navegador. Cada um tem uma análise detalhada própria com link no fim desta página.

O principal ponto de atenção

Um site estático é um retrato. Ele mostra o que era verdadeiro na última vez em que você o gerou. Se você alterar um preço, corrigir um erro de digitação ou publicar um post e esquecer de gerar e implantar novamente, os mecanismos de busca continuarão vendo a versão antiga. Portanto, a principal disciplina com um SSG é garantir que as alterações acionem um novo build. Evidência desta afirmação Changes to a statically generated site require a new build and deployment before the generated output changes. Escopo: Astro static builds as a representative SSG workflow. Confiança: alta · Verificado: 2026-07-14 Astro: Deploy your site

Quer a versão técnica — como os SSGs diferem dos frameworks client-side e dos meta-frameworks, uma comparação lado a lado dos seis e uma análise detalhada da armadilha de atualização do build? Acesse a aba Avançado.

TL;DR — Um SSG pré-renderiza cada rota como HTML estático durante o build, então o conteúdo já existe na resposta antes da primeira solicitação do rastreador — sem Web Rendering Service, sem fila de renderização e sem atraso da “Wave 2”. Essa é a maior vantagem de indexabilidade que você pode oferecer a um site. SSGs diferem de frameworks CSR (que montam a página no navegador) e de meta-frameworks (que podem fazer SSR a cada solicitação). Os seis deste cluster — Hugo, Jekyll, Eleventy, Hexo, Gatsby e Astro — entregam HTML estático; eles variam em linguagem, carga de JS e ferramentas integradas de sitemap e imagens. O verdadeiro modo de falha não é a renderização, mas a atualização do build: um site estático só está tão atualizado quanto seu último build, portanto, uma alteração de conteúdo que não acione um novo build serve silenciosamente HTML desatualizado aos mecanismos de busca. Uso Astro neste site exatamente por esse conjunto de concessões.

O que “estático” realmente significa

Um gerador de sites estáticos passa seu conteúdo e seus templates por uma etapa de build e gera uma pasta com HTML, CSS e ativos prontos. A parte crucial para o SEO é quando o HTML é produzido: durante o build, uma vez, para todos — não a cada solicitação nem no navegador. A orientação do Google sobre JavaScript descreve rastreamento, renderização e indexação como etapas distintas de processamento. Um SSG remove a renderização client-side do caminho crítico do conteúdo gerado porque o HTML já está completo. Evidência desta afirmação Google processes JavaScript through crawling, rendering, and indexing, while pre-rendered HTML is present before client execution. Escopo: Google Search JavaScript processing; indexing is not guaranteed. Confiança: alta · Verificado: 2026-07-14 Google: JavaScript SEO basics

É por isso que sites estáticos são a arquitetura mais segura possível para conseguir indexação. O conteúdo está no primeiro byte da resposta. Não há diferença de paridade entre o HTML bruto e o renderizado, nem dependência do sucesso do renderizador, nem peculiaridades do Chrome sem estado que precisem ser contornadas no projeto.

SSG vs. renderização client-side vs. meta-frameworks

Três arquiteturas, três momentos diferentes em que o HTML passa a existir:

• Geração de site estático (SSG). O HTML é criado uma vez, durante o build, antes de qualquer solicitação. É servido como arquivos simples (muitas vezes por uma CDN). O conteúdo está no HTML bruto. É o caso de Hugo, Jekyll, Eleventy e Hexo — além de Gatsby e Astro em seu modo estático padrão.
• Renderização client-side (CSR). O servidor envia uma estrutura mínima; o JavaScript monta a página no navegador durante a solicitação/execução. O conteúdo depende do sucesso da renderização. É o caso de uma SPA em React ou Vue com CSR padrão — a configuração mais arriscada para SEO (consulte SEO para JavaScript).
• Meta-frameworks (SSR/híbrido). Frameworks como Next.js, Nuxt e SvelteKit podem renderizar HTML a cada solicitação no servidor (SSR), pré-renderizar algumas rotas (SSG) ou combinar os dois. O conteúdo está no HTML, mas é produzido no momento da solicitação, o que acrescenta custo de servidor e latência que não existem com um SSG puro.

A distinção fica menos nítida nas bordas — Gatsby e Astro às vezes são chamados de meta-frameworks porque são baseados em componentes e podem fazer mais do que gerar arquivos simples. Mas, no modo mais comum, são geradores estáticos, e é assim que você deve tratá-los para SEO. O modelo mental que importa: quanto antes o HTML existir, menos coisas poderão dar errado antes que um rastreador o veja. SSG é a opção mais antecipada.

Comparação entre os seis geradores

Todos os seis produzem HTML estático indexável. Veja como eles diferem nos aspectos que realmente afetam uma decisão de SEO:

Alguns pontos dessa tabela merecem destaque:

• A carga de JS é o diferencial relacionado ao SEO. Hugo, Jekyll, Eleventy e Hexo praticamente não enviam JavaScript, a menos que você o adicione. O Gatsby reidrata um bundle completo do React no cliente — continua indexável (o HTML é estático), mas tem um custo de Core Web Vitals que os outros não têm. O Astro fica no meio-termo com a arquitetura de ilhas: HTML estático por padrão e JavaScript somente para os componentes interativos específicos (“ilhas”) que precisam dele.
• A velocidade do build escala de maneiras diferentes. Hugo (Go) é famoso pela rapidez e lida tranquilamente com dezenas de milhares de páginas. Os geradores baseados em Node ficam mais lentos em grande escala, e os tempos de build do Gatsby historicamente são sua maior fonte de reclamações.
• Sitemaps e otimização de imagens estão praticamente resolvidos em todos — mas Hugo e Astro oferecem mais recursos prontos, enquanto Jekyll, Eleventy e Hexo dependem de plugins (bem mantidos).
• A cadência de lançamentos do Gatsby diminuiu de forma perceptível. O projeto não está arquivado e ainda lança correções, mas, em julho de 2026, seu repositório no GitHub mostrava apenas alguns commits nos 90 dias anteriores e uma versão secundária desde fevereiro. Vale ponderar isso frente a uma opção desenvolvida mais ativamente se você estiver escolhendo um gerador hoje, além do custo de hidratação/CWV mencionado acima.

Por que criei este site com Astro

Criei este site — e o patrickstox.com — com Astro, e o raciocínio vem diretamente desta página. Eu queria escrever em Markdown/MDX com componentes de verdade, mas não queria pagar o custo do JavaScript em todas as páginas só para tê-los. O padrão do Astro é não enviar JS client-side: as páginas que você está lendo são entregues como HTML estático, e o único JavaScript carregado é o necessário para os poucos elementos interativos (como as abas de lentes e o quiz). Isso me dá a indexabilidade de um SSG clássico e bons Core Web Vitals, sem abrir mão de uma experiência de autoria baseada em componentes. Se eu precisasse de builds extremamente rápidos para um conjunto enorme de conteúdo sem nenhuma interatividade, Hugo seria a escolha óbvia; para uma camada de dados em React, Gatsby. Para este caso — um site com muito conteúdo e alguns detalhes interativos — Astro é a concessão certa.

O único problema real: atualização do build

Tudo o que foi dito acima é vantagem. Agora vem o porém que surpreende muita gente.

Um site estático só está tão atualizado quanto seu último build. O HTML é um retrato congelado durante o build. Alterar um preço, corrigir um fato, publicar um post ou atualizar uma tag de título — nada disso chega aos mecanismos de busca até que você gere e implante novamente. Não há um servidor ativo montando a página a partir de um banco de dados a cada solicitação, então nada aplica sua alteração automaticamente. Evidência desta afirmação Static build output remains a snapshot until the project is rebuilt and redeployed. Escopo: Astro static build workflow as a representative example. Confiança: alta · Verificado: 2026-07-14 Astro: Build and deploy

Na prática, isso significa:

• Edições de conteúdo precisam acionar um build. Se você trabalha em um CMS headless ou no Git, configure um webhook para que a publicação inicie uma implantação. Um processo de build apenas manual é como preços desatualizados e erros 404s “fantasmas” entram no índice.
• Dados que mudam com frequência são complicados. Estoque, preços, contagens em tempo real — se algo muda mais rápido do que seus builds, a cópia estática fica para trás. É aí que builds incrementais, builds agendados ou uma abordagem híbrida (um meta-framework com SSR/ISR para as rotas voláteis) mostram seu valor.
• Páginas sensíveis ao tempo precisam de uma cadência. Se as “ofertas de hoje” são incorporadas durante o build, o build precisa ser executado pelo menos diariamente, ou a página fica incorreta.

Nada disso impede o uso — é uma disciplina. O mesmo motivo pelo qual SSGs são ótimos para SEO (HTML definido antecipadamente) é o motivo pelo qual você precisa deliberadamente redefini-lo quando o conteúdo muda.

Próximo passo: o cluster de geradores de sites estáticos

Este hub é o mapa. Cada gerador abaixo tem sua própria análise detalhada — linguagem, carga de JS, ferramentas de sitemap/imagens, peculiaridades de SEO específicas do framework e como manter os builds atualizados:

• SEO para Hugo — baseado em Go, sem JS e com builds extremamente rápidos; o sitemap gerado automaticamente, o processamento de imagens integrado e o gerenciamento de conjuntos enormes de conteúdo.
• SEO para Jekyll — o SSG original e o padrão do GitHub Pages; jekyll-seo-tag, jekyll-sitemap e a limitação de plugins no GitHub Pages.
• SEO para Eleventy (11ty) — baseado em JavaScript, com saída sem JS; geração de sitemaps a partir de templates e eleventy-img para imagens responsivas.
• SEO para Hexo — o gerador de blogs em Node; plugins de sitemap/feed, JS do tema e higiene de permalink/canonical.
• SEO para Gatsby — geração estática baseada em React; a concessão entre hidratação e CWV, gatsby-plugin-image, gatsby-plugin-sitemap e obtenção de dados durante o build.
• SEO para Astro — sem JS por padrão, arquitetura de ilhas, @astrojs/sitemap, astro:assets, View Transitions e comportamento de fallback de Server Islands.

Todos os tópicos acima estão agrupados neste hub e também aparecem na barra lateral.

Para ver o contexto mais amplo — como o Google renderiza JavaScript, os modos de falha de paridade e interação e qual modo de renderização escolher quando você realmente precisa de JS —, consulte o hub principal SEO para JavaScript.

Resumo por IA

Uma versão condensada da seção Avançado:

• Um SSG pré-renderiza todas as páginas como HTML estático durante o build — o conteúdo existe na resposta antes da primeira solicitação do rastreador. Sem Web Rendering Service, sem fila de renderização e sem atraso da “Wave 2”. É a arquitetura mais segura para indexabilidade.
• Três arquiteturas conforme quando o HTML existe: SSG (durante o build, mais segura), CSR (no navegador durante a execução, mais arriscada) e meta-frameworks/SSR (a cada solicitação no servidor, com o conteúdo presente, mas com latência/custo).
• Todos os seis geradores entregam HTML estático indexável. Eles diferem em linguagem, carga de JS e ferramentas integradas de sitemap/imagens:
  • Hugo (Go) — sem JS, builds mais rápidos, sitemap e processamento de imagens integrados.
  • Jekyll (Ruby) — sem JS, padrão do GitHub Pages, baseado em plugins.
  • Eleventy (Node) — sem JS, flexível, baseado em plugins.
  • Hexo (Node) — sem JS por padrão, voltado a blogs, baseado em plugins.
  • Gatsby (React) — hidrata um bundle do React (custo de CWV), tem ferramentas robustas de imagens, mas sua cadência de lançamentos diminuiu muito até meados de 2026.
  • Astro (qualquer framework) — sem JS por padrão graças às ilhas, sitemap oficial e astro:assets.
• A carga de JS é o diferencial relacionado ao SEO — Gatsby carrega um bundle do React; as ilhas do Astro enviam JS somente onde necessário; os demais não enviam JS por padrão.
• Patrick criou este site (e o patrickstox.com) com Astro — componentes sem o custo do JS: HTML estático e bons Core Web Vitals.
• O único problema real é a atualização do build: um site estático só está tão atualizado quanto seu último build. Conecte edições de conteúdo a um webhook de rebuild; use builds incrementais/agendados ou uma rota híbrida com SSR/ISR para dados que mudam rapidamente.

Documentação oficial

Documentação de fontes primárias — dos mecanismos de busca e de cada gerador.

Mecanismos de busca — renderização e HTML estático

• Entenda os princípios básicos de SEO para JavaScript — as fases rastrear → renderizar → indexar que um build estático permite pular para o conteúdo.
• Guia detalhado sobre como a Pesquisa Google funciona — onde a renderização se encaixa e por que o HTML pré-renderizado apresenta o menor risco.

Os geradores

• Documentação do Hugo — além da documentação do template de sitemap e do processamento de imagens.
• Documentação do Jekyll — além de jekyll-seo-tag e jekyll-sitemap.
• Documentação do Eleventy (11ty) — e eleventy-img.
• Documentação do Hexo — e o plugin hexo-generator-sitemap.
• Documentação do Gatsby — além de gatsby-plugin-image e gatsby-plugin-sitemap.
• Documentação do Astro — além de @astrojs/sitemap e astro:assets/imagens.

Citações das fontes

Declarações públicas do Google e das próprias equipes dos geradores, além de uma observação de um texto meu.

Google — a renderização é uma etapa separada

• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” Tradução: “Durante o rastreamento, o Google renderiza a página e executa todo JavaScript que encontra usando uma versão recente do Chrome.” — a etapa que um SSG remove do caminho crítico ao entregar HTML pronto. Ir para a citação
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” Tradução: “A renderização é importante porque os sites muitas vezes dependem de JavaScript para inserir conteúdo na página e, sem a renderização, o Google talvez não veja esse conteúdo.” — ou seja, se o conteúdo já estiver no HTML estático, a renderização não poderá prejudicar sua visibilidade. Ir para a citação

Astro — estático por padrão

• “By default, Astro pages, routes, and API endpoints will be pre-rendered at build time as static pages. However, you can choose to render some or all of your routes on demand by a server when a route is requested.” Tradução: “Por padrão, páginas, rotas e endpoints de API do Astro são pré-renderizados durante o build como páginas estáticas. No entanto, você pode optar por renderizar algumas ou todas as rotas sob demanda por um servidor quando uma rota for solicitada.” Ir para a citação

Hugo — velocidade

• O Hugo se apresenta como “the world’s fastest framework for building websites” Tradução: “o framework mais rápido do mundo para criar sites” — a vantagem de velocidade de build que importa em grande escala de conteúdo. Fonte

Patrick Stox (meu próprio trabalho — SEO para JavaScript: um guia definitivo)

• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” Tradução: “Qualquer configuração de SSR, renderização estática e pré-renderização funcionará bem para os mecanismos de busca.” — a geração estática está no extremo de menor risco desse espectro.

Checklist de SEO para sites estáticos

Uma verificação rápida para confirmar que sua configuração de SSG favorece a busca — e continua atualizada:

• O conteúdo importante está presente em Exibir código-fonte (HTML bruto), não apenas depois que o JS é executado — esse é o objetivo central de um SSG.
• Um sitemap XML é gerado a cada build e enviado ao Google Search Console e ao Bing Webmaster Tools.
• Cada página tem <title> e meta description exclusivos, definidos durante o build (pelo sistema de templates do gerador ou por um plugin/integração de SEO).
• As tags canonical estão configuradas e apontam para as URLs finais ativas (não para localhost ou um domínio de preview).
• As imagens são otimizadas durante o build (tamanhos responsivos, formatos modernos) — use as ferramentas integradas do gerador ou um plugin de imagens.
• O JavaScript client-side (bundle do React do Gatsby, ilhas do Astro, JS do tema) não está ocultando conteúdo principal atrás de uma interação.
• Os ativos de JS/CSS não estão bloqueados no robots.txt.
• Edições de conteúdo acionam um novo build e uma nova implantação — um webhook do CMS/Git dispara a implantação automaticamente.
• Páginas sensíveis ao tempo ou que mudam com frequência têm uma cadência de builds agendados (ou são servidas por SSR/ISR, em vez de estaticamente).
• URLs antigas de um build anterior não permanecem como arquivos estáticos órfãos — limpe o diretório de saída/trate as remoções para que páginas excluídas retornem 404 ou 410.
• O build implantado corresponde ao conteúdo mais recente (faça uma verificação pontual em uma página alterada recentemente em produção, não apenas localmente).

Geradores de sites estáticos — referência rápida

Resumo dos seis

Quando o HTML existe (e por que isso importa)

Fatos rápidos

• SSG = nenhum Web Rendering Service no caminho crítico → nenhum atraso da “Wave 2” para o conteúdo.
• Gatsby hidrata um bundle do React (custo de CWV); Astro envia JS somente para ilhas; Hugo/Jekyll/Eleventy/Hexo não enviam JS por padrão.
• A cadência de lançamentos do Gatsby diminuiu até meados de 2026 — confira a atividade no GitHub antes de apostar um novo build nele.
• Hugo (Go) é o campeão de velocidade em grande escala.
• A única armadilha: atualização do build — um site estático mostra seu último build. Conecte um webhook de rebuild às edições de conteúdo.
• Dados que mudam rapidamente (preços, estoque) → builds incrementais/agendados ou SSR/ISR híbrido.

Qual caminho de renderização é adequado?

O framework build → implantação → verificação

• Build: enumere as rotas pretendidas e gere HTML completo, metadados, canonicals e dados estruturados.
• Implantação: publique o novo artefato de forma atômica para manter HTML, ativos, sitemaps e redirecionamentos sincronizados.
• Verificação: compare o HTML de origem e a resposta em produção com a versão do conteúdo que acionou o build.

O HTML estático elimina a dependência de renderização; ele não resolve builds desatualizados, rotas ausentes, hooks de implantação quebrados nem metadados client-side que nunca chegam ao HTML de origem.

Verifique se o conteúdo principal existe no HTML de origem

curl -sS https://example.com/page/ | grep -F 'Expected visible heading'

Para uma lista de URLs, faça a CI falhar quando uma rota de produção estiver ausente ou não tiver um título:

while IFS= read -r url; do html=$(curl -fsSL "$url") || { echo "FETCH FAIL $url"; continue; }; printf '%s' "$html" | grep -qi '<title>[^<]' || echo "TITLE FAIL $url"; done < urls.txt

Execute isto no Console do DevTools para comparar o título, a canonical e o cabeçalho de uma página renderizada:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, h1: document.querySelector('h1')?.textContent.trim()});

Ferramentas para saída estática

• Verificador de HTML bruto vs. renderizado mostra se o conteúdo importante e os sinais do head já estão presentes no HTML inicial.
• Verificador de status HTTP verifica em lote rotas geradas, redirecionamentos e páginas ausentes.
• Verificador de cabeçalhos HTTP inspeciona cabeçalhos de cache e implantação em redirecionamentos.
• O log de build e o manifesto de implantação de um framework são a fonte da verdade sobre quais rotas foram geradas com sucesso.

Comprove que a implantação estática funciona

Teste do HTML de origem

Teste a executar: busque URLs representativas de produção com curl ou o Render Gap. Resultado esperado: o conteúdo principal, o título, a canonical e os links aparecem no HTML bruto. Interpretação da falha: a rota é renderizada no cliente ou o build omitiu dados. Janela de monitoramento: imediatamente após a implantação. Gatilho de rollback: templates importantes entregam HTML de origem vazio ou incompleto.

Teste de atualização da publicação

Teste a executar: publique uma alteração controlada de conteúdo e compare o timestamp do CMS, o log de build, o artefato de implantação e o HTML ao vivo. Resultado esperado: a alteração aciona um build bem-sucedido e chega à produção. Interpretação da falha: o webhook, o build, o cache ou a cadeia de implantação está desatualizado. Janela de monitoramento: o SLA normal de publicação. Gatilho de rollback: a produção mistura HTML antigo com metadados ou ativos novos.

Teste de integridade das rotas

Teste a executar: compare as URLs canonical pretendidas com as rotas geradas/implantadas e verifique os status em lote. Resultado esperado: todas as rotas pretendidas retornam o status planejado. Interpretação da falha: a descoberta de caminhos dinâmicos ou a configuração do build deixou rotas de fora. Janela de monitoramento: todo build. Gatilho de rollback: páginas canonical passam a retornar 404s ou redirecionam inesperadamente.

Teste seus conhecimentos: geradores de sites estáticos

Cinco perguntas rápidas sobre por que os geradores de sites estáticos simplificam o SEO — e o único ponto que ainda pode causar problemas. Escolha uma resposta para cada pergunta e depois confira.

Recursos que valem seu tempo

Meus textos relacionados

• SEO para JavaScript: um guia definitivo — renderização, paridade do DOM e por que a saída estática/pré-renderizada está no extremo de menor risco do espectro.
• Guia de SEO técnico para iniciantes — onde a arquitetura de renderização se encaixa no quadro geral.

Minhas palestras

• Como a busca funciona (SlideShare) — minha explicação sobre rastreamento, renderização, indexação e ranking. (Aplica-se meu aviso habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” Tradução: “Este é o meu entendimento dos sistemas… não será 100% completo nem preciso.”)

De outras fontes do setor

• web.dev — Renderização na Web — a explicação canônica da equipe do Chrome sobre SSG vs. SSR vs. CSR e as concessões entre eles.
• Google Search Central — princípios básicos de SEO para JavaScript — as fases rastrear → renderizar → indexar que um build estático permite pular para o conteúdo.
• Jamstack — o movimento arquitetural (marcação pré-renderizada servida por uma CDN) do qual os geradores de sites estáticos são o motor, com um diretório de geradores.
• Astro — Por que Astro? — a formulação mais clara do modelo “HTML estático, nenhum JS por padrão, ilhas para interatividade”.
• Hugo — o gerador baseado em Go criado em torno da velocidade de build em grande escala de conteúdo.
• Smashing Magazine — cobertura sobre geradores de sites estáticos — artigos de profissionais sobre como escolher e usar SSGs.

Registro de alterações