Erros de JSON-LD: como validar dados estruturados?

Um site pode perder todos os rich results de uma vez sem que nenhum alerta apareça no painel, sem queda de indexação e sem nenhuma linha vermelha no relatório de cobertura.

Os erros de JSON-LD funcionam assim: a página continua no ar, o texto continua correto e o Google continua rastreando. Só o bloco de dados estruturados deixa de ser interpretado.

O efeito prático é uma perda de área na SERP. Estrelas, breadcrumbs, informações de produto e cartões enriquecidos somem, e o resultado volta a ser um link azul comum ao lado de concorrentes que mantiveram a marcação legível.

Em agosto de 2026, esse risco cresceu por um motivo específico: o Google apertou a régua de leitura e parou de consertar sozinho um tipo de erro que antes tolerava.

O que são erros de JSON-LD e por que eles passam despercebidos?

Erros de JSON-LD são defeitos no bloco de dados estruturados que impedem o buscador de interpretar a marcação. Podem ser sintáticos, quando o JSON está mal formado, ou semânticos, quando a propriedade não existe no vocabulário ou não corresponde ao conteúdo da página.

A característica que torna esse problema perigoso é a invisibilidade. O bloco de JSON-LD fica dentro de uma tag de script no código-fonte e não é renderizado para o visitante.

Ninguém percebe a falha navegando pelo site. O layout não quebra, a página carrega igual e o time de conteúdo não recebe nenhum sinal de que algo mudou.

Legenda: Quando o bloco de dados estruturados quebra, o buscador descarta a marcação inteira e o resultado enriquecido some da SERP.

O buscador também não reclama de forma proativa. Quando a marcação está ilegível, o comportamento padrão é simplesmente ignorar o bloco, e não registrar um alerta em todos os casos.

A consequência é uma perda que só aparece nos números. O rich result desaparece da SERP, o CTR cai e a hipótese natural do time é atribuir a queda a um core update ou a um concorrente novo.

Vale separar o que o erro faz do que ele não faz. A documentação de políticas de dados estruturados do Google trata marcação enganosa como violação sujeita a ação manual, mas marcação simplesmente quebrada não é penalidade: é ausência.

Essa distinção muda a urgência e o tipo de correção. Página penalizada precisa de revisão de conformidade, enquanto página com marcação quebrada precisa de conserto técnico e nova validação.

O que mudou na extração de JSON-LD do Googlebot?

O Google Search Central comunicou em 21 de agosto de 2026 que passou a aplicar um único passe de unescaping de HTML na extração de JSON-LD. O objetivo declarado foi alinhar o rastreador ao padrão JSON, e o efeito colateral é que marcação fora do padrão deixou de ser corrigida na leitura.

Antes dessa mudança, o parser era tolerante. Quando encontrava entidades HTML escapadas mais de uma vez, aplicava passes sucessivos até chegar a um JSON válido, o que mascarava defeitos de geração.

Agora o comportamento é literal. O rastreador desfaz o escape uma vez e trabalha com o que sobrou, mesmo que o resultado ainda contenha entidades não resolvidas.

O padrão de referência é público. A RFC 8259, que define o formato JSON, estabelece na seção sobre strings quais caracteres precisam de escape e autoriza a notação hexadecimal de seis caracteres iniciada por barra invertida e a letra u.

Um detalhe importa para quem vai investigar isso agora. Segundo o relato da mudança no Search Engine Roundtable, o aviso circulou por canal social do Search Central, sem entrada correspondente no changelog da documentação até aquele momento.

Isso tem uma implicação prática no diagnóstico. Procurar a regra na documentação oficial e não encontrar não significa que a mudança não valha, então a verificação precisa ser feita na ferramenta, e não no texto de apoio.

O grupo de risco é bem definido: sites cuja marcação é montada por template, plugin ou integração, e não escrita à mão. É nesse caminho que a camada extra de escape costuma ser adicionada sem que ninguém peça.

Por que a dupla escapagem quebra o JSON-LD em silêncio?

A dupla escapagem acontece quando um caractere já convertido em entidade HTML é convertido outra vez antes de chegar ao código final. O símbolo de e comercial vira uma entidade, essa entidade tem o próprio e comercial escapado de novo, e o resultado é uma sequência que nenhum dos dois lados sabe desfazer sozinho.

O caminho típico tem três etapas. O redator escreve um caractere especial no CMS, o editor de texto o converte em entidade para exibir corretamente na página, e o template converte de novo ao serializar o campo dentro do JSON-LD.

Cada etapa isolada faz sentido. O problema nasce da soma, porque nenhuma das camadas sabe que a anterior já fez o mesmo trabalho.

O resultado varia conforme onde o caractere caiu. Quando a sequência quebrada está dentro de um valor de texto, o efeito é cosmético e a propriedade chega suja, com o código da entidade aparecendo dentro do rich result.

Quando a sequência quebrada afeta uma aspa ou uma barra invertida, o efeito é estrutural. O JSON deixa de ser válido, o bloco inteiro é descartado e todas as propriedades daquela marcação somem de uma vez.

Os caracteres que mais causam isso em português são previsíveis: o e comercial em nomes de curso e de instituição, as aspas em títulos e depoimentos, o apóstrofo em nomes próprios e os símbolos de maior e menor em textos técnicos.

Existe uma armadilha adicional na inspeção manual. O navegador pode exibir a entidade já resolvida na aba de elementos, então a leitura precisa ser feita no código-fonte bruto ou direto na ferramenta de validação.

A correção não é remover o escape, e sim escapar uma vez só, no padrão certo. Para caracteres especiais dentro de strings JSON, a notação hexadecimal do próprio JSON resolve sem depender de entidade HTML.

Como validar dados estruturados no Rich Results Test?

A validação de dados estruturados precisa de duas ferramentas, porque elas respondem perguntas diferentes. O Rich Results Test do Google informa se a página é elegível a algum recurso enriquecido na Busca, enquanto o Schema Markup Validator informa se a marcação está correta segundo o vocabulário schema.org.

A diferença entre as duas respostas é o que confunde a maioria dos times. Uma marcação pode estar perfeita no validador do schema.org e mesmo assim não gerar rich result nenhum, simplesmente porque o Google não oferece aquele recurso.

O inverso também acontece. Uma marcação pode passar no Rich Results Test com avisos e ainda assim carregar propriedades erradas que prejudicam a interpretação por sistemas que não sejam o Google.

Veja como cada ferramenta se comporta diante dos problemas mais comuns:

Tabela: Comportamento esperado de cada ferramenta diante dos erros de JSON-LD mais frequentes.

A leitura combinada das duas resolve o diagnóstico. Marcação que some no Rich Results Test e acusa sintaxe no validador é caso de escape, e não de vocabulário.

Um cuidado de método faz diferença no teste. Validar pela URL pública reproduz o que o rastreador realmente recebe, enquanto colar o código do template testa a intenção e pode esconder exatamente a camada de escape adicionada na entrega.

Quais erros de JSON-LD mais aparecem em sites com CMS?

Sites gerenciados por CMS concentram um conjunto previsível de erros de JSON-LD, porque a marcação nasce de template e não de escrita manual. O mesmo defeito se replica em milhares de páginas de uma vez, e a correção também: consertar o template conserta o site inteiro.

O primeiro padrão é o campo livre não sanitizado. Um título de curso com e comercial ou um nome com aspas entra direto na propriedade e leva o escape do editor junto.

O segundo é a duplicidade de blocos. Plugin de SEO e tema do site geram marcação do mesmo tipo de forma independente, e a página passa a declarar dois artigos ou duas organizações concorrentes.

O terceiro é a marcação órfã. O template injeta propriedades que não correspondem a nada visível na página, o que aproxima o caso da fronteira de marcação enganosa descrita nas políticas do Google.

O quarto é a data quebrada. Campos de publicação e atualização saem em formato local em vez do padrão internacional, e o buscador descarta a informação sem avisar.

O quinto é o mais recente. Marcação que dependia da tolerância do parser antigo funcionou por anos e deixou de funcionar em agosto de 2026, sem que nada no site tenha sido alterado.

Esse quinto caso tem uma pegada de diagnóstico útil. Se o rich result sumiu sem deploy, sem migração e sem mudança de conteúdo, a hipótese de escape passa na frente de qualquer teoria sobre algoritmo.

A lógica de campo estruturado limpo, aliás, não é exclusiva de SEO. O mesmo cuidado sustenta o uso de dados estruturados na retenção de clientes, onde o dado sujo contamina segmentação em vez de contaminar a SERP.

Que tipos de schema ainda geram rich result no Google?

A lista de tipos que geram rich result encolheu em 2026, e auditar marcação sem considerar isso desperdiça esforço. O Google confirmou na documentação do FAQPage que os rich results de FAQ deixaram de aparecer na Busca em 7 de maio de 2026, com remoção do relatório e do suporte na ferramenta de teste ao longo daquele ano.

A consequência para a auditoria é de priorização. Corrigir escape em um bloco de FAQPage não devolve nada na SERP, porque o recurso não existe mais para exibir.

Isso não transforma o schema descontinuado em lixo. A marcação continua descrevendo a página para sistemas que consomem dados estruturados, e o valor migrou de aparência para interpretação.

A régua de prioridade fica clara. Comece pelos tipos que ainda produzem efeito visual, como artigo, produto, avaliação, navegação estruturada, evento e organização, e trate os demais como higiene semântica.

Vale casar essa lista com o desenho estratégico da marcação. A construção de uma estratégia de SEO com Schema.org define quais tipos fazem sentido por página antes de o problema virar debate técnico de sintaxe.

Existe uma camada adicional que muda o cálculo. Com a expansão de respostas geradas por IA, a marcação passou a ter função de contexto além de função de exibição, o que costuma justificar manter o schema mesmo sem rich result associado.

Esse raciocínio conecta com um comportamento que já aparece nos números de muitos sites, em que a busca sem clique reduz a sessão mesmo com boa posição, e a clareza da marcação vira parte da disputa por citação.

Como montar uma rotina de auditoria de dados estruturados?

Uma rotina de auditoria de dados estruturados funciona melhor quando é curta e recorrente do que quando é profunda e anual. O objetivo não é revisar cada página, e sim monitorar um conjunto pequeno de páginas representativas de cada template, para detectar defeito sistêmico logo depois que ele aparece.

O primeiro passo é escolher a amostra. Pegue uma página de cada tipo de template do site, entre home, listagem, artigo, página de oferta e página institucional.

O segundo é rodar as duas ferramentas em cada uma delas, sempre pela URL pública. Registre o resultado em planilha simples com data, template, tipo de schema detectado e status.

O terceiro é ler o relatório de dados estruturados no Search Console. Ele cobre o site inteiro e mostra tendência, o que a checagem por amostra não mostra.

O quarto é cruzar a data de qualquer queda com o calendário de mudanças. Datar a variação evita a atribuição errada, que é a origem da maior parte das correções inúteis.

O quinto é definir gatilho de reauditoria. Toda troca de tema, atualização de plugin de SEO, migração de CMS ou mudança anunciada no rastreador justifica repetir a amostra.

A frequência sugerida é mensal para a amostra e imediata para os gatilhos. Esse ritmo costuma ser suficiente para pegar defeito de template antes que ele consuma um ciclo inteiro de tráfego.

O acompanhamento também ganha com a leitura dos dados de IA. O relatório de IA no Search Console ajuda a observar se a queda de cliques se concentra em superfícies generativas ou na SERP clássica.

Como isso muda a operação de um site de instituição de ensino?

Sites de instituição de ensino sentem os erros de JSON-LD de forma desproporcional, porque dependem de páginas repetitivas geradas por template. Um catálogo com dezenas de cursos usa a mesma estrutura para todos, então um defeito de escape no modelo apaga a marcação de todo o catálogo simultaneamente.

O caractere problemático é rotineiro nesse contexto. Nomes de curso com e comercial, títulos com aspas e denominações institucionais longas são exatamente o material que a dupla escapagem estraga.

A sazonalidade agrava o custo. Um bloco de marcação quebrado em janeiro pesa muito mais do que o mesmo bloco quebrado em setembro, porque a janela de captação não espera o próximo ciclo de correção.

Existe ainda um efeito sobre autoridade. Marcação de organização e de autoria é parte do que sustenta os sinais de E-E-A-T na construção de autoridade, e um bloco ilegível remove esse contexto da leitura automática.

O mesmo vale para conteúdo de topo. Um artigo com marcação quebrada perde parte do enriquecimento que ajuda o card a competir no feed, o que se soma à volatilidade natural do Google Discover.

A recomendação operacional é modesta e barata. Coloque uma página de curso e um artigo do blog na amostra mensal, porque esses dois templates cobrem a maior parte do risco de um site educacional.

Perguntas frequentes sobre erros de JSON-LD

Afinal, vale a pena auditar os erros de JSON-LD agora?

Auditar os erros de JSON-LD vale a pena agora por uma razão de janela. A mudança na extração do Googlebot entrou em vigor em agosto de 2026 e afeta a marcação que funcionava havia anos, então o defeito pode já estar ativo sem que nada tenha sido alterado no site.

O custo da checagem é baixo. Uma amostra de cinco páginas em duas ferramentas resolve o diagnóstico inicial em menos de uma hora de trabalho.

O custo de não checar é assimétrico. Rich result ausente não dispara alarme, não aparece em relatório de erro e só se manifesta como uma erosão lenta de cliques que costuma ser creditada a outra causa.

A ordem de prioridade também é simples. Comece pelos templates que geram mais páginas, siga pelos tipos que ainda produzem rich result e deixe a higiene semântica para o final.

Se a operação não tem hoje uma rotina que date variações e separe defeito técnico de mudança de algoritmo, esse é o ponto que costuma render mais rápido. É exatamente o tipo de diagnóstico que estrutura um trabalho de SEO consistente, em que a correção técnica sustenta o conteúdo em vez de competir com ele.

Para revisar a marcação do seu site e transformar essa checagem em rotina, fale com o time da Mkt4edu.