Um site de ecommerce perdeu 47% da sua visibilidade na pesquisa por IA depois de uma atualização ter alterado a forma como as páginas são renderizadas. As mesmas páginas de produto continuavam bem posicionadas no Google. Mas o ChatGPT, o Claude e o Perplexity devolviam zero resultados. A diferença foi a renderização JavaScript.
Isto acontece a todos os sites que dependem de renderização no cliente. Uma landing page de SaaS feita com Vue.js nunca aparece nas respostas do ChatGPT. Um site de notícias a funcionar sobre uma framework JavaScript tem presença zero no Perplexity. Uma base de conhecimento que renderiza o conteúdo com React fica invisível para os rastreadores de IA. Não são casos raros. É o comportamento por defeito da maioria das frameworks web modernas.
A diferença entre um site movido a JavaScript e um site visível para a IA não tem que ver com complexidade nem com orçamento. Tem que ver com perceber o que acontece nos primeiros milissegundos em que um rastreador chega.
O que os rastreadores de IA veem quando vão buscar a tua página
O rastreador do Google executa JavaScript. Espera que a página seja renderizada, capta o estado visual final e indexa-o. A maioria dos rastreadores de IA não faz isso.
Quando o rastreador do ChatGPT (GPTBot) chega ao teu site, a sequência é esta: 1. Vai buscar o ficheiro HTML 2. Extrai o texto visível nesse HTML em bruto 3. Passa à página seguinte
O JavaScript que renderiza o teu título, a descrição do produto e o corpo do artigo nunca chega a correr. O rastreador vê as referências aos ficheiros JavaScript, mas ignora-as. A tua página aparece como uma casca sem conteúdo.
Isto acontece porque os rastreadores de IA foram concebidos para a velocidade e a eficiência. Executar JavaScript é lento. Exige arrancar um navegador, esperar que os recursos carreguem, tratar erros e gerir tempos limite. Quando se rastreiam milhares de milhões de páginas por dia, executar JavaScript torna-se proibitivamente caro.
O Google investe nessa infraestrutura porque os resultados de pesquisa dependem de perceber a renderização visual. Os motores de pesquisa por IA dão prioridade à extração de texto em bruto. Estão otimizados para retirar factos e citações diretamente do HTML, não do que aparece depois de o JavaScript o transformar.
Que renderizadores criam problemas aos rastreadores de IA
Nem todas as frameworks JavaScript causam a mesma perda de visibilidade. O problema está especificamente na renderização no cliente (CSR), em que o JavaScript corre *no navegador* e constrói a página depois de o HTML carregar.
Renderização no cliente (CSR): React, Vue, Angular, Svelte quando configurados para CSR. O HTML chega vazio ou com marcadores de carregamento. O JavaScript preenche o conteúdo depois de ser descarregado. Os rastreadores de IA não esperam.
Renderização no servidor (SSR): Next.js, Nuxt, Remix, SvelteKit. O servidor constrói a página com o conteúdo já inserido no HTML. O navegador recebe o HTML completo. Os rastreadores de IA veem tudo de imediato.
Geração estática (SSG): Geradores de sites estáticos. As páginas são construídas antecipadamente e publicadas como ficheiros HTML estáticos. Não há renderização no momento do pedido. Os rastreadores de IA recebem o conteúdo completo instantaneamente.
Aplicações de página única (SPA): A categoria de maior risco. Uma SPA carrega um único ficheiro HTML e usa JavaScript para trocar o conteúdo consoante a navegação. Todas as rotas parecem idênticas para um rastreador, a não ser que o servidor trate cada rota em particular.
No momento em que escolhes a CSR como estratégia de renderização, crias uma barreira invisível entre o teu conteúdo e todos os rastreadores de IA da internet.
Porque é que isto importa mais do que pensas
A pesquisa por IA ainda está no início, mas a adoção está a acelerar. Estudos mostram que as pesquisas por IA estão a crescer mais depressa do que as pesquisas web tradicionais. O ChatGPT, o Perplexity e o Claude estão a tornar-se ferramentas de pesquisa principais para profissionais, estudantes e decisores.
Quando alguém pergunta ao ChatGPT "melhores criadores de websites para pequenas empresas", a IA escolhe que marcas citar. Essa decisão depende do conteúdo que consegue ler. Se a tua página depende de JavaScript, é invisível.
Isto não é um problema do futuro. Uma análise de 2025 a mais de 500 milhões de pedidos do GPTBot concluiu que os sites dependentes de JavaScript recebiam significativamente menos citações do que os concorrentes renderizados no servidor no mesmo setor. A diferença aumentou nos conteúdos técnicos, nas páginas de produto e nos guias práticos, que são exatamente os tipos de conteúdo que os motores de IA priorizam.
Para as empresas B2B e de ecommerce, as citações em IA estão a tornar-se uma alavanca de visibilidade competitiva. Ser citado numa resposta do ChatGPT ou num excerto do Perplexity pode trazer o mesmo valor de tráfego que uma posição na primeira página do Google. Só que não podes ser citado se o rastreador não conseguir ler o teu conteúdo.
Como decidir o que fazer
Nem todos os sites precisam de abandonar a renderização no cliente. A decisão depende de três fatores: o teu tipo de conteúdo, o teu público e o valor de negócio da visibilidade na pesquisa por IA para a tua situação concreta.
Faz primeiro estas perguntas:
O teu conteúdo merece ser citado pela IA? Notícias, guias práticos, comparações de produtos, artigos de investigação, conselhos de especialistas. Estes são citados pela IA. Documentação técnica, ferramentas interativas, painéis que existem sobretudo para utilizadores com sessão iniciada. Estes não são. Se o teu site for sobretudo do segundo tipo, a renderização JavaScript importa menos.
O teu público pesquisa em motores de IA? Profissionais B2B, quem pesquisa produtos, estudantes, programadores. Usam muito a pesquisa por IA. Se o teu público é muito de nicho e pesquisa exclusivamente no Google, a visibilidade em IA tem um retorno menos imediato.
Qual é o custo de ser invisível? Para um site de notícias ou uma base de conhecimento, zero citações em IA é uma desvantagem competitiva. Para uma intranet de empresa ou um SaaS só para membros, é irrelevante. Para um site de ecommerce, depende de os teus clientes descobrirem produtos através de recomendações de compras por IA.
Se respondeste "conteúdo digno de citação em IA", "sim, o meu público usa a pesquisa por IA" e "perder visibilidade é um custo real", avança. Se as respostas forem mistas, talvez devas priorizar de outra forma.
Renderização no servidor: a solução mais completa
A SSR resolve o problema do JavaScript de forma abrangente. O servidor constrói a página completa, com todo o conteúdo, antes de a enviar ao navegador. Quando qualquer rastreador chega, o conteúdo já lá está.
Como funciona: Quando alguém (ou um bot) pede uma página, o teu servidor corre o teu código e produz o HTML final. Esse HTML inclui o teu título, o texto do artigo e os detalhes do produto. O navegador recebe uma página completa e renderiza-a de imediato. O JavaScript pode continuar a melhorar a interatividade, mas o conteúdo já está acessível.
Plataformas que tornam a SSR simples: Next.js (React), Nuxt (Vue), Remix, SvelteKit. Estas frameworks foram feitas precisamente para tornar a SSR descomplicada. Escreves os teus componentes uma vez, a framework trata da renderização no servidor e a página chega já construída.
O compromisso: A SSR exige recursos de servidor. O teu servidor processa cada pedido, constrói o HTML e envia-o. Isto consome mais CPU e memória do que servir ficheiros estáticos já construídos. Páginas lentas ou complexas podem aumentar o tempo de resposta, o que afeta métricas de desempenho como o First Contentful Paint (FCP) e os Core Web Vitals.
Na maioria dos sites, o impacto no desempenho é pequeno. Em sites de muito tráfego com páginas complexas, torna-se visível. Resolve-se com cache, edge computing ou otimização de código, mas exige decisões de arquitetura.
Pré-renderização: uma abordagem mais leve para conteúdo estático
A pré-renderização constrói as tuas páginas antecipadamente e publica-as como ficheiros HTML estáticos. Quando um rastreador chega, recebe uma página completa de imediato. Quando alguém visita, recebe um ficheiro estático que carrega muito depressa.
Existem serviços de pré-renderização que automatizam isto. Apontas o serviço para o teu site, ele visita todos os URLs do teu sitemap, renderiza cada página (executando o JavaScript), capta o HTML final e serve essas versões estáticas aos rastreadores, enquanto os navegadores continuam a receber a versão interativa.
Funciona se: O teu conteúdo muda pouco. Artigos de blogue, páginas de produto, documentação. Conteúdo que é atualizado talvez uma vez por dia.
Falha se: O teu conteúdo é dinâmico. Números de stock, dados específicos de cada utilizador, informação em tempo real, conteúdo personalizado. Se a tua página é diferente para cada visitante, a pré-renderização não capta todas as versões.
Custo e complexidade: Estes serviços custam $99-$499/mês consoante o volume de páginas. Manténs dois conjuntos de conteúdo: um para o navegador (JavaScript), outro pré-renderizado para os rastreadores. Isto duplica o trabalho de manutenção. Quando publicas um artigo novo, tens de reconstruir e voltar a publicar a versão estática.
Para sites com conteúdo estável, a pré-renderização é um meio-termo pragmático entre não fazer nada e migrar para SSR.
Renderização dinâmica: uma opção tática para alguns sites
A renderização dinâmica deteta que agente de utilizador está a fazer o pedido. Se for um rastreador, serve HTML renderizado no servidor. Se for um navegador, serve a versão JavaScript. Assim manténs a tua stack tecnológica atual e dás aos rastreadores o conteúdo completo.
Em teoria, a ideia é elegante. Na prática, é frágil. Tens de:
Manter uma lista de User-Agents de rastreadores de IA e atualizá-la constantemente à medida que surgem novos rastreadores. Se falhares um, esse rastreador vê a página em branco.
Construir renderização no servidor especificamente para os rastreadores, mantendo a renderização no cliente para os navegadores. Isto é, no fundo, construir duas versões do teu site.
Testar que as duas versões se mantêm sincronizadas. Um erro na versão dos rastreadores quebra, em silêncio, a tua visibilidade na pesquisa por IA.
A renderização dinâmica funciona em sites de conteúdo simples. Em aplicações complexas, dá mais trabalho do que compensa. Se vais renderizar no servidor para os rastreadores, mais vale renderizar para toda a gente (isso é SSR).
Como saber se o teu site tem este problema neste momento
Não precisas de adivinhar. Podes verificar diretamente.
Ver o código-fonte da página: Clica com o botão direito na tua página, escolhe "Ver código-fonte da página" e procura o teu título. Se o título não estiver no HTML em bruto, é renderizado por JavaScript. Os rastreadores de IA não o vão ver.
Ir buscar com curl: No teu terminal, corre curl https://yoursite.com/your-page. Se o conteúdo não estiver lá, foi o JavaScript que o renderizou.
Verifica o teu robots.txt: Se estás a impedir os rastreadores de executar JavaScript, só vão ver o HTML em bruto. Verifica o teu ficheiro robots.txt ou as definições de rastreio do teu site.
Usa uma ferramenta de rastreio: Um rastreador de SEO consegue ir buscar as tuas páginas como um rastreador o faria. Se o conteúdo aparece no navegador mas não no rastreador, o JavaScript é o culpado.
Pesquisa diretamente nos motores de IA: Pesquisa no ChatGPT, no Perplexity ou no Claude frases específicas das tuas páginas. Se o teu conteúdo nunca aparece, tens um problema de visibilidade causado pelo JavaScript.
Otimização específica por plataforma para diferentes rastreadores de IA
Nem todos os rastreadores de IA se comportam da mesma forma. Têm capacidades de renderização diferentes, frequências de rastreio diferentes e preferências de conteúdo diferentes.
ChatGPT (GPTBot): Não executa JavaScript. Vai buscar HTML em bruto. Usa o índice de um motor de pesquisa externo para conteúdo em tempo real. Frequência: mais ou menos semanal para conteúdo já estabelecido.
Claude (motor de pesquisa externo): Não executa JavaScript. Vai buscar HTML em bruto. Dá prioridade a conteúdo recente e com autoridade. Frequência: varia consoante os sinais de atualidade do conteúdo.
Perplexity: Não executa JavaScript. Vai buscar HTML em bruto. Dá muito peso à atualidade. O conteúdo com mais de 48 horas pode ser despriorizado. Frequência: alta para temas em tendência, baixa para conteúdo estático.
AI Overviews do Google: *Executam* JavaScript, porque usam a mesma infraestrutura de renderização da Pesquisa Google. Mas otimiza como se não executassem: ficarás mais visível para os outros motores de pesquisa por IA.
A conclusão prática: não otimizes para um só rastreador. Renderiza no servidor o teu conteúdo crítico e ficarás visível para todos.
Em que a WEMASY ajuda
O criador de websites da WEMASY produz HTML renderizado no servidor por defeito. Todas as páginas que crias são construídas com o conteúdo no HTML antes de chegarem ao navegador. Sem renderização JavaScript. As tuas páginas ficam visíveis de imediato para os rastreadores de IA.
Se estás a avaliar um criador de websites e a visibilidade na pesquisa por IA importa para o teu negócio, a renderização no servidor deve ser um requisito, não uma ideia de última hora. Vê o que está incluído em cada plano WEMASY.
Perguntas frequentes
Posso usar JavaScript para funcionalidades interativas sem bloquear os rastreadores de IA?
Sim. Renderiza no servidor o conteúdo principal (o título, o texto do artigo, os detalhes do produto) e usa JavaScript para os melhoramentos (animações, validação de formulários, widgets interativos). Chama-se "melhoria progressiva". O conteúdo já está no HTML e o JavaScript acrescenta o acabamento por cima. Os rastreadores de IA veem o conteúdo principal. Os navegadores recebem a experiência interativa completa. Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
Migrar para renderização no servidor vai tornar o meu site mais lento?
Pode, se o teu servidor for pouco potente ou as tuas páginas forem complexas. A renderização no servidor moderna, com camadas de cache (como a cache de borda em plataformas de alojamento modernas), pode até ser mais rápida do que a renderização no cliente. A diferença é pequena na maioria dos sites. Se o desempenho te preocupa, testa num ambiente de teste antes de te comprometeres.
Preciso de mudar toda a minha stack tecnológica?
Se usas React, Vue ou outra framework JavaScript como CSR, migrar para Next.js, Nuxt ou uma framework SSR semelhante significa reescrever os teus componentes para funcionarem com renderização no servidor. Não é uma troca rápida. Se o teu site é novo, escolhe desde o início uma framework pensada para SSR. Se tens um site já estabelecido, a pré-renderização ou a renderização dinâmica podem ser mais práticas a curto prazo.
E se os rastreadores de IA passarem a suportar a execução de JavaScript?
É possível, mas não será em breve. Executar JavaScript é computacionalmente caro em grande escala. A menos que o valor de negócio das citações em IA justifique o custo da infraestrutura, os rastreadores vão continuar a ir buscar HTML em bruto. Por agora, renderiza o teu conteúdo no servidor e reduz o teu risco.
O problema de renderização JavaScript do meu site está a prejudicar o meu posicionamento no Google?
Não. O rastreador do Google executa JavaScript, por isso o teu posicionamento no Google não é afetado. O problema são os motores de pesquisa por IA, como o ChatGPT, o Claude e o Perplexity. Não executam JavaScript. Renderiza o teu conteúdo no servidor se quiseres visibilidade nos resultados de pesquisa por IA, não porque o Google o exija. É um problema separado do SEO.
Os sites de notícias têm o mesmo problema com JavaScript?
Sim, e muitas vezes passa despercebido. Um site de notícias feito sobre uma framework JavaScript que renderiza o conteúdo no cliente recebe zero citações em IA, mesmo que o conteúdo esteja publicado e indexado. Os editores de notícias descobriram isto por acaso, quando artigos bem posicionados no Google Notícias tiveram zero menções no ChatGPT ou no Perplexity. Verifica o código-fonte da página. Se o teu título não estiver lá, corrige.