Legibilidade para rastreadores de IA: porque não leem o teu site

Abres o teu site no navegador e está lá tudo: os textos, os preços, as descrições. Mas perguntas ao ChatGPT pela tua empresa e ele responde com informação desatualizada, incompleta ou diretamente da concorrência. A explicação mais frequente não é que o rastreador não chegue ao teu site, mas sim que chega e não encontra nada para ler: recebe um HTML quase vazio que só se transforma em página depois de executar JavaScript, algo que um navegador faz e que nem todos os rastreadores fazem.

Neste guia vais ver o que significa exatamente um site ser legível para um rastreador de IA generativa, porque é que a renderização com JavaScript é o fator que mais pesa de todos, como verificar em menos de um minuto o que um rastreador vê realmente quando visita a tua página, e que outros sinais do HTML determinam que o conteúdo se entenda ou se interprete mal.

O que significa um site ser legível para um rastreador

A legibilidade é o que acontece depois do acesso. São dois problemas distintos e convém não os misturar: o acesso responde a «o rastreador consegue entrar?», e a legibilidade responde a «uma vez lá dentro, percebe o que está a ler?». Um site pode responder corretamente a todos os rastreadores e ainda assim ser praticamente ilegível para eles, porque o que devolve é um esqueleto sem conteúdo, ou um muro de texto onde o menu de navegação e o artigo pesam o mesmo.

Se o que te falha é o primeiro, o artigo de que precisas é outro: como saber se o teu firewall está a bloquear os rastreadores de IA. Este trata do segundo.

Legibilidade para máquinas vs. acessibilidade web

Os dois conceitos sobrepõem-se, mas não são o mesmo. A acessibilidade web (WCAG) procura que uma pessoa com uma deficiência possa usar o site: contraste suficiente, navegação por teclado, textos alternativos nas imagens. A legibilidade para rastreadores procura que um programa perceba a estrutura do conteúdo sem a ver.

A sobreposição é real e convém aproveitá-la: um HTML semântico bem construído, com títulos hierárquicos e regiões marcadas, melhora as duas coisas ao mesmo tempo. Mas não são equivalentes. Um site pode passar numa auditoria de acessibilidade e continuar ilegível para um rastreador que não executa JavaScript, porque o leitor de ecrã do utilizador executa-o e o rastreador não.

O fator que mais pesa: conteúdo que só existe com JavaScript

De tudo o que se pode medir em legibilidade, este é o que decide o resultado. Os restantes fatores afinam; este determina se há alguma coisa para afinar.

Porque é que o navegador o vê e o rastreador não

Quando pedes uma página, o servidor devolve um documento HTML. Num site renderizado no servidor, esse documento já contém o texto. Num site renderizado no cliente — o habitual em aplicações feitas com React, Vue ou Angular sem configuração adicional —, esse documento contém pouco mais do que um contentor vazio e uma referência a um ficheiro JavaScript. O texto aparece depois, quando o navegador descarrega esse ficheiro, o executa e constrói a página.

O teu navegador faz esse trabalho sem que dês por isso. Um rastreador não tem de o fazer: executar JavaScript de milhões de páginas é caro, e nem todos os sistemas que rastreiam a web para alimentar modelos de IA o fazem. Alguns leem o HTML tal como sai do servidor e seguem em frente. Para eles, a tua página não está incompleta: está vazia.

Como verificá-lo em menos de um minuto

Não é preciso nenhuma ferramenta especial. Pede a página como a pediria um rastreador e procura na resposta uma frase que saibas que está no conteúdo:

curl -s https://oteudominio.pt | grep -c "una frase de tu contenido"

Se devolver 0, essa frase não está no HTML servido: só aparece depois de executar JavaScript. Se não tens um terminal à mão, o equivalente no navegador é abrir o código-fonte com Ctrl+U (ou Cmd+Opt+U) e procurar aí a mesma frase. É importante usar «ver código-fonte» e não o inspetor de elementos: o inspetor mostra a página já construída, com o JavaScript executado, e por isso parece sempre que está tudo bem.

A solução: renderização no servidor ou geração estática

A correção real consiste em que o HTML chegue com o conteúdo lá dentro. Há duas formas habituais de o conseguir, e ambas são suportadas pelas frameworks atuais:

• Renderização no servidor (SSR): o servidor constrói o HTML completo em cada pedido. É o indicado quando o conteúdo muda com frequência ou depende do utilizador.
• Geração estática (SSG): o HTML é construído uma vez, ao publicar, e é servido já feito. É o indicado para conteúdo que não muda a cada visita: páginas de produto, artigos, páginas institucionais.

Se o teu site está em WordPress, Shopify ou qualquer CMS clássico, isto já o tens resolvido por omissão: o HTML sai do servidor com o conteúdo lá dentro. O problema aparece sobretudo em desenvolvimentos à medida e em aplicações de página única.

Porque é que <noscript> é um remendo e não uma solução

A etiqueta <noscript> permite incluir conteúdo alternativo para quem não executa JavaScript. Serve para tapar o buraco enquanto se prepara uma mudança maior, e é melhor do que não ter nada. Mas manter essa alternativa sincronizada com o conteúdo real é um trabalho manual que se abandona assim que há pressa, e a partir daí o que o rastreador lê deixa de coincidir com o que o utilizador vê. Usa-o como medida temporária, com data de validade.

Os sinais que fazem com que o conteúdo se entenda

Assumindo que o conteúdo está no HTML, restam quatro sinais que determinam se é bem interpretado. Nenhum deles é tão decisivo como o anterior, mas juntos marcam a diferença entre um texto que se entende e um texto que é preciso adivinhar.

Um só H1, e que diga do que trata a página

O <h1> é o sinal mais básico sobre o tema de uma página. Os dois erros habituais são opostos: não ter nenhum, porque o design usa um <div> com letra grande no seu lugar; ou ter vários, porque as etiquetas foram escolhidas por tamanho visual em vez de por hierarquia. No primeiro caso falta o sinal; no segundo, o tema principal fica ambíguo. Um <h1> por página, e o resto em <h2> e <h3> conforme a estrutura real do conteúdo.

O idioma declarado na etiqueta raiz

Uma linha que se esquece com frequência e que não custa nada:

<html lang="pt-PT">

Sem ela, o idioma do conteúdo tem de ser deduzido do próprio texto. Deduz-se quase sempre bem, mas «quase sempre» é pior do que «sempre», e em sites com conteúdo em vários idiomas ou com muitos nomes próprios a dedução falha mais do que parece.

Delimitar o conteúdo principal com <main> e <article>

Uma página típica contém muito texto que não é o conteúdo: o menu, o rodapé, os avisos de cookies, as ligações relacionadas. Se tudo isso está em <div> indistinguíveis, separar o trigo do joio é uma tarefa de adivinhação. Envolver o conteúdo principal em <main>, e cada peça autónoma em <article>, elimina essa ambiguidade com duas etiquetas.

É também o ponto que mais se repete nos sites que analisamos, precisamente porque não tem nenhum efeito visível: tirar o <main> não muda nada no ecrã, por isso ninguém dá pela falta.

E um sinal que pertence à vizinhança: os dados estruturados

A legibilidade trata de que o texto seja lido e entendido. Declarar explicitamente o que é cada coisa — quem és, o que vendes, quem assina um artigo — é o passo seguinte, e faz-se com dados estruturados. São problemas vizinhos: o primeiro faz com que o conteúdo exista para a máquina, o segundo faz com que ela não tenha de o interpretar.

As cinco verificações, ordenadas pelo que pesam

Nem todas valem o mesmo, e tratá-las como uma lista plana leva a corrigir o fácil antes do importante. Esta é a ordem por impacto:

Verificação	Peso	O que falha quando falha
Conteúdo disponível sem JavaScript	🔴 Crítico	O rastreador recebe uma página vazia. Nada do resto importa.
Alternativa <noscript>	🟠 Médio	Sem renderização no servidor e sem alternativa, não sobra nada para ler.
Título principal (H1)	🟠 Médio	Falta o sinal mais básico sobre o tema, ou há vários e contradizem-se.
Idioma declarado	🟠 Médio	O idioma tem de ser deduzido do texto, e às vezes deduz-se mal.
Conteúdo principal delimitado	🟡 Baixo	O menu e o rodapé pesam o mesmo que o conteúdo.

A ordem importa: corrigir o H1 num site cujo conteúdo só existe com JavaScript é pintar uma parede que ainda não está construída.

Erros comuns ao tentar corrigir a legibilidade

• Verificá-lo com o inspetor de elementos em vez de com «ver código-fonte». O inspetor mostra a página já construída, por isso parece sempre que o conteúdo lá está.
• Dar por garantido que, se a Google indexa a página, todos os rastreadores a leem da mesma maneira. A Google renderiza JavaScript; nem todos os sistemas que alimentam assistentes de IA o fazem.
• Instalar um plugin de prerender e não voltar a verificar. Estas soluções dependem de detetar corretamente o rastreador, e quando a deteção falha, falha em silêncio.
• Corrigir um template e supor que o resto do site herda a correção. A página inicial e as fichas de produto costumam usar templates diferentes.

Nenhum destes problemas se deteta a olhar para o site. Todos dependem do que o servidor devolve realmente quando lhe pede a página algo que não é um navegador, que é exatamente o que faz um diagnóstico técnico de acessibilidade para rastreadores.

Perguntas frequentes sobre legibilidade para rastreadores

Os rastreadores de IA executam JavaScript?

Nem todos, e nem sempre. Executar JavaScript à escala de toda a web é caro, e alguns sistemas leem o HTML tal como o servidor o devolve. Como não há forma de saber com certeza o que cada um faz em cada momento, o prudente é que o conteúdo não dependa disso.

Se a Google indexa bem o meu site, o problema está resolvido?

Não necessariamente. A Google renderiza JavaScript há anos, por isso um site que só funciona com JS pode ser indexado na Google e ainda assim ser ilegível para outros rastreadores. São sistemas distintos com capacidades distintas.

Como vejo o que um rastreador vê no meu site?

Abrindo o código-fonte da página com Ctrl+U (Cmd+Opt+U no Mac) e procurando aí uma frase do teu conteúdo. Se não aparecer, não está no HTML servido. O inspetor de elementos não serve para isto, porque mostra a página depois de executar o JavaScript.

<noscript> serve para resolver isto?

Serve como remendo temporário. O problema é mantê-lo sincronizado com o conteúdo real: assim que se dessincroniza, o que o rastreador lê deixa de coincidir com o que o utilizador vê. A solução estável é renderizar no servidor ou gerar o HTML de forma estática.

Um site pode ter vários H1?

Tecnicamente o HTML permite-o, mas para um rastreador o resultado é um tema principal ambíguo. O recomendável continua a ser um único H1 por página, e os restantes títulos escolhidos por hierarquia e não por tamanho visual.

Melhorar a legibilidade garante que o ChatGPT cite o meu site?

Não. Garante que seja possível: se o conteúdo não está no HTML, não há nada para citar. Que além disso seja citado depende da autoridade do site, da consulta concreta e de outros fatores que nenhuma mudança técnica controla por si só.

O que verificar no teu site agora mesmo

Começa pelo que mais pesa: abre o código-fonte da tua página mais importante e procura uma frase do conteúdo. Se não estiver lá, já sabes qual é a tua prioridade e nenhuma outra correção a substitui. Se estiver, revê então o H1, o atributo lang e se o conteúdo principal vai dentro de um <main>. E se preferes ver tudo de uma vez, sobre todas as tuas páginas e com a linha exata que causa cada ponto, podes verificar a legibilidade do teu site gratuitamente.