503 Service Unavailable
Why 503 is the correct status for planned maintenance, how the Retry-After header guides Googlebot, how Google backs off crawling on 503s, and how to avoid accidental deindexing.
503 Service Unavailable is the correct status code for planned, temporary downtime — Google explicitly recommends it over a 404 or a 200 'coming soon' page. Pair it with a Retry-After header so Googlebot knows when to come back, keep robots.txt crawlable (never 503 it), and treat 1–2 days as the ceiling for a full-site 503. Beyond a few days Google starts reading the 503 as permanent, your indexed titles/descriptions freeze rather than refresh, and pages can drop from the index with no guaranteed 1:1 recovery. For longer closures, switch to an indexable 200 placeholder instead.
TL;DR — A 503 Service Unavailable response tells search engines “the site is temporarily down — check back soon,” instead of “this page is gone.” When you need to take your site offline for planned maintenance, a 503 is the right code to return. Add a
Retry-Afterheader so Googlebot knows when to come back, keep yourrobots.txtreachable, and don’t leave the 503 up for more than a day or two.
What a 503 actually means
HTTP 503 means the server is temporarily unable to handle the request, and the standard permits a Retry-After header. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: 503 Google recommends 503 for brief downtime but warns that extended unavailability can affect indexing. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Pause an online business
A 503 is an HTTP status code in the 5xx family — the “something’s wrong on the
server side” group. Specifically, it means the server is up enough to answer, but
it can’t serve the request right now, usually because it’s overloaded or you’ve
put it into maintenance mode.
The key word is temporary. That’s what separates a 503 from the other codes you might reach for when a page isn’t available:
- 200 OK says “here’s the content” — even if that “content” is a “we’ll be right back” message. Search engines take that literally and can index the error page.
- 404 Not Found / 410 Gone say “this page doesn’t exist / is permanently gone.” Use these during maintenance and you’re telling Google to drop the page.
- 503 Service Unavailable says “I exist, I’m just busy — come back later.” This is the one you want for planned downtime.
Why 503 is the right call for maintenance
When you’re doing a deploy, a server move, or scheduled maintenance, you want search engines to pause, not to conclude your pages are dead. A 503 buys you that pause. Google says so directly: if you need to take a site down briefly, return a 503, not a 404 and not a 200 error page.
Think of it like a “Back in 10 minutes” sign on a shop door. A 404 is like bulldozing the shop; a 200 “coming soon” page is like replacing your whole inventory with a single sign and hoping customers still think you sell shoes. The 503 is the sign that keeps your spot.
The Retry-After header
Alongside the 503, you can send a Retry-After header that tells crawlers roughly
when to return. It can be a number of seconds or a specific date/time:
HTTP/1.1 503 Service Unavailable
Retry-After: 3600That example asks bots to wait about an hour. Google may use it as a hint for when to recrawl. It won’t come back to the exact second, but it won’t come back before then either.
The three things not to get wrong
- Don’t 503 for long. A day or two is fine. Much longer and Google starts to think the outage is permanent and can drop your pages.
- Don’t 503 your
robots.txtfile. If that file returns a 503, Google can’t crawl anything — including the check that would tell it you’re back online. - Don’t use a 404 or a plain 200 “coming soon” page instead. Those send the wrong signal and can cost you more than the 503 would.
Want the duration thresholds, the exact Google quotes, and the platform-by-platform implementation? Switch to the Advanced tab.
TL;DR — 503 is the correct code for temporary unavailability, and Google explicitly prefers it over 404/410 (permanent) or a 200 error page (indexable junk). Pair it with
Retry-After. Google’s own ceiling for a full-site 503 is 1–2 days; past “a couple of days” it treats the 503 as permanent and drops URLs. A 503 also freezes your indexed metadata — titles, descriptions, and structured data won’t refresh while it’s served. Never 503 yourrobots.txt. Google treats 429 and 503 the same for crawl-rate backoff. And recovery from a long outage is likely but not guaranteed to be 1:1. For anything longer than a day or two, serve an indexable 200 placeholder instead.
What 503 is — and isn’t
A 503 is a temporary server condition, not a permanent removal signal. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: 503 Search behavior depends on duration and repeated responses; recovery timing is not guaranteed. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Pause an online business
RFC 9110 keeps the language soft on purpose: the server is currently unable to
handle the request, relief is described as likely, not certain, and the
Retry-After header is optional — a MAY, not a requirement. The standard doesn’t
compel a crawler to return at any particular time, and a server can even skip the
503 entirely and just refuse the connection instead. That matters for this whole
page: everything below about Google’s crawl behavior and recovery timing describes
what tends to happen, not a contractual guarantee.
503 is for temporary server-side unavailability. It is not a general-purpose “hide this page” tool, and it is not interchangeable with its neighbors:
- 404 / 410 — permanent removal. During maintenance these tell Google your pages are gone, and it will start dropping them (410 a touch faster than 404).
- 200 with error content — a “we’ll be right back” page returning
200 OKlooks like real content. Google indexes it, and if every URL returns the same page, it may treat them as duplicates. - 503 — “I’m here, just temporarily unable.” The one code that says pause, not delete.
What Google actually recommends (in order)
Google’s current, actively-maintained guidance (Temporarily pause or disable a website) lays out a preference order that most competitor articles skip past. Lead with it:
1. Don’t go fully dark at all — limit functionality instead. Google’s top recommendation is to keep the site live and just disable the risky parts (turn off the cart, show a banner, update your structured data / Merchant Center feed), because that “minimizes any negative effects on your site’s presence in Search.” Full-site 503 is the fallback, not the default.
2. If you must disable the whole site: the 1–2 day rule. Google calls a full-site takedown “an extreme measure that should only be taken for a very short period of time (a few days at most),” and is specific about the mechanism: “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content.”
3. Longer than that: switch to an indexable 200 placeholder. Once you’re past a day or two, stop serving 503s. Google: “If you need to disable the site for a longer time, then provide an indexable home page as a placeholder for users to find in Search by using the 200 HTTP status code.”
The duration spectrum (there’s no single hard cutoff)
Different Google sources give you a spectrum, not one magic number — and it’s directional, not a compliance guarantee. The only figure that comes from Google’s own current documentation is the 1–2 day ceiling below; the minute- and day-level figures are Google staff comments relayed by Search Engine Journal from office-hours sessions, not primary-sourced statements you can hold Google to.
- Minutes, occasionally. Gary Illyes, via Search Engine Journal: “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate. Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.”
- A day or so. John Mueller, via Search Engine Journal: “For an outage of maybe a day or so, using a 503 result code is a great way to tell us that we should check back.”
- 1–2 days. Google’s own documented ceiling for an urgent full-site 503 — the one figure in this list from Google’s current, primary-sourced guidance.
- “A couple of days” and beyond. This is where it turns. Mueller, via Search Engine Journal: “after a couple of days we think this is a permanent result code, and we think your pages are just gone, and we will drop them from the index.”
- Weeks. Near-guaranteed index loss, and — per the docs — recovery from a full removal has “no fixed time … and there’s no mechanism to speed that up.”
None of this adds up to a safe-harbor countdown clock. It describes what tends to happen, not a rule you can rely on for a specific outcome — treat the 1–2 day figure as the outer edge to plan around, not a guarantee that anything inside it is risk-free.
The metadata-freeze side effect (the risk nobody talks about)
Even a short, correct 503 has a cost that gets missed: while you’re serving 503s, Google can’t update what it already has. Straight from the docs: “it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code.”
So a 503 freezes your indexed metadata — it doesn’t erase it and it doesn’t update it. If you changed a title or a schema markup right before maintenance, a stale SERP snippet can persist through the whole window. “Safe” means “not permanently harmful when brief,” not “invisible.”
Never return a 503 for robots.txt
This is a real-world foot-gun: some maintenance-mode plugins and blanket CDN rules
503 everything, including robots.txt. Don’t. Google is explicit: “Don’t return
a 503 HTTP response status code for the robots.txt file because this blocks all
crawling.” A 503’d robots.txt stops Google from crawling anything at all —
including the recrawl that would confirm you’re back. Keep robots.txt returning
200 even during a full-site outage.
503 vs 429 — Google treats them the same
People search “429 or 503” interchangeably in rate-limiting contexts. For
crawl-rate purposes they’re equivalent to Google. Mueller (on a page he himself
later marked as older): “we treat them both about the same. We see both as a
temporary issue, and tend to slow down crawling if we see a bunch of them.” Same
backoff logic; a 429 Too Many Requests and a 503 both tell Googlebot to ease off.
(Its 502/504 siblings, the other transient gateway/timeout errors, get similar
treatment — sustained 5xx of any flavour slows crawling.)
A branded maintenance page can look correct while returning 200. Check the HTTP response itself, then confirm Retry-After separately because this result does not display the header.
Test the affected URLs with my free HTTP Status Checker Free
- Test representative page URLs and the robots.txt URL during the maintenance window.
- Confirm affected pages return 503 while robots.txt remains reachable, and inspect Retry-After with a header-capable client.
- Restore 200 responses promptly and rerun the same URL list after maintenance.
The checker shows one URL returning HTTP 503, grouped in the 5xx server-error filter. The verification panel identifies the URL and status and provides a rerun action.
Recovery is likely — not guaranteed
The most useful myth-buster in this whole topic: if a long outage does drop your pages, they usually come back, but not always the same. Mueller: “when the pages come back we will crawl them again and we will try to index them again. But it’s essentially during that time we will probably drop a lot of the pages from the website from our index, and there’s a pretty good chance that it’ll come back in a similar way but it’s not always guaranteed.” Plan your maintenance windows as if recovery could be imperfect, because it can be.
A few FAQs worth answering directly
- Does a 503 hurt SEO? Not when it’s brief and correct. A short 503 with
Retry-Afteris the intended signal for planned downtime. The harm comes from leaving it up too long, or from 503’ingrobots.txt. - Is 503 or 404 better for maintenance? 503, every time. A 404 says “gone” and starts deindexing; a 503 says “back soon.”
- Does WordPress return a 503 during updates? Yes — WordPress serves a 503 automatically while core or plugins update. That’s the correct behaviour; the window is normally seconds.
- Can I just show a “coming soon” page at 200 instead? No. A 200 error page gets indexed as content, and if it’s the same page across every URL, Google may treat those URLs as duplicates.
The single rule to remember
Google’s own ceiling for an urgent full-site 503 is 1–2 days — treat that as the outer edge to plan around, not a guaranteed-safe window. Even inside it, a 503 still pauses your crawl rate and freezes your metadata, and nothing here promises a specific ranking, indexing, or recovery outcome. Past that ceiling, switch to an indexable 200 placeholder before Google decides your pages are gone. Everything else on this page is a footnote to that.
For the neighbouring codes, see the rest of the HTTP status codes cluster.
AI summary
A condensed take on the Advanced version:
- 503 = temporary unavailability. It’s the correct code for planned maintenance — Google prefers it over 404/410 (permanent) and over a 200 error page (which gets indexed as content, often as duplicates).
- Pair it with
Retry-After(seconds or an HTTP date), though RFC 9110 makes the header optional (aMAY) — Googlebot may use it as a hint for when to recrawl and backs off its crawl rate, but nothing compels an exact return time. - Duration is a spectrum, not a guarantee: the only figure from Google’s own current docs is 1–2 days, its documented ceiling for an urgent full-site 503. Google staff comments relayed by Search Engine Journal put brief windows (10–15 minutes, ~a day) as generally fine and put “a couple of days”+ as where Google starts treating the 503 as permanent and drops pages — read those as directional, not primary-sourced commitments. For longer closures, serve an indexable 200 placeholder instead.
- Metadata freezes: while a 503 is served, Google can’t refresh titles, descriptions, or structured data — so stale snippets can persist.
- Never 503
robots.txt— that blocks all crawling, including the recrawl that confirms you’re back. - 429 ≈ 503 for crawl-rate backoff; Google treats them the same.
- Recovery after a long outage is likely but “not always guaranteed” to be 1:1 (Mueller); full-index removal has no fixed recovery time.
- Best practice overall: Google’s top recommendation is to avoid a full takedown at all — limit functionality and stay live.
Official documentation
Primary-source guidance on 503 and planned downtime.
- Temporarily pause or disable a website — Google’s current, canonical guidance: the preference order, the 1–2 day rule,
Retry-After, the robots.txt exception, the metadata-freeze note, and the curl verification tip. - How to deal with planned site downtime (2011 blog post) — the original write-up (now carries an “outdated, see best practices” banner). Source of the classic PHP
Retry-Afterexample. - In-Depth Guide to How Google Search Works — background on crawl-rate backoff: HTTP 500-family errors mean “slow down.”
RFC / technical reference
- MDN — 503 Service Unavailable — the standards-based definition of the status code.
- MDN — Retry-After header — syntax for the seconds and HTTP-date forms.
Bing / Microsoft
- Bing does not publish 503-for-maintenance guidance at the same granularity as Google.
Retry-Afteris a standard RFC header (not Google-specific), and Bingbot also backs off crawl rate on repeated5xx/429responses — but treat any specific Bing behaviour as inferred from standard HTTP semantics rather than a documented statement.
Quotes from the source
On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.
Google docs — the 1–2 day rule
- “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content.” Jump to quote
- “If you need to disable the site for a longer time, then provide an indexable home page as a placeholder for users to find in Search by using the 200 HTTP status code.” Jump to quote
Google docs — robots.txt and metadata
- “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” Jump to quote
- “it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code.” Jump to quote
- “removing a site completely from Google’s index is a significant change that can take quite some time to recover from.” Jump to quote
Google Search Central Blog (2011)
- “instead of returning an HTTP result code 404 (Not Found) or showing an error page with the status code 200 (OK) when a page is requested, it’s better to return a 503 HTTP result code (Service Unavailable) which tells search engine crawlers that the downtime is temporary.” Jump to quote
- “If known, the length of the downtime in seconds or the estimated date and time when the downtime will be complete can be specified in an optional Retry-After header, which Googlebot may use to determine when to recrawl the URL.” Jump to quote
John Mueller, Google
- “please return a ‘503 Service unavailable’ HTTP result code… they’re generally more than happy to give your site some time to catch up again.” Jump to quote From johnmu.com/503s/ (2013), Mueller’s personal republish of a Google+ post. The live page renders typographic apostrophes, so the deep link is kept short to guarantee an exact text match.
- “we treat them both about the same. We see both as a temporary issue, and tend to slow down crawling if we see a bunch of them.” (on 429 vs 503) Jump to quote From johnmu.com/429-or-503/ (2015), a page Mueller himself marks as “old, probably outdated.”
- “after a couple of days we think this is a permanent result code, and we think your pages are just gone, and we will drop them from the index.” Jump to quote Relayed by Search Engine Journal from a Search Central office-hours/Q&A; confirm against the original before treating as final.
Gary Illyes, Google
- “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate. Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” Jump to quote Relayed by Search Engine Journal from a Google Search Central SEO office-hours session.
Planned-maintenance 503 checklist
Run this before, during, and after a maintenance window:
- Decided whether you even need a full takedown — can you limit functionality and stay live instead (Google’s preferred option)?
- Maintenance page returns a real
503status (verified with curl, not just eyeballed in a browser). - A
Retry-Afterheader is set (seconds or an HTTP date) with a realistic estimate. -
robots.txtstill returns200and is reachable — never 503’d. - The 503 page is lightweight: static HTML, inline CSS, no heavy assets (bots will hit it repeatedly).
- A hard internal deadline is set to switch to a 200 indexable placeholder if the window exceeds ~1–2 days.
- No pages are returning
404/410or a200“coming soon” page instead of the 503. - Search Console Page Indexing and Crawl Stats are being watched during
and after the window for
5xxspikes. - Post-maintenance: confirmed pages returned to
200, submitted a fresh crawl via URL Inspection for key URLs, and verified metadata/snippets refreshed.
SOP: Put your site into planned maintenance mode correctly
A repeatable procedure for a short, safe maintenance window.
Before the window
- Decide the scope. If you can keep the site live and only disable the risky part (cart, checkout, a broken feature), do that instead — it’s Google’s top recommendation and avoids all of the risk below. Only proceed to a full 503 if you genuinely must take everything offline.
- Estimate the duration honestly. If it’s realistically more than 1–2 days,
don’t plan a full-site 503 at all — plan an indexable
200placeholder homepage instead. - Build a lightweight maintenance page. Static HTML, inline CSS, base64 or no images. Bots (and users) will hit it repeatedly, so it must not strain the server.
Configuring the response
- Return a real 503 for site content. Examples:
- Apache (
.htaccess): route everything to the maintenance page and force the status —RewriteEngine On RewriteCond %{REQUEST_URI} !^/maintenance\.html$ RewriteCond %{REQUEST_URI} !^/robots\.txt$ RewriteRule ^ /maintenance.html [R=503,L] ErrorDocument 503 /maintenance.html Header always set Retry-After "3600" - Nginx:
location / { return 503; } error_page 503 /maintenance.html; location = /maintenance.html { internal; add_header Retry-After 3600; } location = /robots.txt { } # keep robots.txt serving 200 - PHP (Google’s own example form):
header('HTTP/1.1 503 Service Unavailable'); header('Retry-After: 3600');
- Apache (
- Set
Retry-Afterto a realistic estimate — seconds (3600) or an HTTP date. - Exempt
robots.txt. Make surerobots.txtstill returns200(see the rewrite conditions above). This is the step most people miss.
Verify
- Confirm the status with curl, not the browser:
curl -I -X GET "https://www.example.com/" # expect: HTTP/1.1 503 Service Unavailable + Retry-After: ... curl -I "https://www.example.com/robots.txt" # expect: HTTP/1.1 200 OK
During and after
- Watch the clock. If you’re approaching the 1–2 day ceiling, switch to a
200indexable placeholder before Google starts treating the 503 as permanent. - Bring the site back. Remove the 503 rule; confirm pages return
200again. - Recheck. Use GSC URL Inspection on key pages, watch Crawl Stats for the
5xxspike to subside, and confirm titles/descriptions/structured data refresh (they were frozen during the 503).
What not to do — and the myths behind it
Myth: “A 503 for more than a couple of days is completely safe as long as I use
Retry-After.”
Retry-After improves precision; it doesn’t override Google’s ceiling. The docs cap
an urgent full-site 503 at 1–2 days, and Mueller: “after a couple of days we think
this is a permanent result code… and we will drop them from the index.” Switch to
a 200 placeholder before you get there.
Myth: “503 has zero SEO impact if implemented correctly.” Even a short, correct 503 pauses metadata refresh — titles, descriptions, and structured data can’t update while it’s served — and any 503 nudges crawl rate down. “Safe” means “not permanently harmful when brief,” not “invisible.”
Myth: “A 404 or a 200 ‘coming soon’ page is just as good during maintenance.”
No. 404/410 signals permanent removal and gets pages dropped faster. A blanket
200 error page gets indexed as content — and if every URL returns the same page,
Google may treat them as duplicates.
Myth: “You should 503 your robots.txt too, to be thorough.”
The opposite. A 503’d robots.txt blocks all crawling, including the recrawl that
confirms your site is back. Keep it at 200.
Myth: “If Google drops my pages during downtime, they’ll come back exactly the same.” Likely, but “not always guaranteed” (Mueller), and full-removal recovery has no fixed timeline and no way to speed it up.
Myth: “429 and 503 are totally different signals.” For crawl-rate backoff, Google “treat[s] them both about the same.”
The anti-pattern to burn into memory: serving a bare 200 OK “down for
maintenance” page. It’s the single most common mistake and the one Google warns
about most directly.
503 for maintenance — cheat sheet
Which code for which situation
| Situation | Code | Why |
|---|---|---|
| Short planned maintenance (≤ 1–2 days) | 503 + Retry-After | ”Temporary — check back” |
| Maintenance longer than 1–2 days | 200 indexable placeholder | 503 would read as permanent |
| Page permanently removed | 404 / 410 | Genuine removal |
| Just disable the cart / one feature | stay 200, limit functionality | Google’s top recommendation |
| Server overloaded / rate-limiting | 503 or 429 | Google treats them the same |
Duration spectrum
| Window | Verdict |
|---|---|
| 10–15 min, occasionally | Fine (Illyes) |
| ~a day | Fine (Mueller) |
| 1–2 days | Google’s documented ceiling for full-site 503 |
| ”A couple of days”+ | Google treats 503 as permanent — pages dropped |
| Weeks | Near-certain index loss; no fixed recovery time |
The 1–2 day row is Google’s own current documented ceiling. The minute- and day-level rows are Google staff comments relayed by Search Engine Journal, not primary Google documentation — read the spectrum as directional, not a guaranteed-safe compliance window.
Retry-After forms
- Seconds:
Retry-After: 3600 - HTTP date:
Retry-After: Sat, 8 Oct 2011 18:27:00 GMT
Don’t-forget rules
robots.txtstays 200 — never 503 it.- 503 page = static HTML, inline CSS (bots hit it repeatedly).
- 503 freezes indexed titles/descriptions/schema — they won’t refresh.
- Verify with
curl -I, not the browser.
Verify your 503 is actually a 503
A browser can show a maintenance page while the server quietly returns 200.
Check the real status code and headers with curl.
macOS / Linux
# Site content should return 503 with a Retry-After header
curl -I -X GET "https://www.example.com/"
# expect: HTTP/1.1 503 Service Unavailable
# Retry-After: 3600
# robots.txt must stay reachable (200), NOT 503
curl -I "https://www.example.com/robots.txt"
# expect: HTTP/1.1 200 OKWindows (PowerShell)
# -SkipHttpErrorCheck lets PowerShell show the 503 instead of throwing
(Invoke-WebRequest -Uri "https://www.example.com/" -Method Head -SkipHttpErrorCheck).StatusCode
(Invoke-WebRequest -Uri "https://www.example.com/robots.txt" -Method Head).StatusCode Minimal 503 responses
PHP (Google’s own example form)
<?php
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600'); // or an HTTP date: 'Sat, 8 Oct 2011 18:27:00 GMT'
?>
<!DOCTYPE html>
<title>We'll be right back</title>
<h1>Down for scheduled maintenance</h1>
<p>We expect to be back within the hour. Thanks for your patience.</p>Nginx (content 503, robots.txt exempt)
location / {
return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
internal;
add_header Retry-After 3600;
}
location = /robots.txt { } # keep serving robots.txt normally (200)Keep the maintenance page static with inline CSS and no heavy assets — bots will request it repeatedly and you don’t want that page itself straining the server.
Patrick's relevant free tools
- Website Down Checker — Check whether one URL or a small sample is reachable right now from one Cloudflare location, with response timing, redirects, DNS fallback evidence, and connection-status details.
Tools for handling and checking a 503
curl -I— the fastest way to confirm the real status code andRetry-Afterheader (a browser can hide the truth). See the Scripts tab.- Google Search Console — URL Inspection — check the last crawled status of a specific URL and request a fresh crawl once you’re back online.
- GSC — Crawl Stats report — watch for the
5xx/503spike during the window and confirm it subsides afterward. - GSC — Page Indexing report — spot any pages that got dropped if the window ran long.
- Screaming Frog SEO Spider — crawl your own site to confirm which URLs return
503 vs 200 (and that
robots.txtisn’t 503’d). - Ahrefs Site Audit / Ahrefs Webmaster Tools — surfaces
5xxresponses across the site so you can catch a stray 503 that lingers past the window. - WordPress maintenance-mode plugins (e.g. WP Maintenance Mode) — WordPress
already 503s automatically during core/plugin updates; a plugin gives you a
controlled maintenance page — just confirm it doesn’t 503
robots.txt.
Resources worth your time
My related writing
- HTTP Status Codes: The Complete List for SEO — my full guide to the status codes that matter for SEO, with 503 in the
5xxcontext. This single-topic deep dive is the expanded version of that guide’s one-line treatment. - The Beginner’s Guide to Technical SEO — where crawling, status codes, and maintenance fit in the bigger picture.
From around the industry
- Temporarily pause or disable a website (Google Search Central) — the canonical, current guidance; read this first.
- How to deal with planned site downtime (Google Search Central Blog, 2011) — the original write-up and the classic PHP
Retry-Afterexample. - 503s (John Mueller, johnmu.com) — Mueller’s own plain-language take on why to 503 during downtime.
- Google On The SEO Impact Of 503 Status Codes (Search Engine Journal) — Gary Illyes on the “10–15 minutes is fine” data point.
- Google Will Deindex Pages If Site Is Down For Several Days (Search Engine Journal) — Mueller’s “a couple of days… we will drop them” threshold.
- HTTP 503: Handling site maintenance correctly for SEO (Yoast) — a practical, WordPress-flavoured walkthrough of the
Retry-Aftermechanics. - 503 Service Unavailable (MDN) — the standards reference for the status code itself.
Videos
- Google Search Central (YouTube) — the How Google Search Works series and the SEO office-hours archives, where Mueller and Illyes have answered the 503/maintenance and deindexing-timeline questions quoted throughout this page. Channel
Stats worth citing
- 1–2 days — Google’s documented ceiling for using a full-site 503 during an urgent takedown; beyond that, switch to a 200 placeholder. Source
- 10–15 minutes, occasionally = fine — Gary Illyes on how brief a 503 window can be without denting crawl rate. Source
- “A couple of days” — the point at which Google starts treating a 503 as permanent and dropping pages from the index (John Mueller). Source
- No fixed recovery time — Google’s docs on recovering from a complete removal from the index: no set timeline and no way to speed it up. Source
Test yourself: 503 Service Unavailable
Five quick questions on using 503 for planned maintenance. Pick an answer for each, then check.
503 Service Unavailable
503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime.
Related: HTTP Status Code, 500 Internal Server Error, 429 Too Many Requests
503 Service Unavailable
503 Service Unavailable is a 5xx HTTP status code that means the server understood the request but can’t handle it right now because it’s temporarily overloaded or down for maintenance. The “temporarily” is the whole point: unlike a 404/410 (permanent removal) or a 200 with error content (which reads as real content), a 503 tells search engine crawlers the outage is short-lived and they should check back later.
Because of that semantic, Google explicitly recommends returning a 503 — not a 404 and not a 200 “coming soon” page — when you have to take a site down for planned maintenance. Google’s own current guidance sets 1–2 days as the ceiling for an urgent full-site 503 — treat that as the outer edge to plan around, not a guaranteed-safe window; serve one for much longer and Google starts to read it as permanent and can drop your pages from the index.
Two implementation details matter. First, pair the 503 with a Retry-After header (a number of seconds or an HTTP date) so Googlebot has a hint about when to return and can back its crawl rate off accordingly. Second, never return a 503 for robots.txt itself — a 503’d robots.txt blocks all crawling, including the recrawl that would confirm your site is back. Google treats 503 and 429 Too Many Requests about the same way for crawl-rate purposes; both are “slow down” signals, alongside its 500-family siblings like 502 and 504.
Related: HTTP Status Code, 500 Internal Server Error, 429 Too Many Requests
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Revision history
Compare the published article with an archived editorial snapshot. Added and removed words are shown only after you open a comparison.
Updated Jul 17, 2026.
Editorial summary and recorded change details.Summary
Qualified maintenance-window guidance and aligned Retry-After behavior with RFC 9110.
Change details
-
Clarified that RFC 9110 makes Retry-After optional on 503 and describes relief as likely rather than guaranteed.
Try it live
This is a real endpoint on this site — not a simulation.
Hit it from the button, open it in a new tab, or
curl -i it from your terminal, and the server answers with the actual status code this article is about.