Hoy los SEO debemos revisar nuestras webs. Google endurece su extractor de JSON-LD: el error invisible en el SEO técnico que puede arruinar tus datos estructurados y perder presencia en el buscador de Google.
El Search Engine Optimization (SEO) técnico se mueve a menudo en una escala invisible para el usuario final. Un cambio de un solo carácter en una línea de código no siempre rompe una página web a simple vista, pero puede cegar por completo a los algoritmos que interpretan su contenido. Esto es exactamente lo que acaba de ocurrir con una de las actualizaciones de infraestructura más silenciosas pero de mayor impacto operativo comunicadas por Google Search Central: el cambio estricto en la política de desescape HTML en su extractor de JSON-LD.
Hasta la fecha, el motor de búsqueda mantenía una postura extremadamente permisiva respecto a cómo las webs codificaban sus datos estructurados. Si una plantilla, un plugin mal optimizado o un sistema de gestión de contenidos (CMS) cometía el error de enviar un carácter especial transformado o «escapado» dos veces por error, Google lo corregía de forma implícita tras bambalinas. Esa tolerancia ha terminado.
Google ha modificado de forma oficial el comportamiento de su parser de datos estructurados para alinearse de manera estricta con las especificaciones estándar de JSON. A partir de ahora, la herramienta de extracción de datos de Google Search solo aplicará una única pasada de desescape HTML (HTML unescaping) y se detendrá inmediatamente ahí.
Esta modificación no representa una actualización de algoritmos de clasificación de core ranking, ni introduce una nueva penalización algorítmica o manual contra los sitios web. Sin embargo, su consecuencia práctica en el posicionamiento orgánico y la presencia en Google Discover es innegable: miles de etiquetas JSON-LD que antes pasaban el filtro de Google ahora conservarán texto literal corrupto, degradando la calidad del dato entidad, provocando la pérdida de resultados enriquecidos (rich snippets) y perjudicando la visibilidad en el feed de contenidos.
Anatomía del cambio: ¿Qué ha modificado exactamente Google Search Central?
Para comprender el impacto de esta directiva de Google Search Central, es crucial entender cómo leen los motores de búsqueda las entidades dentro del código fuente de una página. El marcado JSON-LD (JavaScript Object Notation for Linked Data) es el estándar recomendado por Google para implementar datos estructurados, permitiendo a los robots clasificar productos, artículos, organizaciones, eventos y autores.
Historicamente, el proceso de renderizado y extracción de datos de Google operaba con capas de tolerancia. Si un fragmento de código JSON-LD declaraba el nombre de una marca como M&M’s, el extractor de Google ejecutaba una primera pasada para convertir & en &, y al detectar que aún quedaba una entidad HTML sin resolver, aplicaba una segunda iteración para convertir & en el carácter &.
Con el nuevo criterio técnico, Google detiene la interpretación tras la primera pasada.
El patrón del problema: Del carácter UTF-8 al doble escapado
El problema no radica en un ampersand tradicional ni en una entidad HTML correctamente declarada una sola vez. El fallo aparece cuando se añade una segunda capa de procesamiento por error en la cadena de desarrollo web o en la tubería de datos (data pipeline).
[ Primer Escapado HTML: & ] ↓
[ Segundo Escapado por Error: & ]
Bajo el nuevo parser de Google:
- Entrada en código JSON-LD: «name»: «M&M’s»
- Resultado que procesa Google ahora: «M&M’s» (Texto corrupto en lugar del nombre real de la marca).
- Entrada de un símbolo numérico: «description»: «Envío gratis ✔»
- Resultado procesado con doble escape (✔): «Envío gratis ✔» (Símbolo de verificación roto que se muestra como texto plano).
La recomendación oficial del estándar JSON y de la documentación de Google es directa: las cadenas de texto deben utilizar caracteres UTF-8 directamente cuando el estándar lo permite, o en su defecto, el escape sintáctico propio del lenguaje JSON (como utilizar \u0026 para representar el carácter &). Tratar de resolver esto codificando entidades HTML dentro de una estructura JSON representa una mala práctica de desarrollo que ahora pagará peaje técnico.
Las consecuencias prácticas en e-Commerce, Medios y Google Discover
Aunque este ajuste no altera los sistemas de ordenación algorítmica de los resultados de búsqueda (search rankings), el impacto indirecto en la analítica de negocio es considerable. Los datos estructurados son el lenguaje primario mediante el cual Google construye la gráfica de conocimiento (Knowledge Graph) y comprende las entidades clave de un sitio web.
+——————————————————————————-+
| CADENA DE IMPACTO EN EL SEO |
+——————————————————————————-+
| 1. Plantilla/Plugin aplica doble escapado HTML en el código JSON-LD |
| ↓ |
| 2. Google ejecuta solo 1 pasada de ‘unescape’ → El valor queda corrupto |
| ↓ |
| 3. El validador invalida la propiedad (ej: Tipo de Moneda, Precio, Título) |
| ↓ |
| 4. Pérdida de Rich Snippets (Estrellas, Precios, Stock) en la SERP |
| ↓ |
| 5. Caída drástica del Click-Through Rate (CTR) y pérdida de tráfico en Discover|
+——————————————————————————-+
1. Inelegibilidad para Resultados Enriquecidos (Rich Snippets)
Si una ficha de producto en un comercio electrónico pierde la interpretación del campo price, priceCurrency o availability debido a caracteres extraños generados por un doble escape, Google descalificará la página automáticamente para mostrar las fragmentos enriquecidos (estrellas de valoración, rango de precios o stock disponible) en la SERP.
2. Contaminación de Datos de Entidad y Desconexión del Knowledge Graph
Para sitios de noticias, blogs editoriales y páginas corporativas, los tipos Article, NewsArticle y Organization son críticos. Si el nombre del autor, la entidad editora o los titulares contienen códigos como " en lugar de comillas normales, los motores de indexación perderán la trazabilidad de la entidad.
3. Impacto Severo en la Aparición en Google Discover
Google Discover depende estrechamente de la claridad sintáctica y la calidad del marcado del contenido editorial. La pérdida de elegibilidad en fragmentos visuales o la degradación de la semántica en el marcado NewsArticle reduce considerablemente las probabilidades de que una noticia sea impulsada en los feeds personalizados de los usuarios.
Puntos críticos de fallo: Dónde se origina el doble escapado HTML
No todos los sitios web están expuestos a esta vulnerabilidad. Las plataformas que generan su marcado JSON-LD mediante librerías nativas bien depuradas no se verán afectadas. Sin embargo, la falla suele manifestarse en arquitecturas complejas donde los datos sufren múltiples transformaciones antes de imprimirse en el DOM.
|
Entorno / Arquitectura |
Causa del Doble Escapado |
Nivel de Riesgo |
|---|---|---|
|
Plugins SEO en WordPress / WooCommerce |
Procesan campos de texto que ya fueron filtrados por sanitizadores HTML de WordPress (esc_html, wp_kses). |
Alto |
|
Integraciones Headless & Frameworks JS |
Renderizado en servidor (SSR) o cliente (CSR) que serializa objetos JSON previamente codificados como cadenas HTML. |
Alto |
|
Feeds de Datos, ERPs y PIMs |
Exportación de catálogos desde bases de datos externas donde los caracteres especiales sufren transformaciones previas. |
Medio-Alto |
|
Temas Hijo y Snippets Personalizados |
Creación de bloques <script type=»application/ld+json»> mediante concatenación manual de strings en PHP/JS. |
Crítico |
|
Sistemas de Comentarios y Reseñas |
Entrada de datos por parte del usuario final sin un proceso claro de desescapado previo a la serialización JSON. |
Medio |
Guía de auditoría paso a paso: Cómo auditar y solucionar el error en tu web
Para afrontar esta actualización no es necesario realizar migraciones masivas ni cundir en el pánico técnico. La clave reside en realizar auditorías dirigidas sobre los componentes del sistema que generan los fragmentos de código.
+———————————-+
| Identificar Páginas Críticas |
| (Home, Producto, Artículo) |
+———————————-+
|
v
+———————————-+
| Insponar CÓDIGO FUENTE RAW |
| (Evitar el DOM alterado por JS) |
+———————————-+
|
v
+———————————-+
| ¿Existen secuencias como |
| &amp; o ✔? |
+———————————-+
/ \
/ \
SÍ / \ NO
v v
+—————————-+ +—————————-+
| Corregir la FUENTE del | | Validar en Rich Results |
| dato (Backend/Plugin) | | Test de Google Search |
+—————————-+ +—————————-+
| |
v v
+————————————————————-+
| Monitorear Search Console (Sección Datos Estructurados) |
+————————————————————-+
Paso 1: Inspección del código fuente «Raw»
No confíes únicamente en el inspector de elementos de tu navegador (F12), ya que el árbol DOM renderizado por JavaScript suele corregir o alterar la representación de caracteres de forma automática.
- Haz clic derecho en la página y selecciona Ver código fuente de la página (Ctrl + U o Cmd + Option + U).
- Presiona Ctrl + F y busca la etiqueta <script type=»application/ld+json»>.
- Ejecute una búsqueda de los siguientes patrones problemáticos dentro del JSON:
- &amp;
- &quot;
- &#
- < o > duplicados dentro de cadenas de texto explícitas.
Paso 2: Análisis por tipos de entidad clave
Focaliza tu esfuerzo de auditoría en los tipos de marcado que mueven la aguja de tu negocio:
- e-Commerce: Revisa el esquema Product. Presta atención a las propiedades name, description, brand y los campos de offers.
- Editoriales y Medios: Revisa Article y NewsArticle. Comprueba que headline, articleBody y los datos del author mantengan caracteres limpìos.
- Empresas y Negocios Locales: Inspecciona Organization y LocalBusiness. Verifica nombres comerciales, direcciones físicas (streetAddress) y descripciones de servicio.
- Navegación: Inspecciona los esquemas de BreadcrumbList, donde las comillas y divisores suelen sufrir problemas de codificación.
Paso 3: Validación con la Herramienta de Resultados Enriquecidos
Accede a la herramienta oficial Rich Results Test (Prueba de resultados enriquecidos de Google). Introduce la URL o copia directamente el código HTML extraído.
- Comprueba si Google parsea la propiedad con el valor de texto real o si mantiene caracteres de entidad HTML en la vista previa del informe de extracción.
Solución en WordPress, WooCommerce y Desarrollos a Medida
Si detectas que tu sitio web está emitiendo marcado con doble escape, nunca intentes corregir el marcado editando manualmente cada entrada o producto. La solución debe aplicarse en la capa donde se genera la información.
Buenas prácticas en entornos WordPress
En el ecosistema de WordPress es habitual que varios complementos intenten inyectar datos estructurados simultáneamente.
- Establece un único responsable: Configura un solo plugin para la gestión global del Schema (por ejemplo, centralizando todo en tu plugin SEO de cabecera como Rank Math o Yoast SEO) y desactiva los módulos de Schema secundarios incluidos en tu plantilla.
- Sanitización correcta de datos: Si desarrollas integraciones personalizadas dentro de functions.php, evita concatenar fragmentos de código HTML o usar addslashes() sin control dentro del script.
- Uso de la función nativa de serialización: Construye primero un array de PHP limpio y conviértelo a JSON mediante las funciones del sistema:
// CÓDIGO INCORRECTO (Propenso a doble escapado por concatenación)
$json_code = ‘{
«@context»: «https://schema.org»,
«@type»: «Product»,
«name»: «‘ . esc_html($product_name) . ‘»
}’;
// CÓDIGO CORRECTO (Garantiza un escape JSON nativo y limpio)
$schema_data = [
«@context» => «https://schema.org»,
«@type» => «Product»,
«name» => $product_name // El valor se pasa en texto plano sin sanitizar como HTML
];
echo ‘<script type=»application/ld+json»>’ . wp_json_encode($schema_data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) . ‘</script>’;
Al utilizar wp_json_encode() combinado con la constante JSON_UNESCAPED_UNICODE, WordPress se encarga de serializar correctamente los símbolos, acentos, eñes y caracteres especiales bajo el estándar nativo de JSON, eliminando por completo cualquier entidad HTML residual.
Checklist de mantenimiento SEO Técnico
Para garantizar que tu sitio web cumple estrictamente con el nuevo parser de Google, incorpora este protocolo en tu rutina de auditoría técnica:
- [ ] Muestra representativa: Selecciona entre 5 y 10 URLs tipo que representen cada arquitectura de plantilla (Home, Categoria, Ficha de Producto, Noticia, Pagina de Servicio).
- [ ] Rastreo de patrones: Realiza una búsqueda mediante rastreadores tipo Screaming Frog o Sitebulb utilizando extracción de código personalizada (Custom Extraction) con expresiones regulares para localizar &amp; dentro de bloques ld+json.
- [ ] Control de fuentes de datos: Verifica que los feeds externos, sistemas ERP, PIM o importadores masivos no estén inyectando datos previamente transformados en HTML a la base de datos de tu CMS.
- [ ] Entorno de Staging: Prueba cualquier corrección de código o actualización de plugins en un entorno de pruebas antes de desplegar en producción.
- [ ] Seguimiento en Search Console: Monitoriza la pestaña «Resultados enriquecidos» dentro de Google Search Console durante las 2 o 3 semanas posteriores a la corrección para confirmar la resolución de advertencias o errores de extracción.
Preguntas Frecuentes (FAQ)
¿Este cambio en el extractor de JSON-LD implica una penalización para mi web?
No. Google no aplica ningún tipo de sanción manual ni penalización algorítmica por este motivo. Se trata de un ajuste en el funcionamiento del parser informático. El único riesgo es la pérdida de interpretación de ciertos datos estructurados, lo que puede provocar que la web deje de mostrar fragmentos enriquecidos (estrellas, precios, etc.) en las páginas de resultados.
¿Cómo sé si mi plugin SEO en WordPress está afectado por este problema?
Las versiones actualizadas de los principales plugins SEO (como Rank Math, Yoast SEO o SEOPress) suelen generar el código JSON-LD de forma correcta. Sin embargo, el problema aparece si dichos plugins consumen títulos, marcas o descripciones que han sido previamente escapadas por un tema personalizado, un maquetador visual o un plugin de importación de catálogo. La mejor forma de saberlo es revisar el código fuente directamente.
¿Es necesario cambiar todo el marcado JSON-LD de mi web a UTF-8?
No es obligatorio reescribir todo el marcado si este se encuentra bien generado. Si tu código JSON-LD actual utiliza caracteres UTF-8 normales o los escapes propios del lenguaje JSON (como \u0026), no debes hacer nada. Solo debes actuar si descubres la presencia de entidades HTML que han sido escapadas dos veces (como &amp;).
¿Por qué mi web mostraba resultados enriquecidos antes y ahora han desaparecido?
Si tus fragmentos enriquecidos han dejado de aparecer recientemente sin que hayas modificado el contenido de las páginas, es muy probable que Google haya re-rastreado tu sitio con el nuevo extractor. Al no poder interpretar correctamente las propiedades del JSON-LD debido al doble escapado, el motor de búsqueda clasifica el marcado como incompleto o inválido.
¿Debo migrar de JSON-LD a Microdatos o RDFa para evitar este fallo?
No. Google mantiene a JSON-LD como el formato totalmente preferido y recomendado para la implementación de datos estructurados por su facilidad de mantenimiento y desacoplamiento del diseño HTML. Cambiar de formato no soluciona el problema de fondo (que es la mala codificación del dato en la base de datos) y añadiría una complejidad innecesaria al desarrollo de la web.
En resumen, Google ha dejado de ser tan tolerante con un error que suele pasar desapercibido: el JSON-LD con entidades HTML escapadas dos veces.
El cambio no es una actualización de rankings ni una nueva penalización. Afecta a cómo Google extrae ciertos valores del marcado. Si una plantilla, plugin o integración enviaba un carácter convertido dos veces, Google podía corregirlo de forma implícita. Ahora solo aplica una pasada de desescape HTML y se detiene ahí.
El aviso original está publicado por Google Search Central. La regla de fondo es la misma que define el estándar de JSON: las cadenas deben escaparse con sintaxis JSON, no mediante una cadena de transformaciones HTML.
Sus directrices de datos estructurados siguen recomendando JSON-LD y recuerdan que la validez no equivale a una apariencia garantizada en resultados.
Haz una prueba de resultados enriquecidos. Sirve para detectar muchos problemas técnicos, pero no sustituye leer el valor que finalmente genera la plantilla. Puedes acceder a ella desde el Rich Results Test de Google. Te ahorrara tiempo y disgustos.
. Leer artículo completo en Frikipandi Google endurece su extractor de JSON-LD: el error invisible en el SEO técnico que puede arruinar tus datos estructurados.
Entradas recientes para Google endurece su extractor de JSON-LD: el error invisible en el SEO técnico que puede arruinar tus datos estructurados
- Google endurece su extractor de JSON-LD: el error invisible en el SEO técnico que puede arruinar tus datos estructurados
- Nueva temporada, nuevo comienzo con MOVA: simplifica tus tareas diarias
- EA SPORTS FC celebra la Clase del 27, rindiendo homenaje a una nueva generación de ICONOS
- OPPO Find X9 Ultra gana el premio EISA a "Smartphone para foto y vídeo de 2026-2027"
- League of Legends: Caps, primer jugador occidental en el Hall of Legends