01Por qué el schema markup importa en GEO
Google usa el schema markup principalmente para habilitar rich results — las estrellas de review, los FAQs expandibles, las migas de pan en el SERP. Eso ya genera retorno. Pero en GEO el mecanismo es diferente: los LLMs usan el schema para verificar la identidad de la fuente antes de citarla.
Cuando ChatGPT, Perplexity o Claude rastrean una página, el JSON-LD les dice:
- Quién es la organización detrás del contenido (y si tiene presencia verificable en otras plataformas)
- Quién es el autor específico (y si ese autor tiene credenciales declaradas)
- De qué trata exactamente la página (y cuáles son sus keywords primarias)
- Cuándo fue publicado y actualizado (señal de frescura)
- Qué preguntas específicas responde (FAQPage = citabilidad directa)
Sin esos datos, el modelo tiene que inferirlos del texto plano. La inferencia introduce ruido. El schema elimina ese ruido y reduce la fricción de citabilidad.
Nota sobre E-E-A-T: El schema markup es también la forma más directa de declarar Experience, Expertise, Authoritativeness y Trustworthiness de forma parseable. Un Person con knowsAbout, hasCredential y sameAs a perfiles verificables vale más que diez párrafos de "somos expertos".
02Organization — el ancla del sitio
El tipo Organization es el punto de partida. Debe aparecer en todas las páginas del sitio con un @id consistente — ese ID es el ancla que conecta todos los demás schemas entre sí y forma el Knowledge Graph del sitio.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://tudominio.com/#organization",
"name": "Nombre de la Empresa",
"url": "https://tudominio.com/",
"logo": {
"@type": "ImageObject",
"url": "https://tudominio.com/logo.png",
"width": 807,
"height": 256
},
"description": "Descripción clara de qué hace la empresa y para quién.",
"email": "contacto@tudominio.com",
"telephone": "+52-XX XXXX XXXX",
"address": {
"@type": "PostalAddress",
"addressLocality": "Ciudad",
"addressRegion": "Estado",
"addressCountry": "MX"
},
"foundingDate": "2024",
"knowsAbout": [
"SEO técnico",
"GEO — Generative Engine Optimization",
"Optimización para motores de IA"
],
"sameAs": [
"https://www.instagram.com/tuhandle",
"https://www.youtube.com/@tucanal",
"https://www.linkedin.com/company/tuempresa"
]
}Campos críticos para GEO
@id — Usa la URL completa con el fragmento #organization. Este ID se referencia desde Article, Service y Person para construir el grafo de conocimiento del sitio.
knowsAbout — Declara explícitamente los temas de expertise. Los LLMs usan esto para asociar la entidad con dominios de conocimiento específicos.
sameAs — URLs a perfiles verificables en plataformas externas. Cada entrada es una señal de que la entidad existe fuera del propio sitio, lo cual es crítico para la verificabilidad.
Error frecuente
Usar el @id sin el fragmento URL (solo https://tudominio.com/ en lugar de https://tudominio.com/#organization) hace que el schema sea válido sintácticamente pero no construye un grafo enlazado — los otros tipos no pueden referenciarlo correctamente.
03Person — autoría verificable
Para GEO, el tipo Person para el autor es uno de los schemas más importantes. Los LLMs verifican la autoría como señal de E-E-A-T antes de decidir si citar un artículo. Un autor sin schema es un nombre en texto — un autor con schema es una entidad verificable.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://tudominio.com/nosotros/#fundadora",
"name": "Nombre Apellido",
"jobTitle": "Especialista SEO + GEO",
"description": "Breve bio de 1-2 oraciones con especialidad.",
"url": "https://tudominio.com/nosotros/",
"image": {
"@type": "ImageObject",
"url": "https://tudominio.com/team/foto.jpg",
"width": 400,
"height": 400
},
"worksFor": {
"@id": "https://tudominio.com/#organization"
},
"knowsAbout": [
"SEO técnico",
"GEO — Generative Engine Optimization",
"Schema markup",
"Optimización para LLMs",
"AEO — Answer Engine Optimization"
],
"sameAs": [
"https://www.linkedin.com/in/tuperfil",
"https://www.instagram.com/tuhandle",
"https://www.youtube.com/@tucanal"
]
}El campo worksFor referencia al @id del Organization. Eso crea el enlace entre la persona y la entidad — el modelo puede seguir ese enlace para verificar que el autor pertenece a la organización que publica el contenido.
Práctica recomendada
Define el Person schema en la página /nosotros/ y referéncialo desde cada artículo usando su @id en el campo "author" del Article schema — en lugar de redefinir el Person completo en cada página. Esto construye un grafo limpio y evita inconsistencias.
04Article — para cada pieza editorial
El tipo Article (o su subtipo TechArticle para contenido técnico) debe estar en cada artículo del blog o guía. Los campos más importantes para GEO son los que conectan el artículo con la entidad autora y declaran los temas cubiertos.
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://tudominio.com/recursos/nombre-articulo/#article",
"headline": "Título del artículo (idéntico al H1)",
"description": "Meta description del artículo.",
"image": "https://tudominio.com/og-image.jpg",
"datePublished": "2026-05-13",
"dateModified": "2026-05-13",
"author": {
"@id": "https://tudominio.com/nosotros/#fundadora"
},
"publisher": {
"@id": "https://tudominio.com/#organization"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://tudominio.com/recursos/nombre-articulo/"
},
"wordCount": 2400,
"inLanguage": "es-MX",
"keywords": [
"keyword principal",
"keyword secundaria",
"tema relacionado"
]
}Nota que author y publisher usan @id para referenciar entidades definidas en otros schemas — no repiten los datos. Esto es schema enlazado y es exactamente lo que los LLMs prefieren sobre datos planos repetidos.
| Campo | Para Google | Para LLMs (GEO) |
|---|---|---|
| headline | Rich result title | Verifica que el H1 coincide |
| datePublished | Freshness signal | Evalúa vigencia antes de citar |
| author @id | E-E-A-T signal | Verifica entidad autora vía grafo |
| keywords | Ignorado | Confirma relevancia temática |
| wordCount | Ignorado | Señal de profundidad de cobertura |
05FAQPage — el tipo más citado por los LLMs
El FAQPage es probablemente el schema con mayor impacto directo en GEO. Los LLMs están entrenados para responder preguntas — y el FAQPage es esencialmente una lista de preguntas con respuestas verificables y estructuradas. Es la señal de citabilidad más directa que existe en el vocabulario de schema.org.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿Cuál es la pregunta exacta que alguien escribiría?",
"acceptedAnswer": {
"@type": "Answer",
"text": "La respuesta completa y autónoma. No puede depender de
contexto anterior — debe tener sentido leída de forma aislada.
Entre 50 y 200 palabras es el rango óptimo para citabilidad."
}
},
{
"@type": "Question",
"name": "¿Segunda pregunta relacionada al tema?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Segunda respuesta completa y autónoma."
}
}
]
}Cómo escribir las respuestas para máxima citabilidad
La respuesta en el FAQPage no es la misma que aparece en el HTML visible. Puede ser más completa. Lo que importa:
- Autónoma — debe tener sentido sin leer el artículo completo
- Específica — no "depende de varios factores" sino la respuesta real
- Con dato o ejemplo — las respuestas con cifras o casos concretos se citan más
- Sin ambigüedad — evitar "puede ser" y "en algunos casos" sin concretar cuáles
Cuántas FAQs agregar: Entre 4 y 7 por página es el rango donde la cobertura temática es sólida sin saturar el schema. Menos de 3 no cubren suficientes variaciones de consulta. Más de 10 tienden a incluir preguntas genéricas que diluyen la señal temática.
06Service — para páginas de servicio
Cada página de servicio debería tener su propio Service schema. Esto es especialmente importante para GEO porque cuando alguien pregunta a un LLM "¿qué agencias ofrecen X servicio en Y ciudad?", el modelo busca exactamente estas declaraciones estructuradas para construir su respuesta.
{
"@context": "https://schema.org",
"@type": "Service",
"@id": "https://tudominio.com/servicios/nombre-servicio/#service",
"name": "Nombre del Servicio",
"serviceType": "Tipo de servicio (ej: GEO — Generative Engine Optimization)",
"description": "Descripción específica del servicio: qué incluye,
para quién y qué resultado produce.",
"provider": {
"@id": "https://tudominio.com/#organization"
},
"areaServed": {
"@type": "Country",
"name": "México"
},
"audience": {
"@type": "Audience",
"audienceType": "Agencias de marketing digital"
},
"availableChannel": {
"@type": "ServiceChannel",
"serviceUrl": "https://tudominio.com/contacto/"
},
"offers": {
"@type": "Offer",
"priceCurrency": "MXN",
"availability": "https://schema.org/InStock",
"seller": {
"@id": "https://tudominio.com/#organization"
}
}
}El campo areaServed es clave para búsquedas locales y regionales en LLMs. Si el servicio opera en toda Latinoamérica, se puede usar un array de países o la región "Latin America".
07HowTo — guías paso a paso
Cuando el contenido es una guía de procedimiento — "cómo hacer X" — el schema HowTo aumenta drásticamente la citabilidad. Los LLMs extraen los pasos para presentarlos en sus respuestas, con atribución a la fuente.
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "Cómo implementar schema markup para GEO",
"description": "Guía paso a paso para implementar structured data
en un sitio web con enfoque en citabilidad por LLMs.",
"totalTime": "PT2H",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Audita el schema existente",
"text": "Abre Google Rich Results Test y valida cada URL clave.
Identifica qué tipos están presentes y cuáles faltan."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Implementa Organization en todas las páginas",
"text": "Crea el bloque Organization con @id consistente.
Agrégalo en el de todas las plantillas del sitio."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Define Person para cada autor",
"text": "Crea el bloque Person en la página /nosotros/ o /autor/.
Incluye knowsAbout y sameAs con perfiles verificables."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Agrega Article a cada pieza editorial",
"text": "Referencia al Person y Organization usando @id.
Incluye keywords, wordCount y dateModified."
},
{
"@type": "HowToStep",
"position": 5,
"name": "Agrega FAQPage a artículos y páginas clave",
"text": "Escribe entre 4-7 preguntas con respuestas autónomas.
Cada respuesta debe tener sentido leída de forma aislada."
}
]
}08BreadcrumbList — navegación semántica
El BreadcrumbList es el schema más sencillo pero uno de los más consistentemente ignorados. Debe estar en todas las páginas que no son la home. Le dice al LLM cómo está organizado el sitio y dónde encaja esa página dentro de la arquitectura.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://tudominio.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Recursos",
"item": "https://tudominio.com/recursos/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Nombre del artículo actual",
"item": "https://tudominio.com/recursos/nombre-articulo/"
}
]
}El campo item en la última posición es opcional según la spec, pero recomendable para GEO porque provee la URL canónica de la página dentro del grafo de navegación.
09Dónde colocar el JSON-LD
La especificación de schema.org permite JSON-LD en el <head> o en el <body>. Google acepta ambos. Para GEO, el <head> es la ubicación recomendada porque los crawlers de LLMs tienden a parsear los metadatos antes del contenido visible.
JSON-LD en el <head>, antes del cierre </head>
Cada bloque de schema en un <script type="application/ld+json"> separado. No combinar múltiples tipos en un solo bloque — hace la depuración más difícil y algunos parsers tienen límites de tamaño por bloque.
Un solo bloque JSON-LD con múltiples tipos
Técnicamente válido, pero dificulta la validación, el mantenimiento y puede confundir a parsers que esperan un tipo por bloque. La separación es la práctica estándar en producción.
Microdata o RDFa en el HTML
Ambos formatos son válidos para schema.org pero requieren que la información esté en el HTML visible. JSON-LD mantiene la capa semántica separada del contenido editorial, lo que facilita la actualización independiente y reduce errores de sincronización.
10Cómo auditar tu schema actual
Antes de implementar, auditá lo que ya tienes. La mayoría de los sitios tienen schema parcial — Organization sin sameAs, Article sin autoría enlazada, o FAQPage con respuestas demasiado cortas para ser citables.
Proceso de auditoría en 4 pasos
Inventario con Google Rich Results Test
Pega cada URL clave (home, /servicios/, artículos principales, /nosotros/) en Rich Results Test. Descarga qué tipos detecta, qué campos tienen errores y qué campos faltan. Esto da el mapa de deuda técnica.
Verificar consistencia de @id
El @id del Organization debe ser idéntico en todas las páginas. Busca en el código fuente de 3 páginas distintas y confirma que el valor es exactamente el mismo. Una inconsistencia rompe el grafo.
Validar legibilidad semántica con un LLM
Copia el JSON-LD de una página y pregunta a ChatGPT: "Basándote solo en este schema, ¿qué es esta entidad, quién la creó y en qué temas es experta?" Si la respuesta es vaga o incorrecta, el schema tiene problemas semánticos aunque sea sintácticamente válido.
Audit de FAQPage: prueba de autonomía
Lee cada respuesta del FAQPage en aislamiento — sin el artículo, sin el contexto. ¿Tiene sentido completo? ¿Responde la pregunta de forma concreta? Si necesita el artículo para entenderse, la respuesta no es citable.
| Tipo de schema | ¿Obligatorio? | Impacto GEO | Impacto Google |
|---|---|---|---|
| Organization | SÍ | Muy alto — ancla del grafo | Medio — Knowledge Panel |
| Person (autor) | SÍ | Muy alto — E-E-A-T | Medio — E-E-A-T |
| Article | SÍ en blog | Alto — contexto editorial | Medio — rich results |
| FAQPage | Recomendado | Muy alto — citabilidad directa | Alto — FAQs en SERP |
| Service | SÍ en servicios | Alto — consultas comerciales | Bajo |
| HowTo | Si aplica | Alto — guías de procedimiento | Alto — rich results |
| BreadcrumbList | SÍ | Medio — arquitectura del sitio | Alto — breadcrumbs en SERP |
11Preguntas frecuentes
No garantiza, pero aumenta significativamente la probabilidad. El schema markup funciona como una señal de verificabilidad: le dice al LLM quién creó el contenido, cuándo, con qué autoridad y sobre qué tema específico. Sin schema, el modelo tiene que inferir esa información del texto plano, lo que introduce incertidumbre. Con schema correcto, el modelo puede confirmar esos datos. La diferencia práctica es que el contenido con schema pasa el umbral de citabilidad con mayor frecuencia.
Depende del plugin y de la configuración. La mayoría de los plugins generan Organization y Article básicos, pero omiten datos críticos para GEO como authorship verificable (Person con knowsAbout), Service types, o FAQPage estructurado. También es común que generen IDs de schema (@id) sin formato de URL completa, lo que reduce la verificabilidad entre grafos. La recomendación es auditar el JSON-LD generado en cada plantilla clave y complementar manualmente lo que falta.
Lo necesario para describir completamente ese contexto, sin duplicar. Una página de artículo típicamente necesita: Organization (sitio), Article (pieza), BreadcrumbList (navegación), Person (autor) y FAQPage si tiene preguntas frecuentes. Una página de servicio necesita: Organization, Service, BreadcrumbList. Agregar tipos que no corresponden al contenido real no ayuda y puede confundir al parser. Calidad sobre cantidad.
Sí, aunque de formas distintas. Para Google, el schema correcto habilita rich results (FAQs, breadcrumbs, site links, review stars) que aumentan el CTR orgánico. Para LLMs, el schema funciona como metadatos de confianza que ayudan al modelo a decidir si una fuente es citable. Son dos beneficios sobre la misma implementación técnica, lo que hace que el schema markup sea una de las inversiones técnicas con mayor retorno compuesto en 2026.
Tres herramientas: (1) Google Rich Results Test — valida que el JSON-LD sea sintácticamente correcto y elegible para rich results. (2) Schema.org Validator — verifica conformidad con la especificación de schema.org sin sesgos de Google. (3) Inspeccionando el DOM con DevTools → Sources y buscando los bloques script type="application/ld+json". Adicionalmente, puedes pegar el JSON-LD en un LLM y preguntarle qué infiere sobre la entidad — si la lectura es ambigua, el schema tiene problemas semánticos aunque sea sintácticamente válido.