WordPress vs. a Custom-Built Site: What We Learned Migrating Our Own

Most of what we publish here is general advice. This one is different — it's what actually happened when we moved our own website off WordPress.

Why we moved

Our old site was a fairly typical small-business WordPress build: a page builder theme, a handful of plugins, hosted on shared PHP hosting. It worked, but it had the usual WordPress-site problems that we spend a lot of our client conversations explaining to other business owners:

• Every plugin and theme update is a maintenance task, and every unpatched one is a potential security hole — the exact kind of unmanaged attack surface we warn clients about.
• A single-page layout with a handful of separate WordPress pages meant sections like About, Pricing and Contact were anchors on the homepage rather than real, indexable, linkable pages — fine for a very small brochure site, limiting for anything else.
• No visibility into real performance numbers — "the site feels a bit slow" isn't something you can act on without measuring it properly.

What we changed it to

We rebuilt the entire site as static HTML — Eleventy compiling plain HTML/CSS/JS pages, no WordPress, no PHP, no database, no plugins — deployed on Cloudflare Pages. Every page is a real, individually indexable URL now: dedicated Services, Pricing, About, Work, Insights and Contact pages, rather than homepage anchors.

What we actually measured

We didn't just assume the new version was faster — we ran Lighthouse and axe-core against every template before calling it done:

• Lighthouse: 99+ performance, 100 accessibility, 100 best practices, 100 SEO across every page template, with a Largest Contentful Paint around 1.8-2.0 seconds on a cold local build.
• Zero accessibility violations (WCAG 2.0/2.2 AA + best practices) across all 13 unique page templates, checked with axe-core — not just eyeballed.
• Zero known dependency vulnerabilities in the production build (npm audit), because there's no plugin ecosystem to keep patched in the first place.

None of that is a marketing number — it's the literal output of the same tools we'd point a client at if we audited their site.

What we'd tell a client in the same position

Not every business should do what we did. If you need a large content team publishing frequently, non-technical staff editing pages daily, or you're deep in a WordPress plugin ecosystem you rely on (memberships, complex e-commerce, a page builder your team already knows), a well-maintained WordPress site can still be the right call — the fix there is usually maintenance discipline, not a rebuild.

Where a static rebuild tends to make sense is closer to what our own site needed: a small number of pages, content that changes in bursts rather than daily, and a strong preference for the lowest possible attack surface and the fastest possible load time. If you're not sure which category your business falls into, that's exactly the kind of question we'd rather answer honestly on a free discovery call than assume.