La mayoría de los sitios que usan JSON-LD hoy no pasarían una comprobación básica: pegar sus datos estructurados en un validador y ver qué sale realmente. No "está optimizado". Simplemente: ¿parsea? ¿Apunta a una sola entidad o a tres que se contradicen? ¿Es markup para un resultado enriquecido que Google todavía concede?
El schema se ha convertido en una casilla que marcar: se instala un plugin, se copia una plantilla de un post de blog, y todo el mundo asume que funciona porque nada cambió visiblemente en la página. Los fallos de datos estructurados son invisibles por diseño. No hay un layout roto que notar. Solo hay un Knowledge Graph que nunca termina de entender quién eres, y resultados enriquecidos que nunca aparecen, y nadie lo depura porque nada parece estar mal.
Qué está haciendo realmente el JSON-LD en 2026
Dos trabajos distintos se meten en el mismo saco de "schema markup", y confundirlos es donde empieza gran parte del esfuerzo desperdiciado.
El primer trabajo son los resultados enriquecidos: las mejoras visuales en el SERP —valoraciones con estrellas, rangos de precio, fechas de eventos, ofertas de empleo, breadcrumbs, miniaturas de video—. Un conjunto reducido de @types califica, y Google cambia ese conjunto sin avisar demasiado.
El segundo trabajo es la claridad de entidad: decirle a Google quién eres, de qué formas parte y cómo se relacionan tus páginas entre sí. Organization, WebSite, Person y WebPage hacen sobre todo este trabajo. Rara vez producen un snippet visible por sí solos, pero de ahí se alimentan el Knowledge Panel, el sitelinks search box y la desambiguación de marca.
La mayoría de los errores de schema que vale la pena corregir caen en uno de tres grupos, y ninguno es sutil una vez que sabes dónde mirar.
Error 1: JSON roto por escapado incorrecto en la plantilla
Este es el fallo más común y el menos visible. Ocurre en la unión entre tu CMS y tu etiqueta <script type="application/ld+json">.
Una cita de una reseña con una comilla doble suelta dentro. Una descripción de producto pegada de una ficha técnica con un salto de línea sin escapar en medio. Cualquiera de estos casos, insertado en una plantilla JSON-LD mediante concatenación de strings ingenua en lugar de una serialización adecuada, produce algo así:
{
"@type": "Product",
"name": "Editor's Choice Desk Lamp",
"description": "The reviewer called it "the best lamp under $50""
}
Esa comilla doble sin escapar rompe el parser de JSON justo en ese punto. El Rich Results Test de Google lo marcará como inválido, pero esa prueba normalmente se ejecuta una sola vez, en el lanzamiento, contra una URL elegida a mano. Nadie vuelve a ejecutarla contra las 400 páginas de producto que se publican seis meses después con los hábitos de puntuación de un nuevo redactor.
La solución no es complicada: nunca construyas el string JSON a mano. Construye el objeto en tu lenguaje de plantillas y serialízalo correctamente (JSON.stringify en JS, json_encode en PHP, el equivalente en lo que sea que renderice tus páginas) para que el escapado lo gestione código que sabe qué es JSON, no un autor de plantillas que no lo sabe. Luego valida el HTML renderizado —la respuesta real que ve un crawler—, no el código fuente de la plantilla. Una plantilla puede parecer perfecta y aun así generar JSON roto ante cualquier string con un carácter especial.
Error 2: Entidades Organization duplicadas sin un @id compartido
Este caso aparece casi siempre que un sitio ha pasado por un rediseño, una migración de CMS, o más de un plugin de SEO al mismo tiempo.
El theme emite un bloque Organization en el footer. Un plugin emite otro en cada página, con un logo y una lista sameAs ligeramente distintos. Un desarrollador añadió un tercero a mano, en la home, hace dos años, para una prueba de schema markup que nunca se limpió. Ninguno comparte un @id.
Para Google, tres objetos Organization sin un identificador compartido no se leen como "un mismo negocio descrito tres veces". Se leen como algo ambiguo: posiblemente tres entidades distintas, posiblemente señales duplicadas que se anulan entre sí. Esa ambigüedad es justo lo que el markup de entidad se supone que debe evitar.
La solución es un único @id canónico, acuñado una vez y referenciado en todas partes:
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/example"]
}
Cada otra página referencia entonces ese @id en lugar de repetir el objeto: el publisher de un WebSite, el author o publisher de un Article, el isPartOf de un WebPage. Una entidad, un conjunto de datos, referenciado de forma consistente. Esto es modelado de grafo, no decoración, y es la diferencia entre que Google unifique tus señales o que Google dude sobre qué versión de ti confiar.
Error 3: Tipos de schema que dejaron de dar resultados
Google redujo los resultados enriquecidos de FAQ en agosto de 2023 a un pequeño grupo de sitios gubernamentales y de salud, y después eliminó la función de Search por completo: esa excepción también desapareció. El markup FAQPage se sigue copiando y pegando en librerías de plantillas y plugins de CMS como práctica recomendada por defecto, y muchos sitios B2B y de e-commerce lo siguen usando, sin obtener nada a cambio, y en algunos casos exponiéndose a un riesgo real: si el texto de FAQ marcado no coincide con lo que se ve visiblemente en la página, eso es una infracción de las directrices de datos estructurados, no solo markup desperdiciado. Los resultados enriquecidos de HowTo desaparecieron de la misma forma: eliminados en móvil en 2023, y después en escritorio, sin ninguna superficie donde el tipo siga generando un resultado visible.
El patrón a vigilar no es solo "este tipo está obsoleto". Es markup que se copió de una plantilla hace tres años y nunca se revisó contra lo que ese tipo hace actualmente. El vocabulario de Schema.org es estable; la disposición de Google a renderizar un tipo dado como resultado enriquecido no lo es, y cambia en un calendario que nadie te notifica.
Qué sigue consiguiendo un resultado enriquecido
La lista que da resultados de forma fiable en 2026: Product con precio real, disponibilidad y AggregateRating proveniente de reseñas genuinas de ese producto específico (la política de reseñas de Google prohíbe explícitamente las reseñas interesadas —un negocio reseñando su propio producto—, así que las reseñas deben ser de clientes reales, no fabricadas); BreadcrumbList; VideoObject; JobPosting; Event; Recipe; y SoftwareApplication con un applicationCategory válido. Junto a ellos, Organization y WebSite con una estructura de @id limpia y sin duplicados siguen haciendo su trabajo más silencioso de claridad de entidad y elegibilidad para el sitelinks search box, incluso sin un snippet visible propio.
Una auditoría mínima que vale la pena hacer cada trimestre
- Valida la respuesta HTML renderizada, no el archivo de plantilla: los errores de escapado solo aparecen después del renderizado.
- Busca en tu código cada lugar donde se emite
OrganizationoWebSite. Si hay más de uno, consolídalos detrás de un@idcompartido. - Contrasta cada
@typeque usas con la documentación actual de datos estructurados de Google, no con el post de blog del que lo copiaste. - Revisa mensualmente los informes de Enhancements de Search Console: un pico en errores de "Invalid JSON-LD" o "Missing field" suele deberse a un despliegue, no a un cambio de política de Google.
- Confirma que cada dato marcado (una puntuación de reseña, una respuesta de FAQ, un precio) sea visible en la página en la misma forma. Un markup que no está respaldado por contenido visible es una infracción de directrices esperando a ser detectada.
Conclusión
Los datos estructurados son infraestructura, no decoración: fallan como falla la infraestructura, en silencio, hasta que una auditoría o una acción manual los saca a la luz. Los sitios que consiguen resultados enriquecidos en 2026 no son los que tienen más schema. Son los que tienen un JSON que realmente parsea, entidades que resuelven a un único @id, y un markup que coincide con lo que una persona ve en la página.
Si quieres que esto se revise correctamente —output renderizado, no código fuente de plantilla—, nuestro equipo de SEO ejecuta la validación de datos estructurados como parte estándar de cada auditoría técnica, junto al trabajo de crawlability y Core Web Vitals que suele estar justo al lado.
