A maioria dos crawlers de IA não executa JavaScript. Isso significa que, se o conteúdo da sua página só aparece depois que o JS roda no navegador, o robô que indexa para o ChatGPT, o Perplexity ou o Gemini chega na URL e encontra um HTML quase vazio: a estrutura do documento sem o texto que importa. Para o crawler, a página existe; para a IA, o conteúdo não está lá.
Esse ponto é diferente do problema de permissão de acesso, que você resolve no robots.txt. Como deixar seu site rastreável pelos crawlers de IA cobre o portão de entrada: liberar o GPTBot para acessar as URLs. Este artigo começa depois disso. O crawler entrou, mas o que ele encontra depois de entrar? Se o seu blog, a sua página de produto ou a sua seção de perguntas frequentes depende de JavaScript para aparecer, uma parte importante do conteúdo fica invisível para as IAs que poderiam citá-lo.
Como verificar se o conteúdo chega ao crawler sem JavaScript
A verificação mais direta não usa ferramenta nenhuma. Abra o navegador, entre no site e use a opção "Ver código-fonte" (no Chrome: Ctrl+U no Windows ou Cmd+U no Mac; no Firefox e no Edge o atalho é o mesmo). O que aparecer ali é o HTML que o servidor entregou antes de qualquer JavaScript rodar. Se o conteúdo principal da página, o texto do artigo, a descrição do produto, o FAQ, está visível nesse código-fonte, o crawler vai conseguir ler. Se você encontrar apenas tags <div> vazias ou mensagens como "loading...", o conteúdo depende de JS para existir.
Uma alternativa por linha de comando confirma o mesmo ponto de forma inequívoca:
curl -s https://seusite.com.br/pagina-importante/ | grep "trecho do seu conteudo"
Se o trecho aparecer no resultado, o servidor está entregando HTML completo. Se não aparecer, o texto existe só depois que o JavaScript executa no navegador.
O DevTools do navegador (F12 ou "Inspecionar") não serve para esse diagnóstico. Ao abrir as ferramentas de desenvolvedor, você está vendo o DOM renderizado, que já inclui tudo que o JavaScript modificou. É a visão do navegador depois da renderização completa, não a visão do crawler ao chegar na página. "Ver código-fonte" e curl mostram o HTML original do servidor: o mesmo documento que o robô de IA recebe.
O que são SPA, SSR e SSG, e o que muda para o crawler?
Três arquiteturas definem o que o crawler encontra ao acessar uma URL.
Uma SPA (Single Page Application) é um site em que todo o conteúdo é montado pelo JavaScript no navegador. O servidor entrega um arquivo HTML mínimo com uma <div> de ancoragem e um bundle de script; o JavaScript preenche o restante. React, Vue e Angular sem configuração adicional produzem SPAs por padrão. O usuário vê a página completa; o crawler recebe o esqueleto.
SSR (Server-Side Rendering, ou renderização no servidor) significa que o servidor monta o HTML completo antes de enviá-lo ao cliente. Quando o crawler acessa a URL, o texto já está no HTML, sem depender de mais nada. Frameworks como Next.js e Nuxt.js oferecem SSR como opção nativa.
SSG (Static Site Generation, ou geração estática) vai além: o HTML de cada página é gerado em tempo de build, quando você publica uma atualização, e servido como arquivo estático. O rastreamento é mais simples ainda, porque não há computação no servidor durante o acesso. Blogs e sites de documentação com baixa frequência de alteração se encaixam bem nesse modelo.
| Técnica | O que o crawler de IA recebe |
|---|---|
| SPA pura (React, Vue ou Angular sem SSR) | HTML mínimo com <div> de ancoragem, conteúdo ausente |
| SSR (renderização no servidor) | HTML completo com o texto visível desde as primeiras linhas |
| SSG (geração estática) | HTML completo pré-gerado em build time, servido como arquivo estático |
| Pré-renderização | HTML estático servido para bots, página dinâmica servida para usuários |
Quando a dependência de JavaScript prejudica a visibilidade nas IAs?
A resposta depende do que está por trás do JavaScript. Nem toda dependência de JS é crítica. O que importa é se o conteúdo principal da página, aquele que você quer que a IA leia e possivelmente cite, só existe depois que o script roda.
Os casos onde o impacto é direto:
Páginas de produto construídas como SPA. O nome, a descrição, o preço e as avaliações ficam invisíveis para o crawler. A IA não tem material para citar o produto nem para confirmar a existência da marca naquele contexto.
Blogs e artigos gerados via JavaScript. O texto do artigo não chega ao robô. Por mais que o conteúdo seja bem escrito e estruturado segundo os padrões de conteúdo que as IAs escolhem citar, ele simplesmente não aparece no HTML que o crawler processa.
Páginas de FAQ montadas dinamicamente. O formato de pergunta e resposta é especialmente valorizado pelos modelos de linguagem para extração de resposta direta. Se o FAQ aparece só depois de o JS carregar, esse sinal se perde.
Um detalhe que passa batido: headings gerados por JavaScript também somem do crawler. Se os títulos H2 e H3 da página aparecem via script, o robô lê o documento sem a estrutura que o orienta. A importância da hierarquia de headings para IA pressupõe que esses títulos estejam no HTML do servidor, e não só no DOM gerado pelo navegador. Vale também mencionar que menus de navegação gerados por JavaScript criam um problema lateral: quando o crawler não consegue seguir esses links, a fragmentação do site fica comprometida, e páginas inteiras podem nunca ser descobertas.
O que normalmente não afeta a visibilidade: seções de comentários, carregamento adicional por scroll infinito, contadores em tempo real e qualquer elemento interativo acessório ao conteúdo principal. A IA não espera receber esses elementos no HTML inicial.
Quais são as opções para corrigir o problema?
Não existe um único caminho: a escolha depende da tecnologia do site, do volume de páginas e de quanto a arquitetura pode ser alterada.
Migrar para SSR ou SSG é a solução mais completa. Se o site usa Next.js, Nuxt.js ou Astro, essas opções já vêm disponíveis de forma nativa: é uma questão de configuração, não de reescrever o projeto do zero. Se a base de código for uma SPA em React puro sem framework, a migração exige mais trabalho, mas os frameworks modernos permitem uma adoção incremental, migrando página por página.
Pré-renderização é o meio-termo para quem não pode alterar o servidor. Um serviço de pré-renderização detecta quando a visita vem de um crawler (pelo user-agent, como o GPTBot) e serve uma versão estática do HTML em vez da SPA dinâmica. O usuário recebe a versão JavaScript normalmente; o crawler recebe o HTML pronto. Funciona bem para sites com poucos templates e páginas que mudam com baixa frequência.
Ajustes cirúrgicos de arquitetura quando só parte das páginas tem o problema. Um blog rodando como SPA pode ser migrado para um gerador estático independente enquanto o restante do site fica inalterado. Páginas de produto prioritárias ganham SSR; a listagem geral fica dinâmica.
O que não resolve: injetar conteúdo via elementos ocultos (com display:none ou visibility:hidden) para tentar entregar texto ao crawler sem mostrá-lo ao usuário. Conteúdo oculto não é tratado como conteúdo principal pelos robôs de IA, e a técnica não resolve o problema de renderização.
O que não precisa de SSR
Antes de qualquer mudança, vale separar o que realmente precisa chegar ao crawler do que não precisa.
Painéis de usuário logado, dashboards internos, configurações de conta e qualquer página por trás de autenticação são invisíveis para crawlers por padrão, porque o robô não faz login. SSR nessas áreas não muda nada do ponto de vista de visibilidade em IA.
Formulários de contato, calculadoras interativas e ferramentas que dependem de input do usuário também não exigem SSR para fins de citação: o crawler não interage com eles, e a IA não cita campos de formulário.
Animações, carrosséis de imagem, widgets de redes sociais e contadores em tempo real são ornamentais. Se dependem de JavaScript, a ausência no HTML do crawler não afeta o que a IA pode citar sobre o site.
A prioridade vai para o conteúdo editorial: textos de produto, artigos, FAQ, páginas institucionais e qualquer conteúdo que você esperaria ver citado numa resposta de IA. É esse conteúdo que precisa chegar no HTML antes do JavaScript. O conjunto completo de ajustes técnicos nessa direção está no GEO técnico.
A auditoria de site da Promptis simula a leitura de um robô de IA e aponta onde o conteúdo principal depende de JavaScript, página por página. Você também pode conferir como auditar seu site para GEO para ver o checklist técnico completo além da renderização. A primeira análise é gratuita, sem cartão. Se você não sabe hoje se o seu blog ou as suas páginas de produto estão invisíveis para o GPTBot, esse é o ponto de partida mais direto para descobrir.
