Follow-up to my 60k phpBB migration: I used the same site to stress-test WordPress MCP

Three months ago I posted about migrating 60,000 phpBB topics and 180,000 comments into WordPress with raw SQL. After that I got curious about MCP, but testing it on a clean install with 20 posts seemed pointless. Everything behaves nicely when there's nothing to break. I wanted to poke a big anthill with a stick and see what happened.

So I went back to that same site: tens of thousands of migrated posts, old forum taxonomy, years of metadata, comments, redirects, and a few leftovers from the phpBB conversion. Perfect anthill.

I connected Novamira to Codex as a remote MCP server and started with read-only checks before allowing writes.

First tests and actual useful work

Started read-only: WP/PHP/MySQL versions, active plugins, posts, settings, site structure. Confirmed, that it was actually reading live data, not just returning a green light.

I also tested AIOSEO MCP separately while Novamira stayed my general WordPress connection.

Real write test: changed the site title through the AIOSEO API, verified it landed, verified nothing else shifted. Then a safe round trip on one post, changed the SEO description, read it back, restored the original.

From there I used MCP more as a diagnostic tool: robots.txt, sitemap settings, stale social titles, an incorrect BreadcrumbList, invalid dates leaking into the sitemap index, and a lot of old posts with no focus keyphrase.

Codex wrote a tiny site-specific plugin to fix the BreadcrumbList and sitemap dates, and I kept it in mu-plugins so the fixes always load. That plugin was separate from Novamira.

Then Codex built itself a local copy of the site

Pulling tens of thousands of posts through WordPress on every pass stopped making sense.

I exported the site as XML and Codex built a local SQLite mirror from that: about 9 GB, 52,837 published posts, plus taxonomy and metadata.

That changed the workflow. Codex could query the site as data: inspect structure, sample posts, test classifications, find duplicates, pick rewrite candidates, build internal-linking plans, all without touching WordPress.

And the database stays there for whatever comes next.

Codex does the messy thinking locally. MCP does the WordPress work.

Rebuilding the old forum structure

Tens of thousands of posts sitting in old forum-style taxonomy isn't something you hand to an agent to sort live while it's simultaneously writing to WordPress.

Using the local mirror, we tested classification on about 2,000 posts, iterated the taxonomy a couple of times, then generated the full reassignment plan offline.

Only the finished plan got pushed through Novamira to staging. The agent wasn't deciding placement live, it was executing a plan that had already been checked.

Afterward I verified category counts, old vs new categories, spot-checked posts, URLs, content, authors, and comments.

Where things actually started breaking

Next up: dropping categories from the URL structure and switching permalinks to /%postname%/.

Some malformed slugs had slipped through during the original phpBB migration. They were less obvious while category names were still part of the URLs, but once the category path disappeared every slug had to stand on its own.

Codex checked the archive locally for bad characters, empty slugs, and duplicates that could collide once the category path was gone. Then we started applying the cleanup.

At around 500 records per batch, Hostinge.r started throwing 503 and 504 errors.

The interesting problem wasn't the timeout. A failed batch didn't tell me whether it had written nothing, half, or almost everything. Resending it blind wasn't safe.

After one failed large batch, 454 records still needed reconciling. Codex recalculated the current DB state first, then resumed with batches of 50, dropping to 20 when Hostinger stayed flaky.

That worked.

Final check across the archive: 0 empty, non-normalized, or duplicate slugs. Switched permalinks to /%postname%/ and did one soft rewrite flush.

At this scale, the first real limit I hit wasn't MCP. It was cheap shared hosting choking on batch size.

Second site

I also connected Novamira to another WordPress site this month. Same basic setup, same read-only baseline.

The second time was much less dramatic. First time you're fighting JSON and endpoints, second time it's mostly config.

What's still broken

New post creation mostly works, the post gets created, but the featured image doesn't attach.

Haven't isolated yet whether it's the upload step, attachment step, or specific ability.

That's next: media upload, featured image, SEO metadata, and verification, all in one reliable publish flow.

Ideally the same pipeline should generate the featured image and metadata too, instead of me adding them manually afterward.

I still wouldn't run the riskier parts of this directly against production. Staging and backups are cheap compared with finding out what an agent just did to 60,000 posts.