HTTP 503 error

Long definition

503 is the only HTTP status that tells a crawler "I'm temporarily unavailable, here's when to come back" without the crawler treating it as a long-term problem. RFC 9110 defines it as a server-side error that's expected to be transient.

Google's published behavior, confirmed multiple times by the Search team:

• Short 503 (hours) — Googlebot retries. No indexing impact.
• Sustained 503 (days) — Googlebot starts dropping URLs from the index. Recovery on resolution but with delay.
• 503 with Retry-After — Googlebot honors the hint, pauses fetches accordingly, and resumes once the deadline passes.

The Retry-After header takes either a number of seconds (Retry-After: 3600) or an HTTP-date (Retry-After: Wed, 30 Apr 2026 12:00:00 GMT). For planned downtime, set it to your expected duration plus a buffer. For overload protection (rate limiting), shorter values (60-300 seconds) are appropriate.

When 503 is the right answer:

• Planned maintenance — backups, schema migrations, deploy windows. Return 503 across the whole site or just the affected paths.
• Soft launches — early access pages that aren't ready for indexing yet but exist at known URLs.
• Capacity protection — requests exceeding your server's safe load. Better than 500-erroring or returning slow 200s, both of which Google treats worse.
• Cutover windows during migrations — the gap between old infrastructure stopping and new infrastructure being ready.

When 503 is the wrong answer:

• Pages that won't come back — that's 404 or 410.
• Hidden content behind a login wall — that's 401 or 403.
• Geo-restricted content — that's 451 (legal) or 403 (policy).

Implementation reminder: a 503 must come from the actual HTTP response status. A 200 page that says "we're under maintenance" is invisible to crawlers as a maintenance signal — and worse, may get indexed as legitimate content. Configure your maintenance page to return 503 explicitly.

Common misconceptions

• "503 deindexes pages." Not on its own. Short-lived 503s are crawl-pauses, not deindexing signals. Days-long 503 without Retry-After is when problems start.
• "Retry-After is optional." Technically yes, practically no for SEO-critical maintenance. Without it, Googlebot retries on its own schedule and may slow down crawling more aggressively than needed.
• "You should 503 your whole site during any deploy." Most deploys are zero-downtime. 503 is for actual unavailability — disk migrations, database cutovers, infrastructure incidents — not normal CI/CD.
• "503 hurts user trust." A clear "we'll be back at HH:MM" maintenance page sets expectations. Users hate silent failures, slow loads, and broken pages — a polite 503 with an ETA is better than any of those.