O que os agentes de IA recebem mesmo: renderização e JavaScript

Vê uma página completa. O agente recebe um ficheiro HTML em bruto. Se o seu conteúdo é montado no browser por JavaScript, há uma hipótese real de que o que chegou ao outro lado tenha sido apenas uma casca vazia. A única medição pública que encontrei sobre isto — feita pela Vercel e pela MERJ em dezembro de 2024 — concluiu que nenhum dos principais crawlers de IA executa JavaScript: descarregam os ficheiros JS (11,50% dos pedidos do ChatGPT, 23,84% dos do Claude) mas nunca os executam. O Google é a exceção: renderiza com uma versão evergreen do Chromium, embora também pare aos 2 MB. O teste em si demora dois minutos e uma linha de curl.

A única pergunta que importa: o que está no HTML inicial?

Há uma diferença entre aquilo que o seu site mostra e aquilo que o seu site envia. O browser recebe um documento HTML, descarrega os ficheiros JavaScript, executa-os, faz mais chamadas à API e monta a partir de tudo isso a página que vê. Toda a cadeia acontece na máquina do utilizador, não no seu servidor. Um agente que pede o URL e fica por aí recebe apenas o primeiro passo.

Na maioria dos sistemas de gestão de conteúdos clássicos isto não é problema, porque o HTML chega do servidor já completo. A dificuldade começa quando o site é construído como uma aplicação do lado do cliente: React, Vue ou Angular a gerar o conteúdo depois do carregamento. Nesse caso, o documento que sai do seu servidor pode ser três kilobytes de etiquetas vazias com um <div id=”root”></div> no meio, sendo tudo o resto construído apenas no browser.

Um ponto merece destaque: isto não é uma questão de permissões. Pode dar a todos os bots acesso total, devolver 200 em todos os pedidos e ainda assim não aparecer em resposta nenhuma — simplesmente porque não havia conteúdo para ler. Analisei a camada das permissões em separado no mapa dos bots de 2026; esta é a camada que vem logo a seguir.

O que foi realmente medido — e o que não foi

O tema exige cuidado, porque está cheio de números que circulam sem fonte. O que existe: um estudo conjunto da Vercel e da MERJ publicado a 17 de dezembro de 2024, analisando logs reais de sites de grande dimensão. A conclusão central é que nenhum dos principais crawlers de IA — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot e outros — executa JavaScript. Descarregam os ficheiros JS mas não os correm. A exceção na lista deles é o AppleBot, que renderiza através de um browser.

O mesmo estudo dá também uma noção de volume: cerca de 569 milhões de pedidos mensais do GPTBot e à volta de 370 milhões do Claude, em conjunto aproximadamente um quinto do volume de pedidos do Googlebot nesse período.

O Google é a exceção, não a regra

O Google Search Central afirma explicitamente, numa página atualizada a 4 de março de 2026, que a Pesquisa Google executa JavaScript com uma versão evergreen do Chromium e que o Googlebot coloca em fila para renderização todas as páginas que devolvem o código de estado 200. No mesmo documento o Google acrescenta a ressalva mais relevante aqui: nem todos os bots conseguem executar JavaScript.

Vale a pena conhecer dois limites práticos do Google. Primeiro, segundo a documentação do Googlebot, o crawler obtém os primeiros 2 MB de um tipo de ficheiro suportado e para aí. Se o seu HTML for mais pesado, tudo o que passa desse corte simplesmente não é lido. Segundo, quanto às funcionalidades baseadas em IA, o Google afirma que não existem requisitos técnicos adicionais além de a página estar indexada e elegível para aparecer com um snippet. Nenhum ficheiro especial e nenhuma marcação dedicada: o que se lê bem na Pesquisa lê-se bem também aí.

Três padrões que esvaziam a página

Renderização do lado do cliente. O caso clássico. O documento vindo do servidor contém uma casca e o conteúdo carrega depois. Fácil de detetar: o código-fonte da página é muito mais curto do que aquilo que o olho vê.

Conteúdo que só abre com interação. Acordeões, separadores, «carregar mais», scroll infinito. Se o conteúdo só é injetado no DOM depois de um clique, não existe no documento. Se está no HTML e apenas escondido por CSS, está lá, e isso é perfeitamente aceitável.

Camadas bloqueadoras à frente do conteúdo. Um banner de cookies que exige consentimento antes de o conteúdo carregar, uma paywall, uma janela de login, ou uma camada de gestão de bots que devolve um challenge. Nesses casos o bot até recebe uma página — só que não é a sua.

Como verificar em dois minutos

Não é preciso nenhuma ferramenta externa. Bastam três linhas para saber exatamente o que sai do seu servidor:

A interpretação é simples. Se a linha 2 devolver um número próximo da contagem de palavras que vê na página, está tudo bem. Se devolver 40 palavras para uma página de 1.200 palavras, o conteúdo está a ser construído no browser. Se a linha 3 devolver 0, a sua frase central não existe em nenhuma resposta que venha alguma vez a ser gerada a partir dessa página. Vale também a pena repetir a mesma verificação com um user-agent de browser normal e comparar: uma diferença grande entre os dois indica um servidor a servir conteúdo diferente aos bots.

Como confirmar que o bot é genuíno

Antes de tirar conclusões do seu log, certifique-se de que quem dizia ser o GPTBot é mesmo o GPTBot. Todos os grandes fornecedores publicam listas oficiais de endereços IP, e o Google publica ainda um método de verificação por DNS inverso:

O Google é o único dos quatro a oferecer verificação por DNS inverso. Com os restantes, comparar o IP com a lista oficial é a única verificação disponível. Vale a pena obter estes ficheiros automaticamente em vez de copiar as gamas à mão — elas mudam.

O que fazer quando a resposta é «a página está vazia»

A correção depende da arquitetura, mas a direção é a mesma em todos os casos: mover a montagem do conteúdo do browser para o servidor.

1. Renderização do lado do servidor ou geração estática. Nas frameworks modernas isto é uma definição página a página, não uma reescrita. O resultado é HTML completo logo na primeira resposta, o que também melhora o tempo de carregamento para os utilizadores humanos.
2. Garanta que o conteúdo principal não depende de interação. Um acordeão cujo conteúdo está no HTML e é escondido por CSS é uma solução perfeitamente válida. Um acordeão que vai buscar o conteúdo ao clique não é.
3. Verifique o que acontece antes do consentimento. Se o banner de cookies bloqueia o conteúdo até haver clique, o bot não vê nada. O conteúdo tem de estar no documento mesmo quando nada foi clicado.
4. Meça outra vez; não presuma. Depois de cada alteração, a mesma linha de curl. A verificação demora segundos, e presumir que funcionou é exatamente o que criou o problema logo de início.

E se a questão mais ampla lhe interessa — o que um agente de IA lê de facto no seu site antes mesmo de se pôr a questão da renderização — escrevi sobre isso na camada de descoberta.

Uma ordem de prioridades prática

Se tem uma hora, esta é a ordem que recomendo. Primeiro, corra a verificação curl nas três páginas mais importantes do site — a página inicial, a página de serviço principal e o artigo com mais tráfego. Depois compare a contagem de palavras com o que está efetivamente visível. Só se houver diferença é que faz sentido abrir a questão da arquitetura. Na maioria dos sites WordPress e dos sites institucionais a resposta será que está tudo bem, e isso é um excelente resultado — mais vale saber do que passar um mês a resolver um problema que não tem.

Perguntas frequentes