Two SEO Plugins and Two Page Builders: When to Fix a WordPress Site Instead of Rebuilding It

A while ago I looked at the infrastructure behind a North American medical aesthetics training center. I was leading R&D there, redesigning the landing pages, and I wanted to understand where the old designs were failing before I replaced them.

What I found was a site carrying years of accumulated decisions, each one sensible on the day it was made.

I recommended rebuilding the front end. They didn't do it. They're still on the same stack today, and the site is still slow.

That outcome is the reason I'm writing this rather than a post about migration wins. The interesting question isn't "what was broken." It's why a business with the budget and the motivation to fix it still didn't.

What Was Actually Installed

From memory, the parts that mattered:

• Two SEO plugins running simultaneously — Yoast and Rank Math.
• Two page builders running simultaneously — WPBakery and Elementor.
• LearnDash for the courses, WooCommerce for payments, Zapier wiring things together.
• A separate plugin handling user roles and course access, layered on top of the LMS.

The two SEO plugins are the one that makes people wince, so start there. Yoast and Rank Math both want to write your title tag, your meta description, your canonical, your Open Graph tags, and your sitemap. Running them together doesn't give you two opinions — it gives you a race. Whichever one hooks later wins, per tag, and the losing plugin's settings sit in an admin panel showing you a green light for something that never reaches the page.

That's worse than having no SEO plugin at all. With none, you know you have a problem. With two, you have a dashboard telling you you're fine.

The two page builders are the more interesting one, and I'll come back to them, because they aren't carelessness. They're a rational response to a real constraint.

The Analytics We Turned Off

I needed behavioural data. I was rebuilding landing pages and I wanted to see where people got stuck on the old ones before I guessed at new ones.

Our tech lead told me we had Microsoft Clarity installed. I got access, went through the session recordings, and got what I needed.

Some time later I went back in and something was off — no new sessions. The data just stopped.

I asked the tech lead. Clarity had been deactivated, weeks earlier. It was making the site heavier and slower, and the tech team turned it off. Reasonable decision from where they sat: they owned uptime and page speed, Clarity was measurably hurting both, so it went.

All told it ran for about a month.

Nobody did anything wrong here, and that's what makes it worth telling. The team that owned performance made a defensible performance decision. The person who needed the behavioural data — me — found out by noticing the graph had stopped moving. There was no process connecting those two facts.

That's what infrastructure debt actually looks like day to day. Not a dramatic outage. A slow trade of your ability to see the problem in exchange for the site staying up.

If you're running a clinic or a course business: go check right now whether any analytics or session-recording tool on your site has been disabled for performance reasons. If one has, that's the finding. Everything downstream of it is being decided blind.

Pages Nobody Could Delete

Multiple teams published, cloned, and abandoned pages over the years. Nothing in the setup stopped an abandoned page from staying publicly live, and dozens of them were — with pricing that no longer existed and courses that no longer ran.

We asked people to use noindex or keep drafts in draft. That fails every time, and not because anyone is careless. A manual step with no enforcement is a wish, not a process.

Google indexed those pages. Prospective students landed on prices we didn't charge anymore.

Why the Rebuild Never Happened

Here's the part I'd have skipped two years ago.

Toward the end of my time there, the team started building new pages in Elementor. Not migrating — building new ones. The old WPBakery pages stayed exactly where they were.

Why? Because the old pages were ranking.

Years of SEO work sat in those WPBakery pages. Rebuilding them meant risking positions that were actively producing enrolments, on a site with a large user base, to fix a problem that was annoying rather than fatal. So the decision was: new pages in Elementor, old ranking pages left alone. A handful got renewed, and their WPBakery versions were set to private. The rest stayed.

Which is how you end up with two page builders. Not through negligence — through a completely rational refusal to gamble revenue on a cleanup.

They chose to go slow and incremental. I don't know how far they got. I do know they never moved to a headless architecture, and haven't to this day.

And I've stopped thinking they were simply wrong.

The pitch I was making — rebuild the front end, get pre-rendered pages, put indexing rules in code, get real deploys — solves every problem I described above. It's still what I'd build from scratch. But "this architecture is better" and "migrating to it is the right move for you this quarter" are different claims, and I was making the first one while answering the second.

For a business with an established page carrying real traffic, the honest cost of a rebuild includes the ranking risk, the retraining, the parallel-running period, and the months where nothing improves. If nobody prices those in, the recommendation isn't a plan. It's an opinion.

What I'd Do Now, In Order

If I walked into the same situation today, I wouldn't lead with the rebuild. I'd do this:

1. Delete the duplicate SEO plugin this week. Pick one, export its settings, deactivate the other. Zero ranking risk, immediately fixes conflicting tags. This is a one-hour job with no downside and it should never wait for a strategy.
2. Audit every live page for stale pricing. Search your own site for old prices and count what comes back. Then decide, page by page: update, redirect, or remove.
3. Turn the analytics back on and fix the reason it was heavy — usually lazy-loading the script, not removing the tool. You cannot prioritise anything else honestly while you're blind.
4. Freeze new page builders. One builder for everything new. You're not migrating the old pages yet; you're stopping the split from getting wider.
5. Only then talk about architecture — and only for the pages that aren't carrying ranking equity. New sections, new funnels, new landing pages. Prove the stack on something that can't lose you money, then let the migration case make itself.

Steps 1 through 4 don't require a developer's roadmap or a budget approval. They're most of the value, and they're the ones I under-sold because a rebuild is a more exciting thing to propose.

The Point

WordPress wasn't the villain in this story. I build on WordPress — I'm building a course platform on it right now, WordPress with WooCommerce and Tutor LMS, and I picked that stack on purpose over the exact architecture I just described.

What broke here wasn't the CMS. It was that nobody owned the boundary between "install a plugin to solve today's problem" and "the sum of those installs is now our architecture." A disciplined WordPress build — one SEO plugin, one page builder, someone responsible for what stays indexed — produces none of the failures above.

So the first question isn't which platform. It's who decides what gets installed, and who decides what stays live? If the answer is "nobody in particular," a new stack will be in the same state in eighteen months, and you'll have paid for the privilege.