Como o Google renderiza uma página
Renderização é a etapa em que o Google roda um navegador para ver a página como um usuário veria, depois que o HTML, o CSS e o JavaScript terminam de carregar. Ela acontece entre o rastreamento e a indexação: o Googlebot busca o HTML, um navegador Chromium sem interface (headless) executa o código da página e o resultado, o HTML renderizado, é o que o Google indexa. Se o conteúdo só aparece depois que o JavaScript roda, é na renderização que ele se torna visível para a busca. Este artigo explica como esse processo funciona e o que pode fazê-lo falhar.
O que é renderização na Pesquisa Google
Renderização, no contexto da busca, é headless browsing: o Google controla um navegador por software para carregar a página e executar o JavaScript, de modo a indexar aquilo que o usuário veria depois do carregamento. O time de rendering do Google descreve o processo como rodar um navegador dentro da pipeline de indexação, e não como uma simples leitura do código-fonte.
O resultado dessa etapa é o DOM (Document Object Model), a árvore que representa a visão do navegador sobre a página em tempo de renderização. O DOM importa para SEO porque o Google indexa o conteúdo que está nele depois da renderização. Se um texto só existe após uma chamada de JavaScript, ele precisa entrar no DOM para ser indexado. Onde a página coloca esse trabalho, no servidor, no navegador ou no momento do build, muda a performance e a robustez, mas o foco aqui é o lado do Google. A taxonomia dessas estratégias está detalhada no guia Renderização na Web da web.dev.
Onde a renderização entra no processo de busca
A renderização é a segunda de três fases que o Google usa para processar páginas com JavaScript: rastreamento, renderização e indexação. Primeiro o Googlebot busca o HTML por uma requisição HTTP e confere o robots.txt; depois enfileira a página para renderização; por fim, usa o HTML renderizado para indexar e ainda extrai novos links para a fila de rastreamento.
Esse enfileiramento vale para toda página que responde com status HTTP 200, tenha ela JavaScript ou não. Páginas que respondem com status diferente de 200, como um 404, podem pular a renderização. A página pode aguardar segundos ou mais na fila até que os recursos do Google permitam renderizá-la, segundo a documentação oficial de SEO em JavaScript do Google. A etapa anterior, o rastreamento, está detalhada no artigo sobre como o Google rastreia seu site.
O Google renderiza todas as páginas?
O Google renderiza todas as páginas HTML que retornam status 200, não apenas as que dependem de JavaScript. Outros tipos de arquivo, como PDFs, ficam de fora desse processo.
Rodar um navegador para cada página é caro, e o custo exato é confidencial segundo o time de rendering, mas páginas que não dependem de JavaScript são baratas de renderizar, então o Google simplesmente renderiza todas. Na prática, isso desmonta a ideia da existência de um "rendering budget" que faria o Google escolher quais páginas processar. Não há uma cota de renderização por site, o que existe é uma fila, e o atraso, quando ocorre, é o tempo de espera nela, não uma seleção que deixa páginas de fora.
O Googlebot evergreen e o JavaScript moderno
Desde 2019, o Googlebot é evergreen: ele acompanha a versão estável do Chromium por integração contínua, então recursos novos de JavaScript passam a funcionar quase de graça. Antes disso, o Googlebot ficava preso a versões antigas do motor de renderização, e recursos do ES6 (de 2015) não eram suportados, o que obrigava desenvolvedores a evitar código moderno.
Na prática, o Google executa JavaScript bem, inclusive dados estruturados. Dá para gerar o JSON-LD por JavaScript e injetá-lo na página, que o Google lê no HTML renderizado. O mesmo vale para o <title>, a meta description e a tag rel="canonical", que podem ser definidos por JavaScript, embora o canonical seja mais seguro quando declarado direto no HTML. Ainda existem limites pontuais de compatibilidade de API, e a documentação recomenda exibição diferencial e polyfills quando um recurso do navegador não está disponível.
O maior risco é a fragilidade, não o JavaScript
O problema mais comum entre JavaScript e SEO não é o Google deixar de executar o código, e sim a fragilidade da página quando algo dá errado durante a renderização. Se uma chamada de API essencial falha, por exemplo retornando 429 (excesso de requisições) ou outro erro HTTP, e o conteúdo depende dela, o Google pode acabar indexando uma página vazia.
Quando um recurso crítico não carrega, o resultado varia: conteúdo parcial, página em branco, uma mensagem de erro ou até um redirecionamento para o google.com, conforme relatos do time de rendering. O Google não sabe como a página deveria ficar, então uma página que parece quebrada não é bem indexada. A recomendação é tratar erros com elegância e, sempre que possível, ter o conteúdo já no HTML. Renderização prévia ou no servidor continua indicada, porque deixa o site mais rápido e nem todos os robôs executam JavaScript. Muitos crawlers de IA não renderizam JavaScript, e o Googlebot é a exceção, não a regra. Também vale usar códigos HTTP significativos e evitar erros soft 404 em aplicações de página única.
O que faz a renderização falhar
Alguns problemas específicos impedem o Google de renderizar ou indexar a página como você espera. Os mais comuns envolvem robots.txt, noindex, roteamento por fragmento, dynamic rendering e cache.
robots.txt que bloqueia o conteúdo
Se a API ou o arquivo JavaScript que entrega o conteúdo está bloqueado para o Googlebot no robots.txt, a renderização não consegue buscar esse recurso e a página fica sem o conteúdo principal. A renderização usa o Googlebot para buscar recursos e respeita o robots.txt. Recursos secundários bloqueados são ignorados sem prejuízo, mas bloquear justamente o que entrega o texto quebra a página. É importante revisar o que o seu robots.txt permite antes de culpar o JavaScript.
noindex que interrompe a renderização
Quando o Google encontra uma tag noindex no HTML, ele pode pular a renderização e a execução do JavaScript. Por isso, tentar remover ou trocar o noindex por JavaScript costuma não funcionar, uma vez que o Google já decidiu não renderizar antes de rodar o código. Se a página precisa ser indexada, não coloque noindex no HTML original. Entenda o comportamento da tag meta robots antes de manipulá-la por script.
roteamento por fragmento em aplicações de página única
O Google só descobre links que são elementos <a> com atributo href. Em aplicações de página única, usar fragmentos de URL, como #/produtos, para carregar conteúdos diferentes esconde essas rotas do Googlebot, porque o fragmento não é resolvido de forma confiável. A recomendação oficial é usar a History API com URLs reais, para que cada visão do app tenha um endereço próprio e rastreável.
dynamic rendering, servir HTML diferente por user-agent
Servir um HTML para o Googlebot e outro para os usuários, técnica conhecida como dynamic rendering, hoje é desencorajado pelo Google. O código escrito só para o user-agent do Googlebot tende a ser esquecido e, com o tempo, passa a servir HTML quebrado ou desatualizado sem ninguém perceber. Trate como solução legada e prefira entregar o mesmo conteúdo para todos.
cache que serve JavaScript defasado
O serviço de renderização do Google, o WRS, armazena recursos em cache para economizar rede e pode ignorar seus cabeçalhos de cache, o que às vezes o leva a usar versões antigas de JavaScript ou CSS. A solução recomendada é o fingerprint no nome do arquivo, por exemplo main.2bb85551.js, que gera um nome novo a cada mudança de conteúdo e força o WRS a buscar a versão atual.
Como testar a renderização da sua página
A forma mais direta de verificar a renderização é a ferramenta de Inspeção de URL no Google Search Console: ela mostra o HTML renderizado, ou seja, o que o Google enxerga depois de executar o JavaScript. Se o conteúdo aparece ali, em geral o Googlebot consegue renderizar a página.
Olhe o HTML renderizado, não apenas o screenshot, e confira se o texto e os links importantes estão presentes. Comparar o HTML inicial, o que vem na resposta HTTP, com o HTML renderizado ajuda a identificar o que só existe depois do JavaScript. O Teste de Resultados Aprimorados serve como alternativa para checar se os dados estruturados aparecem após a renderização.
Perguntas frequentes sobre renderização
Renderização é o mesmo que indexação?
Não. Renderização é a etapa de executar o navegador para gerar o HTML final da página; indexação é a análise desse HTML e o armazenamento no índice do Google. São fases distintas do mesmo processo: rastrear, renderizar e indexar. Uma página pode ser renderizada e ainda assim não ser indexada, por exemplo se tiver noindex ou conteúdo considerado de baixo valor.
O Google renderiza JavaScript ou só lê o HTML?
O Google renderiza. O Googlebot executa JavaScript com uma versão estável do Chromium e usa o HTML renderizado, e não apenas o HTML inicial, para indexar a página. A condição é que o conteúdo termine no DOM depois que o script roda; o que não entra no DOM renderizado não é indexado.
Existe um limite de renderização por site?
Não há uma cota de renderização por site. O Google renderiza todas as páginas HTML que respondem com status 200, com ou sem JavaScript. O que existe é uma fila de renderização, e a página pode aguardar segundos ou mais até ser processada, mas não é descartada por uma suposta economia de renderização.
Por que minha página em JavaScript aparece em branco no teste de URL?
Em geral, porque um recurso essencial não carregou durante a renderização: uma API bloqueada no robots.txt, um erro HTTP como 429, ou uma dependência que falhou. Como o Google não sabe qual seria o conteúdo correto, ele indexa o que conseguiu montar. Verifique o HTML renderizado na Inspeção de URL e trate os erros de carregamento da página.
Dados estruturados em JavaScript funcionam para SEO?
Sim. Dá para gerar o JSON-LD por JavaScript e injetá-lo na página, e o Google o lê no HTML renderizado. A recomendação é testar a implementação para garantir que a marcação realmente aparece depois da renderização, já que ela depende do script rodar sem erros.
O Google segue redirecionamento feito por JavaScript?
Sim. Redirecionamentos por JavaScript são seguidos e funcionam como redirecionamentos comuns, com uma diferença: acontecem em tempo de renderização, não em tempo de rastreamento. Evite loops de redirecionamento, que também quebram quando feitos no servidor.
Próximos passos
A renderização decide se o conteúdo que depende de JavaScript chega ao índice do Google. Garanta que o conteúdo essencial esteja no HTML renderizado, trate erros de carregamento com elegância e não bloqueie no robots.txt os recursos que entregam esse conteúdo. O Google renderiza todas as páginas HTML e executa JavaScript moderno bem, o que mais falha é a fragilidade da página, não a falta de suporte.
O próximo passo é medir: teste suas páginas com a Inspeção de URL, compare o HTML inicial com o renderizado e confirme que o conteúdo importante sobrevive à renderização. Para uma checagem rápida de boas práticas on-page da sua página, use a ferramenta de SEO Check.