How to Build a Content Refresh Workflow for Old Blog Posts

How do you decide which old blog posts to refresh first?

Start with posts that still get impressions but have lost position, not posts with no traffic at all. A page with impressions has already earned relevance and is losing a tiebreak you can influence. A page with zero impressions has a different problem, and refreshing the writing will not solve it.

Most refresh projects fail at this first decision. Somebody sorts the blog by date, picks the oldest posts, and rewrites them. That sorts by age, and age is not the problem. Some three year old posts are still the best thing on the internet for their question, and some six month old posts were never good. You want a signal about performance, not a calendar.

This walkthrough uses Google Search Console, because it is free, it is the only place the actual impression data lives, and its filtering is more capable than most people realise. I will go through the exact filters, the traps in the data, and what I change once a post is selected.

What does step one look like in Search Console?

Open the Performance report for Search results and add a date comparison. In Search Console you add a filter by clicking Add filter in the filters row at the top of the report, and the Search type and date filters are always present and cannot be removed. Compare a recent period against the equivalent earlier one.

The Search Console documentation makes a specific recommendation here that I would follow. When comparing two date ranges, it suggests using the weekly or monthly granularity option, because aggregating by week or month neutralises the day of the week effect and gives a clearer view of genuine long term trends. Daily comparison produces noise that looks like signal.

Once the comparison is applied, the results table shows a difference column comparing values in each row. Group by page, sort by the difference in average position, and you now have a list of pages that were doing better and are doing worse. That list is your refresh queue, and it took about two minutes to build.

How do you use regex to pull a content cluster in one filter?

Use the custom regex filter on the Pages dimension. Search Console documents that you add a filter, choose Pages, choose Custom regex, and enter your expression. For multiple values you separate them with a vertical bar and wrap the whole expression in parentheses, and you can invert it by choosing does not match regex.

This is the feature that turns Search Console from a page by page tool into a cluster tool. If you have fourteen posts about one topic scattered across three years, one expression pulls them all into a single view, and you can see whether the cluster as a whole is gaining or losing. Individual pages within a cluster often cannibalise each other, and you cannot see that one page at a time.

Two details from the documentation will save you time. The syntax is RE2, and default matching is a partial match, so your expression can match anywhere in the target string unless you anchor it with a caret for start of string or a dollar sign for end of string. Default matching is also not case sensitive, and you can prepend a case sensitivity flag if you need exact case. Most people's first regex filter returns too much because they forgot the partial match default.

Why do the numbers not match your analytics?

Because filtered Search Console data is not a complete census. The documentation states plainly that filtering your data by query or URL can affect the report totals due to data truncation and the omission of anonymised queries. The moment you filter, your totals stop being comparable to unfiltered totals.

This catches people out in a specific and embarrassing way. You filter to a cluster, add up the impressions, compare that to the site total, and conclude the cluster represents some percentage of your traffic. That percentage is wrong, and it is wrong in a direction you cannot calculate. Use filtered data to compare periods against each other, not to compute shares of a whole.

There is a row limit to respect as well. Search Console applies a thousand row limitation to performance data, which matters if your regex matches a large cluster on a large site. If you are working with a blog of any real size, pull narrower clusters rather than trying to see everything at once. I go into the reporting side of this in more depth in building a monthly SEO reporting view in Looker Studio.

How do you check whether AI features are sending anything?

Open the generative AI performance report. Search Console documents that this report shows how your site performs in generative AI features on Google Search, and that it includes impressions for AI Overviews and AI Mode. It lets you see which pages get the highest and lowest impressions in those features.

If the report is not there, the documentation gives three reasons. Not all properties have access yet because it is rolling out over time. Your site may not have received enough impressions in generative AI features. Or you may have excluded your site from Search generative AI features, in which case you would need to include it to be eligible for display. That third reason is worth checking before you conclude anything.

Read the report with its rules in mind. The pages dimension groups by the final URL linked after any redirects, and like the standard performance report, most data is assigned to the page's canonical URL rather than a duplicate. All dates are in Pacific Time. The newest data can be preliminary and still changing, shown as a dotted line on the graph, so do not react to yesterday.

What do you actually change when you refresh a post?

Change the substance before the surface. Add what you have learned since publishing, remove what turned out to be wrong, and replace anything that has gone stale. If the only changes are a new date and rearranged headings, you have not refreshed the post, you have edited its metadata.

My working order is to check factual accuracy first, because an old post confidently stating something no longer true is worse than no post. Then I look at what the piece is missing, which is usually the thing I know now and did not know then. Then, only then, do I touch structure, headings, and internal links.

The internal links are the part most people skip and they are among the cheapest wins available. An old post was written before your last two years of publishing existed, so it links to nothing recent and nothing recent links to it. Fixing that in both directions during a refresh costs ten minutes and compounds across the whole archive.

How do you know the refresh worked?

Set the measurement window before you publish the change, and make it long. Pick the exact page filter and the exact comparison period you will use, write them down, and do not look for at least four weeks. Deciding what counts as success after seeing the data is how teams talk themselves into believing anything worked.

Use average position as the primary metric rather than clicks for the first check. Position responds to content quality changes more directly, while clicks are also moving because of seasonality, competitor activity, and how the result is being displayed. If position improved and clicks did not, that is useful information rather than a failure, and it usually points at the title and description.

Be prepared for the refresh to do nothing at all on some pages. That happens, it is normal, and the honest interpretation is usually that the page is competing on an even footing and the tiebreak went elsewhere. A refresh that fails tells you the content was never the constraint, which is worth knowing before you refresh forty more.

How often should this run?

Monthly for the selection step, quarterly for the actual work. Building the comparison view and updating the queue takes minutes and is worth doing often. Rewriting posts properly takes real time and should be batched, because context switching between refresh work and new writing is expensive and both suffer.

I would cap it. Something like four refreshes a month is sustainable alongside new publishing, and it means a hundred post archive gets meaningful attention over a couple of years. Teams that decide to refresh everything usually refresh nine things enthusiastically and then stop, which is worse than a small number done repeatedly.

One thing to watch as this becomes routine is decay in AI citations specifically, which does not always move in step with classic rankings. I wrote separately about AI citation decay and content freshness, because a post can hold its position and quietly stop being quoted.

What should you do next?

Build the comparison view today. Open the Performance report, add a date comparison at monthly granularity, group by page, and sort by the difference in average position. That single view is the whole selection half of this workflow, and most sites have never looked at it.

Then take the worst three pages and check them against the substance test rather than the writing test. Ask what is factually stale, what is missing that you now know, and what should link here from the last two years of your own archive. If you can answer those three for a page, you have a refresh brief.

If your CMS is making any of this harder than it should be, that is a separate and fixable problem, and the schema side of it is covered in finding schema errors on a Webflow blog with Search Console. If you want help turning this into a workflow your team actually runs rather than a document nobody opens, reach out and let's chat.