404 vs 410 for a page you removed, and the two cases where neither is right
404 vs 410 is not a decision for Google — its documentation treats every 4xx except 429 identically. The choice that changes the outcome is between a 4xx, a 301 and a 503, and this chapter is the three questions that pick one.

For Google, 404 vs 410 is not a decision. Its documentation says every 4xx status except 429 is handled identically: the URL comes out of the index and gets crawled less over time. The choice that does change the outcome is between a 4xx, a redirect and a 503, and picking the wrong one of those three is how a removal turns into a page that keeps costing you.
Before you start
You need to be able to set the status code your server returns for a given path, which on some hosted platforms means a redirect rule rather than a response code. You also need to know one thing about the page you are removing: whether an equivalent still exists somewhere on the site. That single answer decides most of what follows.
Why 404 vs 410 is the wrong question to start with
Google's page on how HTTP status codes affect its crawlers, read on 2026-08-26, groups the whole 4xx range into one behaviour:
"All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist. In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren't processed. The crawling frequency gradually decreases."
Read the list that sentence covers: 400, 401, 403, 404, 410, 411. A page behind a login that answers 403 is being removed from the index on exactly the same terms as a page you deleted on purpose. That is the most useful thing on this page and it has nothing to do with choosing between two of them.
| Code | What Google does | Use it when |
|---|---|---|
| 404 / 410 | Drops the URL, crawls less | Content is gone for good |
| 301 | Strong signal for the target | An equivalent page exists |
| 302 | Weak signal for the target | The move is temporary |
| 503 | Keeps the URL for now | The page is coming back |
| 200 + error text | Reports a soft 404 | Never on purpose |
| Disallow | Keeps it in the queue | Page exists, should not be fetched |
The 503 row is the one people skip. Google's description of the 5xx range says "already indexed URLs are preserved in the index, but eventually dropped", and that it slows crawling in proportion to how many URLs are erroring. So a 503 buys time for a page that is genuinely coming back, and costs you crawl rate if you leave it there.
How to choose, in three questions
Answer these in order and stop at the first yes. They are ordered by how much of the page's history you keep, so the earliest yes is also the cheapest outcome.
- Does an equivalent page exist? Redirect to it with a 301. Google treats a 301 as "a strong signal that the redirect target should be processed", which is the only option here that carries anything forward
- Is the page coming back within days? Return 503. The URL stays in the index while you fix it
- Neither? Return 404 or 410, whichever your stack makes easier, and leave it alone
There is no fourth branch. If you find yourself looking for one, the honest answer is usually that you do not want the page gone at all — you want it improved, which is a different chapter: how to decide whether to refresh, merge or delete an old page sorts a page into four verdicts before any status code gets involved.
The deliverable: a check that takes one command
Before and after any removal, look at what the URL actually answers. The status a framework returns is often not the status a CDN passes on.
# Follow the chain and print every status on the way
curl -sIL -o /dev/null -A 'Mozilla/5.0' \
-w '%{http_code} %{url_effective}\n' https://example.com/old-page
Read the output against this list. Three of the five results are problems.
| You see | Verdict |
|---|---|
| 404 or 410 | Correct, if it is gone |
| 301 to a related page | Correct, if one exists |
| 301 to the homepage | Wrong target |
| 200 with an error message | Soft 404 |
| 403 on a public page | Silent removal |
Then open the Page Indexing report and read the soft 404 group. Google's crawl budget guidance names that report as the place to find them and adds the cost: "soft 404 pages will continue to be crawled, and waste your budget."
A status code is a sentence addressed to a machine. Returning 200 for a page that no longer exists is telling it the page is fine.
What going wrong looks like
The soft 404 is the most common failure and the hardest to notice, because every human check passes. The page loads, the message is polite, the status is 200. Google's rule for the 2xx range covers it: "If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error." Our measurement of what 27 homepages return for a URL that does not exist found live sites doing exactly this.
The second failure is the blanket redirect to the homepage. It looks tidier than an error page and it makes a specific claim on your behalf: a 301 tells Google the target should be processed in place of the original. Applied to a hundred deleted product pages, that claim is that your homepage is the replacement for a hundred different things.
The third is reaching for robots.txt. Google's crawl budget documentation contrasts the two directly: "Google won't forget a URL that it knows about, but a 404 status code is a strong signal not to crawl that URL again. Blocked URLs, however, will stay part of your crawl queue much longer, and will be recrawled when the block is removed." Blocking a deleted URL keeps it alive in the queue and stops the one signal that would have retired it.
The fourth is putting a page behind authentication and assuming that is neutral. It is not neutral; a 401 or 403 sits in the same sentence as 404 in Google's own table. If the page should stay indexed, it cannot be gated. If it should not, this works, and you should know that is what you did.
When you need it gone today
A 4xx removes a URL on the crawler's schedule, not yours. For anything urgent, Google's removals documentation describes a separate tool: "For quick removals, use the Removals tool to remove a page hosted on your site from Google's search results within a day." It also states the catch — "Requests made in the Removals tool last for about 6 months" — so it is a stopgap in front of a real fix, and the documentation lists three of those: remove or update the content, password-protect the page, or add a noindex tag.
One point of care: the tool works on URLs, and the documentation warns that "in many cases, different URLs can point to the same page", giving the example of a path in different letter cases and a parameter form of the same content. Removing one variant leaves the others.
Where this stops
Everything above is about Google, because Google is the one that publishes a table. Other engines and retrieval clients are not obliged to treat 404 vs 410 the same way, and none of them documents it at this level, so if you want the semantic distinction for its own sake, 410 is the honest code for content you deliberately destroyed. We cannot tell you it buys anything measurable.
Your own logs are the other place the distinction earns its keep. A 404 in an access log means someone asked for a path that does not resolve, which is a bug report as often as it is a removal; a 410 in the same log is a path you retired on purpose. Splitting them makes a weekly scan possible, and that is a local benefit rather than a search one. It is also the only argument for 410 that survives reading Google's table.
This chapter also does not cover what a removal breaks elsewhere. Internal links, sitemap entries, canonical targets and structured data can all still point at the URL you just retired, and that damage is the subject of what changing a URL affects. Do that pass before the status code change, not after. If you want to see how a page reaches an engine in the first place, see how QueryWin works.
Common questions
Is 410 faster than 404 for getting a page out of Google?
Google's documentation puts both in the same row and says every 4xx except 429 is treated the same. There is no published figure showing one is faster, and we did not measure it. If speed is what you need, the removals tool is the documented answer.
What should a 404 page look like?
Like a useful page that happens to return 404. The status code is what the crawler reads; the content is what the person reads. The only combination to avoid is a helpful page that returns 200, which is the soft 404.
Should I redirect deleted pages to a category page?
Only if the category is genuinely the closest equivalent for that specific page. A 301 asserts that the target should be processed in place of the original, and a category page can carry that for one product but not for every product you ever removed.
Do 404s hurt my rankings?
Not by existing. A 4xx makes Google stop using that URL and gradually crawl it less, which is what a removal is supposed to do. The costs show up elsewhere: a 404 that is still linked from your own navigation, or a 404 on a URL that still earns links from other sites.
What about a page that only exists in one season?
If it comes back within days, 503 keeps the URL in the index while it is away. Across months, that stops working — 5xx URLs are "preserved in the index, but eventually dropped" — and the page is better left live with the content updated.
Part of the QueryWin handbook · Level 3


