// guía
¿Cómo se hace GEO en la práctica en el propio sitio?
Actualizado: 2026-08-03
// respuesta breve
El GEO técnico es higiene, no magia. En get-geo.ai media jornada de trabajo hizo que todas las señales apunten a un solo host, dio a los fetchers de IA el contenido a la primera petición, pasó Search Console a una propiedad de dominio y puso el corpus completo de guías en archivos llms-full por locale que se actualizan solos desde el mismo registro que las páginas. El contenido decide si te citan; la técnica decide si alguien llega a leer lo suficiente para citarte.
Punto de partida: un sitio que parece correcto
Vendemos GEO — así que nuestro propio sitio tiene que ser la implementación de referencia. Esta guía no es teoría sino el protocolo de un día de trabajo real: qué encontramos, cómo lo arreglamos y qué verificamos. Todos los ejemplos son de este mismo sitio.
get-geo.ai se construyó «según el manual» desde el primer día: renderizado en servidor, 8 idiomas con hreflang, JSON-LD de Schema.org, estructura answer-first, llms.txt. ¿Qué podría haber que arreglar? La auditoría encontró un problema invisible a simple vista.
Hallazgo n.º 1: el conflicto apex / www
El sitio vivía físicamente en www.get-geo.ai, mientras que todas las señales — canonical, sitemap, hreflang, JSON-LD, llms.txt — apuntaban a get-geo.ai (el apex, el dominio sin subdominio). Y el apex respondía con una redirección 308 de vuelta a www.
El resultado: un bucle. «La versión canónica es el apex» → el apex redirige a www → www declara «la versión canónica es el apex». Un crawler clásico de Google lo sobrevive, aunque quemando presupuesto de rastreo. Los fetchers de IA muchas veces no: muchos tienen un presupuesto de una o dos peticiones por página, y algunos sencillamente nunca llegan al contenido a través de una redirección. Para el GEO esto es crítico: un archivo invisible para el fetcher es un archivo que no existe.
El arreglo: el apex pasó a ser dominio primario en el hosting (Vercel), con www en 308 hacia el apex. Un solo interruptor — y todas las señales se volvieron coherentes: la dirección real, el canonical, los enlaces internos, el sitemap y llms.txt ahora apuntan al mismo lugar.
La lección: la elección entre apex y www no importa. Lo que importa es que el sitio viva exactamente en uno de los dos y que el otro redirija con firmeza. Cualquier brecha entre «dónde vive el sitio» y «adónde apuntan las señales» es un impuesto en cada visita del crawler.
Hallazgo n.º 2: el consejo desactualizado de un agente de IA
El diagnóstico lo hacía un agente de IA, y su checklist incluía: «verifica que el registro A del apex apunte a 76.76.21.21». La comprobación del DNS real mostró otra cosa: el dominio resuelve a 216.198.79.1 — la infraestructura nueva de Vercel, a la que el hosting migró después del corte de datos de entrenamiento del modelo.
El consejo no era dañino — solo rancio. El modelo citaba el pasado con total seguridad.
La lección: un agente de IA sin herramientas de verificación es memoria, no conocimiento. Contrasten cualquier recomendación técnica de un modelo con el estado real del sistema: una consulta DNS cuesta un segundo y zanja la cuestión. Este, por cierto, es el principio mismo del GEO: los modelos responden a partir de lo que lograron leer — y exactamente por eso hacemos el contenido legible.
Paso 3: Google Search Console — la propiedad de dominio
Tras el cambio de host primario, la antigua propiedad de GSC (prefijo de URL en https://www.get-geo.ai/) quedó inútil: cubre solo www, mientras las páginas migraban al apex.
La configuración correcta es una propiedad de dominio (get-geo.ai, sin protocolo ni subdominio): cubre de una vez apex, www, http, https y todos los subdominios. Solo se verifica mediante un registro DNS TXT — con un detalle agradable: el token google-site-verification está ligado a la cuenta, no al método de verificación, así que un registro añadido antes al DNS pasó la verificación al instante. Después — envío del sitemap con la dirección apex: https://get-geo.ai/sitemap.xml.
La lección: un sitemap recién enviado en GSC suele quedarse con el estado rojo «No se ha podido obtener» y cero páginas. No es un error sino un marcador de posición hasta el primer procesamiento — es asíncrono y puede tardar hasta un par de días. Antes de entrar en pánico, comprueben tres cosas: el archivo se abre en su URL directa, cada <loc> apunta al host correcto, y robots.txt contiene una línea Sitemap:. Si las tres se cumplen — simplemente esperen.
Paso 4: el sitemap como instrumento GEO, no como formalidad
Nuestro sitemap incluye más que páginas. Lista llms.txt, llms-full.txt y todas las versiones lingüísticas llms-full/{locale} — con fechas lastmod y prioridades.
Por qué: se ha observado a los crawlers de IA (GPTBot, ClaudeBot, PerplexityBot) leyendo sitemaps, y listar explícitamente los archivos LLM les da una ruta directa a la versión legible por máquinas del sitio — sin confiar en que el fetcher conozca la convención /llms.txt.
La lección: traten el sitemap como un menú para máquinas, no como una casilla. Todo lo que quieran mostrar a los sistemas de IA debe estar listado ahí, con fechas lastmod honestas.
Paso 5: llms-full — el contenido completo, no el índice
La convención distingue dos archivos: llms.txt es un índice con enlaces; llms-full.txt es el contenido completo para sistemas que no siguen enlaces. Nuestra versión full contenía al principio solo la landing: las guías — nuestro activo más citable — solo estaban disponibles página a página.
Qué cambiamos:
- Archivos por locale. Los textos completos de las guías pasaron a llms-full/{locale}, cada archivo íntegramente en su idioma. Amontonar 8 idiomas en un solo archivo significa diluir por ocho la densidad útil para cualquier consulta concreta.
- Una URL bajo cada título. Dentro del archivo, cada guía abre con su título y la URL canónica justo debajo — para que un modelo que tome el texto pueda citar la página, no el propio txt.
- Generación automática desde un registro único. Los archivos se construyen desde la misma fuente que las páginas de las guías. Una guía nueva llega al sitio, al sitemap y a llms-full con una sola acción. La sincronización manual muere en un mes — ni siquiera la empezamos.
- Un límite con degradación honesta. El archivo tiene un tope de tamaño; al desbordarse, en lugar de un recorte silencioso, añade la lista de guías que no cupieron, con sus enlaces.
- Una lección de un lugar inesperado: el primer límite de 100 KB casi lo rompe un sistema de escritura. El Devanagari (hindi) ocupa 3 bytes por carácter en UTF-8 frente a 1 del latino — el archivo hindi llegaba a 85 KB cuando el inglés pesaba la mitad. Subimos el límite a 200 KB. Si su sitio es multilingüe, presupuesten teniendo en cuenta la escritura: los sistemas CJK e índicos pesan varias veces más.
Balance del día
Media jornada de trabajo, ni una sola página nueva de contenido — y sin embargo:
- cada señal del sitio apunta a un solo host, sin bucles ni redirecciones de más;
- un fetcher de IA con presupuesto de una petición obtiene el contenido al primer intento;
- GSC recoge datos de todo el dominio, no de un solo subdominio;
- el corpus completo de guías en 8 idiomas está disponible para las máquinas en un archivo por locale;
- publicar una guía nueva actualiza automáticamente el sitio, el sitemap y llms-full.
Higiene, no magia
Esta es la parte técnica del GEO: no magia, higiene. El contenido decide si te citan. La técnica decide si alguien llega a leer hasta tu contenido.
Preguntas relacionadas
¿Importa apex vs www para el GEO?
La elección en sí no. Lo que importa es que el sitio viva exactamente en un solo host y que todas las señales — canonical, sitemap, hreflang, JSON-LD, llms.txt — apunten ahí, con el otro hostname en redirección dura. Un bucle entre apex y www quema presupuesto de rastreo y a menudo detiene a los fetchers de IA que solo hacen una o dos peticiones.
¿Debo usar una propiedad de dominio en Google Search Console?
Sí, si te importan tanto apex como www (o http y https). Una propiedad de dominio los cubre todos a la vez y se verifica vía DNS TXT. Una propiedad de prefijo de URL solo en www se queda ciega en cuanto el host primario pasa al apex.
¿Por qué listar llms.txt en el sitemap?
Se ha observado a los crawlers de IA leyendo sitemaps. Listar llms.txt y los archivos llms-full por locale les da una ruta directa al corpus legible por máquinas sin confiar en que cada fetcher conozca la convención /llms.txt.
¿Por qué archivos llms-full por locale en lugar de un volcado multilingüe?
Un solo archivo con ocho idiomas diluye la densidad útil ocho veces para cualquier consulta concreta. Un archivo por locale mantiene el corpus denso, pone una URL canónica bajo cada título de guía y puede generarse desde el mismo registro que las páginas HTML.