Glosario Error 429
El error 429 (Too Many Requests) es el código de estado HTTP con el que un servidor responde a un cliente que ha enviado demasiadas peticiones en un periodo de tiempo. Afecta a ese cliente, no a todo el servidor. La respuesta puede llevar la cabecera Retry-After, que indica cuánto esperar antes de volver a intentarlo.
Error 429: el servidor frena a un cliente que ha hecho demasiadas peticiones. Por qué Google lo trata como un 5xx y cómo usarlo sin perder URL.
El 429 no estaba en las primeras versiones de HTTP. Lo introdujo el RFC 6585, «Additional HTTP Status Codes», publicado por el IETF en abril de 2012, junto con los códigos 428, 431 y 511. El mecanismo que describe se llama en inglés rate limiting: limitar cuántas peticiones acepta un servidor de cada cliente. El RFC 9110 de 2022 no redefine el 429, así que la referencia sigue siendo el RFC 6585.
Alguien cuenta las peticiones de cada cliente y, al superar el límite, deja de servir la página y responde 429 hasta que pasa el tiempo de espera. Ese alguien puede ser la propia aplicación, una pasarela de API o una CDN con cortafuegos.
El RFC deja abierto cómo se identifica al cliente y cómo se cuentan las peticiones. El límite puede valer por recurso, para todo el servidor o para un grupo de servidores, y el cliente puede reconocerse por sus credenciales o por una cookie. Según MDN, lo más habitual es limitar por dirección IP. Dos reglas más del RFC: una respuesta 429 no debe guardarse en caché, y el servidor no está obligado a usarla; bajo un ataque, cortar la conexión puede ser más sensato que contestar a cada petición.
Para Google, el 429 es la excepción dentro de los errores del cliente. Su documentación sobre códigos de estado trata todos los 4xx igual, salvo el 429: con un 404 o un 403, la URL no se indexa y, si ya estaba indexada, sale del índice. El 429, en cambio, cuenta como señal de servidor sobrecargado y «it's considered a server error». Por eso tiene los efectos de un 5xx:
Google recomienda el 429, junto con el 500 y el 503, para frenar su rastreo durante unas horas o uno o dos días. Para eso desaconseja el 403 y el 404.
El 429 en el archivo robots.txt tiene reglas propias. La documentación de Google sobre robots.txt trata cualquier 4xx como si el archivo no existiera, salvo el 429. La ayuda de Search Console sobre estadísticas de rastreo cuenta el «HTTP 429/5XX» entre las respuestas fallidas del robots.txt. Un 429 ahí se lee como un fallo de conexión.
Con los rastreadores de IA falta la base documental. Las páginas de OpenAI, Anthropic y Perplexity sobre sus rastreadores, consultadas el 12.11.2026, no dicen cómo reaccionan ante un 429 o ante Retry-After. Anthropic sí acepta la directiva Crawl-delay en robots.txt. Para controlarlos quedan robots.txt y, si no quieres depender de la buena voluntad del rastreador, el bloqueo en servidor. Y pay per crawl no usa el 429: responde con un 402 y pide un pago.
El propio RFC 6585 da este ejemplo, para un sitio que permite 50 peticiones por hora a cada usuario con sesión iniciada:
HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600
Los 3600 son segundos, una hora.
Una regla de CDN pensada contra scrapers también puede tocar a Googlebot si este rastrea muchas URL de filtros en poco tiempo. Si la regla responde 429, Google rastrea más despacio todo el host. Si responde 403, Google entiende que esas URL no existen.
Para ver el código de una URL basta una petición desde la terminal: curl -I https://www.example.com/. La primera línea da el código y, si existe, aparece Retry-After. Si el límite depende de la IP o del agente, hay que probar desde el mismo origen que el cliente afectado.
En Google Search Console, el informe de estadísticas de rastreo muestra las respuestas que recibió Google por tipo y el estado del host, con la disponibilidad del robots.txt. Los registros del servidor dicen a quién se ha limitado: qué agente, qué IP y cuántas peticiones.
El 429 dice exactamente lo que pasa: hay demasiadas peticiones, no falta la página ni el permiso. Para Google eso significa bajar el ritmo en lugar de retirar URL, y con Retry-After el servidor da un tiempo concreto.
El coste es el de frenar el rastreo. Google advierte que, con menos rastreo, descubre menos páginas nuevas y actualiza las demás con menos frecuencia, de modo que precios y disponibilidad de productos pueden tardar más en verse en la búsqueda. Si el 429 dura días en las mismas URL, estas pueden salir del índice. Y un límite por IP mal calibrado bloquea también a personas que comparten red.
| Código | Qué dice el servidor | Para qué sirve |
|---|---|---|
| 429 Too Many Requests | Este cliente ha hecho demasiadas peticiones | Limitar a un cliente; para Google, frenar el rastreo |
| 503 Service Unavailable | No puedo atender a nadie ahora | Mantenimiento y sobrecarga del servidor entero |
| 403 Forbidden | Entiendo la petición, pero no la atiendo | Denegar el acceso; para Google es como un 404, no frena el rastreo |
Fuente: RFC 6585 (abril de 2012), apartado 4; RFC 9110 (junio de 2022), apartados 15.5.4 y 15.6.4; documentación de Google sobre códigos de estado (consultados el 12.11.2026).
Sobre cuánto tiempo puede durar un 429 a propósito, las fuentes de Google no coinciden. La guía para reducir la frecuencia de rastreo, actualizada el 6 de octubre de 2026, aconseja no pasar de «1-2 days». La ayuda de Search Console sobre estadísticas de rastreo, sin fecha visible, habla de «dos o tres días». Sobre la retirada del índice, la página de Google sobre errores de rastreo, actualizada el 18 de diciembre de 2025, dice que devolver 503 o 429 durante más de dos días «will cause Google to drop those URLs from the index», mientras que la guía para reducir la frecuencia de rastreo solo escribe que la URL puede salir tras varios días.
El artículo del blog de Google de febrero de 2023 que dio a conocer la excepción del 429 recomendaba también bajar el ritmo desde Search Console. Esa herramienta se retiró el 8 de enero de 2024, según anunció Google en noviembre de 2023.
Tampoco hay un estándar para avisar del límite antes de alcanzarlo. Cabeceras como X-RateLimit-Remaining son convenciones de cada servicio, y las cabeceras RateLimit del IETF siguen siendo un borrador en noviembre de 2026.
Esta entrada se redactó en noviembre de 2026 con ayuda de IA. Los datos proceden de los RFC 6585 y 9110, de la documentación de Google sobre códigos de estado, frecuencia de rastreo, robots.txt y verificación de rastreadores, de la ayuda de Search Console, del blog de Google, de MDN y de la documentación de Cloudflare, OpenAI, Anthropic, Perplexity y el IETF. Se revisó antes de publicarse y no contiene datos de clientes.
Una auditoría técnica revisa esto y el resto en un solo paso.
Solicitar auditoríaLo que fije el servidor. Si envía Retry-After, ese es el tiempo de espera, en segundos o como fecha. El RFC no fija ninguna duración.
En parte. El servidor ha contado demasiadas peticiones desde tu conexión, tu cuenta o tu clave. Si la red es compartida, como en una oficina o con una VPN, pueden haber sido otras personas.
Sí. Google lo recomienda, junto con el 500 y el 503, durante unas horas o uno o dos días. Baja el rastreo de todo el host y lo vuelve a subir cuando desaparecen los errores.
No está documentado. Las páginas de OpenAI, Anthropic y Perplexity sobre sus rastreadores no hablan del 429. Para controlarlos quedan robots.txt y, sin depender de la buena voluntad del rastreador, el bloqueo en servidor.
Esperar unos minutos y volver a intentarlo, sin repetir la acción en bucle, porque cada intento cuenta. Si persiste, el límite es del servicio y solo su soporte puede revisarlo.