Schema JSON-LD y la IA: Google dice por escrito que no hace falta (y aun así lo implementamos entero)

Resumen ejecutivo

• Google afirma por escrito y en documentación oficial que no hace falta ningún schema.org especial para aparecer en AI Overviews ni en AI Mode. El requisito es estar indexado y ser elegible con snippet: «no additional technical requirements».
• El único experimento cuasi-controlado publicado —Ahrefs, mayo de 2026, 1.885 páginas que añadieron marcado frente a ~4.000 de control— no encontró aumento de citaciones: −4,6 % en AI Overviews, +2,4 % en AI Mode, +2,2 % en ChatGPT.
• Un test de laboratorio de searchVIU sugiere que, al abrir una URL directamente, los LLMs no leen el JSON-LD en absoluto: extraen solo HTML visible.
• Lo que sí está documentado: rich results en Google Search y desambiguación de entidad vía Organization. Eso basta para justificar el marcado, y es un argumento distinto del que vende la industria.
• Nuestro sitio emite unos 30 tipos de schema conectados por @id en un grafo real. Enseñamos la implementación entera y explicamos por qué la mantenemos sabiendo lo que dice esta evidencia.

La promesa que se está vendiendo

Busca «schema para GEO» y encontrarás la misma tesis repetida en decenas de artículos: los modelos de lenguaje necesitan datos estructurados para entenderte, el JSON-LD es el idioma que hablan las máquinas, y marcar tu web es la vía rápida a que ChatGPT te cite.

Es una tesis atractiva porque encaja con una intuición correcta —los datos estructurados son, en efecto, más fáciles de procesar que la prosa— y porque produce un entregable verificable en dos segundos. Un consultor puede abrir tu web, ver que no tienes Organization, y venderte la corrección. Es el mismo mecanismo comercial que analizábamos en el artículo sobre para qué sirve de verdad el llms.txt: lo que se vende bien no es lo que funciona, es lo que se comprueba de un vistazo.

El problema es que, a diferencia del llms.txt, aquí sí hay algo que funciona. Solo que no es lo que te están vendiendo. Vamos por partes, empezando por la fuente primaria que casi nadie cita.

Lo que Google dice por escrito

Esta parte suele contarse de oídas. Conviene ponerla con su procedencia, porque no es una declaración informal en un podcast: es documentación oficial, con fecha de actualización visible.

En la guía AI features and your website de Search Central (actualizada el 10 de diciembre de 2025), Google escribe:

«You don't need to create new machine readable files, AI text files, or markup to appear in these features.»

Y, dos párrafos más abajo, sin margen interpretativo:

«There's also no special schema.org structured data that you need to add.»

Sobre el requisito real para aparecer como enlace de apoyo en AI Overviews o AI Mode, la misma guía es igual de explícita: la página tiene que estar indexada y ser elegible para mostrarse en Google Search con un snippet. «There are no additional technical requirements.»

La guía de optimización para IA, actualizada el 10 de julio de 2026, lo repite en otras palabras: los datos estructurados no son necesarios para la búsqueda generativa y no hay marcado especial que añadir. Eso sí, recomienda seguir usándolos como parte de la estrategia SEO general —porque cualifican páginas para rich results en Search—, que es exactamente la distinción que sostiene este artículo.

Hay un matiz que merece rescatarse, y viene de John Mueller, respondiendo en Reddit a si un marcado extenso ayuda a los LLMs con las entidades. Su respuesta empieza con un «yes, no, and it depends» y separa tres casos: hay funciones que dependen del marcado —precio, envío y disponibilidad en shopping son, en sus palabras, prácticamente imposibles de leer con fidelidad desde una página de texto—, hay casos donde el marcado solo enriquece la comprensión, y hay pensamiento mágico. Su ejemplo del tercer grupo es demoledor: tu «mejor comparador de seguros» no va a posicionar mejor por añadirle marcado de seguros.

Mueller aclaró explícitamente que aquello no era guía oficial, sino su punto de vista. Lo cito como lo que es: la formulación más útil que existe del problema, hecha por alguien de Google a título personal.

El experimento que la industria no cita

La documentación establece qué dice Google. No establece qué ocurre en la práctica. Para eso hace falta medir, y hay exactamente un intento serio publicado.

Louise Linehan publicó en Ahrefs, el 11 de mayo de 2026, un estudio que rastreó 1.885 páginas que añadieron JSON-LD entre agosto de 2025 y marzo de 2026, contrastándolas con unas 4.000 páginas de control emparejadas. El diseño es de diferencias-en-diferencias, que es lo correcto para este tipo de pregunta: no compara páginas con y sin schema (eso solo mediría que las webs cuidadas hacen muchas cosas bien a la vez), sino el cambio en las páginas tratadas frente al cambio en las de control durante la misma ventana.

Los resultados, en citaciones tras añadir el marcado:

• Google AI Overviews: −4,6 % (estadísticamente significativo)
• Google AI Mode: +2,4 % (indistinguible de cero)
• ChatGPT: +2,2 % (indistinguible de cero)

Antes de que nadie construya un titular con el −4,6 %: ese número no demuestra que el schema perjudique. Es un efecto pequeño, sin mecanismo explicado, y la propia autora lo deja sin explicar. La lectura honesta de las tres cifras juntas es «no se detecta efecto», no «se detecta efecto negativo».

El estudio incluye además el dato descriptivo que la industria sí cita, casi siempre mal: el 53 % de las páginas citadas por IA tiene schema. Es una correlación, y una bastante insulsa —las páginas con marcado son también las que tienen equipo técnico, contenido cuidado y autoridad previa—. Presentarla como prueba de causalidad es el error estadístico más común de todo el sector.

Y ahora la parte que hay que leer con la misma atención que los resultados: los límites que declara la propia autora. El estudio solo incluye páginas que ya tenían más de cien citaciones a comienzos de 2025. Es decir, páginas que la IA ya veía. No dice absolutamente nada sobre si el marcado ayuda a una página desconocida a entrar por primera vez en el conjunto de consideración. Tampoco separa el schema de otros cambios simultáneos, ni distingue por tipo de marcado, ni mira más allá de treinta días.

Ese hueco es real y nadie lo ha testeado. Quien afirme que el schema no sirve para nada en IA está extrapolando tanto como quien afirma que te hace citar.

¿Leen siquiera el JSON-LD?

Hay una pregunta más básica y más incómoda: cuando un modelo abre tu URL, ¿mira el marcado?

Michael, de searchVIU, publicó un test el 2 de diciembre de 2025 con datos recogidos el 30 de octubre. Montó una página con ocho productos ficticios y distribuyó los precios en capas distintas: HTML visible, contenido renderizado por JavaScript, JSON-LD, microdatos ocultos, microdatos visibles y RDFa. Después preguntó repetidamente a ChatGPT, Claude, Gemini, Perplexity y Google AI Mode qué productos había y a qué precio.

El resultado central, en sus palabras: «JSON-LD is ignored».

Ningún sistema extrajo un solo precio del JSON-LD, de los microdatos ocultos ni de la RDFa oculta. Cero de ocho, en todos los casos. Todo lo que recuperaron vino del HTML visible —o, en el caso de Gemini, de JavaScript renderizado—. Las tasas de recuperación total fueron: Gemini 50 %, ChatGPT 37,5 %, Google AI Mode 25 %, Perplexity 12,5 % y Claude 0 %.

Los límites, otra vez, porque un dato sin límites es propaganda. Es una sola página de test con productos inventados: ilustrativo, no estadístico. Y cubre el fetch directo, que es solo una de las vías por las que un modelo llega a tu contenido; el marcado podría seguir usándose durante la indexación clásica o por sistemas integrados con buscador como AI Overviews. El propio autor lo señala.

Aun así, el hallazgo encaja con todo lo anterior y con algo que ya sabíamos: lo que se extrae es lo que se lee, y lo que se lee es el texto visible. Es el mismo principio de extractibilidad que rige el AEO y que explicábamos en la guía de GEO: si un pasaje no se sostiene solo en la página, no sirve. El schema no rescata un contenido que no dice claramente lo que afirma decir.

Lo que hay que dejar de contar como entregable

Dos tipos de marcado siguen apareciendo en propuestas comerciales como si tuvieran efecto visual. No lo tienen.

FAQPage. El 8 de agosto de 2023, Google anunció que reducía la visibilidad de los rich results de FAQ y los limitaba a webs gubernamentales y de salud reconocidas y autorizadas. Para todo el resto, dejaron de mostrarse. Posteriormente la función se retiró por completo y su documentación desapareció. Sigue siendo un tipo válido de schema.org y puede quedarse en la página sin causar ningún problema.

HowTo. El rich result se restringió a escritorio en el mismo anuncio de agosto de 2023 y el 14 de septiembre de 2023 Google retiró la documentación, indicando que ya no se muestra en resultados de búsqueda.

Aquí conviene ser preciso con el propio discurso, porque nosotros seguimos emitiendo ambos. Que un rich result desaparezca no invalida el vocabulario: FAQPage y HowTo siguen siendo schema.org correcto y describen fielmente el contenido de esas páginas. Lo que es indefendible no es mantenerlos, es facturarlos como palanca de visibilidad. Si aparecen en un informe mensual bajo el epígrafe «acciones de GEO ejecutadas», alguien está inflando el trabajo.

Y hay un tercer error, este sí sancionable: marcar lo que no está visible en la página. Las políticas de spam de datos estructurados de Google son antiguas y claras — el marcado debe representar contenido que el usuario ve. Marcar productos inexistentes, valoraciones que nadie dejó o FAQs que no aparecen en pantalla es motivo de acción manual, y lo verás en Search Console como «Structured data issue». Es el único apartado de este artículo donde el schema puede hacerte daño de verdad.

El caso del sameAs, o cómo describir no es crear

Merece párrafo propio porque es la pieza donde más se confunde el razonamiento plausible con la evidencia.

La narrativa dice: si declaras sameAs apuntando a tu LinkedIn, tu Crunchbase y tu Wikidata, consolidas tu marca como entidad y los modelos empiezan a reconocerte. Es razonable desde primeros principios. Y no tiene respaldo público.

Google documenta sameAs de forma notablemente escueta: la URL de una página en otro sitio con información adicional sobre tu organización, por ejemplo tu perfil en una red social o un sitio de reseñas. Puedes dar varias. Eso es todo. No dice que alimente el Knowledge Graph, ni que ayude a los modelos. Lo que sí documenta es que el marcado de Organization sirve para desambiguar tu organización de otras y para decidir qué logo e información aparecen en el knowledge panel — que es un beneficio real, concreto y suficiente.

Todo el material que sostiene la cadena sameAs → reconocimiento por LLM procede de blogs de agencia que se citan entre sí sin aportar una sola medición.

La forma correcta de entenderlo es esta: el sameAs describe una realidad externa; no la crea. Declarar que tienes un perfil en un sitio de autoridad no te da autoridad. Lo que mueve la aguja es existir, de forma consistente y verificable, en fuentes terceras que los modelos ya consideran fiables. El marcado hace ese hecho más fácil de conectar; no lo sustituye. Es la tesis que desarrollábamos en del backlink al consenso y en el artículo sobre convertir tu marca en entidad, y aquí encaja como una pieza más: la consistencia es el activo, el marcado es la señalización.

Entonces, ¿por qué implementamos treinta tipos de schema?

Aquí es donde tendríamos que explicar por qué, sabiendo todo lo anterior, nuestro propio sitio emite alrededor de treinta tipos distintos de schema conectados entre sí. Puedes abrir el código fuente de cualquier página y verlo ahora mismo.

Las razones son tres, y ninguna es que esperemos más citaciones.

Una: los rich results son reales y están documentados. La galería oficial de Google enumera los tipos que producen resultados enriquecidos —Article, Breadcrumb, Organization, Product, Event, Profile page, Speakable, Local business y una veintena más— y esa es una función de Google Search con efecto visible en la SERP, no una hipótesis sobre modelos generativos. BreadcrumbList cambia cómo se ve nuestra URL en los resultados. Eso es todo el argumento que hace falta.

Dos: la desambiguación de entidad está documentada. Organization con su dirección, su fundador y sus perfiles es la vía por la que Google decide qué mostrar de nosotros. No garantiza un knowledge panel; es el requisito previo para poder tener uno.

Tres, y es la razón que hace que la ecuación salga: no nos cuesta mantenerlo. Todo el marcado se genera a partir de las mismas constantes canónicas que renderizan la web. Cuando damos de alta un servicio, cambiamos un precio o publicamos este mismo artículo, el JSON-LD se actualiza solo en el siguiente despliegue. No hay un fichero paralelo que alguien tenga que acordarse de tocar.

Ese último punto no es un detalle de implementación. Es la diferencia entre que el schema sea un activo o un pasivo, y es la única parte de este artículo que cambiará tu resultado de verdad.

Cómo lo hemos construido, en concreto

Si vas a implementar marcado, esto es lo que nos parece que separa hacerlo bien de rellenar un checklist. Todo lo que sigue está en nuestro código.

Un grafo, no islas sueltas. El error más común es emitir bloques de schema que no se conocen entre sí: un Organization aquí, un Person allá, un BlogPosting más abajo. Cada uno es una entidad huérfana. Nosotros definimos cuatro @id estables —#organization, #website, #person-federico-noya y el catálogo de servicios— y todo lo demás los referencia. La Organization declara a su fundador por @id; la Person declara worksFor de vuelta. Antes solo existía la arista unidireccional, y Google y los modelos veían dos entidades que apenas se tocaban.

Híbrido @id + campos inline. Cuando el BlogPosting declara su autor, lo hace con el @id global y además con name, url, jobTitle y sameAs repetidos. El @id resuelve el grafo para quien lo sabe resolver; los campos inline funcionan para el parser que no sigue referencias. Cuesta unos bytes y elimina una suposición sobre el consumidor.

Un @id por entidad, no por página. Nuestros cuatro pilares de servicio compartían en su día el mismo identificador. Eso colapsaba cuatro entidades distintas en un único documento y hacía imposible que un sistema RAG las separase. Cada servicio tiene ahora el suyo.

No declares funciones que no existen. Nuestro WebSite no emite SearchAction, porque el blog no implementa búsqueda por parámetro. Declararla era describir una funcionalidad inexistente — y Google retiró el sitelinks searchbox en 2024, así que ni siquiera había premio. El principio general: el marcado que no corresponde a la realidad de la página es, en el mejor caso, ruido.

speakable solo donde es válido y solo si el selector existe. Es válido en Article y WebPage, no en HowTo ni en DefinedTerm. Y los selectores CSS que declara tienen que existir en el DOM renderizado: al reescribir un H1 retiramos un selector que había quedado apuntando a nada. Un speakable que señala una clase inexistente es dato muerto que además acopla tu marcado a tus nombres de clase — un renombrado silencioso lo rompe.

Fechas que signifiquen algo. La dateModified del perfil de autor es una constante que actualizamos a mano cuando cambia la biografía, no un new Date() que se recalcula en cada build. Una frescura sintética que cambia cada vez que despliegas es exactamente el tipo de señal que un buscador aprende a descontar.

Cierra el bucle con el HTML. Es el punto que conecta con la evidencia de searchVIU. Si los modelos extraen lo visible, el marcado tiene que coincidir con lo visible, no compensarlo. Nuestro articleBody lleva un extracto acotado en vez del post íntegro —el cuerpo completo inflaba el HTML servido decenas de kilobytes por artículo sin ganancia demostrable— y el <article> del post excluye a propósito los artículos relacionados y el CTA, para que la unidad citable sea el contenido y no el ruido de plantilla.

Qué hacer el lunes

Si tuvieras que quedarte con una decisión práctica de todo esto, sería esta secuencia, en este orden:

1. Comprueba que estás indexado. Es el requisito que Google documenta para AI Overviews, y el único. Si tienes un problema de indexación o un bloqueo a los rastreadores de IA en tu robots.txt o tu WAF, ninguna cantidad de marcado lo compensa. Lo desarrollamos en la auditoría técnica de robots.txt y OAI-SearchBot.
2. Implementa Organization bien, una vez. Nombre, logo, dirección, fundador, perfiles reales. Es la base de tu entidad y está documentada por Google.
3. Implementa los tipos que producen rich results para tu caso: Article, BreadcrumbList, Product, Event, lo que aplique. Con efecto medible en Search, no en promesas.
4. Genera todo desde tu fuente de verdad. Si el marcado no deriva de los mismos datos que renderizan la página, se desincronizará. Es cuestión de meses.
5. Y después olvídate del schema y dedica el esfuerzo a lo que sí predice la citación: contenido extractable, E-E-A-T verificable y presencia consistente en fuentes terceras.

El resumen honesto cabe en una frase. El marcado estructurado es buena ingeniería web con beneficios documentados en Google Search; no es una palanca de visibilidad en IA, y quien te lo venda como tal está facturando una hipótesis no verificada. La distinción no es un matiz académico: determina en qué gastas los próximos tres meses.