Is It Better to Update Old Blog Posts or Write New Ones?

If your site has more than about thirty published posts, updating old ones beats writing new ones. Refreshed posts move in weeks instead of months because the URL already carries crawl history, internal links and whatever ranking signals it earned the first time, while a brand new URL starts from nothing.

That is the answer for most sites. It is not the answer for every site, and the case where it flips is specific enough to be worth naming up front.

The short answer, and the one case where it flips

Updating wins because you are not starting the ranking process over. Google has already crawled the URL, already has a quality assessment on it, and in most cases already ranks it somewhere. Moving a post from position 14 to position 6 is a much smaller ask than getting a new URL from nowhere to position 6.

New content wins in exactly one situation: when you have a real topic gap. If people are searching for something you have never covered, no amount of refreshing will produce a page that answers it. Refreshing improves pages that exist. It cannot invent coverage you never had.

So the honest split for a mature site is roughly 60/40 in favor of refreshing, not 100/0. If your archive is under thirty posts, invert it. You do not have enough surface area to refresh yet.

What the data actually shows

The most-cited numbers here come from HubSpot, and they are routinely misquoted, so here is the accurate version.

HubSpot found that 76% of their monthly blog views and 92% of their monthly blog leads came from posts published before that month. In other words, almost everything their blog produced came from the archive, not from that month’s new work. Acting on that, they ran an internal program updating old posts and more than doubled the monthly leads from the posts they optimized, with an average 106% increase in conversion rates.

The pattern generalizes even if the exact percentages do not. Any site with a few years of publishing behind it is sitting on traffic it already paid to acquire, slowly leaking as competitors update and it does not.

Why an old URL beats a new one

Four things an existing post has that a new one does not.

Crawl history. Google knows the URL and revisits it on a schedule. A new URL has to be discovered, queued and assessed before it can compete.

Existing rankings. Even a decayed post usually ranks for something. That gives you a real starting position and, more useful, Search Console data telling you which query it actually ranks for rather than the one you hoped for.

Internal links. Older posts have accumulated links from across your own site. New posts have none until you add them.

Age and stability. The URL has not changed, which matters more than a refreshed publish date. This is also why blanket-updating publish dates across an archive is a bad idea. It looks like manipulation and it throws away the signal that the page has been stable and useful for years.

What one post actually takes

Here is the gap in every guide on this topic. They all tell you what to change. Almost none tell you how long it takes, and the ones that mention it say something like “just skim through and fix a few issues.”

That is true for one post. It is completely false for three hundred. So here is the honest breakdown for a refresh done properly, not a skim.

Call it 25 minutes if you are fast and the post is short, 45 if it needs real rewriting. Now multiply.

This is why most content refresh projects get announced, run for two weeks, and quietly stop at post number forty. The strategy is correct. The arithmetic is what kills it.

When writing new content is still the right call

Refreshing is not a universal answer. Write new when any of these is true.

• You have a genuine topic gap. No page exists for a query your buyers use. Nothing to refresh.
• Your archive is under about thirty posts. Too little surface area. Build first.
• The old post is wrong at the foundation. If the premise has aged out entirely, a rewrite is a new post wearing an old URL, and sometimes that is fine, but do not pretend it is a 40-minute job.
• You are entering a new topic cluster. Clusters need a pillar and spokes that do not exist yet.

The mistake is treating this as a binary. Most sites should run both, weighted toward the archive once it is mature.

How to choose which posts to refresh first

Do not start at the oldest post and work forward. Start where the upside is largest.

Positions 5 to 20. These are one good refresh away from page one. Anything already at position 2 has little room, and anything at 60 usually has a bigger problem than stale metadata.

High impressions, low clicks. Google is showing the page and nobody is choosing it. That is almost always a title tag problem, which is the cheapest fix on the list.

Posts that used to perform and no longer do. Compare the last 3 months against the same period last year. Clean decay is the single best refresh candidate. If the drop is sharp rather than gradual, check it against the algorithm timeline first, because a page that fell off a cliff during the May 2026 core update has a different problem than one that faded over two years.

Anything cannibalizing another post. Two posts chasing one query means neither wins. Fixing that can lift both without touching the prose.

If you want to see how your archive is currently showing up in AI answers as well as classic search, the Search Console Generative AI report now gives you page-level impressions for AI Overviews and AI Mode, which is a useful second lens on which old posts are still earning visibility.

One caution on that lens. If a post is invisible in AI answers, refreshing the date will not fix it, because structure is doing most of the work there rather than freshness. That is a separate job, covered in how to rank in AI Overviews.

Doing it at scale

There are three honest options once you have accepted the arithmetic.

Do it yourself, slowly. Ten posts a week is sustainable alongside a job. A 250-post archive takes about six months. This works, and most people quit around week five.

Batch the mechanical layer. Roughly two thirds of that 43-minute checklist is mechanical: titles, meta descriptions, heading structure, alt text, schema, internal link mapping. Those can be generated and pushed through the WordPress REST API in bulk rather than edited by hand. The judgment-heavy third, deciding what is actually out of date and rewriting it, still needs a person. I wrote about the pipeline side of this in how I publish 50 SEO posts in an afternoon with Claude Code.

Hire it out. Which brings me to a disclosure.

I run bulk WordPress refreshes through the REST API, which is the batched-mechanical-layer option above. Fifty posts starts at $69 and 500 posts is $599, on Upwork with escrow and payment protection. Full database backup first, every change reversible, and a before-and-after Search Console report.

What it does not do, and I would rather say this here than in a refund conversation: it does not deep-rewrite the substance of 500 posts. Nobody can do that for $599 and you should be suspicious of anyone offering it. It handles the mechanical layer across the whole archive so your own time goes to the ten or twenty posts that genuinely need rewriting.

Frequently asked questions

Is it better to update old blog posts or write new ones?

Update, for any site with more than about thirty published posts. Existing URLs already carry crawl history, internal links and rankings, so they move in weeks rather than months. Write new content only when you have a genuine topic gap that no existing page covers.

How much traffic can updating old posts actually recover?

It varies too much to promise a number. HubSpot reported that 76% of their monthly views came from older posts and saw conversion rates rise an average of 106% after optimizing them. Treat published case studies as directional, not as a forecast for your site.

Should I change the publish date when I update a post?

Only when the update is substantial. Blanket-updating dates across an archive in one pass looks like manipulation and discards the stability signal an old URL has earned. Change the date when the content genuinely changed, and leave it alone for metadata-only fixes.

How long does it take to update one blog post?

About 25 to 45 minutes for a proper refresh, averaging around 43 minutes if you follow the full checklist including Search Console review, heading rewrites, schema, internal links and a cannibalization check. Light metadata-only passes are faster but move far less.

How many old posts should I update per week?

Ten per week is realistic alongside other work, which clears a 250-post archive in roughly six months. Batch them rather than spreading them out, and resist republishing everything at once, because a sudden archive-wide burst is the pattern that draws unwanted attention.

Which posts should I refresh first?

Start with pages ranking in positions 5 to 20, then pages with high impressions and low click-through, then posts that clearly used to perform and no longer do. These three groups hold nearly all the recoverable upside. Oldest-first is the wrong order.

Can updating old posts hurt my rankings?

It can if you change URLs, strip content that was doing the ranking, or republish an entire archive in one burst. Take a database backup first, ship in batches, and avoid rewriting pages that are already ranking well. Careful updates rarely lose ground.

Does refreshing content help with AI search visibility?

It helps, though freshness is one signal among several rather than a switch. Clear structure, direct answers near the top and accurate facts matter more. Some pages keep earning AI impressions for months untouched, so do not assume an unrefreshed post has disappeared from AI answers.

Should I delete old posts instead of updating them?

Delete only pages with no traffic, no links and no strategic purpose, and redirect rather than remove where a close replacement exists. Most underperforming posts are better consolidated into a stronger page than deleted outright. Pruning is a smaller lever than people expect.

Do I need a tool to refresh content at scale?

Not for fewer than about fifty posts, where manual editing is fine. Past that, the mechanical work of titles, meta, headings, alt text and schema is faster through the WordPress REST API than through the editor. The judgment work does not automate well.

Bottom line

Update old posts. For any site with a real archive it is the higher-return use of the same hours, and the reason is boring rather than clever: you are improving pages Google already trusts instead of asking it to trust something new.

The strategy is not the hard part, and it never was. The hard part is that a proper refresh costs about 43 minutes and most archives have hundreds of posts. Decide up front whether you are doing ten a week for six months, batching the mechanical layer, or paying someone. All three work. Announcing a refresh project and stopping at post forty does not.

Sources: HubSpot, The Blogging Tactic No One Is Talking About: Optimizing the Past · Animalz, Content Refresh Strategy · Semrush, When to Update Blog Content