A maioria dos sites que rodam JSON-LD hoje falharia em um teste básico de sanidade: colar os dados estruturados em um validador e ver o que realmente sai dali. Não "está otimizado". Apenas: o parser consegue ler. Aponta para uma única entidade ou para três que se contradizem. É markup para um rich result que o Google ainda concede.
Schema virou item de checklist — instala-se um plugin, copia-se um template de algum post de blog, e todo mundo presume que está funcionando porque nada mudou visivelmente na página. Falhas em dados estruturados são invisíveis por natureza. Não há layout quebrado para notar. Existe apenas um Knowledge Graph que nunca entende direito quem você é, rich results que nunca aparecem, e ninguém investigando o problema porque nada parece errado.
O que o JSON-LD realmente faz em 2026
Duas funções diferentes são misturadas sob o termo "schema markup", e confundir as duas é onde começa boa parte do esforço desperdiçado.
A primeira função são os rich results: os destaques visuais na SERP — avaliações em estrelas, faixas de preço, datas de eventos, vagas de emprego, breadcrumbs, miniaturas de vídeo. Apenas um conjunto restrito de @types se qualifica, e o Google muda esse conjunto sem muito aviso.
A segunda função é a clareza de entidade: dizer ao Google quem você é, do que você faz parte, e como suas páginas se relacionam entre si. Organization, WebSite, Person e WebPage cumprem principalmente essa função. Raramente geram um snippet visível por conta própria, mas são a base de onde vêm o Knowledge Panel, a sitelinks search box e a desambiguação de marca.
A maioria dos erros de schema que vale a pena corrigir se encaixa em uma de três categorias, e nenhuma delas é sutil depois que você sabe onde olhar.
Erro 1: JSON quebrado por escaping incorreto no template
Essa é a falha mais comum e a menos visível. Ela acontece na costura entre o seu CMS e a sua tag <script type="application/ld+json">.
Uma citação de avaliação com uma aspa dupla perdida no meio. Uma descrição de produto colada de uma ficha técnica com uma quebra de linha bruta no meio do texto. Qualquer uma dessas, jogada em um template de JSON-LD via concatenação ingênua de strings em vez de serialização adequada, produz algo assim:
{
"@type": "Product",
"name": "Editor's Choice Desk Lamp",
"description": "The reviewer called it "the best lamp under $50""
}
Essa aspa dupla interna sem escape quebra o parser JSON exatamente nesse ponto. O Rich Results Test do Google vai sinalizar isso como inválido — mas esse teste geralmente é rodado uma única vez, no lançamento, contra uma URL escolhida a dedo. Ninguém roda de novo contra as 400 páginas de produto que vão ao ar seis meses depois, com os hábitos de pontuação de um novo redator.
A correção não é complicada: nunca monte a string JSON manualmente. Construa o objeto na sua linguagem de templates e serialize-o corretamente (JSON.stringify em JS, json_encode em PHP, o equivalente no que quer que renderize suas páginas), para que o escaping seja tratado por um código que sabe o que é JSON, não por quem escreveu o template e não sabe. Depois valide o HTML renderizado — a resposta real que um crawler vê — não o código-fonte do template. Um template pode parecer perfeito e mesmo assim gerar um JSON quebrado para qualquer string com um caractere especial.
Erro 2: Entidades Organization duplicadas sem @id compartilhado
Esse aparece quase toda vez que um site passou por um redesign, uma migração de CMS, ou tem mais de um plugin de SEO rodando ao mesmo tempo.
O tema emite um bloco Organization no rodapé. Um plugin emite outro em todas as páginas, com um logo e uma lista sameAs ligeiramente diferentes. Um desenvolvedor adicionou um terceiro, manualmente, na home, dois anos atrás, para um teste de schema markup que nunca foi limpo. Nenhum deles compartilha um @id.
Para o Google, três objetos Organization sem um identificador compartilhado não são lidos como "uma empresa descrita três vezes". São lidos como ambíguos — possivelmente três entidades diferentes, possivelmente sinais duplicados que se anulam. Essa ambiguidade é exatamente o que o markup de entidade deveria evitar.
A correção é um único @id canônico, criado uma vez e referenciado em todo lugar:
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/example"]
}
Todas as outras páginas passam então a referenciar esse @id em vez de repetir o objeto inteiro — o publisher de um WebSite, o author ou publisher de um Article, o isPartOf de um WebPage. Uma entidade, um conjunto de fatos, referenciado de forma consistente. Isso é modelagem de grafo, não decoração, e é a diferença entre o Google unificar seus sinais ou ficar em dúvida sobre qual versão sua confiar.
Erro 3: Tipos de schema que pararam de gerar qualquer resultado
O Google restringiu os rich results de FAQ em agosto de 2023 a um pequeno grupo de sites governamentais e de saúde, e depois removeu o recurso da Busca por completo — essa exceção também acabou. O markup FAQPage continua sendo copiado e colado em bibliotecas de templates e plugins de CMS como boa prática padrão, e muitos sites B2B e de e-commerce continuam publicando esse markup, sem ganhar nada com isso, e em alguns casos se expondo a um risco real: se o texto de FAQ marcado não corresponder ao que está visível na página, isso é uma violação das diretrizes de dados estruturados, não apenas markup desperdiçado. Os rich results de HowTo desapareceram da mesma forma — removidos do mobile em 2023, depois do desktop, sem nenhuma superfície onde o tipo ainda gere um resultado visível.
O padrão a observar não é apenas "esse tipo está obsoleto". É markup que foi copiado de um template há três anos e nunca foi revisado à luz do que aquele tipo faz atualmente. O vocabulário do Schema.org é estável; a disposição do Google em renderizar qualquer tipo específico como rich result não é, e isso muda em um cronograma que ninguém te avisa.
O que ainda garante um rich result
A lista que compensa de forma confiável em 2026: Product com preço real, disponibilidade, e AggregateRating vindo de avaliações genuínas daquele produto específico (a política de review snippets do Google proíbe explicitamente avaliações autopromovidas — uma empresa avaliando o próprio produto —, então as avaliações precisam ser de clientes reais, não fabricadas); BreadcrumbList; VideoObject; JobPosting; Event; Recipe; e SoftwareApplication com um applicationCategory válido. Junto a esses, Organization e WebSite com uma estrutura de @id limpa e sem duplicação continuam cumprindo o trabalho mais silencioso de clareza de entidade e elegibilidade para a sitelinks search box, mesmo sem um snippet visível próprio.
Uma auditoria mínima que vale rodar trimestralmente
- Valide a resposta HTML renderizada, não o arquivo de template — bugs de escaping só aparecem depois da renderização.
- Faça um grep no seu código em busca de todo lugar onde
OrganizationouWebSiteé emitido. Se houver mais de um, consolide atrás de um@idcompartilhado. - Confira cada
@typeque você usa contra a documentação atual de dados estruturados do Google, não contra o post de blog de onde você copiou. - Verifique os relatórios de Aprimoramentos do Search Console mensalmente — um pico em erros de "JSON-LD inválido" ou "Campo ausente" geralmente indica um deploy, não uma mudança de política do Google.
- Confirme que toda afirmação marcada (uma nota de avaliação, uma resposta de FAQ, um preço) está visível na página na mesma forma. Markup sem conteúdo visível correspondente é uma violação de diretrizes esperando para ser notada.
Conclusão
Dados estruturados são infraestrutura, não decoração — e falham do jeito que infraestrutura falha: silenciosamente, até que uma auditoria ou uma ação manual traga o problema à tona. Os sites que conseguem rich results em 2026 não são os que têm mais schema. São os que têm um JSON que realmente é lido corretamente, cujas entidades resolvem para um único @id, e cujo markup corresponde ao que uma pessoa vê na página.
Se você quer isso verificado direito — a saída renderizada, não o código-fonte do template — nossa equipe de SEO roda a validação de dados estruturados como parte padrão de toda auditoria técnica, junto com o trabalho de rastreabilidade e Core Web Vitals que normalmente aparece bem ao lado disso.
