Como verificar os seus dados estruturados: erros de JSON-LD, propriedades ausentes e o que esperar

Dados estruturados são informações legíveis por máquina sobre uma página — que ela é um artigo com tal título e tal autor, um produto com tal preço, uma empresa em tal endereço — escritas no vocabulário do schema.org. Os mecanismos de busca os usam para entender o conteúdo e, em alguns tipos, para exibir resultados enriquecidos, como preços de produtos ou trilhas de navegação (breadcrumbs).

O Google recomenda o JSON-LD: um bloco <script type="application/ld+json"> contendo um objeto JSON, separado do HTML visível. É o formato mais fácil de adicionar e de verificar, e é nele que este guia se concentra.

Como é um JSON-LD válido

Um artigo mínimo: {"@context": "https://schema.org", "@type": "Article", "headline": "How to check structured data", "datePublished": "2026-09-26", "author": {"@type": "Organization", "name": "Example Team"}}. Todo objeto tem um @type; as coisas aninhadas (o autor) são objetos com o seu próprio tipo; as datas usam ISO 8601; as URLs são absolutas.

Os erros que quebram os dados estruturados

1. JSON que não pode ser interpretado

Basta um erro de sintaxe para os mecanismos de busca ignorarem o bloco inteiro. As causas de sempre: uma vírgula sobrando depois da última propriedade, aspas curvas "inteligentes" coladas de um editor de texto, aspas duplas ou quebras de linha sem escape dentro de um valor e variáveis de template que não imprimem nada, deixando "name": ,. Se o JSON vem de um campo do CMS, uma tag HTML perdida ali dentro produz o mesmo efeito.

2. Propriedades essenciais ausentes

Cada recurso da busca documenta propriedades obrigatórias (sem elas, a página não se qualifica para aquele recurso) e recomendadas (elas o melhoram). Uma Organization sem name, um Product sem nenhum offers, review ou aggregateRating, ou um item de breadcrumb sem position estão incompletos. A documentação da galeria de pesquisa do Google lista os requisitos de cada recurso; eles mudam de tempos em tempos, então consulte-a em vez de confiar na memória.

3. URLs inválidas

url, logo e image devem ser URLs absolutas e que funcionam. Caminhos relativos, marcadores provisórios como # e hostnames de staging são comuns em templates.

4. Blocos duplicados ou conflitantes

Um tema e um plugin de SEO emitindo, cada um, um bloco Organization ou WebSite, com nomes ou logos diferentes, causam confusão, na melhor das hipóteses. Gere cada tipo uma única vez.

5. Marcação que não corresponde à página

Os dados estruturados precisam descrever o que os visitantes conseguem ver: avaliações que não estão na página, preços diferentes do preço exibido ou respostas de FAQ que não aparecem contrariam as diretrizes do Google e podem resultar em uma ação manual. Nenhum verificador automatizado consegue avaliar isso por você.

O que o verificador de SEO do Rudra procura

O verificador de SEO gratuito lê todos os blocos JSON-LD do HTML que o seu servidor envia (inclusive blocos envoltos em comentários HTML ou CDATA e blocos cujo tipo traz um charset). Ele informa:

• blocos que não podem ser interpretados, com o erro do parser (um aviso que custa pontos, porque a marcação fica inutilizável);
• o mesmo @type declarado mais de uma vez;
• valores de url, logo ou image que não são URLs absolutas válidas;
• propriedades essenciais ausentes em um conjunto conservador de tipos comuns: name e url em Organization e WebSite; headline, datePublished e author em Article, BlogPosting e NewsArticle; name e address em LocalBusiness; name mais um entre offers, review ou aggregateRating em Product; perguntas com um name e uma resposta com text em FAQPage; e itens com position e com name ou item em BreadcrumbList.

São mínimos sensatos, não uma cópia dos requisitos de cada mecanismo de busca — para alguns recursos o Google exige mais e, no caso de Article, lista essas propriedades como recomendadas, não como obrigatórias. O verificador lê apenas o HTML antes de o JavaScript ser executado, portanto os dados estruturados injetados por um gerenciador de tags não serão vistos. Trate os achados dele como uma primeira passada e depois confirme com as ferramentas abaixo.

Outras ferramentas para usar

• O Teste de pesquisa aprimorada do Google (Rich Results Test) mostra para quais recursos do Google uma página se qualifica e os erros que a impedem. Ele renderiza JavaScript, portanto também enxerga a marcação injetada.
• O Schema Markup Validator (validator.schema.org) confere qualquer marcação schema.org em relação ao vocabulário, independentemente dos recursos do Google.
• Os relatórios de melhorias do Search Console mostram erros e avisos de cada tipo de dado estruturado nas páginas que o Google rastreou.

O que os dados estruturados não podem prometer

Uma marcação válida e completa torna a página qualificada para resultados enriquecidos. Não os garante: os mecanismos de busca decidem, a cada consulta, se vão exibi-los, e os recursos mudam. Por exemplo, em 2023 o Google limitou os resultados enriquecidos de FAQ a um pequeno conjunto de sites governamentais e de saúde de grande autoridade e deixou de exibir os resultados enriquecidos de HowTo. Os dados estruturados também não são um atalho para ranquear; o valor deles está em ajudar os mecanismos de busca a entender o seu conteúdo com precisão.

Um fluxo de trabalho simples

1. Gere o JSON-LD a partir do seu CMS ou dos seus templates, com os mesmos dados que renderizam a página, para que os dois não fiquem dessincronizados.
2. Emita cada tipo uma única vez por página.
3. Verifique uma página de cada template com o verificador de SEO e com o Teste de pesquisa aprimorada depois de toda mudança de template.
4. Acompanhe os relatórios de melhorias do Search Console em busca de novos erros depois dos deploys.