Content refresh: which old posts to update first

A content refresh strategy decides which old posts to update by two numbers from Google Search Console: the clicks a page lost comparing the last 3 months with the 3 months before, and the queries where a page already sits at average positions 4 to 20. Refresh the pages that score on both first, then either one, and count as an update only a change to the substance: new facts, new sections, corrected claims.

Below is the exact Search Console setup for each list, a way to rank them, what a refresh must change, and how to handle dates, lastmod and measurement afterwards.

How do you find the posts that lost clicks?

Open the Performance report in Search Console, set the date filter to compare the last 3 months with the previous period, and switch the table to Pages. Search Console adds a difference column for each metric, so sorting by the clicks difference puts the biggest losers at the top.

Step by step:

1. In Search Console, open Performance, then Search results.
2. Click the Date filter, choose Compare, and pick the last 3 months against the previous period. Search Console's help gives "this week versus last week" as one example of a date comparison; any two periods work the same way.
3. Turn on Clicks, Impressions, CTR and Average position above the chart.
4. Open the Pages tab under the chart.
5. Sort by the clicks difference, largest loss first.
6. Export the table so you can work through it.

Search Console's help recommends Weekly or Monthly granularity when comparing date ranges, because it "neutralizes the day-of-the-week effect." Seasonal businesses should also run the same comparison year over year, since a Christmas guide losing clicks in February is normal and not a refresh signal.

Filter out pages you would never refresh, such as tag archives or thank-you pages, with a URL filter: choose Pages, then URLs not containing, and enter /tag/. Keep the list to posts that exist to answer a question.

How do you find striking-distance queries?

Striking-distance queries are the searches where a page already ranks on page one or two but below the top three: average positions 4 to 20. Find them per page in the Performance report by clicking a page to filter the report to it, then opening the Queries tab with Average position turned on.

For each post on your loss list, and then for your other important posts:

1. In the Pages tab, click the post's URL. Search Console filters the whole report to that page.
2. Switch to the Queries tab.
3. Sort by Impressions.
4. Note every query with an average position between 4 and 20 and meaningful impressions.

Read the position carefully. Search Console's help defines average position as "the average position of the topmost result from your site," so a page that sometimes ranks 3 and sometimes 12 shows a blended number. Queries with few impressions produce noisy averages; weigh the ones with the most impressions first.

These queries tell you what to add. A post that ranks 9 for a question it only half answers needs that answer written in. The striking-distance keywords guide covers this list in more depth.

How do you rank posts for a refresh?

Put both lists together and sort posts into four groups. Posts that lost clicks and still have striking-distance queries come first, because the demand is proven and the page is close. Then posts with many striking-distance impressions, then posts that lost clicks for other reasons, and last, posts that are steady.

Within each group, sort by clicks lost, then by impressions at positions 4 to 20. That ordering puts the largest known demand first without needing any number Search Console does not give you. Work through five to ten posts at a time, then measure before doing more.

Why did a page lose clicks?

Before rewriting, find which metric moved. Clicks fall when impressions fall, when position falls, or when click-through rate falls at the same position. Each points to a different fix, and rewriting a page that lost clicks to seasonality wastes the effort.

The alternating-URL case needs its own fix: merge the pages or make each one distinct, rather than refreshing both. The keyword cannibalization guide walks through it.

What counts as a real update?

A real update changes what the page tells the reader. Add facts that are new since publication, add sections that answer the striking-distance queries, correct claims that are no longer true, and remove advice that has gone stale. Changing the date, swapping synonyms or padding the word count does not count.

Google's guidance is specific here. Its list of warning signs for "search engine-first" content includes "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" and "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)." It also asks whether you are "writing to a particular word count," and answers: "No, we don't" have a preferred one. The guide to thin content and word count covers that myth.

A refresh checklist that stays on the right side:

1. Re-verify every number, price, limit and screenshot against its source, and replace what changed.
2. Add an answer for each striking-distance query the page does not yet answer, under a heading phrased as that query.
3. Rewrite the first two sentences so they answer the page's main query directly.
4. Remove or correct anything no longer true; say plainly what changed if readers relied on it.
5. Add internal links from the refreshed page to newer posts, and from newer posts back to it.
6. Keep the URL. A refreshed page keeps its links and history; a new URL starts from nothing.

How should dates and lastmod change after a refresh?

Show the original published date and add an "Updated" date only when the content really changed, and make the structured data match. Google's byline date guidance asks for datePublished and dateModified that "match between the equivalent user-visible and structured values." Update the sitemap's lastmod at the same time.

Google's sitemap documentation says it uses <lastmod> "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate," and that the value should reflect "the last significant update to the page." It counts "an update to the main content, the structured data, or links on the page" as significant, and says "an update to the copyright date is not." A CMS that bumps lastmod on every save teaches Google to ignore the field for your whole site.

The guide to updating a blog post's date shows the visible and structured markup for both dates.

How do you measure whether a refresh worked?

Record the date of each refresh, wait for Google to recrawl the page, then compare the same length of time before and after in the Performance report, filtered to that page. Look at clicks first, then at the striking-distance queries you targeted, to see whether their positions moved.

After publishing the update, inspect the URL in Search Console and click Request indexing. Google says crawling "can take anywhere from a few days to a few weeks," and that requesting a recrawl more than once "won't get it crawled any faster," so ask once. Give a refreshed page at least four weeks before judging it, and compare with Weekly granularity to smooth out day-of-week swings.

Keep a simple log: URL, refresh date, what changed, and clicks for the four weeks before and after. After a few rounds it tells you which kind of change moves rankings on your site.

Have new articles planned from the same Search Console data

The data that tells you which posts to refresh also tells you which articles you have not written yet. LaunchScaler's content engine plans a month of articles led by your own Search Console queries, "the searches you already rank for just off page one," with your readiness audit and real keyword data filling in the rest. It writes one a day, thirty a month, in your voice, and by default every draft waits in your workspace for you to rewrite, trim or scrap before it publishes to WordPress, Webflow, Ghost, Shopify, Notion, Medium or a signed webhook.

It costs $99/mo per website, with 3 days free before the first charge. Start the engine and the first article arrives on day one.