In short. Retry-After communicates a suggested waiting time through an HTTP response header, while crawler handling depends on documented implementation behavior.

Definition: Retry-After is an HTTP response header that tells a client how long it ought to wait before making a follow-up request. RFC 9110 defines its value as either an HTTP date or a delay in seconds after receiving the response.

Key facts

RFC 9110, HTTP Semantics defines the seconds value as a non-negative decimal integer.
RFC 6585, Additional HTTP Status Codes permits Retry-After in a 429 Too Many Requests response, which indicates rate limiting.
As of 17 October 2026, Google's crawl-rate guidance documents Retry-After with 503 or 429 responses to indicate when its crawlers can retry.
Google's HTTP status documentation says its crawlers temporarily slow down in response to server errors and 429 responses; content received with a 5xx response is ignored.

How is the waiting time expressed?

RFC 9110, section 10.2.3 defines two alternatives. A numeric value measures seconds from receipt of the response. Its example below asks for a delay of two minutes:

Retry-After: 120

An HTTP date identifies an absolute time. Google's crawl-rate guidance supplies this alternative example:

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

The numeric format requires a whole number of seconds, so a fractional value falls outside the RFC's grammar.

Which responses use Retry-After?

RFC 9110, section 15.6.4 defines 503 Service Unavailable for temporary overload or scheduled maintenance. A server may include Retry-After to suggest how long the client should wait. With that status, the header expresses how long the service is expected to be unavailable.

Rate limiting means restricting requests over a period of time. RFC 6585, section 4 defines 429 Too Many Requests for this situation and makes Retry-After optional. The specification leaves the method of identifying users and counting requests to the server.

RFC 9110 also defines Retry-After with redirection responses in the 3xx class. In that context, it expresses the minimum requested wait before following the redirect. Interpreting the header therefore requires reading the response status alongside its value.

What are the limits for crawlers?

Google's emergency crawl-rate instructions show the header accompanying this response:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

The same guidance says a significant number of 500, 503 or 429 responses reduces crawling across the whole hostname, including URLs that still return content. The crawl rate automatically increases again as these errors decrease.

Google advises against serving these errors for longer than one or two days. If Googlebot observes them on the same URL for multiple days, that URL may leave Google's search index. Retry-After belongs within temporary overload handling; persistent error responses carry their own indexing consequences. The cited documentation does not establish a common retry schedule across answer-engine crawlers.

FAQ

Does Retry-After contain seconds or milliseconds?

RFC 9110 specifies seconds for the numeric form. You can also supply an HTTP date.

Is Retry-After required with a rate-limit response?

RFC 6585 makes the header optional with 429 Too Many Requests. The status identifies rate limiting even when the server omits the header.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer