JavaScript SEO: SSR, CSR e o que o Googlebot realmente renderiza

O que é JavaScript SEO?

É a parte do SEO técnico que garante que páginas construídas ou alteradas com JavaScript sejam rastreadas, renderizadas e indexadas corretamente. Em sites com React, Vue, Angular ou qualquer framework moderno, o conteúdo que o usuário vê pode não existir no HTML que o servidor entrega. E o que não existe para o robô não ranqueia nem é citado.

O problema não é o JavaScript em si. É a pergunta: o conteúdo importante depende de JavaScript para aparecer? Se a resposta é sim, cada robô que não executa JavaScript, ou que executa com atraso, vê uma versão incompleta do site.

Esse é o tema que eu ensino no curso de JavaScript SEO e HTML Semântico da EducaSEO. O princípio que atravessa todo o curso é simples: conferir a página no código-fonte, onde o robô começa, e não só no DevTools, onde tudo já foi montado pelo JavaScript.

Como o Googlebot processa uma página em JavaScript?

Em três fases: rastreamento, renderização e indexação. A renderização é a fase que o JavaScript acrescenta, e é onde as coisas dão errado.

1. Rastreamento: o Googlebot baixa o HTML da URL e confere o robots.txt. Os links <a href> encontrados nesse HTML entram na fila de rastreamento.
2. Renderização: páginas com status 200 entram em uma fila de renderização. Quando há recursos, o Web Rendering Service executa o JavaScript em um Chromium atualizado e gera o HTML final. Segundo o Google, a página pode ficar na fila por alguns segundos ou mais.
3. Indexação: o Google usa o HTML renderizado para indexar o conteúdo e descobrir novos links.

Qual a diferença entre CSR, SSR e SSG?

A diferença é onde o HTML é montado: no navegador (CSR), no servidor a cada visita (SSR) ou no build, antes de qualquer visita (SSG). Para SEO, o que importa é se o conteúdo chega pronto no HTML.

Em todas as estratégias com HTML completo, o JavaScript ainda roda no navegador para deixar a página interativa. Esse processo se chama hidratação: o framework "assume" o HTML que já chegou pronto, em vez de montar tudo do zero.

Este blog é um exemplo de SSG: cada post é gerado como HTML completo no build, com o texto, os links, as meta tags e os dados estruturados, e o React hidrata a página no navegador para o sumário, o compartilhamento e as animações.

Por que os robôs de IA mudaram a conta?

Porque os principais robôs de IA não executam JavaScript: para eles, um site em CSR é uma página vazia. Uma análise da Vercel com a MERJ, sobre o tráfego de robôs na rede da Vercel, mostrou que os robôs da OpenAI, o ClaudeBot da Anthropic e o PerplexityBot baixam arquivos JavaScript, mas não os executam.

Antes, dava para argumentar que "o Google renderiza, então tudo bem". Com a busca nas IAs, essa conta não fecha: um site que depende de JavaScript para mostrar o conteúdo fica fora das respostas do ChatGPT, do Claude e do Perplexity. Isso pesa diretamente no GEO, porque a IA só cita o que consegue ler. E, antes mesmo da renderização, o robô precisa passar pelo CDN, como mostra o post sobre o Cloudflare e os robôs de IA.

Quais erros de JavaScript mais prejudicam o SEO?

Links que não são links, conteúdo que só aparece após interação, meta tags só no JavaScript e páginas de erro com status 200. A maioria vem de decisões de desenvolvimento que funcionam para o usuário e falham para o robô.

O caso das animações que escondem conteúdo

Um erro menos óbvio aconteceu neste próprio site. Os blocos abaixo da dobra tinham uma animação de entrada: começavam invisíveis (opacity: 0) e apareciam conforme a pessoa rolava. Na captura de tela do teste de URL do Search Console, o resumo do post, o bloco do autor e os relacionados apareciam vazios, e na home os contadores saíam zerados.

O motivo: o renderizador do Google não rola a página como uma pessoa e não espera as transições terminarem. O texto estava no HTML, mas aparecia como oculto na renderização. A correção foi desligar essas animações para os robôs que renderizam (Googlebot, ferramenta de teste do Search Console, Bing e Lighthouse), entregando a eles a página exatamente como o HTML. O conteúdo é o mesmo para todos, só sem a animação.

Como testar se o Google está vendo o conteúdo?

Compare o HTML de origem com o HTML renderizado e confira a captura de tela no Search Console. Cinco testes cobrem quase todos os casos:

1. Código-fonte (Ctrl+U): o texto principal, os links e as meta tags estão no HTML que o servidor entrega? Se não, eles dependem de JavaScript.
2. Teste do URL ativo no Search Console: na Inspeção de URL, veja o HTML renderizado, a captura de tela e, em "Mais informações", os recursos que não carregaram e os erros de JavaScript.
3. Navegador com JavaScript desativado: desative o JavaScript no DevTools e recarregue. O que sumir é o que os robôs de IA não veem.
4. Teste de pesquisa aprimorada: confere se os dados estruturados gerados por JavaScript aparecem para o Google.
5. Rastreador com e sem renderização: ferramentas como o Screaming Frog rastreiam o site nos dois modos. A diferença de conteúdo e de links entre eles mostra o que depende de JavaScript.

Um teste rápido no terminal mostra o que um robô sem JavaScript recebe:

curl -s https://seusite.com.br/produto | grep -c "Nome do produto"

Se o resultado for 0, o nome do produto não está no HTML de origem.

Qual estratégia escolher?

SSG para conteúdo, SSR para páginas que mudam a cada visita e CSR só para áreas logadas ou ferramentas que não precisam ranquear. A maioria dos frameworks atuais permite misturar as estratégias por rota.

Para quem quer ir além da indexação, o próximo passo é deixar o site utilizável por agentes de IA, que é a proposta do WebMCP.

Quais erros evitar?