robots.txt Sin Mitología: Guía Práctica Que Coincide Con Cómo Funcionan los Crawlers

Lo Único Que robots.txt No Es

El malentendido más caro en SEO técnico es creer que robots.txt controla la indexación. No lo hace. Controla el rastreo. Una URL bloqueada por Disallow puede seguir apareciendo en el índice de Google — sin título, sin snippet, sin rendimiento de búsqueda útil — si Google se entera de la URL por cualquier otra fuente: un backlink, una entrada de sitemap, un enlace interno desde una página que Google sí tiene permiso para rastrear. El resultado es el temido estado "Indexada, aunque bloqueada por robots.txt" en Search Console: una URL en el índice que no se puede servir adecuadamente, lo que es aproximadamente lo peor de ambos mundos.

Si quieres una URL fuera del índice, tienes que dejar a Google rastrearla para que pueda leer una etiqueta meta noindex o una cabecera de respuesta X-Robots-Tag. Si quieres una URL fuera del crawl budget, robots.txt es la herramienta correcta. Confundir estas dos operaciones causa una fracción sorprendente de los tickets de "¿por qué sigue rankeando esta URL?" — y la solución casi siempre es eliminar el bloqueo de robots.txt, añadir una etiqueta noindex, esperar al re-crawl, y solo entonces volver a bloquear en robots.txt para ahorrar crawl budget una vez la página haya caído del índice.

Una vez interiorizada esa distinción, robots.txt pasa a ser una herramienta precisa y predecible. El resto del artículo recorre cómo funciona realmente la coincidencia, qué directivas son estándares reales frente a artefactos históricos, y el flujo que uso para validar un robots.txt antes de cualquier despliegue.

RFC 9309: La Spec Por Fin Se Escribió

Durante la mayor parte de su historia, robots.txt fue un estándar de facto — un borrador de 1994 en una lista de correo de Stanford que los operadores de crawlers implementaron con sus propias interpretaciones. En 2019 Google liberó su parser de referencia como open source. En 2022 la IETF formalizó el comportamiento como RFC 9309. La spec captura tres reglas que importan:

1. Selección de grupo por especificidad de user-agent. Cuando un crawler lee robots.txt, selecciona el grupo cuyo nombre de User-agent sea la coincidencia de subcadena más específica (sin distinguir mayúsculas) con su propio nombre. Si varios grupos coinciden, gana el User-agent declarado más largo. Si ninguno coincide, aplica el comodín User-agent: *. Si tampoco hay comodín, todas las URLs están permitidas.
2. Coincidencia más larga gana dentro del grupo elegido. El crawler recoge cada regla Allow y Disallow cuya ruta coincida con la URL solicitada. Gana la regla con más caracteres literales en su ruta. Esta es la parte sorprendente: el orden de las reglas no importa. Un Disallow declarado en la línea 3 puede ser anulado por un Allow declarado en la línea 20 simplemente porque la ruta del Allow es más larga.
3. Allow gana a Disallow en empates. Cuando una regla Allow y una Disallow coinciden con la misma longitud literal, gana Allow. Es lo que hace que el patrón canónico Disallow: /private/ más Allow: /private/public/ produzca el resultado intuitivo de que /private/public/anything sea rastreable.

Los comodines * (cualquier secuencia, incluida vacía) y $ (ancla de fin de URL) forman parte de la spec. Disallow: /*.pdf$ bloquea /report.pdf pero no /report.pdf?download=1. Disallow: /api/ bloquea /api/users pero también /api/private/users. Las barras finales importan: Disallow: /admin/ no bloquea /administrator, pero Disallow: /admin sí. Son el tipo de detalles donde la intuición falla y un tester es invaluable.

Los Cinco Errores Que Rompen los robots.txt Reales

La mayoría de errores de robots.txt que veo en producción caen en una de cinco categorías.

1. Rutas sin barra inicial. Una regla como Disallow: admin/ es ignorada silenciosamente por Google. La spec exige que las rutas empiecen por / o *. La corrección es un único carácter, pero el impacto es total: la regla no hace nada. Plantillas CMS que construyen la ruta con paths relativos o que eliminan barras iniciales durante una concatenación de strings son los culpables habituales. Tanto el verificador hreflang como el tester de robots lo marcan; en el tester aparece como PATH_MISSING_LEADING_SLASH.

2. Reglas fuera de cualquier grupo. Un Disallow o Allow que aparece antes de cualquier declaración de User-agent se ignora. La corrección es añadir una línea User-agent: * sobre las reglas. La causa suele ser un copy-paste de un ejemplo que solo incluía las líneas de regla, o un generador programático que olvidó la cabecera User-agent del grupo comodín.

3. Confiar en el algoritmo longest-match sin entenderlo. La conversación más común que tengo en code review va así: "Añadí Disallow: /admin/ pero Googlebot sigue rastreando /admin/public/page". La respuesta casi siempre es que hay una regla Allow en algún sitio — a menudo un genérico Allow: / en otro grupo o más arriba en el archivo — cuya ruta es más larga de lo esperado. El tester lo expone mostrando la regla exacta que coincidió y su número de línea, lo que normalmente hace evidente el malentendido.

4. Usar Noindex en robots.txt. Google soportó brevemente una directiva no estándar Noindex: en robots.txt hacia 2019. Nunca se documentó. El soporte se retiró el mismo año. Artículos de SEO de esa época todavía la referencian, y los autores que aprendieron robots.txt entonces a veces escriben reglas como Noindex: /private/ y confían en que Google sacará la URL del índice. Google no lo hará. La directiva se ignora, la URL sigue siendo indexable (o peor, se queda atascada en "Indexada, aunque bloqueada por robots.txt"), y el equipo tiene una falsa sensación de seguridad. El tester lo marca como NOINDEX_IN_ROBOTS con la recomendación de usar una meta etiqueta o X-Robots-Tag en su lugar.

5. Suposiciones sobre Crawl-delay. Crawl-delay es respetado por Bingbot y Yandex. Googlebot lo ignora. Los equipos que necesiten frenar específicamente a Googlebot tienen que usar el ajuste de tasa de rastreo en Search Console (cuando esté disponible) o, si el servidor está genuinamente sobrecargado, devolver respuestas HTTP 503 con una cabecera Retry-After. El tester reporta Crawl-delay como informativo para que sepas que se está aplicando pero solo por un subconjunto de crawlers.

Crawlers de IA: La Nueva Categoría

La categoría más nueva de crawlers en las auditorías de robots.txt de la mayoría de equipos son los bots de IA. Los principales que conviene conocer:

• GPTBot. El crawler de OpenAI para recoger datos de entrenamiento. Documentado y respeta robots.txt. Bloquéalo con User-agent: GPTBot\nDisallow: /.
• ChatGPT-User. El crawler de OpenAI disparado por prompts de usuario dentro de ChatGPT (la función "browse"). Distinto de GPTBot en que no es para entrenamiento, es para recuperación en vivo.
• Claude-Web. El fetcher web de Anthropic. Usado para recuperación en vivo en productos de Claude.
• PerplexityBot. El crawler de Perplexity para su producto de búsqueda con IA.
• Bytespider, CCBot, Amazonbot, y otros. Muchos de estos ignoraban robots.txt hasta 2023 pero la mayoría ahora lo respetan tras presión pública.

La decisión de qué bots de IA permitir o bloquear es una pregunta de política, no técnica. La parte técnica es verificar que la regla que escribiste hace realmente lo que crees. El selector de user-agent del tester de robots.txt te permite alternar entre estos bots y ver cómo cada uno interpretaría tu archivo — útil cuando tus reglas usan un comodín User-agent: * con overrides para bots específicos, porque la regla de coincidencia más específica hace fácil equivocar la precedencia.

La Directiva Sitemap

La directiva Sitemap es la única parte de robots.txt que no trata sobre reglas de rastreo. Indica a los crawlers dónde encontrar tus sitemaps XML. Las reglas son simples pero merecen acertarse:

• Cada línea Sitemap es independiente; se permiten varias líneas y son aditivas.
• La URL debe ser absoluta (la spec es explícita: las URLs relativas no son válidas). Sitemap: /sitemap.xml no es conforme; Sitemap: https://ejemplo.com/sitemap.xml es correcto.
• La directiva Sitemap aplica a todo el robots.txt independientemente del grupo de User-agent en que aparezca. Por convención va arriba o abajo, fuera de cualquier grupo.
• Se soportan varios sitemaps e índices de sitemap. Los sitios grandes normalmente declaran un índice de sitemap que apunta a muchos sitemaps hijos.

El tester extrae cada directiva Sitemap a su propia pestaña, valida el requisito de URL absoluta y renderiza las URLs como enlaces clicables para detectar referencias obsoletas en el mismo pase de auditoría. Combinar el tester con el Comparador de Sitemaps en el mismo host detecta la mayoría de problemas pre-despliegue en un único flujo.

Un Flujo Que Detecta Errores Antes del Despliegue

1. Genera o exporta el robots.txt propuesto desde tu CMS, pipeline de build o archivo editado a mano. Pégalo en el panel izquierdo del tester.
2. Lista las URLs que realmente te importan en el panel derecho — páginas de alto tráfico, rutas de admin sensibles, contenido restringido, cualquier cosa que hayas cambiado recientemente. El tester no rastrea tu sitio, así que las entradas están enteramente bajo tu control.
3. Prueba primero contra Googlebot. Selecciona Googlebot en el desplegable de user-agent, pulsa Probar, revisa la pestaña Veredictos. Cada resultado Bloqueada debe ser intencional; cada resultado Permitida sobre contenido sensible también debe ser intencional.
4. Cambia de user-agent para verificar política. Reejecuta con Bingbot, GPTBot, Claude-Web, PerplexityBot. Si tu política dice "bloquear GPTBot, permitir Claude-Web", los veredictos deben reflejarlo. Si no, tus reglas tienen un bug de precedencia.
5. Revisa la pestaña Hallazgos. Cualquier error significa que una regla se ignora silenciosamente. Cualquier aviso significa que el archivo es técnicamente válido pero usa una característica obsoleta o no estándar. Resuelve ambos antes de enviar.
6. Comprueba la pestaña Sitemaps. Cada Sitemap declarado debe ser accesible y actual. Las referencias obsoletas confunden a los crawlers y contaminan los informes de Search Console.
7. Exporta veredictos como CSV. Adjunta a la PR de despliegue como artefacto de auditoría. La próxima persona que revise este archivo tendrá un registro de lo que se probó y cuál era el comportamiento esperado.
8. Conecta el parser a CI. La misma lógica de parseo y coincidencia está expuesta por el paquete open-source @anthropic-tools/tools-core. Un test de CI que cargue el robots.txt de producción y asegure el veredicto esperado para una lista fija de URLs canario convierte la corrección de robots.txt en una propiedad verificada por regresión.

El Límite: Lo Que robots.txt No Puede Hacer

Dos advertencias finales antes de enviar:

• robots.txt no es una frontera de seguridad. El archivo es legible públicamente. Listar tus rutas de admin en robots.txt es efectivamente publicarlas. Si necesitas control de acceso, usa autenticación HTTP, listas de IPs permitidas o un guard de ruta autenticada — no reglas Disallow.
• Los crawlers maliciosos lo ignoran. RFC 9309 es un protocolo de bots educados. Scrapers, ladrones de contenido y recolectores de datos de competidores buscarán tus URLs sin importar lo que diga robots.txt. Si tus logs de tráfico muestran descargas de un bot que debería estar bloqueado, la respuesta es un bloqueo a nivel de servidor (firewall, WAF, rate limit), no una regla de robots.txt más fuerte.

Conclusión

robots.txt es un archivo pequeño con un impacto desproporcionado sobre el crawl budget y la política de entrenamiento de IA. El algoritmo de RFC 9309 es preciso y verificable, los errores comunes son bien conocidos y el coste de equivocarse — crawl budget desperdiciado, rutas de admin expuestas, contenido equivocado usado para entrenamiento de IA — es real. El Comprobador de robots.txt implementa el mismo algoritmo que usa Googlebot, se ejecuta enteramente en tu navegador y convierte un archivo que de otro modo auditarías a mano en una verificación pre-despliegue de un minuto. Pega tu archivo, lista las URLs que te importan, elige el user-agent que quieras verificar y mira lo que tus crawlers ven realmente.