Search Engine Optimization

How to refresh, merge or retire old blog posts: our method

9 min readBy Jaskirat Singh Talwar

Hands sorting old printed pages into a box, with a bundle tied in orange string

Decide every old post one of three ways. Refresh it if the topic still matters to your buyers and the post has something worth keeping: keep the URL, fix the facts, add what only you can say. Merge it if another post covers the same question better: move the useful parts there and 301-redirect the old URL. Retire it if it is outdated news or off-topic for your business: redirect it to the closest relevant page and drop it from the sitemap. In October 2026 we applied exactly this to our own blog of 222 posts; this is the method and what the files say we did.

Key takeaways

  • Our 14 October 2026 audit sorted 222 posts (written between 2013 and 2023, none after March 2023) into four classes: 53 refresh, 47 light update, 86 consolidate and 36 retire.
  • Before this batch, our release file listed 52 refreshed posts and 88 old URLs retired with a 301 into 44 destinations: 41 stronger posts and 3 service pages.
  • A refresh keeps the original publication date and shows an "Updated" date; we change that date only for a substantive change, as Google's helpful-content guidance warns against faking freshness.
  • Redirects go in one hop to the final page. Google treats a permanent redirect as "a signal that the redirect target should be canonical".
  • The post you are reading was itself on our merge list. Instead of merging it, we rewrote it to answer a question no other post on the site answers, and moved it to a URL that matches the new topic, with a 301 from the old one.

Why clean up an old blog at all?

Because old posts that nobody needs make the whole site look less trustworthy and compete with each other. Our audit found the typical problems of a blog written over a decade: every post credited to a generic account ("impinge" on 205 posts, "administrator_Impinge" on 17), dated product news, year-stamped trend lists, and clusters of posts chasing the same question. The audit named the worst clusters: two AngularJS posts, three landing-page posts, eight IoT posts and four blockchain posts.

Google's own guidance gives the reason not to keep everything as it is. Its page-indexing report says "Don't expect every URL on your site to be indexed", and its helpful-content questions ask whether content is "primarily made to attract visits from search engines". A post that exists only because it once targeted a keyword fails that test.

How do you decide: refresh, merge or retire?

Ask three questions of each post, in order.

  1. Is the topic still relevant to what you sell? If not, retire it. Our retire list held 2016 product news (an iPhone launch, a Rails release, Google's Possum local update), year-stamped trend lists and promotions for platforms we no longer offer.
  2. Does another post answer the same question? If yes, keep the stronger one and merge the other into it. Keep one primary topic per post: two posts chasing one query compete with each other.
  3. Can you add something the current top results do not have? If yes, refresh it. If you cannot name that information gain (first-hand experience, your own data or tools, a real project), a rewrite will be one more generic page.
Decision When What happens to the URL What happens to the content
Refresh Topic matters to buyers, and you can add first-hand value Kept, same canonical Strong parts kept; facts, sources, author, FAQ updated
Light update Still accurate in outline Kept Facts, dates, dead references and titles fixed
Merge (consolidate) Another post covers the same question better 301 to the stronger post Useful paragraphs moved into the stronger post
Retire Outdated or off-topic, nothing to merge 301 to the closest relevant page; or 404/410 if there is none Dropped; removed from the sitemap

The audit proposed 122 redirects (86 consolidate plus 36 retire) and 100 live legacy posts (53 refresh plus 47 light update) instead of 222.

What did a refresh involve for us?

A refresh is an improvement, not a rewrite from scratch. For each one we listed what to keep, what to strengthen and what to add, then:

  • kept the slug and canonical exactly, so existing links and any search history stay with the page;
  • kept the original publication date and added an "Updated" date, which our release file enforces ("A refresh keeps the legacy post's own publication date");
  • replaced the generic author with one of three named authors;
  • rewrote the opening as a direct answer, added a short FAQ and a sources list, and checked every number against a primary source;
  • linked the post to its service page and to related posts.

In a second round we refreshed posts whose old topic had disappeared altogether (a 2016 phone launch, a retired chat app). The rewritten posts answered a different question, so a URL like /iphone-7-specifications-.../ would have misdescribed them. Those posts moved to new, accurate URLs, each old URL redirects to its new one with a single 301, and they carry the date they were rewritten rather than the old publication date.

Some refreshes absorbed several older posts at once. In our release file, the content strategy post and the IoT app development post each absorbed six old URLs, and three of the 2026 trend posts absorbed five each. Our refreshed content strategy guide is one of those merge targets.

How should merged and retired posts be redirected?

With a permanent server-side redirect to the final destination, in one hop. Google's redirect documentation says "we recommend that you use a permanent server-side redirect whenever possible" and that the 301 and 308 codes "mean that a page has permanently moved to a new location".

Rules we followed:

  1. Pick the closest page, not the home page. Of our 88 retired URLs, 85 point to a stronger post and 3 to service pages. A 2016 preview of an Apple event went to our iOS development page, not to the blog index.
  2. No chains. Every merge target was itself a refresh or a light update, so no redirect points at a page that is about to move. The audit also flagged two existing redirects that would have become chains once their targets merged, so they had to be repointed.
  3. Wait for the destination. Our redirect plan held a "waiting" list: old posts stayed live until the post they would merge into had been refreshed, so readers never landed on a weaker page.
  4. Remove the old URLs from the sitemap. A sitemap should list only canonical pages that return 200.
  5. Use 404 or 410 only when nothing relevant exists. Google treats them the same: "URLs that are already indexed and return a 4xx status code are removed from the index."

Our account of moving impingesolutions.com from WordPress to Astro shows how we ran redirects at the edge, and the website relaunch SEO checklist shows how to test redirects after a change.

What about dates and the sitemap?

Honest dates are part of the method. Google's helpful-content guidance asks: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" So:

  • the "Updated" date and dateModified change only for a substantive change (facts, sections, advice), never for a typo fix or a re-import;
  • the sitemap lastmod follows the same rule; Google says it "should reflect the date and time of the last significant update to the page" and uses it only if it is "consistently and verifiably" accurate;
  • a new post is dated the day it is published; nothing is backdated.

Google also "ignores <priority> and <changefreq> values", so there is no point tuning them.

Why is this post not about writing SEO-friendly blogs any more?

Because we already have that post. The 2017 version of this post gave tips for writing an SEO-friendly blog: pick keywords, use them naturally, link out and internally, write longer posts. Most of that is now covered better in our guide to SEO content that ranks and gets cited, and our redirect plan had the old URL marked to merge into it.

Applying our own rule, a merge was the default. We rewrote the post instead only because it could answer a different question that no post on the site answered: how to clean up an old blog, with our own audit as the evidence. That is the test we would apply to any client's post too. If you cannot name the different question, merge.

How do you know it worked?

Watch indexing before traffic. Search Console's page-indexing report shows which URLs are indexed and why others are not, including "Crawled - currently not indexed" (crawled but not indexed, and it "may or may not be indexed in the future"). Check it monthly: retired URLs should leave the index, refreshed ones should be crawled again. Our Search Console guide explains the report. We are not quoting traffic results for our own cleanup here; it is too early to judge, and a single month says little.

If you want a second opinion on which of your posts to keep, our SEO services start with the same audit.

FAQ

Should I delete old blog posts that get no traffic?

Not automatically. Merge a post into a stronger one if it overlaps, refresh it if the topic matters and you can add value, and retire it with a redirect to the closest page if it is outdated or off-topic.

Does deleting old posts improve SEO?

Removing posts is not a ranking trick. The benefit is a site where each page answers one question well, without several weak posts competing for the same query.

Should a refreshed post get a new publication date?

No. Keep the original publication date and show an "Updated" date for substantive changes. Changing dates without real changes is what Google's guidance warns against.

Where should a retired post redirect?

To the closest relevant page, such as a stronger post on the same topic or the matching service page, in one hop. If nothing relevant exists, return 404 or 410.

How many posts should I refresh at once?

As many as you can do properly. Each refresh needs facts checked against current sources and something new to add; a batch of quick rewrites with new dates is the kind of change Google's freshness question is aimed at.

What if an old post has backlinks?

Then the redirect matters most. Keep the URL with a refresh, or redirect it to the page that best answers the same question, so the link still leads somewhere useful.

Sources (6 links)
Share this article