Passar na ferramenta de validação do Google não garante que os mecanismos de IA consigam capturar seus dados estruturados. Cada sistema percorre um caminho de análise diferente. O Rich Results Test verifica apenas a elegibilidade para os poucos tipos de pesquisa aprimorada aceitos pelo Google. Já o Schema.org Validator confere se a sintaxe segue o vocabulário especificado. Nenhum dos dois mostra o que os crawlers do ChatGPT, Perplexity ou Google AI Overviews realmente leem na página. Muitas páginas recebem sinal verde em toda a validação e, ainda assim, permanecem invisíveis nas respostas de IA. Essa é a lacuna.
Por que “passou na validação” não significa “a IA consegue ler”
A função das ferramentas é verificar conformidade, não legibilidade. O Schema.org Validator compara seu JSON-LD com o vocabulário do schema.org para confirmar se tipos e propriedades estão escritos corretamente e se a estrutura aninhada é válida. O Rich Results Test, por sua vez, simula a renderização da página pelo Googlebot para determinar se ela pode gerar determinado resultado aprimorado. Ao concluir essas 2 verificações, você sabe apenas que a sintaxe está correta e se o Google considera a página elegível para um resultado aprimorado. Muitos crawlers de IA capturam diretamente o HTML original entregue pelo servidor, não executam JavaScript e não levam em conta essa elegibilidade. O que realmente determina a leitura pela IA é a presença do JSON-LD no HTML original e a conexão entre as entidades.
2 ferramentas essenciais, cada uma com seus pontos cegos
Antes de montar o processo, é preciso entender com clareza o papel de cada ferramenta — e o que cada uma deixa passar.
- Rich Results Test (search.google.com/test/rich-results): usa o Googlebot para renderizar a página, executar JavaScript e listar, um a um, os tipos de resultado aprimorado detectados, além de erros e alertas. Seu ponto cego é a cobertura limitada a cerca de 30 tipos aceitos pelo Google. Se você marcar tipos como Organization e Person, que não geram resultados aprimorados, a ferramenta poderá exibir “Item não detectado”. Isso não significa que o Schema seja inválido.
- Schema.org Validator (validator.schema.org): independentemente do suporte do Google, exibe a árvore completa de entidades de todos os tipos e é ideal para conferir sintaxe e vocabulário. Seu ponto cego é não executar JavaScript por padrão. Ao enviar o código-fonte ou informar uma URL, você muitas vezes recebe a versão não renderizada. A ferramenta também não informa a elegibilidade para resultados aprimorados e pode ser permissiva demais com determinados erros semânticos.
A conclusão é simples: use as 2 ferramentas e defina o objetivo de cada etapa. Recorra ao Schema.org Validator para conferir a sintaxe e a estrutura das entidades. Use o Rich Results Test para verificar a elegibilidade para resultados aprimorados do Google e o conteúdo após a renderização. Nenhuma delas responde se um crawler sem execução de JavaScript consegue enxergar os dados. Para isso, a próxima etapa é inspecionar o código-fonte.
Um processo replicável de validação de Schema
Organize a validação em uma sequência fixa e aplique o mesmo checklist a todas as páginas e revisões. Assim, a equipe deixa de validar por impressão e reduz o risco de ignorar uma falha diferente a cada rodada.
- Cole o HTML “renderizado” no Schema.org Validator. Confirme a sintaxe e o vocabulário, abra toda a árvore de entidades e verifique, um a um, os tipos e atributos obrigatórios.
- Informe a URL oficial no Rich Results Test. Confirme se o Google captura a versão renderizada, reconhece o tipo de resultado aprimorado desejado e não aponta erros em vermelho.
- Use curl ou view-source para capturar o HTML original “sem executar JavaScript”. Procure por application/ld+json e confirme que o JSON-LD está de fato no conteúdo entregue pelo servidor. Essa etapa simula o comportamento da maioria dos crawlers de IA.
- Verifique as referências cruzadas entre @id e @type em Organization, WebSite, Article e Person. Confirme se os mesmos @id conectam as entidades em uma estrutura coerente, permitindo que o mecanismo identifique a organização à qual o autor pertence e o site ao qual o artigo está vinculado.
- Compare, item por item, os valores do Schema com o conteúdo visível na página. Preço, título, avaliação e data precisam ser consistentes. Quando há divergências, o Google pode ignorar diretamente os dados, e os mecanismos de IA também reduzem o grau de confiança.
- Salve um snapshot de referência. A cada revisão, execute novamente toda a lista e trate as diferenças como possíveis regressões.
Erros que fazem o Schema ficar ilegível para mecanismos de IA
Mesmo um Schema aprovado no nível sintático pode apresentar toda uma categoria de falhas em que “a ferramenta diz que está tudo certo, mas a IA não consegue ler”. Estes são os problemas que encontramos com mais frequência nas auditorias de clientes:
- O framework de front-end ou o gerenciador de tags injeta o JSON-LD no navegador. O HTML original entregue pelo servidor não contém uma única linha desses dados, tornando-os completamente invisíveis para crawlers que não executam JavaScript.
- O @id está ausente ou apresenta inconsistências. Com isso, as entidades não se conectam, e o mecanismo não consegue associar autores, organizações e artigos ao mesmo nó do grafo de conhecimento.
- O tipo está correto, mas o valor foi inserido na propriedade errada: a moeda aparece em price, a descrição inteira foi colocada em name ou priceCurrency está ausente de offers.
- A sintaxe é válida, mas a semântica está incompleta: Product não contém offers, Article não informa author ou publisher, ou a resposta de FAQPage é uma string vazia.
- A mesma página contém vários blocos JSON-LD conflitantes, como um Organization vindo do template da página inicial e outro inserido na própria página. O mecanismo não consegue determinar qual deles deve considerar.
- A data não segue o padrão ISO 8601, ou a imagem usa um caminho relativo em vez de uma URL absoluta. Esses dados podem passar por um validador mais permissivo, mas costumam ser descartados durante a extração.
Não se limite às ferramentas: examine a diferença entre o DOM renderizado e o código-fonte
Uma validação sólida exige comparar as 2 versões da página. No painel Elements do DevTools, você vê o DOM renderizado pelo navegador, que se aproxima do conteúdo acessado pelo Googlebot. Com view-source ou curl, você enxerga o HTML original entregue inicialmente pelo servidor, que corresponde ao que a maioria dos crawlers de IA recebe. Se os dados estruturados aparecem apenas na primeira versão, a diferença entre elas é exatamente o ponto em que a IA deixa de conseguir ler a página. As ferramentas ajudam a examinar a versão renderizada; a inspeção do HTML original precisa fazer parte do seu próprio processo.
A validação de Schema não é uma tarefa pontual encerrada no momento da publicação. Ela precisa ser repetida após cada revisão: uma atualização do CMS ou um ajuste de template pode desmontar silenciosamente toda a árvore de entidades.— Tenten GEO Technical Audit Notes
Transforme a validação em uma etapa fixa antes da publicação
A abordagem mais prática é incorporar esse checklist ao processo de publicação, em vez de depender da memória e de verificações improvisadas. Você pode adicionar um script à CI para capturar o HTML original da URL oficial, extrair o JSON-LD, comparar os atributos obrigatórios e as referências de @id e bloquear o deploy quando algo estiver ausente. Equipes sem CI devem incluir pelo menos 6 etapas em um checklist de pré-publicação e marcar cada item após uma revisão. O valor dos dados estruturados está na estabilidade com que as máquinas conseguem extraí-los, e essa estabilidade vem do processo, não da sorte em uma validação manual. Para descobrir como sua página aparece aos olhos de um crawler que não executa JavaScript e quais partes do Schema estão totalmente ilegíveis para a IA, acesse /contact e agende um diagnóstico de GEO de 30 minutos. Aplicaremos o processo à sua página real.
