Crawl-delay es una de las directivas más copiadas de robots.txt y también una de las más malinterpretadas. Para Google hay un dato clave: Googlebot no admite Crawl-delay en robots.txt. Añadir un número de segundos no obliga a Googlebot a esperar ese tiempo entre peticiones.
Otros crawlers sí pueden implementar extensiones propias. Por eso no conviene asumir que una línea funciona igual para todos: consulta la documentación del operador del bot que quieres controlar.
Ejemplo de Crawl-delay
User-agent: ExampleBot
Crawl-delay: 10
Suele interpretarse como una solicitud para espaciar las peticiones unos diez segundos. Sin embargo, RFC 9309 estandariza el núcleo del Robots Exclusion Protocol y no convierte todas las directivas históricas en campos universales.
Google documenta user-agent, allow, disallow y sitemap, y marca crawl-delay como no compatible.
Por qué puede dar una falsa sensación de control
Si se añade durante un pico de tráfico y el crawler lo ignora, nada cambia. Mientras tanto puede pasar desapercibida la causa real:
- explosión de URLs por filtros o navegación facetada;
- calendarios, búsquedas o parámetros que crean espacios infinitos;
- respuestas
5xxque provocan reintentos; - un bot que no respeta robots.txt;
- otro User-agent distinto del que se está intentando limitar;
- lentitud de la aplicación que hace costoso un volumen normal.
Empieza por los logs: User-agent, frecuencia, rutas y códigos de respuesta.
No uses 401 o 403 para reducir Googlebot
Bloquear el propio /robots.txt con 401 o 403 es especialmente arriesgado. Google trata la mayoría de los 4xx, excepto 429, como si no existiera un robots.txt válido, lo que implica ausencia de restricciones de rastreo.
HTTP/1.1 403 Forbidden
no significa “Googlebot rastreará más despacio”. Puede impedir que lea las reglas que querías aplicar.
429 y 5xx son señales distintas
429 Too Many Requests y los errores de servidor indican sobrecarga o indisponibilidad y pueden reducir temporalmente el rastreo. No deben usarse como sustituto permanente de una buena arquitectura.
La secuencia adecuada suele ser: corregir espacios de URL accidentales, bloquear solo rutas realmente innecesarias, mejorar caché y capacidad, y usar controles específicos del proveedor cuando existan.
Si el problema son rutas innecesarias, usa Disallow con criterio
User-agent: *
Disallow: /busqueda-interna/
Disallow: /cart/
Disallow: /session/
Sitemap: https://example.com/sitemap.xml
Esto reduce solicitudes a esas rutas en vez de espaciar todas las peticiones. Pero Disallow no es noindex, así que no lo uses solo para sacar páginas de los resultados.
En sitios grandes importa la eficiencia de rastreo
En ecommerce, marketplaces o medios, el problema suele ser si el crawler puede llegar a páginas canónicas importantes sin gastar la mayoría del tiempo en combinaciones duplicadas. Revisa filtros, parámetros de orden, búsquedas internas, IDs de sesión, previews y paginaciones de poco valor.
Flujo seguro de diagnóstico
- identifica el crawler exacto en logs;
- confirma si su operador admite Crawl-delay;
- mide volumen y rutas más solicitadas;
- detecta explosiones de URL;
- comprueba estado, tamaño y codificación de
/robots.txt; - verifica que no bloqueas páginas o recursos importantes;
- analiza
429y5xx; - prueba cambios con URLs reales;
- monitoriza después de publicar.
Para Googlebot, la conclusión es directa: no dependas de Crawl-delay; usa reglas compatibles, corrige trampas de rastreo y soluciona los problemas de servidor que estén generando la carga.
