JSON-LD tras el cambio de Google: revisamos 1,044 sitios, al 1.6% le afectó, pero el problema real alcanza a un tercio

El 21 de agosto Google cambió la forma en que su rastreador lee el marcado JSON-LD, y los medios del sector se apresuraron a escribir "revisa tu marcado ahora". Nosotros lo revisamos, pero no en nuestro sitio, sino en 1044: 748 del top diez de Google para consultas comerciales, 295 sitios de nuestros clientes y el nuestro. En total, 3167 páginas. El cambio de Google afectó al 1.6% de los sitios. Lo que sí encontramos fue un problema veinte veces mayor del que nadie está hablando, y un error nuestro, que ya corregimos.

Qué cambió exactamente Google

El anuncio no apareció en la documentación, sino en una publicación de Google Search Central en LinkedIn. La frase clave:

Para entender qué implica, hay que conocer un dato sobre HTML. En el texto normal de una página, el ampersand se escribe como & y el navegador lo muestra como "&". Pero el contenido de una etiqueta <script>, que es justo donde vive JSON-LD, es "texto sin procesar" según la especificación de HTML: allí las entidades HTML no se decodifican en absoluto. La especificación de JSON-LD lo dice de forma directa: esos caracteres "seguirán escapados después del procesamiento".

Google siempre ha sido flexible con esto y decodificaba las entidades por su cuenta. Hasta agosto lo hacía dos veces seguidas, así que incluso un & con doble escape se convertía en un "&" limpio. Ahora lo hace una sola vez. Esto es lo que significa para el nombre de una empresa:

El cambio afecta solo a la segunda fila: el doble escape. La primera fila sigue funcionando en Google, pero solo en Google. Las dos últimas son correctas para todos.

Cómo lo comprobamos

Tres muestras. La primera son 2,076 páginas del top diez de Google y de fuentes de respuestas de IA para 48 consultas comerciales de nuestro estudio sobre recomendaciones de IA: sitios que realmente reciben tráfico por consultas costosas. La segunda son los sitios de nuestros clientes: la página de inicio y hasta cuatro páginas promocionadas de cada uno, para que los sitios grandes no dominen. La tercera son 300 páginas aleatorias de nuestro propio sitio. Cada página se descargó directamente, sin servicios de pago.

En cada página extrajimos todos los bloques JSON-LD y los analizamos de tres maneras: como los leía Google antes, como los lee ahora y como lo exige el estándar. Contamos los resultados por sitio, no por página: las páginas que usan una misma plantilla repiten un mismo error, y contar páginas lo infla mucho. Por ejemplo, casi la mitad de las páginas con doble escape de nuestra muestra provenían de un solo sitio.

A quién afectó el cambio: 1.6% de los sitios

De 748 sitios con marcado, 12 tenían doble escape. Más de la mitad son publicaciones de un mismo grupo de medios: comparten una plantilla en la que la descripción del autor se escapa dos veces. Como resultado, estos sitios ahora tienen un literal “'” en lugar de un apóstrofo en la biografía del autor dentro de su marcado. Entre los sitios de nuestros clientes hay dos casos así de 295.

La conclusión es sencilla: si no has visto nuevos errores de datos estructurados en Search Console desde el 21 de agosto, casi con seguridad el cambio no te afectó. La alarma en los medios del sector fue desproporcionada respecto a la escala real.

Un problema mayor: Shopify y los caracteres que nadie decodifica

Hay una segunda forma de corromper un carácter, y Google no tiene nada que ver. La entidad termina oculta dentro de un escape JSON: el código contiene \u0026amp;. La decodificación HTML no la ve, porque no hay ningún ampersand en el texto, y tras el análisis del JSON el valor contiene un literal “&”. Ningún procesador estándar lo limpiará.

Lo encontramos en 11 de 47 sitios de Shopify en el top 10 de Google: 23%. En todas las demás plataformas, en 2.3%. Una diferencia de diez veces. La plataforma en sí no es la causa; lo son las plantillas de los temas: el texto primero se escapa para HTML y luego un filtro lo envuelve en JSON una vez más, y la entidad pasa sin cambios. Las descripciones de producto son las más afectadas: vienen del editor visual con las entidades ya incluidas.

El mayor problema: un tercio de los sitios escribe el marcado “solo para Google”

El 36% de los sitios del top diez de Google y el 23% de los sitios de nuestros clientes tienen entidades HTML comunes dentro de JSON-LD: &, ", '. Google aún las entiende: basta con una sola pasada de decodificación. Pero es el único que lo hace por iniciativa propia. El estándar exige leerlas de forma literal, así que cualquier otro consumidor del marcado (otros buscadores, validadores, servicios que recopilan datos de productos y empresas según la especificación) verá “Tom & Jerry” en el nombre.

Casi todos estos caracteres se pueden escribir en JSON tal cual: el ampersand, las comillas tipográficas y el apóstrofo. Las comillas rectas dentro de una cadena JSON se escapan con una barra invertida, no con una entidad HTML. Lo único realmente prohibido dentro de una etiqueta script es una secuencia que el navegador interprete como el final del script. Para esos casos, como aconseja Google, existe el escape de JSON: \u003C en lugar de “<” y \u0026 en lugar de “&”.

Revisamos nuestro propio sitio y encontramos algo

Nuestro sitio tiene marcado en las 300 páginas que revisamos y no apareció ningún doble escape. Pero dos páginas cayeron en la clase “solo para Google”: en las migas de pan, el título de un artículo en inglés entró en el marcado como “Web 2.0 &amp; Cascade Promotion”.

La causa es exactamente la que con más frecuencia mete entidades en JSON-LD. La plantilla de la página escapa el título para mostrarlo en HTML, y el código que construye las migas de pan toma la cadena ya escapada y la pone en JSON. En pantalla todo se ve bien; en el marcado no. Lo corregimos el 29 de septiembre con una sola línea: la cadena se decodifica de nuevo antes de empaquetarla en JSON. Volvimos a revisar: cero entidades en el marcado.

Cómo revisar y corregir tu sitio

// Mal: la cadena ya está escapada para HTML: las entidades terminan en JSON-LD
$title = htmlspecialchars($post['title']);
echo json_encode(['headline' => $title]);

// Bien: el texto sin procesar va a JSON, y las banderas convierten & y < en \u0026 y \u003C
echo json_encode(['headline' => $post['title']],
    JSON_HEX_TAG | JSON_HEX_AMP | JSON_UNESCAPED_UNICODE);

Preguntas frecuentes

¿Qué cambió exactamente Google en el análisis de JSON-LD el 21 de agosto de 2026?
Antes Google eliminaba dos veces el escape HTML del marcado; ahora lo hace una sola vez. Así, un carácter con doble escape, como un ampersand escrito como entidad de una entidad, ahora llega al valor como texto de entidad y no como el carácter. Las entidades normales, con un solo escape, Google las sigue entendiendo.

¿Cómo sé si el cambio afectó a mi sitio?
Abre el código fuente de la página y busca dentro de los bloques JSON-LD entidades escritas dos veces: un ampersand seguido de la palabra amp y luego otra entidad. En nuestra revisión esto apareció solo en el 1.6% de los sitios del top diez de Google y en el 0.7% de los sitios de clientes, y más de la mitad de los casos eran una plantilla de un mismo grupo de medios.

¿Debo eliminar las entidades HTML del marcado si Google las entiende?
Sí, si te importa que el marcado se lea correctamente más allá de Google. El estándar JSON-LD exige que estas entidades se tomen literalmente, y cualquier procesador que siga la especificación verá en el valor el texto de la entidad en lugar del carácter. En nuestra revisión, el 36% de los sitios del top diez de Google escribe su marcado de esta manera.

¿Cómo debo escribir un ampersand y comillas en JSON-LD?
Lo más sencillo es escribirlos tal cual: dentro de una etiqueta script, el ampersand, el apóstrofo y las comillas tipográficas son seguros. Las comillas rectas dentro de una cadena se escapan con una barra invertida según las reglas de JSON. Si quieres protección total contra el cierre accidental de la etiqueta script, usa el escape de JSON: \u0026 para el ampersand y \u003C para el signo de menor que.

¿Por qué los caracteres dañados son más comunes en Shopify?
No por la plataforma en sí, sino por las plantillas de los temas. El texto primero se escapa para la salida HTML y luego se empaqueta en JSON, y la entidad queda oculta dentro de un escape de JSON. En nuestra muestra esto ocurre en el 23% de los sitios de Shopify frente al 2.3% en otras plataformas.

¿Un error en JSON-LD afecta el posicionamiento?
No directamente: el marcado determina cómo puede verse una página en los resultados y con qué precisión las máquinas entienden sus datos. Pero un valor dañado llegará a un fragmento enriquecido, a una ficha de producto o a un sistema externo que lee el marcado exactamente en su forma dañada. La corrección normalmente requiere una sola línea de código.

Fuentes: publicación de Google Search Central en LinkedIn (21 de agosto de 2026), especificación W3C JSON-LD 1.1, sección 7.2, y la especificación HTML (WHATWG) sobre elementos de texto sin procesar. Datos propios: 3,167 páginas de 1,271 sitios descargadas el 29 de septiembre de 2026: el top diez de Google para 48 consultas comerciales, sitios de clientes de PromoPilot (sin nombres) y 300 páginas de promopilot.link.

Ver los precios de PromoPilot