Google endureció el parser de JSON-LD: qué cambió exactamente, por qué los sitios en español están más expuestos y cómo revisarlo en menos de una hora.

22 min de lectura · Publicado el 21 de agosto de 2026 · Alerta técnica Webhexup

Durante años, el parser de Google fue deliberadamente permisivo con el JSON-LD. Sabía que buena parte de la web genera datos estructurados con plantillas, plugins y concatenaciones de cadenas que producen código sintácticamente sucio, y decidió limpiar en varias pasadas antes de interpretar. Esa tolerancia sostuvo silenciosamente los resultados enriquecidos de muchísimos sitios que técnicamente estaban emitiendo JSON inválido.

Esa etapa se acabó. Google anunció que ajustó su extracción de JSON-LD para aplicar una única pasada de desescapado de HTML, con el objetivo explícito de alinear el parser con el estándar. Gary Illyes remitió al RFC 8259, sección 7, que es donde el estándar define exactamente qué es un escapado correcto en JSON.

Para la mayoría de sitios esto no cambia nada. Para una minoría concreta, cambia bastante. Este artículo explica exactamente qué se rompió, cómo saber en veinte minutos si te afecta, por qué el riesgo es mayor en sitios en español, y cómo corregirlo según la plataforma que uses.

Qué cambió exactamente
y qué es el doble escapado.

Para entender el problema hay que separar dos capas que conviven en la misma página y que se confunden constantemente: la capa HTML y la capa JSON.

Tu JSON-LD vive dentro de una etiqueta script en un documento HTML. Eso significa que el contenido pasa por dos sistemas de escapado distintos, con reglas distintas, y cada uno tiene su propia forma de representar caracteres especiales. Cuando una plantilla aplica el escapado de HTML sobre un contenido que ya venía escapado, se produce el doble escapado.

Cómo se ve el problema

Tomemos el nombre de una firma legal colombiana real como ejemplo: Fernández & Asociados. El símbolo intermedio es el que causa todo el problema.

El parser anterior desescapaba repetidamente hasta llegar al carácter limpio. El parser actual desescapa una vez y entrega lo que quede, aunque siga siendo una entidad sin resolver.

El mismo caso en código

Así se ve el marcado que rompe y el marcado que funciona. Fíjate únicamente en el campo del nombre:

// INCORRECTO · entidad HTML dentro del valor JSON
{
  "@type": "LegalService",
  "name": "Fernández & Asociados",
  "description": "Defensa penal & corporativa en Medellín"
}

// CORRECTO opción 1 · carácter directo en UTF-8
{
  "@type": "LegalService",
  "name": "Fernández & Asociados",
  "description": "Defensa penal & corporativa en Medellín"
}

// CORRECTO opción 2 · escape Unicode hexadecimal
{
  "@type": "LegalService",
  "name": "Fernández \u0026 Asociados",
  "description": "Defensa penal \u0026 corporativa en Medellín"
}

Las dos opciones correctas producen exactamente el mismo resultado al interpretarse. La segunda es preferible cuando el JSON pasa por varias capas de plantillas, porque la barra invertida no vuelve a escaparse como HTML.

Los otros caracteres que suelen romper

A quién afecta:
matriz de riesgo por configuración.

El riesgo no es uniforme. Depende casi por completo de cómo se genera el JSON-LD en tu sitio, no del tamaño del sitio ni del sector. Esta es la matriz que uso para clasificar clientes cuando llega un cambio de este tipo:

El patrón que genera casi todos los casos graves

En mi experiencia revisando desarrollos a medida, el origen del problema suele ser el mismo: alguien aplicó una función de escapado de HTML sobre un valor que va a ir dentro de un JSON, por precaución de seguridad, sin darse cuenta de que el contexto no es HTML sino JSON.

// PHP · patrón que produce doble escapado
$nombre = "Fernández & Asociados";
$json = '{"name": "' . htmlspecialchars($nombre) . '"}';
// resultado: {"name": "Fernández & Asociados"}

// PHP · patrón correcto
$datos = ["name" => "Fernández & Asociados"];
$json = json_encode($datos, JSON_UNESCAPED_UNICODE | JSON_HEX_AMP);
// resultado: {"name":"Fernández \u0026 Asociados"}

La regla general es no construir JSON concatenando cadenas. Usa siempre la función de serialización del lenguaje, que conoce las reglas de escapado del formato y las aplica correctamente.

Por qué los sitios en español
están más expuestos.

Esta sección no la vas a encontrar en las coberturas en inglés del anuncio, y es la que más me preocupa como consultor trabajando el mercado hispanohablante. Hay tres razones concretas por las que nuestro riesgo es mayor.

Razón 1 · Los nombres comerciales con ampersand son mucho más frecuentes

En el mundo hispanohablante, y muy especialmente en servicios profesionales, la construcción con ampersand es la norma para firmas de abogados, contadores, arquitectos y consultoras. Fernández & Asociados, Muñoz & Cía, Restrepo & Hermanos. Ese carácter es exactamente el que dispara el problema, y aparece en el campo más importante del marcado: el nombre de la organización.

Un sitio en inglés de comercio electrónico puede pasar años sin un solo ampersand en su JSON-LD. Un directorio de despachos jurídicos colombianos lo tiene en cada ficha.

Razón 2 · Las migraciones desde CMS antiguos arrastran entidades de caracteres acentuados

Buena parte del parque web latinoamericano viene de migraciones desde sistemas antiguos que almacenaban los caracteres acentuados como entidades HTML nombradas en lugar de UTF-8. Cuando ese contenido pasa a un campo que después se serializa a JSON, y encima se le aplica un escapado adicional, aparece el doble escapado sobre caracteres que en inglés simplemente no existen.

// Cadena migrada desde CMS antiguo
"description": "Especialistas en derecho penal en Medellín"

// Lo que ve Google tras una sola pasada
"description": "Especialistas en derecho penal en Medellín"

// Lo correcto en UTF-8
"description": "Especialistas en derecho penal en Medellín"

La eñe, las vocales acentuadas y la diéresis son los caracteres que más aparecen mal codificados en contenido migrado. En inglés este vector de riesgo es prácticamente inexistente.

Razón 3 · Los signos de apertura son un caso especial poco documentado

El signo de apertura de interrogación y el de exclamación no existen en inglés, así que ninguna guía en ese idioma advierte sobre ellos. En marcado de preguntas frecuentes, donde cada pregunta empieza con el signo de apertura, un pipeline que los convierta a entidades y después escape otra vez produce el problema en absolutamente todas las preguntas del bloque.

Si usas marcado de preguntas frecuentes en español, ese bloque concentra más caracteres de riesgo que cualquier otro de tu sitio, y es además uno de los que más resultados enriquecidos genera históricamente.

Cómo diagnosticarlo
en tu sitio paso a paso.

Este es el procedimiento que sigo, ordenado de más rápido a más exhaustivo. Los primeros tres pasos toman veinte minutos y detectan la mayoría de los casos.

Cómo corregirlo
según tu plataforma.

WordPress con Yoast o Rank Math

Si no has personalizado la salida, no deberías tener problema: ambos generan el JSON con funciones de serialización nativas. El riesgo aparece cuando hay filtros personalizados que modifican la salida o cuando el campo de texto trae entidades desde la base de datos.

// Filtro peligroso que puede introducir doble escapado
add_filter('wpseo_schema_organization', function($data) {
    $data['name'] = esc_html(get_bloginfo('name'));
    return $data;
});

// Versión correcta: sin escapado HTML adicional
add_filter('wpseo_schema_organization', function($data) {
    $data['name'] = html_entity_decode(
        get_bloginfo('name'),
        ENT_QUOTES,
        'UTF-8'
    );
    return $data;
});

La función de decodificación de entidades antes de entregar el valor al generador de schema resuelve el problema en origen, incluso si el dato viene sucio de la base de datos.

JSON-LD pegado en un widget HTML de Elementor

Es el caso que más veo en sitios construidos con constructores visuales, y el diagnóstico es sencillo: el editor puede reescribir caracteres al guardar. Verifica siempre el código fuente servido después de guardar, no el que ves en el editor.

Si detectas que el editor está transformando los caracteres, la solución más robusta es usar escapes Unicode hexadecimales en lugar de caracteres directos, porque la barra invertida no se reescribe como entidad.

Desarrollo a medida en PHP

La regla es una sola y no admite excepciones: nunca construyas el JSON concatenando cadenas.

// Construcción segura con banderas explícitas
$schema = [
    "@context" => "https://schema.org",
    "@type"    => "LegalService",
    "name"     => "Fernández & Asociados",
    "address"  => [
        "@type"           => "PostalAddress",
        "addressLocality" => "Medellín",
        "addressCountry"  => "CO"
    ]
];

echo '<script type="application/ld+json">';
echo json_encode(
    $schema,
    JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP
);
echo '</script>';

Las dos últimas banderas convierten los caracteres problemáticos a su forma Unicode hexadecimal, lo que evita cualquier conflicto con el escapado de HTML del documento contenedor. Es la configuración que uso por defecto en todos los desarrollos.

Shopify con plantillas Liquid

El error habitual es aplicar el filtro de escapado sobre el valor. La forma correcta es usar el filtro de serialización a JSON, que aplica las reglas del formato correcto.

// Incorrecto: escapa como HTML dentro de un contexto JSON
"name": "{{ product.title | escape }}"

// Correcto: serializa según las reglas de JSON
"name": {{ product.title | json }}

Nota que en la versión correcta no se escriben las comillas manualmente: el filtro de serialización las incluye. Es un cambio pequeño con efecto grande.

Entornos con JavaScript o headless

Serializa el objeto completo con la función nativa del lenguaje e insértalo sin transformaciones adicionales. Si el framework aplica escapado automático al insertar en el documento, usa la vía explícita que el framework provee para contenido ya serializado, y verifica el resultado en el HTML servido, no en el componente.

Checklist de prevención
permanente.

Corregir el problema de hoy sirve poco si el pipeline lo va a volver a generar la próxima vez que alguien edite una ficha. Estas son las siete reglas que dejo escritas en la documentación técnica de cada cliente con desarrollo a medida:

• Nunca construir JSON concatenando cadenas. Siempre usar la función de serialización del lenguaje.
• Nunca aplicar funciones de escapado de HTML sobre valores que van dentro de un JSON. El contexto es JSON, no HTML.
• Preferir escapes Unicode hexadecimales cuando el marcado atraviesa varias capas de plantillas.
• Verificar siempre el código fuente crudo servido, nunca el DOM del inspector ni el editor visual.
• Incluir la validación de datos estructurados en el proceso de publicación, no solo en auditorías trimestrales.
• Limpiar las entidades HTML en el momento de la migración de contenido, no dejarlas para después.
• Revisar el informe de mejoras de Search Console con periodicidad mensual, para detectar caídas escalonadas antes de que se acumulen.

Una nota sobre proporción

Quiero cerrar con esto porque el tono de urgencia en redes puede desbordarse. Este cambio no es una penalización, no es una actualización de algoritmo y no afecta posiciones. Afecta la elegibilidad para resultados enriquecidos en las páginas cuyo marcado dependía de una tolerancia que Google decidió retirar.

Para la mayoría de sitios que usan generadores estándar, la revisión va a confirmar que todo está bien y no habrá nada que hacer. Para sitios con desarrollo a medida, marcado inyectado manualmente o historial de migraciones, la revisión vale mucho la pena y se hace en una tarde.

La lectura de fondo, que va más allá de este cambio puntual, es que la era de la tolerancia de los parsers se está cerrando en todos los frentes. Un marcado sintácticamente correcto ya no es una buena práctica opcional, es el requisito mínimo para participar. Y con los sistemas de IA leyendo cada vez más contenido estructurado para fundamentar respuestas, la calidad técnica de tu marcado tiene más consecuencias que nunca. Ese contexto lo desarrollo en la guía AI Visibility 2026 desde Colombia.

Preguntas frecuentes
sobre el cambio del parser.

Contenido relacionado
del ecosistema Webhexup.