How to Take Your Site Offline in 2026 Without Losing Rankings: The Complete Guide to the 503 Status Code

Sooner or later, every site has to go dark: a core update, a PHP security patch, a server migration, heavy database work. For anyone who earns money from traffic, those few minutes or hours of downtime aren’t just a technical footnote. The HTTP status code your server returns during that window directly decides whether your pages stay in the index — and whether your organic traffic (and the revenue attached to it) comes back intact.

The core rule is short: during planned or emergency downtime, return a 503 (Service Unavailable) status code. It tells search engines the outage is temporary and that already-indexed URLs should be preserved. But there are a few details around that rule that quietly cost sites their rankings.

What a 503 is and how search engines read it

An HTTP status code is the signal a server sends along with a page. Browsers use it to decide how to behave; search crawlers use it to decide what to do with a URL in their index.

200 OK — everything’s fine, here’s the page.
404 Not Found — the page doesn’t exist.
503 Service Unavailable — the service is temporarily down, come back later.

The key word is temporarily. When a crawler sees a 503, it understands the page still exists and just can’t be served right now. So the URL stays in the index and the crawler returns later. Once the site starts responding with 200 again, things return to normal on their own, with no manual intervention required.

The status-code hierarchy: best to worst

If downtime is unavoidable, status codes can be ranked by how “safe” they are for SEO, from best to worst:

503 → 500 → 403 → 404 → 200 (error page)

503 is ideal: “temporarily unavailable.”
500 (internal server error) is worse, but a crawler still reads it as a glitch, not as “the page is gone.”
403 (forbidden) is an ambiguous signal.
404 (not found) is bad — you’re effectively saying the page doesn’t exist.
200 on a “We’re doing maintenance” page is the most dangerous option of all.

That last one is the classic beginner trap. If your server returns a “Site under maintenance” placeholder with a 200 OK code, the search engine treats that placeholder as a legitimate page. It may then index the placeholder itself instead of your real content — so your article or product page gets replaced in the results with the line “We’re doing maintenance.” Google confirmed this behavior years ago, and the guidance hasn’t changed since.

The most common mistake: a 503 must not come from PHP

Here’s the detail that breaks the whole plan. Plenty of tutorials tell you to return a 503 using PHP (http_response_code(503) and the like). That works — but only while PHP itself is alive.

The problem is that sites are often taken down precisely to update or restart PHP — for example, during an emergency security patch. At that exact moment PHP is unavailable, which means no PHP script can return a 503. Requests start timing out or returning 500s and 404s — the very codes we were trying to avoid.

The takeaway: the 503 has to come from a layer that keeps running while PHP is off. That can be:

a rule at the CDN level (such as a custom maintenance page in Cloudflare);
a web server configuration (Nginx or Apache) that doesn’t depend on PHP;
a temporary placeholder server you’ve pointed DNS at;
a separate load balancer.

Google representatives have said this directly: when taking PHP sites down, serve the 503 from outside PHP — via a CDN, web server settings, or by pointing DNS elsewhere — rather than relying on PHP itself.

robots.txt is a special case

One rule to memorize separately: do not serve your robots.txt file with a 503. If a search engine gets a 503 on robots.txt, it reads that as “the rules can’t be read right now” and pauses crawling of the entire site. While the main site is in maintenance, robots.txt must keep responding normally (with a 200) so the crawler can still see the site and come back cleanly.

The Retry-After header: tell the crawler when to come back

Alongside a 503 (or 429), you can send a Retry-After HTTP header that tells the crawler when to try again. You can express it two ways:

as a number of seconds: Retry-After: 3600
as a specific date and time in UTC: Retry-After: Wed, 28 Oct 2026 08:00:00 GMT

It’s optional but useful: it keeps the crawler from wasting attempts and helps it return promptly once your work is done.

How long you can keep a 503 up

A 503 is a short-term measure. Google’s documentation explicitly recommends against keeping one up for longer than 1–2 days: if the same URL returns a server error for several days running, it may be dropped from the index. The wording in Google’s docs is unambiguous — indexed URLs returning server errors are preserved for a while, but eventually dropped.

Short outages, on the other hand, are completely safe. According to comments from Google representatives, a 503 lasting 10–15 minutes every now and then isn’t “extended” by any stretch, and there’s nothing to worry about. Google calls taking an entire site offline an extreme measure that should last a few days at most.

What happens to crawling, snippets, and revenue

Google treats 500, 503, and 429 codes as a signal to urgently reduce crawler load. When the crawler hits a large number of these responses, it lowers the crawl rate across the whole hostname — including URLs that are still serving normal content. Once the error count drops, the crawl rate recovers automatically. But a slowed-down crawl has direct consequences for a site that earns from search:

New pages get discovered more slowly. Googlebot opens fresh URLs less often, so your new articles or products land in the index later.
Existing pages get refreshed less often. Price, stock, and promotion changes reach the results with a delay.
Snippets freeze. While a page returns a 503, Google can’t refresh its title, description, metadata, or structured data (Schema). For a store, that means stale prices or an outdated “in stock” status can linger in the results.
Ad campaigns can pause. When a site has availability problems, ad campaigns (including Google Ads) can be paused or disapproved — a direct hit to paid traffic and conversions.

How to actually return a 503

Here are working approaches depending on your infrastructure.

Cloudflare / any CDN. Set up a maintenance page at the CDN level (for example, via Cloudflare Workers, transform rules, or a custom error page). The CDN keeps working even when your origin server or PHP is down, and it can serve the 503 with the right Retry-After header itself. This is the most reliable method for the “we’re patching PHP” scenario specifically.

Nginx. You can switch the site into maintenance mode at the config level, bypassing PHP entirely:

nginx

location / {

return 503;

}

error_page 503 @maintenance;

location @maintenance {

root /var/www/maintenance;

rewrite ^(.*)$ /maintenance.html break;

add_header Retry-After 3600;

}

Keep the robots.txt rule separate so it continues to return 200.

Apache (.htaccess). With mod_rewrite you can route all requests to a static placeholder returning a 503, while excluding robots.txt and the placeholder file itself from the rule. The key is not to tie this to a PHP handler.

WordPress. The built-in maintenance mode and many plugins return a 503 by default — which is good. But verify the status code by hand: some plugins and custom placeholders return 200, which drops you straight into the trap described above. And for patching PHP itself, WordPress maintenance mode won’t help (it’s written in PHP too) — you need a layer above it.

How to verify you’re returning the right code

Don’t trust how the page looks — check the actual status code:

curl in a terminal: curl -I https://your-site.com — look for the HTTP/… 503 line and the presence of Retry-After.
Browser DevTools: Network tab → click the document → Status column.
Search Console: the URL Inspection tool shows exactly what Googlebot saw on its last crawl.
Online status-code checkers — for a quick check of individual URLs, including robots.txt.

Test several internal pages and robots.txt separately — a common mistake is a 503 rule accidentally covering robots.txt too.

Scenarios by downtime length

Minutes (up to ~15 min). A quick restart — barely a concern, but still return a 503.
Hours. Serve a 503 with Retry-After and make sure robots.txt stays reachable.
1–2 days. The upper safety limit for a 503. Longer than that risks URLs dropping from the index.
Longer than 1–2 days. A 503 no longer fits. Google recommends serving an indexable 200 placeholder instead — for example, a stripped-down but real homepage that explains the situation and when you’ll be back. Once the site returns 200 on all URLs again, crawling and indexing recover gradually.

2026 context: PHP versions and AI crawlers

This topic is relevant again because of the PHP security situation. As of 2026, only the PHP 8.2, 8.3, 8.4, and 8.5 branches are officially supported; everything 8.1 and below has reached end of life (PHP 8.1 on December 31, 2025). That means more and more sites run on versions without regular official updates and have to apply security patches in a hurry — i.e., take PHP down. That’s exactly why serving a 503 correctly, from outside PHP, matters. If you’re still on 8.1 or older, a planned upgrade to a supported branch will cut down how often you face these fire drills.

A distinctly 2026 factor is the rise of AI crawlers (the bots behind ChatGPT, Claude, Perplexity, and others), which also crawl sites and shape your visibility in AI search. A correct 503 matters for them too: you’re signaling that the outage is temporary and reducing the risk of dropping out of the sources AI answers cite. The logic is the same as with Googlebot — a temporary glitch is a 503, not a 404 and not a 200 placeholder.

Planned-maintenance checklist

Decide in advance which layer will serve the 503 (CDN, web server, DNS) — especially if you’re taking PHP down.
Configure a 503 for all user-facing URLs.
Add a Retry-After header with a realistic time.
Make sure robots.txt responds with 200, not 503.
Verify the actual status code via curl / DevTools / Search Console.
Stay within 1–2 days; if it’ll be longer, switch to a 200 placeholder.
After the work, confirm every URL returns 200 again and watch crawling recover in Search Console.

Mistakes that cost you traffic

A “maintenance” placeholder with a 200 code instead of a 503.
Trying to serve a 503 from PHP while updating PHP itself.
A 503 on robots.txt — a full stop to crawling.
Dragging maintenance past 1–2 days on a 503.
Skipping the verification of the real status code after setup.

The bottom line

Taking a site offline doesn’t drop your rankings on its own — sending the wrong signal to search engines does. A short, honest “503 + Retry-After,” served above the PHP layer, with a live robots.txt and a return to 200 within a couple of days, is all it takes to ride out maintenance without losing your index, your traffic, or your revenue. Every other option — 404s, timeouts, and especially 200 placeholders — ends up costing more than the downtime itself.