Blog · Caso próprio
Porque é que o seu site está correto para pessoas e vazio para máquinas?
Resposta curta
Porque o navegador executa JavaScript e a maioria dos leitores automáticos não executa. A WrightGate publicou a sua página de termos a 24 de agosto de 2026 com a identificação legal por preencher e preencheu-a a 28 de agosto de 2026 — dentro de um ficheiro JavaScript. Durante o dia seguinte, o HTML servido dessa página conteve a expressão «por preencher» dez vezes e o NIPC da empresa zero vezes, enquanto qualquer pessoa que a abrisse num navegador via a empresa completamente identificada.
Os dados estavam corretos. Não estavam legíveis.
O que é o HTML servido, e porque é que é ele que conta?
O HTML servido é o texto que o servidor devolve no pedido, antes de qualquer script correr. É o documento tal como sai pelo cabo. Tudo o que uma página acrescenta depois — com JavaScript, ao carregar, ao rolar ou ao clicar — não faz parte dele.
Um navegador moderno esconde a diferença, porque executa os scripts em milissegundos e mostra o resultado final. A diferença aparece quando o leitor não é um navegador. Uma pré-visualização de ligação no WhatsApp, um agregador de notícias, um verificador de conformidade, um rastreador e um modelo de linguagem que vai buscar a página para responder a uma pergunta leem, em regra, o HTML servido e nada mais.
A consequência é literal e não é uma metáfora: um facto que só existe depois de o script correr é um facto que esses leitores não têm. Não o leem mal — não o leem de todo.
O que estava escrito no ficheiro, e o que estava escrito na página?
A 28 de agosto de 2026, a identificação legal da WrightGate estava escrita, completa e
correta, em assets/js/company.js: designação REALCHAIN, S.A., NIPC
516852574, sede na Avenida da Liberdade 110, 1269-046 Lisboa, registo comercial, capital
social e telefone. Esse ficheiro pintava os valores nos lugares certos da página quando o
navegador o executava.
No mesmo dia, o HTML servido da página /termos dizia outra coisa. A
tabela abaixo mostra o que uma contagem de ocorrências devolvia sobre o documento tal
como saía do servidor.
| Expressão procurada no HTML servido | /termos a 28-08-2026 | /termos a 29-08-2026 |
|---|---|---|
por preencher | 10 ocorrências | 0 ocorrências |
516852574 (o NIPC) | 0 ocorrências | 2 ocorrências |
REALCHAIN (a designação) | 0 ocorrências | 2 ocorrências |
A página /privacidade tinha o mesmo problema à mesma data, com sete
ocorrências de «por preencher» no HTML servido.
Havia ainda uma frase pior do que a ausência dos dados. Enquanto a identificação estivesse incompleta, a página avisava, em texto visível, que não devia ser usada para vender. Esse aviso estava escrito diretamente no HTML e por isso era exatamente a parte que qualquer leitor automático conseguia ler sem esforço nenhum. A única afirmação sobre a empresa que estava garantidamente legível por máquina era a de que a empresa ainda não estava pronta.
Porque é que ninguém deu por isso?
Porque a verificação natural é abrir a página, e abrir a página mostra a versão
certa. Quem preencheu os dados a 28 de agosto de 2026 confirmou o trabalho da maneira
óbvia: carregou /termos, viu «REALCHAIN, S.A.» e «516852574» no sítio certo,
e deu a tarefa por fechada. A confirmação foi feita com a única ferramenta que não
conseguia detetar o defeito.
Este é o modo de falha central do problema, e não é um descuido individual: o navegador é simultaneamente a ferramenta de trabalho e o único leitor do mundo que nunca vê o erro. Enquanto a verificação for visual, o defeito é invisível por construção.
Como é que a WrightGate corrigiu?
A correção foi escrever os valores no HTML, e não melhorar o script. A 29 de agosto de
2026, os nove campos de identificação passaram a estar no documento servido de
/termos e de /privacidade, cada um marcado com um atributo
data-company que diz a que campo corresponde. O script continua a existir e
continua a ser a fonte de verdade, mas deixou de ser a única cópia: quando corre, escreve
por cima de valores que já estavam certos.
O aviso de identificação incompleta saiu do HTML por inteiro. Escondê-lo não teria resolvido nada, porque um elemento escondido continua nos bytes servidos e continua a ser lido por quem lê os bytes. Passou a ser criado pelo próprio script, e apenas quando encontra mesmo um campo em falta.
O que impede que volte a acontecer?
Duas cópias do mesmo dado divergem sempre. A WrightGate acrescentou por isso um
verificador, tools/verificar-identidade.mjs, que lê o objeto de identidade do
ficheiro JavaScript, percorre todas as páginas do site e compara campo a campo com o que
está escrito no HTML. Devolve erro, com a linha exata, quando um dos dois lados muda sem
o outro. À data desta publicação confere 22 campos em 6 páginas.
A regra que ficou escrita no projeto é uma só: tudo o que uma máquina precisa de ler tem de estar no HTML servido — identidade, atividade, zona e contactos —, e a verificação de que lá está não se faz num navegador, faz-se num pedido sem JavaScript.
Metodologia
As contagens desta página são reproduzíveis por quem tiver acesso ao repositório do site. Cada linha da tabela é o número devolvido por uma contagem de ocorrências sobre a versão do ficheiro no commit indicado, e não uma estimativa:
git show 9a8145e:termos/index.html | grep -c "por preencher" # 10
git show 9a8145e:termos/index.html | grep -c "516852574" # 0
git show d5e1867:termos/index.html | grep -c "por preencher" # 0O commit 9a8145e é de 28 de agosto de 2026 e é o que introduziu a
identidade no ficheiro JavaScript. Os commits 744b85a e d5e1867
são de 29 de agosto de 2026 e são os que escreveram os valores no HTML e removeram o
aviso. Sobre um site publicado, a mesma verificação faz-se sem repositório nenhum, com um
pedido que não executa scripts:
curl -s https://www.wrightgate.com/termos | grep -c "516852574"O que este artigo não diz
Não afirma que todos os motores de IA ignoram JavaScript. Alguns rastreadores executam scripts em parte dos pedidos, e a prática muda com o tempo e entre fornecedores. O argumento aqui não depende disso: depende de a execução ser opcional para quem lê e obrigatória para quem publica desta forma, e uma condição que não se controla não é uma condição em que se assente a identificação legal de uma empresa.
Não afirma que ter o conteúdo em HTML servido garante ser mencionado por um motor de IA. É condição necessária e não suficiente: sem ela o motor não consegue citar a empresa; com ela, continua a escolher entre as que consegue ler.
Não quantifica quantas empresas portuguesas têm este defeito. A WrightGate ainda não publicou essa auditoria, e nenhum número sobre o mercado português aparece nesta página por essa razão.
Quem publica
Artigo publicado pela WrightGate IT Solutions a 29 de agosto de 2026. Os dados brutos e os commits citados estão disponíveis mediante pedido para info@wrightgate.com.
WrightGate IT Solutions é a marca de REALCHAIN, S.A. · NIPC 516852574 · Avenida da Liberdade 110, 1269-046 Lisboa, Portugal · 935 380 857