¿Las IAs leen el JSON-LD? Lo probé con Gemini, OpenAI y DeepSeek

Se repite mucho que las IAs “leen” el JSON-LD y que por eso conviene llenar la página de datos estructurados. Otros dicen lo contrario. Como no encontré una prueba directa, hice una: planté datos que ningún modelo puede adivinar y medí cuáles herramientas los devuelven.

Este artículo es el resultado. Los números son míos, de una página de laboratorio y de dos rondas de pruebas. La evidencia externa aparece como contexto y está citada en las fuentes.

En corto

• El modelo sí entiende JSON-LD si le llega. DeepSeek con el HTML crudo acertó el dato escondido en el JSON-LD 10 de 10 veces.
• Casi nunca le llega. Gemini lo pasó 9 de 10 veces; OpenAI, 0 de 10. Los cinco extractores de HTML a texto que probé (trafilatura, readability, markdownify, BeautifulSoup y Jina Reader) lo descartaron; solo el HTML crudo lo conserva.
• La meta description tampoco llegó a ninguna herramienta alojada.
• Qué hacer: repite en texto visible todo lo que importe. Usa el JSON-LD como complemento, con coherencia exacta con lo que se ve.

Por qué importa el JSON-LD para SEO

JSON-LD es un bloque <script type="application/ld+json"> donde describes tu página con el vocabulario de schema.org: quién es el autor, qué organización publica, cuándo se modificó el artículo. Para Google es la forma recomendada de enviar datos estructurados, y es la base de varios resultados enriquecidos. Si quieres el repaso general, lo cubro en la sección de Schema de mi guía de SEO on page.

La pregunta nueva es otra: ¿sirve también para que un asistente de IA que navega la web entienda tu página? Ahí es donde las afirmaciones chocan, y ahí es donde quise medir.

Cómo hice la prueba

La idea es simple: poner valores “Carnada” sin sentido, que un modelo no puede conocer por entrenamiento ni adivinar, y ver si los devuelve de forma literal.

Creé una página de laboratorio con tres datos, cada uno en un sitio distinto. La página es noindex y está fuera del sitemap, para no esconder datos en JSON-LD en ninguna página indexable.

Tabla 1: Datos plantados en la página de laboratorio

Dato	Dónde vive	Valor
A (control)	Texto visible del cuerpo	VERDE-7342
B	Solo en el JSON-LD	ÁMBAR-9157
C	Meta description	MAGENTA-5086

Cómo leerla: la letra identifica el dato y la columna “Dónde vive” dice dónde está. A está en el texto que ve cualquier visitante, B solo dentro del JSON-LD y C en la meta description.

Este es el JSON-LD real de esa página. El dato B está en disambiguatingDescription:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Laboratorio de prueba de datos estructurados",
  "disambiguatingDescription": "Marcador interno de datos estructurados: ÁMBAR-9157.",
  "inLanguage": "es",
  "author": { "@type": "Person", "name": "Camilo Andrés Rodríguez" }
}

Reglas de la prueba:

• Prompt neutro e idéntico en todas las configuraciones. Se da la URL (o el contenido) y se hacen tres preguntas, A, B y C, sin decir dónde está cada dato. Se permite responder NOT_FOUND.
• Puntuación exacta: el valor esperado debe aparecer literal en el campo de la respuesta. No usé ningún modelo como juez.
• Modelos y herramientas: gemini-3.5-flash con url_context; OpenAI con web_search; y deepseek-flash, sin herramienta web, alimentado con el HTML crudo y con la salida de cada extractor.
• Diez ejecuciones por configuración en la página de laboratorio.

Antes hice una primera ronda, más corta, con un artículo real de este blog: 3 ejecuciones por configuración. Allí el dato A era la versión de Git citada en el texto (2.53.0) y el B era la fecha dateModified del JSON-LD.

Ronda 1: un artículo real

Tabla 2: Ronda 1, artículo real del blog, 3 ejecuciones por configuración

Configuración	A (visible)	B (solo JSON-LD)
Gemini url_context	0/3	0/3
GPT-5.5 web_search	3/3	0/3
DeepSeek, HTML crudo	3/3	3/3
DeepSeek, trafilatura, readability, markdownify, get_text o Jina	3/3	0/3

Cómo leerla: “3/3” significa que el modelo devolvió el valor exacto las 3 veces que lo intenté. A es el dato visible y B el que solo vive en el JSON-LD. B solo apareció con DeepSeek alimentado con el HTML crudo.

Dos cosas llamaron la atención. La primera: Gemini marcó la recuperación como exitosa, pero con solo unos 1.800 tokens de herramienta, y no devolvió ni el dato visible. No pude comprobar qué parte del texto recibió el modelo, así que no afirmo por qué falló.

La segunda: GPT-5.5 sin restricciones hizo muchas acciones (más de 20 en una ejecución de sondeo). Abrió la URL directa, pero también proxies y servicios de terceros como r.jina.ai, api.allorigins.win y api.codetabs.com, además de buscar y abrir llms.txt. No devolvió B, y no puedo decir por qué canal obtuvo A.

Ronda 2: la página de laboratorio

¿Sobrevive cada dato a los extractores?

Primero, sin modelos: ¿qué queda de A, B y C después de convertir el HTML a texto? Esto es determinista, una sola ejecución.

Tabla 3: Datos que sobreviven a cada extractor de HTML a texto

Extractor	A	B	C	Caracteres
HTML crudo	sí	sí	sí	96.838
trafilatura	sí	no	no	166
readability-lxml	no	no	no	237
markdownify	sí	no	no	7.938
BeautifulSoup get_text	sí	no	no	3.995
Jina Reader	no	no	no	5.243

Cómo leerla: “sí” significa que el valor sigue presente en el texto que deja el extractor y “no” que se perdió; “Caracteres” es cuánto texto conservó. B y C solo sobreviven en el HTML crudo.

Solo el HTML crudo conserva el JSON-LD. Cualquier conversión a texto lo tira, porque descarta los bloques <script>. Y la meta description también se pierde en todos. Además, readability descartó incluso el dato visible A con su heurística de contenido principal, y Jina Reader no lo traía.

¿Qué responden los modelos?

Tabla 4: Aciertos sobre 10 ejecuciones, página de laboratorio

Configuración	A	B	C	Página recuperada
Gemini url_context	9/10	9/10	0/10	9/10
OpenAI gpt-6-luna + web_search	10/10	0/10	0/10	10/10
DeepSeek, HTML crudo	10/10	10/10	10/10	n/a
DeepSeek, trafilatura	10/10	0/10	0/10	n/a
DeepSeek, markdownify	10/10	0/10	0/10	n/a
DeepSeek, get_text	10/10	0/10	0/10	n/a
DeepSeek, readability	0/10	0/10	0/10	n/a
DeepSeek, Jina Reader	0/10	0/10	0/10	n/a

Cómo leerla: “9/10” significa que el modelo devolvió el valor exacto en 9 de 10 intentos. A es el dato visible, B el del JSON-LD y C el de la meta description; “n/a” indica que no aplica, porque DeepSeek recibió el HTML directamente. B solo apareció con el HTML crudo y con Gemini url_context.

Lo que dicen los datos:

1. DeepSeek con HTML crudo lo acierta todo. Es el control: si el JSON-LD llega al modelo, el modelo lo usa. El problema no es la comprensión.
2. Gemini es la herramienta alojada que sí lo pasó. Acertó A y B en 9 de 10 ejecuciones. En la décima falló la recuperación de la URL (URL_RETRIEVAL_STATUS_ERROR) y respondió NOT_FOUND en los tres campos. La meta description (C) no la devolvió nunca.
3. OpenAI abrió la página directamente y no devolvió B. Las 10 ejecuciones dieron exactamente la misma respuesta: {"A":"VERDE-7342","B":"NOT_FOUND","C":"NOT_FOUND"}. Sin variación y sin inventar nada.
4. Los extractores dejan fuera B y C, así que cualquier sistema construido sobre ellos no verá tu JSON-LD.

Un hallazgo incómodo: respuestas inventadas

Cuando el dato no llegó, lo normal fue NOT_FOUND. Pero no siempre. Con markdownify, DeepSeek respondió una vez a B con el título de la página (“Laboratorio de datos estructurados”) y una vez a C con la URL. Con get_text, respondió B con el título en 4 de 10 ejecuciones, y C con la URL o con “jsonld-test” en 3 de 10. Ninguna de esas respuestas incorrectas afectó al dato A.

Son respuestas que toman texto visible como si fuera el dato pedido. Gemini no dio ninguna. Si construyes algo que consume extracciones de páginas, un campo ausente puede acabar rellenado con lo más cercano que haya, y no es fácil de detectar.

Cuánto contexto recibe cada herramienta

Los tokens de herramienta de Gemini dan una pista. En la página de laboratorio, las 9 ejecuciones correctas usaron entre 4.759 y 4.891 tokens; la que falló, 369. En la ronda 1, con el artículo largo, fueron solo unos 1.800, y Gemini no devolvió ni el dato visible.

En OpenAI, la diferencia fue de coste. En la primera ronda, GPT-5.5 sin restricciones consumía unos 85.000 tokens de entrada por ejecución. En la segunda restringí la búsqueda con allowed_domains al propio dominio, y gpt-6-luna gastó unos 7.300 por ejecución, con 2 o 3 acciones (siempre open_page y search).

Qué dice la evidencia externa

Mi prueba es pequeña. Esto es lo que encontré fuera, solo lo que pude verificar.

Vercel midió agentes sobre 25 sitios. En su guía Make your site readable by AI agents, hicieron 1.033 ejecuciones de agentes con ora.ai en 25 sitios, más 190 sondeos. Añadir JSON-LD, llms.txt, sitemaps o espejos en Markdown no cambió la recuperación cuando la respuesta ya estaba en el HTML renderizado en servidor. El estudio no midió ninguna ganancia de precisión por el JSON-LD. Recomiendan repetir los hechos críticos en texto visible, porque los conversores descartan los bloques de script. Otros hallazgos: una respuesta que solo existía con JavaScript no la encontró un cliente de fetch simple (0 de 5), y un 403 bloqueó a ambos clientes. Y cuando un fetch nombraba un formato, se eligió Markdown 2.259 de 2.361 veces (95,7 %).

Agentes con interfaces estructuradas frente a scraping. Steiner, Peeters y Bizer, en WWW 2026, probaron cuatro tiendas simuladas. Los agentes con RAG, MCP y NLWeb superaron a los que leían HTML: la F1 pasó de 0,67 a 0,75–0,77 y los tokens por tarea bajaron de unos 241.000 a 47.000–140.000. Es un resultado sobre interfaces estructuradas para agentes frente al scraping de HTML; no dice que meter JSON-LD en tu página dé esa mejora.

Un caso distinto: conjuntos de datos. Chen, Alrashed, Halevy y Noy (arXiv 2605.28787) estudian la búsqueda de conjuntos de datos sobre un corpus schema.org. El agente semántico logró una precisión global un 65,7 % mayor, aunque la línea base respondió un 40 % más de preguntas. Habla de datasets, no de páginas web.

Mi lectura, sin forzarla: lo estructurado ayuda cuando es una interfaz pensada para agentes o un corpus controlado. Un bloque JSON-LD en una página corriente depende de que la herramienta lo conserve, y lo que medí es que casi nunca lo hace.

Qué hacer con tu JSON-LD en 2026

Esto no es abandonar los datos estructurados. Google y otros sistemas los siguen usando, y sigue siendo la mejor forma de que tu sitio se describa a sí mismo de forma ordenada. Es ajustar la expectativa y el método.

1. Paridad entre texto visible y JSON-LD. Todo lo que importe (autor, fechas, qué es la página, la respuesta clave) debe estar también en el texto. El JSON-LD lo confirma; no es el único sitio donde vive el dato.
2. Renderiza en servidor. Que el JSON-LD esté en el HTML que devuelve el servidor, no inyectado solo por JavaScript en el cliente. Sobre esto hay más en la guía de SEO técnico (SSR frente a CSR). En WordPress, mira que tu plugin de SEO o tu tema lo impriman en el HTML y no lo añadan con JavaScript.
3. Usa @graph y enlaza las entidades con @id. Una organización, una persona y un artículo, conectados entre sí. Añade sameAs con enlaces a perfiles reales.
4. Cuida los sameAs. Una URL de compartir no identifica a nadie; el perfil sí.
5. Valida siempre. Un JSON-LD con un error de sintaxis se ignora sin avisar.

Una plantilla mínima

Artículo, persona y organización en un @graph. Cambia los valores por los tuyos:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://ejemplo.com/#organizacion",
      "name": "Nombre de tu organización",
      "url": "https://ejemplo.com/",
      "sameAs": ["https://www.linkedin.com/company/tu-empresa/"]
    },
    {
      "@type": "Person",
      "@id": "https://ejemplo.com/autor/tu-nombre/#persona",
      "name": "Tu Nombre",
      "url": "https://ejemplo.com/autor/tu-nombre/",
      "sameAs": ["https://www.linkedin.com/in/tu-perfil/"],
      "worksFor": { "@id": "https://ejemplo.com/#organizacion" }
    },
    {
      "@type": "Article",
      "@id": "https://ejemplo.com/blog/mi-articulo/#articulo",
      "headline": "Título visible del artículo",
      "datePublished": "2026-10-15",
      "dateModified": "2026-10-15",
      "inLanguage": "es",
      "author": { "@id": "https://ejemplo.com/autor/tu-nombre/#persona" },
      "publisher": { "@id": "https://ejemplo.com/#organizacion" },
      "mainEntityOfPage": "https://ejemplo.com/blog/mi-articulo/"
    }
  ]
}

Pega la plantilla dentro de <script type="application/ld+json">…</script>, en el <head> de la página o en la plantilla del sitio. En WordPress, un plugin de SEO suele generarla; si la pegas a mano, valídala con las herramientas del final.

Cada entidad lleva un @id único y las demás la referencian con ese @id, en lugar de repetir los datos.

Cómo validar JSON-LD

Dos herramientas gratuitas, con funciones distintas:

• Rich Results Test de Google: te dice si la página es elegible para resultados enriquecidos de Google.
• Schema Markup Validator: comprueba que el marcado sea válido según schema.org, aunque Google no lo use para un resultado enriquecido.

Una nota para no sobrevalorar el marcado: según la cobertura de jsonld.com, Google retiró el resultado enriquecido de FAQ en 2026. Un tipo de marcado puede dejar de tener efecto visible de un día para otro, y por eso conviene no depender de uno solo.

Para el contexto más amplio de cómo se posiciona hoy una página, mira los fundamentos de SEO en 2026 y por qué se dice que el SEO murió con la IA, que trata la parte de GEO.

Limitaciones

• Muestras pequeñas. 3 ejecuciones en la ronda 1 y 10 en la ronda 2, con un solo modelo por proveedor y una sola página por ronda. En DeepSeek las llamadas usaron temperatura 0, así que su estabilidad es esperable.
• Mido las APIs, no las aplicaciones. No verifiqué qué modelo ni qué extractor usan ChatGPT o Gemini en su interfaz de consumo.
• El dato C no es exclusivo de la meta description. El sitio lo copia a og:description y twitter:description, de modo que aparece 3 veces en el HTML.
• Gemini en la ronda 1. Con el artículo largo, el conteo de tokens de herramienta fue bajo y no pude ver qué recibió el modelo.
• GPT-5.5 en la ronda 1 pasó por proxies de terceros. Por eso, en la ronda 2 restringí el dominio, y no puedo afirmar por qué canal obtuvo el dato A la primera vez.
• Dato B de la página real. Era una fecha, que un modelo podría estimar; el formato con milisegundos y Z lo hace improbable.
• Jina Reader. Su salida para el laboratorio tenía otro título (“Laboratorio de prueba de datos estructurados”) que el de la página servida, y no contenía A. Puede ser una copia en caché de otra versión; no lo verifiqué.

Reproducibilidad

Escribí los scripts para repetirlo: uno que aplica cada extractor y comprueba de forma determinista qué datos sobreviven, y otro que lanza el mismo prompt a cada modelo, aplica la puntuación exacta y guarda las peticiones y respuestas crudas, sin claves, con un tope de peticiones por proveedor. Hoy no están publicados. Si quieres replicarlo, la receta de este artículo basta: tres datos canario, una página noindex, un prompt neutro y puntuación literal.

Conclusión

Los modelos entienden JSON-LD. Lo que falla es que a menudo no les llega: los extractores lo descartan, y de las dos herramientas alojadas que probé, una lo pasó y la otra no. Mi consejo es no tratar el JSON-LD como el único lugar de un dato importante. Escríbelo en el texto, mantén el marcado coherente, renderízalo en servidor y valídalo.

Si quieres que revise los datos estructurados de tu sitio, escríbeme a contact@camilordz.com.

Fuentes

• Vercel, Make your site readable by AI agents.
• Steiner, Peeters y Bizer, arXiv 2511.23281 (WWW 2026).
• Chen, Alrashed, Halevy y Noy, arXiv 2605.28787.
• jsonld.com, Google FAQ rich results deprecated.
• Google, Rich Results Test.
• Schema.org, Schema Markup Validator.
• Datos propios: dos rondas de pruebas con Gemini, OpenAI y DeepSeek sobre un artículo de este blog y una página de laboratorio (octubre de 2026).