O Verificador de Dados Estruturados da Screpy examina JSON-LD de uma página pública ou de código colado. Identifica erros de análise, lista entidades declaradas e assinala problemas em propriedades selecionadas de cinco tipos de schema suportados. Use o relatório para decidir o que corrigir e o que precisa de uma verificação mais abrangente. Sintaxe válida, verificações suportadas e elegibilidade para um resultado avançado do Google são questões distintas; um estado verde não responde às três.
Escolha um URL de página ou JSON-LD colado
Selecione URL da página para examinar uma página publicada, como uma ficha de produto ou uma página de contacto da empresa. Introduza o endereço público HTTP ou HTTPS dessa página em vez de usar sempre a página inicial: modelos diferentes podem conter marcação diferente. O modo URL lê o HTML devolvido pela página. Uma página privada ou protegida por palavra-passe não fornece a mesma evidência pública; uma falha ao obtê-la não prova que os seus dados estruturados estejam incorretos.
Selecione Colar código para rever um rascunho, um script extraído ou HTML que já tem disponível. Escolha JSON-LD para o próprio JSON, sem um elemento <script> à volta. Escolha HTML quando a entrada contém blocos <script type="application/ld+json">. O endereço de um ficheiro JSON independente não é uma página HTML; cole o conteúdo no modo JSON-LD. A entrada colada está limitada a 256 KiB medidos em bytes UTF-8, pelo que a quantidade de caracteres permitida depende do texto.
As verificações por URL não executam JavaScript. A marcação inserida depois de a página carregar pode faltar no código-fonte obtido. O Google pode processar JSON-LD inserido dinamicamente, pelo que um bloco ausente neste relatório não prova que o Google também não o veja. Examine a marcação renderizada relevante ou use o teste de funcionalidades do Google quando esta distinção for importante. Colar código verifica o que forneceu, sem confirmar o que a página publicada apresenta.
Leia o relatório de dados estruturados
Comece pela cobertura, depois leia as observações e a tabela de entidades. Blocos JSON-LD conta os scripts detetados no HTML; JSON-LD colado é tratado como um bloco. Entidades conta os objetos retidos com tipo declarado cujo JSON foi analisado com sucesso; um script pode conter várias entidades. Erros de sintaxe conta os blocos processados que não puderam ser analisados. São quantidades diferentes: uma página com três blocos não tem necessariamente três entidades. Num relatório parcial, o número de blocos detetados não prova que todos foram examinados.
Cada linha distingue Sintaxe de Escopo. Sintaxe válida a verde significa que o analisador JSON aceitou o bloco. Verificações suportadas a verde indicam que a entidade cumpriu as condições dos controlos de propriedades selecionadas desta ferramenta. Leia também as observações: nenhuma destas indicações confirma que todas as propriedades estão corretas. O vermelho identifica erros de análise ou observações de erro, o amarelo destaca avisos e cobertura parcial, e o cinzento indica evidência não suportada ou indisponível. Considere o estado escrito juntamente com a cor.
A coluna Caminho ajuda a localizar objetos aninhados. Por exemplo, $.author aponta para o objeto do autor dentro da raiz, enquanto $.@graph[1] aponta para o segundo objeto de uma matriz @graph. Os caminhos são relativos ao respetivo bloco JSON-LD, pelo que o mesmo caminho pode aparecer em vários scripts; o JSON descarregado inclui números de bloco para os distinguir.
A coluna Nome lê name, não a propriedade de apresentação de todos os tipos. Um Article com headline válido pode, por isso, ter a célula Nome vazia. Examine a propriedade e a observação relevantes antes de considerar esse vazio um defeito do conteúdo.
Corrija a sintaxe JSON antes dos avisos de propriedades
Um bloco inválido não fornece observações fiáveis sobre entidades. Repare primeiro o JSON e repita a verificação antes de interpretar avisos de propriedades em falta. Entre as causas comuns estão aspas simples em nomes ou texto, uma vírgula extra depois da última propriedade, um parêntese reto ou uma chaveta de fecho em falta e uma aspa sem escape dentro do texto. JSON usa cadeias entre aspas duplas e vírgulas entre membros; a RFC 8259 define a gramática.
Esta Organization fictícia é um exemplo mínimo de sintaxe para Colar código → JSON-LD:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
O exemplo fornece as duas propriedades que este verificador procura em Organization. Não é um modelo completo para qualquer funcionalidade de pesquisa do Google. Substitua os valores fictícios por informações reais da página e consulte os requisitos da funcionalidade relevante antes de publicar.
JSON válido, por si só, não confirma dados estruturados utilizáveis. Uma cadeia de texto ou um número isolado pode ser JSON válido, mas não descreve a entidade esperada; a ferramenta informa que a raiz precisa de um objeto ou matriz. Da mesma forma, um objeto analisado sem @type declarado pode não produzir linhas de entidades. Verifique a estrutura real antes de acrescentar propriedades apenas para eliminar avisos do relatório.
Que propriedades de schema são verificadas?
O Verificador de Dados Estruturados aplica verificações selecionadas a cinco tipos exatos quando reconhece o contexto. Use a tabela para compreender uma observação, não como lista completa de propriedades Schema.org ou de campos obrigatórios do Google.
| Tipo declarado | O que este verificador examina | Como usar a observação |
|---|---|---|
Organization |
Presença de name e url |
Verifique se descrevem a organização real e o seu site correto. |
LocalBusiness |
Presença de name e address |
Reveja a identidade e o endereço reais da empresa; os componentes do endereço não são totalmente validados. |
Article |
Presença de headline, author, datePublished e image |
Compare os valores com o artigo e reveja os formatos separadamente. |
Product |
Presença de name; fornecimento de algum dos valores offers, review ou aggregateRating |
Use apenas dados do produto verdadeiros e aplicáveis. Não invente uma oferta ou avaliação para remover um aviso. |
BreadcrumbList |
Matriz itemListElement não vazia; position inteiro positivo e name de texto não vazio em cada item examinado |
Corrija o item indicado e verifique depois o percurso de navegação completo e os URL de destino separadamente. |
A maioria são verificações de presença. Um valor pode existir mesmo que o URL, a data, a imagem, a estrutura do objeto ou o conteúdo factual estejam errados. Um objeto vazio pode satisfazer uma verificação de presença; valores constituídos apenas por espaços não são rejeitados em todas as verificações. Um estado suportado não confirma, portanto, que um endereço, autor ou oferta estejam completos.
As verificações de breadcrumbs também examinam os valores selecionados dos itens, mas não confirmam posições sequenciais ou únicas, URL item corretos ou a semântica completa de ListItem. O relatório retém no máximo 100 observações de propriedades por entidade. Um percurso longo ou uma entidade com muitos defeitos repetidos pode precisar de revisão adicional após essas observações.
Corrija uma observação no contexto da página. Se o autor de um artigo é uma pessoa, preserve a estrutura correta do autor mesmo que a Person aninhada apareça fora do âmbito do verificador. Alterar marcação verdadeira apenas para obter indicadores verdes pode esconder o problema original em vez de o resolver.
Porque aparece marcação válida como não suportada ou parcial?
Não suportado significa que a ferramenta não aplicou as suas verificações selecionadas de propriedades à entidade. Não significa que Schema.org proíba o tipo. Por exemplo, um Article suportado pode conter um autor Person aninhado. Article recebe as verificações selecionadas, mas Person aparece como não suportado e torna a cobertura parcial. Restaurant também fica fora dos cinco tipos exatos suportados, embora seja um tipo de empresa mais específico. Mantenha o tipo que descreve corretamente o assunto e use um validador mais abrangente para as verificações restantes.
O contexto pode causar a mesma distinção. Este verificador reconhece um contexto simples http://schema.org ou https://schema.org, com ou sem barra final, incluindo um contexto herdado de um objeto superior. Não resolve contextos de objeto ou matriz. Estas formas podem ser legítimas segundo a especificação W3C de contextos JSON-LD. Quando uma entidade declara vários tipos, todos têm de pertencer ao conjunto suportado para que as propriedades sejam verificadas.
A cobertura também é limitada. O verificador considera os primeiros 50 blocos JSON-LD e retém até 500 linhas de resultados, incluindo linhas de blocos inválidos. Interrompe o percurso além de 32 níveis de aninhamento ou 10 000 valores visitados por bloco. Estes limites podem deixar entidades posteriores sem verificação. Microdata ou RDFa detetados no HTML também tornam o relatório parcial, porque estes formatos não são validados aqui.
Para entradas coladas grandes, divida blocos JSON-LD completos em verificações separadas; não corte um objeto a meio, criando um novo erro de sintaxe. Preserve a fonte original e identifique as partes cobertas por cada relatório. Estas verificações não são combinadas automaticamente numa auditoria completa da página.
Verifique a página após corrigir a marcação
Compare primeiro a marcação com o que um visitante consegue ler na página. Verifique identidades, datas, endereços, detalhes de produtos e eventuais avaliações com base no conteúdo real. As diretrizes do Google para dados estruturados exigem informações relevantes e exatas e o cumprimento dos requisitos aplicáveis às funcionalidades; um analisador não confirma esses factos. Não acrescente detalhes inventados para satisfazer um aviso de propriedade.
Escolha a próxima verificação conforme a questão ainda em aberto. Use o Validador de Marcação Schema.org para uma análise mais abrangente de marcação Schema.org, incluindo Microdata e RDFa. Também tem limites: não obtém nem interpreta outros URL de contexto. Use o Teste de resultados avançados do Google para examinar funcionalidades de pesquisa Google suportadas e os respetivos erros ou avisos. Passar num teste não garante que o Google mostre um resultado avançado.
Se está a preparar marcação empresarial, o Gerador de Schema para Negócios Locais pode produzir JSON-LD a partir dos seus dados reais. Reveja o resultado antes de publicar. Tipos de empresa específicos e objetos PostalAddress aninhados podem continuar não suportados neste verificador; geração e validação selecionada são tarefas distintas.
Depois de aplicar uma correção, repita a verificação relevante na página publicada, não apenas no rascunho. Confirme que a marcação devolvida contém a alteração prevista e compare as observações restantes. Use Descarregar JSON para guardar números de bloco, caminhos das entidades, observações e cobertura dessa execução. Guarde a entrada e o âmbito juntamente com a exportação para que outro revisor compreenda a evidência. Um relatório guardado documenta uma verificação; não monitoriza continuamente futuras alterações de modelos ou conteúdo.