Organization
La entidad raíz: quién eres. name, url, logo, foundingDate, sameAs (perfiles oficiales) y knowsAbout (temas de los que eres referente). Es la base de tu identidad para los motores.
aprende · la capa técnica
Schema, AEO, GEO y SEO en 2026
El schema markup —los datos estructurados en JSON-LD— es el puente entre tu contenido y los motores que hoy generan respuestas. En 2026 su función se desplazó: de perseguir resultados enriquecidos a verificar tu entidad para que la IA te entienda y te cite con precisión. Esta guía cubre qué cambió, qué tipos importan y cómo implementarlo sin generar deuda de mantenimiento, con un apartado para sitios bilingües ES/EN.
Qué cambió en 2026 (y por qué confunde)
El cambio que más desconcierta es el del FAQ. Durante años, marcar preguntas frecuentes con FAQPage mostraba acordeones desplegables en los resultados de Google, y media web lo implementó por ese rich result. En 2026 Google restringió drásticamente su visualización para evitar que los sitios acapararan la pantalla; ahora aparece sobre todo en sitios gubernamentales o de salud de alta autoridad. Muchos concluyeron que el FAQ schema "murió", y se equivocan.
Lo que cambió es el motivo para usarlo, no su utilidad. El FAQ schema sigue siendo valioso para estructurar información de cara a los LLMs y a la búsqueda por voz: marca pares pregunta-respuesta que los modelos extraen con facilidad y que alimentan respuestas conversacionales. La lección general de 2026 es esa: el schema dejó de valer principalmente por el adorno visual en la SERP y pasó a valer por cómo ayuda a las máquinas a entender y citar. Quien siga midiendo el schema solo por sus rich results está mirando la mitad equivocada del tablero.
El caso del FAQ es el ejemplo más visible de un movimiento más amplio: Google ha ido recortando los rich results que premiaban el marcado por sí mismo, mientras los motores de IA hacían lo contrario, apoyándose cada vez más en datos estructurados para entender y citar. El resultado es una inversión de incentivos. Si implementabas schema para ganar espacio en la SERP, parte de esa recompensa se ha evaporado; si lo implementas para que las máquinas te comprendan, nunca ha valido más. La estrategia sensata en 2026 es dejar de optimizar el schema para la galería de resultados y empezar a optimizarlo para la comprensión, que es donde se decide la cita.
el giro de fondo
De adornar resultados a verificar tu entidad
Sin datos estructurados, los buscadores y los agentes de IA interpretan tu web como texto plano. Con ellos, la interpretan como información verificable: entidades, atributos y relaciones. Esa diferencia es la que decide si un motor generativo te cita con precisión o te describe a tientas. El schema pasó de ser una técnica de CTR a ser el lenguaje con el que le cuentas a la IA, sin ambigüedad, qué es tu negocio, qué ofreces y cómo se relaciona todo.
Por eso el centro de gravedad se movió hacia la entidad. Los motores construyen un grafo de conocimiento sobre tu marca a partir de señales consistentes, y el schema es la forma más directa de alimentar ese grafo con la verdad sobre ti. Organization con su sameAs, Article con su autor, Service con sus atributos: cada bloque correcto refuerza una entidad coherente, y una entidad coherente es lo que más premian Claude, Gemini y el resto al decidir a quién citar. El schema, en 2026, es infraestructura de identidad antes que decoración de resultados.
Hay una consecuencia práctica que conviene interiorizar: el schema no convence por sí solo, confirma. Los datos estructurados ayudan cuando el texto visible aporta el contexto y las fuentes; un marcado impecable sobre una página vacía no consigue una sola cita. Lo que hace el schema es eliminar la ambigüedad de lo que la página ya demuestra: si tu contenido evidencia que eres referente en un tema, el Organization con su knowsAbout lo confirma sin que el motor tenga que inferirlo; si un artículo está firmado por un experto, el Article con author lo declara sin lugar a duda. Schema y contenido son las dos mitades de un mismo mensaje, y la IA las lee juntas.
el formato
JSON-LD, y por qué es el formato a usar
Schema markup es el vocabulario (los tipos y propiedades de schema.org); JSON-LD es el formato con el que se escribe, y el recomendado por Google. Su ventaja es práctica: se inserta como un bloque de script separado del HTML visible, así que puedes añadir, cambiar o quitar datos estructurados sin tocar el contenido de la página, y es más fácil de generar dinámicamente, mantener y depurar. Un ejemplo mínimo de Organization:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "The AC Group",
"url": "https://theacgroup.com",
"foundingDate": "1999",
"knowsAbout": ["Generative Engine Optimization", "AI visibility"],
"sameAs": ["https://www.linkedin.com/company/..."]
}Un detalle que marca diferencia: escribe el schema del lado del servidor. Así queda en el código que recibe el motor y cualquier crawler lo lee de inmediato, sin depender de que se ejecute JavaScript. Esto enlaza con un principio de accesibilidad que la IA premia: la información importante no debería depender de ejecuciones complejas. Código limpio, server-side, legible al primer paso.
Para contenido editorial, el patrón que más eleva la confianza es declarar el autor como entidad. Un Article con author nombrado y verificable se cita con bastante más seguridad que el mismo texto sin firma:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Qué es el GEO",
"datePublished": "2026-02-10",
"dateModified": "2026-06-11",
"author": {
"@type": "Person",
"name": "Nombre Apellido",
"jobTitle": "Especialista en GEO",
"url": "https://theacgroup.com/equipo/..."
},
"publisher": { "@type": "Organization", "name": "The AC Group" }
}Cuando una página justifica varios tipos la forma ordenada de combinarlos es anidarlos con @graph, declarando cada entidad una vez y enlazándolas por sus @id en lugar de repetir bloques sueltos. Un @graph bien armado le da al motor un mapa de cómo se relacionan tu organización, tu artículo, su autor y sus preguntas, que es justo el tipo de coherencia que refuerza tu entidad.
qué implementar
Los tipos que de verdad importan
Schema.org define más de 800 tipos, pero para la mayoría de los sitios un puñado hace casi todo el trabajo. Estos son los que sostienen una buena base para SEO y para GEO:
Article + author
Para contenido editorial, con un autor declarado y verificable. La autoría nombrada eleva la confianza con que la IA cita; una página "sin autor" pesa menos que una firmada por un experto con perfil público.
Service / Product
Describe lo que ofreces con sus atributos verificables: precio, disponibilidad, área servida. Cuantos más atributos estructurados correctos, mejor te clasifica y cita el modelo.
FAQPage / HowTo
Pares pregunta-respuesta y pasos. Su rich result se restringió, pero siguen estructurando información extraíble para LLMs y voz. Úsalos donde la página realmente tenga FAQs o pasos, no de adorno.
BreadcrumbList
La ruta de navegación. Ayuda a los motores a situar la página en la jerarquía del sitio y aporta contexto sobre de qué trata y dónde encaja.
Una práctica de las agencias serias es combinar varios en cada plantilla —por ejemplo Article + FAQPage + Organization en un artículo— anidados con @graph para expresar cómo se relacionan. Pero combinar no es acumular: cada tipo añadido debe corresponder a algo que la página realmente contiene. Esa disciplina nos lleva al principio más importante de todos.
Un apunte sobre prioridades, porque no todos rinden igual. Si tuvieras que implementar solo uno, sería Organization bien hecho: es el que ancla tu identidad y del que cuelga casi todo lo demás. Después, Article con autor en tu contenido editorial y Service o Product en tus páginas comerciales. FAQPage, HowTo y BreadcrumbList suman donde encajan de forma natural, pero no merece la pena forzarlos. Empieza por la entidad raíz y crece desde ahí; un Organization sólido con tres tipos correctos vale más que ocho tipos a medias.
el principio rector
Honestidad estructural: el schema describe lo que la página sostiene
Si hay una sola regla que respetar, es esta: el schema debe reflejar lo que la página demuestra de verdad, ni más ni menos. No marques FAQ en una página narrativa sin preguntas. No marques Product sin disponibilidad real. Si el modelo cita un precio desde tu schema, ese precio tiene que ser el que ve un humano en la página. Un grafo pequeño y correcto vence siempre a uno grande y contradictorio, porque la incoherencia entre el marcado y el contenido visible es justo lo que penalizan los buscadores y lo que erosiona la confianza de un modelo.
La forma técnica de garantizarlo es generar los datos desde el mismo backend que pinta la interfaz, de modo que schema y página no puedan divergir, y validarlos en integración continua para que un rediseño no rompa el marcado en silencio. Los rediseños son la causa más frecuente de schema roto: guarda URLs de referencia para comparar antes y después, y prueba por plantilla. Y cuando algo caduca —una promoción, un precio, un producto retirado— limpia el schema y el contenido el mismo día. El marcado desactualizado no es neutral: es una mentira que un modelo puede repetir con tu nombre.
Esta disciplina tiene una recompensa que va más allá de evitar penalizaciones. Un grafo de schema coherente, mantenido y verdadero se convierte en un activo defensivo: alimenta a los motores con la verdad sobre tu negocio de forma tan consistente que se vuelve la versión que la IA da por buena, y desplaza a las descripciones imprecisas que circulan por ahí. Es lo más parecido a controlar tu propia narrativa ante una máquina que, por defecto, sintetiza la suya. Pero ese activo solo existe si es honesto; en cuanto el marcado promete lo que la página no cumple, deja de ser un foso y pasa a ser una grieta.
para sitios ES/EN
Schema bilingüe: una entidad, dos idiomas
Un sitio que vive en español e inglés tiene un reto de identidad que casi ninguna guía aborda: lograr que la IA entienda que las dos versiones son la misma entidad, no dos marcas distintas. La regla que funciona es separar lo que es para humanos de lo que es para sistemas. Localiza los textos —name, description— en cada idioma, porque los lee la gente; pero mantén estables los identificadores —los @id, la entidad canónica— porque los leen las máquinas. Une las versiones con hreflang en el head y con sameAs en el grafo, de modo que el modelo conecte ambas como una sola marca.
Conviene además documentar cuál es la marca canónica en español frente a inglés y revisar las relaciones sameAs cuando algo cambie —una fusión, un nuevo perfil, un cambio de dominio— porque un sameAs roto fragmenta tu entidad y reparte tus citas entre dos identidades a medias. Para una marca que sirve a la vez a Estados Unidos, España y Latinoamérica, este cuidado no es un extra técnico: es lo que evita que el trabajo de visibilidad en un idioma se pierda en el otro. Es, además, una de las razones por las que tratamos el GEO bilingüe como una sola entidad gestionada en dos idiomas, no como dos proyectos paralelos.
Un error concreto ilustra por qué importa tanto: traducir el sitio y dejar que cada versión declare su propio Organization sin enlazarlos. A ojos de un modelo, eso crea dos entidades —"The AC Group" y su equivalente en el otro idioma— que compiten por las mismas citas y diluyen la autoridad de ambas. La IA reparte la confianza entre dos identidades a medias en lugar de concentrarla en una. La corrección es declarar una entidad canónica única, referida por @id estable, y que cada versión idiomática la referencie en lugar de redefinirla; los textos cambian, la identidad no. Con hreflang señalas a Google que son traducciones de la misma página, y con sameAs y un @id compartido le dices a cualquier motor que detrás hay una sola marca. Hecho así, el trabajo de visibilidad en inglés y en español se suma en una entidad más fuerte, en lugar de restarse en dos más débiles.
qué evitar
Errores que invalidan tu marcado
La mayoría de los problemas de schema no son de estrategia sino de ejecución. Estos cinco son los que más a menudo tiran por tierra un buen marcado:
Datos no coincidentes
El schema dice una cosa y la página visible otra. Google penaliza esta inconsistencia, y un modelo que cite el dato equivocado daña tu credibilidad.
Propiedades obligatorias faltantes
Cada tipo tiene propiedades requeridas; omitirlas invalida el marcado entero, aunque el resto esté bien.
JSON-LD mal formateado
Una coma de más o un corchete sin cerrar rompe todo el bloque. La validación antes y después de publicar no es opcional.
Schema en páginas irrelevantes
Marcar una página "Sobre nosotros" como Product, o meter FAQ en una narrativa sin preguntas. El tipo debe corresponder a lo que la página es.
Reseñas auto-generadas
Crear reseñas falsas con Review viola las directrices y, descubierto, cuesta más que la ventaja que buscaba.
La defensa contra todos ellos es la misma rutina: validar el JSON-LD antes y después de publicar, vigilar la sección de mejoras de Search Console para detectar errores y advertencias por tipo, y tratar el schema como código que se prueba, no como texto que se pega. Implementado así —con JSON-LD, propiedades validadas y gobernanza— refuerza las señales de entidad que importan tanto en la búsqueda tradicional como en el descubrimiento por IA, sin convertirse con el tiempo en una deuda de mantenimiento.
Vale la pena concretar esa rutina, porque "validar" suena obvio y casi nadie lo hace de forma sistemática. Antes de publicar, pasa cada plantilla por un validador de datos estructurados y por la prueba de resultados enriquecidos para confirmar que el tipo es elegible y no faltan propiedades obligatorias. Después de publicar, vigila la sección de mejoras de Search Console, que lista errores y advertencias por tipo a medida que Google rastrea: es el primer sitio donde aparece un schema roto por un rediseño. Y automatiza lo que puedas: una prueba por plantilla en integración continua atrapa la coma que falta antes de que llegue a producción. Tratar el schema como código que se prueba, y no como texto que se pega una vez y se olvida, es la diferencia entre un activo que envejece bien y una fuente silenciosa de errores.
Cerramos donde empezamos: en 2026 el schema vale por cómo te hace comprensible para las máquinas, no por el adorno que ya casi no muestra. Implementado con honestidad, validado con disciplina y cuidado en ambos idiomas, es una de las inversiones técnicas de mayor retorno para la visibilidad en IA. Si quieres ver el porqué de fondo, está en qué es el GEO; si prefieres el método completo, en cómo aparecer en la IA; y si quieres que lo implementemos por ti, ese es el trabajo de nuestra agencia GEO.
preguntas
Schema y datos estructurados: preguntas frecuentes
¿Sigue sirviendo el FAQ schema en 2026?
Sí, aunque su papel cambió. Google restringió la visualización de los acordeones de FAQ en los resultados tradicionales, que ahora se muestran sobre todo en sitios gubernamentales o de salud de alta autoridad. Pero el FAQ schema sigue siendo útil para estructurar la información de cara a los LLMs y a la búsqueda por voz: marca pares pregunta-respuesta que los modelos extraen con facilidad. La conclusión no es eliminarlo, sino dejar de esperar de él un rich result que ya casi no aparece y mantenerlo por su valor para la IA.
¿Por qué JSON-LD y no microdatos?
Porque JSON-LD es el formato recomendado por Google y el más mantenible. Se inserta como un bloque de script independiente del HTML visible, así que puedes añadir, modificar o eliminar datos estructurados sin tocar el contenido de la página, y es más fácil de generar dinámicamente y de depurar. Si el schema se escribe del lado del servidor queda directamente en el código que recibe el motor, de modo que cualquier crawler lo lee de inmediato, sin depender de que se ejecute JavaScript.
¿El schema me garantiza aparecer en la IA?
No por sí solo. El schema ayuda a que los motores entiendan e interpreten tu contenido con menos ambigüedad, y los sitios con datos estructurados validados tienden a ser citados con más frecuencia, pero es una condición facilitadora, no un interruptor. Los datos estructurados ayudan cuando el texto visible aporta el contexto y las fuentes; un marcado perfecto sobre una página vacía no cita a nadie. Schema y contenido trabajan juntos: el primero etiqueta lo que el segundo demuestra.
¿Qué pasa si el schema no coincide con lo que se ve en la página?
Es uno de los errores más penalizados. Si el schema dice un precio, un horario o una característica distinta de lo que ve un humano en la página, Google lo trata como datos no coincidentes y puede ignorar el marcado o penalizarlo. La regla, que llamamos honestidad estructural, es simple: el schema describe lo que la página sostiene de verdad, ni más ni menos. Si el modelo cita un precio desde tu schema, debe ser el mismo que ve la persona.
¿Cómo manejo el schema en un sitio bilingüe ES/EN?
Con una regla clara: localiza los nombres para los usuarios, pero mantén los identificadores estables para los sistemas. La descripción y el name pueden estar en cada idioma, mientras que los @id y la entidad canónica se mantienen consistentes entre versiones, enlazadas con sameAs y hreflang. Conviene documentar cuál es la marca canónica en español frente a inglés y revisar las relaciones sameAs cuando algo cambie, para que la IA reconozca que las dos versiones son la misma entidad y no dos marcas distintas.
¿Tu schema ayuda o estorba?
La instantánea gratuita de visibilidad en IA revisa, entre otras cosas, si tus datos estructurados son coherentes con tu contenido y si tu entidad se entiende en ambos idiomas. Cuarenta y ocho horas, sin llamada de ventas.