A tutorial from two years ago has seen its organic traffic drop from 800 to 300 a month. Do you add two paragraphs of fresh data, or tear the whole thing down and rewrite it? Deciding by gut feeling usually ends the same way: effort spent, ranking unmoved.
My advice: don’t apply one rewrite frequency across the board. Group old posts by content half-life, act before the inflection point where traffic decays, and use a single metric — “traffic increment per work hour” — to decide between a light update and a full rewrite. With the same headcount, good scheduling can squeeze out 30–50% more organic traffic; blindly refreshing everything, on the other hand, crowds out capacity for new topics.
First, get the real cost of rewriting straight
Most teams only count writing hours, which makes rewriting look cheap. The real cost also includes topic re-check, review, re-creating images, re-arranging internal links, and the observation window after resubmitting for indexing. Factor all that in and a single rewrite’s investment usually runs 30% higher than estimated. Even easier to overlook is the opportunity cost: those 6 hours, spent on a new post, could have covered a batch of long-tail keywords nobody’s done yet.
I’d suggest adding three columns to your content ledger for every old post — estimated hours, last quarter’s organic traffic, and last 30 days’ traffic. With those three columns in place, pages that are “heavy investment, small plate” show up immediately. For the concrete refresh moves, follow the old post update checklist item by item so you’re not designing a process from scratch on every rewrite.
Figure: Content refresh frequency experiment — traffic dropped from 800 to 300? How often rewriting pays off (compiled by Operations GO)
| Cost item | How to estimate | Typical value |
|---|---|---|
| Writing hours | Target word count ÷ output per hour | 2000 words ÷ 500 = 4 hours |
| Review and images | Per post, including revisions | About 1.5 hours |
| Internal links and structure | Affected pages × 5 minutes | About 0.5 hours |
| Opportunity cost | New posts producible in the same window | About 0.5 posts |
Group old posts by content half-life
Different topics decay at wildly different speeds. You don’t need gut feeling to judge half-life: pull the page’s last 12 months of click data in the Search Console performance report and see how long it took to fall from peak to half — that’s its actual half-life. Pages sliding for three straight months with competitors updating more often are the fast-decay type.
- Fast decay (half-life within 6 months): industry news, version updates, pricing and policy — once the data goes stale, credibility goes with it.
- Medium decay (6–18 months): method tutorials, tool reviews, process guides — the framework still holds but screenshots and parameters get old.
- Evergreen (18 months+): concept explanations, beginner primers, principle breakdowns — refresh once a year with a new example.
After grouping, give each group a different re-check cadence: fast-decay every quarter, medium every six months, evergreen every year. Write the cadence into the content calendar with system reminders, not someone’s good memory. For how to balance evergreen against timely content, see the evergreen vs trending content piece.
Run one minimal controlled experiment to set your cadence
Instead of arguing over “how often to update”, run a two-month experiment and let your own data answer. The steps compress to five:
- Pick 10 old posts from the same category with similar baseline traffic, ideally all medium-decay.
- Randomly split into two groups: group A gets a light update (revise the intro, swap stale data, add two internal links); group B gets a full rewrite (keep the URL, rebuild structure and examples).
- Stagger the two groups’ publish times by 3–5 days so algorithm fluctuations don’t hit both at once and muddy the comparison.
- Record organic search clicks for 30 days before and 30 days after, excluding social and direct visits.
- Log each post’s actual time to the half hour.
Don’t touch the URL. Changing it severs external-link weight and historical data, and the experiment’s conclusion falls apart. If you really must change it, sort out the redirects first.
When reading results, don’t be fooled by the average
Looking only at “did it go up or not” almost guarantees a misjudgment. What you should actually look at is increment per work hour: if the light group captured 80% of the rewrite group’s effect in 30% of the time, the answer is clear — give budget priority to light updates, and reserve full rewrites for the few severely decayed pages.
Plot the results on a scatter chart with hours on the x-axis and 30-day click increment on the y-axis; pages in the lower right (lots of time, little gain) are the ones to cut from next round’s rewrite queue. This algorithm shares the same data caliber as content ROI, so you can reuse one ledger.
| Approach | Click increment | Average hours | Efficiency per hour |
|---|---|---|---|
| Light update | Medium | 1.5 hours | High |
| Full rewrite | High | 6 hours | Medium |
| Only change publish date | Near zero | 0.1 hours | Low |
| No action | Negative growth | 0 | — |
When these signals appear, don’t hesitate — rewrite directly
There are cases a light update can’t rescue, and the longer you delay, the bigger the loss. Write these signals as rules and pin them to the ledger; when one triggers, the post auto-enters the rewrite queue, no meeting required.
- All core data is stale: the body cites a report from two years ago or a tool version that’s been retired.
- Ranking fell off the page: it used to hold page one, now it’s past page two and hasn’t recovered for two months.
- Search intent drifted: page one for the same keyword is now all videos or tool pages, and your long-form article no longer fits.
- Structural flaw: the article covers three or four topics at once without going deep on any; splitting into a topic cluster would pay off more.
While rewriting, re-arrange the internal links so the new version keeps channeling weight to the pillar page — the specifics follow the topic-cluster internal-linking strategy.
Default quotas by team size
A solo-operated site and a ten-person content team can’t run the same rhythm. Small teams press the budget into light updates — 8 light and 1 rewrite per month, prioritizing keeping evergreen pages from slipping; medium and large teams can staff a quarterly rewrite queue auto-dispatched by the three rules of “stale data, ranking drop, intent drift”. Write the quota into the content calendar with system reminders, not anyone’s memory.
- Small team: rewrite quota no more than 2 per month; the rest go through light updates.
- Medium team: set up half-life grouping — fast-decay quarterly, evergreen yearly.
- Large team: wire the trigger rules into the ledger; a hit auto-enters the rewrite queue.
| Signal | Approach | Reason |
|---|---|---|
| All core data stale | Full rewrite | Old examples are dead; nothing left to patch |
| Ranking fell past page two | Full rewrite | Light updates can’t rescue the weight |
| Only parameters and screenshots old | Light update | Framework still holds; swap images and numbers |
When it comes to execution, the moves are concentrated: today export the last 12 months of click data and tag old posts as fast-decay, medium, or evergreen; this week pick 10 baseline-similar posts from the medium group and launch the controlled experiment with the five steps above; build a ledger that consistently records each post’s hours, clicks 30 days before and after, and approach; two months later compute the increment per work hour and use it to set your team’s rewrite quota — say 8 light and 2 rewrites per month; set “stale data, ranking drop, intent drift” as the three auto-trigger rewrite rules. Updating isn’t about doing more — it’s about putting the effort in right before the moment of decay.
