Pular para o conteúdo
Aback Tools Logo

Como Verificar Dados Estruturados em um Site: Guia de Validação JSON-LD

Como verificar dados estruturados em um site: encontre blocos JSON-LD, valide sintaxe e propriedades obrigatórias, corrija erros de esquema comuns, teste a elegibilidade para resultados ricos e automatize a validação em CI/CD.

DH
Tutorials & How-Tos12 min de leitura2,700 palavras

Os dados estruturados dizem aos mecanismos de busca o que seu conteúdo significa — não apenas o que as palavras dizem, mas se uma página é um produto, um artigo, uma receita ou uma FAQ. Acertando, o Google exibe seu conteúdo como resultados ricos: avaliações em estrelas, acordeões de FAQ, trilhas de breadcrumb e carrosséis de passos. Errando, a marcação é silenciosamente ignorada. Este guia cobre todos os métodos para verificar dados estruturados em qualquer site, da inspeção do código-fonte à validação automatizada em CI.

40+Tipos de esquemasuportados pelos resultados ricos do Google
100%Verificação local no navegadorsem URL ou login
<1sVelocidade de validaçãofeedback JSON-LD instantâneo

O que são dados estruturados?

Dados estruturados são metadados legíveis por máquina embutidos numa página web que ajudam os mecanismos de busca a entender o conteúdo além do texto visível. O formato dominante é JSON-LD — uma tag script em notação de objetos JavaScript colocada no `<head>` de uma página, usando vocabulário do schema.org para descrever entidades como artigos, produtos, eventos, receitas e organizações.

Quando um mecanismo de busca rastreia uma página, ele extrai esses blocos de esquema e os usa para gerar resultados ricos: listagens de busca aprimoradas que mostram avaliações em estrelas, faixas de preço, datas de eventos, acordeões de FAQ e navegação em breadcrumb diretamente na SERP. Resultados ricos alcançam consistentemente taxas de clique mais altas que listagens padrão de link azul porque transmitem mais informação de relance.

Os três formatos de dados estruturados

  • JSON-LD: uma tag `<script type="application/ld+json">` autônoma contendo um objeto JSON. O Google recomenda esse formato — o mais fácil de adicionar, validar e manter sem tocar no HTML da página.
  • Microdados: atributos de esquema (`itemscope`, `itemtype`, `itemprop`) adicionados diretamente aos elementos HTML. Fortemente acoplados à estrutura da página — mais difíceis de validar e atualizar.
  • RDFa: atributos de dados vinculados (`typeof`, `property`) adicionados aos elementos HTML. Muito usado em algumas plataformas de CMS, mas menos comum que JSON-LD em implementações novas.

Note

O Google suporta os três formatos, mas recomenda JSON-LD para a maioria dos casos. Este guia foca no JSON-LD porque é o formato dominante nas implementações modernas e o que orienta a maioria das ferramentas.

Como verificar dados estruturados

Há quatro métodos práticos para verificar dados estruturados numa página, cada um adequado a situações diferentes. Os métodos mais rápidos não exigem ferramenta nenhuma; os mais completos pedem um validador e o ambiente de testes do próprio Google.

Método 1: ver o código-fonte da página

Clique com o botão direito em qualquer página no navegador e escolha Ver código-fonte (Ctrl+U / Cmd+U). Pressione Ctrl+F para abrir a busca e procure por `application/ld+json`. Cada resultado é um bloco de dados estruturados. Isso diz imediatamente se existem dados estruturados na página e permite copiar o JSON para validação. Em páginas que renderizam conteúdo via JavaScript, ver o código-fonte mostra apenas o HTML inicial — use o DevTools para a saída renderizada.

Método 2: painel Elements das DevTools

Abra o DevTools do Chrome (F12), vá à aba Elements e procure por `ld+json` na árvore de elementos. Isso mostra os dados estruturados como o navegador os renderiza atualmente — incluindo blocos injetados por JavaScript após o carregamento da página. É a abordagem correta para React, Next.js ou qualquer framework que adicione dados estruturados no cliente ou via renderização no servidor.

Método 3: Validador de Dados Estruturados (o mais rápido em desenvolvimento)

Copie um bloco JSON-LD e cole no validador de dados estruturados. Ele valida a sintaxe do JSON, verifica as declarações `@context` e `@type` e sinaliza propriedades obrigatórias ausentes para o tipo de esquema declarado — tudo no seu navegador, sem enviar uma URL nem esperar um rastreamento. É o ciclo mais rápido em desenvolvimento porque você corrige e revalida em segundos.

Método 4: o Teste de Resultados Ricos do Google

Envie a URL da sua página ativa ao Teste de Resultados Ricos do Google em `search.google.com/test/rich-results`. O Google busca a página, extrai todos os dados estruturados e informa para quais tipos de resultado rico a página se qualifica. É o teste autoritativo para elegibilidade de resultados ricos — mas exige uma URL ativa e leva de 5 a 30 segundos por teste. Use-o depois de a validação local estar limpa.

Validador de Dados Estruturados

Valide qualquer bloco de dados estruturados JSON-LD por sintaxe, propriedades obrigatórias e conformidade com o schema.org — local no navegador, sem URL.

Open tool

Validando a marcação JSON-LD

A validação JSON-LD tem duas camadas distintas: a validação de sintaxe (o JSON é estruturalmente válido?) e a validação de esquema (o conteúdo está conforme as propriedades obrigatórias e recomendadas do tipo do schema.org?). Ambas as camadas precisam passar antes de um bloco de dados estruturados ser útil.

1

Inspecione a página em busca de blocos JSON-LD

Clique com o botão direito na página e escolha Ver código-fonte. Procure por `application/ld+json`. Copie o objeto JSON inteiro de dentro da tag script — da chave de abertura à chave de fechamento. Se houver vários blocos, copie cada um separadamente para validação.

2

Valide a sintaxe com o validador JSON-LD

Cole o bloco copiado no validador JSON-LD. Ele verifica que o JSON está bem formado, que `@context` está definido como `https://schema.org` e que `@type` referencia um tipo reconhecido do schema.org. Erros de sintaxe são reportados com números de linha; avisos de tipo desconhecido identificam tipos de esquema com pouca chance de gerar resultados ricos.

3

Verifique as propriedades obrigatórias do tipo declarado

Cada tipo de esquema tem propriedades obrigatórias e recomendadas. Um esquema `Product` exige `name` e `offers` ou `review` para elegibilidade de resultado rico. Um `Article` exige `headline`, `author` e `datePublished`. O validador de dados estruturados verifica o `@type` declarado e sinaliza cada propriedade obrigatória ausente ou mal formatada.

4

Teste a elegibilidade com a ferramenta do Google

Com a validação local limpa, envie a URL da página ao Teste de Resultados Ricos do Google. Revise a lista de tipos de esquema detectados e confirme que cada um aparece como elegível em vez de sinalizado com erros. Trate os avisos de "Recomendado" de propriedades que melhoram a qualidade dos resultados ricos mesmo sem bloqueá-los.

exemplo-schema-artigo.json
json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Check Structured Data on a Website",
  "author": {
    "@type": "Person",
    "name": "Devvrat Hans",
    "url": "https://abacktools.com"
  },
  "datePublished": "2026-06-11",
  "dateModified": "2026-06-11",
  "publisher": {
    "@type": "Organization",
    "name": "Aback Tools",
    "url": "https://abacktools.com"
  }
}

Tip

Defina sempre `datePublished` e `dateModified` como strings de data ISO 8601 (`YYYY-MM-DD` ou `YYYY-MM-DDTHH:MM:SSZ`). Um erro comum é usar um formato legível como "11 de junho de 2026" — isso falha na validação do esquema e pode impedir o artigo de aparecer no Google Discover e Top Stories.

Erros comuns de dados estruturados

A maioria dos erros de dados estruturados cai em categorias previsíveis. Saber o que cada tipo de erro significa — e por que importa — permite corrigir na ordem certa: primeiro a sintaxe, depois as propriedades obrigatórias, por último as melhorias recomendadas.

Propriedades obrigatórias ausentes

O Google define propriedades obrigatórias para cada tipo de esquema que suporta resultados ricos. Se qualquer propriedade obrigatória estiver ausente, o esquema inteiro fica inelegível para sua função de resultado rico. Exemplos comuns: `Product` sem `name` ou `offers`, `Recipe` sem `name` ou `recipeIngredient`, `Event` sem `name`, `startDate` ou `location`. O verificador de completude do esquema Product audita especificamente esquemas Product contra todos os campos obrigatórios e recomendados do Google.

Tipos de valor incorretos

Propriedades do schema.org esperam tipos de valor específicos. Propriedades `url` devem ser URLs absolutas começando com `https://`; `ratingValue` deve ser um número (não uma string como `"4.5"`); `datePublished` deve ser uma string de data ISO 8601 válida. Passar uma string onde um número é esperado, ou um caminho relativo onde uma URL absoluta é exigida, causa um erro de incompatibilidade de tipo que impede o esquema de ser lido corretamente.

Tipo de esquema e conteúdo da página incompatíveis

O Google exige que os dados estruturados reflitam com precisão o conteúdo visível da página. Colocar marcação `FAQPage` numa página que não exibe visivelmente perguntas e respostas, ou adicionar marcação `Product` a uma página de categoria sem detalhes específicos de produto, viola as diretrizes de dados estruturados do Google e pode resultar em ações manuais contra a elegibilidade de resultados ricos.

Tipo de erroExemploImpactoComo corrigir
Propriedade obrigatória ausenteProduct sem nameBloqueia o resultado ricoAdicione a propriedade
Tipo de valor erradoratingValue: "4.5" (string)Esquema ignoradoUse um número: 4.5
URL relativa em campo urlimage: /foto.jpgErro de validaçãoUse URL HTTPS absoluta
Formato de data inválidodatePublished: "junho 2026"Data não interpretadaUse o formato YYYY-MM-DD
@type desconhecido@type: "BlogPosting2"Esquema não reconhecidoUse o tipo exato do schema.org
@context ausenteSem declaração @contextEsquema não extraídoAdicione o contexto schema.org
Conteúdo incompatívelFAQPage em página sem FAQRisco de ação manualAlinhe o esquema ao conteúdo

Warning

As políticas de Dados Estruturados do Google proíbem usar dados estruturados para marcar conteúdo que não é visível ao usuário. Dados estruturados ocultos — descrições mais ricas que o conteúdo visível, avaliações falsas ou dados de entidade fabricados para SEO — são tratados como spam. Garanta sempre que seu JSON-LD reflete o que os usuários realmente veem na página.

Verificação por tipo de esquema

Tipos de esquema diferentes têm propriedades obrigatórias diferentes, apresentações de resultados ricos diferentes e ferramentas de validação mais adequadas a cada um. Veja como abordar os tipos mais usados.

FAQPage e HowTo

FAQPage é um dos tipos de esquema de maior impacto no CTR orgânico — um esquema FAQPage válido é renderizado como um acordeão expansível diretamente nos resultados do Google, mostrando perguntas e respostas sem clique. Use o gerador de esquema FAQ para produzir marcação FAQPage limpa a partir de pares de pergunta e resposta, e valide a saída com o validador JSON-LD. Para conteúdo instrucional passo a passo, o gerador de esquema HowTo constrói marcação HowTo válida com blocos `HowToStep` bem estruturados.

A marcação BreadcrumbList gera a trilha de breadcrumb exibida sob o título da página nos resultados do Google — substituindo a URL crua por uma hierarquia legível. Cada `ListItem` exige um `name` e uma URL `item`. Use o gerador de esquema Breadcrumb para gerar JSON-LD de BreadcrumbList a partir de um caminho de URL ou entradas manuais, pronto para inserir diretamente no seu template de página.

Organization e Article

O esquema Organization estabelece a identidade do seu site para o grafo de conhecimento do Google — nome, logotipo, informações de contato e perfis sociais. O validador de esquema Organization verifica que todos os campos recomendados estão presentes e corretamente formatados. Para conteúdo editorial, o esquema Article com `author`, `datePublished` e `publisher` aumenta a elegibilidade para Google News, Top Stories e Discover, o que pode trazer tráfego significativo para páginas de notícias e blogs.

Avaliações e classificações agregadas

As avaliações em estrelas nos resultados vêm de `AggregateRating` aninhado dentro de um esquema `Product`, `LocalBusiness` ou `Recipe`. O `ratingValue` deve ser um número, `reviewCount` deve ser um inteiro positivo, e tanto `bestRating` quanto `worstRating` devem ser especificados para evitar ambiguidade. O verificador de elegibilidade de snippets de avaliação valida a marcação de classificação contra os requisitos específicos do Google para resultados ricos de avaliações.


Tipo de esquemaResultado ricoCampos obrigatórios-chaveVerificador do Aback Tools
FAQPageAcordeão de FAQ na SERPmainEntity com perguntas e respostasGerador de esquema FAQ
HowToCarrossel de passos na SERPname, step, textGerador de esquema HowTo
BreadcrumbListTrilha de breadcrumb na SERPitemListElement, name, itemGerador de esquema Breadcrumb
ProductPainel de produto com preço/avaliaçãoname, offers ou reviewVerificador de completude do esquema Product
ArticleTop Stories, Discoverheadline, author, datePublishedValidador JSON-LD
OrganizationPainel de conhecimentoname, url, logoValidador de esquema Organization
LocalBusinessPacote local, mapasname, address, telephoneValidador de dados estruturados

Dados estruturados em CI/CD

Verificações manuais de dados estruturados funcionam para páginas individuais, mas sites grandes com templates que geram dados estruturados programaticamente precisam de validação automatizada. Adicionar uma verificação de dados estruturados ao seu pipeline de CI/CD detecta regressões antes que cheguem à produção e bloqueiem a elegibilidade de resultados ricos.

Extração e validação em pipelines de build

A abordagem mais confiável é extrair o JSON-LD do HTML compilado e validá-lo programaticamente. Após um build, analise os arquivos HTML gerados, extraia cada bloco `<script type="application/ld+json">` e passe cada um por uma biblioteca de validação do schema.org como `schema-dts` (TypeScript), `jsonld` (Node.js) ou o Structured Data Linter do Google. Faça o build falhar se qualquer propriedade obrigatória estiver ausente ou o JSON estiver malformado.

terminal
bash
# Extract all JSON-LD blocks from built HTML using grep
grep -rl 'application/ld+json' ./out/ | while read file; do
  # Parse and validate each block
  node scripts/validate-schema.js "$file"
done

# Or use a dedicated CLI tool
npx schema-validator ./out/**/*.html --strict

Monitoramento de recursos da SERP

Após o deploy, monitore o desempenho dos resultados ricos no Google Search Console, na seção "Melhorias". Cada tipo de esquema que você implementou recebe seu próprio relatório mostrando itens válidos, avisos e erros conforme o Googlebot rastreia suas páginas. Um pico repentino de erros geralmente indica uma mudança de template que quebrou o esquema de uma categoria inteira de páginas. O verificador de recursos da SERP oferece uma visão complementar — quais recursos da SERP uma URL específica aciona atualmente.

Tip

Depois de corrigir um erro de dados estruturados, solicite a reindexação das URLs afetadas no Google Search Console usando a ferramenta de inspeção de URL. Clique em "Solicitar indexação" para pedir ao Googlebot que recrawle e reextraia os dados estruturados antes do ciclo normal de rastreamento, que pode levar dias ou semanas em páginas de menor prioridade.

Boas práticas

Seguir estas práticas garante que seus dados estruturados estejam corretos, manteníveis e alinhados às diretrizes do Google — maximizando a elegibilidade de resultados ricos sem arriscar ações manuais ou falhas silenciosas de esquema.

Mantenha os dados estruturados sincronizados com o conteúdo visível

A fonte mais comum de ações manuais do Google contra dados estruturados é uma incompatibilidade entre o esquema e o que os usuários veem. Se seu esquema `Product` mostra um preço de US$ 29 mas a página exibe US$ 49, o Google trata isso como marcação enganosa. Use seu CMS ou sistema de templates para gerar os dados estruturados da mesma fonte de dados que popula o conteúdo visível da página — nunca codifique manualmente valores no esquema que são exibidos dinamicamente em outro lugar.

Use tipos específicos, não genéricos

O schema.org tem uma hierarquia de tipos profunda. Uma página sobre um produto de software deve usar `SoftwareApplication`, não o genérico `Product`. Um restaurante local deve usar `Restaurant` (subtipo de `FoodEstablishment`), não o genérico `LocalBusiness`. Tipos mais específicos dão mais sinal aos mecanismos de busca sobre o conteúdo e podem desbloquear formatos de apresentação mais ricos nos resultados.

Dados estruturados não devem ser usados para enganar usuários nem fornecer informações enganosas. Os dados estruturados de uma página devem representar com precisão o conteúdo da página.

- Documentação do Google Search Central
  • Valide antes de implantar: execute o validador de dados estruturados em cada bloco de esquema antes de ir ao ar — capture os erros antes do Googlebot.
  • Uma entidade por bloco: aninhe entidades relacionadas (ex.: `author` dentro de `Article`) em vez de criar blocos de nível superior separados para cada subentidade.
  • Use URLs absolutas em todos os lugares: os campos `url`, `image`, `logo` e `sameAs` exigem URLs completas `https://` — caminhos relativos são inválidos em dados estruturados.
  • Inclua sameAs para organizações: vincule seu esquema Organization à Wikipédia, Wikidata, LinkedIn e outras fontes de autoridade para fortalecer a associação ao grafo de conhecimento.
  • Monitore o Google Search Console: confira os relatórios de Melhorias semanalmente — eles mostram quais páginas têm dados estruturados válidos, com avisos ou com erros conforme o Googlebot as rastreia.

Note

Dados estruturados são lidos por mais que o Google. Microsoft Bing, Rich Pins do Pinterest e previews de link do Slack usam todos dados estruturados do schema.org para suas exibições enriquecidas. Uma estratégia de esquemas bem implementada beneficia toda plataforma que consome suas páginas, não só a Pesquisa Google.

Key takeaways

  • Verifique dados estruturados buscando `application/ld+json` no código-fonte da página — cada tag script com esse tipo é um bloco de dados estruturados.
  • Use o validador de dados estruturados durante o desenvolvimento para validação JSON-LD instantânea e local no navegador, sem enviar nenhuma URL.
  • O Teste de Resultados Ricos do Google é a ferramenta autoritativa para elegibilidade — rode-o depois de a validação local estar limpa, não no lugar dela.
  • Os erros mais comuns são propriedades obrigatórias ausentes, tipos de valor incorretos (strings onde números são esperados) e URLs relativas onde URLs HTTPS absolutas são exigidas.
  • Gere marcação de esquema correta para os tipos FAQPage, HowTo, BreadcrumbList e Product usando os geradores e validadores dedicados do Aback Tools.
  • Dados estruturados devem corresponder ao conteúdo visível da página — incompatibilidades entre valores do esquema e valores exibidos arriscam ações manuais do Google contra a elegibilidade.
  • Monitore a seção Melhorias no Google Search Console após o deploy para acompanhar itens válidos, avisos e erros conforme o Googlebot rastreia suas páginas.

Perguntas frequentes

The fastest way is to right-click the page, select View Page Source, and search for "application/ld+json". Each script tag with that type contains a structured data block. Alternatively, open Chrome DevTools, go to the Network tab, reload the page, find the HTML document response, and search for "schema.org" in the response body. For a visual summary, use a browser extension like Schema Markup Validator or submit the URL to Google's Rich Results Test.

Google's Rich Results Test (search.google.com/test/rich-results) is the authoritative tool for checking rich result eligibility - it shows exactly which features your markup qualifies for. For faster, privacy-first validation without submitting a URL, the Aback Tools Structured Data Validator checks your JSON-LD block entirely in the browser with line-level error reporting. Use both: the Aback Tools validator during development and Google's tool before deployment.

JSON-LD (JavaScript Object Notation for Linked Data) is the W3C standard format for embedding structured data in web pages. You place a `<script type="application/ld+json">` tag in the `<head>` of your HTML document containing a JSON object that describes the page content using schema.org vocabulary. Google, Bing, and other search engines read this script tag to understand the page and generate rich results - star ratings, FAQ accordions, recipe cards, and breadcrumb trails in search results.

The most frequent errors are missing required properties (a `Product` schema without `name` or `offers`, an `Article` without `headline`), incorrect value types (a number where a URL is expected), invalid enum values (a `priceValidUntil` date in the wrong format), missing `@context` or `@type` declarations, and mismatched types (using `FAQPage` markup on a page that is not an FAQ page). Google also flags "soft errors" - missing recommended properties that do not block rich results but reduce their quality.

Structured data does not directly improve rankings - Google has stated it is not a ranking signal. Its value is in rich result eligibility: pages with correct structured data can appear as FAQ accordions, product panels with ratings and price, event listings, recipe cards, and How-to carousels in Google Search. These rich features increase click-through rate significantly, which has an indirect positive effect on organic performance. Structured data is also used by Google's AI Overviews for sourcing cited information.

Copy the JSON-LD block from your template or build output and paste it into the Aback Tools Structured Data Validator - it validates the schema without needing a live URL. For full rich-result eligibility testing, Google's Rich Results Test accepts either a URL or raw HTML - paste the entire `<head>` section of your page into the code input and it will extract and validate the structured data without the page being publicly accessible.

Yes. A page can have multiple `<script type="application/ld+json">` tags, each containing a separate schema type. A blog post page might include an Article schema, a BreadcrumbList schema, and an FAQPage schema simultaneously. Google reads all of them independently and applies whichever rich result features each schema qualifies for. The schemas must not contradict each other - the page name, URL, and author should be consistent across all blocks on the same page.

All three are formats for embedding structured data in HTML, but they differ in approach. JSON-LD places the schema in a standalone script tag, separate from the visible HTML - making it easy to add, maintain, and validate without touching the page content. Microdata and RDFa annotate existing HTML elements with schema attributes, tightly coupling the markup to the page structure. Google supports all three formats, but officially recommends JSON-LD for most use cases because it is the easiest to implement and maintain.

ShareXLinkedIn