This site has 17 posts going back to 2021, most of them stale in one way or another. I’ve been meaning to clean it up forever and never did, mostly because “go read every old post and check if the commands still work” is exactly the kind of task I’ll put off indefinitely. So instead I hooked Claude up to the site via an MCP-enabling WordPress plugin and had it do the pass. Here’s what that actually looked like.
What the connector exposes
The plugin wraps the WP REST API as a set of MCP tools: create/read/update posts and pages, media uploads, categories and tags, users, comments, custom post types, block templates, the works. A few things about it were worth noting up front:
- New posts default to draft status unless you explicitly ask for publish (and the plugin has a setting to force draft regardless, ignoring the model).
- Every write goes through an audit log with before/after diffs, queryable by tool, user, or date range.
- There’s a search-and-replace tool that edits one field of a post without resending the whole thing, which matters once posts have any real length to them.
None of that is exotic, but it’s the difference between “AI with a REST API key” and something I was actually comfortable pointing at a live site.
The first pass: just look at everything
First thing was just inventory: list every post regardless of status, sort by last modified, get a feel for what’s actually here. That surfaced the two abandoned drafts, the real publish/draft counts, and one post with a modified date of today that I hadn’t touched. More on that below.
Before touching anything live, I had it walk me through what “update the outdated ones” would actually mean in practice, and we settled on: publish updates as it goes, flag anything major instead of quietly deciding on its own, batch a few posts per pass instead of one at a time. That took about thirty seconds and saved a bunch of back and forth later.
The bug hunting was the actually useful part
I expected this to mostly be “note that Ubuntu 20.04 is EOL” busywork. Some of it was. But going through post by post also turned up things a simple find-and-replace never would have:
- A post titled “ext4 partition resize” that actually used
xfs_growfs, an XFS-only command, in the example. Wrong filesystem entirely.
- A typo in a Perl JSON example (
Dumepr instead of Dumper) that would have just thrown an error for anyone who copy-pasted it.
- An InfluxDB install post pinned to a repo path and package name that don’t exist anymore — InfluxDB’s on 3.x now, not 1.x.
- A Netplan example using
gateway4, which still works but is deprecated in favor of a routes: block.
Then there was the image problem. A couple of posts had images pointing at an internal IP address that obviously doesn’t resolve from the outside — that one was a clear miss on the initial pass, since it was flagged but not fixed. When I asked to go fix it, checking the media library against what was actually in the post content turned up more of the same pattern in another post that had looked fine at a glance: right domain, wrong protocol (http instead of https), on three separate images. That one hadn’t tripped any obvious “this looks broken” signal on the first read-through. It only showed up because the correction pass checked the actual media library records against what the posts referenced, instead of trusting the URLs looked plausible.
The mystery edit
One post showed a modified timestamp from minutes before the session even started. Instead of guessing, the audit log answered it directly: same OAuth client, a wp_update_post call, timestamped two minutes before the first tool call in this conversation. Almost certainly a separate session on my end, not a mystery. Being able to just check that instead of speculating about it is exactly the kind of thing the audit trail is for.
Where I still drew a line
Not everything got auto-corrected. The two genuinely stale drafts (a Wireguard setup and a Radarr install guide, both built around dependency situations that don’t exist anymore) needed real rewrites, not patches, so those got flagged and reworked from scratch rather than papered over. And a couple of posts got an editor’s note added rather than a rewrite, because I’d rather flag “this external tool has a history of going down” than assert something I can’t fully verify.
Net result: a handful of real bugs fixed, several posts with honest editor’s notes instead of silently stale info, and a repeatable process for the next time this backlog builds up. Given this site is mostly an excuse to tinker with self-hosting and automation in the first place, that last part is the actual point.
