A IA renderiza JavaScript?

#A IA renderiza JavaScript

Para os engenheiros de pesquisa isto não é uma ideia nova, mas até agora era argumento e não prova. Agora foi testado diretamente, e a prova é incómoda para a grande classe de sites construídos como aplicações JavaScript que montam o seu conteúdo no navegador.

#Como testar se assistentes de IA renderizam JavaScript no site

O teste, feito por Andre Alpar e publicado em junho de 2026 no Search Engine World, foi simples e difícil de enganar. A página servia um número de referência engodo no HTML em bruto. O número real só era substituído por JavaScript externo, obtido de um segundo endpoint, e não aparecia em lado nenhum do HTML nem do código do script. Cada um dos doze assistentes recebeu o seu próprio URL, sem ligações de lado nenhum e impossível de adivinhar, para que cada acesso ao servidor pudesse ser atribuído a um único assistente, e o servidor registou três eventos separados: a obtenção da página, a obtenção do ficheiro JavaScript e a chamada ao endpoint do número. A lógica é à prova de falhas. Devolver o número real significa que executou o script. Devolver o engodo significa que leu apenas o HTML.

A obtenção era desencadeada pelo utilizador. Alpar colou cada URL à mão no chat e pediu ao assistente que resumisse a página e indicasse o número de referência interno. O teste mede, portanto, o que acontece quando uma pessoa entrega um link a um assistente, e não o que um crawler em segundo plano faz segundo o seu próprio calendário. O autor nomeia os limites: é “um teste de passagem única, com obtenção em direto: um prompt por assistente, captado num único momento”, e os crawlers em segundo plano, como o GPTBot e o ClaudeBot, “podem perfeitamente comportar-se de outra forma” (tradução própria). Leia o resultado como um retrato nítido do percurso de resposta em direto em junho de 2026, e não como uma propriedade permanente de cada produto.

#Que assistentes de IA leem apenas o HTML em bruto

No teste de Alpar, estes assistentes devolveram o engodo, ou seja, basearam o grounding no HTML em bruto e nunca correram o script:

• ChatGPT
• Claude
• Gemini
• Perplexity
• Meta AI
• Microsoft Copilot

O Grok executou o JavaScript num nó, mas ainda assim devolveu o engodo, por isso mesmo onde o script correu, o valor renderizado não chegou à resposta.

Três detalhes dos registos do servidor tornam o quadro mais preciso. Entre os sistemas norte-americanos que não renderizaram, o Microsoft Copilot foi o único que descarregou o ficheiro JavaScript, através do scraper externo Diffbot, mas nunca fez a chamada seguinte para obter o número e devolveu o engodo. O Gemini, que Alpar chama a surpresa por vir da Google, também não renderizou. A resposta do Perplexity afirmou que não conseguia aceder à página, embora o seu crawler a tivesse obtido com HTTP 200. Daí o conselho de Alpar: confie no registo do servidor, nunca no relato do chatbot sobre o que fez.

Glenn Gabe, da GSQi, repetiu a pergunta em cinco plataformas e publicou o resultado a 19 de outubro de 2026. O ChatGPT, o Claude e o Perplexity falharam os três testes. O Gemini e o Copilot passaram os dois primeiros: uma página cujo conteúdo é todo carregado por JavaScript e uma página com cabeçalho e rodapé estáticos, mas conteúdo em JavaScript. No terceiro teste, um site com efeito parallax construído em WebGL, o Gemini leu o conteúdo e o Copilot não. Gabe explica-o diretamente: “O Gemini recorre aos sistemas de pesquisa da Google, por isso consegue ver conteúdo renderizado através de JavaScript” (tradução própria). O êxito do Copilot é atribuído da mesma forma aos sistemas de pesquisa do Bing.

Os dois resultados podem ser verdadeiros ao mesmo tempo. Alpar deu a cada assistente um URL novo, sem ligações em lado nenhum, que nenhum motor de pesquisa tinha indexado, por isso o Gemini e o Copilot tiveram de obter o HTML em bruto como os restantes. Gabe testou sites existentes que a Google e o Bing já conheciam, pelo que o Gemini e o Copilot podiam recorrer à versão renderizada pelo motor de pesquisa. Para uma página nova, até um motor de pesquisa a renderizar, vale o resultado de junho. O ChatGPT, o Claude e o Perplexity leram apenas o HTML nos dois testes.

#Que assistentes de IA executam JavaScript

Cinco assistentes devolveram o número real, provando que executaram o script:

• DeepSeek, ERNIE, Qwen e Kimi, todos da China
• Mistral, da Europa

O DeepSeek desta lista é o chat. Suganthan Mohanadasan testou outro caminho da mesma empresa, a Fetch API da pesquisa do DeepSeek, e descreveu o teste a 19 de outubro de 2026. No teste de renderização, o fetcher carregou o CSS, mas não executou JavaScript, não carregou imagens nem disparou o beacon XHR, por isso o conteúdo que precisava do script não apareceu no resultado. Identificou-se como Firefox/149.0 a partir da rede AS136907 (Huawei Cloud, Hong Kong), sem nada que nomeasse o DeepSeek, e obteve URLs bloqueados no robots.txt. O teste inteiro, 110 chamadas, custou cerca de 0,08 USD. O chat do DeepSeek e a sua API de obtenção de páginas são simplesmente dois caminhos diferentes até ao seu HTML, e nestes testes só o chat executou o script.

A renderização de JS pela IA está de facto a acontecer. Acontece que, para os grandes assistentes ocidentais com que as empresas europeias realmente se preocupam, é a exceção numa obtenção em direto, e o Gemini e o Copilot só veem conteúdo em JavaScript através do índice do seu motor de pesquisa. A divisão é nítida o suficiente para se planear em torno dela: construa para os assistentes que os seus clientes usam, e hoje esses leem HTML.

#O que o estudo da Vercel revelou sobre crawlers de IA e JavaScript

O teste de junho de 2026 não é a primeira medição a apontar neste sentido. Em dezembro de 2024, a Vercel, em conjunto com a MERJ, publicou uma análise do tráfego de crawlers de IA na sua rede e concluiu que “nenhum dos principais crawlers de IA renderiza JavaScript atualmente” (tradução própria). O ChatGPT e o Claude pediam ficheiros JavaScript, 11,50% e 23,84% dos seus pedidos, respetivamente, mas não os executavam. No mês medido, o GPTBot fez 569 milhões de pedidos, o Claude 370 milhões e o PerplexityBot 24,4 milhões, contra 4,5 mil milhões do Googlebot somando o Gemini e a pesquisa. O ChatGPT gastou 34,82% dos seus pedidos em páginas 404 e o Claude 34,16%.

A Vercel indicou dois crawlers que renderizam: o AppleBot, através de um crawler baseado em navegador semelhante ao Googlebot, e o Gemini, por usar a infraestrutura do Googlebot. Este segundo ponto choca com o resultado de Alpar em 2026, em que o Gemini devolveu o engodo. As duas medições observam percursos diferentes, o rastreio em segundo plano na rede da Vercel e uma obtenção em direto provocada pelo prompt de um utilizador, e essa diferença é a lição: o facto de a Google renderizar a sua página para o índice diz pouco sobre o que o Gemini lê enquanto responde a uma pergunta. A recomendação da Vercel coincide com o resto deste artigo: renderize no servidor o conteúdo principal, a meta-informação e a navegação, e deixe a renderização no cliente para funcionalidades que apenas enriquecem a página.

#O Google renderiza JavaScript de forma diferente dos assistentes de IA

Esta é a objeção que descarrila toda a conversa, por isso enfrente-a de frente. Sim, o Googlebot renderiza JavaScript para o índice de pesquisa clássico. Isso é um pipeline separado do grounding das respostas de IA, e o teste é sobre o segundo. Uma página pode classificar perfeitamente na pesquisa clássica do Google com conteúdo que só existe depois de o JavaScript correr, e ainda assim ser invisível quando o ChatGPT ou o Perplexity a obtêm para compor uma resposta. Tratar “o Google renderiza JS” como prova de que “a IA renderiza JS” é o erro. Os dois sistemas comportam-se de forma diferente, e é exatamente nessa lacuna que a visibilidade em IA se escoa em silêncio.

#O que diz a documentação da Google sobre SEO e JavaScript

A Google descreve o seu próprio processo nos princípios básicos de SEO para JavaScript: as aplicações web com JavaScript passam por três fases, rastreio, renderização e indexação. As páginas esperam numa fila de renderização antes de um Chromium sem interface executar o seu JavaScript, e a Google refere que uma página “pode ficar nesta fila alguns segundos, mas pode demorar mais do que isso” (tradução própria). A mesma página continua a recomendar a renderização no servidor ou a pré-renderização, porque é mais rápida para utilizadores e crawlers e porque “nem todos os bots conseguem executar JavaScript” (tradução própria).

Essa frase é a ponte para os assistentes de IA. A Google explica que se pode gerar JSON-LD com JavaScript e injetá-lo na página, e o Googlebot lê-o depois do passo de renderização. Alpar testou um número em texto visível, e não dados estruturados, mas o schema injetado por um script chega a um assistente pelo mesmo mecanismo, por isso um assistente que nunca executa o script nunca o vê. A documentação da Google foi escrita para o Googlebot. A camada de respostas de IA é o caso de “nem todos os bots”.

A página da Google sobre renderização dinâmica, atualizada pela última vez a 10 de dezembro de 2025, afasta o atalho de detetar bots e servir-lhes uma cópia renderizada no servidor enquanto os utilizadores recebem a versão renderizada no navegador. A Google chama-lhe uma solução provisória e não a recomenda, porque acrescenta complexidade e exige mais recursos, e indica em alternativa a renderização no servidor, a renderização estática ou a hidratação. A pré-renderização no momento da compilação, descrita mais abaixo, cabe na renderização estática, por isso todos os clientes, bots ou navegadores, recebem o mesmo HTML.

#Que padrões JavaScript escondem conteúdo dos assistentes de IA

O risco concentra-se num conjunto reconhecível de padrões:

• Aplicações single-page que enviam uma casca de HTML quase vazia e montam a página no navegador.
• Preços, estado de stock ou especificações injetados por JavaScript a partir de uma API depois do carregamento.
• Conteúdo escondido por trás de separadores, acordeões ou “carregar mais” do lado do cliente, que só é obtido na interação.
• Descrições de produtos ou serviços renderizadas por uma framework do cliente sem alternativa no servidor.
• Avaliações, classificações e widgets de FAQ incorporados como JavaScript de terceiros.

Se algum destes carrega os factos que quer que uma IA repita, está a apostar a sua visibilidade em IA num comportamento de renderização em que seis de sete assistentes ocidentais acabaram de falhar.

#Como tornar conteúdo JavaScript visível para a IA

O remédio é a regra que o SEO clássico repete há uma década: coloque os factos essenciais em HTML renderizado no servidor. A geração de sites estáticos e a renderização no servidor satisfazem-na ambas. A framework não importa, o que importa é onde o HTML é montado. Renderize o conteúdo no servidor, sirva-o na primeira resposta e deixe o JavaScript enriquecê-lo em vez de o fornecer.

Pode verificar o seu próprio site num minuto. Obtenha uma página sem navegador e leia o que volta:

curl -s https://o-seu-site.example/a-sua-pagina/ | less

Se os cabeçalhos, o texto, os preços, as especificações e o Schema.org JSON-LD estiverem todos nessa resposta em bruto, os assistentes de IA conseguem lê-los. Se a página for uma casca fina que se preenche depois de o script correr, esse é o seu problema, e agora consegue vê-lo.

#Que user agents usam os assistentes de IA para obter páginas

Os fornecedores documentam agentes separados para treino, indexação de pesquisa e obtenções desencadeadas pelo utilizador, e as regras de robots.txt diferem entre eles:

• OpenAI: o GPTBot rastreia conteúdo que pode ser usado para treinar modelos fundacionais, o OAI-SearchBot decide se um site pode aparecer nas respostas de pesquisa do ChatGPT, e o ChatGPT-User obtém páginas para ações do utilizador. O ChatGPT-User não é usado para rastrear a web de forma automática e, como as suas ações são iniciadas pelo utilizador, as regras de robots.txt podem não se aplicar. Cada definição é independente, e a OpenAI indica que uma alteração ao robots.txt pode demorar cerca de 24 horas a chegar aos resultados de pesquisa.
• Anthropic: o ClaudeBot recolhe dados de treino, o Claude-SearchBot indexa para a qualidade da pesquisa, e o Claude-User obtém páginas quando uma pessoa faz uma pergunta ao Claude. A Anthropic afirma que os seus bots respeitam o robots.txt e publica a lista de IP dos seus crawlers.
• Perplexity: o PerplexityBot mostra sites na pesquisa do Perplexity e não é usado para treinar modelos. O Perplexity-User suporta ações do utilizador e, como foi um utilizador a pedir a obtenção, em geral ignora o robots.txt.
• Google: o Google-Extended é um token de produto para robots.txt, e não um crawler separado. Controla o uso para o treino do Gemini e para grounding, não tem user agent HTTP próprio e não afeta a inclusão nem a classificação na pesquisa Google.

Nenhuma destas páginas promete renderizar JavaScript. Numa segunda experiência, sobre o robots.txt, Alpar verificou que só 3 de 12 assistentes deixaram em paz um URL bloqueado: o ChatGPT como ChatGPT-User, o Claude como Claude-User e o Perplexity como Perplexity-User. O Gemini chegou com um user agent simples, “Google”, o Copilot através do Diffbot com uma cadeia de Chrome comum, e o Grok, o DeepSeek, o Qwen e o Kimi com user agents de navegador falsificados. A consequência prática para a renderização: não é possível entregar de forma fiável aos assistentes de IA uma versão pré-renderizada especial detetando o user agent, por isso o HTML que todos recebem tem de transportar os factos.

#Como o WordPress serve conteúdo à IA sem JavaScript

Um tema clássico de WordPress está do lado seguro por defeito: o PHP constrói a página no servidor, por isso os artigos, as descrições de produtos e os preços da base de dados estão no HTML antes de qualquer script correr. O risco surge quando o conteúdo passa para widgets do lado do cliente, para blocos que obtêm dados pela REST API depois do carregamento ou para um frontend headless que só renderiza no navegador.

Para a interatividade, o WordPress tem uma resposta que mantém o conteúdo no servidor. A Interactivity API, introduzida no WordPress 6.5, usa diretivas na marcação de um bloco, e o seu processamento de diretivas no servidor permite ao WordPress gerar o HTML inicial com o estado correto. A função wp_interactivity_process_directives encontra as diretivas e usa a HTML API para reescrever a marcação a partir do estado inicial e do contexto. No exemplo da documentação, uma lista construída com data-wp-each e data-wp-text sai do servidor como itens de lista normais, com os nomes das frutas já preenchidos e sem diretivas. A página chega completa, o JavaScript acrescenta o comportamento depois, e um assistente que lê o HTML em bruto vê a mesma lista que um visitante. A documentação dá o motivo nas suas próprias palavras: a abordagem mantém “os benefícios de SEO e desempenho da renderização tradicional do WordPress no servidor” (tradução própria).

#Como HTML estático com Astro melhora a visibilidade em IA

Não somos neutros aqui, porque fizemos esta aposta de propósito. O wppoland.com corre em Astro, que renderiza as páginas para HTML estático em tempo de build e as serve a partir da edge. Tudo o que importa está na resposta em bruto: o texto, cada cabeçalho, o FAQ e o Schema.org JSON-LD. Verificámos da mesma forma que o teste, lendo o HTML em bruto em vez da página renderizada, e o conteúdo está todo lá antes de uma única linha do nosso JavaScript correr. O JavaScript nas nossas páginas é enriquecimento, nunca a fonte do conteúdo.

É a mesma conclusão a que chegámos pelo caminho longo em servir conteúdo a agentes de IA: HTML limpo, renderizado no servidor e semântico, mais Schema, é o único sinal que tanto os crawlers clássicos como os sistemas de IA realmente consomem. Este teste é a prova mais limpa até hoje a favor dessa posição. É também o motivo pelo qual um programa de GEO e LLMO tem de começar por como a página é renderizada, e não por metadados engenhosos, porque metadados que um assistente nunca executa são metadados que ele nunca lê.

#Renderização no servidor e no cliente explicada

Para leitores que gerem um negócio e não um pipeline de build:

• Renderização no servidor / geração estática - o HTML da página é montado no servidor (ou em tempo de build) e chega completo na primeira resposta.
• Renderização no cliente - o servidor envia uma casca quase vazia, e o JavaScript do navegador constrói a página depois.
• Grounding - quando um assistente de IA obtém páginas reais para fundamentar uma resposta em factos e não na memória.
• Hidratação - JavaScript que anexa interatividade a HTML já renderizado; seguro, porque o conteúdo estava lá primeiro.
• Pré-renderização - executar uma aplicação de cliente no momento do build para captar o seu estado inicial como HTML estático, segundo a definição do guia web.dev Rendering on the Web. O mesmo guia observa que os crawlers conseguem compreender JavaScript, “mas muitas vezes têm limitações na forma como renderizam” (tradução própria).

#Vale a pena esperar que a IA renderize JavaScript

A renderização de JavaScript pelos assistentes de IA provavelmente vai melhorar com o tempo, e os assistentes chineses mais o Mistral mostram que tecnicamente é rotina. Mas não pode publicar para os assistentes que gostaria que existissem. Publica para os que os seus clientes usam, e em junho de 2026 os maiores assistentes ocidentais leem HTML em bruto e param aí. A resposta segura, aborrecida e com uma década revela-se a correta também para a IA: sirva os seus factos em HTML que o servidor já renderizou, e trate tudo o que só aparece depois do JavaScript como conteúdo que a IA não verá.