JSON-LD após a mudança do Google: verificamos 1.044 sites. 1,6% foram afetados, mas o problema real atinge um terço

Em 21 de agosto, o Google mudou a forma como seu crawler lê o markup JSON-LD, e os veículos do setor correram para escrever “verifique seu markup agora”. Nós verificamos, e não só o nosso: foram 1.044 sites, sendo 748 do top 10 do Google para consultas comerciais, 295 sites de nossos clientes e o nosso próprio. Ao todo, 3.167 páginas. A mudança do Google afetou 1,6% dos sites. O que encontramos foi um problema vinte vezes maior, sobre o qual ninguém está escrevendo, além de um erro nosso, que já corrigimos.

O que exatamente o Google mudou

O anúncio não saiu na documentação, mas em um post do Google Search Central no LinkedIn. A frase principal:

Para entender o que isso significa, você precisa de um fato sobre HTML. No texto comum de uma página, o e comercial é escrito como &, e o navegador o exibe como “&”. Mas o conteúdo de uma tag <script>, que é exatamente onde o JSON-LD fica, é “texto bruto” segundo a especificação do HTML: as entidades HTML não são decodificadas ali. A especificação do JSON-LD diz isso diretamente: esses caracteres “continuarão escapados após o processamento”.

O Google sempre foi tolerante nesse ponto e decodificava as entidades por conta própria. Até agosto, ele fazia isso duas vezes seguidas, então até um & com escape duplo virava um “&” limpo. Agora ele faz isso uma vez só. Veja o que isso significa para o nome de uma empresa:

A mudança afeta apenas a segunda linha: o escape duplo. A primeira linha ainda funciona no Google, mas só no Google. As duas últimas estão corretas para todo mundo.

Como verificamos

Três amostras. A primeira reúne 2.076 páginas do top dez do Google e de fontes de respostas de IA para 48 consultas comerciais em nosso estudo sobre recomendações de IA: sites que realmente recebem tráfego em consultas caras. A segunda são os sites dos nossos clientes: a página inicial e até quatro páginas promovidas de cada um, para que sites grandes não dominem. A terceira são 300 páginas aleatórias do nosso próprio site. Cada página foi baixada diretamente, sem serviços pagos.

Em cada página, extraímos todos os blocos JSON-LD e os processamos de três formas: como o Google lia antes, como lê agora e como o padrão exige. Contamos os resultados por site, não por página: páginas que usam o mesmo template repetem o mesmo erro, e contar páginas infla muito esse número. Por exemplo, quase metade das páginas com escape duplo em nossa amostra veio de um único site.

Quem foi afetado pela mudança: 1,6% dos sites

De 748 sites com marcação, 12 tinham escape duplo. Mais da metade deles são publicações de um mesmo grupo de mídia: elas compartilham um template em que a descrição do autor passa por escape duas vezes. Como resultado, esses sites agora exibem um literal “'” em vez de um apóstrofo na bio do autor em sua marcação. Entre os sites dos nossos clientes, há dois casos desse tipo em 295.

A conclusão é simples: se você não viu novos erros de dados estruturados no Search Console desde 21 de agosto, a mudança quase certamente não afetou você. O alarme nos veículos do setor foi desproporcional à escala do problema.

Um problema maior: Shopify e caracteres que ninguém decodifica

Há uma segunda forma de corromper um caractere, e o Google não tem nada a ver com isso. A entidade acaba escondida dentro de um escape JSON: o código contém \u0026amp;. A decodificação de HTML não a enxerga: não há nenhum e comercial no texto, e após o parse do JSON o valor contém um literal “&”. Nenhum processador padrão vai limpar isso.

Encontramos isso em 11 de 47 sites Shopify entre os dez primeiros resultados do Google: 23%. Em todas as outras plataformas, em 2,3%. Uma diferença de dez vezes. A plataforma em si não é a causa; os templates de tema são: o texto é primeiro escapado para HTML e depois empacotado em JSON mais uma vez por um filtro, e a entidade passa direto. As descrições de produtos são as mais afetadas, pois vêm do editor visual já com entidades dentro.

O maior problema: um terço dos sites escreve marcação “só para o Google”

36% dos sites no top 10 do Google e 23% dos sites dos nossos clientes têm entidades HTML comuns dentro do JSON-LD: &, ", '. O Google ainda as entende: uma única passagem de decodificação basta. Mas ele é o único que faz isso por conta própria. O padrão exige que elas sejam lidas literalmente, então qualquer outro consumidor da marcação (outros mecanismos de busca, validadores, serviços que coletam dados de produtos e empresas conforme a especificação) verá “Tom & Jerry” no nome.

Quase todos esses caracteres podem ser gravados no JSON como estão: o e comercial, as aspas curvas e o apóstrofo. As aspas retas dentro de uma string JSON são escapadas com uma barra invertida, não com uma entidade HTML. A única coisa realmente proibida dentro de uma tag script é uma sequência que o navegador interpretaria como o fim do script. Para esses casos, como o Google recomenda, existe o escape JSON: \u003C em vez de “<” e \u0026 em vez de “&”.

Verificamos o nosso próprio site e encontramos um problema

Nosso site tem markup em todas as 300 páginas que verificamos, e não apareceu nenhum escape duplo. Mas duas páginas se enquadraram na classe “somente para o Google”: nos breadcrumbs, o título de um artigo em inglês entrou no markup como “Web 2.0 &amp; Cascade Promotion”.

A causa é exatamente a que mais costuma colocar entidades no JSON-LD. O template da página escapa o título para a saída em HTML, e o código que monta os breadcrumbs pega a string já escapada e a coloca no JSON. Na tela tudo parece certo; no markup, não. Corrigimos em 29 de setembro com uma única linha: a string é decodificada de volta antes de ser empacotada no JSON. Verificamos de novo: zero entidades no markup.

Como verificar e corrigir o seu site

// Errado: a string já está escapada para HTML, então as entidades vão parar no JSON-LD
$title = htmlspecialchars($post['title']);
echo json_encode(['headline' => $title]);

// Certo: o texto bruto vai para o JSON, e as flags transformam & e < em \u0026 e \u003C
echo json_encode(['headline' => $post['title']],
    JSON_HEX_TAG | JSON_HEX_AMP | JSON_UNESCAPED_UNICODE);

Perguntas frequentes

O que exatamente o Google mudou na análise do JSON-LD em 21 de agosto de 2026?
O Google costumava remover o escape HTML do markup duas vezes; agora remove apenas uma. Assim, um caractere com escape duplo, como um e comercial escrito como a entidade de uma entidade, agora fica no valor como texto da entidade, e não como o caractere. As entidades comuns, com escape simples, continuam sendo entendidas pelo Google.

Como saber se a mudança afetou o meu site?
Abra o código-fonte da página e procure dentro dos blocos JSON-LD entidades escritas duas vezes: um e comercial seguido da palavra amp e depois de outra entidade. Na nossa verificação, isso apareceu em apenas 1,6% dos sites do top 10 do Google e em 0,7% dos sites de clientes, e mais da metade dos casos era um único template de um único grupo de mídia.

Devo remover entidades HTML do markup se o Google as entende?
Sim, se você se preocupa com que o markup seja lido corretamente além do Google. O padrão JSON-LD exige que essas entidades sejam tomadas literalmente, e qualquer processador que siga a especificação verá o texto da entidade no valor, em vez do caractere. Na nossa verificação, 36% dos sites do top 10 do Google escrevem o markup dessa forma.

Como devo escrever o e comercial e as aspas em JSON-LD?
O jeito mais simples é escrevê-los como são: dentro de uma tag script, o e comercial, o apóstrofo e as aspas curvas são seguros. Aspas retas dentro de uma string são escapadas com barra invertida, conforme as regras do JSON. Se você quiser proteção total contra o fechamento acidental da tag script, use o escape JSON: \u0026 para o e comercial e \u003C para o sinal de menor que.

Por que caracteres corrompidos são mais comuns no Shopify?
Não por causa da plataforma em si, mas por causa dos templates de tema. O texto é primeiro escapado para a saída em HTML e depois empacotado em JSON, e a entidade acaba escondida dentro de um escape JSON. Na nossa amostra, isso acontece em 23% dos sites Shopify, contra 2,3% em outras plataformas.

Um erro de JSON-LD afeta o ranqueamento?
Não diretamente: o markup determina como uma página pode aparecer nos resultados e com que precisão as máquinas entendem seus dados. Mas um valor corrompido chegará a um rich snippet, a um card de produto ou a um sistema de terceiros que lê o markup exatamente na forma corrompida. A correção geralmente leva uma linha de código.

Fontes: post do Google Search Central no LinkedIn (21 de agosto de 2026), especificação W3C JSON-LD 1.1, seção 7.2, e a especificação HTML (WHATWG) sobre elementos de texto bruto. Dados próprios: 3.167 páginas de 1.271 sites baixadas em 29 de setembro de 2026: top 10 do Google para 48 consultas comerciais, sites de clientes da PromoPilot (sem identificação) e 300 páginas do promopilot.link.

Veja os preços do PromoPilot