Server Downtime and SEO: What Your Proxy Should Return

For server downtime SEO, the rule is short. While your origin is down, your proxy should return a 5xx status code, ideally 503. Never an error page with a 200 status, and never a 404. This guide is for site owners whose origin falls over now and then and who have no idea what crawlers actually get while it’s down. And here’s the thing: during an outage the origin can’t answer at all, so whatever sits in front of it (usually a reverse proxy) decides what Googlebot sees.

What does Googlebot see when your origin server goes down?

It sees the status code from the proxy layer in front of your origin. That’s it. If the origin refuses connections or crashes, NGINX and similar proxies answer with 502 Bad Gateway. If the origin takes the request but never finishes it, you’ll usually get 504 Gateway Timeout. Some setups show a custom error page instead, and that page can carry any status code at all.

For indexing, only the status code matters. The visible text doesn’t. A page that says “temporarily unavailable” but returns 200? To a crawler that’s a normal, working page. This mismatch is one of the failure modes of proxy layers that tend to go unnoticed until rankings drop.

How Google treats 5xx errors and crawl rate

According to Google’s documentation on HTTP status codes, 5xx and 429 responses make Google’s crawlers temporarily slow down, and any content in a 5xx response is ignored. URLs already in the index stay there for a while, but they’re eventually dropped, and URLs that keep returning a server error get removed. The slowdown scales with how many individual URLs return a server error. Once the server responds with 2xx again, Google gradually increases the crawl rate.

The same page lumps 500, 502 and 503 into one server error group. There’s no separate handling described for a 502 versus a 503. So no, one won’t protect your rankings better than the other.

Why a 200 or 404 maintenance page hurts more than a 503

A 200 tells Google your error page is real content. A 404 tells Google the page is gone. Both are wrong during an outage. The Google status code reference says content from a 2xx response may be considered for indexing, which means a “we’ll be back soon” notice could end up replacing your article in the index. Not great. The same reference says indexed URLs returning 4xx are removed from the index and crawled less often over time.

So the right maintenance page status code is a 5xx. Keep the friendly page for visitors, sure - just serve it with 503.

Configuring NGINX to return 503 with Retry-After during an outage

You can set this up on your own NGINX or origin server with one static file and a handful of directives. This part is configured on your side, not in the proxy.

1. Create a static maintenance file, for example /var/www/errors/maintenance.html, with no dependency on the application or the database.
2. Map upstream errors to it with error_page, and switch on proxy_intercept_errors so errors returned by the origin itself get caught too.
3. Force the response code to 503 with the =503 syntax.
4. Add a Retry-After header with always, so NGINX sends it on error responses as well.
5. Decide how robots.txt should behave. Make sure it doesn’t turn into your HTML page with a 200, and test it on its own.

location / {
    proxy_pass http://origin;
    proxy_intercept_errors on;
    error_page 502 504 =503 /maintenance.html;
}

location = /maintenance.html {
    root /var/www/errors;
    internal;
    add_header Retry-After 1800 always;
}

Retry-After is a standard HTTP header that tells clients when to come back. Google’s page linked above doesn’t say how its crawlers use it, so treat it as a courtesy, not a ranking lever. Checking the result is easy: stop the origin and run curl -I https://example.com/. You should see the 503 status line and the Retry-After header. That’s exactly what a crawler would get.

Planned maintenance vs unexpected outages: what to check

Planned work is the easy case. Switch to 503 on purpose, keep the window short, get back to 2xx as fast as you can. Unexpected crashes are where it gets messy, because the default error response might come from a CMS or hosting panel that happily serves a nicely styled page with a 200. After any incident, go through:. Start by checking whether your error page actually returned a 200, because Google treats that pattern as soft 404 error pages and can quietly drop those URLs from the index.

• the status code your error page actually returns,
• what robots.txt returns while the origin is down,
• crawl errors in Search Console over the following days,
• whether uptime monitoring alerted you, and how fast.

Same discipline when you change servers or addresses, by the way. The guide on migrating without losing rankings covers that case.

Where the proxy layer fits in

A reverse proxy stays reachable when the origin behind it fails. Which is why it controls the response crawlers get. Jalvo is an NGINX reverse proxy with IP addresses in the EU and the USA, a panel for pointing domains, IP rotation, geotargeting and optional hosting. The error handling described above still belongs in your own server config. The proxy uptime and performance page lists what the service includes.

Summary: the right status code for server downtime SEO

Origin down? Return 503 or another 5xx, never a 200 page or a 404, and get back to 2xx responses as quickly as you can. Test the setup with curl before the next outage, not in the middle of it. Not sure how your stack behaves? Ask us about your setup and we’ll look at how your domains are pointed. Honestly, a few lines of configuration are all that separate harmless downtime from lost rankings, and that’s why this belongs on every server downtime SEO checklist.

FAQ