Error 429 Too Many Requests

TL;DR — Un 429 Too Many Requests significa que su servidor le dijo a un visitante o a un bot: «está pidiendo demasiadas páginas demasiado rápido, vaya más despacio». A eso se le llama limitación de frecuencia (rate limiting). La buena noticia para el SEO: el 429 es el único error de su familia que Google gestiona con delicadeza. En lugar de descartar sus páginas, Googlebot simplemente afloja y le rastrea más despacio durante un tiempo. Solo se convierte en un problema si su servidor sigue enviando 429 durante días.

Qué dice realmente un 429

Cada vez que un navegador, un script o el rastreador de un buscador le pide una página a su servidor, el servidor responde con un código de estado. 200 significa «aquí tiene la página». Un 429 significa «ha hecho demasiadas peticiones en poco tiempo, así que no voy a responder a esta: vuelva más tarde».

Los servidores usan el 429 a propósito para protegerse. Si un visitante (o un bot) está machacando el sitio lo bastante rápido como para ralentizarlo para todos los demás, devolver un 429 es la forma que tiene el servidor de decir para un poco. Una respuesta 429 bien construida también incluye una cabecera Retry-After: una indicación que le dice al cliente cuántos segundos debe esperar antes de volver a intentarlo. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Por qué el 429 es el error «amable» para el SEO

Esta es la parte que sorprende a la gente. El 429 pertenece al grupo de «errores de cliente 4xx», justo al lado de códigos como 403 Forbidden y 404 Not Found. Esos dos son malas noticias si Google los sigue viendo: acaba eliminando esas páginas de la búsqueda.

El 429 es la excepción. Google interpreta un 429 como el servidor está ocupado, ve más despacio, igual que interpreta un error de servidor 503 o 500. Así que, en lugar de eliminar sus páginas, Googlebot simplemente rastrea su sitio más despacio durante un tiempo. De hecho, Google recomienda el 429 como la forma correcta de ralentizar un rastreador, y advierte específicamente contra el uso del 403 o el 404 para hacerlo. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Cuándo el 429 se convierte en un problema

Un 429 puntual es completamente normal y se corrige solo: en cuanto su servidor deja de enviarlos, Google vuelve a acelerar el rastreo por su cuenta. No hay que pedir nada.

El peligro aparece cuando los 429 se prolongan. Si Googlebot sigue encontrando 429 en las mismas páginas durante más de uno o dos días, Google puede empezar a eliminar esas páginas de su índice, porque desde su lado parece que su sitio lleva días roto y no disponible. Así que el 429 es una herramienta a corto plazo, no una configuración permanente.

Qué conviene hacer al respecto

• Si no pretendía enviar 429s (aparecen por sorpresa en Google Search Console o en su herramienta de rastreo), algo está limitando la frecuencia de forma demasiado agresiva: a menudo un plugin de seguridad, un cortafuegos (WAF) o su hosting/CDN. Localícelo y afloje el límite para que deje de bloquear a los buscadores reales.
• Si sí pretendía enviarlos —por ejemplo, porque su servidor está muy cargado—, no pasa nada: solo póngale un plazo y añada una cabecera Retry-After. Desactívelo en uno o dos días.

¿Quiere el paso a paso de configuración del servidor, la redacción exacta de Google y los mitos que la gente repite mal? Cambie a la pestaña Avanzado.

TL;DR — El 429 es el único código 4xx que Google trata como un 5xx: en cuanto encuentra un número significativo de respuestas 500/503/429, lo interpreta como una señal de sobrecarga del servidor y reduce la frecuencia de rastreo de Googlebot en todo el nombre de host en lugar de eliminar contenido. Es el único código que Google avala para ralentizar un rastreador: nunca 403 ni 404. La documentación de Google da una recomendación de uso en emergencias de «a couple of hours, or 1–2 days» (traducción: «un par de horas, o 1–2 días»), no una ventana segura garantizada; los 429 sostenidos en las mismas URL arriesgan que esas URL acaben siendo eliminadas del índice, y la frecuencia limitada vuelve a aumentar (no necesariamente de forma inmediata ni completa) en cuanto baja el volumen de errores. El RFC 6585 dice que un 429 SHOULD explicar la condición y MAY incluir Retry-After: enviarlo es una práctica recomendada, no un requisito de cumplimiento. Acote el límite al tráfico adecuado y verifique la identidad del rastreador antes de escribir excepciones.

Qué es un 429 a nivel de protocolo

Directamente de la especificación, tal y como lo formula MDN: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (traducción) «La respuesta HTTP 429 señala que el cliente envió demasiadas solicitudes en un intervalo determinado; pedirle que reduzca el ritmo se conoce normalmente como ‘rate limiting’.» Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

El §4 del RFC 6585 es más preciso de lo que reflejan la mayoría de sus resúmenes. Una representación 429 SHOULD (debería) explicar la condición y MAY (puede) incluir una cabecera Retry-After que le dé al cliente un número concreto de segundos (el RFC 9110 también admite una fecha HTTP) que esperar antes de reintentar: Retry-After es una práctica recomendada, no un requisito de cumplimiento. La especificación tampoco define cómo se identifica a un cliente ni cómo se cuentan las peticiones; eso queda enteramente en manos de quien haya emitido la respuesta (por IP, por sesión, por clave de API, por recurso: política de implementación, no de protocolo). Otra regla que es fácil pasar por alto: el RFC 6585 dice que una respuesta 429 no debe ser almacenada por una caché (no debe ser almacenada por una caché). Si ve un 429 que parece cacheado o repetido sobre un origen sano, es un intermediario (CDN, proxy) que se está portando mal, no el origen que vuelve a decidir limitarle.

Siempre lo he planteado de forma directa en mi guía Códigos de estado HTTP y su impacto en el SEO: el 429 es “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (traducción) «una forma de limitación de frecuencia para proteger el servidor porque el cliente envió demasiadas peticiones al servidor demasiado rápido». Nominalmente es un error de cliente: el cliente hizo algo mal al pedir demasiado. Pero ese encuadre es exactamente donde la historia del SEO se separa de la especificación.

La única excepción entre los códigos 4xx

El dato más importante de esta página: Google no trata el 429 como al resto de la familia 4xx. Gary Illyes escribió una entrada entera sobre esto en el blog de Google Search Central en febrero de 2023, porque había suficientes sitios y CDN usando mal los 404s para limitar a Googlebot como para que Google tuviera que pedirles que dejaran de hacerlo.

Su regla: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (traducción) «El 429 es la excepción y significa ‘demasiadas solicitudes’: para un robot bien comportado, incluido Googlebot, es una señal inequívoca de que debe bajar el ritmo porque está saturando el servidor». Y la otra cara, en la referencia de códigos de estado de Google: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «No emplees los estados 401 y 403 para frenar el rastreo: salvo el 429, los estados 4xx no modifican la frecuencia de rastreo».

Así que, en el mismo movimiento en el que un 403 y un 404 harán que su contenido sea eliminado de la Búsqueda, el 429 le supone una ralentización temporal. Google lo agrupa literalmente con los errores de servidor: “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 de servidor». Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Esto es lo que convierte al 429 en el hermano útil del 503 Service Unavailable (la señal tradicional de mantenimiento o indisponibilidad temporal), y en lo exactamente opuesto al 403 Forbidden, que es la herramienta equivocada para la limitación de frecuencia por muchos cortafuegos que lo usen por defecto.

El impacto en la frecuencia de rastreo abarca todo el nombre de host, con un umbral

Aquí se mezclan dos ámbitos distintos y conviene separarlos. Cómo cuenta y agrupa usted un límite de frecuencia —por IP, por sesión, por clave de API, por recurso, por servidor— es su propia política; la especificación HTTP no lo define. Lo que Google hace con los errores que observa es un comportamiento distinto y documentado, y está condicionado al volumen, no a una única respuesta: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (traducción) «La infraestructura de rastreo de Google reduce la frecuencia de rastreo de tu sitio cuando encuentra un número significativo de URL con códigos de estado de respuesta HTTP 500, 503 o 429». Una vez alcanzado ese umbral, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (traducción) «la frecuencia de rastreo reducida afecta a todo el nombre de host de tu sitio (por ejemplo, subdomain.example.com), tanto al rastreo de las URL que devuelven errores como al de las URL que devuelven contenido».

Dicho de otro modo: si devuelve 429 en un subconjunto de páginas (pongamos, una ruta de API pesada) con volumen real, Googlebot ralentiza el rastreo del conjunto del nombre de host, incluidas las páginas que siguen devolviendo 200. Ese suele ser el efecto buscado cuando su objetivo es reducir la carga total. Pero un 429 aislado en una sola ruta, por sí solo, no establece ese efecto sobre todo el nombre de host: la propia redacción de Google está acotada a «a significant number» (traducción: «un número significativo») de respuestas de error, no a una cualquiera.

La guía de 1–2 días: cuándo el 429 se vuelve arriesgado

El 429 es una señal a corto plazo, y Google da una guía concreta para su uso en emergencias, no una ventana segura garantizada ni un límite tajante. De la documentación de «reduce crawl rate»: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traducción) «Si necesitas reducir urgentemente la frecuencia de rastreo durante un periodo corto de tiempo (por ejemplo, un par de horas, o 1-2 días), devuelve el código de estado de respuesta HTTP 500, 503 o 429 en lugar de 200 a las peticiones de rastreo».

Si va más allá, entra en un terreno más arriesgado, aunque Google lo plantea como una posibilidad, no como una promesa: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (traducción) «No recomendamos que hagas esto durante un periodo largo de tiempo (es decir, más de 1-2 días), ya que puede tener un efecto negativo en cómo aparece tu sitio en los productos de Google… si Googlebot observa estos códigos de estado en la misma URL durante varios días, la URL puede ser eliminada del índice de Google». La referencia de códigos de estado dice lo mismo para los 5xx y el 429 conjuntamente: “already indexed URLs are preserved in the index, but eventually dropped.” (traducción) «las URL ya indexadas se conservan en el índice, pero acaban siendo eliminadas».

El modelo de riesgo, dicho con honestidad: un 429 de corta duración encaja en la ventana que Google recomienda para uso de emergencia; un 429 sostenido en las mismas URL durante varios días es donde el propio lenguaje de Google pasa a «may» y «eventually dropped» (traducción: «puede» y «acaban siendo eliminadas»): un riesgo documentado, no un resultado garantizado en ninguno de los dos sentidos. Es la misma dinámica que un 503 prolongado.

La frecuencia de rastreo se recupera automáticamente

La cara tranquilizadora: no hay ninguna marca de penalización que persiga a su sitio. Una vez que los errores remiten, Google dice que “the crawl rate will automatically start increasing again.” (traducción) «la frecuencia de rastreo empezará a aumentar de nuevo automáticamente». No hay que presentar nada ni volver a solicitar nada. Fíjese, eso sí, en la redacción exacta: Google dice «empieza a aumentar», no “instantly returns to your prior rate.” (traducción) «vuelve al instante a su ritmo anterior». Trate la recuperación como una dirección documentada, sin plazo fijo ni punto final garantizado, no como un SLA.

(Compárelo con el problema opuesto: querer que Google le rastree menos de forma permanente. Si servir errores no es viable, Google dice que hay que “file a special request to report a problem with unusually high crawl rate” (traducción) «presentar una solicitud especial para informar de un problema de frecuencia de rastreo inusualmente alta»: una vía manual que puede tardar días y que no está garantizada. Para la recuperación no existe esa fricción.)

Cómo gestiona Bing el 429

Se informa ampliamente de que Bingbot se comporta de forma similar —429/500/503 como señal de sobrecarga y Bingbot aflojando el ritmo—, aunque en esta ronda de investigación no pude confirmar de forma independiente una redacción actual en ese sentido en las propias páginas de ayuda de Bing (son SPA renderizadas con JavaScript que no permitieron obtener texto estático). Trate la afirmación de paridad como algo reportado por el sector, no como algo que yo haya verificado contra la documentación actual de Bing. Lo que Bing sí confirma, en su propia documentación histórica, son dos controles proactivos que Google no ofrece de la misma forma:

• Crawl Control en Bing Webmaster Tools, una cuadrícula de peticiones por segundo donde se fija la velocidad de Bingbot por hora del día.
• La directiva crawl-delay de robots.txt. La documentación actual de Bing Webmaster documenta valores de 1 a 20 segundos. Es específica de Bing; no limita a Googlebot.

Así que en Bing puede limitar de forma proactiva con crawl-delay o con Crawl Control en lugar de hacerlo de forma reactiva con códigos de estado. (Google retiró en 2024 su propio control manual de frecuencia de rastreo y ahora se apoya por completo en las respuestas de su servidor.)

Cuándo enviaría deliberadamente un 429

Razones legítimas para devolver un 429 a propósito:

• Carga de servidor de emergencia: un pico de tráfico, una migración chapucera o una caída en la que necesita que Googlebot afloje ahora mismo durante unas horas.
• Proteger APIs y endpoints que no son HTML del abuso de bots y rastreadores: los rastreadores de buscadores, los rastreadores SEO de terceros (Ahrefs, Screaming Frog) y los scrapers chocan todos con límites de frecuencia pensados para frenar el abuso.

Para lo que no sirve el 429: bloquear permanentemente bots que no quiere en absoluto. Si no quiere que algo se rastree nunca, eso es trabajo de un disallow en robots.txt, no de un 429. Y si quiere conservar una página pero fuera del índice, eso es noindex. El 429 solo significa «más tarde», no «nunca».

429s no intencionados: los sospechosos habituales

Cuando aparecen 429s en el informe Page Indexing (Indexación de páginas) o en el informe Crawl Stats de GSC y usted no los ha puesto ahí, el origen suele ser uno de estos. No conozco buenas evidencias de una clasificación universal sobre cuál es el más frecuente, así que tómelo como una lista de candidatos que confirmar o descartar, no como un diagnóstico:

• Reglas de WAF o cortafuegos que se disparan por error sobre rangos de IP de rastreadores legítimos.
• Límites de frecuencia por defecto del hosting compartido o de la CDN demasiado estrictos para un rastreo real.
• Herramientas de gestión de bots que clasifican a Googlebot o Bingbot como tráfico abusivo.
• Middleware de limitación de frecuencia agresivo, pensado para el abuso de APIs, que atrapa a sus propios rastreadores.

Antes de tocar un umbral o de escribir una regla que exima a los bots de búsqueda reales, establezca primero la procedencia: no adivine qué capa es la dueña de la respuesta. Recupere las cabeceras de respuesta en bruto, las líneas exactas del log de peticiones (no un resumen de un panel), el identificador de la regla o de la zona de limitación que se activó, la clave de cliente contra la que se contabilizó (IP, sesión, clave de API), la ruta, el POP de la CDN o la ubicación del edge, y la ventana temporal. Esa combinación le dice qué capa emitió realmente el 429 y qué estaba contando; solo entonces tiene sentido aflojar un límite o añadir una excepción. Verifique la identidad del rastreador con una comprobación de DNS inverso más directo (el método oficial de Google), no solo con la cadena del agente de usuario (user-agent): los agentes de usuario que se hacen pasar por «Googlebot» son habituales. La pestaña Scripts tiene los comandos exactos.

La versión corta del manual de actuación

1. Use 429 o 503 con Retry-After para ralentizar un rastreador; nunca 403 ni 404.
2. Limítelo a horas, o 1–2 días: más allá de eso, las URL pueden ser eliminadas.
3. Recuerde que la limitación abarca todo el nombre de host y que se recupera sola cuando cesan los errores.
4. Acote el límite al tráfico adecuado y verifique la identidad del rastreador antes de eximir a un bot.

Resumen con IA

Un resumen condensado de la versión Avanzado:

• 429 Demasiadas solicitudes = el servidor le dice a un cliente (navegador, script o rastreador) que ha enviado demasiadas peticiones demasiado rápido: «limitación de frecuencia» o limitación de frecuencia. Nominalmente, un error de cliente 4xx.
• A nivel de protocolo: el RFC 6585 dice que una respuesta 429 SHOULD explicar la condición y MAY incluir Retry-After: recomendado, no obligatorio. Además, no debe ser almacenada por una caché; un 429 cacheado o repetido es un fallo de un intermediario, no del origen. Cómo cuenta y agrupa usted un límite (IP, sesión, clave de API, recurso) es su propia política: la especificación no lo define.
• La única excepción 4xx: Google trata el 429 como un error de servidor 5xx, no como un 403/404. Lo interpreta como “server overloaded, slow down” (traducción) «servidor sobrecargado, ve más despacio» y reduce la frecuencia de rastreo en lugar de eliminar contenido.
• Google avala el 429 (y el 500/503) para ralentizar rastreadores; nunca el 403 ni el 404. Gary Illyes escribió una entrada en 2023 diciendo específicamente a sitios y CDN que dejaran de usar 404 para limitar a Googlebot.
• La limitación abarca todo el nombre de host, por encima de un umbral: la propia redacción de Google condiciona el efecto sobre todo el nombre de host a encontrar «a significant number» (traducción: «un número significativo») de respuestas 500/503/429, no un 429 cualquiera. Por encima de ese umbral, las páginas que siguen sirviendo 200 también se rastrean menos.
• Guía de 1–2 días, no un límite tajante: la documentación de Google da una recomendación de uso en emergencias de «a couple of hours, or 1–2 days» (traducción: «un par de horas, o 1–2 días»). Los 429 sostenidos en las mismas URL durante varios días arriesgan que esas URL acaben siendo eliminadas del índice («may» y «eventually», no una garantía), de forma similar a un 503 prolongado.
• La recuperación es direccional, no instantánea: deje de enviar 429 y, según Google, la frecuencia de rastreo «empieza a aumentar de nuevo»: sin volver a solicitar nada y sin penalización persistente, pero también sin promesa de un ritmo inmediato o plenamente restaurado en un plazo fijo.
• Reintentos en el cliente: respete un Retry-After válido cuando esté presente; cuando no lo esté, el RFC no prescribe ninguna fórmula: use una política acotada de backoff con jitter, limite el número de intentos y compruebe la idempotencia antes de repetir peticiones no idempotentes.
• Acote el límite al tráfico adecuado y verifique la identidad del rastreador (DNS inverso + directo) antes de eximir bots.
• De Bing se informa ampliamente de que afloja ante un 429 de forma similar, aunque esa afirmación de paridad no se confirmó de forma independiente contra la documentación actual de Bing en esta ronda; la documentación histórica de Bing sí confirma crawl-delay y la cuadrícula de Crawl Control como alternativas proactivas.
• 429 ≠ bloqueo: significa «más tarde», no «nunca». Use robots.txt para mantener a los bots fuera y noindex para eliminar una página.

Documentación oficial

Documentación de fuente primaria de los buscadores y de la especificación HTTP.

Google

• No uses 403s ni 404s para limitar la frecuencia — entrada de Gary Illyes de febrero de 2023; la declaración canónica de que el 429 es la excepción y de que el 403/404 son las herramientas equivocadas.
• Reduce la frecuencia de rastreo de Google — la guía de «devuelve 500, 503 o 429», la ventana de 1–2 días, la limitación en todo el nombre de host y la recuperación automática.
• Códigos de estado HTTP, de red y DNS — cómo gestiona Google cada código; el 429 agrupado con los errores de servidor (también servido en la ruta antigua search/docs/crawling-indexing/http-network-errors).
• Reduce la frecuencia de rastreo de Google — vía de solicitud especial — la vía manual de «informar de un problema de frecuencia de rastreo inusualmente alta» cuando servir errores no es viable.

Bing / Microsoft

• Crawl Control — el planificador de peticiones por segundo de Bingbot en Bing Webmaster Tools.
• Bingbot guidance — documentación actual de Bing Webmaster para crawl-delay (de 1 a 20 segundos).

Especificación HTTP

• MDN — 429 Too Many Requests — la definición del protocolo, Retry-After y los fundamentos de la limitación de frecuencia.

Citas de la fuente

Declaraciones oficiales de Google, Bing y la especificación HTTP. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — Gary Illyes, “Don’t use 403s or 404s for rate limiting” (febrero de 2023)

• “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.” (traducción) «En los últimos meses hemos observado un aumento de propietarios de sitios web y de algunas redes de distribución de contenidos (CDN) que intentan usar el 404 y otros errores de cliente 4xx (pero no el 429) para intentar reducir la frecuencia de rastreo de Googlebot». Ir a la cita
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (traducción) «La única excepción es el 429, que significa ‘demasiadas peticiones’. Este error es una señal clara para cualquier robot que se comporte bien, incluido nuestro querido Googlebot, de que tiene que ir más despacio porque está sobrecargando el servidor». Ir a la cita
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (traducción) «Todos los códigos de estado HTTP 4xx (de nuevo, salvo el 429) harán que tu contenido se elimine de la Búsqueda de Google». Ir a la cita
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (traducción) «Usa Search Console para reducir temporalmente la frecuencia de rastreo. Devuelve un código de estado HTTP 500, 503 o 429 a Googlebot cuando esté rastreando demasiado rápido». Ir a la cita

Google — Reducir la frecuencia de rastreo / referencia de códigos de estado

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traducción) «Si necesitas reducir urgentemente la frecuencia de rastreo durante un periodo corto de tiempo (por ejemplo, un par de horas, o 1-2 días), devuelve el código de estado de respuesta HTTP 500, 503 o 429 en lugar de 200 a las peticiones de rastreo». Ir a la cita
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (traducción) «La frecuencia de rastreo reducida afecta a todo el nombre de host de tu sitio… Una vez que se reduce el número de estos errores, la frecuencia de rastreo empezará a aumentar de nuevo automáticamente». Ir a la cita
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (traducción) «No recomendamos que hagas esto durante un periodo largo de tiempo (es decir, más de 1-2 días)… la URL puede ser eliminada del índice de Google». Ir a la cita
• “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 de servidor». Ir a la cita
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «No uses los códigos de estado 401 y 403 para limitar la frecuencia de rastreo. Los códigos de estado 4xx, salvo el 429, no tienen ningún efecto sobre la frecuencia de rastreo». Ir a la cita

MDN — la definición del protocolo

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (traducción) «El código de estado de respuesta de error de cliente HTTP 429 Too Many Requests indica que el cliente ha enviado demasiadas peticiones en un periodo de tiempo determinado. Este mecanismo de pedir al cliente que reduzca el ritmo de peticiones se denomina habitualmente ‘rate limiting’.» Ir a la cita

Bing — documentación actual de Webmaster

• Bingbot guidance documenta valores de crawl-delay de 1 a 20 segundos. Trátelo como documentación específica de Bing y no como una limitación genérica para rastreadores.

Corroboración del sector sobre la declaración de Google

• La entrada de Illyes de febrero de 2023 fue cubierta literalmente por Search Engine Land, Search Engine Roundtable y Search Engine Journal, y las tres presentan el 429 como “the one exception” (traducción: «la única excepción»). Son artículos de la prensa especializada sobre la misma entrada de Google; la fuente primaria es la entrada de blog de Illyes citada más arriba.

Enviar un 429 correcto, con Retry-After

La pieza más importante de un 429 bien construido es la cabecera Retry-After. Le indica a cualquier cliente que la respete —incluido Googlebot— cuánto tiempo debe esperar. Admite un número de segundos o una fecha HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Omitir Retry-After no incumple la especificación, pero incluirlo es una buena práctica y da a los rastreadores una señal concreta de espera.

nginx: limitación de frecuencia que devuelve 429

Por defecto, el limit_req de nginx devuelve 503. Para una semántica amigable con los rastreadores, cámbielo a 429 y añada una cabecera Retry-After. Este ejemplo permite 10 peticiones por segundo por IP con una pequeña ráfaga:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache: limitación de frecuencia con mod_ratelimit / mod_evasive

El mod_ratelimit del núcleo de Apache limita el ancho de banda, no el número de peticiones, así que para limitar la frecuencia de peticiones normalmente se recurre a mod_evasive (o a un WAF). Para que una respuesta limitada devuelva un 429 con Retry-After, hay que fijarlo explícitamente:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Ojo con la salvedad: las compilaciones antiguas de mod_evasive devuelven por defecto un 403 como respuesta de bloqueo, que es exactamente el código que Google dice que no debe usarse para la limitación de frecuencia. Confirme que su compilación devuelve 429 (o póngale delante una CDN/WAF que sí lo haga).

Cloudflare / CDN: limitar la frecuencia con un 429

En la capa de CDN, configure la respuesta de la acción de su regla de limitación de frecuencia como 429 (muchas usan por defecto 403 o un desafío). En las reglas de Rate Limiting de Cloudflare, el código de estado de respuesta para los límites superados es configurable: elija 429 y, donde esté soportado, añada un Retry-After. El mismo principio se aplica en Fastly, Akamai o una pasarela de API: la acción al superarse el límite debe ser 429 Too Many Requests, no 403 Forbidden.

En el cliente: reintentar tras un 429 sin una fórmula

Si es usted quien escribe el cliente, el RFC le da exactamente una regla firme y ningún algoritmo de reserva: respete un Retry-After válido cuando esté presente. Cuando no lo está, el RFC 6585 no prescribe un intervalo de reintento, ni una fórmula de backoff, ni una distribución de jitter, ni un número de intentos, ni una condición de «éxito»: eso es política suya, no un requisito de la especificación. No presente ninguna fórmula concreta (incluida la de abajo) como ley del HTTP; es un valor por defecto acotado y razonable, no el único correcto.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Las piezas que importan al margen de los números exactos que elija: un tope para la espera total y para el número de intentos (no reintente eternamente), jitter (para que una flota de clientes no reintente al unísono y vuelva a disparar el límite) y una comprobación de idempotencia antes de repetir cualquier cosa que no sea segura repetir (un POST que no sea idempotente necesita una clave de deduplicación, no un reintento a ciegas).

Verifique que un bot es realmente Googlebot antes de eximirlo

Si va a escribir excepciones de limitación de frecuencia para los buscadores, confirme la identidad con una comprobación de DNS inverso + directo: los agentes de usuario que se hacen pasar por «Googlebot» son habituales y la cadena del agente de usuario por sí sola no demuestra nada.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Si la búsqueda inversa no termina en un dominio de Google, o la búsqueda directa no coincide con la IP original, no es Googlebot. También puede contrastarlo con los rangos de IP publicados por Google (googlebot.json).

Mitos habituales sobre el 429 y el SEO

Mito: «Cualquier 429 perjudicará mi SEO o hará que me desindexen». No. Google diseñó el 429 para que fuera una señal de limitación segura y esperada. Los 429 puntuales o intermitentes son normales y se corrigen solos. El riesgo de desindexación solo aparece con 429 sostenidos en las mismas URL durante varios días: la propia guía de Google de 1–2 días marca la línea.

Mito: «El 429 y el 503 son básicamente intercambiables para el SEO». Para limitar la frecuencia de rastreo, Google los trata de forma similar. Pero significan cosas distintas: 503 Service Unavailable es la señal tradicional de «caído temporalmente / mantenimiento», mientras que el 429 comunica específicamente una sobrecarga por frecuencia o volumen. Usar el semánticamente correcto importa para su propia monitorización, su instrumental y cualquier sistema aguas abajo que lea códigos de estado, aunque Googlebot afloje en ambos casos.

Mito: «Puedes usar un 403 o un 404 para ralentizar a Googlebot igual que un 429». Lo refuta directamente la entrada de Illyes de febrero de 2023: era lo bastante común como para que Google escribiera un artículo dedicado a pedir que se dejara de hacer. El 403 y el 404 no tienen ningún efecto sobre la frecuencia de rastreo y además eliminan activamente contenido del índice. El 429 es el único código 4xx que limita el ritmo.

Mito: «Limitar la frecuencia de los bots de búsqueda provoca un recorte permanente del presupuesto de rastreo». La reducción es temporal y se recupera sola en cuanto baja el volumen de errores. No queda ninguna marca persistente en su sitio después de que cesen los errores: la documentación de Google dice que la frecuencia de rastreo “will automatically start increasing again.” (traducción) «empezará a aumentar de nuevo automáticamente».

Mito: «Si Googlebot recibe un 429, abandona esa URL para siempre». Google lo reintenta más adelante. La preocupación son los 429 sostenidos durante varios días por URL, no un límite puntual u ocasional, que Googlebot simplemente respeta y del que vuelve.

Preguntas frecuentes

¿Un error 429 perjudica mi SEO? Por sí solo, no. Los 429 puntuales o intermitentes solo ralentizan a Googlebot de forma temporal y se corrigen solos. El riesgo aparece únicamente cuando las mismas URL devuelven 429 durante varios días.

¿Cuánto tiempo puedo devolver un 429 antes de que Google desindexe mis páginas? La documentación de Google dice que se limite a “a couple of hours, or 1–2 days.” (traducción) «un par de horas, o 1–2 días». Más allá de eso, “the URL may be dropped from Google’s index.” (traducción) «la URL puede ser eliminada del índice de Google». Trate 1–2 días como un techo máximo, no como un objetivo.

¿Cuál es la diferencia entre un 429 y un 503 para el SEO? Google limita el rastreo de forma similar con ambos. Pero el 503 significa «no disponible temporalmente / mantenimiento», mientras que el 429 significa específicamente «está enviando demasiadas peticiones». Use el semánticamente correcto para que su propia monitorización y su instrumental lo interpreten bien.

¿Debería bloquear a Googlebot con un 429 si quiero que rastree menos de forma permanente? No: el 429 es una señal a corto plazo, no una configuración permanente. Para una reducción duradera, Google dice que hay que presentar una solicitud especial sobre la frecuencia de rastreo alta. Para mantener a los bots completamente fuera de un espacio, use robots.txt; para eliminar una página del índice, use noindex.

¿Bingbot respeta el 429 igual que Googlebot? Bingbot también afloja ante señales de sobrecarga como 429/500/503. Además, Bing ofrece controles proactivos que Google no tiene: la directiva crawl-delay de robots.txt y la cuadrícula de peticiones por segundo de Crawl Control en Bing Webmaster Tools.

¿Qué es la cabecera Retry-After y la necesito? Retry-After le indica a un cliente cuánto debe esperar antes de reintentar (un número de segundos o una fecha HTTP). No es estrictamente obligatoria, pero es una buena práctica y da a los rastreadores una señal concreta de espera.

¿Google reanudará el rastreo normal después de que deje de devolver 429s?

Sí, automáticamente. En cuanto baja el volumen de errores, “the crawl rate will automatically start increasing again.” (traducción) «la frecuencia de rastreo empezará a aumentar de nuevo automáticamente». No hace falta volver a solicitar nada, y no queda ninguna penalización.

¿Pueden las herramientas de WAF o de CDN devolver un 429 a Googlebot por accidente? Con mucha frecuencia. Las reglas de cortafuegos agresivas, los límites por defecto de la CDN o del hosting y las herramientas de gestión de bots pueden clasificar mal a Googlebot o a Bingbot. Verifique la identidad del rastreador (DNS inverso + directo) antes de escribir excepciones, y afloje los límites que atrapan a buscadores reales.

¿El 429 es un error de cliente o de servidor? Técnicamente es un error de cliente 4xx en la especificación HTTP. Pero Google lo trata como un error de servidor a efectos de rastreo: es el único código 4xx agrupado con los 5xx.

¿Qué debería hacer mi cliente si recibe un 429 sin cabecera Retry-After? No hay ninguna fórmula impuesta por HTTP para esto: la especificación lo deja en manos de su política. Un valor por defecto acotado y razonable: backoff exponencial con jitter, un tope estricto del tiempo total de espera y del número de intentos para no reintentar eternamente, y una comprobación de idempotencia antes de repetir cualquier petición que no sea segura enviar dos veces. En la pestaña Scripts hay una versión en pseudocódigo desarrollada.

¿Qué hago con un 429?

Problemas habituales con el 429

Googlebot recibe 429 pero los visitantes normales no

Síntoma: los informes de rastreo muestran 429 mientras las comprobaciones desde el navegador devuelven 200. Causa probable: gestión de bots, una regla basada en el agente de usuario o limitación de frecuencia por IP. Solución: correlacione los eventos del WAF con IP de rastreadores verificadas y luego acote o corrija la regla responsable; no incluya en la lista de permitidos una cadena de agente de usuario por sí sola.

Cae la frecuencia de rastreo de todo el nombre de host

Síntoma: el rastreo se ralentiza más allá de las URL que devolvieron 429. Causa probable: Google aplica la señal de sobrecarga a todo el nombre de host. Solución: detenga los 429 no intencionados, restablezca respuestas de éxito estables y deje que la frecuencia de rastreo se recupere automáticamente.

Las respuestas 429 continúan después del incidente

Síntoma: el servidor está sano pero las URL siguen devolviendo 429. Causa probable: una caché de CDN, una regla de edge o el estado del limitador sobrevivieron al evento. Solución: desactive o haga expirar la regla temporal, purgue la respuesta cacheada incorrectamente y verifíquelo en rutas y regiones representativas.

Retry-After falta o no es utilizable

Síntoma: los clientes saben que fueron limitados, pero no cuándo reintentar. Causa probable: la respuesta la generó una regla de seguridad genérica. Solución: haga que la capa emisora envíe un retardo o una fecha HTTP válidos y pruebe la cabecera en bruto.

Prompt: auditar una regla de limitación de frecuencia

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: diagnosticar 429s inexplicables

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Herramientas para investigar los 429s

• Bulk HTTP Status Code Checker: pruebe un conjunto representativo de URL y exporte qué rutas devuelven actualmente un 429.
• HTTP Header Checker: inspeccione Retry-After, las huellas de la CDN y los saltos de redirección en la respuesta limitada.
• Googlebot Verifier: valide la evidencia de IP antes de crear una excepción para rastreadores.
• Log File Analyzer: segmente el desperdicio por código de estado según el bot y la sección, manteniendo los logs subidos en el navegador.
• Search Console Crawl Stats: compare el momento de los 429 con los cambios en las peticiones de rastreo y en el comportamiento de respuesta del host.

Validar una configuración de 429

Prueba del contrato de respuesta

Prueba a ejecutar: dispare el límite de forma segura en un entorno controlado e inspeccione la respuesta en bruto. Resultado esperado: 429 con un Retry-After válido y sin redirección ni código de éxito accidentales. Interpretación del fallo: la capa o la plantilla de error equivocada es la dueña de la respuesta. Ventana de monitorización: inmediata. Disparador de reversión: las peticiones normales se ven limitadas o la prueba desestabiliza el servicio.

Prueba de alcance

Prueba a ejecutar: ejercite un cliente que sí deba quedar limitado junto con usuarios normales y tráfico de rastreadores verificados en clases de URL representativas. Resultado esperado: solo el tráfico definido supera el límite. Interpretación del fallo: la clave del límite de frecuencia o el alcance de la regla son demasiado amplios. Ventana de monitorización: durante toda la prueba controlada y la propagación en el edge. Disparador de reversión: rutas, usuarios o hosts no relacionados reciben 429.

Prueba de recuperación

Prueba a ejecutar: detenga el disparador, espere el intervalo de reintento configurado y repita las peticiones. Resultado esperado: se reanudan respuestas normales y estables sin ningún apaño manual por URL. Interpretación del fallo: persisten 429s cacheados o el estado del limitador. Ventana de monitorización: el intervalo configurado más la propagación del despliegue. Disparador de reversión: el nombre de host sigue limitado después de que haya desaparecido la carga subyacente.

Prueba de almacenamiento en caché

Prueba a ejecutar: ponga una caché o un edge de CDN delante de la ruta limitada, dispare un 429 y vuelva a pedir la misma URL después de que se resuelva la condición subyacente. Resultado esperado: la segunda petición se evalúa de nuevo: no se sirve ningún 429 cacheado ni repetido desde el edge. Interpretación del fallo: un intermediario está almacenando una respuesta que el RFC 6585 dice que no debe cachearse; revise las cabeceras de cache-control y la configuración de las reglas del edge, no el origen. Ventana de monitorización: inmediata, en un conjunto representativo de nodos o POP del edge. Disparador de reversión: se sirve cualquier 429 cacheado después de que el origen se haya recuperado.

Prueba de la política de reintentos del cliente

Prueba a ejecutar: haga pasar a un cliente por un 429 tanto con una cabecera Retry-After válida presente como sin ella. Resultado esperado: con la cabecera, el cliente espera el intervalo indicado; sin ella, el cliente aplica una política acotada de backoff con jitter, respeta un número máximo de intentos y comprueba la idempotencia antes de repetir una petición no idempotente. Interpretación del fallo: un cliente que reintenta de inmediato, que reintenta sin límite o que repite a ciegas una petición no idempotente tiene una política de reintentos rota, no un problema de cumplimiento de HTTP. Ventana de monitorización: toda la secuencia acotada de reintentos. Disparador de reversión: el cliente vuelve a disparar el mismo límite de frecuencia mediante reintentos inmediatos o sin límite.

Recursos que merecen su tiempo

Mis artículos relacionados

• Códigos de estado HTTP y su impacto en el SEO — mi guía completa sobre cómo afecta cada código de estado al SEO, incluido dónde encaja el 429.
• La guía para principiantes de SEO técnico — dónde encajan los controles de rastreo y los códigos de estado en el panorama general.
• La historia de bloquear 2 páginas de alto posicionamiento con robots.txt — mi experimento de primera mano sobre lo que ocurre realmente cuando se corta el paso a los rastreadores.

Mis charlas

• How Search Works (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y el ranking, incluido cómo los servidores le señalan a los rastreadores que vayan más despacio. (Se aplica mi descargo habitual: “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 exacta».)

Del sector

• No uses 403s ni 404s para limitar la frecuencia (Centro de la Búsqueda de Google, Gary Illyes) — la declaración canónica de que el 429 es la excepción.
• Reduce la frecuencia de rastreo de Google (Google) — la ventana de 1–2 días, la limitación en todo el nombre de host y la recuperación automática.
• Google advierte contra usar códigos de estado 403 o 404 para limitar la frecuencia de rastreo de Googlebot (Search Engine Land) — cobertura de la prensa especializada sobre la entrada de Illyes.
• Google dice que dejen de usar 403s o 404s para reducir la frecuencia de rastreo de Googlebot (Search Engine Roundtable) — el resumen de Barry Schwartz, que presenta el 429 como “the one exception” (traducción) «la única excepción»_.
• Google: no uses respuestas de error 403/404 para limitar la frecuencia de rastreo de Googlebot (Search Engine Journal) — un tercer artículo independiente sobre la misma guía.
• MDN — 429 Demasiadas solicitudes — la definición de la especificación HTTP y la referencia de Retry-After.
• Guía para Bingbot — documentación actual de Bing para la directiva crawl-delay.

Ponga a prueba sus conocimientos: 429 Too Many Requests

Cinco preguntas rápidas sobre cómo funciona el 429 y cómo lo trata Google. Elija una respuesta para cada una y luego compruebe.

Registro de cambios