11 min read

Os rastreadores de IA conseguem ler o seu site? Verificamos 342 sites de lançamento sem JavaScript

A maioria dos crawlers de IA não executa JavaScript. Acessamos 365 sites de produtos lançados recentemente da mesma forma que eles. Dos 342 que carregaram, 1 em cada 10 retornou uma página com título e descrição, mas quase nenhum texto no corpo. O que medimos, por que isso acontece e a verificação de dois minutos para o seu próprio site.

GEOAI CrawlersJavaScript SEOTechnical SEOData
Os rastreadores de IA conseguem ler o seu site? Verificamos 342 sites de lançamento sem JavaScript

Em outubro de 2026, solicitamos 365 sites de produtos lançados no aat.ee da mesma forma que um crawler que não executa JavaScript faria, e contamos o texto no HTML retornado. Dos 342 que responderam com HTTP 200, 37 (10,8%) retornaram menos de 50 palavras de texto no corpo. Quase todos ainda tinham um título e uma meta description, então a página parece bem em uma prévia de link enquanto o conteúdo em si só chega depois que o JavaScript é executado. Quando carregamos as mesmas 37 páginas em um navegador real, 23 das 30 que terminaram de carregar exibiram 150 palavras ou mais.

Isso importa porque foi observado que os crawlers por trás do ChatGPT, Claude e Perplexity não executam JavaScript. Se a descrição do seu produto existe apenas na página renderizada, esses sistemas podem nunca vê-la. Abaixo estão os números, a causa e uma verificação que você pode fazer no seu próprio site em dois minutos.

Quais crawlers executam JavaScript

OpenAI, Anthropic, Meta, ByteDance e Perplexity não documentam se seus crawlers renderizam JavaScript. A melhor evidência disponível é um estudo de dezembro de 2024 da Vercel e da MERJ. Ele descobriu que nenhum dos principais crawlers de IA que examinou renderizava JavaScript: OAI-SearchBot, ChatGPT-User e GPTBot da OpenAI, ClaudeBot da Anthropic, Meta-ExternalAgent, Bytespider da ByteDance e PerplexityBot. Os crawlers do ChatGPT e do Claude baixaram arquivos JavaScript (11,50% e 23,84% de suas requisições), mas não os executaram. O Gemini, que usa a infraestrutura do Googlebot, renderizava. O AppleBot também.

O Googlebot renderiza JavaScript, mas em uma etapa separada. O guia de SEO para JavaScript do Google diz que as páginas são enfileiradas e que "assim que os recursos do Google permitirem, um Chromium headless renderiza a página e executa o JavaScript". O Google ainda recomenda renderização no servidor ou pré-renderização, porque "isso torna seu site mais rápido para usuários e crawlers, e nem todos os bots conseguem executar JavaScript".

O estudo é uma única observação, com quase dois anos, e o comportamento dos crawlers pode mudar sem aviso. Ainda assim, são os melhores dados disponíveis, e nenhuma das empresas o contestou.

Como medimos

  • Amostra: 400 URLs de projetos sorteadas aleatoriamente entre produtos lançados no aat.ee nos 120 dias anteriores à auditoria. Mantivemos uma URL por nome de host e descartamos 14 links que apontavam para GitHub, lojas de aplicativos ou Hugging Face em vez do site do próprio produto, o que deixou 365 sites. 342 retornaram HTTP 200 e são a base dos números abaixo.
  • Requisição: um GET por site com um user agent contendo o token OAI-SearchBot da OpenAI, seguindo redirecionamentos, sem executar JavaScript.
  • Medida: palavras de texto visível no corpo após remover os elementos <script>, <style>, <noscript>, <template> e <svg>. Também registramos se o HTML continha um título, uma meta description, um link canônico, JSON-LD e um <h1>.
  • Limitações: buscamos apenas a URL enviada pelo fundador, geralmente a página inicial. Nossas requisições vieram da nossa própria rede, não dos intervalos de IP da OpenAI, então um site que trata crawlers verificados de forma diferente poderia servir outra coisa a eles. Texto dentro de tags script não foi contado. O estudo da Vercel observa que dados incorporados no HTML inicial, como JSON, "ainda podem ser indexados", então, para alguns frameworks, nossa contagem subestima o que um crawler recebe. A maioria das páginas vazias abaixo são aplicações de página única cujo conteúdo vive em bundles JavaScript separados, que o estudo descobriu que esses crawlers baixam mas não executam.

Os resultados

Palavras no corpo no HTML brutoSitesParticipação de 342
Menos de 203510,2%
20–4920,6%
50–14930,9%
150–399236,7%
400 ou mais27981,6%

O site mediano retornou cerca de 1.180 palavras, então a maioria dos sites de lançamento está em boa forma. O problema é concentrado: 37 sites, quase todos com praticamente nada no corpo.

O head está preenchido e o corpo está vazio. Das 37 páginas com pouco texto, 36 tinham um <title> e 34 tinham uma meta description. Apenas 4 tinham um <h1>, e apenas 4 tinham cinco ou mais links. Um crawler que lê esse HTML aprende o nome do produto e um pitch de uma linha, e nada sobre recursos, preços ou para quem ele é.

Um padrão explica a maioria delas. 30 das 37 serviam um <div id="root"> ou <div id="app"> vazio e construíam a página inteira no navegador, que é o padrão de uma aplicação de página única feita com Vite ou Create React App. 12 eram builds do Vite. Em contraste, apenas 1 dos 165 sites Next.js da amostra tinha pouco texto. O Next.js renderiza páginas no servidor por padrão, então o conteúdo está na primeira resposta.

Templates vazam. 16 das 37 ainda tinham a meta description padrão do Create React App, "Web site created using create-react-app". Essas 16 vieram de três contas de envio lançando uma família de produtos semelhantes, então elas inflam o total. Deixe-as de fora e a parcela com pouco texto é de 21 de 326, ou 6,4%. Isso ainda é cerca de um lançamento em dezesseis.

Em um navegador, o conteúdo está lá

Em seguida, carregamos as 37 páginas com pouco texto em Chromium headless, esperamos cinco segundos após o evento de load e contamos o texto visível novamente. 30 páginas terminaram de carregar. 7 deram timeout após três tentativas.

Palavras no corpo após o JavaScript ser executadoSites (de 30)
150 ou mais23
50–1492
Menos de 505

A página mediana passou de 0 palavras no HTML bruto para cerca de 475 após a renderização. Então, para a maioria desses sites, o texto existe, e um visitante em um navegador o vê. Ele simplesmente não está no HTML que o servidor envia, que é a única parte que um crawler que não renderiza lê. As cinco que ficaram abaixo de 50 palavras eram uma tela de login, uma página que renderizou em branco e três páginas muito curtas. Essas são pobres para todos, não apenas para crawlers.

Um achado paralelo: algumas proteções contra bots também bloqueiam o crawler

Três sites responderam à nossa requisição OAI-SearchBot com HTTP 403 e responderam à mesma requisição com um user agent do Chrome com 200. Dois deles retornaram um desafio do Cloudflare (cf-mitigated: challenge). Nenhum dos seus arquivos robots.txt proibia crawlers de IA, então os proprietários provavelmente não pretendiam bloqueá-los.

Não podemos dizer a partir disso se o crawler real da OpenAI está bloqueado. Proteções contra bots como a do Cloudflare podem reconhecer bots verificados por seus endereços IP, e nossas requisições não vieram da OpenAI. Trate isso como um motivo para verificar: se você usa Cloudflare, confira as configurações de crawler de IA e de combate a bots no painel e confirme se elas correspondem ao que seu robots.txt diz.

Verifique seu próprio site em dois minutos

  1. Busque-o da forma como um crawler faz.

    UA='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)'
    curl -sL -A "$UA" -o raw.html -w '%{http_code}\n' https://yoursite.com
    grep -c 'a sentence from your hero section' raw.html

    Um status diferente de 200 geralmente significa que o crawler recebe uma página de erro ou de desafio em vez do seu conteúdo. Uma contagem de 0 significa que essa frase exata não está no HTML. Escolha uma frase curta, já que a marcação pode dividir uma longa.

  2. Veja a página sem JavaScript. No Chrome DevTools, abra o menu de comandos (Ctrl+Shift+P ou Cmd+Shift+P), execute "Disable JavaScript" e recarregue. O que você vê é aproximadamente o que um crawler que não renderiza lê.

  3. Verifique o Google separadamente. A Inspeção de URL do Search Console mostra o HTML que o Googlebot renderizou. Ela informa apenas sobre o Google.

  4. Repita para suas páginas de preços e de recursos, não apenas a página inicial. Essas são as páginas que um assistente precisa para descrever seu produto.

Como corrigir, por stack

StackO que o servidor envia por padrãoCorreção
SPA com Vite ou Create React AppUm <div> raiz vazioPré-renderize as rotas de marketing no momento do build, ou mova-as para um framework que renderiza HTML no servidor ou no build
React Router v7Depende do modoUse o modo framework com renderização no servidor ou prerender para rotas públicas
Next.js App RouterHTML renderizado no servidor; páginas são Server ComponentsMantenha o texto principal fora de componentes client que buscam dados após a montagem
Nuxt, SvelteKitHTML renderizado no servidorVerifique se o SSR não foi desativado (ssr: false) para páginas públicas
Astro, Framer, Webflow, Wix, WordPressHTML estático ou renderizado no servidorGeralmente está tudo bem; verifique a proteção contra bots e se o texto não é carregado por um script

Três regras se aplicam seja o que for que você use:

  • Coloque os fatos na primeira resposta. Isso significa o nome do produto, o que ele faz, para quem é, preços e os principais links, no HTML que o servidor retorna.
  • Sirva aos bots a mesma página que às pessoas. O Google chama a renderização dinâmica, uma versão pré-renderizada separada para crawlers, de "um contorno e não uma solução recomendada". O guia GEO da Microsoft diz: "Garanta que o DOM renderizado contenha os mesmos fatos que os consumidores veem — nunca sirva HTML diferente para bots."
  • Não pare no <head>. Um bom título e descrição ajudam com prévias de link. Eles não são suficientes para um crawler descrever seu produto.

Perguntas frequentes

O Google vê meu conteúdo renderizado no cliente? Geralmente, eventualmente. O Googlebot enfileira páginas para renderização e executa JavaScript com Chromium headless. Isso cobre o Google Search e o Gemini. Para ser um link de apoio nos AI Overviews, uma página "deve estar indexada e elegível para ser exibida no Google Search com um snippet", então renderização lenta ou com falha ainda pode custar caro lá. Isso não cobre ChatGPT, Claude ou Perplexity, cujos crawlers foram observados não renderizando.

Um <div id="root"> vazio é uma penalidade de ranking? Não. Nada o penaliza. O custo é que um crawler que não renderiza não tem nada para ler, então ele não pode citar ou descrever a página.

Meu site tem uma boa meta description. Isso não é suficiente? Ela dá ao crawler uma frase. Um assistente perguntado sobre o que seu produto faz, ou como ele se compara com uma alternativa, precisa do texto do corpo: recursos, preços, casos de uso.

Preciso reconstruir meu aplicativo? Geralmente não. Pré-renderizar as páginas públicas, como as páginas inicial, de preços, de recursos e de documentação, é suficiente. O aplicativo logado pode continuar renderizado no cliente.

Corrigir isso fará com que eu seja citado pelo ChatGPT? Ninguém pode prometer isso. Ser legível é uma precondição. Se você é citado depende do que outras fontes dizem sobre você e de quão bem sua página responde à pergunta. Nosso manual de otimização para busca em IA cobre o resto.

Leitura relacionada

Fontes


Todo produto no aat.ee recebe uma página de listagem permanente, renderizada no servidor, para que os crawlers possam ler uma descrição do seu produto mesmo antes de seu próprio site estar pronto para eles. Envie seu produto, ou veja as opções de listagem.

Criou algo novo?

Lance na aat.ee e seja descoberto

Listagem dofollow permanente em um diretório indexado
Nomeado e citado por assistentes de IA
Envie seu projeto