---
title: "JavaScript SEO: SSR, CSR e o que o Googlebot realmente renderiza"
url: "https://patrickperdigao.com.br/blog/javascript-seo"
description: Como o Google rastreia, renderiza e indexa sites em JavaScript, a diferença entre CSR, SSR e SSG, por que os robôs de IA não executam JS e como testar.
author: Patrick Perdigão
author_url: "https://patrickperdigao.com.br/"
published: 2026-10-19
updated: 2026-10-19
category: SEO Técnico
tags: JavaScript SEO, SSR, CSR, SSG, renderização, Googlebot, robôs de IA, SEO técnico
reading_time: 10 min
---

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

> Como o Google rastreia, renderiza e indexa sites em JavaScript, a diferença entre CSR, SSR e SSG, por que os robôs de IA não executam JS e como testar.

Por Patrick Perdigão · Publicado em 19 out 2026 · 10 min de leitura · Tema: [SEO Técnico](https://patrickperdigao.com.br/blog/tema/seo-tecnico.md)

## TL;DR

O Google processa páginas em JavaScript em três fases: rastreamento, renderização e indexação. Ele executa JavaScript com um Chromium atualizado, mas a renderização entra em uma fila e nem todo robô faz isso: os robôs de IA, como os da OpenAI, da Anthropic e da Perplexity, leem só o HTML. Por isso, o conteúdo importante, os links e as meta tags devem estar no HTML que o servidor entrega, com SSR ou SSG, e o JavaScript deve entrar para a interação.

1. CSR puro (o HTML chega vazio e o JavaScript monta a página) funciona no Google, mas deixa o site invisível para a maioria dos robôs de IA.
2. O Google só segue links que são elementos <a> com href; botões com onClick não são descobertos.
3. noindex no HTML original faz o Google pular a renderização: removê-lo depois com JavaScript pode não funcionar.

## 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](https://educaseo.com.br/hub/professores/patrick-perdigao/). 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.

| Fase | O que o Google usa | O que pode dar errado |
| --- | --- | --- |
| Rastreamento | HTML de origem | Links que não são `<a href>`, recursos bloqueados no `robots.txt` |
| Renderização | JavaScript executado no Chromium | Erros de JS, chamadas de API lentas, conteúdo que só aparece após interação |
| Indexação | HTML renderizado | `noindex` no HTML original, canonical divergente, soft 404 |

> [!WARNING] O noindex que o JavaScript não consegue tirar
> Quando o Google encontra `noindex` no HTML original, ele pode pular a renderização. Se o seu app começa com `noindex` e o remove via JavaScript depois de carregar, a página pode nunca ser indexada. Páginas que devem ser indexadas não podem ter `noindex` no HTML do servidor.

## 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.

| Estratégia | Como funciona | HTML de origem | Para SEO |
| --- | --- | --- | --- |
| CSR (client-side rendering) | O servidor manda um HTML vazio e o JS monta a página | Vazio ou quase | Arriscado: depende da renderização do Google e some para robôs de IA |
| SSR (server-side rendering) | O servidor monta o HTML a cada requisição | Completo | Seguro; exige servidor e cuidado com performance |
| SSG (static site generation) | O HTML de cada página é gerado no build | Completo | O mais seguro e rápido, ideal para conteúdo |
| ISR / regeneração incremental | Páginas estáticas regeneradas de tempos em tempos | Completo | Bom para catálogos grandes que mudam |
| Renderização dinâmica | HTML pré-renderizado só para robôs | Completo para robôs | Paliativo; o Google não recomenda mais |

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.

| Robô | Executa JavaScript? | Efeito em um site CSR |
| --- | --- | --- |
| Googlebot | Sim, com Chromium atualizado, em fila | Indexa, com atraso e risco de erros |
| Robôs da OpenAI (GPTBot, OAI-SearchBot) | Não | Vê a página vazia |
| ClaudeBot (Anthropic) | Não | Vê a página vazia |
| PerplexityBot | Não | Vê a página vazia |

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](https://patrickperdigao.com.br/blog/o-que-e-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](https://patrickperdigao.com.br/blog/cloudflare-robos-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ô.

| Erro | Por que prejudica | Como corrigir |
| --- | --- | --- |
| Navegação com `<div onClick>` ou `<button>` | O Google só segue `<a>` com `href` | Usar `<a href="/pagina">` e interceptar o clique no JS, se preciso |
| Rotas com `#` (`/#/produtos`) | Fragmentos não são resolvidos de forma confiável | URLs reais com a History API (`pushState`) |
| Conteúdo carregado só no clique ou na rolagem | O Google não clica nem rola como uma pessoa | Conteúdo importante no HTML; abas e acordeões com o texto já no DOM |
| Title, canonical e robots só via JS | Risco de divergência entre o HTML original e o renderizado | Meta tags no HTML do servidor; se mudar no JS, manter o mesmo valor |
| SPA que mostra "página não encontrada" com status 200 | Soft 404: o Google indexa páginas de erro | Rota que responde 404 de verdade ou `noindex` nas páginas de erro |
| Bundle sem hash no nome | O renderizador pode usar arquivos desatualizados | Nome com impressão digital (`main.2bb85551.js`) e cache longo |
| Recursos de JS ou API bloqueados no `robots.txt` | O renderizador não consegue montar a página | Liberar os recursos necessários para a renderização |

### 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.

> [!TIP] Confira a captura, não só o HTML
> O HTML renderizado mostra se o texto existe; a captura de tela mostra se ele está visível. Efeitos de entrada, carrosséis e acordeões fechados podem deixar o conteúdo no DOM e, ao mesmo tempo, invisível na renderizaçã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:

```bash
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.

| Tipo de página | Estratégia recomendada |
| --- | --- |
| Blog, guias, páginas institucionais | SSG |
| Categorias e produtos de e-commerce | SSG com regeneração ou SSR, conforme o volume e a frequência de mudança |
| Resultados de busca interna, páginas personalizadas | SSR (e, em geral, `noindex` na busca interna) |
| Painel do cliente, área logada, ferramentas internas | CSR, sem preocupação com indexação |

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](https://patrickperdigao.com.br/blog/webmcp).

## Quais erros evitar?

| Erro | O que fazer no lugar |
| --- | --- |
| Conferir a página só no DevTools | Comparar o código-fonte (Ctrl+U) com o HTML renderizado |
| Achar que "o Google renderiza, então está tudo bem" | Lembrar que os robôs de IA não executam JavaScript |
| Links com `onClick` sem `href` | `<a href>` com URL real |
| `noindex` no HTML que o JS remove depois | Nunca colocar `noindex` em página que deve ser indexada |
| Usar renderização dinâmica em projeto novo | SSR, SSG ou hidratação |
| Página de erro com status 200 | Status 404 ou `noindex` |
| Animações que escondem conteúdo para robôs | Desligar para os robôs ou não esconder conteúdo importante |

## Checklist

- [ ] Conteúdo principal presente no HTML de origem (veja com Ctrl+U, não com o DevTools)
- [ ] Title, meta description, canonical e robots no HTML do servidor
- [ ] Links internos como <a href>, com URLs reais (sem #)
- [ ] Páginas de erro com status 404 de verdade ou noindex
- [ ] Nada de noindex no HTML original de páginas que devem ser indexadas
- [ ] Arquivos JS e CSS com hash no nome e cache longo
- [ ] Teste do URL ativo no Search Console: HTML renderizado e captura de tela conferidos
- [ ] Animações que escondem conteúdo desligadas para robôs

## Perguntas frequentes

### O Google consegue indexar sites feitos em JavaScript?

Sim. O Google renderiza as páginas com uma versão atualizada do Chromium e indexa o conteúdo gerado por JavaScript. Mas a renderização entra em uma fila, que pode levar de segundos a mais tempo, e erros no JavaScript podem impedir que o conteúdo apareça. Por isso, o Google ainda recomenda renderização no servidor ou pré-renderização.

### Qual a diferença entre SSR e CSR?

No CSR (client-side rendering), o servidor entrega um HTML quase vazio e o navegador monta a página executando JavaScript. No SSR (server-side rendering), o servidor entrega o HTML já com o conteúdo, e o JavaScript só adiciona a interação. Para SEO, o SSR é mais seguro, porque qualquer robô lê o conteúdo sem executar JavaScript.

### Os robôs de IA executam JavaScript?

Os principais não. Uma análise da Vercel com a MERJ mostrou que os robôs da OpenAI, da Anthropic (ClaudeBot) e da Perplexity baixam arquivos JavaScript, mas não os executam. Um site em CSR puro aparece para eles como uma página vazia, o que prejudica a presença nas respostas do ChatGPT, do Claude e do Perplexity.

### Renderização dinâmica ainda é recomendada?

Não. A renderização dinâmica, em que o servidor entrega uma versão pré-renderizada só para robôs, é tratada pelo Google como uma solução paliativa, e não como uma recomendação. O caminho indicado é SSR, SSG ou hidratação, que entregam o mesmo HTML completo para pessoas e robôs.

### Como saber se o Google está vendo o conteúdo da minha página?

Use o Testar URL ativo da Inspeção de URL no Search Console e confira o HTML renderizado e a captura de tela. Compare com o código-fonte da página (Ctrl+U): se um texto importante só aparece no HTML renderizado, ele depende de JavaScript para existir.

## Fontes e referências

- [Google Search Central: noções básicas de SEO para JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=pt-br)
- [Google Search Central: renderização dinâmica como solução paliativa](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering?hl=pt-br)
- [Vercel: The rise of the AI crawler](https://vercel.com/blog/the-rise-of-the-ai-crawler)

## Sobre o autor

Patrick Perdigão é especialista em seo e growth. Especialista de SEO na Omie, instrutor na Alura e professor na EducaSEO. Perfil completo: https://patrickperdigao.com.br/index.md

## Continue lendo

- [Cloudflare e os robôs de IA: o que mudou em 2026 e o que conferir no seu site](https://patrickperdigao.com.br/blog/cloudflare-robos-de-ia.md): Em 15/09/2026 o Cloudflare mudou o tratamento de robôs de IA. Entenda Search, Agent e Training e a opção que pode tirar o seu site do Google. (SEO Técnico, 12 out 2026)
- [O que é GEO (Generative Engine Optimization): o guia para ser citado pela IA em 2026](https://patrickperdigao.com.br/blog/o-que-e-geo.md): GEO é otimizar conteúdo para ser citado pelos AI Overviews, Modo IA, ChatGPT e Perplexity. Entenda como funciona, o que muda no SEO e por onde começar. (GEO & AEO, 11 out 2026)
- [WebMCP: o que é e como preparar o site para agentes de IA](https://patrickperdigao.com.br/blog/webmcp.md): WebMCP é a proposta do Google e da Microsoft para sites oferecerem ferramentas a agentes de IA no navegador. Veja como funciona, o status e como implementar. (SEO Técnico, 17 out 2026)