Google editó el 6 de octubre de 2026 una página de su documentación de rastreo y le dio a los responsables de sitios algo que llevaban años improvisando: un ejemplo oficial de cómo decirle a Googlebot cuándo volver. La página es Reduce the Google crawl rate, y ahora incluye la cabecera HTTP Retry-After con dos ejemplos de código.
También incluye la frase que casi nadie recogió. El límite que pone Google a la técnica es de uno o dos días, y el documento dice qué pasa si se supera: «si Googlebot observa esos códigos de estado en la misma URL durante varios días, la URL puede ser eliminada del índice de Google» (traducción nuestra; el original está en inglés).
Cuatro documentos de Google gobiernan lo que ocurre cuando un servidor empieza a rechazar a Googlebot. Consultados en directo el 7 de octubre de 2026, exactamente uno menciona Retry-After y exactamente uno pone una cifra a cuánto tiempo es seguro hacerlo. Son el mismo documento, y es el que cambió ayer.
Qué dice de verdad el documento de Google
La página Reduce the Google crawl rate, con sello Last updated 2026-10-06 UTC, da una sola instrucción de emergencia: «para reducir urgentemente la frecuencia de rastreo durante un periodo corto (por ejemplo, un par de horas, o 1-2 días), devuelve un código de estado HTTP 500, 503 o 429 en lugar de 200 a las solicitudes de rastreo».
El efecto no se limita a las URL que fallan. La misma página explica que «reduce la frecuencia de rastreo de tu sitio en todo el nombre de host (por ejemplo, subdominio.ejemplo.com), tanto en las URL que devuelven errores como en las que devuelven contenido. Vuelve a aumentar la frecuencia de rastreo automáticamente en cuanto disminuye el número de esos errores».
Lo nuevo es la cabecera. «Al devolver un código de estado 503 o 429, también puedes incluir una cabecera HTTP Retry-After (tal como la define RFC 9110 HTTP Semantics) para indicar cuándo pueden reintentar la solicitud los rastreadores de Google», dice la página, y muestra las dos formas documentadas: un retardo en segundos y una fecha absoluta.
HTTP/1.1 503 Service Unavailable
Retry-After: 120HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMTY después el límite: «no recomendamos que hagas esto durante un periodo largo de tiempo (es decir, más de 1-2 días), porque puede tener un efecto negativo en cómo aparece tu sitio en los productos de Google». La Búsqueda aparece ahí como ejemplo, no como el alcance completo.
El cambio está registrado. El registro de cambios de la documentación de rastreo de Google tiene una entrada fechada el 6 de octubre de 2026: «se reestructuró la sección de reducción urgente de la frecuencia de rastreo y se añadió información y ejemplos sobre la cabecera HTTP Retry-After a la documentación Reduce the Google crawl rate».
Qué observó la comunidad
Barry Schwartz detectó la edición en Search Engine Roundtable el 6 de octubre de 2026 y la presentó como un cambio de documentación, no como un cambio en el comportamiento de Googlebot: Google ya trataba 500, 503 y 429 como señales de reducción de rastreo antes de que esta página mencionara Retry-After. Esa lectura coincide con la redacción del propio registro de cambios, que habla de reestructurar y añadir ejemplos.
Ninguna medición de la comunidad acompañó al cambio: nadie publicó un antes y después del volumen de rastreo con y sin la cabecera, y Google no publicó ninguna cifra sobre hasta qué punto sus rastreadores respetan ese valor. Ninguna fuente de este artículo es un estudio, así que no hay tamaño de muestra que aplicar: son documentos, y sus sellos de fecha son la verificación.
Cuatro documentos y lo que le falta a cada uno
La pregunta útil no es qué dice la página nueva, sino qué siguen sin decir las otras. Los cuatro se consultaron en directo el 7 de octubre de 2026.
| Documento de Google | Última actualización | ¿Menciona Retry-After? |
¿Dice cuánto es seguro? |
|---|---|---|---|
| Reduce the Google crawl rate | 2026-10-06 UTC | Sí, con dos ejemplos | Sí: más de 1-2 días no está recomendado |
| How HTTP status codes affect Google’s crawlers | 2026-02-04 UTC | No | No: «persistently» se queda sin definir |
| How Google interprets the robots.txt specification | 2026-08-31 UTC | No | No aplica: robots.txt no controla el ritmo |
| Registro de cambios de Search Central | una entrada de octubre de 2026, del día 1 | No | No aplica: la edición no está registrada ahí |
La segunda fila es el hueco que importa. How HTTP status codes affect Google’s crawlers es la página a la que llega primero un desarrollador, porque es la que explica qué significa un 429 para Google. Dice que «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», y dice que «en el caso de la Búsqueda, el sistema de indexación de Google elimina del índice las URL que devuelven un error de servidor de forma persistente». No define «de forma persistente», y la cadena Retry-After no aparece en ella en ningún sitio. Dos lecturas independientes de esa página el 7 de octubre de 2026 dieron la misma respuesta a ambas preguntas.
Es decir: la única cifra que publica Google sobre cuánto tiempo es seguro está en una página distinta de la frase que matiza, y la página que describe la consecuencia no se toca desde el 4 de febrero de 2026.
La cuarta fila es la que se le habrá escapado a casi todo el sector. El registro de cambios de la documentación de Search Central es la página que esta industria vigila, y su única entrada de octubre de 2026 es del día 1 y trata sobre la guía de contenido generado con IA. La edición de la frecuencia de rastreo está registrada en otro changelog, en otro árbol de documentación. Quien vigilaba una sola página estaba vigilando la equivocada.
Qué cambia en la práctica
El 6 de octubre no cambió nada en el comportamiento de Googlebot. Lo que cambió es que una técnica que se venía usando por fe ya tiene un ejemplo resuelto, una referencia a un RFC y una caducidad declarada — y que las cuatro palancas disponibles resultan diferenciarse en velocidad por dos órdenes de magnitud.
Devolver 5xx o 429 surte efecto en la siguiente solicitud. Avisar de una frecuencia de rastreo anormalmente alta desde Search Console, que es a donde apunta la propia página de Google, lleva la latencia que Google mismo declara: «no puedes solicitar un aumento de la frecuencia de rastreo, y la solicitud puede tardar varios días en evaluarse y atenderse».
Y robots.txt no está en esta escalera. La página Reduce the Google crawl rate no lo ofrece como control de ritmo, y How Google interprets the robots.txt specification, actualizada el 2026-08-31 UTC, dice que Google «normalmente almacena en caché el contenido del archivo robots.txt hasta 24 horas». Un Disallow añadido con el servidor cayéndose puede tardar un día en leerse. Esa es exactamente la razón de que la palanca de emergencia sea un código de estado y no un archivo de texto, y es el tipo de distinción que separa el SEO técnico que funciona del folclore. La etapa sobre la que actúa es la primera de las tres que explica cómo funciona Google.
Un límite de alcance antes de que alguien apunte esto a los rastreadores de IA: esta es documentación de Google sobre los rastreadores de Google. No dice nada sobre si otro operador respeta un valor de Retry-After, y controlar los rastreadores de otras empresas es otro problema, con otros tokens, que el curso trata en los tres bots de Claude y tu robots.txt.
Qué hacer esta semana
- Averigua qué devuelve hoy tu servidor bajo carga. Si devuelve
200con una página a medio renderizar en vez de un error, esa es la peor respuesta posible: Google sigue rastreando a pleno ritmo e indexa el destrozo. - Si devuelve
503o429, añade la cabecera.Retry-After: 120para un retardo en segundos, o una fecha HTTP comoWed, 21 Oct 2026 07:28:00 GMTpara un momento absoluto. Las dos formas ya están en la documentación de Google. - Pon una alarma a las 24 horas. El techo declarado por Google es de 1-2 días. El fallo típico no es decidir superarlo, sino una incidencia que se queda abierta un fin de semana.
- No acotes los errores a unas URL concretas. La reducción se aplica igualmente a todo el nombre de host, y las URL rotas son justo de lo que habla la frase sobre salir del índice.
- Si la sobrecarga es estructural y no un pico, usa el aviso de Search Console y cuenta con varios días.
- Deja
robots.txtfuera del manual de incidencias. Hasta 24 horas de caché lo convierten en una herramienta de política, no en un freno de emergencia.
Donde el sector discrepa de verdad
Tres preguntas que toca esta historia no tienen respuesta cerrada, y este sitio no finge lo contrario.
¿Una edición fechada de la documentación dice algo sobre los sistemas de rastreo o de posicionamiento de Google? Un bando sostiene que Google escribe su documentación para describir lo que sus sistemas ya hacen, así que una edición con fecha es lo más parecido a una nota de versión que verá nunca el sector. El otro sostiene que la guía y el mecanismo son objetos distintos que se han separado varias veces. Este caso le da al segundo bando su mejor ejemplo: la entrada del changelog habla de reestructurar una sección y añadir ejemplos, que es lenguaje sobre un documento, y nada en ella afirma que Googlebot se comporte distinto de como lo hacía el 5 de octubre. Nadie puede zanjarlo, porque Google no publica ninguna correspondencia entre una edición de documentación y un cambio en producción.
¿Es seguro servirle errores a Googlebot a propósito, y durante cuánto tiempo? Los dos documentos relevantes de Google dan una recomendación («más de 1-2 días» no está recomendado) y un umbral sin definir («de forma persistente»), y no son lo mismo. Un bando trata una técnica documentada con techo publicado como exactamente eso: utilizable dentro del techo. El otro trata servir errores a propósito como un riesgo que ningún sitio debería asumir mientras exista una vía más segura, y señala que la consecuencia que nombra Google es la salida del índice, no un rastreo más lento. Ningún estudio publicado aísla cuántos días de 5xx cuestan cuántas URL, así que ambos bandos argumentan desde la misma ausencia de datos.
¿Una cifra que un empleado de Google dice en una conferencia es evidencia sobre los sistemas de Google? Importa aquí porque la pregunta siguiente evidente — cuánto tarda en recuperarse la frecuencia de rastreo — no tiene respuesta documentada, y las cifras que circulan sobre los ciclos de descubrimiento y refresco de Google vienen de la crónica de una conferencia y no de un documento de Google. Este sitio publicó esas cifras el 4 de octubre de 2026 con su procedencia al lado y se negó a usarlas como referencia. Esa postura no ha cambiado, y cuánto vale una cifra así sigue abierto.
Opinión del autor
Lo que defiendo es la afirmación documental y nada más ancho. A 7 de octubre de 2026, la única página de Google que lleva a la vez Retry-After y una duración segura declarada es la editada el 6 de octubre; la página que define qué significa un 429 para Google no lleva ninguna de las dos; y el changelog que vigila casi todo el sector no menciona la edición. Eso lo puede comprobar cualquiera a partir de los sellos de fecha, y costó cuatro consultas.
Lo que creo que significa en la práctica es más estrecho de lo que sugiere la cobertura. La edición es buena: un ejemplo resuelto vale más que el folclore. Pero espero verla leída como un permiso, y la frase que debería cambiar comportamientos no es la de la cabecera, sino la de varios días y el índice.
No voy a decirte que servirle errores a Googlebot sea seguro, porque las dos páginas de Google no coinciden en dónde está la raya y nadie lo ha medido. Tampoco voy a afirmar que la edición señale nada sobre posicionamiento: Google cambió una página, y si cambió algo en producción es una pregunta que la documentación no puede responder.
Qué sigue sin saberse
- Cuánto tarda la recuperación. La página dice que la frecuencia de rastreo «vuelve a aumentar automáticamente» cuando bajan los errores, y no le pone ninguna duración.
- Qué compra realmente
Retry-After. Google documenta la cabecera y no publica ninguna cifra sobre hasta qué punto sus rastreadores respetan el valor, en ninguna de las dos formas documentadas. - Dónde está «de forma persistente». Esa expresión gobierna la eliminación del índice desde el 2026-02-04 UTC sin definición, y la cifra de 1-2 días de la otra página es una recomendación sobre tu conducta, no un umbral declarado del sistema de indexación.
- Si afecta a algo fuera de la Búsqueda. El aviso habla de «un efecto negativo en cómo aparece tu sitio en los productos de Google», y nombra la Búsqueda solo como ejemplo.
Fuentes
Ninguna de las fuentes siguientes es un estudio. Son documentos y un artículo de prensa especializada, así que no hay tamaño de muestra que aplicar: los sellos de fecha son la verificación.
- Google, Reduce the Google crawl rate, documentación de infraestructura de rastreo. Last updated 2026-10-06 UTC. Consultada en directo el 7 de octubre de 2026.
- Google, registro de cambios de la documentación de rastreo, entrada del 6 de octubre de 2026. Consultado en directo el 7 de octubre de 2026.
- Google, How HTTP status codes affect Google’s crawlers. Last updated 2026-02-04 UTC. Consultada dos veces en directo el 7 de octubre de 2026.
- Google, How Google interprets the robots.txt specification. Last updated 2026-08-31 UTC. Consultada en directo el 7 de octubre de 2026.
- Google, registro de cambios de la documentación de Search Central. Única entrada de octubre de 2026, del 1 de octubre. Consultado dos veces en directo el 7 de octubre de 2026.
- Barry Schwartz, Google Search Crawl Rate Doc Adds Retry-After HTTP & More, Search Engine Roundtable, 6 de octubre de 2026.
- Google, Search Status Dashboard,
incidents.jsonconsultado en directo el 7 de octubre de 2026: ningún incidente tiene fecha de inicio en octubre de 2026.