Cuando una herramienta dice «todos los rastreadores permitidos», puede significar «no pudimos saberlo»

Los dos fallos que parecen idénticos

Cuando una herramienta pide /robots.txt a tu servidor pueden pasar tres cosas. Que reciba el archivo. Que reciba un «eso no existe» definitivo. O que no reciba nada utilizable: un tiempo de espera agotado, una conexión cortada, un 403 de un firewall, un 503 de un origen sobrecargado.

Las dos primeras son respuestas. La tercera no lo es, y la distinción importa porque la segunda y la tercera llevan a conclusiones opuestas. Un 404 confirmado sí significa que los rastreadores pueden descargar lo que quieran: sin archivo no hay reglas, así que nada está prohibido. Un tiempo de espera agotado significa que no sabes cuáles son las reglas.

El error consiste en reducir ambos casos a una cadena vacía. Analiza una cadena vacía buscando reglas Disallow, no encuentres ninguna e informa de «permitido». La lógica es correcta en cada paso y produce una respuesta rotundamente equivocada.

Qué dice realmente la especificación

La RFC 9309, que estandarizó el Protocolo de Exclusión de Robots en 2022, trata estos casos por separado y les asigna significados opuestos.

La sección 2.3.1.3 cubre el estado «unavailable» (no disponible): códigos 4xx, incluidos 404 y 410. El rastreador puede acceder a cualquier recurso del servidor. Sin archivo, sin restricciones.

La sección 2.3.1.4 cubre el estado «unreachable» (inaccesible): códigos 5xx y errores de red. La redacción es inusualmente contundente: el archivo robots.txt queda indefinido y el rastreador DEBE asumir una prohibición completa. No «que actúe con cautela». La lectura estricta es la obligatoria, y es exactamente lo contrario del caso 404.

Así que una herramienta que trata un tiempo de espera agotado como un archivo inexistente no ha sido algo conservadora. Ha invertido un requisito normativo.

Por qué los rastreadores reales son más indulgentes que la RFC

Google no implementa el DEBE literal, y conviene saberlo antes de alarmarse por un 503.

El comportamiento documentado de Google: durante las primeras doce horas de respuestas 5xx deja de rastrear el sitio y sigue reintentando. Los treinta días siguientes usa la última copia válida en caché. Si no existe copia en caché, asume que no hay restricciones de rastreo. Pasados treinta días, si el sitio funciona con normalidad, actúa como si no hubiera robots.txt.

Es una degradación gradual que la RFC permite pero no exige. También significa que una caída breve no te cuesta nada, siempre que tu robots.txt fuera accesible antes y vuelva a serlo después.

La conclusión práctica es más estrecha que «un 503 te va a desindexar». Es que un 403 persistente —el que produce una regla antibots, que nunca se resuelve ni llega a la caché— es un problema distinto y bastante más duradero que un 500 pasajero.

El caso que de verdad hace daño: un firewall que responde a todo

Un 403 de un WAF es el fallo interesante, porque es invisible desde el navegador. Entras en tusitio.com/robots.txt, ves el archivo y concluyes que todo está bien. El archivo se te está sirviendo a ti y se le está negando a cualquier cosa que parezca automatizada.

No es hipotético. Al ejecutar nuestro propio analizador contra sitios grandes el 13 de septiembre de 2026, medium.com, quora.com, g2.com y stackoverflow.com devolvieron un 403 a nuestra petición. Nuestro user-agent es anodino y se identifica con honestidad, y precisamente por eso lo rechazan: las reglas antibots se fijan justo en eso.

Conviene ver lo rápido que cambia esto. nytimes.com, reddit.com y theguardian.com nos rechazaron el día anterior y ahora responden con normalidad. Cualquier lista de sitios bloqueados, incluida esta, es una foto de un momento y no un dato sobre esas empresas, que es justamente el argumento para probar tu propio dominio en lugar de razonar a partir de los resultados de otros.

Esos sitios casi con seguridad sí son accesibles para OAI-SearchBot y PerplexityBot, porque los grandes rastreadores de IA publican sus rangos de IP y las CDN los incluyen en listas de permitidos. La conclusión honesta para un sitio grande es «no podemos verlo, pero los rastreadores reales probablemente sí». El caso peligroso es el inverso: un sitio pequeño detrás de una regla WAF agresiva por defecto, donde nadie ha añadido nada a ninguna lista de permitidos, y donde «rechazaron a nuestro analizador» es una advertencia real y no una falsa alarma.

Cómo comprobarlo tú mismo con un comando

Olvídate del navegador: es el único cliente que tiene garantizada una respuesta amable. Usa curl con un user-agent que una regla antibots reconozca, y fíjate en el código de estado más que en el contenido. El parámetro -L es imprescindible: muchos dominios redirigen /robots.txt y sin él te quedarías leyendo el 301.

Ejecuta esto sustituyendo tu dominio:

curl -sL -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://tusitio.com/robots.txt

Un 200 significa que el archivo se está sirviendo a algo que se anuncia como rastreador. Un 403 o un 503 significan que no, y merece investigarse al margen de lo que te haya dicho cualquier herramienta. Compáralo con la misma petición usando un user-agent de navegador: si los dos difieren, tienes una regla antibots decidiendo quién ve tus directivas de rastreo.

Una trampa que conviene evitar: no añadas -I para enviar una petición HEAD. Al probarlo, quora.com devolvió 403 a HEAD y 200 a GET con la misma URL y el mismo user-agent. Algunas reglas antibots consideran HEAD más sospechoso que GET, así que una prueba basada en HEAD fabrica exactamente la falsa alarma de la que trata este artículo. Los rastreadores descargan con GET, así que prueba con GET.

En el caso concreto de OpenAI puedes ir más lejos: publica los rangos de IP de cada bot en openai.com/searchbot.json, gptbot.json y chatgpt-user.json. Si los registros de tu firewall muestran bloqueos desde esos rangos, el problema queda confirmado y no solo supuesto.

Qué hace nuestro analizador y en qué se aparta de la especificación

Nuestro analizador de visibilidad en IA devuelve uno de tres estados para robots.txt: leído correctamente, ausencia confirmada, o ilegible. Un 404 confirmado obtiene la puntuación máxima, porque según la RFC eso sí significa acceso sin restricciones. Un robots.txt ilegible obtiene una puntuación parcial y se informa como no verificado, marcando la comprobación como fallida y no como superada.

Conviene ser precisos en un punto, porque este artículo trata sobre la falta de precisión de otros. La RFC dice que un rastreador DEBE asumir prohibición completa cuando robots.txt es inaccesible. Nosotros no informamos de una puntuación de cero. Una herramienta de diagnóstico y un rastreador tienen tareas distintas: el rastreador tiene que decidir si descarga o no, así que necesita un valor por defecto, y el valor seguro es quedarse fuera. Una herramienta tiene que contarte lo que es cierto, y lo cierto es que el estado es desconocido. Informar de cero cambiaría una respuesta rotunda equivocada por otra.

Este fue un error real en nuestro propio código, no una hipótesis que detectamos en otros. Nuestra primera versión reducía «fallo al descargar» a una cadena vacía y otorgaba una puntuación perfecta de acceso de rastreadores a nytimes.com —que en ese momento nos estaba rechazando—, informando de que los diez rastreadores de IA estaban permitidos cuando no habíamos leído absolutamente nada. Lo encontramos ejecutando la herramienta contra sitios que no controlamos, que es la única forma fiable de encontrar este tipo de error.

Cómo evaluar cualquier analizador en este aspecto

No necesitas leer el código fuente de nadie. Apunta la herramienta a un dominio cuyo robots.txt se sepa que rechaza peticiones automatizadas —los medios citados arriba sirven perfectamente— y lee lo que afirma.

Si informa de un número concreto de rastreadores permitidos, está informando del análisis de la nada. Si distingue entre «no se encontró robots.txt» y «no se pudo leer robots.txt», está tratando el caso correctamente. Si no dice nada sobre robots.txt, has aprendido menos de lo que ese silencio aparenta.

Esto va más allá de robots.txt. Cualquier comprobación que pueda fallar al obtener sus datos de entrada necesita tres resultados posibles en lugar de dos, y es en el tercero donde las herramientas revelan si se construyeron para informarte o para mostrar una marca verde tranquilizadora.