Los códigos de estado HTTP 429 combinados con el encabezado Retry-After permiten que su servidor web señale que Googlebot debe reducir su tasa de rastreo. Cuando su servidor detecta un volumen excesivo de solicitudes simultáneas, esta señal informa al rastreador del motor de búsqueda que debe pausar y esperar una duración definida antes de intentar acceder a su contenido nuevamente. Esta práctica técnica evita el agotamiento del servidor y mantiene la estabilidad del sitio durante eventos de alta demanda.
¿Por qué debería usar el código de estado 429 para los rastreadores?
Controlar el presupuesto de rastreo sigue siendo un aspecto clave del SEO técnico. Si Googlebot solicita demasiadas URL a la vez, su base de datos y la CPU del servidor pueden tener dificultades para procesar estas solicitudes junto con el tráfico humano real. Esto provoca picos en los tiempos de respuesta, lo que afecta negativamente la experiencia del usuario para los visitantes reales.
Enviar una respuesta 429 es una señal clara de que su servidor no puede manejar temporalmente más carga. Este enfoque es superior a permitir que el servidor se bloquee o devuelva errores 5xx. Cuando un servidor devuelve un error 5xx, señala un fallo, mientras que un 429 señala que el sitio funciona pero requiere una pausa temporal en la frecuencia de solicitudes. Esta distinción permite que el motor de búsqueda mantenga su proceso de indexación sin marcar su sitio como roto.
Por ejemplo, en una cuenta típica que experimenta una gran venta flash, miles de bots podrían acceder al servidor simultáneamente. Sin limitación de tasa, el servidor podría fallar al servir las páginas de pago a clientes reales. Al identificar el tráfico de bots y emitir códigos de estado 429, el servidor preserva sus recursos para los usuarios humanos, asegurando que las rutas de conversión permanezcan abiertas mientras se comunica con el rastreador de búsqueda.
Además, el uso del código 429 es una forma estándar de señalar que el servidor está actualmente abrumado pero tiene la intención de atender solicitudes en un futuro cercano. A diferencia de un error 503, que a menudo implica una ventana de mantenimiento, el código 429 aborda específicamente la gestión del volumen de solicitudes. Esto permite que su backend reduzca la carga durante picos repentinos de tráfico, como cuando el lanzamiento de un nuevo producto desencadena un aumento en el interés.
¿Cómo funciona el encabezado Retry-After?
El encabezado Retry-After proporciona una duración en segundos o una fecha HTTP que le dice a Googlebot exactamente cuándo es seguro reanudar el rastreo. Al incluir este encabezado, usted ofrece orientación en lugar de solo un mensaje de error. Ayuda al rastreador a comprender que el problema es temporal y que debe regresar más tarde, lo cual es esencial para mantener un ritmo de indexación saludable.
Sin el encabezado Retry-After, un rastreador podría intentar volver a conectarse inmediatamente, lo que crearía un bucle de respuestas 429. Al especificar un tiempo, como 30 o 60 segundos, le da tiempo al servidor para limpiar su cola y recuperarse. Esto crea un ritmo predecible que respeta tanto la capacidad del servidor como la necesidad de datos de índice frescos.
La implementación es simple pero requiere precisión. El valor en el encabezado debe ser preciso, ya que un tiempo de espera demasiado agresivo podría retrasar la indexación innecesariamente, mientras que un valor demasiado corto podría desencadenar otra ola de 429. Sugerimos comenzar con una ventana de 60 segundos durante los períodos de alta carga para darle a su base de datos tiempo para procesar las consultas pendientes.
- Incluya un encabezado Retry-After válido con su respuesta 429 que indique el tiempo de espera en segundos.
- Asegúrese de que el servidor devuelva un estado 200 OK para las solicitudes exitosas posteriores después del período de espera.
- No bloquee a Googlebot permanentemente usando códigos 429, ya que esto conducirá a la desindexación.
- Verifique los registros de su servidor para asegurarse de que la tasa de rastreo se ajuste después de que haya transcurrido el período de espera.
¿Cuáles son los errores comunes al implementar la limitación de tasa?
Los propietarios de sitios a menudo confunden los códigos 429 con una prohibición permanente. Es fundamental diferenciar entre un límite de tasa temporal y una restricción de acceso completa. Si el servidor sigue devolviendo 429 durante un tiempo prolongado, Googlebot puede interpretar esto como una señal de que el sitio ya no está disponible, lo que lleva a posibles caídas en la cobertura del índice.
Otro error común es aplicar la respuesta 429 a archivos CSS, JavaScript o de imagen necesarios para la renderización. Si el rastreador no puede acceder a los recursos necesarios para comprender la página, puede indexar la página basándose en una versión incompleta del contenido. Asegúrese siempre de que la limitación de tasa se aplique al flujo de solicitudes del rastreador en su conjunto, en lugar de bloquear recursos individuales que son críticos para el análisis de la página.
Además, verifique si hay conflictos con la configuración de su CDN o WAF. A veces, las capas de seguridad pueden emitir automáticamente códigos 429 cuando detectan actividad de bots, incluso si su servidor de origen es estable. Si estas capas están mal configuradas, podrían bloquear a Googlebot por completo, lo cual es contraproducente. Verifique que su WAF esté configurado para permitir que los rangos de IP de Googlebot omitan las reglas agresivas de limitación de tasa.
Un archivo robots.txt le dice a los rastreadores de los motores de búsqueda a qué URL puede acceder el rastreador en su sitio.
Google Search Central
Cómo aplica esto Alien Road
En Alien Road, gestionamos los problemas de tasa de rastreo monitoreando los registros del servidor en busca de solicitudes de alta frecuencia durante ventas pico o actualizaciones de contenido. Configuramos el servidor para que responda con un código de estado 429 siempre que las solicitudes superen un umbral específico determinado por nuestra capacidad actual del servidor. Esto asegura que la infraestructura permanezca disponible para los usuarios humanos mientras el rastreador recibe instrucciones claras sobre cómo proceder.
Nuestro equipo sigue un enfoque estructurado para garantizar que la implementación sea efectiva sin causar problemas de indexación. Priorizamos la precisión sobre la velocidad en estas configuraciones, ya que un límite de tasa incorrecto puede dañar inadvertidamente la visibilidad de un sitio. Por ejemplo, durante el pico estacional de un cliente, configuramos alertas automatizadas en nuestro panel de monitoreo que activan una respuesta 429 si la latencia del servidor supera los 500ms durante más de tres minutos consecutivos.
Una vez que disminuye el pico de tráfico, relajamos gradualmente los límites de tasa y monitoreamos el informe de rastreo de Google Search Console. Este enfoque basado en datos nos permite mantener los sitios de nuestros clientes indexados mientras protegemos el servidor durante eventos de alta demanda. Tratamos el código de estado 429 como una herramienta quirúrgica, no como un instrumento contundente, para la gestión del tráfico.
- Audite los patrones de rastreo existentes para identificar segmentos de alta carga en los registros de acceso de su servidor.
- Configure una limitación de tasa dinámica basada en métricas de salud del servidor en tiempo real, como el uso de CPU o la carga de memoria.
- Pruebe el encabezado Retry-After en un entorno de prueba para asegurarse de que Googlebot interprete correctamente el comando de pausa.
- Monitoree los informes de indexación de Google Search Console para confirmar que la tasa de rastreo se mantiene constante.
Por dónde empezar esta semana
Revise los registros actuales de su servidor esta semana para verificar si hay picos en la actividad de Googlebot. Si identifica períodos en los que aumenta el tiempo de respuesta de su servidor, implemente la lógica del código de estado 429. Comience estableciendo un valor conservador de Retry-After para evitar cualquier impacto negativo en su presupuesto de rastreo. Al tomar estos pequeños pasos medidos, protege el núcleo de sus operaciones digitales mientras mantiene una relación profesional con el motor de búsqueda.
Comience analizando sus registros de acceso de los últimos siete días. Utilice una herramienta de línea de comandos o su plataforma de análisis de registros para filtrar por agentes de usuario de Googlebot y calcular el recuento de solicitudes por minuto. Si ve picos sostenidos que coinciden con problemas de rendimiento en su sitio, ahí es donde debe definir su umbral para implementar el código de estado 429.