O fato
Em meados de 2026, nenhum dos principais crawlers de IA renderiza JavaScript. A lista inclui GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent e CCBot.
Uma análise de mais de 500 milhões de fetches do GPTBot não encontrou nenhuma evidência de execução de JavaScript. Não é limitação parcial nem fila de renderização atrasada, como acontece com o Google. É ausência de capacidade: o bot baixa o HTML que o servidor devolveu, e acabou.
Consequência direta: se o conteúdo da sua página aparece só depois que o JavaScript monta os componentes e resolve as chamadas de API, esse conteúdo não existe para ChatGPT, Claude ou Perplexity. Não é que ele seja mal interpretado. Ele não chega.
Por que o Googlebot confunde todo mundo
Aqui está a raiz do mal-entendido. O Googlebot renderiza JavaScript. Ele usa um motor baseado em Chrome headless, executa o script, espera o DOM estabilizar e indexa a página renderizada. Isso funciona há anos, com atraso ocasional e algumas pegadinhas, mas funciona.
Então o time de engenharia testa no Search Console, vê a página renderizada corretamente na inspeção de URL, e conclui que renderização está resolvida. Está resolvida para o Google. Para os crawlers de IA, não é a mesma situação, e não dá para assumir equivalência.
Esse é o ponto que eu insisto mais em auditoria hoje, porque é uma daquelas coisas que passa despercebida por meses: o site vai bem no orgânico, a marca simplesmente não aparece em IA, e ninguém liga uma coisa à outra porque os relatórios são separados.
O que eles veem de verdade
Quando o GPTBot visita uma SPA em React, ele baixa o HTML que o servidor mandou. Numa aplicação com render no cliente, esse HTML costuma ser algo assim:
- Um
<div id="root"></div>vazio. - Algumas tags de
<script>apontando para bundles. - Talvez um título e uma meta description, se houver configuração de SSR parcial para tags.
Nenhum texto. Nenhum heading. Nenhum link interno. Do ponto de vista do modelo, essa URL é uma página em branco com um título. E aí você tem um problema difícil de enxergar: a página é indexada pelo Google, ranqueia razoavelmente, e é completamente invisível para o canal que mais cresce.
Quatro dos seis principais crawlers, incluindo GPTBot, ClaudeBot, PerplexityBot e CCBot, buscam apenas HTML estático. Isso faz da renderização no servidor um requisito, não uma otimização.
Como testar o seu site
O teste é simples e leva cinco minutos. Compare o que o servidor entrega com o que o navegador mostra.
Primeiro, pegue o HTML bruto, sem executar nada:
Depois abra o arquivo e procure pelo texto principal da página. Se o parágrafo de abertura, os subtítulos e os links internos não estiverem lá, você achou o problema.
Um teste rápido que uso para dimensionar: contar palavras no HTML bruto e comparar com o conteúdo renderizado. Se o bruto tem 200 palavras e a página tem 1.800, existe uma lacuna de 1.600 palavras que os crawlers de IA nunca vão ver.
Vale rodar isso em três tipos de página diferentes, porque é comum a home ser server-side e as páginas internas não, ou o oposto.
As soluções, por custo
Geração estática, quando dá
Para conteúdo que não muda a cada request, como blog, páginas de serviço e institucional, gerar HTML estático no build resolve tudo de uma vez. É a opção mais barata de operar, a mais rápida para o usuário e a mais confiável para qualquer crawler. Este site é HTML estático, e essa foi uma decisão consciente.
Renderização no servidor
Para aplicações com conteúdo dinâmico, SSR entrega o HTML montado na primeira resposta. Next.js, Nuxt, SvelteKit e Remix já trazem isso pronto. O custo é de infraestrutura e de complexidade no time, e é uma migração que costuma levar um trimestre em projeto de porte médio.
Renderização dinâmica para bots
Entregar HTML pré-renderizado quando o user-agent é bot e a versão normal para o usuário. Funciona, mas é a opção que menos gosto: adiciona uma camada que quebra silenciosamente, e você só descobre quando alguém vai procurar. Se for usar, monitore com alerta automático, algo que dá para montar em n8n como descrevo em monitorar visibilidade em IA com n8n.
Hidratação parcial e ilhas
Arquitetura em que o conteúdo vem no HTML e só os componentes interativos são hidratados no cliente. É o melhor equilíbrio para site de conteúdo com pedaços dinâmicos, e é para onde o mercado está indo.
Armadilhas comuns
Conteúdo em tab ou acordeão carregado sob demanda. Se o texto só entra no DOM quando o usuário clica, ele não está no HTML inicial. Coloque no HTML e esconda com CSS, que é a diferença entre invisível e presente.
Scroll infinito sem paginação real. Sem URLs paginadas servindo HTML, os itens depois do primeiro lote não existem para nenhum crawler.
Conteúdo injetado por ferramenta de terceiro. Avaliação de produto, comentário, tabela de preço vinda de widget. Tudo isso costuma ser cliente-side e some.
Dados estruturados injetados por JavaScript. O Googlebot lê, os crawlers de IA não. Se o seu JSON-LD é inserido por tag manager, ele não chega em quem mais precisaria dele. Vale conferir junto com o que descrevo em dados estruturados como sinal de entidade.
Consent banner bloqueando conteúdo. Se o texto só renderiza após aceitação de cookie, o bot fica na tela de consentimento.
Diagnóstico completo
O teste rápido do curl responde sim ou não. Para dimensionar o problema e priorizar, vale um diagnóstico mais estruturado.
Amostragem por tipo de página
Escolha de três a cinco URLs de cada tipo: home, categoria, produto ou serviço, artigo, e página de conversão. É comum encontrar comportamento diferente entre elas, porque a migração para SSR costuma ter sido parcial.
Métrica de cobertura
Para cada URL, compare a contagem de palavras do HTML bruto com a do conteúdo renderizado. Uma forma rápida no terminal:
Compare com o número de palavras que você conta na página aberta no navegador. Uma razão abaixo de 0,5 indica que metade do conteúdo não chega ao crawler. Abaixo de 0,2, a página é praticamente vazia para ele.
Verifique os elementos críticos, um a um
Além do texto, confirme no HTML bruto:
titlee meta description.h1e a hierarquia de headings.- Os links internos de navegação, porque sem eles o crawler não descobre o resto do site.
- O JSON-LD, que é onde mais vejo problema, porque muita gente injeta por tag manager.
- Em e-commerce: preço, disponibilidade e avaliação.
Priorize por valor
Não adianta listar 4 mil URLs quebradas. Cruze o resultado com as páginas de maior valor comercial e com as que já têm impressão em recursos de IA no Search Console. A interseção é onde você começa.
Planejando a migração
Se o diagnóstico apontar renderização no cliente em páginas importantes, a correção é um projeto, não uma tarefa. Como costumo sequenciar:
Fase 1, o que é estático vira estático. Blog, páginas institucionais, páginas de serviço, landing pages. Geração estática no build, sem depender de runtime. Costuma cobrir de 30% a 60% das URLs de valor e é a fase mais barata.
Fase 2, o que é dinâmico e público ganha SSR. Categoria, produto, listagem. Aqui entra decisão de infraestrutura e cache, e é onde o custo aparece.
Fase 3, o que é privado fica como está. Área logada, painel, checkout. Não precisa ser rastreável e não vale o esforço.
Um erro de sequenciamento que vejo: começar pela parte mais complexa, o catálogo dinâmico, porque é onde está a receita. O problema é que essa é a fase que trava, e o projeto morre antes de entregar as vitórias fáceis. Comece pelo estático, mostre resultado, compre credibilidade para a fase 2.
Alternativa quando não há orçamento: se a migração não cabe no ano, pelo menos garanta que o conteúdo essencial de cada página venha no HTML inicial, mesmo que o resto seja hidratado depois. Título, descrição, o primeiro bloco de texto e os links de navegação já mudam bastante o cenário.
Um caso de e-commerce
Vale contar um caso porque ele mostra como o problema se esconde.
Uma loja de médio porte, catálogo em React com renderização no cliente e SSR só na home. O orgânico ia bem: o Googlebot renderiza, o site tinha bom desempenho na busca, e ninguém tinha motivo para desconfiar de nada.
A questão apareceu quando o time perguntou por que a marca nunca aparecia em recomendação de produto no ChatGPT, enquanto dois concorrentes menores apareciam. O teste do curl numa página de produto devolveu 34 palavras: o nome do site, o menu e um div vazio. Nem o nome do produto estava lá.
Ou seja, para qualquer sistema generativo, aquele catálogo inteiro não existia. Não era questão de otimização de conteúdo, de schema ou de autoridade. O conteúdo não chegava.
A correção priorizada foi entregar no HTML inicial o nome do produto, a descrição curta, o preço, a disponibilidade e as especificações principais, mantendo o resto da experiência como estava. Não foi uma reescrita da aplicação, foi mover cinco campos para a resposta do servidor.
Duas lições que levo desse caso. A primeira é que o problema é invisível para todos os relatórios que a equipe olhava. A segunda é que a correção mínima viável costuma ser bem menor que a migração completa que o time imagina quando o assunto aparece pela primeira vez.
Se o seu catálogo está nessa situação, o contexto comercial está em ChatGPT Shopping e o e-commerce, e o trabalho técnico é o que faço em SEO técnico.
Conclusão
Esse é, na minha opinião, o problema técnico mais caro e menos discutido de 2026. Ele não aparece no Search Console, não gera alerta, não derruba ranking. Simplesmente mantém a sua marca fora de um canal inteiro, em silêncio, enquanto todo mundo discute prompt e ferramenta de monitoramento.
E a correção não é sofisticada. É entregar HTML. A mesma coisa que a gente fazia em 2005, e que uma década de arquitetura de front-end nos convenceu a parar de fazer.
Se quiser diagnosticar isso no seu site, faz parte de SEO técnico, e se o problema for de arquitetura de front-end, é o que trato em desenvolvimento front-end.