Google deja de deshacer los escapes HTML dobles en el JSON-LD

Desde el 21 de agosto de 2026 Google aplica una sola pasada de desescapado HTML al leer JSON-LD. El escapado HTML normal sigue funcionando (no tendría sentido que no lo hiciera); el problema son los escapes dobles que generan algunos CMS, plugins de minificado y CDN: antes Google los deshacía y ahora los deja como texto ilegible en tus datos estructurados.

Google ha cambiado la forma de leer los datos estructurados de las páginas. Desde el 21 de agosto de 2026 deshace los escapes HTML del JSON-LD una sola vez, y no tantas veces como hiciera falta. Si tu web los tiene escapados dos veces, cosa que hacen sin avisar muchos plugins de caché, de minificado o de datos estructurados, Google ya no los lee bien. Y ninguna herramienta te lo señala todavía.

El JSON-LD no va en un archivo aparte: se inserta dentro del HTML de la página. Por eso conviven dos formas de escapar caracteres: la del HTML (&, é, ✔) y la propia de JSON (\", \n, \u0026). Hasta ahora Google era tolerante: si una entidad HTML venía escapada dos veces, la deshacía hasta llegar al carácter. Ahora la deshace una vez y lo que queda se lee tal cual.

Lo anunció Google Search Central el 21 de agosto en una publicación en LinkedIn: «para poner nuestro analizador a la altura de JSON y otros estándares, hemos cambiado la extracción de JSON-LD y ahora aplicamos una sola pasada de desescapado HTML». Gary Illyes, de Google, añadió el mismo día que el escapado correcto en JSON está definido en la sección 7 del RFC 8259.

Hay parte de verdad en el revuelo y también exageración. Google sigue leyendo los escapes HTML normales; lo que ya no lee son los dobles, que casi nunca se escriben a mano: los produce un CMS que escapa lo que ya estaba escapado, un plugin de caché o de minificado, un plugin de JSON o un CDN que minifica el HTML. Un truco para verlos: si dentro del texto de un JSON aparece una «palabra» que empieza por &, es un escape HTML; si esa palabra empieza por &, es doble.

Qué hace Google ahora con cada tipo de escape dentro de un JSON-LD:

Parte de la confusión viene de cómo se reprodujo el mensaje de Google. En la versión que publicó Search Engine Roundtable, y en otras que la copiaron, los ejemplos aparecen como & y ✔, es decir, con un solo escape: el propio CMS del medio deshizo el doble escape del original. Leído así parece que Google deja de aceptar el escapado HTML normal, y no es eso. En el mensaje original de Google los ejemplos son & y ✔: escapes dobles. No es lo mismo &, que sigue siendo válido, que &.

El mismo JSON-LD dos veces en la prueba de resultados enriquecidos: con escapes HTML simples Google lee «Máster SEO Técnico & GEO»; con escapes dobles el nombre queda como «Máster SEO Técnico & GEO». Los dos elementos se dan por válidos: la herramienta no avisa.

Eso es lo peligroso: antes se leía bien y ahora se vería un texto distinto e ilegible, y ninguna herramienta lo señala todavía. La prueba de resultados enriquecidos sigue marcando el elemento como válido, porque sintácticamente lo es; hay que mirar el texto que muestra en «Elementos detectados» para ver si el nombre del producto, del curso o de la empresa ha salido con basura dentro.

La versión corregida: el mismo bloque con escapes estándar de JSON. Comprobarlo página a página es lento; a escala hay que rastrear.

Comprobarlo no es automático ni rápido. Para una página, la prueba de resultados enriquecidos: si en los elementos detectados ves & o é escritos tal cual, tienes el problema. Para un sitio entero, un rastreo con Screaming Frog con una búsqueda personalizada o una extracción por expresión regular sobre los bloques application/ld+json: cualquier & seguido de amp;, quot;, # o el nombre de una entidad es un escape doble. Quien use plugins de minificado (muchos de caché lo hacen), plugins que generan JSON o un CDN que minifica HTML es quien más motivos tiene para rastrear.

La solución no es quitar el escapado HTML, que sigue siendo válido, sino arreglar la cadena que lo dobla: normalmente una llamada a htmlspecialchars (o su equivalente) sobre un texto que ya venía escapado, o sobre la salida de json_encode. Lo más robusto, y lo que pide Google, es generar el JSON-LD con los escapes propios de JSON (\u0026 para el ampersand, \" para las comillas) y no pasar ese bloque por ningún escapado HTML después.

El resumen, publicado en LinkedIn el mismo día:

Publicación en LinkedIn de Carlos Sánchez sobre el cambio de Google en el escapado del JSON-LD

Referencias

1. Bray, T. (2017, 1 de diciembre). The JavaScript Object Notation (JSON) Data Interchange Format, sección 7: Strings. rfc-editor.org. https://www.rfc-editor.org/rfc/rfc8259#section-7 (el estándar de escapado de JSON al que remite Google)
2. Google (s. f.). Prueba de resultados enriquecidos. https://search.google.com/test/rich-results (herramienta con la que se han hecho las capturas del artículo)
3. Google Search Central (2026, 21 de agosto). To bring our parser up to JSON and other standards, we changed our JSON-LD extraction [publicación en LinkedIn]. https://www.linkedin.com/feed/update/urn:li:share:7496492350370713600/ Fuente principal
4. Illyes, G. (2026, 21 de agosto). If you're wondering what proper escaping is in JSON, it's very well defined in RFC 8259 [publicación en LinkedIn]. LinkedIn. https://www.linkedin.com/posts/garyillyes_if-youre-wondering-what-proper-escaping-share-7496494336604360705-8Ram/ (aclaración de Google sobre el escapado correcto)
5. Schwartz, B. (2026, 21 de agosto). Google Changes JSON-LD Extraction For Googlebot. Search Engine Roundtable. https://www.seroundtable.com/json-ld-extraction-googlebot-41921.html (recoge el anuncio; en su texto los escapes dobles del mensaje de Google salen colapsados)