An HTTP status code is the only statement of intent a crawler ever hears from your server. It does not read your deploy notes or your maintenance banner; it reads the three digits. And several of those codes are handled in ways that diverge from what developers reasonably assume — sometimes more forgivingly, sometimes less.
The divergences cluster in four places: redirect flavors, the two "gone" codes, the maintenance code, and pages whose code contradicts their content.
The redirect quartet: 301, 302, 307, 308
The HTTP spec draws two distinctions — permanent versus temporary, and whether the request method is preserved — giving four codes:
| Code | Permanence | Method preserved | Search treatment |
|---|---|---|---|
| 301 | Permanent | No | Canonical moves to the target |
| 308 | Permanent | Yes | Same as 301 |
| 302 | Temporary | No | Source URL tends to stay canonical, at least initially |
| 307 | Temporary | Yes | Same as 302 |
Two things are commonly misunderstood here. First, the old fear that redirects leak ranking signal is out of date: Googlers have publicly stated that no PageRank is lost through any 3xx redirect, and Google's documentation treats 301 and 308 as equivalent permanence signals. The method-preservation distinction matters to browsers and APIs, not to indexing.
Second, a 302 is not a lasting way to keep the old URL indexed. Googlers have said that a temporary redirect left in place long enough gets treated as permanent — the system trusts observed behavior over the declared code. So a long-lived 302 usually converges to the 301 outcome, just more slowly and less predictably. The cost of the wrong flavor is not lost equity; it is a slower, murkier canonicalization while Google decides which URL to index. Say what you mean and it decides immediately.
404 versus 410
Both mean the content is not here, and both eventually drop the URL from the index. The difference is confidence. A 404 says "not found," which is compatible with a glitch, so Google re-checks 404ing URLs for a while before giving up — and continues occasional revisits long after. A 410 says "gone, deliberately," and Googlers have said it is treated somewhat more definitively, with removal proceeding a bit faster. It is a marginal difference, worth using when you are purging content at scale and worth ignoring for a page or two.
The more consequential points sit on either side of that comparison:
- 404s are not a quality problem. Google has been explicit that 404s on URLs that should not exist do not harm the rest of the site. A large 404 count in Search Console is often just evidence of a working error handler.
- A 404 with inbound links is a small write-off. If a dead URL has real external links and a genuinely equivalent page exists, a 301 preserves what the 404 discards. Redirect for equivalence, not for the sake of avoiding 404s — mass-redirecting everything to the homepage produces soft 404 treatment, covered below.
503 is a tool, not just a failure
For planned maintenance, 503 with a Retry-After header is the documented correct answer, and Google's documented handling is unusually forgiving: Googlebot backs off, retries later, and keeps your pages indexed through a short outage. Nothing is judged; the index simply waits. Google treats 429 similarly as a back-off signal when you are rate-limiting the crawler.
The forgiveness has a time limit. A 503 that persists for days stops reading as an outage and starts reading as the state of the site — crawl rate drops, and pages can eventually fall out of the index. The two classic self-inflicted wounds are worse than honest downtime:
- Serving the maintenance page with a 200 — you have just asked Google to index "We'll be back soon" as the content of every URL.
- Serving 404 during downtime — you have declared all your content removed, and it will be treated accordingly.
Soft 404s: when your 200 is overruled
A soft 404 is Google's classification, visible in Search Console, for a page that returns 200 but looks like an error or empty result: "no products found" category pages, expired listings with an apology message, and — the dominant modern cause — single-page apps whose router renders a not-found view while the server happily returns 200 for any path.
This is the inversion of everything above: the one case where Google overrides your declared code based on the content. Pages classified as soft 404s are dropped from the index as if they had returned 404, and crawling them is pure waste. Blanket redirects of dead URLs to the homepage or a category page get the same classification — a redirect to somewhere that does not answer the original URL's purpose is still a dead end.
The fix is to make the code tell the truth: configure the server or the SPA's hosting layer to return a real 404 for unknown routes, and either fix, remove, or honestly 404 the empty pages.
What to do
- Audit by URL class, not by URL. Take one representative URL per template — product, category, article, retired page, unknown path — and check the actual response with
curl -I, following redirects. Assumptions about what the CMS returns are wrong often enough to make this ten minutes well spent. - Make every permanent redirect a 301 or 308, and collapse chains to a single hop while you are in there.
- Purge deliberately: 410 for bulk-removed content nobody links to, 301 to a true equivalent where one exists, and a plain 404 for the rest — with no guilt about the 404s.
- Script your maintenance mode to return 503 with
Retry-Afterbefore you need it, and never let a maintenance page ship with a 200. - Watch the Soft 404 report in Search Console after any frontend-framework migration — it is where SPA routing mistakes surface first.