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

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 &.

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.

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: