// guía
¿Cómo se hace GEO en la práctica en el propio sitio?
Autor: Dmitry Filippov, Founder, GET-GEO.AI
Publicado: 2026-08-03 · Actualizado: 2026-09-22
// respuesta breve
En get-geo.ai dedicamos media jornada a unificar las señales en un solo host, facilitar la lectura del contenido desde la primera petición y configurar una propiedad de dominio en Search Console. También generamos archivos llms-full por idioma desde el mismo registro que las páginas. Estos cambios facilitan el acceso a los contenidos que los asistentes pueden citar.
- Hacer GEO en nuestro propio sitio llevó medio día y ninguna página nueva: un host principal, una propiedad de dominio en Search Console y exportaciones llms-full reconstruidas.
- Todas las señales apuntaban al apex mientras el apex respondía con una redirección 308 a www: un bucle que los sistemas de IA con presupuesto de una petición nunca atraviesan.
- El checklist de un agente de IA decía que el registro A del apex debía apuntar a 76.76.21.21; el DNS real mostraba 216.198.79.1, la infraestructura nueva de Vercel, así que verifique el consejo del modelo contra el sistema real.
- Un sitemap recién enviado puede mostrar «No se ha podido obtener» durante un par de días; compruebe tres cosas: el archivo abre, cada loc usa el host correcto y robots.txt lo lista.
- llms-full ahora publica un archivo por idioma para 9 idiomas; el devanagari ocupa 3 bytes por carácter, así que el archivo hindi llegó a 85 KB y el límite subió a 300 KB.
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, 9 idiomas con hreflang, JSON-LD de Schema.org, contenido con la respuesta al principio, 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 rastreador convencional de Google puede superar el bucle, aunque consume presupuesto de rastreo. Los sistemas de IA que recuperan páginas 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 sistema que lo consulta 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 de forma permanente. Cualquier brecha entre «dónde vive el sitio» y «adónde apuntan las señales» consume recursos en cada visita del rastreador.
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 desactualizado. El modelo citaba el pasado con total seguridad.
La lección: un agente de IA sin herramientas de verificación es memoria, no conocimiento. Contraste 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, compruebe 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 espere.
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 rastreadores 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 sistema conozca la convención /llms.txt.
La lección: trate el sitemap como un menú para máquinas, no como una casilla. Todo lo que quiera 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 página de inicio: las guías — nuestro activo más citable — solo estaban disponibles página a página.
Qué cambiamos:
- Archivos por idioma. Los textos completos de las guías pasaron a llms-full/{locale}, cada archivo íntegramente en su idioma. Amontonar 9 idiomas en un solo archivo significa diluir por nueve 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. Así evitamos depender de una sincronización manual que sería difícil mantener.
- Un límite con una alternativa explícita. 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 300 KB. Si su sitio es multilingüe, presupueste 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 sistema de IA que recupera páginas 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 9 idiomas está disponible para las máquinas en un archivo por idioma;
- 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 le citan. La técnica decide si alguien llega a leer hasta su 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 nombre de host configurado con una redirección permanente. Un bucle entre apex y www quema presupuesto de rastreo y a menudo detiene a los sistemas de IA que recuperan páginas que solo hacen una o dos peticiones.
¿Debo usar una propiedad de dominio en Google Search Console?
Sí, si le 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 rastreadores de IA leyendo sitemaps. Listar llms.txt y los archivos llms-full por idioma les da una ruta directa al corpus legible por máquinas sin confiar en que cada sistema conozca la convención /llms.txt.
¿Por qué archivos llms-full por idioma en lugar de un volcado multilingüe?
Un solo archivo con nueve idiomas diluye la densidad útil nueve veces para cualquier consulta concreta. Un archivo por idioma 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.
Guías relacionadas
Fuentes
// compartir
Cómo citar esta página
Puedes citar y reutilizar el contenido indicando la autoría y enlazando esta página.
“¿Cómo se hace GEO en la práctica en el propio sitio?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/es/guides/how-we-do-geo-ourselves