Refactoring fifteen years of blog taxonomy in one session

I have spent about fifteen years marketing Red Bridge as a WordPress agency, and the blog showed it. Twenty categories, fifty-five tags, posts going back to 2007. Magento, Joomla, osCommerce, and a catch-all bucket called Stream. Good history, but it had stopped matching the work. We are repositioning around applied AI now, and the taxonomy still read like 2011.

So we fixed it, in one working session. I sat with an agent, Claude Code wired to our WordPress through the REST API, and we took the whole taxonomy apart and put it back together. This is the write-up of how that went. If you want the unedited version, the full session is tucked at the bottom of this page.

Report first, edits later

The thing that made this work was the order. The agent did not start by changing anything. It started by reading. It pulled the live categories and tags from the API, read the new site to see where we are positioned, and sampled the posts in the categories whose names did not explain themselves. What exactly is "Stream"? Sixty-seven posts, 2007 to 2018, which turned out to be the old firehose from before we sorted the blog by topic. Then it wrote a report and a recommendation, and stopped.

That gave me something to react to instead of a pile of changes to undo. The calls stayed mine. Five posts in an "AI" category were early AI-generated experiments I was not proud of, so we agreed to pull them into a rewrite queue rather than let them seed the new flagship. The old Magento and Joomla posts stay published, for old times sake. Those are judgment calls, and the report surfaced them for a decision instead of guessing at them.

A dry run you can sign off on

Before a single write, the agent produced a change plan with the actual term IDs, the before-and-after category list for every post it would touch, the tags it would delete, and the redirects it would add. I read it, answered five open questions, and told it to go. If you have ever run a big taxonomy change by hand in wp-admin, you know the value of seeing the whole thing laid out first, reversibly, before it runs.

That plan is not a summary you take on faith. It is the whole list. Here is every post it moved, with where each one was and where it landed.

What it looks like now

Twenty categories became seven living ones plus a frozen archive for the dead-platform years. Fifty-five tags became four. Every category now carries a plain description, written to double as a record of what it holds. And every old URL redirects to its new home, so nothing breaks when we cut the domain over.

The parts that made it safe

None of this is magic, and it is not vibes. The agent is making real edits to a live database through an API, so the interesting engineering is in the guardrails, not the model.

Rollback first. Before any change, it saved a snapshot of the current categories and tags. Every deletion is re-creatable from that file.

It checked its own work. Before deleting a category it confirmed the category was actually empty. That check earned its keep: two old drafts were sitting in a category the first scan had missed, because that scan only looked at published posts. It caught them, moved them, then deleted the category. By hand, those two would have quietly gone with it.

The redirects were collision-checked. Two hundred eighty-four old post URLs, each checked against the real pages on the new site, so a redirect could never quietly take over /team or /projects.

And the honest friction. Cloudflare blocked the first API calls as a non-browser client until we sent a browser header. Then a rebuild briefly showed the old categories, because WordPress serves anonymous API reads from a cache that lags a few minutes behind edits. Neither is a disaster. Both are the kind of thing that only shows up when you run it end to end, which is exactly why the last step is to verify against the real build.

This is what AI for WordPress looks like

We still build and run WordPress for enterprise marketing teams. That has not changed. What is changing is how. The model did the tedious part here, a few hundred small edits I would never do by hand at that pace. But the model is the swappable piece. The method is the point: read first, plan in the open, keep a person on the decisions, leave a paper trail, verify against the real thing. When something better than today's model shows up, we swap it in and the method stands.

If you run a large WordPress site and the taxonomy, or the content, or the workflow around it has drifted from where your business actually is, that is the kind of work we do here in the Bay Area. Reach out. We are here for you.

The full session, start to finish

Here is the part I find most useful. Below is the actual session, synthesized close to verbatim: my prompts, the agent's thinking and actions, and the back and forth that got us from a vague "let's modernize the taxonomy" to a shipped change. It is long, so it is folded up. Open it if you want to see exactly how a session like this runs.