Frecuencia de rastreo

TL;DR — La frecuencia de rastreo es la rapidez con la que un motor de búsqueda obtiene las páginas de tu sitio. Google la establece automáticamente según el estado de salud de tu servidor; ya no hay un botón para subirla o bajarla. Si tu servidor está recibiendo una carga excesiva, la solución es hacerlo más rápido (o, solo por uno o dos días, hacer que devuelva un error de “ralentización”). Rastrear más rápido no te ayuda a posicionarte.

Qué es la frecuencia de rastreo

Cuando un motor de búsqueda rastrea tu sitio, no obtiene todas las páginas a la vez; se autorregula. La frecuencia de rastreo es ese ritmo: cuántas páginas obtiene un rastreador por momento y cuánto espera entre obtenciones. Googlebot para Google, Bingbot para Bing. Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

El objetivo de este ritmo es la cortesía. Un rastreador podría saturar fácilmente un servidor pequeño si pidiera cientos de páginas por segundo, así que observa cómo responde tu sitio y retrocede cuando el servidor empieza a tener dificultades. Si respondes rápidamente, obtendrá páginas un poco más rápido; si reduces la velocidad o devuelves errores, rastreará menos.

El cambio más importante

Durante años, el consejo era “entra en Search Console y baja el control deslizante de la frecuencia de rastreo”. Ese control deslizante desapareció: Google lo eliminó el 8 de enero de 2024. Así que si encuentras un tutorial que te dice que lo ajustes, ese tutorial está desactualizado. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation

Hoy la frecuencia es automática. No la ajustas; Google lee las respuestas de tu servidor y decide.

Cómo ralentizar Googlebot

Si tu servidor realmente está sobrecargado, en orden de preferencia:

1. Haz que el servidor sea más rápido o dale más recursos. Esta es la solución real. Googlebot rastreará de forma natural un servidor saludable y rápido con mayor comodidad.
2. Solo para una verdadera emergencia: haz que tu servidor devuelva un error 500, 503 o 429 en lugar de la página normal. Google lo interpreta como “baja la velocidad” casi de inmediato. Pero haz esto durante uno o dos días como máximo — si lo dejas más tiempo, Google puede empezar a eliminar tus páginas de la búsqueda.

Lo que no debes hacer: no bloquees a Googlebot con errores 403/404 (eso no ralentiza el rastreo y conlleva el riesgo de perder páginas), y no confíes en la directiva crawl-delay de tu robots.txt — Google la ignora (Bing sí la respeta).

¿Puedes hacer que Google rastree más rápido?

No bajo demanda: no hay un botón de “rastrear más” y no puedes solicitar un aumento. Puedes fomentarlo indirectamente: un servidor más rápido, un sitemap limpio, buenos enlaces internos y eliminar las URLs duplicadas o basura: todo ayuda. Pero más rastreo no es un fin en sí mismo — no te hará posicionar mejor.

¿Quieres los detalles de los códigos de estado, el historial de obsolescencia y en qué se diferencia Bing? Cambia a la pestaña Avanzado.

TL;DR — La frecuencia de rastreo es el lado de la oferta del presupuesto de rastreo: la velocidad con la que un rastreador obtiene páginas, establecida por lo que Google denomina límite de capacidad de rastreo (conexiones paralelas

• retraso entre las solicitudes de obtención). Es automática y reacciona al estado de salud del servidor; el control deslizante manual de Google Search Console se eliminó el 8 de enero de 2024. Para ralentizar a Googlebot ahora, envía señales mediante HTTP: 500/503/429 durante 1–2 días como máximo, nunca 401/403/404, y Google ignora la directiva crawl-delay (Bing la respeta). No puedes solicitar un aumento; mejórala de forma indirecta. Bing todavía tiene una cuadrícula manual de Crawl Control. La frecuencia de rastreo no es un factor de posicionamiento, y la mayoría de los sitios nunca necesitan tocarla.

Qué es realmente la frecuencia de rastreo

La frecuencia de rastreo es la velocidad con la que un rastreador obtiene páginas de tu servidor: la cantidad de solicitudes simultáneas que realiza y el retraso entre ellas. El nombre que le da Google es límite de capacidad de rastreo: “the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (traducción) «el número máximo de conexiones paralelas simultáneas que Google puede usar para rastrear un sitio, así como el retraso entre las solicitudes de obtención.» Evidence for this claim Google defines crawl capacity using simultaneous connections and the delay between fetches, adjusted according to site responses. Scope: Google crawler capacity, not a ranking factor. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Es una mitad del presupuesto de rastreo. Como lo expreso en mi guía de presupuesto de rastreo de Ahrefs, el presupuesto de rastreo se divide en “crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (traducción) «la demanda de rastreo, que es cuántas páginas quiere rastrear un motor de búsqueda en tu sitio, y la frecuencia de rastreo, que es qué tan rápido puede rastrear». La frecuencia de rastreo es el lado de la oferta (qué tan rápido les permites rastrear); la demanda de rastreo es el lado de la demanda (cuánto quieren rastrear). El presupuesto de rastreo es donde ambos se encuentran — y las posiciones quedan completamente fuera de ese bucle.

En mi presentación How Search Works describo el límite de frecuencia de rastreo simplemente como lo que tu sitio puede soportar — está determinado por la estabilidad de tu servidor y la salud del rastreo, las respuestas lentas, los errores 5xx (de servidor) y las respuestas 429 (Too Many Requests). Google reduce el rastreo cuando tu servidor empieza a tener problemas porque no quiere provocar la caída de tu sitio. Un detalle que la gente pasa por alto: todos los Googlebots comparten un único grupo de rastreo — los bots de búsqueda, imágenes, anuncios, etc., todos consumen de la misma frecuencia. Así que un rastreo descontrolado de un tipo de recurso consume el rastreo de todo lo demás.

Qué establece la frecuencia de rastreo

El límite de capacidad es automático y reacciona a tu servidor en tiempo real. Google: “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traducción) «Si el sitio responde rápidamente durante un tiempo, el límite sube, lo que significa que se pueden usar más conexiones para rastrear. Si el sitio se ralentiza o responde con errores de servidor, el límite baja y Google rastrea menos.»

Hay una segunda palanca que no controlas: los recursos propios de Google. “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (traducción) «Google tiene muchas máquinas, pero no máquinas infinitas. Aún necesitamos tomar decisiones con los recursos que tenemos.» Por lo tanto, la salud de tu servidor establece el techo que Google está dispuesto a usar, pero la capacidad propia de Google y la demanda de rastreo de tu sitio deciden cuánto de ese techo se usa realmente.

El documento de mitos confirma que la relación con la salud del servidor funciona en ambos sentidos: “A speedy site is a sign of healthy servers, so it can get more content over the same number of connections,” (traducción) «Un sitio rápido es una señal de servidores saludables, por lo que puede obtener más contenido con el mismo número de conexiones», mientras que “a significant number of 5xx HTTP response status codes (server errors) or connection timeouts signal the opposite, and crawling slows down.” (traducción) «un número significativo de códigos de estado HTTP 5xx (errores del servidor) o tiempos de espera de conexión señalan lo contrario, y el rastreo se ralentiza».

¿La frecuencia de rastreo afecta el posicionamiento? No.

Desmonta esto primero, porque impulsa mucho esfuerzo equivocado. El rastreo es necesario para aparecer en la búsqueda, pero no es una señal de posicionamiento. Google es explícito: “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (traducción) «Mejorar tu frecuencia de rastreo no necesariamente conducirá a mejores posiciones en los resultados de Google Search.» Un rastreo más rápido o más frecuente te consigue un descubrimiento y una indexación más recientes, no posiciones más altas. La frecuencia de rastreo es una cuestión de eficiencia y de salud del servidor — y punto.

Cómo reducir la frecuencia de rastreo de Googlebot

En orden, desde la solución real hasta la palanca de emergencia:

1. Arregla el servidor (la solución real). Aceléralo o añade recursos. Dado que el límite de capacidad hace seguimiento del tiempo de respuesta y de los errores, un servidor más saludable es la forma duradera de mantener el rastreo en un rango cómodo, y es la que no pone en riesgo tu indexación.

2. La palanca de emergencia — 500/503/429. Google: _“return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traducción) «devuelve un código de estado HTTP 500, 503 o 429 en lugar de 200 a las solicitudes de rastreo». Sus rastreadores _“treat the 429 status code as a signal that the server is overloaded,” (traducción) «tratan el código de estado 429 como una señal de que el servidor está sobrecargado», y _“5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (traducción) «los errores del servidor 5xx y 429 hacen que los rastreadores de Google reduzcan temporalmente el rastreo». Gary Illyes expresó la velocidad de esto en términos concretos: _“if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (traducción) «si el servidor devuelve de forma persistente códigos de estado HTTP 500 para un rango de URL, Googlebot reducirá automáticamente, y casi de inmediato, el rastreo». Prefiere 429 cuando puedas — significa explícitamente «demasiadas solicitudes» y puede incluir un encabezado Retry-After.

El inconveniente es que esto es estrictamente temporal. Google: _“We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (traducción) «No recomendamos que hagas esto durante un periodo largo (es decir, más de 1-2 días)». Si lo dejas activado, el costo es real — si esos códigos persisten en la misma URL durante varios días, _“the URL may be dropped from Google’s index” (traducción) «la URL puede eliminarse del índice de Google» y, para Google Ads, _“your campaigns may be cancelled or paused, and your ads may not serve.” (traducción) «tus campañas pueden cancelarse o pausarse, y tus anuncios pueden no mostrarse».

3. Lo que NO debes hacer. No uses 4xx para limitar el rastreo. “The 4xx status codes, except 429, have no effect on crawl rate,” (traducción) «Los códigos de estado 4xx, excepto 429, no tienen efecto sobre la frecuencia de rastreo», y Google dice claramente “Don’t use 401 and 403 status codes for limiting the crawl rate.” (traducción) «No uses los códigos de estado 401 y 403 para limitar la frecuencia de rastreo». En una publicación dedicada de 2023 sobre personas que hacen exactamente esto, Google escribió: “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate. The short version of this blog post is: please don’t do that…” (traducción) «Durante los últimos meses hemos notado un aumento de propietarios de sitios web y algunas redes de entrega de contenido (CDN) que intentan usar 404 y otros errores de cliente 4xx (pero no 429) para intentar reducir la frecuencia de rastreo de Googlebot. La versión corta de esta publicación de blog es: por favor, no hagas eso…». Y no recurras a la directiva crawl-delay de robots.txt: “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (traducción) «La regla no estándar ‘crawl-delay’ de robots.txt no es procesada por los rastreadores de Google».

4. La solicitud no urgente. Para un problema continuo que no es una emergencia, puedes “file a special request to report a problem with unusually high crawl rate, mentioning the optimal rate for your site.” (traducción) «presentar una solicitud especial para informar de un problema con una frecuencia de rastreo inusualmente alta, mencionando la frecuencia óptima para tu sitio». Es lento y solo va en una dirección (ver abajo).

¿Puedes aumentar la frecuencia de rastreo? No — no directamente.

No existe un aumento manual. Google: _“You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (traducción) «No puedes solicitar un aumento de la frecuencia de rastreo, y pueden pasar varios días antes de que la solicitud se evalúe y se cumpla.» Lo que puedes hacer es mejorarla indirectamente. En mi guía de presupuesto de rastreo, las palancas que realmente mueven la eficiencia de rastreo son: acelera tu servidor / añade recursos; mantén las páginas importantes en sitemaps limpios; elimina el contenido duplicado; consigue más enlaces (externos e internos); corrige los enlaces con redirecciones; usa GET en lugar de POST donde sea posible; y usa la Indexing API cuando cumplas los requisitos. Ten en cuenta que “a speedy site… can get more content over the same number of connections” (traducción) «Un sitio rápido… puede obtener más contenido a través del mismo número de conexiones» — por lo que la salud del servidor es la palanca que aparece tanto del lado de la reducción como del aumento.

Cómo controlar la frecuencia de rastreo de Bingbot

Este es el marcado contraste entre motores. Donde Google retiró el control manual, Bing lo mantuvo. Bing Webmaster Tools tiene Crawl Control (en Configuration): una cuadrícula hora por hora donde cada hora muestra bloques que representan la velocidad de rastreo — más bloques significan un rastreo más rápido, menos bloques significan uno más lento. Puedes elegir un ajuste preestablecido basado en tus horas pico del negocio, o elegir “Custom” y dibujar tu propio patrón a lo largo del día. Bing también sigue respetando la directiva crawl-delay en robots.txt — la directiva exacta que Google ignora. Así que la regla general para dos motores: para Google, envías señales a través de las respuestas del servidor; para Bing, tienes un control real.

¿Qué pasó con la herramienta de frecuencia de rastreo de Search Console?

La cronología, porque muchos consejos todavía hacen referencia a una herramienta que ya no existe:

• dic 2008 — Google introduce el control de frecuencia de rastreo para usuarios en Webmaster Tools.
• feb 2023 — Google publica “don’t use 403s or 404s for rate limiting.” (traducción) «no uses 403 ni 404 para la limitación de frecuencia».
• 24 nov 2023 — Google anuncia la descontinuación de Crawl Rate Limiter Tool. El razonamiento de Illyes: “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (traducción) «con las mejoras que hemos hecho a nuestra lógica de rastreo y a otras herramientas disponibles para los editores, su utilidad se ha disipado». La herramienta antigua era lenta y apenas se usaba — tenía “a much slower effect” (traducción) «un efecto mucho más lento» y “would have taken over a day for the new limits to be applied on crawling,” (traducción) «habría tardado más de un día en que los nuevos límites se aplicaran al rastreo,» y se usaba “rarely,” (traducción) «rara vez,» y quienes lo hacían “in many cases set the crawling speed to the bare minimum.” (traducción) «en muchos casos configuraban la velocidad de rastreo al mínimo absoluto».
• 8 ene 2024 — la herramienta se elimina. Evidence for this claim Google deprecated the Search Console crawl-rate limiter and removed it on January 8, 2024. Scope: Google Search Console's legacy crawl-rate limiter. Confidence: high · Verified: 2026-07-14 Google: Crawl rate limiter deprecation Google también redujo el mínimo: “With the deprecation of the crawl limiter tool, we’re also setting the minimum crawling speed to a lower rate, comparable to the old crawl rate limits.” (traducción) «Con la descontinuación de la herramienta de limitación de rastreo, también estamos estableciendo la velocidad mínima de rastreo en una frecuencia más baja, comparable a los antiguos límites de frecuencia de rastreo».

La consecuencia práctica: el antiguo control deslizante manual tenía un retraso de más de 24 horas de todos modos; el enfoque actual de señales del servidor (5xx/429) ralentiza a Googlebot casi inmediatamente, lo cual es estrictamente mejor para una emergencia real.

Cómo supervisar la frecuencia de rastreo

El Crawl Stats report de GSC es tu ventana a lo que Google está haciendo realmente: total de solicitudes de rastreo a lo largo del tiempo, tamaño total de descarga, tiempo de respuesta promedio y una vista de host status de la disponibilidad de tu sitio para Google durante los últimos ~90 días, además de un desglose por código de respuesta, tipo de archivo, propósito de rastreo y tipo de Googlebot. Vigila el tiempo de respuesta promedio y las señales de host status: un tiempo de respuesta en aumento o una oleada de 5xx es exactamente lo que hace que Googlebot te limite, así que este informe es donde verás una ralentización autoinfligida antes de salir a buscar una. En Bing, Crawl Control y la información de rastreo en Bing Webmaster Tools son los equivalentes.

Frecuencia de rastreo vs presupuesto de rastreo vs frecuencia de rastreo

Ten claros estos conceptos:

• Frecuencia de rastreo = qué tan rápido (oferta / capacidad).
• Demanda de rastreo = cuánto quieren (popularidad + obsolescencia).
• Presupuesto de rastreo = la interacción de ambos — “the amount of time and resources a search engine allows for crawling a website.” (traducción) «la cantidad de tiempo y recursos que un motor de búsqueda permite para el rastreo de un sitio web.»
• Frecuencia de rastreo = con qué frecuencia se vuelve a rastrear una página determinada, lo que es principalmente una cuestión de demanda de rastreo (popularidad y lo fresca u obsoleta que sea la página).

Y la parte tranquilizadora, que es mi postura habitual: la mayoría de los sitios no tienen que preocuparse por nada de esto. “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look” (traducción) «La mayoría de los sitios no tienen que preocuparse por el presupuesto de rastreo, pero hay pocos casos en los que puede que quieras echar un vistazo» — sitios más nuevos con muchas páginas, sitios muy grandes o que cambian rápidamente, y sitios con un montón de URL «Discovered – currently not indexed» en GSC. Si ese no es tu caso, deja en paz la frecuencia de rastreo y deja que la automatización de Google haga su trabajo.

Resumen de IA

Una perspectiva condensada de la versión Advanced:

• Frecuencia de rastreo = con qué rapidez un rastreador obtiene páginas — el «límite de capacidad de rastreo» (conexiones paralelas + demora entre solicitudes). Es el lado de la oferta del presupuesto de rastreo; la demanda de rastreo es el lado de la demanda.
• Es automática y reacciona al estado de salud del servidor: servidor rápido/en buen estado → límite más alto; respuestas lentas o 5xx/429 → Google rastrea menos. La propia capacidad de Google es un segundo límite que no controlas. Todos los Googlebots comparten un único pool de rastreo.
• El control deslizante manual de frecuencia en GSC se eliminó el 8 de enero de 2024. Los consejos que te dicen que «ajustes el control deslizante» están desactualizados.
• Para ralentizar a Googlebot hoy: arregla el servidor (mejor), o devuelve 500/503/429 durante 1–2 días como máximo (más tiempo conlleva riesgo de desindexación + pausa de Ads). Prefiere 429 (incluye Retry-After). Nunca uses 401/403/404, y la directiva crawl-delay es ignorada por Google.
• No puedes solicitar un aumento. Mejórala indirectamente: servidor más rápido, sitemaps limpios, menos URL duplicadas/basura, más enlaces internos + externos, Indexing API cuando corresponda.
• Bing conservó el control manual: cuadrícula por horas de Crawl Control + directiva crawl-delay respetada.
• La frecuencia de rastreo no es un factor de posicionamiento — “improving your crawl rate won’t necessarily lead to better positions.” (traducción) «mejorar tu frecuencia de rastreo no conducirá necesariamente a mejores posiciones.» La mayoría de los sitios nunca necesita gestionarla.

Documentación oficial

Documentación de fuentes primarias de los motores de búsqueda.

Google

• Reduce la frecuencia de rastreo de Googlebot — la guía principal: 500/503/429, el límite de 1–2 días y el formulario de solicitud (puedes reducirlo, no aumentarlo).
• Gestión del presupuesto de rastreo — define el límite de capacidad de rastreo y cómo reacciona al estado de salud del servidor.
• Cómo afectan los códigos de estado HTTP a los rastreadores de Google — exactamente qué códigos limitan el rastreo (5xx/429) y cuáles no (4xx excepto 429).
• Mitos y hechos sobre el rastreo — crawl-delay no se procesa; la frecuencia de rastreo ≠ las posiciones; el estado de salud del servidor afecta el rastreo.
• Próxima obsolescencia de la Herramienta de limitación de la frecuencia de rastreo (nov 2023) — el anuncio de obsolescencia.
• No uses 403s ni 404s para la limitación de frecuencia (feb 2023) — por qué 4xx es el mecanismo incorrecto.
• Estadísticas de rastreo nuevas y mejoradas para tu sitio (nov 2020) — cómo leer el Crawl Stats report.
• Optimiza tu presupuesto de rastreo — capacidad + demanda de rastreo, y quién realmente lo necesita.

Bing / Microsoft

• Bing Webmaster Tools — Control de rastreo — la cuadrícula manual de frecuencia de rastreo hora por hora que Google retiró.
• Orientación de Bingbot — la orientación actual de Bing Webmaster documenta valores de la directiva crawl-delay de 1 a 20 segundos.
• Serie de Bingbot: optimización de la frecuencia de rastreo (octubre de 2018) — la postura de Bing sobre cuándo volver a rastrear.

Citas de la fuente

Declaraciones oficiales de Google. Cada enlace es un enlace profundo que salta al fragmento citado en la página de origen.

Google — qué es la frecuencia de rastreo y qué la establece

• “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traducción) «Si el sitio responde rápidamente durante un tiempo, el límite aumenta, lo que significa que se pueden usar más conexiones para rastrear. Si el sitio se ralentiza o responde con errores de servidor, el límite disminuye y Google rastrea menos.» — Gestión del presupuesto de rastreo. Ir a la cita
• “Google has a lot of machines, but not infinite machines. We still need to make choices with the resources that we have.” (traducción) «Google dispone de muchas máquinas, aunque no de una cantidad infinita; aun así debe escoger cómo emplear los recursos disponibles.» Ir a la cita

Google — cómo reducir la frecuencia de rastreo

• “return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traducción) «devuelve el código de estado de respuesta HTTP 500, 503 o 429 en lugar de 200 a las solicitudes de rastreo.» — Reduce la frecuencia de rastreo de Googlebot. Ir a la cita
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days).” (traducción) «No recomendamos que hagas esto durante un período de tiempo prolongado (es decir, más de 1-2 días).» Ir a la cita
• “You cannot request an increase in crawl rate, and it may take several days for the request to be evaluated and fulfilled.” (traducción) «No puedes solicitar un aumento de la frecuencia de rastreo, y la solicitud puede tardar varios días en evaluarse y cumplirse.» Ir a la cita

Google — qué códigos de estado limitan el rastreo

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traducción) «Los rastreadores de Google tratan el código de estado 429 como una señal de que el servidor está sobrecargado, y se considera un error del servidor.» — Cómo afectan los códigos de estado HTTP a los rastreadores de Google. Ir a la cita
• “The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «Los códigos de estado 4xx, excepto el 429, no tienen ningún efecto sobre la frecuencia de rastreo.» / “Don’t use 401 and 403 status codes for limiting the crawl rate.” (traducción) «No uses los códigos de estado 401 y 403 para limitar la frecuencia de rastreo.» Ir a la cita

Google — directiva crawl-delay y posicionamiento

• “The non-standard ‘crawl-delay’ robots.txt rule is not processed by Google’s crawlers.” (traducción) «La directiva no estándar ‘crawl-delay’ de robots.txt no es procesada por los rastreadores de Google.» — Mitos y hechos sobre el rastreo. Ir a la cita
• “Improving your crawl rate won’t necessarily lead to better positions in Google Search results.” (traducción) «Mejorar tu frecuencia de rastreo no necesariamente conducirá a mejores posiciones en los resultados de búsqueda de Google.» Ir a la cita

Gary Illyes, Google (sobre la desaprobación de la herramienta de frecuencia de rastreo)

• “if the server persistently returns HTTP 500 status codes for a range of URLs, Googlebot will automatically, and almost immediately slow down crawling.” (traducción) «si el servidor devuelve de forma persistente códigos de estado HTTP 500 para un rango de URL, Googlebot ralentizará automáticamente, y casi de inmediato, el rastreo.» Leer la cobertura
• “with the improvements we’ve made to our crawling logic and other tools available to publishers, its usefulness has dissipated.” (traducción) «con las mejoras que hemos hecho en nuestra lógica de rastreo y otras herramientas disponibles para editores, su utilidad se ha disipado.» Leer la cobertura

Listas de verificación de la frecuencia de rastreo

Reduce de forma segura la frecuencia de rastreo de Googlebot (en orden)

• Primero, confirma que el rastreador es el problema real — consulta GSC Crawl Stats (tiempo de respuesta promedio, host status) y los registros de tu servidor, no solo una corazonada.
• Corrige la causa raíz: acelera el servidor o añade recursos. Esta es la solución duradera y la única que no pone en riesgo la indexación.
• Si se trata de una emergencia genuina, devuelve 500/503/429 a las solicitudes de rastreo (prefiere 429 con un Retry-After). Googlebot se ralentiza casi de inmediato.
• Mantén la respuesta de emergencia activada 1–2 días como máximo — más tiempo conlleva el riesgo de que se eliminen páginas del índice y se pausen los anuncios.
• Para un problema continuo (que no es una emergencia), envía la solicitud especial de frecuencia de rastreo de Google, indicando la frecuencia óptima para tu sitio.
• Para Bing, configura la velocidad en Crawl Control y/o añade la directiva crawl-delay a robots.txt.

No hagas lo siguiente

• No uses 401/403/404 para limitar — no tiene efecto sobre la frecuencia, y corres el riesgo de perder páginas.
• No confíes en la directiva crawl-delay de robots.txt para Google — se ignora (Bing lo respeta).
• No busques el antiguo control deslizante de frecuencia de rastreo de GSC: se eliminó el 8 de enero de 2024.

Cuando quieres más rastreo (no puedes forzarlo — mejóralo indirectamente)

• Acelera / añade recursos al servidor.
• Mantén las URL canónicas e indexables en sitemaps limpios con lastmod precisos.
• Elimina las URL duplicadas y de bajo valor que desperdician el rastreo.
• Fortalece los enlaces internos y consigue más enlaces externos.
• Usa GET en lugar de POST siempre que sea posible; usa la Indexing API donde sea elegible.

Frecuencia de rastreo — hoja de referencia

Códigos de estado y cómo afectan la frecuencia de rastreo de Google

Datos rápidos

• Frecuencia de rastreo = qué tan rápido (oferta); demanda de rastreo = cuánto lo desean (demanda); presupuesto de rastreo = ambas cosas juntas.
• Término de Google: crawl capacity limit — conexiones paralelas + demora entre solicitudes. Automático, se ajusta al estado del servidor.
• Ventana de emergencia para 5xx/429: 1–2 días como máximo — más tiempo implica riesgo de desindexación + pausa de Ads.
• Sin aumento manual — solo puedes pedirle a Google que la reduzca, nunca que la aumente.
• Control deslizante manual de frecuencia de rastreo en GSC: eliminado el 8 de enero de 2024 (anunciado el 24 de noviembre de 2023).
• Todos los Googlebots comparten un único grupo de rastreo (búsqueda, imágenes, anuncios, etc.).
• La frecuencia de rastreo no es un factor de posicionamiento.
• Equivalente en Bing: cuadrícula de Crawl Control + se respeta crawl-delay.

Indícale temporalmente a Googlebot que reduzca la velocidad

Esta es solo una palanca de emergencia: devuelve un 503 (o 429) con un encabezado Retry-After al rastreador en lugar de un 200. Google lo interpreta como «reducir la velocidad» casi de inmediato. Mantén esta respuesta durante uno o dos días como máximo: si la dejas más tiempo, las URL afectadas pueden eliminarse del índice (y cualquier anuncio de Google Ads que apunte a ellas puede pausarse). La solución correcta a largo plazo es un servidor más rápido y saludable, no una respuesta de error permanente.

Apache (.htaccess) — devolver 503 con Retry-After

# Emergency only — remove within 1–2 days.
# Sends Googlebot a "slow down / try later" signal.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Googlebot|bingbot) [NC]
RewriteRule ^ - [R=503,L]
Header always set Retry-After "3600"
ErrorDocument 503 "Server temporarily overloaded — please retry later."

Nginx — devolver 503 con Retry-After para rastreadores

# Emergency only — remove within 1–2 days.
if ($http_user_agent ~* (Googlebot|bingbot)) {
    return 503;
}
# Send a Retry-After hint with the 503 response.
add_header Retry-After 3600 always;

Express / Node.js — 429 Too Many Requests con Retry-After

// Emergency only — remove within 1–2 days.
// 429 explicitly means "too many requests" and carries a Retry-After.
app.use((req, res, next) => {
  const ua = req.get("user-agent") || "";
  if (/Googlebot|bingbot/i.test(ua)) {
    res.set("Retry-After", "3600"); // seconds
    return res.status(429).send("Too many requests — please retry later.");
  }
  next();
});

Recordatorio: esto solo ralentiza el rastreo temporalmente. No es una forma de pausar o bloquear la indexación, y no es un sustituto de solucionar la capacidad del servidor.

Herramientas para ver y controlar la frecuencia de rastreo

• Google Search Console — Crawl Stats report — la visión del propio Google: total de solicitudes de rastreo a lo largo del tiempo, tamaño total de descarga, tiempo de respuesta promedio, host status (disponibilidad del sitio para Google durante ~90 días) y desgloses por código de respuesta, tipo de archivo, propósito de rastreo y tipo de Googlebot. Aquí es donde verás la limitación.
• Bing Webmaster Tools — Crawl Control — la cuadrícula manual hora por hora (con ajustes preestablecidos o dibujada de forma personalizada) para configurar la velocidad de Bingbot por hora del día. La palanca manual que Google retiró.
• robots.txt crawl-delay — respetado por Bing (y algunos otros motores), ignorado por Google. Útil para Bing, inútil para Google.
• Análisis de archivos de registro del servidor — la fuente de verdad sobre con qué rapidez los rastreadores realmente acceden a tu sitio y qué códigos de estado reciben. (Consulta log file analysis.)
• Auditorías de sitio / rastreadores — Ahrefs Site Audit y Screaming Frog SEO Spider para encontrar las URL duplicadas, parametrizadas y similares a trampas que desperdician el rastreo.

¿Qué deberías hacer con la frecuencia de rastreo?

Manual de actuación ante incidentes: el tráfico de rastreadores está sobrecargando el origen

1. Verifica el bot. Confirma que la IP de origen pertenezca al rastreador declarado. Si no es así, bloquea o limita la frecuencia del suplantador mediante controles de seguridad normales.
2. Mide el impacto. Correlaciona las solicitudes del rastreador con latencia, saturación, tiempos de espera y respuestas 5xx. Si no se corresponden, investiga la fuente real de carga.
3. Protege la disponibilidad. Descarta solo el tráfico necesario; para una emergencia temporal de Googlebot, usa 429 o 503, no 403 o 404.
4. Encuentra los patrones problemáticos. Agrupa las solicitudes por directorio, parámetros, código de respuesta y bytes. Si un espacio de URL descontrolado domina, corrige sus enlaces o reglas de generación.
5. Repara la causa. Aumenta la capacidad, almacena en caché las respuestas seguras, elimina las trampas para rastreadores o usa los controles compatibles del rastreador específico.
6. Restaura y verifica. Elimina la limitación temporal y luego confirma que la latencia del usuario y las tasas de error del rastreador vuelvan a la línea base del sitio.

Errores de frecuencia de rastreo

• Usar la directiva crawl-delay para Googlebot. Google la ignora. Usa respuestas temporales 429/503 solo para una emergencia y corrige la carga subyacente.
• Devolver 403 o 404 para ralentizar a Googlebot. Esos códigos de estado comunican acceso o ausencia, no una sobrecarga temporal. Usa la señal temporal correcta.
• Intentar forzar un aumento permanente. El control deslizante retirado de Search Console ya no existe, y más rastreo no mejora las posiciones. Mejora la salud del servidor y las señales de demanda.
• Confiar en la cadena del agente de usuario (user-agent). Los suplantadores pueden afirmar ser Googlebot. Verifica la IP antes de cambiar el comportamiento del sitio.
• Dejar activada la limitación de emergencia. Los errores prolongados pueden perjudicar el rastreo y la indexación. Asigna un responsable y una condición de retirada antes del despliegue.

El marco verificar → proteger → reparar

• Verificar: demuestra que el tráfico es un rastreador real y que se correlaciona con un daño al servidor.
• Proteger: usa el control temporal más restrictivo que preserve la disponibilidad del usuario y comunique el significado HTTP correcto.
• Reparar: elimina el cuello de botella de capacidad o el espacio de URL descontrolado, luego retira el control temporal.

Mantén la frecuencia de rastreo separada de la demanda de rastreo: un servidor en buen estado puede elevar el límite de capacidad, pero no puede forzar a un motor de búsqueda a querer más URL.

Demuestra que una intervención de frecuencia de rastreo funcionó

Respuesta de limitación temporal

Prueba que se debe ejecutar: solicita una URL de prueba con limitación de frecuencia mediante curl -I. Resultado esperado: el 429 o 503 planificado aparece solo durante el incidente y las URL normales permanecen disponibles. Interpretación del fallo: la regla tiene un ámbito incorrecto o se está devolviendo el código de estado incorrecto. Ventana de supervisión: inmediata. Activador de reversión: los usuarios o los bots no relacionados reciben la limitación de frecuencia de forma inesperada.

Recuperación después de eliminar la limitación de frecuencia

Prueba que se debe ejecutar: repite las comprobaciones de encabezados y supervisa el servidor y los registros de acceso. Resultado esperado: vuelven las respuestas 200 normales, disminuyen los errores del rastreador y la latencia del usuario se mantiene en el nivel de referencia. Interpretación del fallo: la regla temporal permanece activa o el problema de capacidad persiste. Ventana de supervisión: inmediata para el comportamiento HTTP; continúa durante la siguiente ventana de rastreo normal. Activador de reversión: una saturación renovada o errores 5xx requieren volver al plan de incidente.

Reparación del espacio de URL

Prueba que se debe ejecutar: rastrea y comprueba en los registros el patrón de parámetro o ruta que causó un exceso de solicitudes. Resultado esperado: las nuevas URL trampa ya no se generan ni se enlazan, mientras que las URL valiosas permanecen accesibles. Interpretación del fallo: otra ruta de descubrimiento aún expone el patrón. Ventana de supervisión: compara ventanas de registros equivalentes. Activador de reversión: las páginas valiosas o los recursos requeridos se vuelven inaccesibles.

Métricas para la salud de la frecuencia de rastreo

Frecuencia de solicitudes de rastreadores verificados

Métrica: solicitudes por unidad de tiempo provenientes de direcciones IP de rastreadores verificados. Qué te indica: el ritmo real del rastreador. Cómo obtenerla: registros de acceso tras la verificación de bots. Punto de referencia / rango realista: establece una línea base por rastreador y periodo de tráfico; no existe una frecuencia segura universal. Cadencia: diaria durante incidentes, mensual en caso contrario.

Tasa de errores y latencia correlacionada con el rastreador

Métrica: 5xx/timeouts y latencia del origen durante la actividad del rastreador. Qué te indica: si la frecuencia excede la capacidad. Cómo obtenerla: alinea la telemetría del servidor con las marcas de tiempo de los registros del rastreador. Punto de referencia / rango realista: usa la línea base normal del sitio fuera de incidentes y los objetivos de capacidad. Cadencia: alertas continuas para sitios críticos.

Proporción de solicitudes útiles

Métrica: solicitudes de rastreadores verificados a páginas 200 valiosas frente a redirecciones, errores y URL trampa conocidas. Qué te indica: si la capacidad se usa productivamente. Cómo obtenerla: clasifica las URL y los códigos de estado de los registros. Punto de referencia / rango realista: observa la tendencia frente al inventario del propio sitio; evita un objetivo universal. Cadencia: mensual.

Pon a prueba tus conocimientos: Frecuencia de rastreo

Recursos que vale la pena consultar

Mis artículos relacionados

• ¿Cuándo deberías preocuparte por el presupuesto de rastreo? — la frecuencia de rastreo como una mitad del presupuesto de rastreo, además de las palancas para reducirlo o aumentarlo.
• ¿Qué es Googlebot y cómo funciona? — cómo decide Googlebot con qué rapidez y qué rastrear (y por qué “change crawl rate” ahora está obsoleto).
• La guía para principiantes de SEO técnico — dónde encajan el rastreo y la frecuencia de rastreo en el panorama general.

Mis ponencias

• cómo funciona la búsqueda (SlideShare) — donde enmarco el límite de frecuencia de rastreo como “what your site can support” (traducción) «lo que tu sitio puede soportar» y señalo que todos los Googlebots comparten un único pool de rastreo. (Aviso permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100% completa ni precisa».)

De otros

• Search Engine Land — La herramienta de frecuencia de rastreo de Googlebot desaparecerá y la herramienta ya ha desaparecido — la deprecación, con el razonamiento de Illyes.
• La serie Crawling December de Google — el mejor conjunto concentrado de explicaciones oficiales sobre el rastreo.
• Search Engine Journal — Google elimina la herramienta limitadora de frecuencia de rastreo de Search Console — la difusión de Roger Montti de la deprecación de noviembre de 2023, con el detalle de la nueva velocidad mínima de rastreo establecida automáticamente.
• Search Engine Journal — No uses respuestas de error 403/400 para limitar la frecuencia de Googlebot — cubre la publicación de blog de Google de febrero de 2023 que advierte contra el uso de 4xx para ralentizar el rastreo.
• Bing Webmaster Blog — Serie Bingbot: optimización de la frecuencia de rastreo — la propia explicación de Bing sobre cuándo y cómo decide Bingbot volver a recuperar; un útil contrapunto al enfoque automático de Google.
• Bing Webmaster Blog — Aprovechar al máximo Bingbot mediante Bing Webmaster Tools — cómo usar Crawl Control y otros ajustes de BWT para gestionar la frecuencia de rastreo de Bingbot.

Registro de cambios