Cómo saber de verdad si los bots de IA pueden acceder a tu web

Antes, Google era el principal medio por el cual los usuarios accedían a tu web en la mayoría de los casos. Ahora, también hay que tener muy en cuenta las diferentes IAs: ChatGPT, Gemini, Perplexity o Claude.

Cada una de estas plataformas tiene varios bots que van rastreando webs para construir sus propios índices, porque se lo pide un usuario, para entrenar sus modelos… La pregunta aquí es: ¿podrán hacerlo sin problemas o se encontrarán algún bloqueo por el camino?

Los ejemplos de Windguru y el “falso bloqueo” por robots.txt

Antes de ir a la documentación oficial, quiero exponer dos casos en los que la IA no ha podido leer el contenido de una página web con los bots de petición de usuario por diferentes motivos:

Windguru y su mala relación con la IA

En mi artículo sobre el futuro del SEO ya hablé sobre la dificultad de la IA para acceder a Windguru. Es un claro ejemplo de que, incluso especificando la fuente, la propia IA decide darte una respuesta citando fuentes diferentes si no puede acceder a la que le has pedido.

ChatGPT dice que el contenido de Windguru se queda “Loading”. Esto se debe a que no ha ejecutado el JavaScript y no ha podido ver el contenido. Si deshabilitamos el JavaScript con la consola de Chrome, podemos hacernos una idea de lo que ha visto ChatGPT.

Robots.txt me bloquea el acceso… pero la realidad es otra

Antes de analizar una página web le pedí a Claude que me dijera de qué iba el negocio. Su respuesta: no puede acceder porque lo bloquea el robots.txt.

Sin embargo, tras comprobar el robots.txt y ver las directrices del propio documento, no había bloqueo ninguno.

User-agent: *
Disallow: /wp-content/uploads/wpo-plugins-tables-list.json
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: */?s=
Allow: /wp-admin/admin-ajax.php

Sitemap: https://silveiratech.pt/sitemap_index.xml

Si el problema no era el robots.txt, ¿qué estaba causando el bloqueo? En esta guía vamos a ver algunos de los bots más populares, las formas de controlar su acceso según las fuentes oficiales de cada empresa, y cómo comprobar si pueden acceder y leer el contenido de una página web.

Los bots que analizaremos a continuación

Cada plataforma de IA tiene varios bots con funciones distintas. Tener claro para qué sirven nos ayuda a tomar mejores decisiones sobre la posible necesidad de bloquearlos o no.

Hay tres tipos:

• Bots que forman el índice: guardan la URL con su contenido en una base de datos. La IA usa este índice para responder a los usuarios y citar webs que podrían ser de utilidad.
• Bots de entrenamiento: el contenido se usa para construir el modelo. Queda dentro de él, sin enlaces ni fuentes, y no se actualiza hasta el siguiente entrenamiento.
• Bots de petición del usuario: entran solo cuando alguien le pasa una URL a la IA y le pide que la lea. No rastrean nada por su cuenta.

No todas las empresas tienen los tres. OpenAI y Anthropic sí. Perplexity solo tiene índice y petición del usuario: dice expresamente que no usa lo que rastrea para entrenar sus modelos (se abre en una pestaña nueva). Google y Apple usan un mismo bot para varias funciones, con un mecanismo aparte para el entrenamiento.

Google-Extended (se abre en una pestaña nueva) y Applebot-Extended (se abre en una pestaña nueva) son la forma de decidir si ese entrenamiento ocurre. Google-Extended, además, decide si Gemini usa tu contenido al responder.

Los métodos para controlar la accesibilidad de estos bots

Cada web es diferente. Puede que para proteger a tus servidores, tener un mayor control sobre cómo se usa tu contenido o [inserta aquí el motivo que sea] quieras bloquear alguno de estos bots de IA.

Sea cual sea el motivo, vamos a desglosar los distintos métodos por los que puedes bloquear a estos bots de menor a mayor contundencia:

Robots.txt

Un archivo que ya conocemos desde hace tiempo en el mundo del SEO. Su uso está tan extendido que las propias empresas de IA han aceptado este estándar para que los dueños de las webs puedan controlar la accesibilidad de estos bots a sus webs.

OpenAI y Perplexity avisan de que un cambio en robots.txt puede tardar unas 24 horas en aplicarse.

Claude-User es el único bot de petición del usuario que, según su empresa, respeta robots.txt. Por eso la excusa del principio de esta guía era creíble aunque no resultara ser el caso.

Los grupos no se suman, se sustituyen

Un error que se puede cometer en un robots.txt es que si tienes reglas generales en User-agent: * y luego le das grupo propio a otro bot, ese nuevo bot deja de obedecer todo lo que hay en * y hace caso de sus directrices particulares.

En este robots.txt, por ejemplo, le abres a GPTBot las carpetas de buscar y el carrito que tenías cerradas para todos:

User-agent: *
Disallow: /buscar/
Disallow: /carrito/

User-agent: GPTBot
Allow: /

Si le das grupo propio a un bot, repite las reglas que quieras mantener (se abre en una pestaña nueva). Y si no vas a tomar una decisión distinta sobre su comportamiento en la web, con las reglas generales ya está cubierto.

¿Por qué usar robots.txt?

Robots.txt no bloquea: da unas directrices y cada bot decide si las obedece. Un bot que no quiera hacerte caso podría ignorarlo. Aun así, es un método que hay que tener muy en cuenta por estos motivos:

• Distingue por propósito. Puedes cerrar el paso a GPTBot, que entrena modelos, y dejar entrar a OAI-SearchBot, que te puede traer tráfico.
• Es la única forma de negarte al entrenamiento de Google y Apple sin perder su buscador, con Google-Extended y Applebot-Extended.
• Es fácil de mantener. Un fichero de texto, que escribes una vez y editas cuando quieras.
• Lo respetan muchos bots importantes. Todas las empresas de la tabla declaran que sus bots de índice y de entrenamiento lo siguen.

Por su simplicidad, creo que debería ser la primera opción para controlar el rastreo de los bots de IA.

Search Console: el control de IA generativa

Desde el 31 de agosto de 2026, Search Console permite decidir si tu contenido aparece en AI Overviews, AI Mode y las funciones de IA generativa de Discover.

Hay tres opciones: incluir (la opción por defecto), excluir o heredar la configuración de la propiedad superior.

Según Google, este control:

• No es una señal de ranking: no afecta a tu posición en Search.
• No frena el entrenamiento de Gemini. Para eso está Google-Extended.
• No te saca de Google. Para eso está noindex.

La exclusión no es automática: Google dice que el contenido queda excluido en uno o dos días desde que el cambio entra en vigor, y que algo puede tardar más por la caché. La respuesta de IA será elaborada con el contenido de otras webs. Lo que pierdes es la cita, las impresiones y el tráfico.

nosnippet: no impide la entrada, limita el uso

nosnippet no controla el acceso. El bot puede entrar en tu página y leerla. En este caso, le pides que no muestre cierto contenido en sus resultados. Se puede aplicar de tres formas. Si dos reglas chocan, gana la más restrictiva:

En la cabecera HTTP, útil para archivos donde no puedes poner etiquetas, como un PDF:

X-Robots-Tag: nosnippet

En el <head> de la página, para afectar a toda ella:

<meta name="robots" content="nosnippet">

Como atributo HTML, para marcar solo un fragmento concreto:

<span data-nosnippet>Este texto no se mostrará</span>

Para Google, nosnippet afecta a todos sus resultados, incluidos AI Overviews y AI Mode. Para ser citado con enlace en esas funciones, Google exige que la página pueda mostrarse con snippet (se abre en una pestaña nueva). Por lo tanto, un nosnippet en el head o en la cabecera te deja fuera de esas citas.

En Apple sirve para no aparecer en las respuestas de IA de Siri y de la búsqueda de Apple, algo que robots.txt no controla. Apple indica usarlo dirigido a su bot:

<meta name="applebot" content="nosnippet">

Y si necesitas aplicarlo a un PDF o a una imagen, Apple admite la misma directiva por cabecera: X-Robots-Tag: applebot: nosnippet

Ninguna otra empresa de esta guía documenta que respete nosnippet.

Bloqueos en el CDN o el servidor

Estos bloqueos son más radicales. Aquí ya no sugieres como en el robots.txt, sino que impones una regla. El bot recibe un bloqueo, como un 403, y no puede entrar. Es la barrera contra los bots que no respetan robots.txt, pero también la que puede tener mayores consecuencias.

Antes de seguir conviene entender por dónde pasa una petición. Primero se resuelve el DNS, que decide a dónde va. Si usas un CDN como Cloudflare, la petición llega a su red: ahí el firewall decide si pasa o no, y después se sirve desde la caché si hay copia guardada. Si no la hay, la petición sigue hasta tu servidor, que puede tener sus propias protecciones antes de entregar el archivo.

Hay tres formas de bloquear:

El bloqueo por nombre de user-agent puede ser más fácil de saltar. Por eso las empresas publican formas de verificar que quien dice ser su bot lo es de verdad: todas publican los rangos de IP de sus rastreadores, y Google, Microsoft, Apple y Common Crawl admiten además la verificación por DNS inverso confirmado.

Hay que tener cuidado con los bloqueos por IP. El caso clásico es bloquear las direcciones de Estados Unidos y llevarse por delante a Googlebot, que sale principalmente desde allí. Google dice que, si detecta que un sitio bloquea las peticiones estadounidenses, puede intentar rastrear desde otros países (se abre en una pestaña nueva), pero no es algo con lo que convenga contar.

El CDN

Siguiendo con el ejemplo de Cloudflare, este permite bloquear bots de IA desde su panel por comportamiento, con las mismas categorías que hemos visto: Search, Agent y Training. Para cada una puedes elegir bloquear en toda la web, bloquear solo en las páginas con anuncios, o no bloquear. También puedes ir bot por bot con AI Crawl Control. Tres matices para los que usen esta plataforma al igual que yo:

• En el plan gratuito, AI Crawl Control reconoce a los bots solo por su nombre. Un bot que se identifique con el user agent de estos podría pasar este control.
• Solo funciona si el tráfico pasa por Cloudflare. Si tu dominio está en modo “solo DNS” —la nube gris del panel—, Cloudflare devuelve la IP de tu servidor, las visitas van directas y ninguna de estas reglas llega a aplicarse.
• El ajuste antiguo, Block AI bots, está en proceso de retirada desde el 15 de septiembre de 2026. Y ojo con los nuevos valores por defecto para dominios nuevos: los bots de Training y de Agent quedan bloqueados en las páginas que muestran anuncios.

El servidor o el hosting

Los servidores más famosos, Apache y Nginx, permiten los tres tipos de bloqueo. La opción que recomiendan los proveedores es la combinación de user-agent y dirección IP: rechazar a quien dice ser un bot oficial sin venir de sus IPs oficiales.

Aquí encontramos un problema de mantenimiento: las listas de IPs cambian. Microsoft recomienda no fijar direcciones en la configuración y, si usas su lista, actualizarla a diario (se abre en una pestaña nueva). Podemos correr el riesgo de no actualizar las listas y bloquear algo que no queremos.

Si tienes un hosting compartido o gestionado puede que el proveedor aplique protecciones contra bots de forma automática. Es la causa más difícil de ver: aparentemente no hay bloqueo, y el bot recibe un error igualmente. En ese caso, lo que toca es preguntarle al hosting qué protecciones tiene activadas.

Los métodos que no controlan el acceso

Hay directivas que pueden confundirse con bloqueos de acceso:

meta noindex o el X-Robots

Estas directrices sirven para controlar la indexación del contenido. En mi web, por ejemplo, la página de cookies lleva noindex:

<meta name="robots" content="noindex, follow">

No está en Google. Y aun así, ChatGPT la lee sin problema:

Lo mismo ocurre con X-Robots-Tag, que es la versión en cabecera de la misma instrucción.

Ojo, que no bloqueen el acceso no significa que no tengan efecto. Google exige que una página esté indexada para aparecer como enlace de apoyo en AI Overviews y AI Mode, así que un noindex también te deja fuera de ahí (se abre en una pestaña nueva).

llms.txt

Es un fichero que algunas webs utilizan para ofrecer a las IAs una versión ordenada de su contenido. La idea es razonable, pero ninguna de las empresas de esta guía lo menciona en su documentación sobre rastreadores. Tenerlo no hace daño, pero no controla el acceso de sus bots a tu web.

Entrar no es leer: el contenido bajo JavaScript

Que un bot pueda entrar en tu página no significa que pueda leerla. El contenido bajo JavaScript complica su accesibilidad y hay bots que puede que no lo ejecuten. Con un renderizado de JavaScript por parte del cliente (CSR), el bot puede recibir un esqueleto vacío, como vimos al principio con Windguru.

Carlos Sánchez Donate lo comprobó con diez IAs, replicando un experimento previo de Andre Alpar: puso en una web un código de descuento que solo aparece si se ejecuta JavaScript, y preguntó a cada una por él.

Según su última actualización, del 25 de junio de 2026 y con cinco pruebas por IA, ni ChatGPT, ni Claude, ni Gemini, ni Perplexity, ni Copilot encontraron el código. Grok sí ejecutó el JavaScript, pero ignoró el resultado. Solo Qwen lo hizo de forma consistente, con Kimi, DeepSeek y Mistral dando resultados irregulares. Aquí dejo el enlace a su artículo sobre el SEO y los LLMs (se abre en una pestaña nueva).

Las fuentes oficiales dicen poco, y lo que dicen no invita al optimismo: Apple confirma que Applebot sí renderiza (se abre en una pestaña nueva), Common Crawl dice que CCBot no ejecuta JavaScript (se abre en una pestaña nueva), y el resto ni lo menciona en su documentación.

¿El motivo? Ninguna lo explica, pero lo más probable es el coste que supone. Renderizar exige mucha más maquinaria y más tiempo que descargar el HTML. Google, que lleva años haciéndolo, lo describe así: encola las páginas y las renderiza cuando sus recursos se lo permiten. Y en los bots que actúan a petición de un usuario el coste es aún más evidente: hay alguien esperando la respuesta, y renderizar añade segundos a cada consulta que la IA hace a cada fuente.

La consecuencia es la misma que llevamos años repitiendo con Google, pero ahora con más bots en el panorama: cuanto más dependa tu contenido de JavaScript, más difícil será para las IAs poder leerlo.

Cómo saber si la IA puede leer tu contenido

Hay varias formas de comprobar si el contenido de tu página carga con JavaScript:

Mira el HTML tal y como llega a tu navegador

La forma más rápida es abrir el código fuente de la página: Cmd+Opción+U en Mac, Ctrl+U en Windows. Eso es el HTML tal y como llega, sin JavaScript ejecutado. Puedes usar Cmd+F para buscar el contenido importante: un titular, un precio, un párrafo… Si no está, será invisible para los bots que no ejecuten JavaScript. Y como hemos visto, son la mayoría.

También se puede hacer desde la terminal, y de paso identificarte como uno de los bots con un comando como este:

curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" https://tuweb.com/pagina

Para Googlebot tenemos la vía oficial: la inspección de URL de Search Console hace la petición desde Google y te enseña el HTML renderizado tal y como lo ve.

Ver la página sin JavaScript

Otra forma de comprobarlo es navegar por tu web como lo haría un bot que no ejecuta JavaScript:

1. Abre la página en Chrome.
2. Abre las herramientas de desarrollo (F12, o Cmd+Opción+I en Mac).
3. Pulsa Cmd+Shift+P (Ctrl+Shift+P en Windows), escribe “Disable JavaScript” y pulsa Enter.
4. Recarga la página sin cerrar las herramientas.

A diferencia del código fuente, aquí ves tu web ya montada y puedes seguir navegando. Podrás observar si los menús no se despliegan, si las fichas de producto salen vacías…

Un aviso sobre robots.txt: cuidado con bloquear carpetas de JavaScript o CSS necesarias para el renderizado del contenido. Apple lo dice explícitamente sobre Applebot.

Cómo auditar si la IA puede acceder a tu contenido

Hasta aquí hemos visto qué bots existen, cómo podemos controlarlos y la casuística del JavaScript en el lado del usuario. Respecto a la accesibilidad, la configuración elegida y la realidad pueden no ser la misma. Para saber qué está pasando con tu web hay que auditar quién accede a ella:

El problema de las herramientas online

Hay decenas de herramientas que analizan si los bots de IA pueden entrar en tu web. El método habitual es este: piden tu página identificándose como GPTBot, ClaudeBot y el resto, y miran qué responde tu servidor. Si reciben un 403, te dicen que estás bloqueando a ese bot.

Otterly.AI, una de las más conocidas, lo explica así en su AI Crawler Simulation: “It sends actual HTTP requests using the specific user-agent strings of each AI crawler, but does not check robots.txt files — it only tests how the server responds to the crawler’s user-agent.” Es decir, envía peticiones reales con el user-agent de cada rastreador y solo mira cómo responde el servidor a ese nombre. (Consultado el 30/09/2026)

El problema es de dónde sale esa petición: no sale de las IPs de OpenAI ni de las de Anthropic, sino del centro de datos del proveedor de la herramienta. Como hemos visto, las fuentes oficiales recomiendan comprobar el user-agent y la IP. Una web que siga ese consejo verá un GPTBot que no viene de OpenAI, y lo bloqueará correctamente si así está configurado.

Resultado: la herramienta informa de un bloqueo que no existe. Si una herramienta te dice que estás bloqueado, hay que comprobarlo antes de tocar nada.

Los logs: la mejor evidencia de quién está entrando realmente

Perplexity, Google y Microsoft recomiendan no fiarse únicamente del nombre del user-agent, sino comprobar también las IPs oficiales para asegurarse así de que el bot que está entrando a tu web es, efectivamente, la IA que dice ser en cada caso.

Para saber qué está ocurriendo de verdad hay que ver los logs. Son el registro de cada petición que recibe tu web, con su fecha, su IP, la URL pedida, el código de respuesta y el user-agent. Puede haber dos tipos de logs, los del CDN (si lo usas), que ven todas las peticiones, y los del propio servidor, que ven las que el firewall ha dejado pasar.

Lo más práctico es buscar el nombre dentro del user-agent, en vez de la cadena completa: los números de versión cambian cada poco y casi todos los bots tienen varias variantes, de escritorio y de móvil.

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Claude-User/1.0; +claude-user@anthropic.com)

Entonces, toca analizar y ver si lo configurado está funcionando para sacar conclusiones. Podemos ver, entre otras cosas:

• Bots que te interesan y reciben un error, sobre todo un 403, que es el bloqueo deliberado.
• Bots que leen tu robots.txt y luego no piden nada más.
• Bots que acceden a rutas que tenían prohibidas en el robots.txt.
• Bots que no aparecen por ningún lado, lo cual indica que no te están rastreando.

Hay que tener cuidado con situaciones que pueden confundir los resultados, como paywalls o desafíos tipo CAPTCHA, que devuelven un 200 y parecen visitas correctas.

Por último, el paso de la certeza: comprobar la IP de cada visita con la lista oficial de ese bot, o con el DNS inverso. De esta forma puedes separar las visitas auténticas de IA de las falsas.

Las suplantaciones existen: Common Crawl avisa de que hay rastreadores que se hacen pasar por CCBot.

Si una IP no está en la lista, la conclusión honesta es “no verificada”. Puede ser una suplantación, pero también una lista desactualizada o la lista equivocada: Google publica varias, según el bot.

Pregúntale a la IA si puede acceder a tu contenido

Para una comprobación rápida, hay un método al alcance de cualquiera: pedirle a la IA que abra una página tuya. Tiene la ventaja de que la petición sale de las IPs reales del proveedor, así que es una visita auténtica.

La clave está en cómo se lo pides. “¿Puedes acceder a mi web?” no sirve, porque un sí no demuestra nada. Pídele algo que solo pueda saber si ha leído la página: una frase concreta, un precio, el título del último artículo.

¿Qué dice esta página sobre [algo muy específico]? https://tuweb.com/pagina

Si te devuelve ese dato y coincide con lo que hay en tu página, ha entrado y ha leído. Si responde con vaguedades o con información que no está ahí, pregúntale qué recibió:

¿Qué has visto cuando has abierto la página?

Ahí salen las respuestas interesantes: un “Loading”, una página vacía, un error… Y también las equivocadas, como la de Claude del principio de esta guía. Si accedió o no, es fiable. El motivo que te dé, no tanto.

Dos límites:

• Solo prueba el bot de petición del usuario, así que no dice nada de los que construyen el índice desde el que te pueden citar.
• Prueba una página, no la web entera.

Seguimiento con las herramientas de analítica

Las herramientas de analítica como Google Analytics muestran a las personas que llegan a tu web desde una respuesta de IA. Alguien hizo una consulta, la IA te citó y esa persona hizo clic. Es la consecuencia final de todo lo que hemos visto en esta guía, y la señal de que la cadena completa funciona: el bot entró, leyó tu contenido, la IA lo usó y alguien acabó en tu web.

Por eso sirve como sistema de alarma. Si una web recibe una media de 50 visitas al mes desde ChatGPT y de repente pasa a cero, algo ha cambiado. Puede que hayas dejado de aparecer en sus respuestas, o puede que algo esté bloqueando el acceso.

Lo que no te dará la analítica es el diagnóstico: te da pistas de lo que está ocurriendo, no por qué.

Un apunte: para que ese tráfico se atribuya bien, conviene revisar cómo agrupa tu analítica las fuentes de IA. Si no las tiene identificadas, ese tráfico puede aparecer mezclado y no lo verás tan fácilmente. Es una de las primeras cosas que miro cuando trabajo el AI SEO de un proyecto.

Los tres métodos son complementarios. La analítica te ayuda a llevar un seguimiento más cotidiano y las preguntas a la IA pueden ayudar para alguna duda puntual. El análisis de logs es la herramienta a utilizar si notamos algún cambio o queremos auditar la accesibilidad de la web.

Un resumen de lo visto sobre la accesibilidad de la IA

Lo más importante en cinco puntos

1. Cada empresa tiene varios bots con funciones distintas. Bloquear el de entrenamiento y el que construye el índice desde el que te citan no es lo mismo, aunque sean de la misma empresa.
2. Hay que valorar las ventajas y desventajas de cada método de control. robots.txt es la opción más sencilla y flexible; los bloqueos en el servidor, la más restrictiva.
3. Que un bot entre no significa que lea. Si la web depende de JavaScript, la mayoría de las IAs tendrán problemas para ver el contenido.
4. Las herramientas online pueden dar falsos positivos, porque prueban desde sus propias IPs. Un “bloqueado” puede ser justo lo contrario: una web que verifica quién llama a su puerta.
5. Lo más fiable son los logs, cruzando el user-agent con las IPs oficiales de cada proveedor.

Esta guía sobre la accesibilidad de la IA y demás bots ha nacido de mi propia experiencia auditando y analizando webs. No solo con los ejemplos previamente expuestos, sino con algún que otro bloqueo 403 que me he comido poniendo el user-agent de bots de IA en la consola de Chrome y que finalmente resultaron no serlo, sino webs comprobando que yo no era quien decía ser.

Investigando, llegué a la conclusión de que, aunque las herramientas puedan ser útiles en muchos casos, pueden hacer saltar la alarma cuando no toca y que te lleven a decisiones erróneas. La propia IA y sus diagnósticos tampoco son siempre de fiar. Esta guía intenta dar luz en este aspecto y evitar repetir los falsos disgustos que yo me he llevado en el pasado.

He intentado ser lo más riguroso posible con todas las fuentes oficiales. Si has llegado hasta aquí y has cruzado algún dato que no cuadra o que ha quedado desactualizado, estaré encantado de corregirlo.

Si no tienes tiempo para hacer todo este análisis, escríbeme y reviso tu web: te digo qué IAs entran, cuáles son auténticas y qué se encuentran cuando llegan.

Fuentes