Renderização dinâmica: o que ela resolve em um site JavaScript (e o que não resolve)
Por Toy Wen Da, Cofundador · Atualizado em · 7 min de leitura
Traduzido do original em inglês. Ler em inglês
Renderização dinâmica significa que o seu servidor verifica se quem acessa é um navegador ou um bot de busca e, em seguida, envia aos bots uma versão estática em HTML da página, já pré-renderizada, enquanto as pessoas recebem a experiência completa em JavaScript. Ela resolve os casos em que o Googlebot não consegue ler conteúdo que só aparece depois que os scripts são executados, mas não resolve todos os problemas de indexação.
Antes de mexer em qualquer código do servidor, confira o que o Googlebot vê na página em questão. O Googlebot Simulator gratuito busca uma URL do mesmo jeito que o rastreador do Google e mostra o HTML renderizado. Assim, em um minuto você descobre se o conteúdo em JavaScript está faltando no que o bot recebe.
Como funciona
Detectando o visitante
Seu servidor, ou uma camada de CDN na frente dele, inspeciona o cabeçalho User-Agent de cada requisição. Quando o cabeçalho corresponde a um rastreador conhecido, como o Googlebot ou o Bingbot, ou, cada vez mais, um rastreador de IA, a requisição segue um caminho diferente do de uma requisição enviada por um navegador comum.
Entregando duas versões da mesma página
Os visitantes humanos continuam recebendo o seu app em React, Vue ou Angular, com toda a interatividade. Os bots recebem um instantâneo em HTML pré-renderizado, gerado por uma ferramenta de navegador headless como Puppeteer ou Rendertron, ou por um serviço de terceiros como o Prerender.io. Como o instantâneo é estático, nenhum script precisa ser executado para o conteúdo ficar visível.
Por que os sites precisam disso
O Googlebot consegue executar JavaScript, mas a renderização consome muitos recursos e acontece com atraso. Por isso, as páginas muitas vezes são rastreadas uma vez e renderizadas de novo só depois, o que pode travar a indexação. A maioria dos mecanismos de resposta com IA nem executa JavaScript, então uma página que depende de renderização no lado do cliente pode ficar invisível para eles desde o início. Uma página que nunca é indexada não ganha visibilidade nem taxa de cliques (CTR), muito menos uma boa.
Corrigindo dentro do seu próprio site, passo a passo
- Confirme que existe mesmo uma diferença: busque a página como um bot e compare com o que um navegador normal carrega. Se o conteúdo for o mesmo, você não precisa de nada disso.
- Decida se o problema afeta um template, uma seção do site ou tudo, já que esse alcance determina quanto trabalho de infraestrutura você vai assumir.
- Adicione a detecção de user agent na camada do servidor ou da CDN, por exemplo com um Cloudflare Worker ou uma regra do Nginx, que compare as requisições recebidas com uma lista de bots mantida atualizada.
- Direcione o tráfego dos bots para um serviço de pré-renderização que gere o HTML estático de cada URL e o armazene em cache, para que você não precise renderizar de novo a cada visita de bot.
- Mantenha o conteúdo equivalente: a versão pré-renderizada precisa corresponder ao que uma pessoa acaba vendo, com o mesmo texto, os mesmos links e os mesmos dados estruturados.
- Teste de novo depois do lançamento e também depois de qualquer deploy do front-end, porque uma mudança na interface pode quebrar silenciosamente o que o serviço de pré-renderização captura.
- Monitore a configuração continuamente. Se o serviço de renderização cair, os bots podem passar a receber páginas em branco ou erros, o que pode levar à desindexação rapidamente.
Quando as suas próprias ferramentas bastam e quando não bastam
Verificar uma única página é um trabalho diferente de corrigir a renderização de um site inteiro.
| Situação | O que você está verificando | Ferramenta certa | A opção gratuita basta? |
|---|---|---|---|
| Uma URL parece normal para você, mas não aparece no índice do Google | O que o Googlebot vê nessa página | Googlebot Simulator | Sim, confirma ou descarta uma falha de renderização em minutos |
| Site inteiro construído em React/Vue/Angular, sem renderização no servidor | Rastreabilidade em todo o site | Um rastreamento técnico completo e uma auditoria de renderização | Não, isso é uma mudança de infraestrutura, e não uma verificação de uma página |
| O layout mobile de uma página parece estranho, junto com o problema de indexação | Renderização mobile, viewport, usabilidade | Teste de compatibilidade com dispositivos móveis gratuito | Sim, para diagnosticar a parte específica do mobile |
| As páginas estavam indexadas normalmente e saíram do índice depois de um redesign | Regressão recorrente, e não um caso isolado | Monitoramento contínuo e revisão da configuração de pré-renderização | Não, uma única verificação não pega um problema que volta a cada deploy |
Uma verificação pontual em uma única URL é exatamente para isso que as ferramentas gratuitas existem, enquanto um padrão recorrente, que atinge o site todo, aponta para uma correção de infraestrutura, geralmente envolvendo um desenvolvedor e um serviço de pré-renderização.
Comparando com as alternativas
| Abordagem | Como funciona | Melhor indicação | Carga de manutenção |
|---|---|---|---|
| Renderização dinâmica | Entrega HTML estático aos bots e o app em JS às pessoas | Sites com muito JS, com problemas de orçamento de rastreamento ou de visibilidade em IA, que ainda não podem fazer uma reescrita completa | Alta, é preciso manter um pipeline de renderização separado |
| Renderização no servidor (Server-Side Rendering, SSR) | O servidor renderiza o HTML a cada requisição, para todo mundo | Projetos novos ou sites com recursos para reconstruir o front-end | Moderada, um único caminho de renderização para todos os visitantes |
| Geração de site estático (Static Site Generation, SSG) | O HTML é construído com antecedência, na hora do deploy | Conteúdo que não muda a cada requisição, como blogs ou páginas de marketing | Baixa, basta reconstruir quando o conteúdo mudar |
| Renderização no lado do cliente (sem correção) | O navegador monta a página a partir do JavaScript, e os bots recebem o mesmo | Ferramentas internas, e não páginas públicas voltadas à busca | Pouco esforço, alto risco para a busca |
A orientação do próprio Google trata a técnica como um paliativo, e não como o ponto aonde você quer chegar. SSR ou SSG são correções mais duradouras assim que você puder arcar com a reconstrução.
Isso é considerado cloaking?
Não, desde que você faça isso de boa-fé. A documentação do Google Search Central afirma que o Googlebot, em geral, não trata isso como cloaking, desde que o conteúdo renderizado entregue aos bots seja equivalente ao que os visitantes humanos acabam vendo. A violação não está em existirem duas versões, mas em mostrar aos bots e às pessoas conteúdos realmente diferentes, como uma página recheada de palavras-chave sobre tênis de corrida para os rastreadores, enquanto os visitantes veem uma página sobre algo totalmente diferente. Mantenha a mesma substância nas duas versões e você estará do lado certo da regra.
Erros comuns
- Tratar a técnica como permanente, quando ela apenas disfarça um problema de rastreabilidade e não elimina a necessidade de, no futuro, ter uma arquitetura mais fácil de rastrear.
- Deixar o serviço de pré-renderização ficar desatualizado, de modo que os bots vejam uma versão antiga ou quebrada da página sempre que ele não captar uma mudança no front-end.
- Confiar em uma lista de bots com lacunas, já que a detecção por user agent só funciona para os bots que você listou, e um novo rastreador de IA que as suas regras não reconhecem recebe a versão JavaScript bruta, que provavelmente não consegue ler.
- Deixar de testar de novo depois dos deploys, embora um lançamento de front-end que ninguém conferiu na versão voltada aos bots seja o motivo mais comum para uma configuração como essa quebrar sem alarde.
- Aplicar a técnica em um site que não precisa dela, porque sites pequenos e majoritariamente estáticos raramente têm um problema de renderização que justifique tanta infraestrutura.
Perguntas frequentes
A renderização dinâmica prejudica o meu ranqueamento?
Não por si só. O risco está em uma versão mal configurada, que entrega páginas desatualizadas ou erros e se afasta do que os visitantes humanos veem.
Renderização dinâmica é o mesmo que cloaking?
Não. Cloaking é entregar a bots e a pessoas conteúdos substancialmente diferentes, enquanto essa técnica entrega o mesmo conteúdo em outro formato, algo que os mecanismos de busca permitem de forma explícita.
Como sei se o meu site precisa mesmo de renderização dinâmica?
Busque uma página como o Googlebot e compare com a versão do navegador. Se o conteúdo principal e os links não aparecem na visão do bot, esse é o seu sinal.
Qual é a alternativa de longo prazo à renderização dinâmica?
Renderização no servidor ou geração de site estático, que entregam o mesmo HTML renderizado para todo mundo, em vez de manter dois caminhos separados.
Sites de pequenas empresas podem ignorar a renderização dinâmica por completo?
Em geral, sim. Ela importa principalmente para sites grandes, com muito JavaScript, mudanças frequentes de conteúdo ou restrições de orçamento de rastreamento, e não para um site pequeno típico, construído com templates de página padrão.
Verifique a sua página antes de construir qualquer coisa
Não comece a montar um pipeline de pré-renderização por palpite. Busque a página em questão, veja o que o Googlebot recebe e só invista na infraestrutura se houver uma diferença real entre o que bots e pessoas veem. Se quiser uma segunda opinião sobre o que está travando a sua indexação, fale com a equipe e peça um relatório de SEO de exemplo.
Fontes
Sobre o autor
O SearchBlueprint pesquisou, escreveu e avaliou este artigo com o mesmo pipeline de conteúdo que nossos clientes usam nos próprios sites. A nota que aparece na assinatura é a que nosso mecanismo de conteúdo deu a esta página antes de ela ser publicada. Nada aqui passa por revisão manual, e esse é justamente o ponto: é o resultado do produto, publicado onde qualquer pessoa pode conferir.