Schema.org no nació pensando en IA generativa, pero hoy los motores de respuesta lo leen. Te mostramos cómo implementar Organization, FAQPage y BreadcrumbList — los tres schemas que más pesan al decidir a quién citar.
Por qué JSON-LD pesa más para la IA que para el SEO clásico en 2026
Hubo un cambio que sorprendió al gremio SEO en mayo de 2026 — Google retiró los rich results de FAQ. Según Search Engine Journal, Google "ya no muestra resultados enriquecidos de FAQ en la búsqueda" como resultado público. La lectura fácil es que el marcado dejó de servir; la lectura correcta es que su uso cambió.
El propio Google fue explícito en mantener la estructura. Según Google Search Central, el equipo "puede seguir usando los datos estructurados de FAQ para entender mejor las páginas" aunque ya no los renderice como rich result. La señal no murió — cambió de canal.
Ese canal son los motores de IA. Según Search Engine Land, "ChatGPT, Perplexity y Google AI Overviews dependen de datos estructurados para entender, verificar y citar contenido con precisión". Lo que perdió impacto en SEO clásico lo gana en visibilidad para LLMs.
La idea de fondo es que JSON-LD es un contrato legible por máquina sobre qué es cada cosa en tu página. Cuando un modelo arma una respuesta, el schema le da entidades nombradas, relaciones y atribución — exactamente lo que evita que te confunda con otra marca o que cite una versión imprecisa de tu posición.
El propio schema.org lo planteó así desde el inicio. Su vocabulario "ayuda a los buscadores y otras aplicaciones a entender el contenido" — y los LLMs son justamente esas "otras aplicaciones" a las que esta especificación dejó la puerta abierta hace más de una década. Esto se complementa con las señales de autoridad que un LLM puede leer y forma la base técnica de la visibilidad IA.
Suscríbete al newsletter de Madbotz para recibir el próximo análisis directo en tu correo. Sin spam, sin ruido — solo posts nuevos.
Organization: la identidad que desambigua a tu marca para los modelos
Organization es el schema más importante a nivel de sitio. Define quién eres: nombre canónico, URL, logo, perfiles oficiales. Cuando un motor de respuesta intenta atribuir una mención de "Madbotz" a una entidad concreta, este es el bloque que lee primero.
La definición oficial es clara sobre qué se puede declarar. Según schema.org, Organization soporta propiedades como name, url, logo, sameAs y address — entre muchas otras — para representar "una entidad con la que un individuo puede tener una relación".
Google formalizó el subset relevante para búsquedas en 2023. Según Google Search Central, el panel de organización ahora acepta "name, address, contact information y varios business identifiers" además del logo, convirtiendo Organization en la fuente canónica de identidad que el knowledge graph consume. El bloque de código pesa para ambos lados — search y respuestas IA.
La utilidad para LLMs no es teórica. Si tu sitio aparece sin Organization y un competidor con el mismo nombre lo tiene, el modelo va a elegir el que tiene contrato explícito. La desambiguación no es vanidad — es la diferencia entre que te citen a ti o a otro homónimo.
Así se ve un Organization mínimo y válido:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Madbotz",
"url": "https://www.madbotz.com",
"logo": "https://blog.madbotz.com/content/images/size/w400/2026/05/Logotipo---Madbotz---No-back.png",
"sameAs": [
"https://www.madbotz.com"
]
}
Una estructura similar es la que Madbotz inyecta en este post, su home y cada página de marca. Dato concreto: entre los 131 check items del analizador de Visibility, varios verifican exactamente este bloque y advierten cuando falta el logo, cuando el sameAs apunta a perfiles muertos o cuando el name cambia entre páginas.
FAQPage: el rich result murió, la señal sigue viva
La parte fea primero. Como ya señalamos, Google retiró el rich result de FAQ en mayo de 2026. Si publicaste FAQPage esperando esa caja expandible en SERP, esa caja ya no aparece — y no va a volver.
La parte útil sigue ahí. Según schema.org, FAQPage es "una WebPage que presenta una o más preguntas frecuentes con sus respuestas" — un contrato semántico que cualquier parser puede leer, no solo Google. ChatGPT, Perplexity y Bing Copilot siguen usándolo como fuente directa de Q&A.
La razón es operativa. Las respuestas Q&A son uno de los formatos más fáciles de extraer y citar para un LLM: pregunta clara, respuesta breve, entidad declarada. Según Joost de Valk, "FAQ structured data sigue siendo válida y útil — solo cambió quién la consume" y propone reciclar la sección dentro de un nuevo tipo FAQSection embebido en el Article.
La regla de implementación no cambió. Según Google Search Central, debes usar FAQPage solo cuando ofreces "respuestas oficiales únicas" — no contenido generado por usuarios — y la pregunta y respuesta deben aparecer visibles en la página, no solo en el markup. Esa regla la aplica también cualquier LLM cauteloso: si no encuentra el texto en el HTML, sospecha del schema.
Así se ve una FAQPage con dos preguntas:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"inLanguage": "es",
"mainEntity": [
{
"@type": "Question",
"name": "¿Los LLMs leen JSON-LD igual que Google?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Lo leen, pero lo usan distinto..."
}
},
{
"@type": "Question",
"name": "¿Sigue sirviendo FAQPage si Google quitó el rich result?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sí. Google retiró la caja expandible..."
}
}
]
}
Este post implementa FAQPage en su propio code injection — las cuatro preguntas que están más abajo viajan también como JSON-LD en el header. Practicamos lo que predicamos.
BreadcrumbList: jerarquía como contexto narrativo del LLM
BreadcrumbList es el schema más infravalorado de los tres. No cambia tu apariencia en SERP de forma dramática, pero le da al modelo algo que ningún otro bloque le da: dónde encaja la página dentro del sitio.
La spec lo describe como una cadena enlazada de páginas web. Según schema.org, cada ítem debe declarar position, name e item — la URL canónica de ese nivel — y la convención es orden ascendente desde la home hasta la página actual.
Google es estricto en las reglas. Según Google Search Central, "Google recomienda proveer breadcrumbs que representen el camino típico del usuario hasta una página, no que reflejen la estructura de la URL" — y un BreadcrumbList debe contener al menos dos ListItem para ser elegible.
Para un LLM, esto se traduce en contexto narrativo. Si una página es "Madbotz → Blog → Schema.org JSON-LD para IA", el modelo sabe que es un post de un blog corporativo, no una landing comercial ni una doc técnica. La diferencia importa cuando cita o resume: la jerarquía le dice qué tipo de contenido es antes de leer una sola palabra.
Así se ve el BreadcrumbList de este mismo post:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Madbotz", "item": "https://madbotz.com/"},
{"@type": "ListItem", "position": 2, "name": "Blog", "item": "https://blog.madbotz.com/"},
{"@type": "ListItem", "position": 3, "name": "Schema.org JSON-LD para IA", "item": "https://blog.madbotz.com/schema-jsonld-ia/"}
]
}
Tres niveles, todos con URL absoluta, name humano y position en orden ascendente. Lo mismo va en cada post del blog cambiando solo el último ListItem.
Cómo combinar los tres en un solo header
La pregunta práctica: ¿van en bloques separados o en uno solo? Las dos opciones son válidas y dependen de cómo prefieras debugar.
La opción simple es un script JSON-LD por schema. Es la más legible y la más fácil de validar pieza por pieza en el Rich Results Test. Es buen default cuando estás aprendiendo y quieres aislar errores.
La opción combinada es usar @graph con los tres @type dentro de un único script. Útil si tu CMS dispara cada schema desde plantillas separadas y quieres consolidarlos sin duplicar @context. La definición lo permite explícitamente — y es lo que este post usa en su code injection.
Esto coincide con el primer principio del framework Searchability — ser encontrable y legible para el bot — aplicado al nivel más técnico. Sin schema válido, las otras palancas pierden parte de su efecto.
| Schema | Qué describe | Dónde va | Qué señal le da al LLM |
|---|---|---|---|
| Organization | Identidad del negocio (marca, sitio, autor corporativo) | Header global del sitio o de cada página | Quién eres y cómo te llamas exactamente |
| FAQPage | Preguntas y respuestas oficiales de una página | Header de la página con FAQ visible | Bloques de Q&A listos para citar como respuesta directa |
| BreadcrumbList | Jerarquía de la página dentro del sitio | Header de cada página de contenido | Dónde encaja la página y qué tipo de contenido es |
Independientemente del formato, los tres deben validar limpio en el Rich Results Test y en validator.schema.org. No publiques un schema que tira warning — un LLM cauteloso lo va a ignorar antes que arriesgarse a citarlo mal.
Anti-patrones que rompen el contrato
Hay cuatro patrones que vemos operar y que rompen el contrato entre tu sitio y el modelo:
- Marcado oculto que no coincide con el contenido visible — el clásico "FAQ schema sin sección FAQ en la página".
- Logo que apunta a un archivo SVG inaccesible, a un CDN con CORS bloqueado o a un PNG de baja resolución.
- BreadcrumbList que invierte el orden o que duplica la home como primer y último ListItem.
- Organization con datos distintos entre páginas — name aquí, nombre legal allá, otro logo en la home.
El primero es el más peligroso. Si el LLM cruza el JSON-LD con el HTML renderizado y no encuentra la pregunta declarada, sospecha de todo el sitio. Una contradicción declarada es peor que no tener schema. Es el mismo patrón que vimos en el cargo cult de llms.txt — implementar señales sin verificar coincidencia con la realidad de la página.
La regla operativa es simple: si no aparece literal en pantalla, no va en el markup. Esto aplica desde FAQs hasta nombres de organización — el contrato solo es válido si lo cumples del lado público. Y si tu CMS regenera el schema desde plantillas, vale la pena revisar manualmente al menos los primeros posts.
Preguntas frecuentes
¿Los LLMs leen JSON-LD igual que Google?
Lo leen, pero lo usan distinto. Google lo cruza con su índice para decidir rich results y entidades del knowledge graph. Los LLMs lo extraen como contexto adicional a las entidades y a las respuestas Q&A que pueden citar. El formato JSON-LD es el que mejor parsean ambos.
¿Sigue sirviendo FAQPage si Google quitó el rich result?
Sí. Google retiró la caja expandible en SERP en mayo de 2026, pero confirmó que sigue usando el marcado para entender la página. ChatGPT, Perplexity y Bing Copilot siguen extrayendo FAQPage como fuente de respuestas directas, así que el valor se trasladó al canal de IA.
¿Puedo poner los tres schemas en una misma página?
Sí, y es lo recomendable. Puedes inyectar un script por schema o agrupar los tres en un único @graph compartiendo @context. Ambas opciones validan limpio. Este post combina los tres en un solo @graph en el code injection del header.
¿Organization va en cada página o solo en la home?
Va en todas las páginas, con el mismo bloque idéntico. La consistencia es lo que ayuda al modelo a unificar entidades. Cambiar el nombre, el logo o el sameAs entre páginas hace que el LLM dude de cuál es la versión canónica de tu marca.
Conclusión
Tres ideas para llevarte:
- Schema.org sigue siendo el contrato que los motores de IA leen — incluso cuando Google retira el rich result público de uno de ellos.
- Organization, FAQPage y BreadcrumbList cubren los tres niveles que un LLM necesita: identidad, respuesta directa y contexto del sitio.
- Implementa los tres en JSON-LD, ponlos en el code injection del header, valida con el Rich Results Test y revisa que el HTML coincida.
Si quieres saber qué le falta a tu sitio en estos tres frentes — y en los otros 128 check items del marco Searchability — el analizador de Visibility lo dice en menos de 60 segundos.
Ingresa una URL y obtén tu AI Visibility Score en solo unos minutos.