SEO, AIO y GEO nombran tres objetivos distintos y comparten casi todo el trabajo técnico. El SEO busca aparecer en los resultados de un buscador. El AIOGlosarioAIO y GEODos capas de optimización que se suman al SEO clásico. AIO (AI Optimization) busca que el contenido sea comprensible para asistentes de IA mediante estructura clara, entidades definidas y datos legibles por máquina. GEO (Generative Engine Optimization) busca que una marca aparezca y se cite en las respuestas de los motores generativos. Las dos dependen de los mismos cimientos técnicos que el SEO, como el marcado estructurado y un archivo llms.txt.Ver término completo → busca que un asistente de IA entienda el contenido. El GEO busca que una marca aparezca citada en la respuesta de un motor generativo. Las tres capas se apoyan en un mismo suelo, y ese suelo se construye una vez.
Un mismo suelo para tres capas
Los cimientos técnicos son los mismos y se listan sin más.
- HTML semántico, con encabezados jerárquicos, listas y tablas reales.
- Título y meta descripción por página.
- Canonical y, si hay idiomas, hreflang.
- Datos estructurados en JSON-LDGlosarioJSON-LDFormato de datos estructurados basado en JSON que describe el contenido de una página con el vocabulario de Schema.org.
Se inserta en un bloque
<script type="application/ld+json">del HTML. Buscadores y asistentes de IA lo leen para identificar entidades como un producto, un artículo o una ruta de navegación sin interpretar el diseño de la página.Ver término completo →. - Un
robots.txtcon reglas explícitas por rastreador. - Un fichero llms.txtGlosariollms.txtArchivo de texto en la raíz de un sitio que ofrece a los modelos de lenguaje un índice resumido de sus páginas más relevantes. Funciona como un mapa legible por IA, comparable a un sitemap pensado para asistentes. Un generador propio puede construirlo a partir del modelo de contenido del sitio en lugar de mantenerlo a mano. Más detalle en WebMCP y llms.txt.Ver término completo → como índice legible por máquina.
La tabla sitúa cada cimiento en la capa donde más pesa. Las tres capas usan todos, aunque en proporciones distintas. Los niveles Alto, Medio y Bajo son una valoración orientativa del peso relativo, no un dato medido.
| Cimiento | SEO | AIO | GEO |
|---|---|---|---|
| HTML semántico | Alto | Alto | Medio |
| Título, descripción y canonical | Alto | Medio | Bajo |
| JSON-LD por tipo de contenido | Medio | Alto | Alto |
robots.txt por rastreador | Medio | Medio | Alto |
llms.txt | Bajo | Medio | Medio |
| Contenido con datos citables | Alto | Alto | Alto |
La última fila no es técnica. Ninguna capa funciona sin contenido que merezca ser leído, resumido o citado, y ese contenido sale del modelo de datos, no de una etiqueta.
Qué mide cada capa y qué no se puede prometer
Cada capa tiene un indicador propio y una incertidumbre propia. Prometer un resultado sin línea base es afirmar sin evidencia.
| Capa | Qué se puede medir | Qué no se puede prometer sin línea base |
|---|---|---|
| SEO | Impresiones, clics, posición media, páginas indexadas | Subir de posición o ganar un porcentaje de tráfico |
| AIO | Que el marcado valide, que las páginas se resuman bien en pruebas con asistentes | Que un asistente concreto lea el marcado o el índice |
| GEO | Menciones y citas en respuestas, tráfico referido desde asistentes | Que una respuesta generativa cite la marca |
- ✓La pieza existe y valida. El marcado pasa una validación y el fichero responde con 200.
- ✓La cobertura creció. Más páginas descritas que antes, medido con el mismo recuento.
- ✓La decisión consta por escrito. Una regla de rastreador permitido o bloqueado queda documentada.
- ✕Una mejora porcentual. Sin base, definición, fuente y responsable, la cifra carece de punto de partida.
- ✕Que un asistente use el índice. Existir y ser consultado son hechos distintos.
- ✕Que una cita llegue por haber marcado. La cita depende del contenido y de decisiones del motor.
Implementar desde el modelo de contenido
El marcado se genera mejor desde los campos de negocio que desde una plantilla genérica. Si cada ficha ya guarda su problema, su resumen y sus relaciones, un solo origen alimenta el título, la descripción, el JSON-LD y el índice de llms.txt.
- Inventariar los tipos de contenido. Cada tipo recibe un tipo de Schema.org que le corresponda. Producto, artículo, organización, ruta de migas.
- Elegir un campo de verdad por dato. El problema que resuelve, el resumen técnico, la fecha de publicación. Un dato con dos copias acaba sirviendo el valor viejo en una de ellas.
- Generar todas las salidas desde ese campo. Meta descripción, JSON-LD e índice leen el mismo origen. Cambiar el campo cambia las tres.
- Declarar una entidad de organización con identificador estable. Los artículos apuntan a ella por su identificador, en lugar de repetir el nombre en cada bloque.
- Emitir reglas de rastreador por escrito. Permitir o bloquear cada agente de IA es una decisión de negocio que debe constar. Un
Allowno obliga a nadie a visitar el sitio. - Mantener el índice conciso. Descripciones de una línea y los listados largos en un fichero aparte, porque el índice se consume entero dentro de una ventana de contexto.
- Validar y registrar. Validar el marcado, comprobar que cada URL devuelve un título, una descripción y un canonical únicos, y anotar entorno y fecha del barrido.
Esta lección complementa dos referencias y no repite su contenido. El protocolo de herramientas para agentes y el formato del manifiesto se explican en WebMCP y llms.txt. La relación entre el árbol de accesibilidad, el HTML y el coste en tokens se desarrolla en navegación agéntica. Aquí se trata de la decisión previa, qué capa persigue cada pieza y qué evidencia la respalda.
Errores típicos
- Tratar el JSON-LD como decoración. Un grafo idéntico en todas las páginas no distingue un producto de un artículo y no aporta lo que prometía.
- Duplicar el marcado. Dos generadores activos, por ejemplo un plugin y un motor propio, imprimen bloques en conflicto.
- Prometer citas. Convertir un
llms.txto unAllowen un compromiso de visibilidad. - Copiar el dato en varios sitios. El valor corregido en la ficha sigue viejo en el marcado.
- Omitir la meta descripción por confiar en el extracto. El buscador y los asistentes reciben texto sin curar.
- Inflar el índice. Un
llms.txtque lista todo sin descripciones breves agota la ventana de contexto del modelo antes de llegar a lo importante. - Olvidar la línea base. Implementar sin fijar de antemano qué se medirá deja cualquier resultado sin interpretación posible.
Criterio de decisión
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿Cada ficha guarda sus campos de negocio en un solo lugar? | Generar marcado e índice desde ellos | Ordenar primero el modelo de contenido |
| ¿Existe una línea base con definición, fuente y responsable? | Se puede hablar de mejora medida | Describir lo implementado y no prometer resultados |
| ¿El sitio ya recibe consultas de asistentes de IA registradas? | Medir referidos y citas | Tratar GEO como hipótesis |
| ¿Hay versiones de idioma? | Emitir hreflang y revisar el que genera el sistema de traducción | Posponer hreflang y anotarlo |
| ¿La decisión sobre rastreadores de entrenamiento está tomada? | Reflejarla en robots.txt | Decidirla antes de publicar reglas |
Del caso al principio
El caso de un motor propio de SEO y GEO en WordPress permite ver el reparto en funcionamiento. Cada capa terminó en una pieza concreta, y todas leían los campos de las mismas fichas. El mismo caso deja también el límite, porque lo implementado se puede describir y lo conseguido queda sin cifra mientras falte la medición posterior.
De ahí sale el principio. Las tres capas se construyen una sola vez sobre el modelo de contenido, y cada una se declara con su indicador y su incertidumbre. Una capa sin línea base se documenta como implementada, no como lograda.