The post that brings you the most traffic went up in 2021. It still ranks, it still converts, and it still says "as of 2021" in the second paragraph. The screenshots show a UI your product retired 3 redesigns ago. The headline statistic cites a study its own authors have updated twice since. None of this is unusual; HubSpot measured its own blog and found 76% of monthly views coming from posts published in earlier months. A healthy archive works exactly like that: the posts doing the most work are the oldest ones you have. And old is starting to show.
The work itself is not mysterious; it is a few hundred small judgment calls. Update the facts and dates, replace the dated references, tighten the intro, and leave the sections that earned the ranking exactly alone. WordPress gives you one place to do that, the editor, one post at a time; the built-in bulk edit changes authors and adds categories but cannot touch content. The fix has a different shape. Pull the archive out of the database into files, let your own AI agent find the rot and rewrite against your rules, then read every changed sentence as a diff before it goes anywhere near the live site. Two questions sort every route below: does it know what changed since 2021, and do you read the edit before your readers do.
Your options
A hand refresh, post by post
Open the post, reread it top to bottom, check every claim against what is true now, fix what aged, update. This is the gold standard, because a refresh is mostly judgment and the hand route is all judgment. WordPress backs it well, too: every update saves a revision, with a visual diff between versions and one-click restore. The wall is arithmetic. A careful pass over a 2,000-word post is an hour, and the teams that run refreshing as a program move at the pace that implies; HubSpot's historical optimization project updated 2 to 3 posts a week. At that rate a 300-post archive is a 2-year rotation. Most people refresh the top 10 and stop.
Your SEO plugin's stale-content flags
Some SEO plugins watch for decay: mark posts as cornerstone, and a filter shows which of them have gone 6 months without an update, with a count. As a standing reminder that decay exists, it works, and it is already installed. Three limits. It watches only the posts you flagged, not the archive. It reads the last-modified date, not the content, so it can say a post is old but not what inside it went stale. And the vendor's own advice for clearing the flag ends with saving the post, whether or not anything changed, so the metric measures saves, not freshness. The flag is a to-do list. The list was never the hard part.
A freelancer pass
Real judgment at a pace you can buy, and for a large archive it is often a sane call. The honest accounting has two lines beyond the invoice. First, refresh work has no standard rate; the published surveys price new posts, in the hundreds of dollars per 1,500 words, and agencies quote update passes case by case because the cost depends on what they find. Second, the things a freelancer cannot bring are the things this job is made of: what your pricing was in 2021 and is now, which features were retired, which sections rank and must not move. That knowledge becomes a brief, the brief becomes half the work, and the final read before anything goes live is still yours.
AI rewrite plugins
A category of WordPress plugins now does this job in place: pick the stale posts, send them to a model, write the result back. The better ones have the right instincts, a side-by-side view of old and new, a revision saved before the update, or changes held as drafts until you approve, and that deserves credit: it is review, inside wp-admin, one post at a time. Two things to weigh. The rewrite runs on the plugin's prompt, and a generic refresh prompt does not know that your pricing section is wrong and your methodology section is sacred. And the scheduled mode some offer, automatic weekly rewrites, is precisely the freshness-without-substance pattern Google's date guidance warns against.
Scratch
Scratch moves the archive instead of the editing. Posts, pages, and custom post types come down as files on your laptop, and your own agent works there with your brief. One grep finds every post that still says "as of 2021" or quotes the old price. A 10-line script ranks the archive by age and word count together, a sort the stock posts screen does not offer. Then the agent rereads each shortlisted post and refreshes it under your rules. Templates are excluded and post meta is hidden by default, so themes and plugin-owned SEO fields stay out of reach. Every changed sentence comes back as a word-level diff, only approved posts publish, and each one can be reverted afterward, per post. The trade is stated up front: the review is your own reading, on purpose, and a real refresh pass earns a long afternoon of it.
| Option | Whole archive | Knows your brief | Review before live | Undo after publish |
|---|---|---|---|---|
| Hand refresh | At 2 to 3 posts a week | Completely, it is you | You are the editor | WordPress revisions |
| Stale-content flags | Cornerstone posts only | No, it dates posts | Nothing changes | Nothing to undo |
| Freelancer pass | As budgeted | As briefed | If you reread every post | WordPress revisions |
| AI rewrite plugin | Yes | Its prompt, not your brief | Varies, post by post in wp-admin | A revision, when one was saved |
| Scratch | Yes | Yes, your agent, your rules | Every change, as a word-level diff | Per post, even after publish |
How the loop works on your archive
- Scratch pulls your archive into files. Posts, pages, and any custom post types come down to a folder on your laptop, one file each, with titles, slugs, excerpts, and taxonomies alongside the body. Templates and template parts are excluded, and post meta is hidden by default. Nothing on the live site has changed.
- Your AI triages, then refreshes. Point Claude, Codex, Cursor, or Copilot at the folder. The triage takes the agent a minute: grep every post mentioning the retired plan names, the old pricing, any "as of 20", then list the survivors by age and word count. Then the brief. Refresh the 60 posts in shortlist.md. Update facts, prices, and product references to match changes.md. Tighten any intro over 150 words. Do not touch headings, slugs, or the sections marked keep. changes.md is the change log you would have written for a freelancer anyway: the old price, the new price, the retired features. The agent does 99% of the work, file by file, and it holds no credential to your site. This part is fast because the files are local: grep crosses a 300-post archive in under a second, and the tenth question the agent asks costs the same as the first. Over the REST API, the same triage is a paginated crawl, 100 posts a page, one request at a time, before any judgment starts.
- You review every diff and publish. Each refreshed post sits next to its original, word by word, so the sections the agent was told to leave alone prove themselves untouched. Validators run first if you set them: a slug that must not move, a title that must keep its keyword. Approve what ships, and Scratch writes only those posts back over the REST API, at the API's own pace, one approved post at a time. The last 1%, deciding what your readers see, stays with you, and any published post can be reverted per post.
The loop is shorter to watch than to read. Here it is on a live WordPress site:
Which posts to refresh first
Refresh returns are concentrated. HubSpot's program found 92% of its monthly blog leads coming from old posts, which is why refreshing pays at all, and published refresh studies keep finding the same shape inside the wins: a handful of the refreshed posts produce most of the gain. Selection matters more than volume, and selection is what the local copy is good at. The agent crosses two lists in one pass: posts old enough to have decayed, and posts that still mention things you know changed, prices, plan names, dated years, retired features. Add what Search Console says still earns impressions, and a 300-post archive becomes a 40-post shortlist before any rewriting starts.
Questions people ask
Can AI update the facts without rewriting the parts that earned the ranking?
It can. The brief draws the line: which sections are sacred, which phrases must survive, what the new facts are. In the brief above, that line is the sections marked keep. Models follow briefs imperfectly, which is why the line is enforced twice, once in the prompt and once in the diff. A section the agent was told to leave alone shows up in review as exactly that, no changes. A section it touched anyway is one rejected diff, not a live regression a WordPress revision has to walk back.
Should I change the publish date when I update a post?
Sometimes. Google's guidance is specific: give a post a fresh date when it has been substantially changed, and do not artificially freshen a page without adding significant information. A real refresh, corrected facts, new sections, current references, earns the new date. The plugins that mass-update post dates without touching content are the exact tactic that guidance warns against.
Does refreshing old posts actually help SEO?
Often. Not always. The best-documented case is HubSpot's program, where updated posts averaged a 106% gain in organic search views. Recoveries of decayed posts after a refresh are well documented elsewhere too, and so is the pattern inside them: gains concentrate in a few posts, which is why selection matters more than volume. What nobody can promise is your number. Freshness helps where it is real and where the post still has demand to win back.
Will Google penalize content refreshed by AI?
No. Not for being AI. Google's published policy accepts AI assistance when the result is helpful, people-first content, and aims its spam policies at content generated primarily to manipulate ranking. A reviewed refresh that makes old posts true again is squarely the first kind. The version to avoid is the unreviewed loop the scheduled rewrite plugins run: automatic rewrites at scale with nobody reading the output.
Can I just run a database find and replace?
Partly. For exact strings, WP-CLI ships a search-replace command that swaps one string for another across the database, with a dry run that counts matches first. Two cautions. It writes to the database directly, outside the editor's save path, and the standard advice treats a backup taken beforehand as the only way back. And a refresh is mostly not exact strings; "tighten this intro" and "this stat aged out" have no search pattern.
Can I review every change before it goes live?
Yes. That is the design. WordPress revisions already show edits as a diff, but a revision is the change after it saved. Scratch shows the same word-level comparison before anything reaches the site: each refreshed post sits against its original until you approve it. The agent edits files on your laptop; it never holds a login to wp-admin.
Can I undo a refresh after it publishes?
Yes. Every published post is reversible from Scratch, per post. The original stays next to the refreshed version until you decide which one stands, so a refresh that read well in the diff and wrong on the live page is one revert away, not a database restore.
Will this touch my theme, templates, or SEO plugin fields?
No. Templates and template parts are excluded from edits, and post meta is hidden by default, so plugin-owned SEO fields stay out of an ordinary refresh pass. The editable surface is posts, pages, custom post types, taxonomies, and image alt text.
Do I need to be technical?
No. The grep, the ranking script, and the rewrites on this page are all the agent's work; the write-back is Scratch's, after you approve. Your side is judgment: which posts earn a refresh, what the brief protects, which diffs ship. When refreshing becomes a quarterly routine, you rerun the brief, not the setup.
See it on your own archive
The fastest way to trust it is to watch it run on your posts. See it run on your WordPress archive →, or download Scratch free and pull your 50 oldest posts this afternoon. Scratch is free to try, and the AI is whichever agent you already pay for.