A 503 status code tells Google your site is temporarily unavailable, so URLs that are already indexed stay in Search while you work on the server. When you go back to serving normal 200 pages, crawling picks up again. A 404, or a "we'll be back soon" page served with a 200 code, tells Google something very different, and can cost you indexed pages.
Key takeaways
- Google Search Central posted a reminder this week for anyone patching PHP or taking servers offline: serve a 503, not a 404 or a 200 error page.
- A 503 slows Googlebot down and keeps your indexed URLs in place for a while. A 404 starts removing them.
- Google doesn't give a fixed safe window. Its own guidance for an urgent shutdown talks about one or two days, and URLs that keep returning server errors are eventually dropped.
- Keep robots.txt returning 200 during maintenance. A 5xx on robots.txt makes Google stop crawling the whole site.
Why Google is talking about 503 this week
On 21 October 2026, the PHP project shipped emergency fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. According to Help Net Security, they affect PHP installations that serve web requests, including PHP-FPM, Apache with mod_php and LiteSpeed. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the UK NCSC suggests taking offline any system that can't be patched right away.
WordPress runs on PHP, so a lot of site owners and hosts spent this week patching servers, and some had to take sites down to do it. That's the moment Google Search Central chose for its reminder: "Don't forget the 503!" The post links to Google's documentation on how HTTP status codes affect Google's crawlers, which is the basis for everything below.
If your host manages PHP for you, check whether they've already updated it. If you run your own server and can't patch immediately, a short, properly configured 503 is the SEO-safe way to go offline.
What a 503 status code means to Google
A 503 (Service Unavailable) is a server error in the 5xx range. Google's crawling documentation says that 500, 502, 503 and 429 responses make Google's crawlers temporarily slow down. In Search, URLs that are already indexed are kept at first. Once the server returns 2xx again, Google gradually increases the crawl rate.
The same page is clear about the limit: the indexing pipeline removes URLs that persistently return a server error. So a 503 buys you time. It doesn't protect a page indefinitely.
503 vs 404 vs a 200 "maintenance" page
Here's how the common choices compare, based on Google's documentation.
| What you serve | What Googlebot does | What happens to indexed URLs |
|---|---|---|
| 503 Service Unavailable | Slows crawling temporarily | Kept at first; dropped only if the error persists |
| 404 or 410 | Ignores the content; no effect on crawl rate | Removed from the index over time |
| 200 with a "down for maintenance" message | Treats it as a normal page that says almost nothing | Can be reported as a soft 404 and the real content may be replaced or dropped |
| Redirect everything to a maintenance URL | Follows the redirect and uses the target's content | Your URLs are now redirects to a near-empty page |
| 429 Too Many Requests | Treated like a server error: crawling slows | Same as 5xx |
The 200 error page is the one I see most often on WordPress sites, because many maintenance and "coming soon" plugins serve their splash page with a 200 code unless you change a setting. To Google, that looks like every page on the site suddenly turned into the same thin page.
How long can a site return 503?
Google doesn't publish a number. Its crawling documentation only says URLs are dropped "eventually" if server errors persist. Its guidance on pausing or disabling a website is the closest thing to a time frame: if you must disable your site urgently for one or two days, show an informative error page with a 503 status code. It also strongly recommends limiting features rather than taking a site out of Search completely.
My rule of thumb: plan maintenance in hours, accept a day if something goes wrong, and treat anything beyond a couple of days as a risk to your indexed pages. If the work will take longer, keep a read-only version of the site online instead.
Don't let robots.txt return 503
This is the detail that catches people out. Google's robots.txt specification says that when robots.txt returns a 5xx error, Google stops crawling the site for the first 12 hours while it keeps retrying the file. After that it uses the last cached copy for up to 30 days. Network errors, timeouts and DNS failures are handled the same way.
If your maintenance rule sends a 503 for every request, it sends one for /robots.txt too, and Google pauses crawling of the entire site. Exclude robots.txt from the rule so it keeps returning 200 with its normal content. My robots.txt guide covers the file itself.
The opposite mistake is just as bad: don't add Disallow: / during maintenance. Blocking crawling doesn't protect your rankings, and Google can't see your 503s if it isn't allowed to fetch the pages.
How to serve a 503 during maintenance
The goal is the same on every stack: return status 503 for normal pages, show visitors a short human message, let your own IP through so you can test, and keep robots.txt at 200. Adding a Retry-After header is optional. It tells clients when to try again, but Google's crawling documentation doesn't say it uses it, so treat it as a hint.
WordPress
WordPress's own update mode already does this. While core, plugin or theme updates run, WordPress creates a .maintenance file and serves a 503 with a Retry-After header. If you use a maintenance plugin for longer work, open its settings and choose the maintenance mode that sends a 503, not a "coming soon" page.
Apache (.htaccess)
ErrorDocument 503 /maintenance.html
RewriteEngine On
# let your own IP through (replace with yours)
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteRule ^ - [R=503,L]
Header always set Retry-After "3600"The Header line needs mod_headers enabled. Remove the whole block as soon as the work is done.
Nginx
# inside the server block
set $maint 0;
if (-f $document_root/maintenance.on) { set $maint 1; }
if ($uri = /robots.txt) { set $maint 0; }
if ($maint = 1) { return 503; }
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 3600 always;
rewrite ^ /maintenance.html break;
}Create an empty maintenance.on file in the web root to switch maintenance on, and delete it to switch it off.
Check that it works
Don't trust the browser, because it only shows the page. Check the status code from the command line:
curl -I https://example.com/some-page/
# expect: HTTP/2 503 and a retry-after header
curl -I https://example.com/robots.txt
# expect: HTTP/2 200You can also run a live test in Search Console's URL Inspection tool, which reports the status code Googlebot receives.
After maintenance: what to check in Search Console
- Confirm every page returns 200 again, and that the maintenance rule or plugin is fully off.
- Open Settings > Crawl stats and look at host status. A short spike in server errors on the maintenance day is expected; it should drop back to normal.
- Watch the Page indexing report for a rise in "Server error (5xx)" over the next few days.
- Inspect your most important URLs and request indexing if any were dropped.
Expect crawling to recover gradually rather than instantly. Google slows down after server errors and ramps back up over time, which matters most for new posts waiting to be discovered. I explain why crawl rate drops when servers struggle in my crawl budget guide, and what typical recovery timelines look like in Google's own indexing timelines.
Common mistakes during downtime
- Returning 404 for every URL while the server is being rebuilt.
- Showing a maintenance or "coming soon" page with a 200 status.
- Redirecting every URL to a single maintenance page.
- Adding
noindexorDisallow: /to "protect" the site. - Letting robots.txt return 503 along with everything else.
- Leaving the 503 in place for days after the work is done because nobody switched it off.
- Using 403 or 401 to slow Googlebot down. Google says 4xx codes other than 429 have no effect on crawl rate.
Server errors are also one of the quieter reasons pages end up crawled but not indexed, so a messy maintenance window can show up in your indexing reports weeks later.
Frequently asked questions
Does a 503 status code hurt SEO?
Not for a short period. Google treats a 503 as a temporary server problem, slows crawling and keeps already-indexed URLs in Search. Problems start only if the 503 lasts long enough that Google treats the error as persistent and begins dropping URLs.
How long can I return a 503 before Google drops my pages?
Google doesn't give an exact limit. Its guidance mentions using a 503 if you must disable a site urgently for one or two days. Plan maintenance in hours, and keep a read-only version online for anything longer.
Should I use 503 or 404 when my site is down?
Use 503. A 404 tells Google the page no longer exists, and indexed URLs returning 404 are removed over time. A 503 says the outage is temporary.
Should robots.txt return 503 during maintenance?
No. If robots.txt returns a 5xx error, Google stops crawling the whole site for up to 12 hours and then relies on a cached copy. Keep robots.txt returning 200 and serve the 503 only on regular pages.
Does Google use the Retry-After header?
Google's crawling documentation doesn't say it does. The header is harmless and useful for other clients, so add it if it's easy, but don't rely on it to control Googlebot.
.webp)
Connect with Akif on LinkedIn, Instagram and Facebook.
Driven by advanced SEO expertise, deep marketing analytics, high-impact content strategy
With 2+ years of hands-on SEO experience, I specialize in holistic search strategies that don’t just rank—they drive real, measurable business growth. I’ve worked across industries including healthcare, hospitality, legal, e-commerce, and professional services, helping brands dominate their target markets. My approach bridges the gap between raw data and creative execution. Every strategy I build is rooted in rigorous market analysis, structured SEO frameworks, and tailored content ecosystems—no templates, no shortcuts. Whether you’re a single-location brand or scaling across multiple cities, I create data-driven marketing systems designed to compound results and grow with you.
Pages Missing From Google?
Get a technical SEO audit that finds indexing, canonical and crawl problems on your site — with a prioritised fix list.
Book a Free SEO Audit →