Un bloque de script JSON-LD con marcado Article de Schema.org en un editor de código
Un bloque de script JSON-LD con marcado Article de Schema.org en un editor de código

¿Qué es JSON-LD?

Visibilidad en buscadores, rastreo y datos estructurados

JSON-LD, abreviatura de JavaScript Object Notation for Linked Data, es un formato basado en JSON para publicar datos enlazados: las entidades, propiedades y relaciones de una página. Es el formato más utilizado para añadir datos estructurados de Schema.org, como Article y BreadcrumbList, lo que ayuda a las máquinas a comprender una página. JSON-LD es un estándar W3C. No es un atajo para mejorar el posicionamiento, y los datos estructurados válidos no garantizan resultados enriquecidos. El marcado debe describir contenido realmente visible en la página, y la página debe ser rastreable e indexable para obtener beneficios.

Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026

Qué significa esto

JSON-LD es una forma ordenada de describir de qué trata una página en un formato que las máquinas pueden leer. En lugar de dejar que un motor de búsqueda infiera el significado a partir de las palabras en pantalla, se declara directamente: por ejemplo, que esta página es un artículo, con este titular, este autor y esta fecha de publicación.

Conviene distinguir cuatro conceptos que suelen confundirse. JSON es un formato de datos general. JSON-LD es una variante específica de JSON para datos enlazados. Schema.org es el vocabulario compartido de tipos y propiedades, como Article o Person. El marcado de datos estructurados es la práctica de usar un formato como JSON-LD para publicar ese vocabulario en una página. JSON-LD es popular porque reside en un bloque de código independiente, en lugar de estar entretejido en el HTML visible, lo que facilita su incorporación, uso en plantillas y mantenimiento.

Por qué importa

Que las máquinas comprendan claramente una página es una característica de una buena publicación. Cuando un motor de búsqueda puede leer de forma fiable quién escribió una página, cuándo se actualizó y de qué trata, resulta más fácil representarla con precisión y mostrarla ante las consultas adecuadas. JSON-LD es el formato que Google recomienda para esto, aunque Microdata y RDFa también son compatibles y se consideran igualmente válidos cuando se implementan correctamente.

La advertencia comercial es que los datos estructurados no son magia. No mejoran el posicionamiento por sí solos, y un marcado correcto no garantiza un resultado enriquecido. Los motores de búsqueda deciden qué mostrar en función de muchos factores, y pueden ignorar o rechazar un marcado que sea engañoso o no coincida con la página visible. El valor proviene de un marcado preciso y representativo en páginas que ya merecen mostrarse, no de marcar contenido escaso u oculto.

Cómo funciona

Un estándar W3C para datos enlazados

JSON-LD es un estándar W3C publicado. Se convirtió en Recomendación W3C por primera vez en 2014, y la versión actual, JSON-LD 1.1, obtuvo ese estatus en 2020. Define una forma basada en JSON de serializar datos enlazados para que la misma información pueda compartirse y comprenderse en distintos sistemas. En páginas web, se utiliza principalmente para publicar el vocabulario de Schema.org dentro de un bloque de script de tipo application/ld+json.

Tipos y campos habituales

Para un artículo, el tipo de Schema.org correspondiente es Article, o los más específicos NewsArticle o BlogPosting. Los campos que ayudan a un motor de búsqueda a comprender la página incluyen el titular, el autor con nombre y URL, la fecha de publicación, la fecha de modificación, una imagen y la referencia canónica. Conviene que el titular sea conciso, ya que los muy largos pueden truncarse; las directrices de Google sugieren mantenerlo en torno a 110 caracteres. Las rutas de navegación se describen con BreadcrumbList y sus entradas ListItem, que indican la posición de la página dentro de la jerarquía del sitio.

La regla de que el marcado debe representar la página

Los datos estructurados deben describir el contenido que realmente aparece en la página y ser representativos de su contenido principal. Marcar contenido oculto, irrelevante o engañoso incumple las directrices y puede provocar que el marcado sea ignorado o tratado como spam, un límite de credibilidad que conviene respetar. El marcado es una declaración veraz sobre la página, no una versión alternativa de ella.

Dónde se genera el marcado

JSON-LD puede añadirse en el servidor, a través de una plantilla de sistema de gestión de contenidos, o inyectarse con JavaScript, incluso mediante un gestor de etiquetas. Cada método funciona, pero los enfoques de inyección conllevan más riesgo. Si una página comienza con una instrucción noindex, un motor de búsqueda puede omitir el renderizado y no ejecutar nunca el JavaScript que habría añadido el marcado. Los desajustes en el gestor de etiquetas también pueden dejar el marcado renderizado desincronizado con la página. El marcado en el servidor o basado en plantillas, que aparece en el HTML inicial, es el más fiable.

Elegibilidad y funciones de IA

Un marcado válido es necesario, pero no suficiente. Una página debe ser indexable y apta para mostrarse con un fragmento antes de poder optar a resultados enriquecidos o a funciones generativas como AI Overviews. No bloquees las páginas con datos estructurados mediante robots.txt o noindex si quieres que sean elegibles. Para las funciones de IA de Google en concreto, no existe ningún requisito especial de datos estructurados ni ningún marcado adicional que añadir. Se aplican los mismos fundamentos: una página rastreable e indexable que sea apta para aparecer con un fragmento.

El estado actual de los resultados enriquecidos de FAQ

Los tipos de datos estructurados cambian con el tiempo, y la función FAQ es un ejemplo reciente claro. La documentación de Google indica que, a partir del 7 de mayo de 2026, los resultados enriquecidos de FAQ han dejado de aparecer en Google Search. La apariencia de búsqueda de FAQ, el informe de resultados enriquecidos y el soporte en la Prueba de Resultados Enriquecidos se eliminarán en junio de 2026, y el soporte para el resultado enriquecido de FAQ en la API de Search Console se retirará en agosto de 2026. FAQPage sigue siendo un tipo válido de Schema.org, por lo que el marcado en sí no es inválido y puede mantenerse, pero ya no genera esa función de búsqueda visible. Los resultados enriquecidos de HowTo se deprecaron de forma similar en 2023, y la documentación de HowTo ha sido eliminada desde entonces. La lección para los responsables es que las funciones de resultados enriquecidos aparecen y desaparecen, mientras que el valor subyacente de unos datos estructurados precisos y representativos perdura.

Ejemplos

Un equipo de contenidos asigna a cada tipo de página el tipo de Schema.org correspondiente: Article para piezas editoriales y BreadcrumbList para el contexto de navegación, y verifica que el titular, el autor, la fecha de publicación y la fecha de modificación se obtienen de los campos correctos y no se dejan con los valores predeterminados de la plantilla.

Una empresa que anteriormente añadió marcado FAQ para conseguir una función de búsqueda expandible revisa sus páginas tras la retirada de dicha función. Mantiene el marcado FAQ donde refleja con precisión una sección real y visible de preguntas y respuestas, y lo elimina donde la sección era escasa y se añadió únicamente para la antigua función.

Un equipo de desarrollo traslada los datos estructurados del gestor de etiquetas a la plantilla de página, tras comprobar que el marcado inyectado a veces no se renderizaba correctamente. A continuación, valida el marcado renderizado frente a la página visible mediante una herramienta de prueba de datos estructurados antes de cada lanzamiento.

Malentendidos frecuentes

El error más común es esperar que los datos estructurados mejoren el posicionamiento. Ayudan a las máquinas a comprender una página, pero no son un atajo para el posicionamiento ni garantizan un resultado enriquecido.

Un segundo error es marcar contenido que no es visible en la página, lo que incumple las directrices y puede tratarse como spam.

Un tercero es asumir que un marcado válido es suficiente. Los datos estructurados pueden ser técnicamente válidos pero deficientes, con valores obsoletos o incorrectos, y un marcado correcto sigue sin garantizar un resultado enriquecido.

Un cuarto es confundir los componentes básicos. JSON, JSON-LD, Schema.org y el marcado de datos estructurados son conceptos distintos, y tener claridad sobre cuál es cuál evita errores de implementación.

Riesgos y límites

Los fallos en la asignación de campos son el riesgo práctico más frecuente. Un sistema de gestión de contenidos puede publicar un titular obsoleto, fechas incorrectas, una ruta de navegación predeterminada o el editor equivocado, de modo que el marcado representa erróneamente la página sin que nadie lo advierta.

El exceso de marcado es un segundo riesgo: los equipos marcan todo con la esperanza de obtener más funciones, lo que añade ruido sin aportar valor.

El riesgo del ciclo de vida y las plantillas es un tercero. Un cambio de plantilla o una actualización de complemento puede romper o alterar el marcado de forma silenciosa, por lo que es necesario volver a probarlo tras cualquier modificación.

El límite de credibilidad es la restricción firme. Los motores de búsqueda pueden ignorar o rechazar un marcado que sea engañoso o no coincida con la página visible, por lo que el marcado debe ser siempre una representación fiel de lo que ve el lector. Bloquear las páginas con datos estructurados mediante robots.txt o noindex elimina la elegibilidad que el marcado pretendía respaldar.

Próximos pasos

Elige tipos de Schema.org que realmente correspondan a cada página, y evita marcar contenido que no esté presente o no sea visible.

Alinea la responsabilidad editorial y técnica, de modo que quienes escriben titulares y fechas y quienes construyen las plantillas estén de acuerdo sobre el origen de cada campo. Audita tu marcado con una herramienta de prueba de resultados enriquecidos y compara los datos estructurados renderizados con la página visible para detectar valores obsoletos o desajustados. Considera los datos estructurados como una inversión duradera en la comprensión por parte de las máquinas, y no como una búsqueda de cualquier función de resultado enriquecido concreta, ya que funciones como FAQ y HowTo han sido retiradas mientras que un marcado preciso mantiene su valor.

¿Tienes alguna pregunta o sugerencia, o quieres saber cómo investigamos y revisamos estas guías? Lee sobre nuestros estándares editoriales y cómo contactarnos.

Preguntas frecuentes

¿Cuál es la diferencia entre Article y BlogPosting?

BlogPosting es un tipo más específico de Article, pensado para publicaciones de estilo blog, mientras que Article es adecuado para contenido escrito general y NewsArticle para el periodismo. Usa el tipo más específico que realmente se ajuste a la página. Los tres son compatibles y utilizan campos similares.

¿Ayudará JSON-LD a que mis páginas aparezcan en búsquedas de IA?

Como mucho, de forma indirecta. Una página debe ser indexable y apta para mostrarse con un fragmento antes de que las funciones de IA la tengan en cuenta, y Google afirma que no existe ningún requisito especial de datos estructurados para sus funciones de IA. Un marcado preciso favorece la comprensión por parte de las máquinas, pero no es una vía garantizada hacia la visibilidad en IA.

¿Es seguro inyectar JSON-LD con JavaScript o un gestor de etiquetas?

Puede funcionar, pero conlleva riesgo. Si una página comienza con una instrucción noindex, el motor de búsqueda puede omitir el renderizado y no ejecutar nunca el script, y las configuraciones del gestor de etiquetas pueden desincronizarse con la página. El marcado en el servidor o basado en plantillas, incluido en el HTML inicial, es más fiable.

¿Los datos estructurados válidos garantizan un resultado enriquecido?

No. Un marcado correcto hace que una página sea elegible para una función, pero no la garantiza. Los motores de búsqueda deciden qué mostrar en función de muchos factores y pueden mostrar un resultado estándar en su lugar.

¿Cuáles son los errores más comunes en los CMS con JSON-LD?

Valores de campo obsoletos o incorrectos, como un titular antiguo, fechas de publicación o modificación incorrectas, una ruta de navegación predeterminada o el editor equivocado. Estos errores provienen de una asignación de campos deficiente y se detectan comparando el marcado renderizado con la página visible.

¿Siguen apareciendo los resultados enriquecidos de FAQ en Google?

No. La documentación de Google indica que, a partir del 7 de mayo de 2026, los resultados enriquecidos de FAQ ya no aparecen en Google Search, y el soporte de informes y pruebas se eliminará en junio de 2026, mientras que el soporte de la API de Search Console se retirará en agosto de 2026. FAQPage sigue siendo un tipo válido de Schema.org, por lo que el marcado no es inválido; simplemente ya no genera esa función.

¿Debo eliminar ahora mis datos estructurados de FAQ?

No necesariamente. Mantenlos donde describan con precisión una sección real y visible de preguntas y respuestas, ya que los datos estructurados no utilizados no causan problemas. Elimínalos donde la sección era escasa o se añadió únicamente para conseguir la antigua función.

¿Qué formato de datos estructurados debo usar?

Google recomienda JSON-LD por su facilidad de implementación y mantenimiento, aunque Microdata y RDFa también son compatibles y se consideran igualmente válidos cuando se implementan correctamente. Para la mayoría de los trabajos nuevos, JSON-LD es la opción práctica por defecto.

¿JSON-LD solo es útil para Google?

No. Es un estándar W3C abierto para datos enlazados que se utiliza en muchos sistemas, y otros motores de búsqueda y herramientas pueden leer el marcado de Schema.org publicado en JSON-LD. Su valor reside en la comprensión general por parte de las máquinas, no en una sola plataforma.

Fuentes

  • JSON-LD 1.1 (W3C). Confirmation that JSON-LD is a W3C Recommendation and a JSON based format for serialising linked data.

  • JSON-LD 1.1 Specifications are W3C Recommendations (W3C). The date JSON-LD 1.1 became a W3C Recommendation and the description of its purpose.

  • FAQPage type (Schema.org). Confirmation that FAQPage remains a current, valid Schema.org type that is not deprecated.

  • Mark Up FAQs with Structured Data (FAQPage) (Google Search Central). The deprecation notice stating FAQ rich results no longer appear as of 7 May 2026, with reporting and Rich Results Test support removed in June 2026 and Search Console API support removed in August 2026.