Redirect or delete a page: the decision tree

You are retiring a page. Before touching the server config, answer four questions in order: the first "yes" is your answer, and you stop there.

This is the decision you make before the URL breaks. If you are dealing with a 404 that already exists and you did not create, the triage is different.

The tree, in one table

Four rows, and one useful property: the tree never produces "redirect to the homepage". That is deliberate, and it is its main reason for existing.

1. Does a page cover the same need?

You rewrote the guide, merged two articles, replaced the 2023 pricing page with the 2024 one. 301 to that page. The reader gets what they came for and the accumulated value follows the redirect.

The test is not "is it about a similar topic". It is: would the person who clicked feel they arrived? If the answer is no, this is not the right target, and going one step further down the tree beats forcing it.

2. Does a broader page cover it?

The individual product is discontinued, but the category still exists. The specific event is over, but the events page is still there. 301 to the parent page.

It is a compromise, and an honest one: the reader lands somewhere related and can see why. This is where a redirect to the homepage would have been wrong: the homepage is not a broader version of anything.

One simple test for whether the target is right: if you would need to add a sentence on the destination page explaining to the visitor why they are there, the target is wrong.

3. Did the page have something worth keeping?

Inbound links from other sites, real traffic, a reference someone printed. If so, the question is not where to redirect: it is whether the page should have been removed at all. Restoring it, even in a shorter form, is often cheaper than losing what pointed at it.

This question is settled in five minutes, and it is almost always skipped:

• Inbound links are in Search Console or in your own link tracking.
• Traffic is in your analytics, over twelve months rather than thirty days, otherwise seasonal pages look dead.
• Internal links are found with any of the free link-finding methods, and they tell you how many places on your own site are about to break.

4. None of the above?

Let it 404, or return 410. No redirect, no invention. A URL that nothing points at and nobody visits does not need a destination. Remove it from your sitemap and move on. The temptation at this point is to invent a destination out of tidiness, and tidiness is not a reason a visitor cares about.

Which status code, and what for

The 302 is the one people use by mistake, because it is sometimes the default in a CMS or a plugin. It tells search engines "come back, this will return", so the old URL stays indexed and the new one struggles to take its place. If the move is permanent, the code should be too.

Once the rule is written, check it from the outside rather than in the config file: following a redirect hop by hop shows the real code, the full chain and the final address, which the configuration never tells you.

The three mistakes this tree exists to prevent

Redirecting everything to the homepage. It looks tidy in a config file and it answers nobody's question. The reader loses the thread, and the search engine reads the gesture as an admission that no equivalent exists.

Redirecting to something loosely related. A reader who wanted your discontinued product and lands on your blog index experiences it as an error, whatever the status code says.

Chaining redirects across successive migrations. Old URL to 2019 URL to 2022 URL to today. It works, until someone doing a clean-up cuts a link in the middle because nothing explains which rule still matters. Rewrite the chain to point straight at the current page, and you will also save every visitor two round trips.

The particular case of pages that come back

Some pages disappear and reappear: a seasonal offer, an annual event, a product out of stock. Deleting them each year and recreating them afterwards throws away everything the URL had accumulated, every time.

The right answer is to keep the URL alive and write the current state on it: "the 2025 edition takes place in March, here is the 2024 one in the meantime". It is less elegant than a clean deletion, and it is the only way to keep ten years of links on a single address.

What removing does not solve

Taking a page down makes none of the links pointing at it disappear. They sit on other people's sites, in your old articles, in bookmarks, in newsletters sent three years ago. Deletion moves the problem to the visitor's side, it does not erase it.

Nor does it solve the reasons usually given for bulk deletion. "Slimming the site down so it gets crawled better" rests on a worry that concerns almost nobody: crawl budget is a subject for very large catalogues, not for sites of a few hundred pages. "Removing thin pages to raise average quality" is a different decision, an editorial one, and it deserves to be made page by page rather than at a traffic threshold.

Removing in bulk, without breakage

Once the list runs past ten, three rules save the wasted week.

Decide first, execute afterwards. Fill in the "target" column for every row before touching the server. Decisions made along the way all look alike, and they all point at the homepage.

Work in coherent groups. All the product pages in one category together, all the events of one year together. The target is then obvious and justifies itself.

Spread it over two weeks. A hundred redirects put live on the same day are hard to verify, and one bad rule goes unnoticed among the others.

What to keep afterwards

Redirect rules are the memory of your decisions. They get removed "to clean up" a year or two later, by someone who was not there. Keep them, and leave a comment saying why they exist.

Keep a record of what you decided, too: which page, which target, which date. That is exactly what is missing on the day someone asks why an old address points where it does, and it is the heart of a migration check-list.

One last thing the tree does not cover: the links that left the deleted page for other sites disappear with it, and the ones leaving the remaining pages keep ageing on their own. Broken outbound links are a separate job, and the moment you are removing pages is the moment you think about them least.