Which Blog Posts to Update First (The Traffic-at-Stake Method)

The short version: update the posts losing the most traffic at stake first — the pages that were pulling real clicks and have started to slide — not the oldest posts or the ones with the scariest percentage drop. You find them in Google Search Console by comparing the last 3 months to the previous 3, then ranking every page by the clicks per month it's on track to lose.

That's the whole method. The rest of this is how to actually do it, and which pages to skip.

I run this on my own sites by hand, so everything below is the manual version — no tool required, just Search Console and about ten minutes.

How to decide which blog posts to update first

Most "content refresh" advice tells you to update old posts. It never tells you which ones — so people either refresh whatever they happen to remember writing, or they open a giant spreadsheet of every URL and burn out by row nine.

There's a better order. Rank pages by the clicks you're on track to lose, then work down from the top. Here's the five-step version:

1. Pull your pages from Search Console in compare mode — last 3 months vs the previous 3 months (steps with screenshots below).
2. Switch to the Pages tab and sort by the drop in clicks — biggest negative change at the top.
3. Estimate the monthly clicks at stake for each falling page using the formula in the next section.
4. Rank by that number, not by age or percentage. The page bleeding ~200 clicks a month goes to the top; the one bleeding ~8 goes to the bottom or off the list.
5. Start at the top and stop when the numbers get small. The top handful is almost always where the recoverable traffic lives.

Notice what's not in that list: how old the post is, how far it fell in percent, or whether you personally like it. Those are the things that usually decide what people refresh, and they're the reason so many refreshes land on the wrong page.

The one number that ranks every page: clicks at stake

Here's the number that does all the sorting:

Clicks/mo at stake = (baseline weekly clicks − recent weekly clicks) × 4.33

Take a page's average weekly clicks from its healthy baseline period, subtract its recent weekly clicks, and multiply the weekly gap by 4.33 (the number of weeks in a month). That's roughly how many clicks a month that one page is losing right now.

A worked example: a post averaged 60 clicks a week across the earlier period and is now down to 35 clicks a week. That's a gap of 25 clicks a week. Multiply by 4.33 and you get about 108 clicks a month at stake on that single page. A different post that fell from 8 clicks a week to 2 is down 75% — a much scarier percentage — but it's only ~26 clicks a month at stake. The first page is worth roughly four times as much of your afternoon.

That's the entire point of ranking by clicks at stake instead of percentage: a page losing 40% of a big number beats a page losing 80% of a small one. Sorting by clicks at stake surfaces the first kind and quietly ignores the second. Percentage-sorted "biggest decliners" reports do the opposite — they float tiny pages to the top and hide the ones actually costing you traffic.

This is an estimate, not a forecast. It assumes the recent dip holds, which is exactly the assumption worth acting on: a page that's been sliding for three months usually keeps sliding until you touch it.

Pull it from Search Console in about ten minutes

You don't need a paid tool for any of this. Everything you need is in the free Search Console you already have.

1. Open Search Console → Performance → Search results.
2. Click the date filter and choose the Compare tab. Pick Compare last 3 months to previous period. This is the setting most people never turn on, and it's the one that makes decay visible — you're now looking at change over time, not a single snapshot.
3. Click the Pages tab (under the chart, next to Queries). Each row is now one URL with its clicks for both periods and the difference between them.
4. Sort by the clicks difference so the biggest drops are at the top. Click the "Clicks Difference" column header; the pages with the largest negative change rise to the top. These are your decay candidates.
5. Export to a sheet (the export button, top right) and add one column: clicks_at_stake = (previous_period_clicks − recent_period_clicks) ÷ 13 × 4.33. Dividing the 3-month total by 13 gives you the weekly average; the formula above turns the gap into monthly clicks lost. Sort by that column, and you have your refresh queue in priority order.

The page at the top of that sorted list is the single best use of your next content hour. Not the oldest post. Not the one a competitor just beat you on that you happened to notice. The one quietly losing the most clicks.

One honest caveat while you're reading the list: a real drop and a seasonal dip look identical in a 3-month compare. If a page has obvious seasonality — tax content in spring, gift guides in December — compare it against the same months last year before you count it as decay.

Which pages to skip (and why chasing #1 backfires)

Ranking by clicks at stake tells you what to do. It's just as useful for what not to do. Three kinds of pages look urgent and usually aren't:

• Pages that never had traffic. A post stuck in single-digit clicks since the day it went live isn't decaying — it never ranked. That's a targeting or quality problem, and refreshing it rarely changes the outcome; Google's helpful content guidance is the better starting point for a page like that than any refresh checklist. It shows up nowhere on a clicks-at-stake list, which is correct.
• Big percentage drops on tiny pages. These dominate any decliners report sorted by percent and waste your best hours. A page that went from 10 clicks to 2 is down 80% and worth almost nothing.
• Your page-one, position-one winners. It's tempting to keep polishing the posts already at the top. But the click gap between position 1 and position 2 is smaller than the gap between position 5 and position 1 — the published CTR-by-position studies disagree wildly on the exact numbers, but they agree on the shape of that curve (roundup of the major datasets). So the pages just off the top of page one have far more headroom than the ones already there. Chasing a #1 you already hold is the lowest-leverage refresh you can do; recovering a former winner that slipped to position 6 is the highest.

There's a fourth kind worth knowing about, and it's the one that hurts: a page whose topic lost demand. It can sit high on a clicks-at-stake list and still be unfixable, because refreshing a page can't create searches. That's one of six reasons a post loses traffic, and it's the only one where the right answer is to leave the page alone.

Skipping well is half the method. Every hour you don't spend on a tiny page or an already-won page is an hour you get to spend on the page that's actually bleeding.

After you refresh: check that it worked

Picking the right page is step one; what to change once you're on it — and what to leave alone — is the next. The part almost nobody does is the last one: confirming the refresh actually recovered traffic instead of assuming it did. The honest way is to note the page's baseline before you touch it, wait four to eight weeks, and compare the same-length window after against the window before. If the clicks came back, you've got a repeatable playbook. If they didn't, you learned something before spending another afternoon the same way.

That verification step is a whole method in itself — here's how to tell if a content refresh actually worked, start to finish.

See your worst-decaying pages first

Doing this by hand once a month works, and I'd rather you understood the method than rented a tool you can't explain. If you'd sooner skip the compare-mode clicking and the spreadsheet column, that's the job RefreshRadar does: it runs exactly this clicks-at-stake method on your Search Console data every week and hands you the ranked list — each page with its clicks-at-stake number, the query it's losing ground on, and the likely reason in plain English. It isn't the only tool that reads Search Console for decay — here's how it compares with SEOTesting, including where theirs is the better buy.

Connect Search Console read-only and see what's decaying on your site — free — no card, about 30 seconds, and we never post or change anything. If nothing on your site is decaying, we'll tell you that instead.