SSR vs CSR para SEO e IA: o que o Googlebot e os robôs de IA enxergam

Tempo de leitura: 16 minutos

A diferença entre SSR e CSR está em quem monta a página. No SSR, o servidor entrega o HTML pronto, enquanto no CSR o navegador monta o conteúdo com JavaScript. O Googlebot executa esse JavaScript, mas os robôs de IA medidos pela Vercel e pela MERJ em 2024 leram só o HTML da primeira resposta.

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

A diferença está em quando e onde nasce o HTML. No CSR, o navegador gera o conteúdo depois de baixar e rodar o JavaScript, ao passo que no SSR o servidor gera a página a cada pedido. Com o SSG, a página sai pronta do build. Por fim, o ISR refaz a versão estática em segundo plano, depois de um prazo ou sob demanda.

Modo	Onde e quando o HTML nasce	O que chega na primeira resposta
CSR	No navegador, após o JavaScript	Casca: um <div> vazio e scripts
SSR	No servidor, a cada pedido	Página completa
SSG	No build	Página completa, servida de arquivo ou CDN
ISR	No build, refeito em segundo plano	Página completa, às vezes desatualizada
Streaming	No servidor, em partes	Casca e, na mesma resposta, os blocos prontos
Server Components	No servidor ou no build	HTML do primeiro acesso e payload RSC
Pré-renderização	No build, rodando o app cliente	Estado inicial em HTML
Renderização dinâmica	Num renderizador, só para robôs	HTML pronto para o robô; CSR para pessoas

No ISR do Next.js, a primeira visita após o prazo ainda recebe a versão antiga, enquanto o servidor gera a nova.

Streaming e Server Components são SSR ou CSR?

Os dois entregam HTML na primeira resposta e, portanto, ficam mais perto do SSR do que do CSR.

No streaming, conforme o guia do Next.js, o servidor envia primeiro a casca: layout, menu e os fallbacks de <Suspense>. Em seguida, cada bloco pronto chega na mesma resposta, num <div hidden> com um script que o põe no lugar. Já que o status 200 sai no primeiro pedaço, um notFound() tardio vira meta tag noindex, e um redirect() vira redirecionamento no navegador.

Com Server Components, o Next.js gera o HTML do primeiro acesso, inclusive o dos Client Components. Nas navegações seguintes, só trafega o payload RSC. Para um robô, porém, cada URL baixada é um primeiro acesso.

O Googlebot executa JavaScript? E o Bingbot?

Sim. O Googlebot renderiza com uma versão sempre atualizada do Chromium, assim como o Bingbot faz com a versão estável mais recente do Microsoft Edge. No Google, porém, a renderização é uma etapa separada, o robô não clica nem rola a página, e um erro de script pode esconder conteúdo.

De acordo com o guia de JavaScript do Google Search Central, o Google processa a página em três fases: rastreamento, renderização e indexação. Ele baixa o HTML e extrai os links <a href>. Em seguida, a página entra numa fila e pode esperar alguns segundos ou mais. Por fim, um Chromium headless executa o JavaScript, e o HTML renderizado vai para o índice. Por isso, com CSR, texto e links só aparecem depois da renderização; com SSR, já estão no HTML rastreado.

Em mais de 100 mil acessos do Googlebot ao nextjs.org, em abril de 2024, a Vercel e a MERJ viram todas as páginas HTML indexáveis renderizadas. Além disso, nas mais de 37 mil renderizações medidas, a mediana entre rastreio e renderização foi de 10 segundos, e o percentil 99, de cerca de 18 horas. No entanto, a Vercel vende hospedagem para Next.js, e a MERJ é consultoria de SEO.

Quais limites pesam na renderização do Google e do Bing?

Os que mais pesam, de acordo com o Google:

• Noindex no HTML original: o Google pode pular a renderização e, assim, o script que removeria o noindex pode não rodar.
• Tamanho: o Googlebot lê só os primeiros 2 MB de cada arquivo HTML, JS ou CSS, contados sem compressão.
• Sem estado: cookies, localStorage e sessionStorage são apagados a cada carregamento.
• Sem interação: o robô não clica, não rola e recusa pedidos de permissão.

Os AI Overviews e o Modo IA usam esse índice. Por isso, o link de apoio precisa estar indexado e apto a aparecer com snippet, conforme o guia do Modo IA do Google e dos AI Overviews.

Do mesmo modo, as diretrizes do Bing Webmaster, que também valem para o Copilot, mandam não esconder conteúdo crítico atrás de renderização no cliente. Afinal, conteúdo que não renderiza de forma confiável pode não ser indexado nem escolhido para embasar respostas geradas.

Os robôs de IA, como GPTBot, ClaudeBot e PerplexityBot, executam JavaScript?

Não há resposta oficial, porque as páginas sobre os robôs da OpenAI, da Anthropic e do Perplexity não falam em JavaScript. Além disso, a medição pública mais citada, da Vercel com a MERJ, não viu nenhum robô de IA testado executar JavaScript. Por outro lado, um relato de setembro de 2026 sugere mudança nos robôs da OpenAI, ainda sem confirmação.

Conferimos as páginas de robôs da OpenAI, da Anthropic e do Perplexity, e nenhuma trata de renderização. O feed de atualizações dos robôs da OpenAI estava vazio.

O estudo da Vercel com a MERJ, de 17 de dezembro de 2024, usou o tráfego do nextjs.org, da rede da Vercel e de dois sites de vagas. Não renderizaram JavaScript: OAI-SearchBot, ChatGPT-User, GPTBot, ClaudeBot, Meta-ExternalAgent, Bytespider e PerplexityBot. Os robôs do ChatGPT e do Claude, inclusive, baixavam scripts sem executá-los. Em contrapartida, o Gemini, que usa a infraestrutura do Googlebot, e o Applebot renderizaram. Contudo, a Vercel, que vende hospedagem para Next.js, tem interesse comercial no tema.

“As marcas precisam garantir que a informação crítica seja renderizada no servidor e que seus sites continuem bem otimizados para manter a visibilidade num cenário de busca cada vez mais diverso.” (tradução nossa)

Ryan Siddle, diretor-geral da MERJ (2024)

O relato de 2026 sobre a OpenAI

Em 30 de setembro de 2026, o dono de um marketplace japonês em Next.js publicou na DEV Community a análise dos próprios logs. Com IPs conferidos nas listas da OpenAI, ele viu o OAI-SearchBot e o GPTBot dispararem pedidos ?_rsc= do Next.js desde 25 de setembro. Esses pedidos só surgem com a página renderizada. No entanto, ele não achou anúncio da OpenAI e acha que a mudança vale só para alguns sites. Da mesma forma, nas cópias do Internet Archive, o texto da OpenAI sobre os robôs é o mesmo desde antes do relato.

O que isso muda para SSR e CSR?

A regra prática, portanto, não muda: o que o robô precisa ler deve estar no HTML inicial, como no SSR, e não depender do CSR.

Robô	Executa JavaScript?	Base
Googlebot	Sim, numa fila de renderização	Documentação do Google
Bingbot	Sim, com o Edge atual	Documentação da Microsoft
Gemini (via Googlebot)	Sim, segundo o estudo	Vercel e MERJ, 2024
OAI-SearchBot e GPTBot	Não em 2024; relato de mudança em 2026	Vercel e MERJ; relato sem confirmação
ChatGPT-User	Não, no teste	Vercel e MERJ, 2024
ClaudeBot	Não, no teste	Vercel e MERJ, 2024
PerplexityBot	Não, no teste	Vercel e MERJ, 2024
Claude-SearchBot, Claude-User e Perplexity-User	Não testados em 2024	Lista do estudo da Vercel

Enquanto a OpenAI não confirmar nada, acompanhe o sinal nos seus logs. Qual robô liberar no robots.txt está em como aparecer no ChatGPT e no guia do Gemini, Perplexity e Claude. Esse acesso é o primeiro passo do GEO.

O que cada robô vê em SSR, CSR e nos outros modos

Para o Googlebot, quase todo modo funciona, com atraso no CSR e risco quando um script falha. Para um robô de IA que não executa JavaScript, porém, só existe o que já está no HTML da primeira resposta. A tabela supõe conteúdo vindo de dados do servidor ou de uma API.

Modo	O que o Googlebot vê	Robô de IA que não executa JavaScript
CSR	Conteúdo, após a fila de renderização	Casca vazia
SSR	Página completa	Página completa
SSG	Página completa	Página completa
ISR	Página completa, talvez desatualizada	Página completa, talvez desatualizada
Streaming	Página completa	Casca e, depois, blocos em <div hidden>
Server Components	Página completa	Página completa e payload RSC
Pré-renderização	Página completa	Estado inicial do app
Renderização dinâmica	HTML do renderizador	HTML pronto, se o robô estiver na lista

Como ver o HTML que cada robô recebe?

Compare a primeira resposta do servidor, que é o que lê um robô sem JavaScript, com o DOM depois do JavaScript, próximo do que o Googlebot renderiza. Além disso, com o user agent de cada robô, o teste revela o modo de renderização e se a página muda de robô para robô.

O script abaixo baixa a mesma URL como cada robô e conta o trecho de texto, o title, o canonical, o JSON-LD e os links. As strings vêm das documentações oficiais, e W.X.Y.Z marca a versão do navegador, conforme a fonte. A OpenAI avisa que a versão dos robôs pode mudar, enquanto a Anthropic publica só o nome deles.

URL="https://www.exemplo.com.br/pagina/"
TRECHO="uma frase do texto principal da página"

testar() {
  curl -sL --compressed -A "$2" -o "$1.html" -w "$1: HTTP %{http_code} | " "$URL"
  echo "trecho: $(grep -cF "$TRECHO" "$1.html") | title: $(grep -ci '<title' "$1.html") | canonical: $(grep -ciE 'rel=.?canonical' "$1.html") | JSON-LD: $(grep -o 'application/ld+json' "$1.html" | wc -l) | links: $(grep -o '<a [^>]*href="[^"#][^"]*"' "$1.html" | wc -l)"
}

# Google: developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
testar googlebot 'Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'

# Bing: bing.com/webmasters/help/which-crawlers-does-bing-use-8c184ec0
testar bingbot 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36'

# OpenAI: developers.openai.com/api/docs/bots
testar oai-searchbot 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot'
testar gptbot 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot'
testar chatgpt-user 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot'

# Perplexity: docs.perplexity.ai/docs/resources/perplexity-crawlers
testar perplexitybot 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)'
testar perplexity-user 'Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)'

# Anthropic: support.claude.com/en/articles/8896518 (publica só o nome do robô)
testar claudebot 'ClaudeBot'
testar claude-searchbot 'Claude-SearchBot'
testar claude-user 'Claude-User'

# DOM depois do JavaScript; o --virtual-time-budget dá à página até 10 s de tempo virtual
# Doc: developer.chrome.com/docs/automation-and-testing/headless-cli
# No macOS e no Windows, troque google-chrome pelo caminho do Chrome instalado
google-chrome --headless --virtual-time-budget=10000 --dump-dom "$URL" > renderizado.html
echo "renderizado: trecho: $(grep -cF "$TRECHO" renderizado.html) | links: $(grep -o '<a [^>]*href="[^"#][^"]*"' renderizado.html | wc -l)"

Como saber se a página usa SSR ou CSR?

Quando o trecho e os links aparecem para todos os robôs, a página entrega HTML pronto: SSR, SSG, ISR ou pré-renderização. Se aparecem só no renderizado.html, é CSR. Por outro lado, se mudam de um user agent para outro, há renderização dinâmica ou regra por robô.

Trocar o user agent não transforma o seu computador no robô, já que o pedido sai do seu IP. O Perplexity, por exemplo, orienta liberar seus robôs no WAF da Cloudflare com regra que exige user agent e IP. Na Cloudflare, robô verificado se identifica por assinatura, lista de IPs ou DNS reverso. Por isso, o curl não reproduz bloqueio por IP ou WAF, nem pré-renderização servida só a robôs verificados. Um bloqueio na Cloudflare aparece nos eventos de segurança e nos logs da própria Cloudflare.

Que outros testes completam o diagnóstico?

• Código-fonte contra DOM: no Chrome, view-source: mostra a resposta do servidor, enquanto a aba Elements do DevTools mostra o DOM depois do JavaScript.
• Chrome sem JavaScript: no DevTools, pressione Ctrl+Shift+P (Cmd+Shift+P no Mac), escolha Disable JavaScript e recarregue. Assim, o que some não existe para um robô sem JavaScript.
• Inspeção de URL: conforme a ajuda do Search Console, Ver a página rastreada mostra HTML, resposta HTTP, console JavaScript e recursos da versão indexada. No entanto, só o Teste em tempo real gera captura de tela.
• Logs do servidor: contam os pedidos de cada robô. Mas baixar arquivos .js não prova execução. Sinais mais fortes são as chamadas de API que o script faz e, no Next.js, os pedidos ?_rsc=.

# Pedidos por robô: linhas do log (formato combined do Nginx ou do Apache) com o nome de cada um
for R in Googlebot bingbot OAI-SearchBot GPTBot ChatGPT-User ClaudeBot Claude-SearchBot Claude-User PerplexityBot Perplexity-User; do
  echo "$R: $(grep -c "$R" access.log)"
done

# O IP é do Google? DNS reverso e depois direto (no Windows, use nslookup no lugar de host)
# Doc: developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

# O IP está nas faixas do OAI-SearchBot? (troque pelo IP do log)
curl -s https://openai.com/searchbot.json | python3 -c "import sys,json,ipaddress; ip=ipaddress.ip_address(sys.argv.pop()); print(any(ip in ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix')) for p in json.load(sys.stdin)['prefixes']))" 203.0.113.10

O user agent pode ser falsificado, então confirme o IP: OpenAI, Perplexity e Anthropic publicam listas. Para auditar página por página, com sintoma e correção, use um checklist de JavaScript SEO. Depois da correção, acompanhe o tráfego de IA no GA4.

O que precisa estar no HTML inicial?

Tudo o que um robô sem JavaScript deve ler, entender ou seguir. No Googlebot, o rastreamento já coleta os links do HTML inicial, antes da renderização. A lista mínima tem texto principal, links, title, meta description, canonical, meta robots, dados estruturados e hreflang.

• Texto principal: títulos, parágrafos, preços e datas, em texto e não só em imagem.
• Links como <a href>: o Google só extrai com segurança links <a> com href que resolve num endereço. Por isso, <span> clicável e <a> só com onclick não servem.
• Title e meta description: únicos por URL, já no <head> da resposta.
• Canonical: no HTML. O Google aceita canonical por JavaScript, mas não recomenda e pede que não contradiga o do HTML original.
• Meta robots: não publique noindex no HTML original contando que um script vai removê-lo.
• Dados estruturados: JSON-LD no HTML do servidor. Conforme o Google, Product gerado por JavaScript pode tornar o rastreamento do Shopping menos frequente e confiável.
• hreflang: no HTML, no cabeçalho HTTP ou no sitemap; o Google trata os três métodos como equivalentes. Os dois últimos não dependem de JavaScript.

Erros comuns

• Conteúdo que só aparece com clique. Abas e botões de “ver mais” que buscam o texto no clique o escondem dos robôs. Afinal, o Google avisa que não interage com a página.
• Lazy load por rolagem. Carregue quando o bloco entra na tela, com loading="lazy" em imagens e iframes ou com IntersectionObserver, e não por evento de rolagem.
• Rotas sem URL própria. SPAs com #/produtos ou estado que não muda o endereço. O Google pede a History API, com uma URL real por página.
• Meta tags injetadas por JavaScript. Title, description e canonical criados no cliente só existem para quem renderiza. No Next.js, por exemplo, metadados assíncronos podem ir para o <body> no streaming. O <head> completo fica para a lista padrão de robôs do Next.js, sem GPTBot, OAI-SearchBot, ClaudeBot ou PerplexityBot. A opção htmlLimitedBots os inclui, mas substitui a lista inteira.
• Soft 404 em SPA. A rota inexistente responde 200 com mensagem de erro. O Google sugere redirecionar para uma URL com status 404 ou incluir noindex.

Pré-renderização e renderização dinâmica ainda valem?

Valem como paliativo, não como arquitetura. Afinal, o Google trata a renderização dinâmica como solução temporária e recomenda SSR, renderização estática ou hidratação. Serviços como o Prerender.io seguem esse modelo, isto é, detectam o robô pelo user agent e entregam HTML já renderizado. Funcionam desde que a lista de robôs e o conteúdo estejam certos.

De acordo com a documentação do Google, a renderização dinâmica “foi um paliativo, e não uma solução de longo prazo” (tradução nossa). Ela não é cloaking, desde que o conteúdo seja parecido. No entanto, servir conteúdo completamente diferente a robôs e pessoas pode ser cloaking, que o Google e o Bing tratam como manipulação.

No middleware prerender-node, por exemplo, a lista padrão inclui GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot e PerplexityBot. Claude-SearchBot e Claude-User, porém, ficam de fora, porque o código procura o trecho “claudebot” no user agent. Já a pré-renderização no build não tem esse risco, pois entrega o mesmo HTML a todos.

SSR ou CSR: qual modo de renderização escolher para aparecer no Google e na IA?

Escolha o modo que põe o conteúdo público no HTML da primeira resposta com o menor custo. Para a maioria dos sites, isso é SSG ou ISR. O SSR entra quando o conteúdo muda a cada pedido ou depende de quem pede. Por outro lado, o CSR fica para o que não precisa de robôs, como áreas logadas e widgets.

• Site institucional: SSG, porque as páginas mudam pouco e o HTML sai direto de uma CDN.
• Blog: SSG ou ISR, com revalidação a cada publicação. O WordPress já gera HTML no servidor, mas o risco está em plugins que montam blocos por JavaScript.
• E-commerce: SSR ou ISR em produto e categoria, com preço, estoque e JSON-LD de Product no HTML. Com ISR, ajuste o prazo ao ritmo de mudança de preço.
• App logado: CSR atrás do login não afeta SEO, mas home, preços, documentação e páginas de recurso precisam de SSG ou SSR.

Como sair do CSR para o SSR em cada stack?

Cada stack tem seu caminho, e em site já no ar tudo começa pelo diagnóstico de JavaScript SEO. O SEO em React passa por sair do CSR padrão, com SSR, pré-renderização ou Next.js. Para SEO no Next.js, o App Router usa Server Components por padrão, e as escolhas ficam entre estático, ISR, streaming e metadados. O SSR no Angular e no Vue vem do pacote @angular/ssr e do Nuxt.

Os sites do Lovable mudaram em 2026. De acordo com a documentação do Lovable, apps criados desde 13 de maio usam TanStack Start, com renderização no servidor (nos planos Enterprise, desde 22 de junho). Já os antigos, em React e Vite, montam a página no navegador, mas recebem pré-renderização só para robôs verificados na hospedagem do Lovable.

Quando reescrever o front não cabe no prazo, a pré-renderização como serviço, no modelo do Prerender.io, compra tempo. Renderização é a base técnica do SEO que sustenta a visibilidade da marca em IA.

Perguntas frequentes

Fontes principais

• Google Search Central, Understand JavaScript SEO Basics (2026).
• Google Search Central, Dynamic Rendering as a workaround (2025).
• Vercel, The rise of the AI crawler, estudo com a MERJ (2024).
• Vercel, How Google handles JavaScript throughout the indexing process, estudo com a MERJ (2024).
• Bing Webmaster, Bing Webmaster Guidelines (2026).
• OpenAI, Overview of OpenAI Crawlers (2026).