How Often Should You Update Old Blog Posts? A Schedule You Can Defend and Keep

How often to update old blog posts has no measured answer, so use a rule: review every post you have already published on a calendar, and update one only when a review or a trigger shows that a fact, a price, the query or the ranking has changed. We found no published study that measures how often ranking pages get updated, and no number from Google, so you choose the interval and your working week tests it.

"Update your blog" can also mean publishing new posts. The FAQ takes that question.

The short answer, and what it rests on

There is no universal number for how often you should update old blog posts. Two intervals have a traceable origin, and neither is a measurement: twelve months, the gap after which the review reminders of Google's Search documentation team came back, by its own account in 2024, and 180 days, the default age at which Unstale lists a post as stale. One is a team's internal practice, the other a convention. Use the shorter for time-sensitive posts (prices, statistics, comparisons, legal points), the longer for evergreen content. Then test it against your week: an interval you cannot keep is the wrong one.

What the published numbers are worth

None of the frequencies in circulation rests on a measurement of frequency.

We read six guides on September 17, 2026, the ones Google ranks or cites in its AI Overview for this question and close variants. Four give a range in months: three to six for most of a blog; six to twelve for fast-moving industries, twelve to twenty-four for evergreen; six to twelve for evergreen, three to six for trend and data pieces; a review of top pages every six to twelve months. Every six to twelve months is one guide's fast lane and another's slow lane. None of the four cites a study, a sample or a measurement.

The only data in the set is Siege Media's content refresh study, last updated April 22, 2025, collection date and market not stated. It measures the average age of the date Google shows in the snippet, over the top 10 results, for 18 keyword families of up to 1,000 keywords each: 730 days across all keywords, from 400 on "best" queries to 1,420 on "calculator" queries. It then recommends updating "best software" posts every six months, "if not more frequently", a family it measures at 530 days. An age is not a frequency.

Ahrefs' study of how old top-ranking pages are (May 15, 2025, 1.3 million US keywords): the page in position 1 is 5 years old on average, and 72.9% of top 10 pages are more than 3 years old. Age there means first seen by Ahrefs' crawler: old addresses rank well, and nothing says how often they were edited.

Nobody has measured a frequency, and neither have we.

What Google actually says about fresh content

Google reserves freshness for the queries that call for it, and answers no to anyone who edits a site to look fresh.

We have various "query deserves freshness" systems designed to show fresher content for queries where it would be expected.

Are you adding a lot of new content or removing a lot of older content primarily because you believe it will help your search rankings overall by somehow making your site seem "fresh?" (No, it won't)

The first is from A guide to Google Search ranking systems, the second from Creating helpful, reliable, people-first content, both updated December 10, 2025 and read on September 17, 2026. In that second list, the bullet just above targets dates changed on content that has not substantially changed. None of the six guides quotes Google on freshness; one links that second page without repeating its answer.

Google's podcast agrees. In Search Off the Record, episode 73 (May 9, 2024), Lizzi Sassman asks whether every page must be less than six months old. John Mueller: "No. Definitely not." (03:34). He calls it a question of strategy, not a direct SEO factor: does the page match what people look for, is the information still correct.

We looked for a Google statement from 2024 to 2026 giving a numeric frequency. As of September 17, 2026, we found none.

Review on a calendar, update on a trigger

The calendar is for reading, the trigger is for writing: review a post on a schedule, update it only when something changed.

Reviewing is opening the post and checking its facts, figures, links and what the query now asks. Updating is changing it. Both camps in the six guides are half right: the calendar camp describes a review, the wait-for-a-drop camp an update, and none separates the two.

The only cadence we found at Google is a review schedule. In episode 73 (May 9, 2024), Lizzi Sassman describes a bot that reminds the documentation team to reread a page after a set time, never stated, and check its links and advice (30:48). After one big spring cleaning, "the bot came back 12 months later" (31:20). That is one team's internal practice, not ranking guidance.

An update waits for a trigger, whatever the review schedule says:

• A fact, a price or a version number changed.
• The query no longer means what it meant.
• In Search Console, impressions hold while clicks fall, or the position slides over months.
• A dated event known in advance, such as new rates on January 3.

Which signals say a post is due, and which posts come first, is the main guide's job: updating old blog posts. Before treating a drop as a trigger, check that it really is content decay. And when a review says merge or remove instead, that choice is prune or refresh.

When to come back to a post you already updated

In WordPress the return interval already exists: it is Unstale's age threshold, counted from the last modified date.

A published refresh resets that date to now. The post leaves the stale list and returns one threshold later, 180 days by default. The plugin has no other waiting rule. So you come back to a post one threshold after it was last published, unless a trigger fires first.

The limit: every WordPress save resets the last modified date, a corrected typo included. Age measures time since the last save, not since the last real review, so one fixed typo takes the post off the list for a full threshold.

Do not come back to a post before the page has been recrawled and served again. Of the six guides, one says a few months, another promises results within sixty days, and neither cites anything. We are not going to invent a number.

The opposite mistake exists too: a post that ranks and whose facts hold gets a review, not a rewrite. Editing it to look fresh is what Google answers with (No, it won't).

The threshold, its three bands and the screen that shows them have their own guide: find outdated content on your site.

How many posts a week your backlog demands

A schedule is a division: the posts in your backlog, divided by the weeks in the interval.

posts per week = posts to cover / weeks in the interval

Take a site with 520 published posts.

If the quotient does not fit in your week, the interval is wrong, not the team. The division also reads backwards: one person who seriously reviews 5 posts a week covers a 520-post backlog in 104 weeks, two years. Promise that site six months and you promise 20 reviews a week from someone who does 5.

Google's documentation team hit the same wall in its internal reviews: every reminder came back the same week, and Lizzi Sassman's verdict was "that's too much workload" (episode 73, May 9, 2024, 31:20). Her conclusion: spread the reviews out, so each one gets the time to be done properly.

Unstale Pro's automation, off by default, takes the stalest posts first: 5 per run, one daily run, a 180-day threshold. Those defaults hold 5 x 180 = 900 posts under the threshold, on one condition: every refresh is read, approved and published, because publication resets the date and nothing publishes without review by default. That is 5 x 7 = 35 diffs to read a week. Above 900, the queue grows faster than it empties: raise the posts per run (hard cap: 50) or lengthen the threshold.

A second pass need not cost what the first did. The calculator prices one 12 months on, at the Minimal level: what an AI refresh costs.

Putting it on the calendar in WordPress, and what Unstale does not see

Two mechanisms put this schedule on the calendar in WordPress: a one-off scheduled refresh in the free plugin, and an age-based automation in Pro.

Schedule refresh, in the free plugin. In the bulk actions of Content health, you pick a date and time, up to a year ahead, for up to 50 posts per batch. Each post shows "Scheduled for" and a Cancel link. If WordPress gets to it more than a day late, nothing starts and the post says why. The result waits in the review queue, with its diff. This is the tool for the dated trigger above.

Automation, in Pro. It runs hourly, daily or weekly, with per-category rules, each carrying its own age threshold and refresh level: a rhythm per type of content, held in settings. Licensing is on the pricing page.

Unstale does not read Search Console, in any version. It fires on age, never on a drop. And a scheduled refresh is one-off, it does not repeat. The trigger side stays with you, in Search Console.

Questions people ask about how often to update old posts

How often should I publish new blog posts?

That is another question. "How often should you update your blog" or "how often to update website content" can mean publishing new posts or updating old ones, and this page covers only the second. New posts get what the review schedule leaves of your week.

Should I spend more time updating old posts or writing new ones?

No published split is sourced. One guide we read gives three on a single page: one old post for two new, 60% of your time on updates, then half and half. Count what your review schedule takes per week; new posts get the rest.

Should I add "Updated for 2026" to the title?

Only if the content changed for 2026. Of a year stamped on an unchanged list, Google's John Mueller said: "I think it almost comes across a bit as clickbait." (Search Off the Record, episode 73, May 9, 2024, 21:12). A point about readers, not rankings.

Does fixing a broken link or a typo count as an update?

It is maintenance, and no reason to move the visible date. On Google's own blog, Lizzi Sassman leaves the date alone after fixing a link: the blog sorts by it, and nothing meaningful changed. A real addition gets a dated note (Search Off the Record, episode 73, May 9, 2024, 19:07 and 20:02). WordPress moves its last modified date anyway. The visible date is its own question: changing the publish date.

Should every lastmod in my sitemap show today's date?

No. Google's John Mueller called it "just lazy": trivial to detect, and it makes real updates harder to spot. He was answering someone whose competitor does it, on Reddit then Bluesky, not official channels (reported by Search Engine Roundtable, April 29, 2025). A changed lastmod is not pointless, he added; today's date on every URL is.

Do AI answers prefer recently updated pages?

Probably a little; nobody outside those systems can say how much. The one public figure has no published sample, as discussed under content decay. How often to refresh content for SEO or for AI answers: when a fact changes. A date alone does nothing. The four guides we read that Google's AI Overview cites on this query each put their answer in a standalone sentence, at the top of a section or in an FAQ.

Can Unstale refresh the same post every few months on its own?

Not post by post. Schedule refresh is one-off. What comes back on its own is the threshold: a published refresh puts the post under it, and the post crosses it again 180 days later, by default. Unstale Pro's automation, if switched on, picks up whatever crossed it, stalest first.

Quoted material from Google Search Central is used under the Creative Commons Attribution 4.0 License. Sources: "A guide to Google Search ranking systems" and "Creating helpful, reliable, people-first content", Google Search Central documentation.