Es cierto que en pocas ocasiones de nuestra vida nos vamos a plantear como podemos hacer para que Google rastree nuestra web con menos frecuencia. Pero se puede dar el caso que al analizar los Logs y el Uptime de nuestra web, se de la correlación de que cae en picos donde Google rastrea nuestra web.
O si nos ponemos más trickis, estamos en un momento de cambios en producción donde queremos que Google no nos rastree con exceso para que no se le quede en caché contenido de poca calidad, pero a la vez no es un cambio tan drástico como para poner la web en 5XX (ni ponerle 5XX solo a Google).
El problema de la directiva Crawl-delay
La directiva Crawl-delay en el archivo robots.txt no funciona con Google.
Aunque otros motores de búsqueda como Bing la respetan para espaciar el tiempo entre peticiones.
También es verdad que bing se lo curra más y en BingWebmaster tienes hasta un control del rastreo donde le puedes decir a Bing las horas más interesantes para rastrearte.

No obstante no todos los bots son tan considerados de cara a organizar nosotros el rastreo de nuestra web, de hecho en ocasiones debemos saber bloquear el acceso a user-agents incluso con medidas mucho más potentes que el robots.txt. Googlebot que además es un bot que en general queremos que acceda a nuestra web ignora la directiva del Crawl-delay por completo, y tampoco tenemos una opción de modificar el rastreo desde la Search Console.
Entonces podríamos darnos por vencido y decidir que mejor no tocar a Google y que rastree lo que quiera. Pero es cierto que en determinados proyectos puede haber un pico de rastreo de Google en fechas donde no se puede soportar tanta carga.
He visto este Crawl-delay aplicado para Googlebot directamente y en ocasiones puede conllevar a problemas de reglas aplicadas de forma inesperada, ya que Googlebot ignora esta directiva y eso tiene sus riesgos, eso lo podemos ver en este ejemplo:

Mi recomendación siempre sería tener preparado el servidor para momentos picos, pero puede ser que queramos limitar a Google porque nos rastrea de forma excesiva.
Bloqueo por rango de IP
El caso más probable cuando una web se nos tumba por un exceso de rastreo de Bots de Google, es que realmente no sean Bots de Google. Y aunque sea relativamente complejo de implementar, si no usamos ningún CDN que nos cubra esta función, podemos implementar en nuestra web un bloqueo a todos los user-agents de Google que no cumplan este rango de ip.

Si bien no es lo recomendable, este listado es muy importante para webs que por ejemplo están prohibidas en EEUU y es necesario bloquearlo, pero se necesita aparecer en Google.
Para lo que nos ocupa, en muchas ocasiones prohibiendo el rastreo a toda web que no entre dentro del rango de IP funciona bastante bien.
Esta práctica por ejemplo la aplica Airbnb, donde podemos ver que si fingimos ser Google nos bloquea:


Para quien se lo pregunte, ni esta implementación, ni la hiper personalización que hace para el usuario afecta negativamente a su posicionamiento, más bien lo contrario.
Ahora, ¿qué ocurre si hacemos estos cambios y aun así descubrimos que nuestro legítimo San Google es realmente quien nos está rastreando de forma excesiva? Pues tenemos un As bajo la manga.
Códigos 503 o 429 y cabecera Retry-After
La forma técnica correcta de obligar a Googlebot a detenerse es devolver un código de estado HTTP 5XX o 429.
Esto puede ir acompañado de la cabecera Retry-After. Así proteges tu infraestructura de forma inmediata y das a Google una instrucción estandarizada de cuándo es seguro volver. Si no, dejas a criterio de Google cuando volver a intentarlo, que si bien reducirá bastante el rastreo y tardará en hacer cambios en el índice, con el retry-after tienes el control.
Google actualizó el 6 de octubre su guía para reducir la frecuencia de rastreo y añadió explícitamente el uso de esta cabecera (tal y como la define el RFC 9110).

La guía muestra cómo el retraso puede indicarse en segundos:
HTTP/1.1 503 Service Unavailable
Retry-After: 120
O mediante una fecha y hora absolutas en UTC:
HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Cómo se envía Retry-After en Apache, LiteSpeed y nginx
Dos decisiones: en qué respuestas va (503 de mantenimiento, 429 de límite de peticiones) y con qué valor (segundos, o una fecha HTTP como Retry-After: Wed, 07 Oct 2026 18:00:00 GMT). Y una regla: la cabecera acompaña al estado, no a la ruta. Si la añades a todas las respuestas de un directorio, la verán también los 200, y ahí no significa nada.
Apache. Lo resuelven dos módulos que ya tienes: mod_rewrite pone el estado y mod_headers la cabecera, condicionada al estado con expr= (Apache 2.4.10 o superior). Vale igual en el .htaccess y en el VirtualHost.
.htaccess en la raíz, o el VirtualHost# Mantenimiento de todo el sitio: 503 y Retry-After de una hora.
# Tu IP sigue entrando, y la página de mantenimiento (y su carpeta) no se bloquea.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/mantenimiento
RewriteRule ^ - [R=503,L]
</IfModule>
ErrorDocument 503 /mantenimiento.html
# La cabecera solo cuando la respuesta es 503 (Apache 2.4.10 o superior).
# «always»: sin él, Apache solo añade cabeceras a las respuestas 2xx.
<IfModule mod_headers.c>
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"
</IfModule>.htaccess dentro de /tienda/# Solo /tienda/ devuelve 503; el resto de la web sigue en pie.
# En el VirtualHost sería lo mismo dentro de <Location /tienda/> … </Location>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteRule ^ - [R=503,L]
</IfModule>
ErrorDocument 503 /mantenimiento.html
<IfModule mod_headers.c>
Header always set Retry-After "7200" "expr=%{REQUEST_STATUS} == 503"
</IfModule># Limitar de verdad es cosa de un WAF o de mod_security. Pero si quieres frenar
# a un bot con 429 (que dice «vuelve luego») en vez de con 403 (que dice «fuera»):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot) [NC]
RewriteRule ^ - [R=429,L]
</IfModule>
<IfModule mod_headers.c>
Header always set Retry-After "600" "expr=%{REQUEST_STATUS} == 429"
</IfModule>LiteSpeed. Lee el .htaccess de Apache, pero no entero: LiteSpeed Enterprise entiende Header con always y con env=, pero no la condición expr= de Apache 2.4 (y una directiva que no reconoce no da error: simplemente no hace nada); OpenLiteSpeed solo lee las reglas de mod_rewrite. Así que aquí el estado y la cabecera los pone PHP: la regla reescribe a un script, y el script responde.
.htaccess, en la raíz o dentro de /tienda/# Mantenimiento: todo lo que no venga de tu IP se sirve desde mantenimiento.php,
# que es quien devuelve el 503 y la cabecera. Sin R=503, sin mod_headers y sin
# ErrorDocument: vale igual en LiteSpeed Enterprise y en OpenLiteSpeed
# (en OpenLiteSpeed, con «Auto Load from .htaccess» activado en Rewrite).
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/mantenimiento
RewriteRule ^ /mantenimiento.php [L]<?php
// 503 y Retry-After desde PHP: esto lo entiende cualquier servidor.
http_response_code(503);
header('Retry-After: 3600'); // segundos, o una fecha HTTP en GMT
header('Cache-Control: no-store'); // que ninguna caché se quede con el 503
header('Content-Type: text/html; charset=utf-8');
?>
<!doctype html>
<html lang="es">
<head><meta charset="utf-8"><title>Mantenimiento</title></head>
<body>
<h1>Volvemos en una hora</h1>
<p>Estamos haciendo cambios. Vuelve a intentarlo un poco más tarde.</p>
</body>
</html>.htaccess reescribe, limite.php contesta# El límite por IP de LiteSpeed (Per Client Throttling, en el WebAdmin) frena,
# pero no contesta 429 ni manda Retry-After: a las peticiones de más las deja
# esperando. Para decirle a un bot «vuelve en diez minutos», que lo diga PHP:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot) [NC]
RewriteCond %{REQUEST_URI} !^/limite\.php$
RewriteRule ^ /limite.php [L]<?php
http_response_code(429);
header('Retry-After: 600');
header('Content-Type: text/plain; charset=utf-8');
echo 'Demasiadas peticiones. Vuelve a intentarlo en diez minutos.';nginx. La cabecera se declara una sola vez con un map sobre $status: nginx no envía una cabecera cuyo valor quede vacío, así que Retry-After solo acompaña a los 503 y a los 429. El estado lo pone return o limit_req.
http { } y en el server { }# nginx no envía una cabecera cuyo valor esté vacío: con un map, Retry-After
# solo acompaña a los estados que la necesitan. Esto vale para todo lo de abajo.
map $status $retry_after {
503 3600; # mantenimiento: una hora
429 10; # límite de peticiones: diez segundos
default "";
}
server {
# …
add_header Retry-After $retry_after always; # «always»: también en los errores (1.7.5 o superior)
# Ojo: si una location tiene su propio add_header, no hereda este. Repítelo ahí.
}server { }# Se activa creando el archivo mantenimiento.flag en la raíz y se desactiva
# borrándolo: sin tocar la configuración ni recargar nginx.
set $mantenimiento 0;
if (-f $document_root/mantenimiento.flag) { set $mantenimiento 1; }
if ($remote_addr = 203.0.113.10) { set $mantenimiento 0; }
if ($mantenimiento) { return 503; }
error_page 503 @mantenimiento;
location @mantenimiento {
rewrite ^ /mantenimiento.html break;
}
# La página de mantenimiento, con el CSS incrustado: cualquier recurso aparte
# (una hoja de estilos, un logo) recibiría también el 503.location de /tienda/location /tienda/ {
set $mantenimiento 0;
if (-f $document_root/mantenimiento.flag) { set $mantenimiento 1; }
if ($remote_addr = 203.0.113.10) { set $mantenimiento 0; }
if ($mantenimiento) { return 503; }
# … lo que ya tuvieras aquí (try_files, fastcgi_pass…)
}
# El error_page 503 y el map de la cabecera del primer bloque ya cubren esto.# En http { }: una zona por IP, diez peticiones por segundo.
limit_req_zone $binary_remote_addr zone=porip:10m rate=10r/s;
# En el server { } o en la location que quieras proteger:
limit_req zone=porip burst=20 nodelay;
limit_req_status 429; # por defecto nginx responde 503, que es mentira (1.3.15 o superior)
# Con el map del primer bloque, cada 429 lleva Retry-After: 10Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de web.
Accede al Máster de SEO Técnico