What Should a Temporarily Unavailable Page Return?

What should a page return when it is only temporarily unavailable?

A 503, and nothing else. Not a 404, not a redirect to your homepage, not a cheerful page saying back soon that returns 200. A 503 is the only common status code that means this URL is real, it is coming back, and you should not act on its absence yet.

This comes up more than people expect. A product paused for a month. A pricing page pulled while legal reviews it. A region specific page disabled during a migration. In each case the URL will exist again, and the status code is how you say so to anything that is not a person.

Getting it wrong is quiet and expensive. You take a page down for three weeks, bring it back, and wonder for the next quarter why it never recovered. Usually the answer is that you told every crawler the page was gone rather than that it was resting.

What does Google actually say about server errors?

Its documentation on HTTP and network errors states that 5xx and 429 server errors prompt Google's crawlers to temporarily slow down, and that Google gradually increases the crawl rate for the site once it receives 2xx responses again. That is the mechanism, in Google's own words.

The same page describes 429 as a signal that the server is overloaded, and says it is considered a server error. So a 503 and a 429 land in the same family as far as crawling is concerned, even though they describe different problems to a developer.

What matters in that wording is the word temporarily. Google is describing a pause in crawling behaviour, not a removal. That is the whole reason 503 is the right code: it puts the URL into a holding pattern instead of a deletion queue.

Why is a 404 the wrong answer for a temporary problem?

Because Google's documentation is explicit about what 404 does. It removes previously indexed URLs from its index, does not process newly encountered 404 pages, and the crawling frequency gradually decreases. That is exactly the outcome you do not want for a page you are bringing back.

The same page says 410 is treated the same way, informing the next processing system that the content does not exist. So the two codes people reach for when a page is missing both mean the same thing here, and both mean permanent as far as your index position is concerned.

There is a related trap worth naming. A page that returns 200 with the words temporarily unavailable on it is worse than either, because now the URL looks alive and its content is a notice about nothing. That is the setup for a soft 404, which I covered separately in what a soft 404 is and why Google decides you have one.

The decision between the permanent codes is a real one with its own logic, and I worked through it in when to use 410 Gone instead of a 301 redirect. This article is about the case those codes cannot express: the page is coming back.

Should you redirect it to the homepage instead?

No. A redirect says this URL has moved and the content now lives over there. Neither half of that is true for a paused page, and you will have to undo it later, which means a second change and a second period of instability.

Google's documentation notes that its crawlers follow up to ten redirect hops by default, and that content from the redirecting URL is ignored while only the final target's content is processed. In other words, once you redirect, the original URL stops being evaluated on its own merits entirely.

The homepage redirect is the most common version of this mistake and the least defensible. It sends someone looking for a specific product to a page that does not mention it, which is a poor experience and tells crawlers something false at the same time. Two costs, no benefit.

What about the Retry-After header?

Retry-After is part of the HTTP specification and it is good practice to send it with a 503, because it tells any well behaved client when to come back. What I will not tell you is that Google acts on it, because Google's own page on HTTP and network errors does not mention Retry-After at all.

I am being deliberate here. There is a lot of confident writing about what Google does with that header, and I cannot verify it against the documentation, so I am not going to repeat it. Send it because the specification says to, not because someone promised you a crawling outcome.

The same discipline applies to the other thing everybody repeats: that Google tolerates a 503 for some specific number of days before dropping the URL. That number does not appear on the page I just described. If you have seen it quoted, treat it as folklore until somebody shows you where it is written.

When does temporary become permanent?

When you stop being able to name the date it comes back. That is the honest test, and it is a business question rather than a technical one. A 503 is a promise, and leaving one in place for months on a page nobody intends to restore is a lie told slowly.

My rule is to put a date on it at the moment I take the page down. If the date arrives and the page is not coming back, that is the day it becomes a permanent decision, and it gets the permanent treatment: a 410 if nothing replaces it, or a 301 if something genuinely does.

Across six years and seventy plus projects, the pages that suffered most were never the ones taken down deliberately. They were the ones where a temporary measure was applied and then forgotten, and the person who applied it had moved on by the time anyone noticed.

What should the page itself say to a human?

The status code is for machines. The body is for people, and it should still be useful. Say what is unavailable, say whether it is coming back, and give them something to do in the meantime. A 503 can return a perfectly helpful page.

The detail people forget is that the visitor arrived for a reason. If a product page is paused, the useful body tells them whether existing customers are affected, points at the nearest relevant page, and offers a way to be told when it returns. That is three sentences and it recovers a meaningful share of an otherwise wasted visit.

What it should not do is apologise at length or explain your internal situation. Nobody arrived wanting to know about your migration. They arrived wanting the thing, and your job is to tell them quickly whether they can have it.

How do you check you got it right?

Request the URL and read the actual status line rather than looking at the page in a browser. A browser will render a helpful looking page regardless of what code came with it, which is precisely how a 200 saying temporarily unavailable survives review for months.

Check it from outside your own network too. Pages behind a maintenance mode sometimes return one code to logged in staff and another to everyone else, and the one that matters is the one strangers get.

Then watch coverage reporting over the following weeks. If a paused URL starts appearing under a not indexed reason, something is returning a code you did not intend. That reporting is also where the more ambiguous states show up, which is a whole diagnosis of its own that I wrote about in what to do about crawled, currently not indexed.

What should you do next?

List every page you have taken offline in the last year and check what each one returns right now. You will find at least one returning 200 with a maintenance message, and probably one redirecting to the homepage because it was quicker at the time.

For each, make the call that is actually true. Coming back on a known date gets a 503. Not coming back gets a 410, or a 301 if there is a real successor. Anything you cannot decide is a business question you are currently answering by accident.

If you have pages that never recovered after a pause and nobody can explain why, this is usually where the answer is. Reach out if you want someone to check it properly. Let's chat.