Datos estructurados JSON-LD

TL;DR — JSON-LD es un pequeño bloque de código que añades a una página para explicar de qué trata —si es un artículo, un producto o una receta— en un formato que los motores de búsqueda y los sistemas de IA leen fácilmente. Vive dentro de su propia etiqueta <script> y no cambia nada de lo que ven los visitantes. Google lo recomienda frente a los otros dos formatos porque es el más fácil de añadir y mantener ordenado. No hará que te posiciones mejor, pero puede hacer que tus resultados sean más completos (estrellas, precios, preguntas frecuentes).

Qué es JSON-LD

Cuando publicas una página, una persona puede leerla y deducir «ah, es una receta de pan de plátano». Un motor de búsqueda tiene que inferirlo a partir de las palabras. Los datos estructurados evitan esa inferencia: etiquetas la página con código legible por máquinas para que los motores sepan que es una receta, quién es el autor o cuál es la valoración.

JSON-LD es la forma más popular de escribir esa etiqueta. El nombre significa notación de objetos JavaScript para datos enlazados. Evidence for this claim JSON-LD is a structured-data format that can express Schema.org types and properties in a script block. Scope: Schema.org JSON-LD guidance; JSON-LD is a format, not the vocabulary itself. Confidence: high · Verified: 2026-07-14 Schema.org: JSON-LD No necesitas saber qué significa para usarlo. En la práctica, JSON-LD es un fragmento de código que parece una lista de datos etiquetados, dentro de una etiqueta <script>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Bake Banana Bread",
  "author": { "@type": "Person", "name": "Patrick Stox" },
  "datePublished": "2026-06-26"
}
</script>

Lo importante es que ese bloque vive separado de las palabras de tu página. No cambia ni una sola cosa de lo que ven tus visitantes. Son simplemente instrucciones para los robots.

Por qué le gusta a Google

En realidad hay tres formas de escribir datos estructurados: JSON-LD, Microdata y RDFa. Las otras dos funcionan esparciendo código adicional dentro de tu HTML visible, mezclado con tus títulos y párrafos. JSON-LD lo mantiene todo en una caja ordenada.

Por eso Google recomienda JSON-LD: es el más fácil de añadir, el más fácil de mantener correcto y es mucho menos probable que algo se rompa. En palabras de Google, es “the easiest solution for website owners to implement and maintain at scale.” (traducción) «la solución más fácil de implementar y mantener a escala para quienes gestionan sitios web». Los tres formatos son válidos: JSON-LD simplemente es el que menos errores provoca.

Qué hace realmente por ti

Dos hechos honestos y un mito:

• Puede hacer que tu resultado de búsqueda parezca más completo. Las valoraciones de recetas, los precios de productos, los desplegables de preguntas frecuentes y las fechas de eventos aparecen como «resultados enriquecidos» gracias a los datos estructurados.
• Ayuda a los motores (y a la IA) a entender tu contenido. Conecta tu página con entidades conocidas: tu empresa, un autor o un producto.
• No hace que te posiciones mejor. Este es el mito. Añadir JSON-LD no mejora directamente el posicionamiento. Google lo ha dicho de forma clara y repetida.

La única regla que importa

Marca únicamente lo que está realmente en la página. No declares una valoración de 5 estrellas en tu JSON-LD si los visitantes no ven ninguna valoración. No describas un precio que no aparece. Los datos estructurados tienen que coincidir con la página visible: describir cosas que no están ahí incumple las reglas y puede hacer que retiren tus resultados enriquecidos.

¿Quieres la versión precisa —la sintaxis @context / @type / @id, el patrón @graph, la trampa de la inyección de JavaScript que oculta tu marcado a los rastreadores de IA y cómo validarlo—? Cambia a la pestaña Avanzado.

TL;DR — JSON-LD (notación de objetos JavaScript para datos enlazados) es una recomendación del W3C de 2014: se basa en JSON, pero @context es lo que lo convierte en datos enlazados, no en simple JSON. Es el formato de datos estructurados que recomienda Google porque es el más fácil de implementar y mantener a escala y nunca toca el HTML visible; Microdata y RDFa son igual de válidos cuando son correctos. La columna vertebral de la sintaxis es @context (el vocabulario: schema.org para la mayoría del marcado SEO, aunque la especificación permite otros contextos), @type (la entidad) y @id (una URI estable útil, pero opcional, para referenciar entidades; es la base de @graph, que es un patrón válido entre otros y no un requisito). Colócalo en <head> o <body>: Google acepta ambos. Googlebot renderiza JS, por lo que el JSON-LD inyectado dinámicamente funciona para Google; varios rastreadores de IA (incluidos GPTBot y ClaudeBot, según las pruebas) no ejecutan JS, pero esto depende del proveedor y de la fecha: verifícalo directamente en vez de suponerlo para todos los rastreadores de IA, y renderiza en el servidor lo que no puedas confirmar. Los datos estructurados no son una señal de posicionamiento: impulsan la elegibilidad para resultados enriquecidos y la comprensión de entidades, y deben describir contenido visible en la página.

JSON-LD es un formato, no un vocabulario

Primero, una distinción que aclara mucha confusión: JSON-LD es el formato; schema.org es el vocabulario. JSON-LD es cómo escribes el marcado; los tipos Article, Product y Organization de schema.org son lo que expresas. Los resultados enriquecidos son la capa de funcionalidades que se coloca sobre ambos. Esta página trata sobre el formato. El enfoque del vocabulario para la IA está en Schema Markup for AI.

JSON-LD es una recomendación del W3C, publicada por primera vez en 2014. Es anterior a su adopción en SEO y se diseñó para la interoperabilidad general de datos enlazados en la web, no específicamente para la búsqueda. Por eso existe una propiedad como @id, y este es el punto de nivel de especificación que la mayoría de las guías de SEO omiten: JSON-LD no es simplemente JSON. Se basa en la sintaxis JSON, pero la declaración @context es lo que hace que los datos estén enlazados: sean identificables y conectables en la web. Si eliminas @context, tienes datos que un analizador no puede interpretar.

JSON-LD tampoco está unido a schema.org. La especificación permite que @context haga referencia a cualquier vocabulario publicado —sus propios ejemplos enlazan a contextos que no son de schema.org—, así que JSON-LD es la respuesta correcta a «¿qué formato?», mientras que schema.org es una respuesta, la habitual para el marcado de búsqueda y búsqueda con IA, a «¿qué vocabulario?». Una página podría usar válidamente JSON-LD con otro vocabulario; simplemente dejaría de ser marcado de schema.org.

JSON-LD frente a Microdata y RDFa

Hay tres formas de expresar datos estructurados y Google admite las tres:

La recomendación de Google es explícita, pero su alcance es limitado: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (traducción) «En general, Google recomienda usar JSON-LD para los datos estructurados si la configuración del sitio lo permite, porque es la solución más fácil de implementar y mantener a escala y resulta menos propensa a errores».

El matiz que normalmente omiten los competidores —y que merece la pena conservar— procede de la misma página de Google: “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (traducción) «Los tres formatos son igualmente válidos para Google siempre que el marcado sea válido y esté bien implementado conforme a la documentación de la función». Por tanto, la recomendación trata sobre facilidad de implementación y tasa de errores, no sobre velocidad de análisis ni ventaja de posicionamiento. Usar Microdata no es una penalización. JSON-LD gana en la práctica porque no enreda los datos estructurados con el marcado que un diseñador podría editar mañana.

La sintaxis: @context, @type, @id, propiedades y anidamiento

Aquí tienes un bloque Article anotado:

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>

• @context: establece el marco semántico (el vocabulario). Para el marcado SEO de schema.org normalmente es "https://schema.org", pero es una convención, no una regla: @context asigna términos a identificadores, y la especificación permite que apunte a otros vocabularios. Indica al analizador cómo interpretar cada nombre de propiedad que sigue. Esta es la parte que convierte los datos en datos enlazados.
• @type: declara la entidad: Article, Product, Organization, BreadcrumbList, etc. Se corresponde con un tipo de schema.org. Usa el tipo aplicable más específico: NewsArticle en lugar de Article si encaja.
• @id: una URI única que identifica el recurso. Es el mecanismo que permite referenciar una entidad desde otra (consulta @graph abajo) y conviene configurarlo en todo lo que vayas a referenciar, pero no es obligatorio universalmente. La especificación JSON-LD permite nodos en blanco no identificados, así que un JSON-LD válido puede omitir @id en entidades a las que nunca necesites referirte desde otro lugar.
• Propiedades: pares normales de clave/valor JSON que usan términos del vocabulario de @context.
• Anidamiento: las entidades hijas se expresan como objetos JSON anidados (el objeto author de arriba) o como matrices de objetos.

El patrón @graph (el enfoque escalable)

La mayoría de las páginas necesitan más de una entidad: una Organization, un WebSite, una BreadcrumbList y el propio Article o WebPage. El enfoque ingenuo son cuatro bloques <script> separados que repiten datos. Una alternativa escalable es un único bloque con @graph: una matriz de entidades referenciadas entre sí mediante @id. Ni la especificación JSON-LD ni Google exigen @graph como el patrón: es sintaxis para expresar un grafo, y existen otras disposiciones válidas (bloques tipados separados, objetos anidados sin un @graph de nivel superior y nodos en blanco sin @id), pero en un sitio con varias entidades referenciadas es el patrón que evita repetir los mismos datos de Organization o WebSite en cada página:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Define Organization una sola vez y apunta a ella con { "@id": "...#org" } en el resto de lugares, en vez de repetir el nombre, el logotipo y la URL. Así construyen su salida los principales plugins de Schema para CMS, y por eso existe @id. Bing argumenta lo mismo sobre el anidamiento de JSON-LD: “makes defining links and relationships between data and entities… easy because it supports nested data.” (traducción) «facilita definir enlaces y relaciones entre datos y entidades porque admite datos anidados».

Dónde colocarlo: <head> o <body>

Google confirma que ambos funcionan: “You can put the JSON-LD data in the <head> or the <body> of the page.” (traducción) «Puedes colocar los datos JSON-LD en el <head> o el <body> de la página». <head> es lo convencional, pero muchos plugins de CMS lo inyectan cerca del final de <body>, y no pasa nada. Bing coincide en que puede estar “in the header, body or foot of the page.” (traducción) «en la cabecera, el cuerpo o el pie de la página». No pierdas tiempo trasladando un bloque válido del body al head: no cambia nada. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: 2026-07-14 Google: Structured data introduction

Generar JSON-LD dinámicamente: la trampa de los rastreadores de IA

Puedes crear JSON-LD al vuelo con JavaScript, y Google documenta dos formas de hacerlo:

1. Google Tag Manager — una etiqueta HTML personalizada que contiene el JSON-LD y extrae valores de las variables de GTM. (Evita duplicar datos entre la página y la etiqueta.)
2. JavaScript personalizado — crea el elemento script mediante programación:

   const script = document.createElement('script');
   script.setAttribute('type', 'application/ld+json');
   script.textContent = structuredDataText;
   document.head.appendChild(script);

Esto funciona para Googlebot, porque Google renderiza la página: “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (traducción) «La Búsqueda de Google puede comprender y procesar los datos estructurados disponibles en el DOM cuando renderiza la página». Hasta aquí, todo bien.

Esta es la trampa que omiten la mayoría de las guías, explicada con cuidado. Varios rastreadores de IA —incluidos GPTBot y ClaudeBot, según pruebas habituales— no han ejecutado JavaScript. Si tu JSON-LD solo existe después de que se ejecute un script del lado del cliente, un rastreador que omite JS nunca lo verá: será invisible para ese bot aunque Googlebot lo lea correctamente, porque Google documenta que renderiza el DOM antes de buscar datos estructurados.

Hay dos matices honestos sobre ese comportamiento de los rastreadores de IA: la documentación propia de Google establece la parte de Googlebot; la parte de los rastreadores de IA procede de pruebas e informes sobre proveedores individuales, no de una especificación publicada por ninguno, así que depende del proveedor y de la fecha. La compatibilidad de un rastreador con JavaScript puede cambiar y no he verificado directamente a todos los proveedores. No trates «los rastreadores de IA omiten JS» como una regla universal sobre la que construir; tómalo como un motivo para comprobar el rastreador que realmente te importa (o usa el renderizado en servidor por defecto cuando no puedas comprobarlo). Si no está en el HTML renderizado por el servidor y no has confirmado que el rastreador ejecute JS, da por hecho que no puede verlo. Para la visibilidad en búsquedas con IA, renderiza JSON-LD en el servidor dentro del HTML estático salvo que hayas verificado lo contrario. (Este es el problema del renderizado de JavaScript visto desde los datos estructurados; consulta SEO para JavaScript.)

Hay un segundo matiz para el comercio electrónico: Google advierte que el marcado Product generado dinámicamente “can make Shopping crawls less frequent and less reliable,” (traducción) «puede hacer que los rastreos de Shopping sean menos frecuentes y menos fiables», lo que es un problema real para precios y disponibilidad que cambian rápidamente. Para productos, prefiere el renderizado en servidor independientemente de la IA.

Las políticas (ahora tienen consecuencias)

Las directrices de datos estructurados de Google son breves y fundamentales:

• “Don’t mark up content that is not visible to readers of the page.” (traducción) «No marques contenido que no sea visible para quienes leen la página».
• “Don’t mark up irrelevant or misleading content, such as fake reviews.” (traducción) «No marques contenido irrelevante o engañoso, como reseñas falsas».
• “Put the structured data on the page that it describes.” (traducción) «Coloca los datos estructurados en la página que describen».
• “Use the most specific applicable type and property names defined by schema.org.” (traducción) «Usa los nombres de tipo y propiedad aplicables más específicos definidos por schema.org».
• No bloquees tus páginas con datos estructurados a Googlebot mediante robots.txt o noindex.

La regla del contenido visible es la que debes interiorizar. El Schema que describe contenido no mostrado en la página siempre ha incumplido las reglas; la aplicación de la norma sobre Schema «invisible» se ha endurecido. Bing formula la advertencia sin rodeos: “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (traducción) «aunque el marcado no sea visible en la página, los motores de búsqueda lo leen, y añadir datos de spam al marcado puede perjudicar tu presencia».

Errores habituales de JSON-LD

• Marcado que no coincide con la página visible: el principal problema de políticas (una valoración en JSON-LD que ningún visitante ve).
• JSON mal formado: una coma final, una comilla sin escapar o comillas tipográficas (" en lugar de ") que rompen en silencio todo el bloque. JSON-LD es estricto.
• Nombres de propiedad incorrectos: inventar propiedades que no existen en schema.org o escribir mal las reales, de modo que el analizador las ignore.
• Un tipo genérico cuando existe uno específico: Thing o Article cuando correspondía Recipe o NewsArticle.
• Bloques Organization duplicados e incoherentes entre páginas, con nombres o logotipos en conflicto.
• Propiedades obligatorias ausentes para el resultado enriquecido al que aspiras (cada función enumera sus propios campos obligatorios).
• Marcado inyectado mediante JS que se da por visible para todos los rastreadores: Google lo renderiza, pero algunos rastreadores de IA no lo han hecho, y conviene verificarlo para cada rastreador (la trampa anterior).

Validar JSON-LD

Bajo «¿es válido mi JSON-LD?» se plantean cuatro preguntas distintas, y no son la misma: pasar una no implica pasar las otras:

• Prueba por URL, no por código pegado, en páginas renderizadas con JS. El modo de entrada de código del Rich Results Test no ejecuta tus scripts ni resuelve las referencias relativas como la prueba de una URL activa: no puede decirte cómo es un bloque inyectado del lado del cliente después del renderizado.
• Bing Webmaster Tools — Validador de marcado: Bing valida JSON-LD desde agosto de 2018.
• Ninguna de estas pruebas representa a los rastreadores que no renderizan JavaScript (consulta el matiz sobre rastreadores de IA): probar la URL renderizada confirma lo que ve Google, no lo que recibe un bot que omite JS.

¿Ayuda JSON-LD al SEO?

Establece las expectativas con honestidad:

• No es una señal de posicionamiento. John Mueller ha dicho que los datos estructurados no harán que un sitio se posicione mejor. Punto.
• Elegibilidad para resultados enriquecidos. Es lo que te hace apto para funciones mejoradas de las SERP (estrellas, precios, preguntas frecuentes y migas de pan): elegibilidad, no garantía.
• CTR, indirectamente. Los resultados con una apariencia más completa pueden conseguir más clics, que es la recompensa real para la mayoría de los sitios.
• Comprensión de entidades. Ayuda a los motores a conectar tu página con entidades conocidas y con el Knowledge Graph.
• Búsqueda con IA. Fabrice Canel (Bing) confirmó en 2025 que el marcado de Schema ayuda a los LLM de Microsoft a entender el contenido, pero ten en cuenta el matiz del estudio controlado de Schema Markup for AI: es infraestructura para desambiguar, no una palanca directa de citación.

Por tanto: implementa JSON-LD para la elegibilidad de resultados enriquecidos, la claridad de las entidades y la comprensión por parte de la IA/los LLM, no como un truco de posicionamiento.

Este artículo está en el hub de datos estructurados. Para el análisis específico de IA sobre el vocabulario de schema.org, consulta Schema Markup for AI; para la mecánica de renderizado tras la inyección dinámica, consulta SEO para JavaScript.

Resumen de IA

Una versión condensada de la pestaña Advanced:

• Qué es: JSON-LD (notación de objetos JavaScript para datos enlazados) es un formato de datos estructurados, no un vocabulario: un bloque <script type="application/ld+json">. En SEO suele combinarse con el vocabulario schema.org, pero @context puede apuntar a otro lugar. Es una recomendación del W3C desde 2014; se basa en JSON, pero @context es lo que lo convierte en datos enlazados, no en JSON normal.
• Por qué lo recomienda Google: es “the easiest solution… to implement and maintain at scale” (traducción) «la solución más fácil de implementar y mantener a escala» y nunca toca el HTML visible. Pero los tres formatos (JSON-LD, Microdata y RDFa) son igual de válidos cuando son correctos: la ventaja está en la tasa de errores, no en el análisis ni en el posicionamiento.
• Columna vertebral de la sintaxis: @context (vocabulario: schema.org para la mayoría del marcado SEO, aunque no es el único valor válido) · @type (entidad; usa el más específico) · @id (URI estable, opcional y útil para referencias cruzadas; los nodos en blanco no identificados también son JSON-LD válido) · propiedades (clave/valor) · anidamiento (objetos/matrices).
• Patrón @graph: un bloque y una matriz de entidades referenciadas mediante @id: define Organization una vez y referencia esa entidad en todas partes. Es un enfoque escalable para páginas con varias entidades, no una exigencia de la especificación ni de Google; existen otros diseños de grafo válidos.
• Ubicación: <head> o <body>: Google acepta ambos; no traslades bloques válidos.
• Inyección dinámica + matiz sobre la IA: Googlebot renderiza JS, por lo que el JSON-LD inyectado funciona para Google; varios rastreadores de IA —incluidos GPTBot y ClaudeBot, según las pruebas— no han ejecutado JS, pero esto depende del proveedor y de la fecha y no es una regla universal: comprueba cada rastreador y renderiza en el servidor lo que no puedas confirmar. El marcado Product dinámico también puede provocar rastreos de Shopping menos frecuentes.
• Políticas: marca solo contenido visible, haz que coincida con la página, usa el tipo más específico y no bloquees la página a los rastreadores. La aplicación de la norma sobre Schema «invisible» se ha endurecido.
• Errores habituales: marcado que no coincide o es invisible, JSON mal formado (comillas tipográficas y comas finales), nombres de propiedad incorrectos, tipos genéricos y propiedades obligatorias ausentes.
• Validación: cuatro comprobaciones distintas (sintaxis JSON, vocabulario schema.org, elegibilidad para resultados enriquecidos de Google y análisis activo en Search Console) que no se sustituyen entre sí: Rich Results Test (por URL, no con código pegado), Schema.org Validator, Mejoras de GSC y Bing Markup Validator.
• Efecto SEO: no es una señal de posicionamiento. Impulsa la elegibilidad para resultados enriquecidos, el CTR, la comprensión de entidades y la comprensión por los LLM (Canel, Bing, 2025).

Documentación oficial

Documentación primaria de los motores de búsqueda y de la especificación.

Google

• Introducción al funcionamiento del marcado de datos estructurados — la recomendación de JSON-LD, el matiz de que «los tres formatos son igualmente válidos» y la ubicación en <head>/<body>.
• Directrices generales de datos estructurados — las políticas: solo contenido visible, coincidencia con la página, tipo más específico y no bloquear a los rastreadores.
• Generar datos estructurados con JavaScript — los enfoques de inyección mediante GTM y JavaScript personalizado, además del matiz de los rastreos de Shopping para Product dinámico.
• Rich Results Test — valida la elegibilidad (prueba por URL en páginas renderizadas con JS).

Bing / Microsoft

• Marcar tu sitio con datos estructurados — Bing recomienda JSON-LD, admite que esté en la cabecera, el cuerpo o el pie y advierte sobre el marcado no válido.
• Introducción de la compatibilidad con JSON-LD en Bing Webmaster Tools (agosto de 2018) — cuándo añadió Bing la validación de JSON-LD.

Estándares / vocabulario

• JSON-LD 1.1 — recomendación del W3C — la propia especificación.
• json-ld.org — sitio del formato, con una definición en lenguaje sencillo.
• Introducción a Schema.org — el vocabulario que expresa JSON-LD y la regla del contenido visible.
• Schema.org Validator — valida el vocabulario.

Citas de la fuente

Declaraciones públicas de Google, Bing y la especificación. Cada enlace salta al pasaje citado de la página de origen donde se muestra el texto.

Documentación de Google: la recomendación y el matiz

• “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (traducción) «Google recomienda en general JSON-LD cuando la configuración del sitio lo permite, porque facilita una implementación mantenible a escala y reduce los errores». Ir a la cita
• “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (traducción) «Google acepta por igual los tres formatos si el marcado es válido y sigue correctamente la documentación de la función». Ir a la cita
• “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (traducción) «Al renderizar la página, la Búsqueda de Google puede interpretar y procesar los datos estructurados presentes en el DOM». Ir a la cita

Documentación de Google: las políticas

• “Don’t mark up content that is not visible to readers of the page.” (traducción) «No marques contenido que quienes visitan la página no puedan ver». Ir a la cita
• “Use the most specific applicable type and property names defined by schema.org.” (traducción) «Utiliza los nombres de tipo y propiedad más específicos que resulten aplicables en schema.org». Ir a la cita

John Mueller, Google: preferencia por JSON-LD y posicionamiento

• “We currently prefer JSON-LD markup. I think most of the new structured data that kind of come out are for JSON-LD first. So that is what we prefer.” (traducción) «Actualmente preferimos el marcado JSON-LD. Creo que la mayoría de los nuevos datos estructurados se publican primero para JSON-LD, así que ese es el formato que preferimos». — Google Webmaster Hangout, marzo de 2019. Cobertura
• Sobre el posicionamiento: “Structured data won’t make your site rank better.” (traducción) «Los datos estructurados no harán que tu sitio se posicione mejor». — 2025. (Reproducido a través de Search Engine Roundtable; confirma el texto exacto en la publicación original.) Cobertura

Bing / Microsoft

• JSON-LD “makes defining links and relationships between data and entities between the data present on your pages easy because it supports nested data.” (traducción) «permite definir con facilidad enlaces y relaciones entre los datos y las entidades presentes en tus páginas porque admite datos anidados». — Documentación de Bing Webmaster Tools. Ir a la cita
• “Webmasters should be very alert as to not put invalid and incorrect information in the markup, as even though the markup is not visible on your page, it is still read by the search engines.” (traducción) «Los webmasters deben tener mucho cuidado de no incluir información inválida o incorrecta en el marcado, porque los motores de búsqueda lo leen aunque no sea visible en la página». — Documentación de Bing Webmaster Tools. Ir a la cita

Fabrice Canel, Microsoft Bing: Schema y LLM

• En SMX Munich (marzo de 2025), Canel confirmó que el marcado de Schema ayuda a los modelos de lenguaje de Microsoft a entender el contenido web. (Parafraseado a partir de varias coberturas; confirma el texto exacto en la grabación de la conferencia o en LinkedIn antes de tratar una formulación concreta como definitiva.) Cobertura

La especificación: json-ld.org

• “JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.” (traducción) «JSON-LD es un formato ligero de datos enlazados, fácil de leer y escribir para las personas, basado en JSON y diseñado para favorecer la interoperabilidad de los datos a escala web». Ir a la cita

Sintaxis de JSON-LD: referencia rápida

The wrapper

<script type="application/ld+json">
{ ...your markup... }
</script>

Las palabras clave reservadas

Single entity

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Widget",
  "offers": { "@type": "Offer", "price": "19.99", "priceCurrency": "USD" }
}

Anidamiento: una entidad hija es un objeto anidado (o una matriz de objetos):

"author": { "@type": "Person", "name": "Patrick Stox" }

El patrón @graph: define una vez y referencia mediante @id:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://ex.com/#org", "name": "Ex Co" },
    { "@type": "WebSite", "publisher": { "@id": "https://ex.com/#org" } }
  ]
}

Propiedades habituales por tipo

• Article / BlogPosting: headline, author, datePublished, image, publisher

• Product: name, image, brand, offers (→ price, priceCurrency, availability)

• Organization: name, url, logo, sameAs (URI sociales/de Wikidata)

• BreadcrumbList: itemListElement → ListItem (position, name, item)

• FAQPage: mainEntity → Question → acceptedAnswer → Answer

• @context es "https://schema.org" para la mayoría del marcado SEO: es una convención, no un requisito de la especificación. Usa comillas rectas, nunca tipográficas.

• No pongas comas finales: JSON es estricto.

• Usa el @type más específico disponible.

• Marca solo lo que sea visible en la página.

• Colócalo en <head> o <body>: ambos son válidos.

• @id y @graph ayudan a referenciar y organizar entidades, pero no son obligatorios: los nodos en blanco y otros diseños también son válidos.

• Para rastreadores cuya ejecución de JavaScript no hayas verificado (varios rastreadores de IA, incluidos GPTBot y ClaudeBot, no lo han hecho en las pruebas), renderiza en el servidor.

• Valida por capas separadas: Rich Results Test (por URL) para la elegibilidad de Google + Schema.org Validator para el vocabulario; que una pase no significa que pase la otra.

Herramientas para validar JSON-LD

• Schema.org Validator: la comprobación más amplia del vocabulario. Un bloque puede pasar aquí y aun así fallar las reglas específicas de una función de Google.
• Google Rich Results Test: prueba la URL publicada cuando importa el renderizado, especialmente en marcado inyectado del lado del cliente. Esta prueba cubre los resultados enriquecidos compatibles con Google, no todos los tipos de schema.org.

Errores de JSON-LD que debes evitar

Marcar datos que los visitantes no pueden ver. Una valoración, precio, autor u otra afirmación del JSON-LD debe coincidir con la página visible. Los datos estructurados ocultos o engañosos pueden hacer que la página pierda la elegibilidad para resultados enriquecidos. Haz esto: genera el marcado a partir de la misma fuente de verdad que el contenido visible.

Tratar un JSON válido como un Schema válido. Un analizador puede aceptar un JSON perfectamente formado cuyas propiedades no existen en schema.org. Haz esto: ejecuta una comprobación del vocabulario JSON-LD y otra de los requisitos de Google para la función objetivo.

Usar comillas tipográficas o comas finales. JSON es estricto: las comillas tipográficas y una coma después de la última propiedad pueden invalidar todo el bloque. Haz esto: serializa los datos en lugar de ensamblar cadenas JSON a mano.

Elegir un tipo genérico cuando existe uno específico. El marcado Thing o un Article amplio pierde significado útil cuando la página es claramente una Recipe, un Product o un NewsArticle. Haz esto: utiliza el tipo de schema.org más específico que se aplique.

Duplicar entidades con detalles en conflicto. Varios bloques Organization con distintos nombres, logotipos o URL hacen que el grafo sea ambiguo. Haz esto: asigna a la entidad un único @id estable, defínela una vez y referencia ese identificador en el resto de lugares.

Suponer que la validez de schema.org garantiza un resultado enriquecido de Google. Google admite un subconjunto de tipos y añade sus propias propiedades obligatorias y políticas de contenido. Haz esto: valida primero el vocabulario y después prueba la elegibilidad para la función concreta de Google.

Inyectar JSON-LD mediante JavaScript y suponer que todos los rastreadores lo ven. Google puede renderizar el marcado del lado del cliente, pero los rastreadores de IA que omiten JS podrían no recibirlo. Haz esto: renderiza JSON-LD en el servidor cuando esos consumidores importen y prueba la URL activa, no solo el código pegado.

Demuestra que el despliegue de JSON-LD ha surtido efecto

Prueba 1: la página activa contiene JSON-LD válido y coincidente con la página

• Prueba que debes ejecutar: obtén la URL publicada con el Validador de datos estructurados y compara las entidades y valores detectados con la página visible.
• Resultado esperado: el JSON se analiza, todas las propiedades pertenecen a schema.org, las referencias @id se resuelven dentro del grafo cuando corresponde y afirmaciones como nombres, precios, valoraciones y fechas coinciden con lo que ven los usuarios.
• Interpretación de un fallo: los errores del analizador apuntan a JSON mal formado; las advertencias de vocabulario apuntan a propiedades mal escritas o no compatibles; los valores que no coinciden apuntan a que las fuentes separadas de contenido y Schema se han desincronizado.
• Ventana de seguimiento: inmediata después del despliegue y de limpiar la caché.
• Disparador de reversión: elimina o revierte el bloque nuevo si publica afirmaciones falsas sobre el contenido visible, rompe un grafo que antes era válido o no se puede analizar.

Prueba 2: la función de búsqueda objetivo reconoce el marcado renderizado

• Prueba que debes ejecutar: pasa la URL publicada por el Rich Results Test de Google y después usa el Comprobador de elegibilidad para resultados enriquecidos para revisar los campos obligatorios y recomendados que faltan por tipo.
• Resultado esperado: Google detecta el tipo compatible previsto sin errores críticos; cualquier bloque generado del lado del cliente aparece en el HTML renderizado.
• Interpretación de un fallo: aprobar Schema.org Validator y fallar en Google suele significar que el tipo no es una función compatible de Google, falta un campo obligatorio de Google, no se cumple una política de contenido o el renderizador nunca recibió el bloque.
• Ventana de seguimiento: inmediata en ambas pruebas; los cambios de Search Console esperan al siguiente rastreo.
• Disparador de reversión: revierte la inyección del lado del cliente si hace desaparecer datos estructurados que antes eran visibles del resultado renderizado, o elimina las afirmaciones de funciones no compatibles hasta que el contenido obligatorio esté presente.

Ponte a prueba: JSON-LD

Cinco preguntas rápidas sobre el formato JSON-LD. Elige una respuesta para cada una y comprueba el resultado después.

Recursos que merecen tu tiempo

Mis artículos relacionados

• Marcado de Schema: la forma fácil de conseguir resultados enriquecidos — la guía de Ahrefs sobre datos estructurados, tipos de Schema y resultados enriquecidos (la capa de funcionalidades que se coloca sobre JSON-LD).
• Guía para principiantes de SEO técnico — dónde encajan los datos estructurados en el panorama técnico más amplio.
• Problemas y buenas prácticas de SEO para JavaScript — el lado del renderizado: por qué el marcado inyectado por JS se comporta de forma distinta para los rastreadores que no ejecutan JavaScript.
• Conoce los nuevos rastreadores web — mi análisis de los rastreadores de IA de Cloudflare Radar (GPTBot, ClaudeBot y compañía): los bots que omiten tu Schema inyectado por JS.

Oficial

• Introducción al funcionamiento del marcado de datos estructurados de Google — la recomendación de JSON-LD y el matiz de que «los tres formatos» son válidos, directamente de la fuente.
• Generar datos estructurados con JavaScript de Google — los métodos de inyección dinámica y el matiz de Product.
• JSON-LD 1.1 — recomendación del W3C y json-ld.org — el propio formato.

De todo el sector

• Qué datos estructurados prefiere Google — Search Engine Journal — el artículo sobre el comentario de Mueller «we currently prefer JSON-LD».
• Microsoft Bing Copilot usa Schema para sus LLM — Search Engine Land — la confirmación de Fabrice Canel en SMX Munich 2025 de que Schema ayuda a los LLM de Bing.
• ¿Qué son los datos estructurados JSON-LD y por qué los necesitas? — Ignite Visibility — explicación sólida para principiantes.
• Guía de JSON-LD Schema para profesionales de SEO — SALT.agency — guía práctica de sintaxis e implementación dirigida a profesionales de SEO.

Registro de cambios