Um catálogo de produtos com o caractere “&” no nome, como em ‘fone bluetooth & microfone’, pode carregar um bloco de JSON-LD que sempre validou sem nenhum alerta no relatório do Search Console. De um dia para o outro, sem que ninguém tenha tocado numa linha de template, o mesmo bloco começa a cair no relatório de dados estruturados não interpretáveis, e não é uma falha recente do site, é o Googlebot lendo o schema de um jeito diferente do que lia até a semana passada.
Nesta sexta-feira, 21 de agosto de 2026, o Search Central, canal oficial do Google para quem trabalha com SEO, publicou que mudou a forma como o Googlebot extrai dados de blocos JSON-LD. O ajuste parece pequeno visto de fora, mas reduz uma margem de tolerância que muita gente nem sabia que estava usando, já que o próprio comunicado do Google não detalha desde quando esse comportamento existia.
E o mais preocupante, quem herdou um pipeline de geração de schema com escape duplicado pode descobrir isso da forma mais desconfortável possível: um rich result que simplesmente some da busca, sem nenhuma mudança visível no conteúdo da página.
O que muda, de fato, na extração de JSON-LD pelo Googlebot
JSON-LD é o formato de dados estruturados que o próprio Google recomenda para descrever produto, receita, avaliação, evento e outros tipos de conteúdo dentro de um bloco de script na página, e ele tinha, até esta semana, uma particularidade pouco discutida fora do círculo mais técnico: o parser do Googlebot corrigia sozinho as entidades de HTML escapadas duas vezes dentro desse bloco.
Isso alterava a leitura de uma string sem que o dono do site percebesse nada de errado. Um caractere como o “e” comercial, escapado incorretamente como & em vez do \u0026 previsto pelo padrão JSON, era desfeito pelo Google até virar o símbolo correto na hora de montar o rich result. Funcionava, mesmo estando tecnicamente fora do padrão.
Segundo o comunicado do Search Central, essa tolerância chega ao fim: “para alinhar nosso parser ao padrão JSON e a outros padrões, mudamos a extração de JSON-LD e agora aplicamos apenas uma única passada de decodificação de HTML”, registrou o Google, conforme reproduzido pelo Search Engine Roundtable.
Gary Illyes, engenheiro do time de Search da empresa, completou o recado citando a especificação técnica que baliza a mudança: “se você está se perguntando qual é o jeito correto de fazer escape em JSON, tenho uma boa notícia: isso está muito, muito bem definido na RFC 8259, especificamente na seção 7”.
Chamar isso de alinhamento ao padrão é a leitura mais confortável para o Google (e, sejamos justos, tecnicamente é exata). Só que o efeito prático, para quem contava com um parser tolerante sem saber, é o mesmo de perder de uma hora para outra uma margem de erro que nunca esteve documentada como garantida.
Por que o escape duplo era tão comum e por que ele deixa de funcionar agora
O escape duplo quase sempre nasce no próprio pipeline de geração de conteúdo, não numa decisão consciente de quem escreve o schema. Um campo de descrição passa primeiro por uma camada que escapa caracteres para exibição segura em HTML e, na sequência, por outra camada que serializa esse mesmo texto para dentro do bloco JSON-LD sem desfazer o primeiro escape. O resultado é uma string com duas camadas de codificação sobrepostas, que o navegador nunca chega a mostrar ao usuário, mas que o Googlebot lia e corrigia por conta própria até agora.
Geradores de site estático, templates concatenados manualmente e integrações que reaproveitam o mesmo texto em dois contextos diferentes (visível na página e embutido no schema) são os ambientes mais propensos a esse tipo de duplicação, já que quanto mais camadas intermediárias existem entre o banco de dados e o bloco <script type="application/ld+json">, maior a chance de um escape ser aplicado duas vezes sem ninguém perceber.
A partir de agora, entidades como &amp; ou &#10004; deixam de ser desfeitas automaticamente e permanecem, literalmente, dentro do valor da string. O bloco continua sendo um JSON sintaticamente válido, só que com um dado diferente do pretendido: em vez do caractere correspondente, o Google passa a ler a sequência de texto da entidade, o que pode custar a elegibilidade daquele trecho para determinado rich result, dependendo de qual campo carrega o problema.
Vale um contraponto de mercado: o Bing oferece suporte a JSON-LD desde 2018, mas nunca deu ao formato o mesmo peso estratégico que o Google dá, e não há, até o momento, nenhum comunicado equivalente sobre mudança de tolerância no parser da Microsoft. O ajuste, por ora, é uma particularidade do ecossistema do Google.
Essa mudança também não nasce isolada. O Google vem recalibrando ao longo de 2026 como trata dados estruturados de forma mais ampla, como mostramos aqui quando cobrimos o fim do rich result de FAQ, mantido como schema válido (continua sendo lido normalmente por crawlers e por agentes de IA, só deixou de gerar qualquer destaque visual na busca).
O padrão que se desenha é o de um parser cada vez mais rígido sobre o que é aceito, ainda que o vocabulário de schema em si continue amplo.
Como auditar dados estruturados antes que o Google flague o escape duplo
O primeiro passo é técnico e rápido: abrir o HTML entregue pelo servidor (o “ver código-fonte” do navegador, sem nenhuma renderização de JavaScript), localizar o bloco application/ld+json e colar o conteúdo bruto num validador JSON simples. Se aquele bloco não for um JSON válido por si só, nenhuma outra checagem de schema faz diferença até esse ponto ser corrigido.
Vale conferir também o DOM depois da renderização, principalmente se o schema for injetado via JavaScript: um bloco que só existe depois que o script roda pode não estar no HTML inicial que o Googlebot lê na primeira passada, o que muda o diagnóstico. Ferramentas como o Rich Results Test e o Schema Markup Validator ajudam nessa checagem porque renderizam a página antes de validar, mas por isso mesmo não substituem a leitura direta do “ver código-fonte”: um teste limpo nelas não garante que o Googlebot vai encontrar o mesmo schema na primeira leitura, sem renderização. Combinar as duas checagens, mais uma consulta pelo URL Inspection do Search Console, é o jeito mais seguro de saber o que o rastreador realmente processa.
Depois de validado o JSON em si, o ajuste de fundo é trocar qualquer escape de entidade HTML por escape padrão de JSON ou por escape Unicode hexadecimal, como \u0026 no lugar de &. Times que geram o schema programaticamente, serializando um objeto com JSON.stringify em vez de concatenar string manualmente, tendem a não sofrer com esse problema, porque a serialização correta já evita a sobreposição de camadas de escape desde a origem.
Quem prefere um diagnóstico contínuo, e não só uma checagem pontual, pode acompanhar, dentro do próprio Search Console, o relatório de dados estruturados não interpretáveis, que já cataloga esse tipo de erro de sintaxe por página, incluindo a categoria específica para sequência de escape malformada dentro de uma string.
Mesma semana, o rollout do spam update de agosto terminou
O ajuste na extração de JSON-LD chegou numa semana carregada de comunicados do Search Central. No mesmo dia 21 de agosto, o Google confirmou, no Search Status Dashboard, que o rollout do spam update de agosto de 2026 chegou ao fim, dois dias e dezesseis horas depois do início, na terça-feira anterior. Já tínhamos coberto aqui o lançamento desse spam update, e agora o rollout está oficialmente encerrado, o que dá aos times de conteúdo uma base mais limpa de dados no Search Console a partir de hoje.
São mudanças de natureza bem diferente, uma mexe em ranqueamento e a outra mexe em como o rastreador interpreta marcação técnica, e não há qualquer indício de que estejam conectadas. A coincidência de datas serve, sobretudo, como lembrete de que agosto de 2026 tem sido um mês de ajuste contínuo dentro do Google, e quem cuida de SEO no dia a dia precisa acompanhar tanto a métrica de ranking quanto a saúde técnica da página ao mesmo tempo.
O que muda na rotina de SEO técnico depois do ajuste no JSON-LD
O Google fechou uma margem de erro que boa parte do mercado nem sabia que estava usando. Sites que sempre validaram sem erro podem começar a acumular itens no relatório de dados estruturados não interpretáveis sem que o time de conteúdo tenha alterado uma linha sequer, simplesmente porque o parser do outro lado ficou mais rígido.
Essa leitura vai além do que o Google confirmou oficialmente sobre esse anúncio específico, mas segue uma linha que a própria empresa vem reforçando em outras frentes ao longo do ano: quanto mais a busca depende de leitura automatizada e estruturada de página, inclusive para alimentar recursos de IA generativa, menos espaço sobra para marcação tolerante a erro.
Para quem trabalha também com GEO, a otimização voltada para motores de busca generativos e assistentes de IA, os dados estruturados precisam representar com fidelidade o que está na página, porque servem justamente pra reduzir a ambiguidade que um sistema automatizado teria ao tentar interpretar o conteúdo sozinho.
O caminho mais seguro é adotar uma rotina simples de auditoria direto na fonte oficial, assim que o Search Central publica um ajuste como esse. E é esse tipo de tradução, do comunicado técnico bruto, à ação prática, que a EducaSEO faz questão de entregar antes que o assunto vire dor de cabeça no seu relatório do Search Console.
Contando com um ecossistema educacional completo com cursos técnicos, programas ao vivo, MBA e mentoria, aqui você encontra informação de ponta voltada pro mercado prático de marketing orgânico, e pra quem cuida de SEO todo dia.
Continue de olho na EducaSEO pra que a próxima mudança do Google chegue até você traduzida e a tempo de agir, não só depois que o rich result já tiver sumido da busca.
Referências
- Schwartz, Barry. Google Changes JSON-LD Extraction For Googlebot. Search Engine Roundtable. Disponível em: https://www.seroundtable.com/json-ld-extraction-googlebot-41921.html.
- Google Search Central. Publicação oficial no LinkedIn. Disponível em: https://www.linkedin.com/showcase/googlesearchcentral/.
- IETF. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, seção 7. Disponível em: https://www.rfc-editor.org/info/rfc8259/.
- Google Search Console Help. Unparsable structured data report. Disponível em: https://support.google.com/webmasters/answer/9166415.
- Google. Search Status Dashboard: August 2026 spam update. Disponível em: https://status.search.google.com/incidents/LEubPCm2octf2uMqCFKE.
- Schwartz, Barry. Google August 2026 Spam Update Is Done Rolling Out. Search Engine Roundtable. Disponível em: https://www.seroundtable.com/google-august-2026-spam-update-done-41906.html.
