For most sites with a few years of published content, refreshing existing pages produces more traffic per hour of effort than publishing new ones. The page already has history, links and some authority; the work is improvement rather than creation.
It is also easy to do badly — changing the date and adding a paragraph achieves nothing.
Finding the right pages
Four groups are worth refreshing, in roughly this priority order.
Pages that ranked and declined. Compare the last 90 days against the same period a year earlier in search console. A page that was position four and is now position eleven has lost something specific and recoverable.
Pages stuck on page two. Positions 11 to 20 attract almost no clicks and are close enough that improvement is realistic. This is usually the highest-return group.
Pages ranking for queries they do not answer well. Look at the queries bringing impressions to a page and compare against what the page covers. Large impressions with a poor click-through rate often means the page is relevant but the content does not deliver.
Pages with links but poor performance. A page that attracted backlinks has value that is not being realised. Improving it capitalises on an asset you already own.
Pages not worth refreshing
Three categories to skip or remove instead.
Pages on topics with no remaining search demand — a tool that no longer exists, a regulation that was repealed. Check that the topic still has volume before investing.
Pages competing with your own better content. These need merging, not refreshing. See keyword cannibalisation.
Pages that never ranked and have no links. A page with no history is a new page; write it as one, or do not.
Diagnose before editing
Each cause of decline has a different fix, and guessing wastes the effort.
Competitors improved. Read the pages now ranking above you. If they cover the subject more completely, the fix is depth. This is the most common cause.
Intent shifted. The results for the query are now a different kind of page — listicles replaced by tools, informational replaced by commercial. The fix is format, not words.
Facts went stale. Old statistics, outdated screenshots, references to deprecated features. Readers notice, bounce, and the signals follow.
Technical. The page became slow, lost internal links, or was accidentally deindexed. Rule this out first, because it is cheap to check and the fix is different entirely.
Site-wide decline. If everything dropped at once, the page is not the problem.
What a real refresh involves
In rough order of impact.
- Cover what is missing. Compare against the top-ranking pages and identify the subtopics they address and you do not. This is usually where most of the gap is.
- Rewrite the introduction. It is the part most readers judge the page by, and it is usually the oldest-feeling part.
- Update every fact, figure and screenshot. Including the ones that are still roughly true but obviously dated.
- Improve the structure. Clearer headings, shorter paragraphs, a table or list where prose was doing badly.
- Add internal links both to and from the page. Pages decline partly because newer content stopped linking to them.
- Revisit the title and meta description against the queries actually bringing impressions.
- Remove what is no longer useful. Cutting is part of refreshing, and a page that only grows eventually becomes unreadable.
What not to change
Three things to leave alone unless there is a specific reason.
The URL. Changing it requires a redirect and loses a little value for no benefit. Only change it if the existing URL is genuinely misleading.
The core topic. Repurposing a page to target a different query usually fails, because the existing links and history relate to the old topic. Write a new page instead.
The publish date, without substantive change. Updating the date on an unchanged page is a transparent tactic that search engines handle poorly for you and readers notice. Change the date because the content changed.
Making it a programme
Refreshing works when it is scheduled rather than occasional. A workable rhythm for a small team is to refresh four to six pages a month alongside new publishing, chosen from a ranked list refreshed quarterly.
Keep a simple record: which pages were refreshed, when, what changed, and the before-and-after performance. Without it, you will refresh the same page twice and never learn which types of change worked.
Roughly a quarter to a third of content capacity spent on refreshing is a reasonable allocation for a site with a few years of archive. Sites with more history should spend more.
Measuring whether it worked
Record the baseline before you publish: average position, impressions, clicks and conversions for the page over the prior 90 days.
Then wait. Meaningful movement usually takes four to eight weeks after recrawling, and reading the result at two weeks produces false conclusions in both directions.
Judge on clicks and position for the target queries rather than on total traffic, which moves with seasonality. And accept that some refreshes do not work — the useful output of the programme is knowing which kinds of page respond, which comes only from tracking the misses as well as the hits.
A refresh worked through
An example makes the process concrete. A guide published three years ago ranked position three for its main term and now sits at twelve. Clicks are down by three quarters.
The diagnosis takes twenty minutes. The page loads fine and is indexed, so it is not technical. Site-wide traffic is stable, so it is not a general decline. Reading the three pages now ranking above it, all three cover two subtopics the original does not mention, and two of them include a comparison table where the original has prose. The original also cites figures from four years ago.
The refresh therefore has a specific scope: add the two missing subtopics properly, replace the prose comparison with a table, update every figure, rewrite the introduction, and add links from four newer articles that cover adjacent ground. Roughly a day of work.
What the refresh does not do: change the URL, change the target query, or add length for its own sake. Two of the original sections are cut because they are no longer relevant, and the page ends up only slightly longer than before.
Refreshing at scale
On a large archive, the limiting factor is deciding what to refresh rather than doing it. A scoring approach makes the queue manageable.
Score each page on three factors: potential traffic if it reached the top three for its main query, how far it currently sits from that, and how much work the gap looks like. Rank by potential divided by effort, and work down the list.
Recalculate quarterly. Pages move, competitors publish, and a queue built a year ago will have the wrong things at the top.
Refreshing within a wider review
Refreshing individual pages works best as part of a periodic review of everything published, because the decision to improve a page only makes sense alongside the decision to merge or remove others. A page worth refreshing in isolation may be better consolidated with two similar ones.
Running a content audit once a year and refreshing continuously between audits is the rhythm that keeps an archive healthy without either exercise becoming overwhelming.
Frequently asked questions
How often should content be refreshed?
Driven by the content rather than the calendar. Fast-moving topics may need annual updates; evergreen explanations can go several years. Let performance decline and factual staleness trigger the work.
Does changing the published date help rankings?
Only when the content genuinely changed. A date change alone is not a ranking signal and can harm trust if readers find stale content under a recent date.
Should a refreshed page be republished to the top of the blog?
It can be, and it gives the page fresh internal links and visibility. Use a separate “updated” date so readers can see both when it was written and when it was revised.
Is it better to refresh or write new content?
For a site with an existing archive, refreshing usually returns more per hour. New content is necessary for topics you have not covered, and the two should run in parallel rather than competing.
