Nobody in this story is real, which is the point. Picture a WordPress rebuild you've watched go sideways, then imagine you've seen a dozen more that went sideways in the exact same spots. That's what this is: a composite, stitched together from patterns we keep running into, not one company's diary. The numbers are typical ranges rather than anybody's actual invoice (so don't reverse-engineer your former employer out of them).
"It's staying on WordPress, so this one's easy." I have lost count of how many times I have heard that sentence at the start of a rebuild, said with the confidence of someone who thinks they have already done the hard part. And you know what? I get it. Same logo in the admin bar, same little dashboard, same familiar Posts and Pages. Feels like swapping the couch, not moving out.
What made me want to write this one down was a page I opened on a freshly rebuilt site: a big, beautiful, high-traffic landing page that now showed a wall of raw square-bracket gibberish where the layout used to be. Nothing had gone wrong with WordPress. WordPress was fine. The theme, the builder, the plugins, the URLs, the host, everything the content actually lived inside had changed, and the content noticed even if the CMS name did not. So let's walk through a composite of exactly where a WordPress-to-WordPress move goes sideways, because "same CMS" is the most expensive assumption in the room.
Context
Picture an established business on WordPress that had accumulated a decade of decisions: a heavy page-builder theme, forty-plus plugins, a couple of acquired microsites bolted on, and a sitemap nobody fully trusted. Nothing was “wrong” with WordPress — the goal was a ground-up rebuild on the block editor with a modern theme, a single consolidated install, and a faster host. Same CMS, new everything.
That “same CMS” framing is exactly what makes WordPress-to-WordPress replatforms go sideways. Teams skip the migration discipline they would apply to a cross-platform move, assuming content just carries over. It does not, because the thing being replaced — the theme, the builder, the URL structure, the plugin stack — is where the content actually lived.
What broke
Page-builder lock-in
The old site’s pages were built in a proprietary page builder that stored layouts as its own shortcodes and markup. On the new block theme, that markup rendered as raw shortcode text or empty boxes. There is no clean automatic conversion from one builder’s format to native blocks — the richest, most-visited pages had to be rebuilt, and that re-authoring was the biggest single task in the project.
URL changes on the restructure
Consolidating the microsites and cleaning up the information architecture changed permalinks across the site. WordPress does not redirect old URLs for you when structure changes, so without a complete 301 map the rebuild would have dropped rankings on content that was otherwise untouched — the most avoidable kind of traffic loss.
Plugin consolidation drops features
Cutting the plugin count from forty to a dozen was a goal, not an accident — but each removed plugin took its shortcodes and features with it. Pages that relied on a retired plugin’s shortcode broke silently. Every plugin being dropped needed a plan for the content that depended on it.
Media, domains, and SEO metadata
Moving hosts and consolidating installs changed media URLs and, in places, the domain. In-body image links and hardcoded absolute URLs broke where they were not rewritten. And the SEO plugin’s per-page titles and meta descriptions had to be carried across deliberately, or years of tuning would have reset to defaults.
What worked
The rebuild went well where the team treated it like a real migration. They ran a full content audit first and retired a surprising amount of thin and duplicate content instead of paying to rebuild it. They converted high-value pages to blocks by hand and accepted that as core work rather than hoping for a plugin to do it. They built the redirect map from a crawl of the live site before cutover, and they validated everything on a staging install that mirrored the new host before flipping DNS.
Lessons
- “Same CMS” is not “same content.” A theme, builder, and host change is a real replatform — apply migration discipline.
- Builder content does not convert cleanly. Budget to rebuild page-builder pages as blocks; there is no lossless shortcut.
- Any structure change needs redirects. Crawl the current URLs and map 301s before you restructure or consolidate.
- Dropping a plugin drops its content. For every retired plugin, plan for the shortcodes and features pages relied on.
- Carry SEO metadata across. Migrate titles and descriptions explicitly; do not let them reset to theme defaults.
Before you make this move
- Audit all content and retire the thin, stale, and duplicate before rebuilding anything.
- Inventory every page-builder layout and plan the block rebuild for the high-value ones.
- Crawl current URLs and build the 301 map for any permalink or domain change.
- List every plugin, mark which are being dropped, and plan for the content each supported.
- Export SEO titles and descriptions and migrate them; validate on a staging install that mirrors the new host.
So here's what I actually think, plainly: a WordPress-to-WordPress rebuild is a full replatform wearing a familiar name tag, and you should treat it with every ounce of the discipline you would give a jump to a whole new platform. Audit the content before you rebuild a single page. Rebuild the builder pages by hand and put it in the budget, because there is no lossless shortcut and pretending otherwise just moves the pain to launch day. Crawl your URLs and map the 301s. For every plugin you drop, know what content goes with it. Carry your titles and descriptions across on purpose. None of this is glamorous, and all of it is cheaper on a Tuesday in a spreadsheet than it is when the traffic graph is falling.
Because that page full of square-bracket gibberish was not a WordPress problem. It was a someone-assumed-it-was-easy problem, and those you can find early. Go look at your richest pages the way a visitor would, before anyone says the words "it's staying on WordPress, so this one's easy." Replatform Radar inventories your pages, redirects, plugins, and the signals that tell machines what your site is about, so the rebuild ships without quietly dropping the stuff that already worked.