Should You 301 A Deleted Page, Or Let It Return 410?

Should I redirect a deleted page or just let it die?

Redirect it only if there is a genuinely equivalent page to send people to. Otherwise let it return an error and stop worrying. The instinct to redirect everything comes from a fear of losing something, but a redirect to an irrelevant page is worse than a clean dead end for both readers and crawlers.

That is the whole decision, and it is simpler than the folklore around it suggests. The complication is that a lot of advice about status codes is repeated rather than checked, so it is worth going to Google's own documentation and reading what it actually says.

I did that, and one line in it contradicts something I have heard confidently asserted for years.

Does Google treat 410 differently from a 404?

No, and this is the part worth knowing. Google's documentation on HTTP status codes says that all 4xx errors, except 429, are treated the same, and that Google crawlers inform the next processing system that the content does not exist. A 410 and a 404 land in the same place.

That matters because the common claim is that 410 Gone gets a page removed from the index faster than 404 Not Found. Google's own page does not support that. It describes one handling path for the whole 4xx family, with 429 as the single exception.

What Google does say about the consequences is clear enough. Its documentation states that the indexing pipeline removes the URL from the index if it was previously indexed, that newly encountered 404 pages are not processed, and that the crawling frequency gradually decreases. It also says Google does not use the content from URLs that return 4xx status codes.

So if someone tells you to switch a batch of 404s to 410s to speed up deindexing, ask them where that is documented. I would rather be the person who checked than the person who repeated it.

Then is there any reason to use 410?

Yes, and the reason is honesty rather than optimisation. A 410 says the resource is gone on purpose. A 404 says it cannot be found, which might mean it never existed, or the URL is mistyped, or something is broken. Those are different statements about the world.

Google makes exactly this argument about redirects, and the logic carries over. Its documentation notes that while Google treats certain status codes the same way, they are semantically different, and advises using the status code appropriate for the situation so that other clients, for example e-readers and other search engines, may benefit from it.

That is the real case for 410. Not that Google rewards it, but that your own logs become readable. When you can separate deliberate removals from genuine breakage, a spike in 404s is a signal rather than noise, and you will notice a broken link the week it appears.

When is a 301 the right answer?

When a reader arriving at the old URL would be satisfied by the new one. That is the test, and it is about the reader rather than about link equity. If the content moved, merged into something broader, or was renamed, redirect it. If it was retired and has no successor, do not.

Google's documentation confirms the redirect does carry weight. For a 301 it says Google follows the redirect and Google systems use the redirect as a strong signal that the redirect target should be processed. For a 302 it says the same following behaviour but describes it as a weak signal.

It also says that any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead. So the redirect is a pointer, not a merge. What ends up assessed is whatever sits at the destination.

This is why mass-redirecting a deleted section to your homepage is a bad habit rather than a safe default. You are telling Google your homepage is the equivalent of two hundred different pages, which is not true, and you are telling a human they cannot have what they clicked on.

How many redirect hops will Google actually follow?

Ten, by default. Google's documentation states that its crawlers follow up to 10 redirect hops, while noting that specific products' crawlers may differ, that Googlebot generally follows 10 hops when crawling for general web content, and that Google Inspection Tools does not follow redirects at all.

Ten sounds generous until you have been through two site migrations. Chains accumulate because nobody updates the old rules, so a URL from 2019 points to a 2022 URL that points to a 2024 URL. Each redesign adds a hop and nobody removes one.

The practical habit is to redirect old URLs to the current destination rather than to the previous redirect, which means editing existing rules instead of only adding new ones. Every hop is also latency for a real person on a slow connection. Flattening chains before a migration is the cheapest performance work available, and it belongs in the same pass as building a redirect map before a migration.

If Google follows 302s anyway, why does the difference matter?

Because Google itself distinguishes them, and because other software reads your codes too. Google's documentation describes a 301 as a strong signal and a 302 as a weak one, which is a real difference in how much it trusts your intent even though the crawl behaviour looks identical.

The documentation also pairs the modern equivalents for you. It says 307 temporary redirect is equivalent to 302, and 308 moved permanently is equivalent to 301. If your host or CDN emits 307 or 308, you are not doing anything exotic.

My rule is to use permanent codes only for changes I am prepared to live with, because a permanent redirect gets cached by browsers and is genuinely awkward to reverse. If you are testing a new URL structure, temporary is the honest code and it saves you from a support ticket later.

What is a soft 404, and why is it worse than a real one?

It is a page that says nothing is here while returning a success code, and it is worse because it is a contradiction. Google's documentation explains that if the content suggests an error, an empty page or an error message, Search Console will show a soft 404 error.

This happens constantly on CMS-driven sites by accident. A collection page whose items were all unpublished, a search results template with no results, a filter combination that legitimately matches nothing. Every one of those serves a real page that contains an apology.

The reason it is worth fixing is that a real error code is actionable and a soft one is not. Google is also explicit that success does not buy you anything by itself, noting that for Google Search an HTTP 2xx status code does not guarantee indexing. A page returning 200 with nothing on it gets you the worst of both worlds. If you are managing what gets indexed at all, that belongs alongside controlling your sitemap deliberately.

Can you use 403 to slow crawlers down?

No, and Google says so directly. Its documentation instructs you not to use 401 and 403 status codes for limiting the crawl rate, and states that the 4xx status codes, except 429, have no effect on crawl rate. If you have been blocking bots this way to reduce load, it is not doing what you think.

The code that does carry that meaning is 429. Google's documentation says its crawlers treat 429 as a signal that the server is overloaded, and that it is considered a server error rather than a client one.

Understand the cost before you reach for it. Google says 5xx and 429 errors prompt its crawlers to temporarily slow down, and that for Google Search already indexed URLs are preserved in the index but eventually dropped. So it buys you relief now and costs you visibility if you leave it on. This is the sort of distinction I work through in more general terms in checking the status codes your site actually returns.

What should you do next?

Take your list of pages you are about to delete and sort it into two piles. Pile one has a genuine successor and gets a 301 to that specific page. Pile two does not, and gets an error code with no redirect. Resist creating a third pile called maybe the homepage.

Then check whether your host lets you return 410 for deliberate removals, and use it if it does, for the sake of your own logs rather than for Google. If it does not, a 404 is fine, because Google handles them the same way. Either way, flatten any redirect chains you find while you are in there.

If you are planning a deletion or a migration and want a second pair of eyes on the redirect decisions before they go live, reach out. Getting this right once is much cheaper than unpicking it later.