AI SEO y GEO: Qué Necesita Realmente un Sitio Web

El AI SEO no es la lista de tareas que describen la mayoría de las guías: un archivo llms.txt, algo de schema extra, esperar a que te citen. Es algo más básico y menos vistoso: si un crawler puede llegar de verdad a tu página, y si queda algo ahí cuando lo hace. En cuanto ves esas dos puertas, la lista de tareas deja de importar.

Respuesta directa

El AI SEO es la práctica de hacer que un sitio web sea legible para los crawlers que alimentan a los grandes modelos de lenguaje, y el GEO es lo que viene después: conseguir la cita una vez que un modelo puede leer realmente la página. Juntos, se reducen a tres cosas: si el crawler puede acceder a la página, si la página sigue teniendo texto una vez que se elimina el JavaScript, y si sus afirmaciones están lo bastante estructuradas y respaldadas como para citarse con confianza. Un archivo llms.txt no es una de ellas.

Puntos clave

• El AI SEO y el GEO no se tratan de posicionarte entre diez enlaces azules, sino de si un modelo de lenguaje puede acceder, leer y confiar en una afirmación de tu página.
• Un archivo llms.txt no cambia nada de esto. Es una convención propuesta, no algo que ningún crawler de IA relevante esté documentado que lea o siga.
• La propia guía de Google para desarrolladores dice que no hace falta ningún schema especial para las AI Overviews o el AI Mode: los datos estructurados habituales siguen ayudando, por las mismas razones de siempre.
• Si tu página renderiza su contenido con JavaScript del lado del cliente, algunos crawlers de IA pueden no verlo nunca, porque trabajan sobre el HTML que obtienen y no ejecutan scripts como lo haría un navegador o Googlebot.
• La solución es aburrida: deja entrar a los crawlers, sirve texto real en la respuesta inicial, marca las entidades, y respalda las afirmaciones con fuentes que un modelo pueda comprobar.

Qué necesitan realmente el AI SEO y el GEO

«AI SEO» y «GEO» se usan indistintamente, y para quien tiene un sitio web la distinción rara vez importa en el día a día. Ambos describen el mismo cambio: la búsqueda ya no es solo una lista de enlaces en la que alguien hace clic. Una parte creciente de las consultas se responde dentro de una ventana de chat, en una AI Overview, o en el propio paso de investigación de un agente, y nada de eso requiere un clic hacia tu sitio. Un artículo anterior en este sitio cubre con más detalle la distinción entre cita y posicionamiento. Lo que no cubre, y lo que realmente decide si todo esto funciona para una página concreta, es la infraestructura de debajo.

Dos sistemas tienen que funcionar antes de que una cita sea posible. Primero, un crawler tiene que tener permiso para entrar en la página y poder extraer algo de ella. Segundo, lo que extraiga tiene que ser lo bastante seguro, estructurado y respaldado en otros sitios como para que un modelo esté dispuesto a atribuir una afirmación a tu dominio en vez de al de un competidor. La mayoría de los consejos públicos sobre AI SEO no abordan ninguna de las dos cosas. Abordan una tercera (un archivo, un fragmento de markup) que no determina ninguno de los dos resultados. Y la lista de tareas falla siempre en los mismos tres puntos: un crawler bloqueado, una página vacía hasta que corre el JavaScript, y una afirmación sin estructura ni respaldo detrás.

¿Llega siquiera un crawler de IA a tu página?

Esta es la primera puerta, y es la que la mayoría se salta porque suena como un problema ya resuelto. No lo es, por dos razones.

La primera es que el volumen de rastreo de IA ha crecido lo suficiente como para que muchos equipos de infraestructura bloqueen ese tráfico por defecto. Cloudflare informó que el tráfico automatizado y no humano superó el 50% del tráfico web que mide durante 2026, un umbral que no esperaba alcanzar hasta un año después. Una parte importante de eso son crawlers y agentes de IA, y el instinto en muchas empresas ha sido tratar ese tráfico como tratarían a un scraper: limitar la tasa, bloquearlo en el CDN, o dejar una regla restrictiva de robots.txt que quedó de una revisión de seguridad que no tenía nada que ver con la búsqueda. Cualquiera de esas medidas, dirigida específicamente a GPTBot, ClaudeBot o PerplexityBot, hace irrelevante el resto de este artículo para tu sitio. Una página que no se puede obtener no se puede citar.

La segunda razón tiene menos que ver con la política y más con no conocer tus propias configuraciones por defecto. Muchas configuraciones de CDN y WAF vienen con el bloqueo de «bots de IA» activado, o incluido dentro de una regla genérica de gestión de bots que el equipo activó por un motivo que no tenía relación con esto. Si la cita y el tráfico referido por IA son objetivos, esa configuración por defecto necesita una decisión deliberada, no un accidente. Comprueba qué hace tu red perimetral con GPTBot, ClaudeBot, Google-Extended y PerplexityBot en concreto: «bloqueamos los bots malos» no es una respuesta a esa pregunta.

La parte que casi nadie comprueba: ¿sigue habiendo texto en la página?

Supongamos que el crawler entra. La siguiente pregunta es qué recibe realmente, y aquí es donde una página que se posiciona perfectamente en Google puede ser funcionalmente invisible para un motor de respuestas de IA.

Los motores de búsqueda y los crawlers de IA no gestionan todos el JavaScript de la misma manera. Googlebot (y por extensión las AI Overviews de Google, a través del crawler Google-Extended que hereda el pipeline de renderizado de Googlebot) ejecuta JavaScript del lado del cliente antes de indexar una página. Eso ha sido así durante años, y es la razón por la que una aplicación moderna de una sola página puede seguir posicionándose en Google. Un análisis a gran escala del comportamiento de los crawlers de IA hecho por Vercel y MERJ, basado en registros reales de peticiones y no en una prueba de laboratorio, encontró el patrón contrario para los crawlers detrás de los grandes asistentes de chat: GPTBot y ClaudeBot trabajan a partir de la respuesta HTML inicial, sin evidencia de ejecutar el JavaScript de la página, incluso en las peticiones en las que sí descargaron los archivos de script de la página.

La consecuencia práctica es concreta. Toma una tienda construida como aplicación renderizada en el cliente (la elección de plataforma importa aquí: mira los mejores creadores de sitios web con IA para ecommerce para ver cómo eso se juega en herramientas concretas): el precio del producto llega mediante una llamada a una API que se dispara después de cargar la página, y un componente «use client» lo pinta en el DOM en cuanto esa llamada se resuelve. Un navegador ve el precio. Googlebot ve el precio, porque espera al renderizado. GPTBot y ClaudeBot, según esta evidencia, ven un campo de precio vacío, porque nada en la respuesta HTML inicial lo contenía nunca; el mismo vacío se aplica a una tabla de especificaciones, una respuesta de FAQ, o el párrafo que realmente explica tu producto. Ven la cáscara. (La misma lógica afecta a la velocidad de página, tanto para las visitas humanas como para el presupuesto de rastreo.) Tu puntuación de SEO en la página puede ser excelente y tu exposición en GEO puede seguir siendo casi nula, por una razón que ningún schema markup arregla.

Los datos estructurados no son irrelevantes aquí, pero tampoco son la palanca que venden la mayoría de los proveedores. La propia documentación de Google para desarrolladores sobre optimización para funciones de IA afirma claramente que no se requiere ningún dato estructurado especial o nuevo para las AI Overviews o el AI Mode: el mismo markup Organization, Article y FAQPage que ya ayuda a desambiguar una página para la búsqueda habitual hace el mismo trabajo aquí, por la misma razón: elimina la ambigüedad sobre qué es un contenido y quién lo publicó. Sigue mereciendo la pena hacerlo. Simplemente no es la frase que cuenta.

Esa tabla es la verdadera lista de tareas del AI SEO. Fíjate en que ninguna de sus filas es un archivo que descargas una vez y olvidas.

Resumen

Nada de esto es una disciplina nueva pegada encima del SEO. Es la misma disciplina (páginas accesibles para crawlers, rápidas, sin ambigüedades) dirigida a una audiencia más nueva y, según las cifras de Cloudflare, ya mayor que la humana. Los sitios que ya trataban el acceso de crawlers y el contenido renderizado en el servidor como innegociables, por razones normales de búsqueda, son los mismos que un crawler de IA ya puede leer sin que nadie haga nada nuevo por ello. El hueco pertenece a los sitios que delegaron su contenido en el cliente y asumieron que una buena puntuación de rendimiento significaba que una máquina podía leerlos. No es así, y ningún archivo llms.txt cierra ese hueco por ti.