SEO JavaScript: por que o ChatGPT pode não ver o seu site

Tempo de leitura: 14 minutos

SEO JavaScript é garantir que o conteúdo montado por JavaScript chegue ao Google e aos rastreadores de IA que indexam e citam páginas. O Google executa o código antes de indexar, mas os rastreadores de IA testados pela Vercel e pela MERJ em 2024 leram só o HTML inicial. Por isso, este guia mostra o processo, os testes e as correções.

O Google renderiza páginas com JavaScript?

Sim. O guia Princípios básicos de SEO em JavaScript, do Google, descreve três fases: rastreamento, renderização e indexação. Toda página com status 200 entra numa fila de renderização, salvo se uma meta tag robots ou um cabeçalho pedir para não indexar. Em seguida, um Chromium sem interface executa o código, e o Google indexa o HTML que sai dessa execução.

O Googlebot lê o robots.txt, baixa a página, coleta os links do href e a põe na fila, onde ela espera segundos ou mais. Assim que a renderização termina, a página passa por nova coleta de links e vai para o índice.

No site medido, em geral, a fila foi curta. A Vercel e a MERJ mediram o tempo de mais de 37 mil renderizações do Googlebot no nextjs.org, em abril de 2024. A mediana entre rastreamento e renderização foi de 10 segundos, mas o percentil 99 chegou a cerca de 18 horas. A Vercel vende hospedagem para sites em Next.js, e a MERJ é uma consultoria de SEO.

Ainda assim, o guia de SEO em JavaScript do Google diz que renderizar no servidor ou pré-renderizar continua sendo boa ideia. Afinal, nem todos os robôs executam JavaScript.

O que atrapalha o SEO JavaScript no Google?

Mesmo com a renderização, alguns problemas deixam conteúdo fora do HTML renderizado ou do índice. Os mais comuns vão de recursos bloqueados ou pesados a erros de script, status HTTP errado e rotas com #.

• Recursos bloqueados no robots.txt. De acordo com o guia de SEO em JavaScript do Google, o buscador não renderiza JavaScript de arquivos bloqueados, e a página pode ficar incompleta.
• Arquivos grandes demais. Segundo um post do Google de março de 2026, o Googlebot baixa até 2 MB de cada URL. Além disso, cada script e cada CSS têm limite próprio, e o Google ignora o que passa disso.
• Recursos lentos. O Google não publica prazo fixo para renderizar. No entanto, a ajuda do teste de pesquisa aprimorada aponta o recurso que não carrega “em um período razoável de tempo”.
• Erros e recursos sem suporte. Um erro de script pode interromper a página, por isso o guia de solução de problemas de JavaScript recomenda registrar os erros. O renderizador, além disso, apaga cookies e armazenamento local entre páginas e não usa WebSockets.
• Conteúdo que depende de interação. O Google não interage com a página, segundo a página sobre carregamento lento. O que só carrega após clique ou rolagem do usuário pode ficar de fora.
• Status diferente de 200 e noindex. O Google pode não renderizar páginas de erro. Da mesma forma, com noindex no HTML inicial, ele pode pular a renderização, e remover a tag por script pode não funcionar.
• Soft 404 em SPA. Quando a aplicação de página única trata erros no navegador, a rota inexistente geralmente responde 200 e pode acabar indexada.
• Fragmentos com #. O guia de SEO em JavaScript do Google desaconselha rotas como /#/produtos, porque o Googlebot não resolve essas URLs de forma confiável.

Os rastreadores de IA 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 em dezembro de 2024, não viu os rastreadores de IA testados executarem o código. Por outro lado, um relato de setembro de 2026 sugere mudança nos robôs da OpenAI, ainda sem confirmação.

Conferimos a documentação da OpenAI, a página da Anthropic e a documentação do Perplexity. Elas descrevem a função de cada robô, mas não tratam de renderização.

No estudo publicado em 17 de dezembro de 2024, a Vercel e a MERJ usaram dados dos meses anteriores do nextjs.org, da rede da Vercel e de dois sites de vagas. Nenhum dos grandes rastreadores de IA testados renderizou JavaScript. Os do ChatGPT e do Claude baixavam scripts, em 11,50% e 23,84% dos pedidos, mas não os executavam. Aliás, a Vercel, que vende hospedagem para Next.js, tem interesse comercial no tema.

O estudo traz duas ressalvas. Em primeiro lugar, dados que já vêm no HTML, como um JSON embutido, ainda podem ser lidos. Em segundo lugar, o Gemini usa a infraestrutura do Googlebot e renderiza JavaScript. Da mesma forma, os AI Overviews e o Modo IA citam páginas do índice da Busca, montado com o HTML renderizado.

“As marcas precisam garantir que a informação crítica seja renderizada no servidor.” (tradução nossa)

Ryan Siddle, diretor-geral da MERJ (2024)

Robô	Executa JavaScript?	Base
Googlebot	Sim, numa fila de renderização	Documentação do Google
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

O relato de setembro de 2026

Em 30 de setembro, o dono de um marketplace japonês em Next.js publicou na DEV Community a análise dos próprios logs, com os IPs conferidos nas listas da OpenAI. Segundo ele, desde 25 de setembro o OAI-SearchBot e o GPTBot disparam, nos sites dele, pré-carregamentos de links que 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.

Além disso, no Internet Archive, o texto sobre os robôs na página da OpenAI é o mesmo desde a cópia de 17 de setembro. Por isso, trate o relato como um sinal a acompanhar nos logs. Para o SEO JavaScript, a regra prática continua a mesma: o que os robôs precisam ler deve estar no HTML inicial. A base técnica é o primeiro passo do SEO para a era da IA.

A função de cada robô está na tabela de robôs do guia sobre o que é GEO. Nas respostas com busca do ChatGPT, por exemplo, quem conta é o OAI-SearchBot, conforme o guia de como aparecer no ChatGPT.

Que conteúdos somem das páginas sem JavaScript (texto, links, preços)?

Some tudo o que o navegador monta depois de carregar a página. Para os rastreadores de IA que leem só o HTML inicial, ficam de fora o texto buscado por API e os links sem href. Da mesma forma, somem preços, avaliações, meta tags e dados estruturados inseridos por script.

Conteúdo	Como costuma ser montado	O que o robô perde
Texto principal	Chamada de API depois do carregamento	A página inteira
Links internos	Botão ou onclick sem href	As páginas linkadas
Preço e estoque	Script que consulta o catálogo	Os dados da oferta
Avaliações	Widget de terceiros	Nota e comentários
Title, description e canonical	Definidos por script	Resumo e URL preferida
Dados estruturados	JSON-LD injetado por script ou pelo GTM	Produto, empresa, autor
Imagens	Troca de data-src por src	O endereço da imagem
Listas longas	Rolagem infinita	Itens além da primeira tela

Segundo a documentação de links do Google, o Google em geral só rastreia elementos <a> com atributo href. Por isso, um menu feito de botões pode esconder páginas internas até do Googlebot.

Em lojas, aliás, o Google avisa que a marcação de produto gerada por JavaScript pode deixar o rastreamento do Shopping menos frequente e menos confiável.

Como testar o SEO JavaScript do seu site?

Compare três versões da página: o HTML que o servidor entrega a cada robô, o DOM depois do JavaScript e o que o Google indexou. O checklist abaixo traz cinco testes, cada um com o sintoma, como verificar e a correção.

1. curl com o user agent de cada robô

Sintoma: a página aparece no Google, mas o ChatGPT e o Perplexity não a citam.

Como verificar: baixe o HTML com o user agent oficial de cada robô e, em seguida, procure uma frase do texto e os links. A Anthropic publica só o nome do robô, mas ele serve para o teste. O Googlebot serve de comparação: se só ele recebe o texto, o servidor muda a resposta conforme o user agent.

URL="https://www.exemplo.com.br/produto/tenis-azul"
FRASE="Tênis de corrida azul"

# No user agent do Googlebot, W.X.Y.Z é como o Google indica a versão do Chrome
for UA in \
  "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)" \
  "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" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" \
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)" \
  "ClaudeBot" "Claude-SearchBot" "Claude-User"
do
  ROBO=$(echo "$UA" | grep -oE "Googlebot|OAI-SearchBot|GPTBot|ChatGPT-User|PerplexityBot|Perplexity-User|Claude[A-Za-z-]*" | head -1)
  STATUS=$(curl -sL -A "$UA" -o pagina.html -w "%{http_code}" "$URL")
  echo "$ROBO | status $STATUS | frase: $(grep -oF "$FRASE" pagina.html | wc -l) | links: $(grep -oi '<a [^>]*href=' pagina.html | wc -l)"
done

O teste não reproduz o IP do robô, por isso um firewall que confere user agent e IP, como o Perplexity recomenda, pode responder diferente. Os rastreadores de IA do Perplexity e do Claude estão no guia de como aparecer no Gemini, no Perplexity e no Claude.

Correção: se a frase ou os links não aparecem, o conteúdo depende de JavaScript e precisa ir para o HTML do servidor. Status 403 ou 503 pede revisão do firewall e da CDN antes do código.

2. Código-fonte contra DOM renderizado

Sintoma: o navegador mostra o texto, mas o código-fonte traz pouco além de um <div id="root"> e scripts.

Como verificar: compare o código-fonte (Ctrl+U) com o painel Elements das ferramentas do desenvolvedor. Na linha de comando, o Chrome sem interface, com a opção --dump-dom, imprime o DOM depois de executar o JavaScript.

URL="https://www.exemplo.com.br/produto/tenis-azul"
FRASE="Tênis de corrida azul"

curl -sL "$URL" > fonte.html
# No Windows e no macOS, troque google-chrome pelo caminho do Chrome instalado
google-chrome --headless --disable-gpu --dump-dom "$URL" > renderizado.html

for f in fonte.html renderizado.html; do
  echo "$f | frase: $(grep -oF "$FRASE" "$f" | wc -l) | links: $(grep -oi '<a [^>]*href=' "$f" | wc -l)"
done

Correção: o que só aparece no arquivo renderizado é invisível para robôs que não executam JavaScript. Portanto, leve primeiro texto, preço, links e meta tags para o HTML do servidor.

3. Inspeção de URL no Search Console

Sintoma: a página não aparece no Google, ou aparece com título, descrição ou canonical errados.

Como verificar: na ferramenta de inspeção de URL, rode o teste em tempo real e então abra “Ver a página testada”. Ali estão a captura de tela, o código da página, os recursos carregados e a saída do console JavaScript.

Correção: libere recursos bloqueados no robots.txt, corrija os erros do console e leve ao servidor o que falta na captura. Por fim, teste de novo e peça a indexação.

4. Teste de pesquisa aprimorada

Sintoma: os dados estruturados não geram resultados avançados, ou a página é de um domínio sem acesso ao Search Console.

Como verificar: cole a URL no teste de pesquisa aprimorada. Ele acessa a página como smartphone, por padrão, avisa sobre recursos que não carregaram e mostra o código renderizado.

Correção: se o JSON-LD aparece no teste, mas não no HTML do curl, só quem executa JavaScript o vê. Então, gere o bloco no servidor.

5. Logs do servidor

Sintoma: você não sabe se os rastreadores de IA visitam o site, com que status ou se renderizam algo.

Como verificar: filtre o log pelos nomes dos robôs, conte os status e veja se o robô pede algo além do HTML.

# Formato combinado do Apache e do Nginx: status no 9º campo, caminho no 7º

# Status HTTP por robô
for R in OAI-SearchBot GPTBot ChatGPT-User ClaudeBot Claude-SearchBot Claude-User PerplexityBot Perplexity-User; do
  echo "== $R"
  grep "$R" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
done

# O que o OAI-SearchBot pede além do HTML
grep "OAI-SearchBot" access.log | awk '{print $7}' \
  | grep -E '\.(css|js|png|jpe?g|webp)|/api/|_rsc=' \
  | sort | uniq -c | sort -rn | head -20

Pedido de arquivo .js não prova execução, porque no estudo da Vercel os rastreadores de IA baixavam scripts sem executá-los. Sinais mais fortes são as chamadas de API que o script faz e, em Next.js, URLs com _rsc=. Em sites feitos em Next.js, veja também o que o framework entrega a cada robô no guia de SEO no Next.js. Já que qualquer um pode imitar um user agent, confira o IP nas listas de cada empresa.

Para o Google, use o relatório de estatísticas de rastreamento do Search Console. Isso porque o guia de solução de problemas de JavaScript avisa que o analytics do navegador pode não mostrar essa atividade por completo.

Correção: 403 ou 429 para um robô que você quer liberar indica firewall ou limite de taxa. Muitos 404, por sua vez, pedem redirecionamentos e sitemap atualizado. No estudo da Vercel, por exemplo, 34,82% dos pedidos do ChatGPT e 34,16% dos do Claude caíram em páginas 404, contra 8,22% do Googlebot.

Como corrigir o SEO JavaScript sem refazer o site?

Em geral, as correções cabem no código atual, sem trocar o framework. A regra é uma só: o que os robôs precisam ler, citar ou seguir deve estar no HTML que o servidor entrega. Isso vale de links e meta tags a imagens, paginação e status HTTP.

Links com href. Mantenha o roteador, mas renderize um <a> com a URL real. Um evento de clique pode continuar no link.

<!-- Evite: o Google pode não extrair a URL -->
<span onclick="irPara('/tenis')">Tênis</span>
<a onclick="irPara('/tenis')">Tênis</a>

<!-- Rastreável -->
<a href="/tenis">Tênis</a>

Uma URL por rota, com a History API. Troque /#/produtos por /produtos e use pushState no roteador. Além disso, o servidor deve responder cada rota com o HTML dela.

Meta tags no HTML do servidor. Title, description, canonical e robots devem vir na resposta do servidor. O guia de SEO em JavaScript do Google aceita title e description definidos por script, mas pede que o script mantenha o canonical do HTML.

<head>
  <title>Tênis de corrida azul | Loja Exemplo</title>
  <meta name="description" content="Tênis leve para treinos de 5 a 21 km.">
  <link rel="canonical" href="https://www.exemplo.com.br/produto/tenis-azul">
</head>

Dados estruturados no HTML inicial. O Google lê JSON-LD injetado por JavaScript ao renderizar, mas um robô que lê só o HTML, não. Por isso, gere o bloco no servidor.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Tênis de corrida azul",
  "offers": {
    "@type": "Offer",
    "price": "399.90",
    "priceCurrency": "BRL",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Lazy load com fallback no HTML. O carregamento nativo do navegador mantém o src no HTML inicial: sem JavaScript, a imagem continua lá. Por outro lado, bibliotecas que trocam data-src por src deixam sem a imagem o robô que não executa JavaScript.

<!-- O robô vê o endereço da imagem -->
<img src="/img/tenis-azul.webp" alt="Tênis de corrida azul" loading="lazy" width="800" height="600">

<!-- Sem JavaScript, não há imagem -->
<img data-src="/img/tenis-azul.webp" class="lazyload" alt="Tênis de corrida azul">

Paginação em vez de rolagem infinita. Dê a cada bloco da lista uma URL fixa, como ?page=2, com links em sequência, e atualize a URL com a History API durante a rolagem. Assim o robô acha todos os itens.

<!-- Na página /tenis?page=2 -->
<nav aria-label="Paginação">
  <a href="/tenis?page=1">Anterior</a>
  <a href="/tenis?page=3">Próxima</a>
</nav>

Status HTTP certos. Rota inexistente deve responder 404 no servidor. Se a SPA não permitir, o Google aceita redirecionar por script para uma URL com 404 ou pôr noindex na página de erro. Para robôs que não executam JavaScript, porém, só o status do servidor conta.

// Rota de produto numa SPA (adaptado do exemplo do Google)
fetch(`/api/produtos/${id}`)
  .then((resposta) => resposta.json())
  .then((produto) => {
    if (!produto.existe) {
      window.location.href = '/nao-encontrado'; // o servidor responde 404 nesta URL
    }
  });

Quando as correções de SEO JavaScript não bastam?

Se o conteúdo principal inteiro depende do navegador, essas correções não bastam. Aí a saída é mudar o modo de renderização, com renderização no servidor, geração estática ou pré-renderização. Para escolher entre esses modos, veja o comparativo entre renderização no servidor e no navegador. O mesmo vale para sites criados no Lovable e em outras ferramentas que geram páginas pelo navegador. Em sites feitos com React, o guia de SEO em React mostra as opções de SSR, pré-renderização e Next.js.

Perguntas frequentes

Fontes principais

• Google Search Central, Princípios básicos de SEO em JavaScript (2026).
• Vercel e MERJ, estudo sobre como o Google renderiza JavaScript (2024).
• Vercel e MERJ, The rise of the AI crawler, sobre rastreadores de IA e JavaScript (2024).
• OpenAI, Overview of OpenAI Crawlers (2026).
• Anthropic, robôs da Anthropic e como controlá-los (2026).
• Perplexity, Perplexity Crawlers (2026).