410, 404 or 301: How to Delete Pages Properly

You have decided to remove a batch of pages. Maybe they were thin, maybe they were written by somebody who no longer speaks for the business, maybe they simply stopped being true. The removal itself takes minutes. The part that decides whether it helps or hurts is what your server says when a crawler comes back for a page that is no longer there — and most sites never make that decision deliberately at all.

The three answers and what each one actually claims

HTTP gives you three reasonable responses for a page you have removed, and they are not interchangeable. Each one makes a different claim about the world.

• 404 Not Found says: this URL has nothing at it. Maybe it never did, maybe something broke, maybe it will be back. It is the shrug of status codes.
• 410 Gone says: there was something here, it was removed on purpose, and it is not coming back. It is a deliberate, permanent statement.
• 301 Moved Permanently says: the thing you wanted still exists, at this other address. It transfers the request, and the ranking signals with it.

Pick by intent. If you are removing content because it should never have been published, 410 is the honest answer. If you have merged three overlapping posts into one good one, 301 to the survivor is the honest answer. 404 is what you leave when you genuinely do not know — which, for a planned removal, should be almost never.

Why 410 is worth the extra effort

Google treats 404 and 410 similarly but not identically. A 404 is ambiguous enough that crawlers will come back and check again, sometimes for a long time, because plenty of 404s are accidents — a bad deploy, a typo in a link, a temporarily broken database. A 410 removes that ambiguity. You are telling the crawler it does not need to keep asking.

For a handful of pages the difference is academic. For a large removal it is not: every URL you leave as a soft maybe is a URL that keeps getting requested, keeps appearing in your crawl logs, and keeps occupying a slot in a crawler's model of your site. When you have decided, say so.

The redirect trap

There is a strong temptation to redirect everything you delete to the homepage. It feels tidy — no error pages, no broken links, nothing red in a crawl report. It is also the wrong answer, and search engines have understood it as such for years.

A redirect is a claim that the destination satisfies the original request. If someone asked for a specific guide and you send them to your homepage, that claim is false, and it gets treated as a soft 404 anyway: the crawler notices the destination has nothing to do with the request and handles it as a removal, except now you have also spent a redirect and confused your own analytics.

Redirect when there is a genuine successor. Do not redirect to invent one.

A decision you can actually follow

1. Is there a page that genuinely answers the same question the removed page answered? If yes, 301 to it. One specific page, not a category index, not the homepage.
2. Did you remove it on purpose, with no successor, and it is not coming back? 410.
3. Are you unsure whether it is coming back, or is the removal temporary? Leave it 404 — or better, do not remove it yet.
4. Is it a page you never want indexed but still want people to reach? That is not a removal at all. That is noindex, and the page stays up.

Implementing it without touching every file

On Apache, the practical mechanism for a bulk removal is a block of RedirectMatch rules in the .htaccess file covering the directory you removed from. Group them between comment markers so the block is obviously machine-managed and can be regenerated rather than hand-edited.

This matters more than it sounds, because of a detail that catches people out: if you deploy over FTP, deleting a file locally does not delete it on the server. Your build pushes files up; it does not reconcile what is already there. Without an explicit status-code rule, a page you deleted from your repository months ago can still be sitting on the server, still returning 200, still in the index — and you would never know, because it is gone from every list you look at.

Whatever your stack, the check is the same: after the removal, request one of the dead URLs yourself and read the status line. Do not assume.

What to do about the sitemap

Remove the dead URLs from your sitemap, but not on the same day. A sitemap is how you ask a crawler to come look. If you delete the entry at the same moment you delete the page, you have removed both the page and the invitation to discover that it is gone — and the URL can sit in the index for longer than it otherwise would.

Leave the entries in place for a crawl cycle or two so the 410s get picked up, then regenerate the sitemap from what actually exists. If your sitemap is generated by a script, this is the one time you want to run it late rather than early.

The part nobody wants to hear

If a removal is large enough to need a strategy, the removal is not your real problem. Pages get deleted in bulk for one of two reasons: they were mass-produced without anyone reading them, or they made claims the business cannot stand behind. Both are upstream failures, and fixing the status codes fixes neither.

Do the technical work properly — it is genuinely worth doing, and doing it badly leaves a mess that outlives the content. Then go and fix whatever process produced pages you eventually had to delete, because otherwise you will be writing this same block of rules again next year.

A short checklist

• Decide intent before you decide status code: gone for good, moved, or unknown.
• One-to-one redirects only, to a page that answers the same question.
• 410 for deliberate permanent removals, in a regenerable block.
• Verify the live status code yourself — deploys do not always delete.
• Keep sitemap entries for a crawl cycle, then regenerate.
• Fix the process that created the pages, not just the pages.

The status code is not paperwork. It is the only sentence your server gets to say about a page you removed — make it a true one.

← Back to all articles