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 estudio cuasi-experimental más sólido 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.
• Otras tres piezas de evidencia, con métodos distintos, convergen: SALT.agency (107.352 URLs citadas), Fischman (efecto nulo al controlar por posición orgánica) y searchVIU (el JSON-LD no se recupera en fetch directo). Ninguna es un ensayo aleatorizado; todas apuntan al mismo sitio.
• El hallazgo más útil no es el efecto nulo, sino por qué aparece: el marcado viaja con el ranking, y al controlar por posición el efecto propio se evapora.
• 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 el estudio cuasi-experimental más sólido que hemos encontrado es el de Ahrefs.

Louise Linehan lo publicó 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 demás 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.

Toda la evidencia disponible, no solo la que nos conviene

Un artículo que se apoyara en un único estudio sería frágil: bastaría con encontrar otro que dijera lo contrario. Así que aquí está lo que hemos podido verificar en su fuente original, con sus diseños y sus defectos. Ninguno es un ensayo aleatorizado y ninguno, por sí solo, cierra la cuestión.

Fuente	Qué es	Qué encuentra
Google Search Central	Documentación oficial	No hace falta schema.org especial para AI Overviews ni AI Mode
Ahrefs (05-2026)	Cuasi-experimento, 1.885 páginas + ~4.000 controles	Sin efecto detectable en citación
Fischman (02-2026)	Observacional controlado por ranking, 730 citaciones	Efecto nulo al controlar por posición orgánica
SALT.agency (09-2025)	Observacional, 107.352 URLs citadas	Ningún schema más allá del estándar destaca
searchVIU (10-2025)	Laboratorio, n=1 página	El JSON-LD no se recupera en fetch directo

Las dos filas nuevas merecen su matiz, porque citarlas sin él sería repetir el error que critico.

SALT.agency, en un análisis firmado por Dan Taylor el 16 de septiembre de 2025, revisó 107.352 URLs citadas en AI Mode: Organization aparecía en el 82 %, WebPage/Article en el 76 %, BreadcrumbList en el 59 %. Su conclusión es que el schema es «un factor de higiene, no un diferenciador». El límite es de diseño y es serio: solo mira páginas ya citadas, sin grupo de control de páginas no citadas. Con esa muestra no se puede medir ninguna ventaja — solo constatar que, entre las citadas, ningún marcado exótico está sobrerrepresentado. Tampoco publica dataset ni fechas de recogida.

Kurt Fischman publicó en febrero de 2026 un estudio sobre 730 citaciones, 75 consultas comerciales y 1.006 páginas únicas en ChatGPT y Gemini. Es un preprint sin revisión por pares y su autor dirige una agencia de GEO, así que tiene interés comercial en el tema: conviene saberlo antes de darle peso. Dicho eso, su aportación es la más interesante de todas, porque explica el resultado raro de Ahrefs. Agrupando sin más, Fischman encuentra que el schema correlaciona negativamente con la citación. Y en vez de titular con ello, lo diagnostica como artefacto: el ranking de Google sobrerrepresenta páginas con marcado en el top 10, así que la comparación ingenua está sesgada. Al controlar por posición orgánica, el efecto desaparece —presencia de schema, odds ratio 0,678 con p = 0,296— y la prevalencia entre páginas citadas y no citadas resulta indistinguible: 43,1 % frente a 44,8 %. Su predictor dominante no es el marcado, es la posición en Google.

Ese es probablemente el mejor argumento de todo el artículo, y no es mío: el −4,6 % de Ahrefs y el efecto negativo de Fischman apuntan a lo mismo, y no es que el schema perjudique. Es que el marcado viaja acompañado de otras variables, y en cuanto se controla la que manda —el ranking— el efecto propio se evapora.

Fischman declara además una excepción que sería deshonesto omitir: el schema de Product/Review con atributos realmente poblados (precio, valoración agregada, especificaciones) sí se asocia a mayor tasa de citación, 61,7 % frente a 41,6 % con p = 0,012, y el beneficio es mayor en dominios de baja autoridad. Encaja exactamente con lo que decía Mueller sobre el shopping: hay datos que una página de texto no transmite con fidelidad, y ahí el marcado hace un trabajo que la prosa no puede hacer.

La conclusión que soportan estas cinco piezas juntas no es «el schema no sirve». Es más incómoda y más útil: métodos distintos, con muestras y sesgos distintos, no han producido hasta hoy evidencia causal convincente de que añadir JSON-LD aumente las citaciones en IA. Quien afirme lo contrario tiene la carga de la prueba.

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. La cronología completa, según el propio registro de cambios de Google, tiene tres hitos y conviene no confundirlos. El 8 de agosto de 2023, Google anunció que reducía la visibilidad de estos resultados y los limitaba a webs gubernamentales y de salud reconocidas; para todo el resto dejaron de mostrarse. El 8 de mayo de 2026 añadió el aviso de deprecación, indicando que la función dejaría de aparecer en Google Search a partir del 7 de mayo de 2026. Y el 15 de junio de 2026 retiró la documentación, porque el resultado enriquecido ya no se muestra. 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 ayuda a Google a distinguirnos de otras organizaciones y puede influir en la información que muestra sobre nosotros, incluido el logo y el knowledge panel. No garantiza un knowledge panel, y tampoco es un requisito para tenerlo —Google construye esas fichas a partir de muchas más señales que tu marcado—, pero es la forma más directa de decirle quién eres sin que tenga que deducirlo.

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. El <article> de este 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.

Y si no puedes describir la realidad, no emitas el campo. Esta regla nos ha costado un cambio de código el mismo día de publicar. Hasta hoy, nuestro BlogPosting emitía articleBody con los primeros 1.500 caracteres del artículo: una decisión de rendimiento razonable —embeber el post íntegro inflaba el HTML servido decenas de kilobytes— pero semánticamente falsa, porque schema.org define articleBody como the actual body of the article, el cuerpo real y no un fragmento. Estábamos declarando como cuerpo algo que no lo era, en un artículo que denuncia justamente eso. Lo hemos retirado: description ya lleva la entradilla y wordCount sí mide el artículo completo, así que no se pierde ninguna señal legítima. Entre un campo truncado y ningún campo, la respuesta correcta es ninguno.

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 y que la página es elegible para mostrarse con snippet. Es el prerrequisito técnico explícito que Google documenta para AI Overviews y AI Mode. 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.