Content Decay: How to Decide Whether to Refresh, Merge or Prune a Page

Content decay is the slow loss of search traffic to a page that used to earn it. The fix is not "update everything". It is to work out why each page is fading, because a page that is out of date, a page that has been outcompeted, and a page that answers a question nobody asks anymore need three different treatments. Refresh the first, merge the second into something stronger, and either prune or leave the third.

Finding them takes twenty minutes in Search Console. Choosing takes a bit of honesty.

Finding the pages that are actually decaying

Search Console is enough for this. In the Performance report, compare the last three months with the same three months a year earlier, switch to the Pages tab, and sort by the change in clicks. The pages with the biggest drops are your candidates.

Before you touch anything, split the drop into its two possible causes using the impressions and position columns:

• Clicks down, impressions roughly flat, position roughly flat: demand is still there and you are still showing up, but fewer people click. Often the result changed around you (an AI Overview, a video carousel, a competitor with a sharper title) or your title and snippet have gone stale.
• Clicks down, position down: you have been outranked. Someone else now answers the question better, more recently, or more completely.
• Clicks down, impressions down, position flat: the question is being asked less. This is demand decay, not page decay, and no amount of rewriting brings the searches back.

Then open the Queries tab for each page. A page that has lost its main query but kept the long tail usually needs a refresh. A page that has lost everything to a single competitor usually needs a rethink.

Ignore the pages that only ever got a trickle. Decay matters where there was something to lose.

When to refresh

Refresh when the topic still matters, people still search for it, and the page is losing because its content is behind. Signs:

• It states facts, prices, versions or rules that have changed.
• It describes a process the way it worked two years ago.
• The examples are dated in a way readers will notice.
• Competing pages that now outrank it cover a sub-question yours skips.

A real refresh changes the substance. Rewrite the sections that are wrong, add the sub-question you missed, replace the dead example, fix the screenshots. Then update the visible date and the dateModified in your Article structured data to match, because Google's byline date guidance asks for the two to agree and for dates to reflect when the page was actually updated.

What a refresh is not: changing the year in the title, swapping two sentences, and republishing with today's date. Google names this one explicitly in its helpful content guidance as a warning sign: "changing the date of pages to make them seem fresh when the content has not substantially changed." It does not help, and it trains readers to distrust your dates.

When to merge

Merge when two or more of your own pages answer the same question and are splitting the result between them. You will see this in Search Console as two URLs that appear for the same queries, often alternating week to week, neither ranking as well as one combined page would.

The merge itself:

1. Pick the URL that has the stronger history, more external links, or the cleaner address. That becomes the surviving page.
2. Bring across anything the other pages had that the survivor lacks: a section, an example, a better explanation of one point. Do not paste the whole thing in. You are building one good page, not a long one.
3. Redirect the retired URLs to the survivor with a 301. Redirect each page to the most relevant section if the page covers several things, otherwise to the top.
4. Update your internal links so they point straight at the survivor rather than bouncing through the redirect.
5. Give it a few weeks. Consolidation takes time to settle, and the combined page will usually end up ranking better than either half did.

Merging is also the right answer for the "ten thin posts on one topic" problem that older blogs accumulate. One deep page with a sensible structure almost always beats a cluster of 400-word posts that each cover a sliver.

When to prune, and when to leave it alone

Prune when a page has no search demand, no links, no traffic from anywhere else, and no reason to exist beyond the fact that it was published once. An announcement from 2019, a seasonal promotion long gone, a half-finished guide nobody linked to. Remove it and return a 404 or 410, or redirect it if there is a genuinely relevant replacement. Redirecting unrelated pages to the home page is not a fix; Google treats that much like a 404 anyway.

Leave alone the pages that look dead in Search Console but do a job elsewhere. The terms page, the page your sales team sends to prospects, the explainer that gets read from your newsletter. Not every page is for search.

One caution. Pruning has a reputation as a ranking lever, and it mostly is not. Google's helpful content guidance says, in so many words, that adding lots of new content or removing lots of old content because you think it makes the site seem "fresh" does not help. Prune because a page is genuinely useless, not because a dashboard told you a smaller site ranks better.

A simple routine so it does not pile up

Decay is continuous, so the review should be too. A quarterly pass is enough for most sites:

• Pull the year-over-year page comparison from Search Console.
• Tag each declining page: refresh, merge, prune, or leave.
• Do the refreshes first. They are the quickest wins and the ones readers notice.
• Batch the merges, because each one involves redirects and link updates.
• Keep a short log of what you changed and when. When a page recovers (or does not), you want to know what you did.

If you have a large site, prioritise by what the page is for. A declining service page costs you leads; a declining blog post from 2021 costs you very little. Spend your attention accordingly.

What does not count as decay

A few patterns look like decay and are not:

• A seasonal dip. Compare year over year, not month over month, or you will "fix" pages every January.
• A short-lived drop that fully recovers in a week or two. Ranking volatility is normal around Google's updates, and a page that bounces back needed nothing.
• A drop on the whole site at once. That is a site-level issue (a technical change, a core update, a migration), and page-by-page refreshes will not address it.
• Fewer clicks while impressions rise. The page is being shown for more queries than before, probably in lower positions. That is often a sign of a page broadening, which can be fine or can mean it has lost focus.

Questions people ask

How old does a page have to be before it decays?

Age is not the trigger, change is. A two-year-old page about something that has not changed can be perfectly healthy, and a six-month-old page can be stale if its subject moved. Watch the data, not the calendar.

Should I change the URL when I rewrite a page?

Almost never. The URL carries the page's history and links. Rewrite the content, keep the address. Only change the URL if the old one is actively misleading about what the page is now, and then redirect the old one.

Does updating the date without changing much hurt?

It does not help, and if the visible date and the structured data disagree, or the "update" is cosmetic, you are inviting Google to ignore your dates altogether. Update the date when the content genuinely changed.

A note on who does this work

Reviewing old content is the kind of task that gets scheduled and then skipped, because new content is more fun. It is built into the monthly cycle of Ranked's SEO service: the pages losing ground get flagged, and the decision between refreshing, merging and pruning is made from the data rather than from a hunch. If you would like us to run that review on your site, tell us about your project.