robots.txt avanzado: directivas, comodines y errores reales

El archivo /robots.txt parece tan simple que rara vez se revisa con el mismo cuidado que otros elementos técnicos del sitio, y precisamente por eso es donde aparecen algunos de los errores más caros de una auditoría: una regla mal escrita puede bloquear sin querer secciones enteras del sitio, o dejar pasar por error contenido que debería quedar fuera del rastreo. Esta guía va más allá de la sintaxis básica de User-agent, Disallow y Allow ya explicada en la guía de rastreo e indexación, y entra en el terreno donde realmente se producen los fallos: cómo interpretan los rastreadores los comodines, qué regla gana cuando varias podrían aplicar a la misma URL, y cómo verificar de verdad —no de memoria— que el archivo hace lo que crees que hace.

Comodines: cómo interpreta un rastreador * y $

El protocolo de exclusión de robots, formalizado como RFC 9309 en 2022 tras décadas funcionando como convención de facto, admite dos comodines en las rutas de Disallow y Allow. El asterisco * representa cualquier secuencia de caracteres, incluida una secuencia vacía, y puede usarse cualquier número de veces dentro de una misma regla. El símbolo $ ancla el final de la ruta, indicando que la coincidencia solo es válida si la URL termina exactamente ahí y no continúa con más caracteres.

La diferencia entre bloquear con y sin ese ancla parece cosmética pero no lo es: sin $, toda regla de Disallow lleva un comodín implícito al final, así que coincide con cualquier continuación de esa cadena.

Disallow: /informe.pdf
# también bloquea /informe.pdf?v=2 y /informe.pdfantiguo.html

Disallow: /informe.pdf$
# solo bloquea la URL que termina exactamente ahí

Este matiz es el origen de bloqueos accidentales de URLs que nunca se pretendió excluir, simplemente porque compartían un prefijo con la ruta que sí quería bloquearse.

Especificidad: qué regla gana cuando varias podrían aplicar

Cuando una URL coincide con más de una regla dentro del mismo bloque de User-agent, la mayoría de rastreadores que siguen RFC 9309 (Googlebot entre ellos) no aplican la primera regla que coincide en orden de lectura, sino la regla más específica, entendida como la que tiene la ruta coincidente más larga en número de caracteres. Es una diferencia fundamental respecto a lo que mucha gente asume por intuición, que "la primera regla gana" como en un cortafuegos clásico, y es la causa de bastantes archivos robots.txt que no hacen lo que su autor esperaba.

User-agent: *
Disallow: /privado/
Allow: /privado/publico/

# /privado/publico/ficha.html SÍ se puede rastrear:
# "/privado/publico/" (17 caracteres) es más específica
# que "/privado/" (9 caracteres), gane quien gane el orden

Cuando dos reglas coinciden con exactamente la misma longitud, la especificación resuelve el empate a favor de Allow sobre Disallow, aunque no todos los rastreadores menos rigurosos respetan ese desempate de forma idéntica, así que en la práctica conviene evitar depender de longitudes idénticas y ser explícito con los comodines si hay ambigüedad real.

Crawl-delay: por qué Google lo ignora y otros bots no

Crawl-delay es una directiva que especifica, en segundos, el tiempo mínimo que un bot debe esperar entre peticiones consecutivas al mismo sitio. Nació como extensión no estándar, nunca formó parte del protocolo original ni de la RFC 9309 final, impulsada originalmente por buscadores como Yahoo y adoptada después por Bing y Yandex, que sí la respetan.

Google es la excepción notable: Googlebot ignora por completo la directiva Crawl-delay en robots.txt, con independencia del valor que se le ponga. La forma correcta, y la única soportada actualmente, de pedirle a Google que reduzca su velocidad de rastreo es el ajuste de límite de velocidad de rastreo en Search Console, un control que además Google solo atiende si detecta que el rastreo está causando problemas reales de rendimiento, no como preferencia arbitraria del propietario del sitio. Un error real y bastante extendido es asumir que un Crawl-delay: 10 en el bloque User-agent: * frena también a Googlebot: no lo hace, y el propietario del sitio se sorprende cuando el rastreo de Google sigue igual de intenso pese a la directiva.

User-agent: bingbot
Crawl-delay: 10

User-agent: Googlebot
# Crawl-delay aquí no tiene ningún efecto; se ignora por completo

Varios bloques de User-agent en el mismo archivo

Un mismo robots.txt puede declarar reglas distintas para bots distintos, y aquí es donde más confusión genera el comportamiento real de los rastreadores: cada bot aplica únicamente las reglas del bloque que coincide con su nombre de user-agent de forma más específica, nunca la suma de varios bloques. Si existe un bloque para Googlebot-Image y otro genérico para *, el rastreador de imágenes de Google obedece solo su propio bloque, ignorando por completo lo que diga el bloque genérico, incluso si ese bloque genérico contiene reglas que en apariencia también deberían aplicarle.

User-agent: *
Disallow: /privado/

User-agent: Googlebot-Image
Disallow: /fotos-internas/

# Googlebot-Image puede rastrear /privado/ sin problema:
# no hereda nada del bloque genérico, solo obedece su propio bloque

Esto tiene una consecuencia práctica importante: si se añade un bloque específico para un bot concreto (por ejemplo, para darle instrucciones distintas a un rastreador de entrenamiento de IA) hay que repetir explícitamente en ese bloque cualquier regla del bloque genérico que también deba aplicarle, porque no existe herencia entre bloques.

Errores reales que más aparecen en auditorías

El más frecuente es el bloqueo accidental de CSS y JavaScript: un Disallow: /wp-includes/ o /assets/ demasiado amplio impide que Googlebot descargue recursos que su propio renderizado necesita, lo que le impide ver la página como la ve un usuario, tal y como se explica en la guía de JavaScript y SEO técnico. El segundo es un Disallow: / heredado de un entorno de pruebas que nadie retira al pasar a producción, bloqueando el dominio entero de un plumazo. El tercero es la sensibilidad a mayúsculas: las rutas de robots.txt distinguen mayúsculas de minúsculas, así que un Disallow: /Descuentos/ no bloquea /descuentos/ aunque para una persona parezcan la misma carpeta. El cuarto es el desajuste de barra final: Disallow: /carpeta (sin barra) bloquea también /carpeta-antigua o /carpeta2 por coincidencia de prefijo, mientras que Disallow: /carpeta/ (con barra) solo bloquea lo que cuelga literalmente de esa carpeta. Y un quinto, menos conocido pero real en sitios con reglas generadas automáticamente: Google solo procesa los primeros 500 KiB del archivo robots.txt; cualquier regla que quede más allá de ese límite se ignora sin ningún aviso visible.

Cómo comprobar robots.txt de verdad, no de memoria

Google retiró la herramienta clásica de prueba de robots.txt de Search Console y la sustituyó por un informe en la sección de Configuración, que muestra el archivo detectado, cuándo se rastreó por última vez y si hay errores de sintaxis o de disponibilidad, pero ya no permite simular una URL concreta contra las reglas como hacía la herramienta antigua. Para esa simulación manual, Google mantiene en abierto (código fuente publicado) la misma librería de análisis de robots.txt que usa internamente Googlebot, que se puede instalar y ejecutar en local contra el archivo real y una lista de URLs de prueba: la forma más fiable de reproducir el comportamiento exacto sin depender de una interpretación humana de las reglas.

Una comprobación manual rápida, aunque menos rigurosa, es simplemente pedir el archivo con curl y revisar la cabecera de respuesta antes que el contenido:

curl -I https://www.tudominio.com/robots.txt

Un robots.txt que devuelve un error de servidor (5xx) hace que Google, de forma temporal, trate el sitio entero como completamente bloqueado al rastreo hasta que vuelva a responder con normalidad, mientras que un 404 se interpreta como "no hay restricciones", con permiso implícito para rastrear todo. Esa diferencia entre un error de servidor y un archivo simplemente ausente es la que más sorprende a quien no la conoce.

Preguntas frecuentes