Guia de Schema.org e JSON-LD para dados estruturados

Selecione o objeto que é realmente descrito na página, preencha suas propriedades e obtenha o código JSON-LD para inserir no HTML. O gerador ajuda a construir a sintaxe, mas antes da publicação é necessário verificar a conformidade com o conteúdo visível, os requisitos do consumidor de dados escolhido e a atualidade dos valores.

Schema.org, JSON-LD e o resultado enriquecido são coisas diferentes

Schema.org

É um vocabulário comum de tipos e propriedades: Article, Product, Organization, Event, name, image, offers e muitos outros. Ele descreve quais entidades e relacionamentos podem ser representados de forma estruturada.

JSON-LD

É um dos formatos para escrever dados estruturados. O código é colocado dentro de:

O Google recomenda JSON-LD quando é adequado para a implementação, mas o Schema.org também pode ser escrito com Microdata ou RDFa.

Resultado enriquecido do Google

É uma apresentação especial nos resultados de pesquisa que suporta apenas um conjunto limitado de tipos e exige a conformidade com regras específicas do Google. Uma marcação Schema.org válida não garante um resultado enriquecido, uma classificação elevada ou mesmo o uso de todas as propriedades enviadas. Portanto, não se deve avaliar a marcação apenas com a pergunta "vai mostrar um snippet bonito?". Ela deve, acima de tudo, descrever corretamente a entidade real da página.

Como escolher o tipo de marcação

Escolha o tipo de acordo com o objeto principal da página, não com a aparência desejada na pesquisa.

Em uma página, vários objetos relacionados são permitidos. Por exemplo, um artigo pode ter um autor Person, um editor Organization, migalhas de pão BreadcrumbList e um vídeo incorporado VideoObject. É melhor vinculá-los via @id em vez de criar cópias contraditórias.

Restrições importantes e atuais do Google

FAQPage

O Google limitou significativamente a exibição de resultados enriquecidos de FAQ: eles geralmente estão disponíveis apenas para sites governamentais e médicos de alta autoridade. Para um site comercial ou informativo comum, uma marcação FAQPage correta pode não gerar uma expansão notável nos resultados. Isso não torna o tipo FAQPage inválido no Schema.org, mas não se pode prometer ao usuário que "as perguntas aparecerão no Google".

HowTo

O Google parou de exibir resultados enriquecidos de HowTo. O tipo HowTo permanece no vocabulário Schema.org e pode ser usado por outros consumidores, mas adicioná-lo exclusivamente para o antigo resultado enriquecido do Google não faz mais sentido.

Outros tipos

Organization, Person e WebSite ajudam a descrever entidades, mas nem todos criam um resultado enriquecido visual separado. O suporte e a aparência dos recursos de pesquisa mudam, portanto, antes de implementar, verifique a galeria atual do Google Search Central.

Regra principal: a marcação deve corresponder ao conteúdo visível

Não adicione em JSON-LD informações que estejam ausentes na página ou que a contradigam. Isso se aplica especialmente a:

• preço e disponibilidade do produto;
• classificação e número de avaliações;
• perguntas e respostas;
• data e local do evento;
• autor do material;
• endereço e horário da empresa;
• condições da vaga;
• ingredientes e etapas da receita.

A marcação não é um local para texto publicitário oculto ou palavras-chave adicionais. O usuário e o mecanismo de pesquisa devem receber informações consistentes.

Os campos obrigatórios dependem de quem lê a marcação

O Schema.org define um vocabulário, mas não uma lista universal única de "campos obrigatórios" para todos os sistemas. Um consumidor específico, como o Google Search, estabelece suas próprias propriedades obrigatórias e recomendadas para uma determinada função de pesquisa. Portanto, três resultados de validação diferentes são possíveis:

1. O JSON é sintaticamente correto.
2. Os tipos e propriedades existem no Schema.org.
3. A marcação atende aos requisitos do resultado enriquecido específico do Google.

A aprovação na primeira ou segunda etapa não garante a terceira.

Como preencher URLs, datas e identificadores

Use URLs absolutas

Preferencialmente:

Em vez de:

Os links devem ser acessíveis ao robô de busca, não exigir autenticação e apontar para um recurso estável.

Indique as datas no formato ISO 8601

Data:

Data e hora com fuso horário:

Para eventos, é especialmente importante não perder o fuso horário. Caso contrário, a hora pode ser interpretada incorretamente.

Crie um @id estável

@id é o identificador da entidade, geralmente na forma de URL com fragmento:

A mesma organização em páginas diferentes deve fazer referência a um identificador estável, e não parecer várias empresas independentes.

Como descrever várias entidades com @graph

Para objetos relacionados, é conveniente usar um único bloco:

Assim, os objetos estão explicitamente vinculados e não é necessário repetir todas as informações sobre a organização dentro de cada artigo.

Onde inserir JSON-LD

O bloco <script type="application/ld+json"> pode ser colocado no <head> ou <body> da página HTML. É mais importante que:

• o código esteja presente no HTML final ou seja acessível após a renderização correta;
• se refira especificamente à página atual;
• o CMS o escape sem danificar aspas e caracteres;
• um mesmo modelo não insira os mesmos dados em páginas diferentes;
• o preço dinâmico, a disponibilidade e as datas sejam atualizados junto com o conteúdo visível.

Após a implementação, verifique não apenas o código do gerador, mas também a URL publicada: o modelo, um plugin ou JavaScript podem modificar a marcação final.

Dois níveis diferentes de validação

Schema Markup Validator

Verifica a sintaxe e o uso do vocabulário Schema.org. É adequado para ver os tipos encontrados, propriedades e problemas gerais da marcação.

Google Rich Results Test

Mostra se o Google reconhece na página um tipo de resultado enriquecido compatível e se seus requisitos especiais são atendidos. A ferramenta não confirma que o enriquecimento aparecerá na pesquisa. Após a publicação, também é útil verificar a URL por meio da inspeção de URL no Google Search Console para ver a versão processada pelo Google e os elementos detectados.

Erro e aviso não são categorias universais

Um validador pode considerar a ausência de uma propriedade como um aviso, enquanto ela se torna obrigatória para um consumidor específico. E vice-versa, o Schema.org permite uma propriedade que o Google não usa para a função desejada. Avalie a mensagem com base em quatro perguntas:

1. A sintaxe JSON está quebrada?
2. O tipo e a propriedade existem no Schema.org?
3. A propriedade está aninhada corretamente e tem um valor válido?
4. É exigida pela função de pesquisa escolhida ou por outra integração?

Erros frequentes

• Tipo inadequado: a página de categoria de produtos é marcada como um único Product, embora não haja um produto individual nem uma oferta única. Ou um artigo comum recebe FAQPage apenas porque há um pequeno bloco de perguntas no final.
• A marcação não corresponde à página: no código, constam um preço antigo, uma classificação inexistente, perguntas ocultas ou outro autor.
• Entidades conflitantes: vários plugins criam blocos Organization diferentes com nomes, logotipos e URLs divergentes. Os objetos não estão vinculados por um @id comum.
• Aninhamento incorreto: por exemplo, price é escrito diretamente em Product, embora a oferta geralmente seja descrita por meio de um objeto Offer na propriedade offers.
• Tipo de valor incorreto: a data é escrita como texto arbitrário, o preço contém a moeda na mesma string, o valor booleano é passado como uma frase e o campo que espera uma URL contém um caminho relativo.
• Imagens e páginas inacessíveis: a URL retorna um erro, está bloqueada por autenticação ou robots.txt, aponta para um link temporário instável ou para uma imagem que o mecanismo de busca não pode recuperar.
• Dados dinâmicos desatualizados: o evento já terminou, a vaga está preenchida, o produto não está disponível, mas a marcação continua transmitindo o status antigo.
• Erros de JSON: aspas simples ou tipográficas; vírgula extra após a última propriedade; colchete não fechado; comentários dentro do JSON; quebra de linha não tratada dentro de um valor de string; chave duplicada em um mesmo objeto.

Fluxo de trabalho para implementação

1. Identifique o objeto principal e o propósito da marcação.
2. Verifique os requisitos atuais do Schema.org e do consumidor de dados necessário.
3. Selecione o tipo mais preciso.
4. Preencha apenas as propriedades confiáveis que estão presentes na página.
5. Gere o JSON-LD.
6. Valide o código no Schema Markup Validator.
7. Se precisar de um resultado enriquecido compatível com o Google, verifique no Rich Results Test.
8. Insira o código em uma versão de teste da página.
9. Verifique novamente a URL publicada, não apenas o fragmento isolado.
10. Configure a atualização de valores dinâmicos e novas verificações após alterações no modelo.

Lista de verificação rápida antes de publicar

• o tipo de objeto real da página foi selecionado;
• os dados correspondem ao conteúdo visível;
• não há classificações, avaliações ou propriedades inventadas;
• as URLs são absolutas, acessíveis e canonicamente consistentes;
• as datas estão em formato claro e com fuso horário quando necessário;
• o preço e a moeda estão em campos separados;
• as mesmas entidades estão vinculadas por meio de um @id estável;
• não há marcação conflitante de outro módulo;
• o código passou pelas validações apropriadas;
• a URL publicada contém o mesmo JSON-LD correto;
• os dados dinâmicos serão atualizados.

Perguntas frequentes

O Schema.org garante um snippet enriquecido?

Não. Uma marcação correta torna a página processável, mas o mecanismo de pesquisa decide de forma independente se a usa e como exibir o resultado.

É necessário adicionar Schema.org em todas as páginas?

Apenas onde houver uma entidade e propriedades úteis e confiáveis para descrevê-la. A inserção em massa do mesmo bloco sem relação com o conteúdo gera erros e contradições.

Posso deixar propriedades que o usuário não vê?

Os relacionamentos técnicos e identificadores podem não ser exibidos como texto separado, mas as informações factuais sobre o produto, classificação, perguntas, evento e outros objetos devem corresponder ao conteúdo acessível ao usuário e às regras do consumidor.

Onde colocar o código – no head ou no body?

O JSON-LD pode estar em ambos os lugares. O importante é o HTML final correto, a acessibilidade da marcação para o processador e a coerência com a página atual.

Por que o Schema Markup Validator não mostra erro, mas o Google mostra?

A primeira ferramenta verifica o vocabulário Schema.org e a estrutura da marcação, enquanto o Google aplica adicionalmente os requisitos específicos da função de pesquisa.

Vale a pena marcar FAQPage atualmente?

Pode ser feito quando a página é realmente uma FAQ e o tipo é útil para outros consumidores de dados. Mas para a maioria dos sites, não se deve esperar o resultado enriquecido de FAQ do Google.

O HowTo é necessário para o Google?

O Google não exibe mais resultados enriquecidos de HowTo. O tipo pode continuar útil como descrição semântica para outros sistemas, mas não se deve esperar o efeito anterior de pesquisa do Google.

Ferramentas relacionadas

Diffchecker; Processador de textos; Base64.

Materiais oficiais

• Vocabulário Schema.org
• Google Search Central — Introdução aos dados estruturados
• Google — Diretrizes gerais de dados estruturados
• Google — Galeria de recursos de dados estruturados
• Schema Markup Validator
• Google Rich Results Test

Recomendações editoriais gerais para a seção

1. Não duplicar o mesmo bloco comercial dentro de cada texto útil

O bloco atual sobre "auditoria SEO completa, ferramentas para o crescimento da visibilidade em IA e automação" pode ser deixado como um CTA visual separado após o material principal. Não deve ser incorporado à estrutura do artigo entre seções úteis: isso interrompe o fluxo de leitura e parece igual em todas as nove páginas. É melhor usar um link curto e contextual que corresponda à ferramenta. Por exemplo:

• após o gerador de UTM — para relatórios por canal e conversões;
• após o combinador — para verificação de frequência, clustering e atribuição de consultas a páginas;
• após Schema — para auditoria de dados estruturados;
• após Diffchecker — para monitoramento de alterações em páginas;
• após a remoção de duplicados — para importação de semântica ou URLs para o projeto.

2. Não criar seções idênticas de "Vantagens" e "Para quem é" por modelo

Seu conteúdo quase sempre se transforma em repetições: "rápido", "prático", "gratuito", "para profissionais de marketing e especialistas". É mais útil deixar cenários concretos, limitações, exemplos e perguntas frequentes. As características breves como "gratuito", "no navegador", "sem registro" já são mostradas ao lado da ferramenta.

3. Alinhar as promessas com a implementação real

Antes de publicar, os desenvolvedores devem confirmar:

• o processamento é feito inteiramente no navegador ou os dados são enviados ao servidor;
• quais são os limites de volume de texto e número de linhas;
• os dados originais ou resultados são mantidos;
• qual algoritmo e biblioteca são usados para a detecção de idioma;
• como exatamente o Diffchecker compara palavras e linhas;
• a remoção de duplicados diferencia maiúsculas de minúsculas e espaços, e em que ordem as ações são aplicadas;
• o gerador de senhas usa uma fonte de aleatoriedade criptograficamente segura;
• qual codificação o conversor Base64 utiliza;
• ele suporta Base64url ou apenas Base64 padrão.

Após a confirmação, esses detalhes podem ser incluídos em um breve bloco "Processamento e privacidade" em cada página. Não se pode prometer processamento local e ausência de armazenamento apenas porque a ferramenta funciona visualmente no navegador.

4. Mostrar as limitações ao lado da função, não escondê-las no final

Avisos especialmente importantes:

• os parâmetros UTM não são colocados em links internos;
• o Diffchecker não verifica o significado nem a correção factual;
• o combinador não confirma a demanda nem cria automaticamente a estrutura do site;
• o Base64 não criptografa dados;
• uma URL inteira não deve ser convertida em minúsculas sem verificação;
• uma senha não pode ser considerada criptograficamente segura sem verificar o gerador;
• um Schema.org válido não garante um resultado enriquecido.

5. Adicionar links internos de acordo com a próxima ação do usuário

Em vez de uma lista geral de todas as utilidades no final da página, coloque dois ou três links realmente relacionados. O nome do link deve explicar a continuação do cenário: "Limpar a lista obtida", "Comparar duas versões", "Remover combinações duplicadas", "Verificar o idioma do texto".

6. Não marcar FAQ apenas para prometer um snippet enriquecido

O FAQ nesses textos é útil para o usuário e pode permanecer na página. Mas a decisão de adicionar FAQPage deve ser tomada separadamente, considerando as regras do Schema.org e as limitações atuais dos mecanismos de pesquisa. Para sites comuns, o Google geralmente não exibe resultados enriquecidos de FAQ.

7. Ordem recomendada para a implementação

1. Diffchecker, detecção de idioma e UTM — atualmente, têm menos material útil.
2. Remoção de duplicados — corrigir urgentemente o conselho de converter todas as URLs para minúsculas.
3. Base64 — substituir "descriptografar" por "decodificar" e adicionar Base64url.
4. Gerador de senhas — atualizar as recomendações de comprimento e verificar a implementação da geração aleatória.
5. Schema.org — substituir o texto atual excessivamente longo e repetitivo por um guia mais compacto, mas tecnicamente preciso.
6. Combinador e processador de textos — manter as partes sólidas, adicionar limitações e uma ordem prática de ações.