Como implementar schema markup passo a passo (JSON-LD)

Já sabes o que é o schema markup e porque importa. A dúvida que provavelmente te trouxe aqui é outra: como implementá-lo sem perder meia tarde a rever a especificação do schema.org tipo a tipo. Se queres perceber primeiro o que são os dados estruturados e a marcação JSON-LD.

Este é o complemento prático: que formato usar, que tipos priorizar consoante o teu negócio, como colocá-lo no teu site conforme a plataforma que usas, e como confirmar que não o partiste antes de publicar.

Antes de implementar schema markup: o que decidir primeiro

Antes de mexer em código convém resolver duas decisões que condicionam tudo o resto: que formato usar e que tipos de schema marcar. Saltar este passo costuma acabar em páginas com schema a mais nos sítios errados e schema ausente onde de facto importa.

Escolhe o formato: porque é que o JSON-LD é a opção recomendada

Existem três formatos suportados para marcar dados estruturados: JSON-LD, Microdata e RDFa. A Google recomenda JSON-LD para projetos novos, e é isso que indica na sua introdução oficial aos dados estruturados.

A razão prática é que o JSON-LD vive num bloco de script independente, separado do HTML visível: podes acrescentá-lo, editá-lo ou removê-lo sem tocar na marcação da página, algo que com Microdata ou RDFa implica editar os atributos de cada etiqueta HTML uma a uma. Microdata e RDFa continuam válidos, mas se começas do zero não há qualquer razão para os escolher em vez de JSON-LD.

Que tipos de schema priorizar consoante o teu negócio

O schema.org define mais de 800 tipos. Tentar cobri-los todos é a forma mais rápida de acabar com um JSON-LD inchado e mal mantido. Na maioria dos sites B2B e B2C, seis tipos cobrem praticamente tudo o que é relevante:

Começa pelo que responde diretamente ao tipo de página que tens à frente: Product numa ficha de produto, Article num artigo de blog, LocalBusiness na página de contacto de um negócio físico. Organization costuma ir à parte, ao nível do site, para não o duplicares em cada URL.

Como implementar JSON-LD passo a passo

1. Escolhe o tipo de schema que corresponde ao conteúdo real da página, não ao que gostarias de ter.
2. Constrói o bloco <script type="application/ld+json"> com as propriedades obrigatórias e as recomendadas que sejam relevantes para esse tipo.
3. Coloca-o no <head> ou no <body> da página; a Google aceita ambas as localizações, por isso a decisão costuma depender das limitações do teu CMS.
4. Se for Organization, define-o uma única vez ao nível do template do site, não o repitas em cada página: isso só acrescenta peso sem trazer nada de novo.
5. Verifica que cada dado marcado coincide exatamente com o conteúdo visível da página. Esta regra não é opcional: está nas diretrizes gerais de dados estruturados da Google, e é a causa mais habitual de uma marcação tecnicamente válida não servir para nada.

Um exemplo mínimo de Organization, o ponto de partida mais comum:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "A tua empresa",
  "url": "https://tuweb.com",
  "logo": "https://tuweb.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/tuempresa",
    "https://twitter.com/tuempresa"
  ]
}

Como implementar schema markup consoante a tua plataforma

WordPress

Plugins como o Yoast SEO ou o Rank Math geram JSON-LD automaticamente para Organization, Article e BreadcrumbList a partir da configuração do site e dos campos do próprio artigo.

Cobrem bem os tipos genéricos, mas para Product, LocalBusiness com dados específicos ou Review vais ter de ver se o plugin permite editar as propriedades diretamente ou se convém inserir o bloco manualmente através de um bloco de código ou de um campo personalizado.

Shopify

O Shopify inclui Product e BreadcrumbList por omissão na maioria dos temas, gerados a partir da ficha do produto. O ponto que mais falha é Organization: muitas lojas deixam-no por marcar porque não há um sítio evidente no painel para o fazer, e costuma exigir editar o ficheiro theme.liquid ou usar uma app dedicada.

Sites sem CMS ou HTML direto

Sem plugin pelo meio, o processo é o mais simples dos três: colar o bloco <script type="application/ld+json"> diretamente no HTML de cada template. A vantagem é o controlo total sobre o que se marca; a desvantagem é que qualquer alteração de conteúdo (um preço, uma morada) tem de ser atualizada à mão em dois sítios, o visível e o schema, ou a marcação deixa de coincidir com a página.

Erros comuns que estragam o resultado enriquecido

• Propriedades obrigatórias incompletas: por exemplo, um Product sem AggregateRating quando o tipo o exige para ser elegível.
• JSON mal formado: uma vírgula a mais ou uma aspa por fechar invalida o bloco inteiro, mesmo que o resto esteja correto.
• Dados marcados que não são visíveis para o utilizador na página: contradiz diretamente as diretrizes da Google.
• Entidades duplicadas: o mesmo Organization definido de formas diferentes em várias páginas do site.

Há um erro que não aparece em nenhum validador e que só se deteta olhando para a página real: um JSON-LD copiado de um gerador online que valida sem erros de sintaxe mas descreve dados que não existem nessa página em concreto.

Como validar a tua implementação

Antes de publicar, passa a página pelo Rich Results Test da Google. Diz-te se a marcação é sintaticamente válida e se é elegível para algum resultado enriquecido, embora elegibilidade não seja garantia de aparecer.

Depois de publicar, o trabalho não termina: o Search Console e a sua ferramenta de inspeção de URLs permitem-te monitorizar se a marcação continua válida ao longo do tempo, porque uma mudança de template pode parti-la semanas depois mesmo que o código original estivesse correto.

Se queres uma fotografia completa de como estes erros afetam o teu site (não só o schema, mas também o acesso dos rastreadores e a legibilidade do conteúdo), o diagnóstico técnico gratuito da Parsigo revê a cobertura e a validade do schema markup existente dentro do seu pilar de estrutura, juntamente com o resto das verificações sobre como te leem os rastreadores, incluindo os dos assistentes de IA.

Não substitui o Rich Results Test para validar sintaxe, mas dá-te contexto de onde encaixa esse erro dentro do conjunto.

O que o schema markup não promete

A Google confirmou repetidamente que a marcação estruturada não é um fator de posicionamento direto. A sua função é tornar um conteúdo elegível para um resultado enriquecido, nunca garantir que apareça: os próprios documentos oficiais incluem esse aviso de forma explícita.

O caso do FAQPage é o exemplo mais claro desta nuance. Desde 7 de maio de 2026, o resultado enriquecido de FAQ deixou de aparecer na Google Search, como confirma a própria documentação de FAQ structured data da Google e como recolhe também o Search Engine Journal com o calendário completo: o relatório do Search Console e o suporte no Rich Results Test são retirados em junho de 2026, e o suporte na API do Search Console em agosto de 2026.

O tipo FAQPage continua válido no schema.org e a Google pode continuar a interpretá-lo (útil para outros sistemas que leem o teu site, não só a Google Search), mas já não gera o menu expansível nos resultados de pesquisa. Se estás a priorizar que tipos implementar agora, o FAQPage já não deve ser um dos que escolhes a pensar em ganhar espaço visual na SERP.

Perguntas frequentes sobre como implementar schema markup

Antes de publicar: checklist mínima

• O formato usado é JSON-LD.
• Os tipos implementados correspondem ao conteúdo real da página, sem marcar tipos a mais.
• Cada propriedade marcada coincide com o que o utilizador vê na página.
• O bloco passou o Rich Results Test sem erros críticos.
• O Organization está definido uma só vez ao nível do site, não duplicado.