Rastreo

Reducir a Google el rastreo por nuestra web

Reducir a Google el rastreo por nuestra web
Autor
Carlos Sánchez
Temática
Rastreo
Publicado
2026-10-07
Revisado
2026-10-07

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.

Rastreo en bing webmaster

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:

Problema con directivas ignoradas robots.txt

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:

bloqueo airbnb
Pero cuando usamos un servicio de Google, con el User-Agent de Google pero con el rango de IP de Google, podemos observar como nos deja pasar sin excesivos problemas.

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.

Todo el sitio · .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>
Solo un directorio · .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>
429 a un bot concreto · Apache no limita peticiones por sí solo
# 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>

Comprueba que la cabecera sale solo en el estado que toca, y desde una IP que no esté en tu lista blanca (el móvil sin wifi vale): curl -sI https://tu-dominio.com/ | grep -iE "^(HTTP|retry-after)"

Si te gusta este artículo, me ayudarías un montón compartiendo mi contenido:
Formación
No se te da mal el SEO técnico

Te 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
Tal vez te interesen otros artículos:
Artículos de SEO