Por qué la IA no cita tu web: mucho llms.txt, mucho markup y el firewall con la porra

Hay una escena que define bastante bien el SEO de este 2026. Un negocio publica un artículo larguísimo con la intención de que Google, ChatGPT, Perplexity, Gemini, Claude y cualquier otro bicho con hambre de texto lo consideren una fuente seria. Le mete subtítulos, referencias, preguntas frecuentes, entidades, enlaces internos, datos estructurados, una introducción que parece escrita con bata blanca y hasta empieza a plantearse si necesita un llms.txt, un archivo Markdown, un JSON-LD bendecido por cuatro gurús y una vela encendida delante del sitemap.

Luego llega un crawler, intenta leer la página y la web le responde con un “Please wait while your request is being verified…”. O con un challenge de JavaScript. O con un captcha. O con un 403 más seco que una anchoa en agosto. Y ahí termina la épica generativa. La IA no lee el artículo. El fetcher no recupera el contenido. La herramienta externa ve una pared. El sistema que podía usar esa página como fuente se queda mirando al portero de discoteca de tu firewall, que le dice: “Tú no entras, que vienes con pinta de robot”.

Y después empiezan los dramas: “¿Por qué la IA no me cita?”.

Pues no sé, Sherlock. Igual porque le has puesto a la IA un control de acceso como si viniera a robar cobre.

La nueva chorrada brillante: obsesionarse con el llms.txt mientras el WAF reparte mamporros

Ahora mismo hay una carrera bastante curiosa por vender soluciones mágicas para aparecer en respuestas de IA. Antes era el “pon FAQ schema y subes”. Luego fue el “mete entidades”. Después el “escribe para intención de búsqueda”. Más tarde el “GEO”, el “AEO”, el “AIO”, el “LLMO” y cualquier combinación de letras que permita cobrar una auditoría con portada futurista. Y ahora le toca al llms.txt, al Markdown, al markup especial y a la promesa de que, si colocas un archivito en la raíz del dominio, las inteligencias artificiales vendrán a tu web como peregrinos a Santiago de Compostela.

No digo que todo eso sea inútil en cualquier contexto, ojo, que os veo venir. Hay matices. Puede haber usos para orientar agentes, documentar contenido importante, facilitar ciertos flujos o dejar instrucciones más limpias para sistemas concretos. Pero conviene no perder el norte. Google ya ha dicho claramente que no necesitas crear archivos especiales tipo llms.txt, textos para IA, markup adicional o versiones en Markdown para aparecer en Google Search, incluidas sus funciones generativas. Así que igual, antes de montar un altar al archivo de moda, merece la pena comprobar una cosa bastante más básica: si la página se puede leer.

Porque esto tiene mucha gracia. Estamos viendo a gente recomendar capas y capas de envoltorio semántico mientras la web devuelve un challenge anti-bot al primer sistema externo que intenta acceder. Es como ponerle un lazo precioso a una caja vacía. O peor: como imprimir una guía cojonuda, meterla dentro de una caja fuerte y luego contratar a un consultor freelance para que explique por qué nadie la consulta.

La pregunta clave para mí no es solo si tienes datos estructurados, si tu HTML está limpito y pulcro o si has generado un llms.txt con aroma a innovación tecnológica. La cuestión es esta: cuando un crawler legítimo llama a la puerta de un artículo público, ¿le sirves el contenido o le sirves una prueba de paciencia y la puerta de salida?

Estar publicado no significa estar disponible

Muchos propietarios de webs prueban una URL desde su navegador, ven que carga y concluyen que todo está bien. Y claro, desde su punto de vista parece lógico. Entran desde su conexión, con su navegador habitual, sus cookies, su historial, su sesión quizá ya validada, su IP residencial y su comportamiento de humano que lleva años navegando sin que nadie le pida demostrar que no es una tostadora parlante.

Pero un crawler no entra así. Una herramienta SEO tampoco. Un fetcher de un asistente puede no entrar así. Un sistema que intenta recuperar una página para resumirla o citarla puede llegar desde una IP de centro de datos, sin cookies previas, con un user-agent automatizado y sin ejecutar la coreografía completa de un usuario humano. Y entonces la web, que al propietario le parecía perfectamente abierta, enseña el garrote.

Puede aparecer una pantalla intermedia de verificación. Puede saltar Cloudflare. Puede intervenir Imunify360. Puede actuar ModSecurity. Puede entrar en juego LiteSpeed, una regla WAF del hosting, un plugin de seguridad de WordPress, una regla personalizada, un bloqueo por país, un filtro por ASN o una configuración anti-bot puesta en modo “aquí no pasa ni el apuntador”.

La web se ve. Sí. Pero, para ti.

Para una parte de las máquinas que deberían leerla, igual no existe. O existe como existe un local cerrado con el cartel bajado: sabes que está ahí, pero no puedes entrar a comprar nada.

La visibilidad ya no termina en “Google me indexa”

Durante años, la gran pregunta técnica era relativamente clara: ¿puede Googlebot rastrear esta página? Si Googlebot podía entrar, recuperar el HTML, procesar el contenido principal e indexarlo, ya teníamos la primera casilla marcada. Luego venía todo lo demás: intención de búsqueda, autoridad, estructura, enlaces internos, rendimiento, contenido útil, semántica, títulos, enlazado, competencia y los habituales sustos de Search Console.

Pero la búsqueda con IA añade una capa más. Ahora no solo importa que una página pueda aparecer en el índice clásico. Importa que pueda ser recuperada, entendida y comparada por sistemas que seleccionan fuentes para respuestas generativas. AI Overviews, AI Mode, ChatGPT Search, Perplexity, Bing con Copilot, asistentes con navegación, herramientas de investigación y sistemas de recuperación no funcionan todos igual, pero tienen una necesidad común: acceder al contenido real.

Y aquí empieza la zona gris. Una página puede estar indexada en Google y, aun así, ser difícil de recuperar para otros sistemas. Puede tener título, URL, fragmento y presencia histórica, pero si cuando una herramienta externa intenta leer el contenido recibe una pantalla de verificación, esa página pierde opciones de ser usada como fuente. No porque el texto sea malo. No porque falte una tabla. No porque no hayas invocado la palabra “entidad” suficientes veces. Pierde opciones porque la máquina llama y tu web le tira la persiana.

Esto conecta directamente con lo que ya expliqué en GEO, AEO y búsqueda con IA: Google acaba de recordar que esto sigue siendo SEO. Muchas siglas nuevas están intentando vender como revolución cosas que siguen dependiendo de fundamentos bastante antiguos: rastreo, contenido útil, estructura clara, autoridad, señales externas y una web técnicamente decente. El envoltorio ha cambiado. La base no tanto.

El falso consuelo: “pero en mi ordenador carga”

“Yo entro y lo veo”. Esta frase debería venir con una sirena amarilla en cualquier auditoría. Es prima hermana de “mi cuñado me buscó y salgo primero”, “la web carga rápido en mi móvil” y “eso del SEO ya lo tenemos porque pusimos palabras clave hace años”.

Que tú puedas entrar en una página no demuestra que los sistemas externos puedan leerla. Demuestra que tú, en tus condiciones concretas, puedes verla. Nada más. El SEO técnico no se valida con la comodidad del propietario, sino comprobando qué reciben los distintos agentes cuando solicitan la URL.

Un navegador humano puede pasar una verificación una vez y después navegar sin problema durante días. Un crawler puede encontrarse con el muro cada vez. Un usuario residencial puede ver el artículo completo. Una herramienta desde una IP de centro de datos puede recibir un 403. Googlebot puede tener vía libre. Otro crawler útil puede comerse un challenge. Bingbot puede entrar. ChatGPT-User puede quedarse en la puerta. Una herramienta SEO puede ver un HTML que no tiene nada que ver con el que ve un usuario normal.

Por eso, cuando alguien dice “la web está bien porque yo la veo”, lo prudente es no responder con violencia, pero sí con cierta compasión técnica. Es una frase humana. Comprensible. Y bastante inútil para diagnosticar este problema.

La IA no cita por telepatía

A veces hablamos de la inteligencia artificial como si fuera una señora con bola de cristal sentada en un despacho de Silicon Valley. Pero los sistemas que citan fuentes no funcionan por inspiración divina. Necesitan descubrir documentos, recuperar páginas, procesar contenido, comparar fuentes y decidir qué merece aparecer en una respuesta.

Si en esa cadena el sistema intenta recuperar una URL y recibe una pantalla anti-bot, la cosa se complica. Si recibe un 403, peor. Si recibe un 429 por un rate limit mal ajustado, mal. Si recibe un 503 temporal cada dos por tres, mal. Si se le sirve una versión vacía porque el contenido depende demasiado de JavaScript o de recursos bloqueados, mal. Si el WAF lo reta con una prueba que no puede resolver, mal. Si la página pública se comporta como una zona privada, mal negocio.

¿Significa esto que todo bloqueo impide siempre cualquier cita? No. No todos los sistemas acceden igual. Algunos usan índices propios. Otros se apoyan en buscadores. Otros hacen lecturas en tiempo real. Otros mezclan varias capas. Pero como regla práctica, y aquí no hace falta llamar a ningún gurú con gafas transparentes: si quieres que tu contenido tenga opciones de ser citado, debe poder ser leído.

Lo contrario es una escena ridícula. El equipo de contenidos escribiendo para la IA. La agencia hablando de visibilidad generativa. El consultor prometiendo aparecer en respuestas conversacionales. El dueño preguntando si hace falta un llms.txt. Y el firewall, en la puerta, haciendo de Gorila de Magaluf: “No pasas”.

robots.txt: útil, sí; varita mágica, no

El archivo robots.txt sigue siendo importante. No lo vamos a tirar por la ventana. Sirve para indicar a crawlers cooperativos qué rutas pueden o no pueden rastrear. Ayuda a gestionar acceso, carga y preferencias. Puede orientar a Googlebot, Bingbot y otros agentes que respeten el estándar. Es una pieza básica de higiene técnica.

Pero no es una cerradura. No es una alarma. No es un vigilante. No es una valla electrificada. Es más bien un cartel. Un cartel útil, sí, pero un cartel. Google recuerda en su documentación que robots.txt sirve principalmente para gestionar el acceso de crawlers y evitar sobrecarga, pero no es un mecanismo para mantener una página fuera de Google. Para proteger contenido sensible hacen falta medidas reales: autenticación, noindex cuando toca, control de servidor, permisos, WAF bien configurado o directamente no exponer lo que no debería ser público.

Y aquí se mezclan dos errores habituales. El primero: usar robots.txt como si fuera seguridad. Mala idea. El segundo: revisar solo robots.txt y olvidarse de que el WAF puede estar bloqueando igualmente. También mala idea. Puedes tener un robots.txt perfecto, limpísimo, digno de enmarcar, y aun así estar sirviendo un challenge a todo fetcher que venga desde una IP que a tu sistema le da mala espina.

Es como poner un cartel de “bienvenidos” detrás de una puerta blindada cerrada con tres candados. Muy educado. Muy inútil.

No todos los bots de IA son el mismo bicho

Otra trampa frecuente es hablar de “los bots de IA” como si todos hicieran lo mismo. No. Un crawler de búsqueda, un fetcher iniciado por usuario y un crawler asociado a entrenamiento no deberían meterse necesariamente en el mismo saco. Hacerlo queda cómodo en una conversación de bar, pero en una estrategia de visibilidad es bastante tosco.

OpenAI, por ejemplo, distingue varios agentes. OAI-SearchBot está vinculado a funciones de búsqueda de ChatGPT. ChatGPT-User aparece en solicitudes iniciadas por usuarios dentro de ChatGPT. GPTBot está asociado al rastreo que puede utilizarse para mejorar o entrenar modelos generativos. Son usos distintos. Y si los usos son distintos, la decisión también debería serlo.

OAI-SearchBot

Está relacionado con funciones de búsqueda de ChatGPT. Permitirlo puede tener sentido si quieres aumentar opciones de aparecer en respuestas con fuentes.

ChatGPT-User

Aparece en solicitudes iniciadas por usuarios dentro de ChatGPT. Bloquearlo puede impedir lecturas bajo demanda cuando alguien quiere consultar una URL concreta.

GPTBot

Está asociado al rastreo que puede utilizarse para mejorar o entrenar modelos. La decisión debería tomarse aparte, según política editorial, legal y de negocio.

La misma lógica se repite con otros sistemas. Perplexity diferencia entre PerplexityBot, orientado al rastreo de páginas para sus respuestas y resultados, y Perplexity-User, asociado a solicitudes iniciadas por usuarios. Anthropic separa ClaudeBot, Claude-User y Claude-SearchBot. Google, además de Googlebot, tiene fetchers iniciados por usuarios como Google-Agent, vinculados a agentes alojados en infraestructura de Google que navegan o actúan bajo petición del usuario.

La conclusión no es “abre todo”. La conclusión es “deja de tomar decisiones con un martillo”. Puedes querer visibilidad en respuestas de búsqueda y, al mismo tiempo, decidir otra cosa sobre entrenamiento. Puedes permitir ciertos fetchers en artículos públicos y bloquear rutas sensibles. Puedes proteger el CMS sin convertir cada post del blog en Fort Knox.

El problema aparece cuando alguien activa un botón genérico de “bloquear bots de IA” y se queda tan ancho, como quien compra un ambientador para arreglar una humedad. Igual has bloqueado basura. Perfecto. Pero igual también has bloqueado sistemas que podían ayudarte a ganar visibilidad. Y si no miras logs, eventos y respuestas HTTP, ni siquiera lo sabes. SEO por intuición. Qué podría salir mal.

Cloudflare, WAF y la maravillosa industria del botón que nadie entiende

Cloudflare tiene herramientas potentes para gestionar crawlers de IA. AI Crawl Control permite revisar actividad y tomar decisiones por crawler. También puede aplicar bloqueos mediante reglas WAF. Esto está bien. Es útil. Es necesario en muchos casos. Pero como cualquier herramienta potente, en manos de alguien con prisa puede terminar pareciendo una escena de bricolaje con motosierra.

Y ahora, para que la fiesta no decaiga, Cloudflare ha anunciado nuevos cambios en sus controles de bots de IA. Ya no se trata solo del viejo enfoque de “bloquear bots de IA” como si todos fueran el mismo señor con gabardina intentando llevarse tus contenidos en una bolsa del Mercadona. Cloudflare empieza a separar mejor el tráfico automatizado según lo que hace: Search, Agent y Training.

Esto es importante. Muy importante. Porque una cosa es un crawler que rastrea tu web para construir un índice de búsqueda y, en teoría, devolverte visibilidad. Otra cosa es un agente que entra en tiempo real porque una persona le ha pedido consultar tu página, resumirla, comparar información o hacer algo con ella. Y otra muy distinta es un bot que se lleva contenido para entrenar o afinar modelos. Meter esas tres cosas en el mismo saco es cómodo, sí, pero también es una forma bastante eficaz de pegarse un tiro en el pie mientras uno presume de haber “bloqueado la IA”.

Cloudflare llama a esas tres categorías Search, Agent y Training. Search sería el comportamiento de recopilar o indexar contenido para responder preguntas más adelante. Agent sería la actividad automatizada que actúa en tiempo real en nombre de una persona, como los fetchers de chat o los agentes que navegan con un navegador. Training sería el rastreo que toma contenido para entrenar o afinar modelos. Dicho en castellano de bar: buscar, actuar y entrenar no son lo mismo. Y si no son lo mismo, no deberías bloquearlos como si fueran el mismo bicho.

La parte delicada llega con los nuevos valores por defecto que Cloudflare activará el 15 de septiembre de 2026. Para los nuevos dominios que entren en Cloudflare, los bots clasificados como Training y Agent se bloquearán por defecto en páginas que muestren anuncios, mientras que Search seguirá permitido. La lógica de Cloudflare es que, si una página muestra anuncios, el propietario probablemente quiere que llegue una persona real, vea la página y genere valor para el negocio. En cambio, Search se mantiene como el comportamiento más parecido al viejo pacto de la web: te rastreo, te indexo y, con suerte, te devuelvo tráfico o algún tipo de valor.

Hasta aquí, todo suena razonable. El problema está en los crawlers de uso mixto. Cloudflare también ha dicho que los crawlers que combinen Search y Training se verán afectados por las reglas de bloqueo de Training. Es decir, si un bot viene con la mochila de búsqueda y la mochila de entrenamiento, y tú has decidido bloquear entrenamiento, puede llevarse el mamporro aunque también tenga una función de búsqueda.

Y aquí está la bomba SEO. No estamos hablando solo de bots raros con nombres sospechosos. Cloudflare menciona expresamente crawlers multiuso como Googlebot, Applebot y BingBot en el contexto de estos cambios. Esto no significa que todos los sitios vayan a perder visibilidad mañana ni que haya que salir corriendo por la calle gritando “nos han matado el SEO”. Significa algo más interesante y más incómodo: la configuración de seguridad empieza a tocar directamente decisiones de visibilidad, rastreo, IA, entrenamiento y modelo de negocio.

Durante años, bloquear bots parecía una decisión de higiene: fuera scrapers, fuera basura, fuera tráfico que no aporta nada. Ahora el asunto es más fino. Puedes querer que tu contenido aparezca en buscadores, en respuestas con fuentes o en sistemas que devuelvan tráfico. Puedes no querer que se use para entrenamiento. Puedes permitir agentes bajo demanda porque un usuario está intentando consultar tu página. Puedes bloquear automatizaciones que no te aportan nada. Todo eso son decisiones distintas. El problema aparece cuando las conviertes en un botón único de “bloquear IA” y te vas a tomar café tan tranquilo.

Cloudflare permite configurar cada categoría con más granularidad: bloquear en toda la zona, bloquear solo en páginas con anuncios o no bloquear. Esto es útil, pero también obliga a pensar. Porque si tienes una web monetizada con anuncios, una revista, un medio pequeño, un blog profesional, un portal de contenidos o una página que vive de tráfico orgánico, no puedes tratar igual una página editorial pública que un endpoint privado, ni un crawler de búsqueda que un extractor de contenido para entrenamiento.

La derivada práctica es clara: quien use Cloudflare tiene que revisar sus ajustes de IA antes de que los valores por defecto le hagan una jugarreta. Y aunque Cloudflare diga que no hay que hacer nada hoy, la lectura SEO es justo la contraria: no hay que entrar en pánico, pero sí conviene mirar qué configuración tienes, qué dominios están afectados, qué páginas muestran anuncios, qué bots están clasificados como Search, Agent o Training y qué pasa con los crawlers de uso mixto.

Porque esto tiene una gracia muy fina. Durante meses hemos tenido a medio sector gritando sobre llms.txt, Markdown, archivos mágicos y señales para modelos, mientras la capa de seguridad real está empezando a tomar decisiones sobre quién entra, quién no entra y con qué finalidad. Y esas decisiones pueden afectar a la visibilidad mucho más que poner otro archivo de texto en la raíz del dominio.

El detalle importante sigue siendo el mismo: las reglas tienen orden. Si una regla WAF anterior bloquea tráfico por país, por ASN, por patrón de bot, por nivel de amenaza o por cualquier condición amplia, da igual que en otra pantalla hayas permitido cierto crawler. El tráfico puede estar recibiendo el tortazo antes de llegar a la regla que tú creías que lo salvaba. Luego uno mira AI Crawl Control y piensa “pero si aquí está permitido”. Sí, claro. Permitido en el cementerio de peticiones.

Esto pasa más de lo que parece. Una web activa protección anti-bot porque recibe basura. Correcto. Luego sube el nivel de seguridad porque los intentos de login son constantes. Comprensible. Luego añade una regla para IPs sospechosas. Razonable. Luego activa un modo más agresivo porque “mejor prevenir”. Entendible. Luego Cloudflare cambia sus controles de IA, aparecen categorías nuevas, los crawlers mixtos entran en la ecuación y nadie revisa si el contenido público está siendo accesible desde fuera. Resultado: la web está segura, sí. También puede estar medio muda.

La seguridad no tiene la culpa. La culpa la tiene configurar seguridad como quien juega al buscaminas con los ojos vendados. Y ahora, con Search, Agent y Training sobre la mesa, jugar al buscaminas sale todavía más caro.

El invitado sorpresa: Imunify360 y el muro invisible de WebShield

Y aquí viene un invitado que tenemos que meter en la conversación porque no todo el mundo usa Cloudflare. Puedes tener una web sin Cloudflare, sin paneles llenos de rayitos naranjas y sin reglas WAF personalizadas creadas por ti, y aun así la IA puede seguir comiéndose un mamporro en la entrada. En muchos hostings compartidos o administrados aparece otro portero silencioso: Imunify360, especialmente a través de su módulo WebShield.

WebShield trabaja en una capa previa a tu web. No está dentro del artículo. No está en el editor del CMS. No está en el archivo de funciones. No está en el contenido. Está antes. Y eso es importante, porque si el bloqueo ocurre ahí, da igual que tu HTML esté precioso, que tu plantilla sea limpia, que el sitemap esté correcto o que le hayas puesto al llms.txt una poesía épica en alejandrinos.

La documentación de Imunify360 explica que la Greylist y el Anti-Bot Challenge de WebShield sirven para distinguir tráfico humano de tráfico automatizado y proteger frente a spam y abuso. Cuando una IP cae en esa greylist, WebShield puede presentar una pantalla de verificación basada en HTML, el famoso splashscreen. CloudLinux lo dice todavía más claro: un bot o crawler simple puede no superar ese reto y quedarse viendo la pantalla con el texto “Please wait while your request is being verified”.

Traducido al idioma de la calle: si un crawler llega desde una IP de centro de datos, sin cookies, sin navegador humano al uso y con un user-agent que huele a máquina desde la otra punta del rack, WebShield puede ponerse nervioso y plantarle delante la pantalla gris. Para un usuario humano, a veces pasa desapercibido. Para un crawler que viene a leer contenido, puede ser el muro de Berlín con spinner.

Y aquí viene el drama técnico: esto no lo arreglas tocando el código de tu web.

Da igual que metas directivas en .htaccess, que llores en el archivo de funciones de WordPress, que cambies un módulo en Joomla o que pongas velas al santo del markup. Si el bloqueo de Imunify360 ocurre antes de que la petición llegue a tu web, tu CMS ni se entera. Es como intentar cambiar la decoración del salón cuando el problema está en que el portero no deja pasar al invitado al edificio.

Por eso este punto es tan importante para SEO técnico, IA y citaciones. Si miras solo Cloudflare, puedes no encontrar nada. Si miras solo robots.txt, puedes pensar que todo está correcto. Si miras solo Search Console, puedes quedarte con una parte de la película. Pero si el hosting tiene Imunify360 y WebShield está sirviendo challenges a ciertos bots útiles, la explicación puede estar justo ahí: en una capa de seguridad que tú no ves desde el editor de la web.

Markup, JSON-LD y el síndrome del mantel bordado

Los datos estructurados tienen su sitio. Ayudan a Google a entender mejor ciertos elementos de una página y pueden habilitar resultados enriquecidos en algunos contextos. Bien usados, forman parte de una web técnicamente cuidada. En Local Rank 942 ya he tratado este tema en Google retira las FAQ con JSON-LD y mueve otra vez el tablero del SEO, precisamente porque conviene no convertir el marcado en una religión.

El problema es cuando el markup se vende como si fuera la solución universal. Hay páginas con datos estructurados impecables que no responden a la intención de búsqueda. Hay páginas con schema metido a paladas que no tienen autoridad. Hay webs con JSON-LD perfectamente formateado y contenido más fino que una loncha de jamón de sobre. Y ahora también tenemos el caso estrella: páginas con ganas de ser citadas por IA que, antes de servir el texto, le ponen al crawler una prueba anti-bot.

El marcado puede ayudar a explicar. Pero no puede resucitar una página inaccesible. Puedes envolver el contenido con todo el JSON-LD del mundo. Si el sistema que intenta leerlo recibe un challenge, le estás dando a la IA un mantel bordado sobre una mesa que no existe.

El llms.txt no va a atravesar tu firewall montado en unicornio

El llms.txt tiene una ventaja comercial evidente: suena nuevo, técnico y lo bastante misterioso como para venderlo en un paquete. Es el tipo de cosa que permite escribir “optimización para modelos de lenguaje” en una propuesta y quedarse mirando al cliente con cara de haber abierto una puerta dimensional.

Pero hay que colocar cada cosa en su sitio. Un archivo llms.txt puede servir como índice orientativo o como recurso para ciertos agentes si deciden usarlo. Puede tener sentido en algunos proyectos como documentación adicional. Puede ser una pieza más. Lo que no puede es compensar una arquitectura rota, una web lenta, un contenido mediocre, una ausencia de autoridad, un sitemap descuidado, un WAF que bloquea la lectura del contenido principal o un WebShield sirviendo una pantalla gris antes de que tu web pueda decir ni buenos días.

Es decir: si tu servidor responde al crawler con “verificando solicitud”, el llms.txt no va a salir volando con capa roja para rescatar el artículo. No es Superman. Es un archivo de texto. Bajemos un poco el volumen de la charanga.

Y aquí está el punto de cachondeo serio: hay webs que se están planteando cómo resumir sus mejores contenidos para que los entienda la IA, mientras no han comprobado si la IA puede abrir esos contenidos. Esto ya no es poner el carro delante de los bueyes. Es comprarle llantas al carro, grabarle el logo, hacerle una landing y descubrir después que los bueyes están encerrados en otro pueblo.

Dónde se rompe la cadena de la cita

Para que una página acabe citada, la cadena debería parecerse a esto: el sistema descubre la URL, solicita la página, recibe el contenido real, procesa el HTML, entiende el texto, lo compara con otras fuentes y decide si merece aparecer en una respuesta. Cada eslabón puede fallar. Pero cuando falla el acceso, no hay mucho más que discutir.

Si el crawler recibe un 403, la cadena se rompe. Si recibe un challenge que no puede resolver, se rompe. Si recibe un captcha, se rompe. Si se topa con un rate limit torpe, se debilita. Si los recursos importantes están bloqueados, se complica. Si el HTML que recibe no contiene el contenido principal, pierde valor. Si el sitemap está mal o no se actualiza, el descubrimiento empeora. Si robots.txt bloquea rutas públicas, el rastreo se entorpece. Si una regla WAF trata todos los bots como invasores bárbaros, la visibilidad se resiente. Y si Imunify360 sirve una pantalla de verificación antes de entregar la página, el CMS puede estar perfecto y el crawler seguir sin leer nada.

Y luego llega la reunión de seguimiento: “No nos cita ChatGPT”. Normal. Tu web ha organizado una recepción para crawlers con la hospitalidad de Mordor.

Cómo saber si tienes un problema

Hay señales bastante claras. Una herramienta externa intenta leer una URL y solo ve una verificación. Un auditor online devuelve 403 donde tu navegador ve 200. Un crawler de prueba no puede recuperar el HTML. Los logs muestran bloqueos a user-agents legítimos. Cloudflare enseña eventos de seguridad sobre rutas públicas del blog. Imunify360 muestra eventos, greylist o challenges asociados a peticiones que iban a contenidos públicos. Bing Webmaster Tools o Search Console muestran problemas de rastreo. Los sitemaps se procesan, pero ciertas páginas no se recuperan bien. Los previsualizadores sociales fallan. Las herramientas de análisis ven una cosa y el navegador otra.

Ninguna señal aislada implica automáticamente desastre. Pero juntas forman una imagen bastante clara: la web está segmentando el tráfico de una manera que quizá no encaja con tu estrategia editorial.

La prueba casera más simple es comparar. Abre una URL en navegador normal. Luego prueba desde una herramienta externa sin cookies. Después revisa código de respuesta. Después mira cabeceras. Después comprueba cómo la ve Google. Después revisa eventos del WAF, de Cloudflare si lo usas y de Imunify360 si tu hosting lo tiene activo. Si cada entorno recibe una versión distinta, no pasa nada; puede ser normal. Pero hay que saberlo. Lo peligroso es no tener ni idea y seguir hablando de visibilidad en IA como si todo dependiera de escribir “respuesta clara” al principio de cada artículo.

La auditoría imprescindible antes de vender humo generativo

Antes de preguntar si tu web necesita un llms.txt, deberías hacer una auditoría de accesibilidad real. No una auditoría de “la página carga en mi navegador”. Una auditoría en condiciones. Con pruebas desde fuera, sin cookies, con distintos user-agents, revisando respuestas HTTP, logs, Search Console, eventos del WAF, eventos de Imunify360 si aplica y comportamiento de herramientas externas.

Primero, comprobar qué ve Googlebot. Search Console sigue siendo una pieza básica. Ya lo he contado en Google Search Console: clics, impresiones, CTR y trucos prácticos: no es un oráculo, pero deja migas suficientes. Para este caso interesa revisar inspección de URLs, cobertura, indexación, páginas importantes, sitemaps y si Google está recuperando el contenido real.

Después, revisar robots.txt. No para venerarlo, sino para comprobar que no bloquea rutas públicas del blog, recursos necesarios, sitemaps o crawlers útiles. También hay que confirmar que el sitemap está actualizado y enlazado correctamente.

Luego viene la zona técnica de verdad: cabeceras HTTP, códigos 200, 301, 401, 403, 429 y 503, cabeceras de Cloudflare, cf-ray, cf-cache-status, reglas WAF, Managed Challenge, Block AI Bots, AI Crawl Control, Super Bot Fight Mode, ModSecurity, Imunify360, WebShield, LiteSpeed, plugins de seguridad, bloqueos geográficos y límites de frecuencia.

Y, sobre todo, logs. Los logs son el sitio donde la fantasía se acaba y empiezan los hechos. ¿Entró ese user-agent? ¿Qué código recibió? ¿Qué ruta pidió? ¿Cuántas veces? ¿Desde qué IP? ¿Lo bloqueó el servidor, Cloudflare, Imunify360, el plugin, el hosting o la madre que parió al firewall? Sin logs, estás haciendo SEO con una ouija.

Cómo arreglarlo sin abrir la puerta a todos los bichos de internet

Vale. Ya hemos hecho la parte divertida: señalar el absurdo de escribir para que la IA te cite mientras tu firewall recibe a los crawlers con una porra extensible. Ahora toca la parte menos vistosa, pero más útil: cómo se corrige esto sin convertir la web en una barra libre para scrapers, bots basura y fauna digital de dudosa higiene.

La solución no es desactivar Cloudflare, apagar el WAF, quitar Imunify360, desactivar WebShield a lo bruto y dejar el CMS en mitad de internet con una pancarta de “pasen y vean”. Eso sería una animalada. La solución es separar. Contenido público, por un lado. Zonas sensibles, por otro. Crawlers útiles, por un lado. Bots basura, por otro. Rastreo para visibilidad, por un lado. Entrenamiento de modelos, por otro. Parece muy básico, pero la mitad de los desastres técnicos empiezan porque alguien decide todo con un único botón.

1. Comprueba primero qué está viendo cada sistema

Antes de tocar nada, hay que diagnosticar. No se arregla una web a base de intuición, igual que no se arregla una fuga de agua rezando al fregadero. Lo primero es probar una URL pública importante, por ejemplo un artículo del blog que quieras que pueda ser citado.

Abre la página como usuario normal. Luego pruébala desde una herramienta externa sin sesión iniciada, sin cookies y sin pasar por tu navegador habitual. Después revisa la URL en Google Search Console con la inspección de URL. Si puedes, comprueba también qué código HTTP devuelve desde fuera: 200, 301, 401, 403, 429, 503 o cualquier otra alegría. Y luego mira los logs del servidor o los eventos de seguridad del WAF.

La pregunta no es “¿yo veo la página?”. La pregunta es: cuando la solicita un sistema externo, ¿recibe el artículo real o recibe un challenge, un captcha, una pantalla de verificación o un 403?

Si tú ves el contenido y una herramienta externa ve “Please wait while your request is being verified…”, ya tienes una pista bastante clara. La web no está rota para humanos. Está filtrando tráfico automatizado. Eso puede estar bien o mal según a quién esté dejando fuera. Si deja fuera basura, perfecto. Si deja fuera crawlers útiles, tienes un problema.

2. Revisa robots.txt, pero no te quedes ahí mirando el archivo como si fuera un santo

El siguiente paso es revisar robots.txt. Tiene que estar en la raíz del dominio, normalmente en una URL tipo https://www.tudominio.com/robots.txt. Ahí conviene comprobar que no se están bloqueando rutas públicas del blog, recursos necesarios, el sitemap o crawlers que te interesan.

Un punto de partida muy simple para una web que quiere visibilidad en buscadores e IA podría ser este:

User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

Sitemap: https://www.tudominio.com/sitemap.xml

Esto no significa que debas copiarlo sin pensar. Cada web tiene su estructura. Un WordPress no es un Joomla. Un ecommerce no es un blog. Una intranet no es una web corporativa. Pero la lógica es clara: si tienes contenidos públicos que quieres que puedan ser descubiertos, leídos y utilizados como fuente, no bloquees por accidente a los sistemas que necesitan rastrearlos o recuperarlos.

También hay que entender una cosa: no todos los fetchers se controlan bien desde robots.txt. Algunos accesos iniciados por usuarios, como ChatGPT-User, Perplexity-User, Claude-User o Google-Agent, pueden comportarse más como una solicitud bajo demanda que como un crawler automático clásico. Por eso no basta con mirar robots.txt. Hay que mirar también WAF, Imunify360, logs, rangos oficiales y respuesta HTTP real.

La decisión sobre GPTBot, ClaudeBot o controles como Google-Extended debe separarse. Puedes querer aparecer en respuestas de búsqueda y, al mismo tiempo, decidir otra cosa sobre el rastreo asociado a entrenamiento de modelos. No es la misma conversación.

# Si decides permitir rastreo asociado a entrenamiento:
User-agent: GPTBot
Allow: /

# Si decides no permitirlo:
User-agent: GPTBot
Disallow: /

# Si decides no permitir entrenamiento en Claude:
User-agent: ClaudeBot
Disallow: /

# Control de uso por Google para Gemini/Vertex, sin afectar a Google Search:
User-agent: Google-Extended
Disallow: /

La clave es no meter todos los bots de IA en el mismo saco. OAI-SearchBot, ChatGPT-User y GPTBot no cumplen exactamente la misma función. PerplexityBot y Perplexity-User tampoco. ClaudeBot, Claude-User y Claude-SearchBot tampoco. Si los bloqueas todos con la misma brocha gorda, luego no te sorprendas si algunas puertas de visibilidad se quedan cerradas.

Y ahora viene la advertencia importante: aunque el robots.txt esté bien, eso no garantiza que el contenido sea accesible. robots.txt es una declaración de preferencias para crawlers cooperativos. No es una cerradura. Si Cloudflare, Imunify360, ModSecurity, LiteSpeed, el hosting o un plugin de seguridad están bloqueando antes de servir la página, el archivo puede estar precioso y no servirte de nada para este problema.

3. Mira Cloudflare, WAF o la capa anti-bot que esté al mando

Si la web usa Cloudflare, el siguiente sitio donde mirar es la zona de seguridad. Hay que revisar eventos del WAF, reglas personalizadas, Bot Fight Mode o Super Bot Fight Mode si está disponible, Managed Challenge, rate limits, reglas por país, bloqueos por ASN y cualquier configuración que pueda estar afectando a rutas públicas.

Pero desde los cambios anunciados por Cloudflare, hay que mirar también los controles específicos de tráfico de IA. Ya no basta con comprobar si está activo o no el viejo botón de “Block AI bots”. Ahora conviene revisar cómo está configurada cada categoría: Search, Agent y Training.

Search es la categoría que más se parece al rastreo de búsqueda tradicional: crawlers que recopilan o indexan tu contenido para responder preguntas más adelante. Si quieres visibilidad, tráfico, citaciones o presencia en respuestas con fuentes, esta categoría suele ser la que menos sentido tiene bloquear a ciegas.

Agent cubre actividad automatizada que actúa en tiempo real en nombre de una persona. Aquí entran fetchers de chat, agentes que navegan o sistemas que visitan una página porque un usuario ha pedido algo concreto. Bloquear Agent puede tener sentido en algunas zonas sensibles, pero bloquearlo en contenidos públicos puede impedir lecturas bajo demanda.

Training es la parte que más propietarios quieren controlar: crawlers que toman contenido para entrenar o afinar modelos. Aquí la decisión es otra. Puedes querer visibilidad en Search y, al mismo tiempo, bloquear Training. Eso es razonable. Lo que no es razonable es no mirar qué bots combinan varios usos y qué regla se les aplica.

La novedad incómoda es esa: los crawlers de uso mixto. Si un crawler combina Search y Training, y tu configuración bloquea Training, puede acabar bloqueado aunque también tenga una función de Search. Cloudflare ha indicado que este criterio afectará a crawlers multiuso y que se aplicarán las reglas más restrictivas cuando corresponda. Traducido: si viene con doble gorra y una de las gorras está prohibida, puede comerse el portazo entero.

En esa revisión hay que mirar, como mínimo, estas cosas: eventos de seguridad sobre URLs públicas, reglas WAF demasiado amplias, AI Crawl Control, configuración de Search, Agent y Training, páginas con anuncios, crawlers de uso mixto, límites de frecuencia y orden de reglas.

Ojo con las páginas con anuncios. Si el sitio muestra publicidad, revisa qué páginas detecta Cloudflare como páginas con anuncios y qué comportamiento aplica ahí. Desde el 15 de septiembre de 2026, los nuevos dominios que entren en Cloudflare tendrán Training y Agent bloqueados por defecto en esas páginas, mientras Search seguirá permitido. Eso puede ser perfecto para algunos proyectos y un susto curioso para otros.

Y ojo también con los crawlers de uso mixto. Si un bot combina búsqueda y entrenamiento, bloquear Training puede arrastrar también parte del rastreo que pensabas conservar para visibilidad. Esto no significa que tengas que permitir entrenamiento si no quieres. Significa que tienes que saber qué estás bloqueando realmente, porque una cosa es proteger contenido y otra pegarte un tiro en la visibilidad mientras aplaudes porque “hemos bloqueado la IA”.

La idea no es permitir todo lo que diga “bot”. La idea es saber qué estás bloqueando. Si quieres bloquear entrenamiento, perfecto. Si quieres bloquear agentes en páginas con anuncios, puede tener sentido. Si quieres mantener Search abierto porque te interesa aparecer y recibir tráfico, también. Pero no confundas control con cerrojazo indiscriminado.

Y aquí conviene hacer una comprobación muy concreta: prueba varias URLs públicas importantes, mira qué reciben desde fuera y cruza eso con los eventos de Cloudflare. Si una página pública que quieres posicionar o que quieres que pueda ser citada está sirviendo un challenge, un 403 o un bloqueo por clasificación de IA, no estás ante una hipótesis filosófica. Estás ante una puerta cerrada.

Si el artículo del blog está recibiendo el mismo tratamiento que el login del administrador, algo está mal planteado.

4. Si el problema es Imunify360, no busques el botón dentro de tu Joomla o WordPress

Si el hosting usa Imunify360, hay que mirar en otro sitio. En muchos entornos compartidos o administrados, tú no tienes acceso real a la configuración global de WebShield. Puedes entrar en cPanel, puedes tocar tu CMS, puedes revisar .htaccess, pero la decisión de servir una pantalla de verificación puede estar ocurriendo antes, en el firewall del servidor.

Lo primero es pedir al hosting que revise si tu dominio está siendo afectado por WebShield, Greylist o Anti-Bot Challenge en peticiones a URLs públicas. No pidas que apaguen todo. Pide que revisen eventos concretos, que comprueben los logs y que creen una excepción razonable para contenido público si procede.

En algunos casos, el administrador puede hacer whitelist del dominio para evitar ciertos checks de Imunify360. En otros, puede mover IPs fuera de Greylist o crear excepciones más finas. La solución exacta depende del panel, del tipo de hosting, del nivel de acceso y de la política de seguridad del proveedor. Lo importante es entender que, si WebShield está sirviendo el challenge antes de entregar la página, tocar el contenido del artículo no arregla nada.

5. Crea excepciones por ruta, no una amnistía general para robots

La forma sensata de resolverlo es trabajar por rutas. No tiene sentido abrir toda la web. Tampoco tiene sentido blindar todo por igual. Las rutas públicas deberían tener una política distinta a las rutas sensibles.

Por ejemplo, en una web normal, las rutas de blog deberían permitir acceso a crawlers legítimos y evitar challenges agresivos si el contenido es público. Las páginas de servicios también deberían permitir rastreo y recuperación si son páginas comerciales abiertas. En cambio, rutas como /wp-admin/, /administrator/, formularios, áreas privadas y endpoints sensibles deben protegerse con reglas fuertes, autenticación, limitación de intentos y restricciones adicionales.

Este es el punto que muchos paneles de seguridad no explican bien. No se trata de elegir entre “web segura” y “web visible”. Se puede tener una web segura y, al mismo tiempo, permitir que los contenidos públicos sean legibles. Lo que no se puede es aplicar la misma regla a todo y esperar que no haya daños colaterales.

6. No permitas por user-agent sin verificar nada

Cuidado con la chapuza contraria: crear una regla que permita todo lo que diga llamarse Googlebot, Bingbot, ChatGPT o cualquier nombre bonito. Los user-agents se pueden falsear. Un bot basura puede ponerse una camiseta que diga “soy Google” y no por eso hay que invitarlo a cenar.

Para crawlers importantes, conviene usar los mecanismos de verificación disponibles. En el caso de Google, existe documentación específica para verificar solicitudes de sus crawlers y fetchers. OpenAI, Perplexity y otros publican rangos o endpoints de IP para determinados agentes. En otros casos, hay documentación oficial, identificadores o criterios que permiten tomar decisiones con menos fe y más datos.

Si estás en Cloudflare con funciones avanzadas, puede que tengas acceso a campos de bot management más precisos. Si estás en un hosting más simple, quizá tengas que trabajar con logs, user-agents, rutas, frecuencia de peticiones y reglas menos finas. Pero incluso ahí hay una diferencia enorme entre configurar con criterio y activar “modo paranoico” porque sonaba seguro.

7. Prueba después de cada cambio

Esto es importante: no cambies cinco cosas a la vez y luego intentes adivinar cuál arregló o rompió algo. Cambia una regla, prueba. Ajusta robots.txt, prueba. Modifica una excepción en WAF, prueba. Pide al hosting una excepción en Imunify360, prueba. Desactiva un challenge en una ruta pública, prueba. Revisa logs, prueba otra vez.

Después de cada cambio, comprueba si la página carga correctamente para usuarios humanos, si Google puede recuperar el contenido principal desde Search Console, si una petición externa sin cookies devuelve contenido real y no una pantalla de verificación, si los crawlers útiles reciben códigos 200 en contenidos públicos y si los eventos del WAF o de Imunify360 dejan de mostrar bloqueos o challenges sobre las rutas que quieres posicionar o convertir en fuente.

El objetivo no es que todo el tráfico pase. El objetivo es que el tráfico útil pueda leer lo que debe leer, y que el tráfico sospechoso siga chocándose contra la pared donde debe chocarse.

8. Documenta la decisión, porque dentro de seis meses nadie se acordará

Cuando se ajusta una política de crawlers, hay que dejarlo documentado. Qué se permite, qué se bloquea, qué rutas tienen excepciones, qué bots se han revisado, qué reglas WAF se han tocado y por qué. Parece burocracia, pero evita el clásico desastre de “alguien activó una opción de seguridad y ahora no sabemos qué pasó”.

La documentación mínima debería incluir la fecha de revisión del robots.txt, los crawlers permitidos o bloqueados, el sitemap declarado, las reglas WAF que afectan a rutas públicas, las excepciones creadas, la decisión sobre OAI-SearchBot, ChatGPT-User, GPTBot, PerplexityBot, Perplexity-User, Claude-SearchBot, Claude-User, ClaudeBot, Google-Agent y otros agentes relevantes, la configuración Search/Agent/Training si usas Cloudflare, las zonas sensibles que siguen protegidas y las pruebas realizadas con sus códigos de respuesta.

Esto no tiene glamour, pero ahorra disgustos. La web no debería depender de que una persona recuerde de memoria qué botón tocó en Cloudflare o qué ticket mandó al hosting una tarde de martes.

Resumen práctico

Si una web quiere ser citada por sistemas de IA, el arreglo no empieza por crear otro archivo de moda. Empieza por comprobar si los contenidos públicos se pueden recuperar. Primero diagnóstico. Después robots.txt. Después WAF. Después Cloudflare Search/Agent/Training si aplica. Después Imunify360 si aplica. Después excepciones por ruta. Después verificación. Después pruebas. Y siempre separando lo público de lo sensible.

Dicho de forma menos elegante: no le pongas al artículo del blog el mismo chaleco antibalas que al panel de administración. El primero quieres que lo lean. El segundo quieres que no lo toque ni Dios.

El error de verificar solo Googlebot

Google sigue siendo central, claro. Pero pensar solo en Googlebot ya se queda corto. La visibilidad actual tiene más puertas. Bing importa porque alimenta parte del ecosistema de búsqueda con IA. ChatGPT Search tiene sus propios mecanismos. Perplexity, Claude, Gemini, herramientas SEO, previsualizadores sociales y agentes bajo demanda pueden entrar de formas distintas.

Esto no significa que tengas que perseguir cada crawler nuevo como si estuvieras completando una Pokédex. Significa que necesitas una política razonable y una forma de comprobar accesos. Qué bots permites. Qué bots bloqueas. Qué rutas proteges. Qué reglas aplicas. Qué logs miras. Qué cambios documentas. Qué pasa cuando activas una opción nueva en Cloudflare, en Imunify360, en el hosting o en un plugin de seguridad.

Porque muchas veces el problema no viene de una gran decisión estratégica. Viene de un clic alegre en un panel. “Activar protección avanzada”. “Bloquear bots de IA”. “Modo agresivo”. “Challenge automático”. “Seguridad máxima”. Todo suena muy bien hasta que descubres que seguridad máxima también significa visibilidad mínima.

La parte empresarial: bloquear sin distinguir también cuesta dinero

Este asunto no es solo técnico. Es de negocio. Si publicas contenido para atraer clientes, reforzar autoridad, alimentar búsquedas informativas, aparecer en respuestas generativas o sostener tu marca, cada bloqueo mal aplicado puede tener coste. No siempre lo verás como una caída clara en Analytics. No siempre aparecerá como un error evidente. Puede ser más silencioso: menos rastreo útil, menos recuperación, menos comparaciones, menos citaciones, menos oportunidades.

En el artículo sobre auditoría GEO/AEO para negocios locales ya señalaba que la presencia en respuestas de IA no sustituye al SEO clásico, sino que amplía el mapa. Pues bien, este es uno de los puntos donde esa ampliación se vuelve técnica. No basta con preguntarse si la IA recomienda a tu competencia. También hay que preguntarse si tú le estás dejando leer tu web.

Y aquí aparece una paradoja bastante hermosa en su estupidez: negocios que pagan por contenidos, consultoría, diseño web, estrategia, SEO y análisis de visibilidad, pero tienen una configuración de seguridad que puede estar bloqueando justo la lectura de esos contenidos. Es como contratar un escaparate nuevo y dejar la persiana bajada. Muy brillante todo, pero desde la calle se ve regular.

En 3 cosas que debería tener tu web si quieres aparecer en Google ya defendía una idea básica: tener web no garantiza nada. Ahora hay que añadir otra capa: tener contenido publicado tampoco garantiza que las máquinas útiles puedan leerlo. Y si no pueden leerlo, puedes olvidarte de muchas alegrías generativas.

Qué es lo que no hay que hacer

No hay que desactivar toda la seguridad porque “queremos que nos lea la IA”. Eso sería una estupidez con luces de neón. Tampoco hay que permitir cualquier user-agent que diga ser Google, OpenAI o el arcángel San Gabriel del rastreo. Los user-agents se pueden falsear. Los bots importantes tienen métodos de verificación, documentación y políticas. Si la web tiene tráfico problemático, hay que protegerla.

Tampoco hay que convertir llms.txt en el nuevo tótem. Si lo quieres probar, se prueba. Si aporta claridad documental, se valora. Si ayuda a ciertos agentes, perfecto. Pero no lo vendas como sustituto de rastreo, indexación, arquitectura, contenido útil, autoridad y accesibilidad técnica. El archivo de moda no arregla una web que devuelve un challenge antes de servir el artículo.

Y no hay que pensar que porque Google pueda leer algo, todos los demás sistemas lo leerán igual. Cada agente tiene comportamiento, infraestructura y tolerancia distinta. La visibilidad se está fragmentando. El SEO técnico tiene que ampliar el radar.

Qué es lo que sí hay que hacer

Hay que revisar la web como sistema. Contenido, rastreo, seguridad, servidor, CMS, CDN, WAF, Imunify360 si existe, sitemap, robots.txt, logs y herramientas de medición. Todo junto. No como compartimentos estancos donde el redactor escribe, el técnico bloquea, el SEO mira Search Console y el dueño pregunta por qué no hay citas.

Hay que decidir qué rutas deben estar abiertas a crawlers legítimos y cuáles deben estar blindadas. Hay que comprobar que los artículos públicos devuelven contenido real. Hay que verificar que Googlebot y Bingbot acceden correctamente. Hay que valorar qué hacer con OAI-SearchBot, ChatGPT-User, GPTBot, PerplexityBot, Perplexity-User, Claude-SearchBot, Claude-User, ClaudeBot, Google-Agent y compañía de forma separada. Hay que mirar si Cloudflare, Imunify360 o el hosting están aplicando reglas demasiado agresivas. Hay que documentar cambios. Hay que probar desde fuera.

Y hay que mantener una idea simple: una web que quiere ser fuente tiene que comportarse como fuente. No como una cámara acorazada con un PDF dentro.

Resumiendo: antes de pedir citas, deja que te lean, carajo

La visibilidad en IA no es una cuestión de escribir más. Tampoco depende solo de estructurar mejor. Ni de poner schema, ni de crear un llms.txt, ni de convertir cada artículo en una lista de preguntas frecuentes con olor a plantilla. Todo eso puede tener su sitio, pero llega después de una condición básica: el contenido debe poder recuperarse.

Si quieres que una IA te cite, primero asegúrate de que puede leer tu web. Parece una obviedad absurda, pero muchas webs están fallando justo ahí. Publican para humanos, optimizan para buscadores, sueñan con respuestas generativas y, cuando llega un crawler que les interesa que visite su página, le enseñan un cartel de verificación, un captcha, un 403 o una puerta cerrada.

La seguridad es muy importante. Cada vez más. Bloquear basura es imprescindible. Proteger administración, formularios y zonas sensibles es vital. Pero bloquear sin distinguir también tiene coste. Y en una estrategia de contenidos, ese coste puede ser alto: menos rastreo útil, menos recuperación, menos opciones de citación y menos presencia en un entorno donde cada vez más usuarios empiezan preguntando a sistemas que resumen, comparan y recomiendan.

El SEO clásico preguntaba si Google podía leer la página. La búsqueda con IA obliga a ampliar la pregunta: ¿pueden leerla también los sistemas que recuperan fuentes para construir respuestas?

Si la respuesta es no, deja el markup un momento, baja del púlpito del llms.txt y mira el firewall. O Cloudflare. O Imunify360. O el WebShield del hosting haciendo de portero con complejo de antidisturbios. Igual el futuro de tu visibilidad no está en otro archivo mágico, sino en quitarle al portero la orden de echar a cualquiera que venga con pinta de máquina.

Y si todo esto es un galimatías para ti y necesitas una mano, pues escríbeme y algo se podrá hacer.

Me desconecto por hoy. Nos vemos en el ciberespacio.

Fuentes oficiales consultadas

• OpenAI: Overview of OpenAI Crawlers
• Perplexity: Perplexity Crawlers
• Anthropic: Claude crawlers and user agents
• Google Search Central: AI optimization guide
• Google Search Central: Introduction to robots.txt
• Google: common crawlers
• Google: user-triggered fetchers and Google-Agent
• Google: verify requests from Google crawlers and fetchers
• Google Search Central: structured data markup
• Cloudflare: Your site, your rules: new AI traffic options for all customers
• Cloudflare Changelog: New options to manage AI traffic
• Cloudflare: Manage AI crawlers
• Cloudflare: AI Crawl Control with WAF
• Cloudflare: Block AI Bots
• Imunify360: WebShield, Greylist and Anti-Bot Challenge
• CloudLinux: How Imunify Anti-Bot Protection identifies suspicious IPs
• cPanel: whitelist a domain to disable CAPTCHA check in Imunify360