A IA consegue ler sites feitos em JavaScript?

Porque é que a resposta não é simplesmente «sim» ou «não»?

Porque «a IA» não é um leitor só. Um pedido a uma página pode vir de pelo menos três tipos de programa com comportamentos diferentes: rastreadores de treino, que recolhem texto em massa; rastreadores de recuperação, que vão buscar uma página no momento em que alguém faz uma pergunta; e agentes que navegam com um navegador real. Os três leem o mesmo endereço e não veem necessariamente o mesmo documento.

Executar JavaScript custa tempo e dinheiro a quem rastreia, por página e à escala de milhões de páginas. Por isso a execução é, na prática, uma decisão de custo tomada por quem lê, e não uma garantia dada a quem publica. Um fornecedor pode executar scripts hoje em parte dos pedidos e deixar de o fazer amanhã sem avisar ninguém, e o site que dependia disso muda de estado sem uma única linha ter sido alterada.

A conclusão prática é assimétrica, e é o que torna a decisão fácil: conteúdo em HTML servido é lido por todos os leitores possíveis; conteúdo pintado por script é lido por alguns, sem que quem publica saiba quais nem por quanto tempo.

Que texto é que costuma estar em falta?

O padrão é constante: falta precisamente o que interessa a quem quer verificar a empresa. Os casos mais comuns num site de PME são a identificação legal e fiscal carregada de um ficheiro de configuração, os preços obtidos por chamada a uma interface depois de a página abrir, os horários e a morada inseridos por um componente de mapa, o catálogo de serviços dentro de separadores ou acordeões preenchidos ao clicar, e os testemunhos trazidos por um widget externo.

O que estes cinco casos têm em comum não é a tecnologia. É que todos eles são o conteúdo que responde às perguntas que um cliente faz a um modelo: quem é esta empresa, onde fica, quanto custa, o que faz, e alguém confia nela.

Como é que se verifica um site em dois minutos?

A verificação faz-se pedindo a página sem executar scripts e procurando nela o texto que devia lá estar. Num terminal, com curl:

# O texto aparece no HTML servido?
curl -s https://exemplo.pt/ | grep -c "512345678"

# Quantas palavras legíveis tem a página sem correr um único script?
curl -s https://exemplo.pt/ | sed 's/<[^>]*>/ /g' | wc -w

Um resultado de 0 na primeira contagem significa que o número de contribuinte não está no documento servido. Uma segunda contagem na ordem das dezenas de palavras, num site com páginas cheias, significa que quase todo o texto é pintado depois do carregamento.

Sem terminal, há duas verificações equivalentes. A primeira é desligar o JavaScript nas definições do navegador e recarregar a página. A segunda é colar o endereço numa aplicação de mensagens e olhar para a pré-visualização: o cartão que aparece é montado a partir do HTML servido, e uma pré-visualização vazia ou genérica é o mesmo sinal.

Corrigir isto obriga a refazer o site?

Não na maioria dos casos. O trabalho é mover o texto que importa, não trocar a tecnologia. Um site construído com uma biblioteca moderna continua a poder escrever no documento servido os factos verificáveis sobre a empresa: nome legal, número de contribuinte, morada, telefone, atividade, zona e preços de tabela.

Foi essa a correção que a WrightGate fez ao próprio site a 29 de agosto de 2026. Os nove campos de identificação passaram a estar escritos no HTML e o ficheiro JavaScript continuou a existir, a escrever por cima de valores que já estavam certos. O caso completo, com as contagens antes e depois, está em Porque é que o seu site está correto para pessoas e vazio para máquinas?