Why We're Moving Our Clients Off WordPress

We still maintain dozens of WordPress sites. Here's the honest operator view from inside the stack — what changed, why we're migrating our own book of business to custom native sites, and how we do it without breaking anything.

The honest opening

I want to be upfront before I say anything else: we still manage 60 to 70 WordPress websites. We've supported some of those clients on WordPress for the better part of a decade. WordPress is not a bad platform, and the people running these sites are not making a mistake by being there. For a long stretch of the web, it was the right answer.

But I owe those same clients an honest read of where the web is going, and the honest read is this: the architecture that served them well for years is starting to cost them — in speed, in security exposure, and in something newer and harder to see, which is visibility inside AI-driven search. So we've started a slow, deliberate migration of our own book of business off WordPress and onto custom native sites. This is the operator-level explanation of why.

What actually changed (it isn't WordPress — it's the web)

Three things shifted in the last 18 months, and together they moved the goalposts for what a small or mid-market website needs to be.

AI answers replaced blue links. Google's AI now answers roughly half of all searches directly on the results page, and most of those searches end without a click. The sites that survive aren't the ones that rank #1 in the old blue links — they're the ones cited inside the AI answer itself. Getting cited requires clean, semantic, server-rendered HTML, accurate hand-built structured data, and content organized as direct answers. That's an architecture problem, not a plugin problem.

Performance thresholds got stricter. The median plugin-heavy WordPress site we manage sits at 3.8s LCP — well above Google's 2.5-second limit. Caching plugins help. They don't fix it. The cost isn't theoretical: slow sites lose AI citations, conversions, and ad efficiency simultaneously.

The security math got worse. In 2025 alone, 11,334 new WordPress vulnerabilities were disclosed — a 42% jump over the prior year — and 91% of them were in plugins and themes, not WordPress core. That's more than 250 disclosures per week, with mass exploitation beginning a median of five hours after disclosure. Across the fleet we manage, nearly every incident we've responded to in 24 months traced back to a plugin or theme. The core team does good work. The ecosystem around it is the problem — and the ecosystem is the reason people choose WordPress in the first place.

This isn't a WordPress problem. It's a stack problem. WordPress core in 2026 is more capable and better maintained than it has ever been. The friction is the plugin-and-theme model around it. Every plugin is code you didn't write, on an update cycle you don't control, with a security posture you can't audit. That model was fine when the web was slower. In an AI-search era that rewards architectural cleanliness, it's the bottleneck.

The data from inside our own client base

I'm going to keep this honest rather than dramatic. Here's what we actually see across the WordPress sites we still maintain:

• Median Largest Contentful Paint of 3.8 seconds — above the threshold AI Overviews favor when picking sources
• An average of 14 active plugins per site, with at least one plugin behind on updates at any given time on roughly a third of the fleet
• 30–45% of total page weight coming from CSS and JavaScript injected by plugins rather than the site's design
• Schema markup that's missing, partial, or contradicted by competing SEO plugins on a meaningful share of sites
• Monthly operational cost (hosting + premium licenses + maintenance hours) often higher than what a comparable custom native site costs to host outright

None of this means those sites are failing. It means the trajectory is wrong: every quarter, the gap between what these sites deliver and what the new web rewards gets wider.

What "custom native" actually means

Not a hand-coded HTML page from 2008. A modern, server-rendered React application built on a clean component architecture, with hand-built schema, first-party analytics, AI-readable content structure, and 100% code ownership delivered to the client.

Every build runs through Specloop, our proprietary spec system: requirements become a full engineering blueprint — product requirements, technical design, implementation plan — before a line of code is written, then the build executes against that spec with daily visibility through the client portal. No plugin marketplace. No monthly licensing for the basics. No third-party JavaScript loading before the page paints.

WordPress vs. custom native — our managed fleet vs. what we migrate to

Why we're doing the migrations ourselves

There's a version of this conversation where the agency that built your WordPress site quietly raises retainers, blames the platform, and keeps the lights on. We're not running that play. We've made the call to lead the migration ourselves — at a price clients can absorb, on a timeline that doesn't disrupt their business, with the new site fully owned by them at the end.

If we don't move them, someone else eventually will, and that handoff will be uglier than a planned migration we run while we still hold the institutional knowledge of every redirect, form, integration, and content quirk. Doing it now is the version with the least risk for the client.

The migration framework we use

Deliberately boring, because boring migrations don't break things:

1. Inventory — every page, URL, form, plugin-driven feature, and external integration
2. Redirect map — 1:1 mapping of old URLs to new, so zero SEO equity is lost at cutover
3. Content port — content moved into structured, AI-readable format with hand-built schema per page type
4. Functional parity — forms, search, integrations, and custom logic rebuilt as first-class features, not plugins
5. Staging review — page-by-page comparison against the live site before DNS is touched
6. Cutover + 30-day watch — traffic, indexation, Core Web Vitals, and AI citations monitored daily post-launch

The client experiences one weekend of careful coordination — then a permanently faster, safer, more visible site.

When WordPress is still the right answer

Not every site needs to move, and we tell clients so:

• A brochure site with low traffic, no growth ambitions, and no dependency on AI-search visibility
• An editorial workflow deeply tied to WordPress block patterns, where editor productivity outweighs performance gains
• A genuinely well-maintained site — lean on plugins, hand-tuned, already AI-readable (these exist; they're rare)
• A site inside a larger replatforming roadmap where migrating today would be wasted work

The point isn't to migrate everyone. It's to migrate the clients losing measurable ground — before that ground becomes a cliff.

What this means if you're on WordPress today

Don't panic, and don't fire up a rebuild on impulse. Look at three numbers: your Core Web Vitals (especially LCP), your organic traffic trend over 12 months, and how often you appear inside AI Overviews and ChatGPT/Perplexity answers for queries you should own.

If all three are healthy, you may not need to do anything for 12–18 months. If two of three are sliding, you're in the cohort we're prioritizing this year. We run the assessment free, for any site — ours or not — so you decide with real data instead of a sales pitch.

FAQ

Is WordPress dying?

No. It still powers about 42% of the web and remains a fine choice for low-stakes brochure sites. But its market share is declining for the first time since 2011, and the decline is concentrated among businesses that need performance, security, and AI-search visibility.

Will I lose my Google rankings if I migrate?

Not with a proper migration. Every URL is mapped and 301-redirected, schema is rebuilt by hand, and the new site is faster — which typically helps rankings. We monitor indexation daily for 30 days after cutover.

Can I still edit my own content without WordPress?

Yes. Builds that need self-service content get a content-editing capability scoped in the spec. You lose the WordPress admin; you keep the ability to update text, images, and posts.

What does a migration cost?

Site rebuilds start at $2,500 and take about a week. Complex sites and applications are quoted from the free assessment, so you're deciding with the facts in front of you.

What happens to my site during the migration?

Nothing. The existing site stays live untouched until launch day, then traffic cuts over via DNS. Zero downtime is the standard.

Why should I trust an agency that profits from migrations?

Fair question. Read the "when WordPress is still right" section above — we regularly tell clients to stay put, and the assessment is free precisely so the data makes the call, not us.