Every week I have a conversation with a prospective client or agency where the question comes up: “Do you use Elementor? What about Divi?” The honest answer is no — and it’s worth explaining why, because the reasons matter more than the preference.
This isn’t a polemic against page builders. They exist for good reasons and they’re the right tool in specific situations. But for the work I do — custom WordPress builds for agencies and regulated-sector clients — they create more problems than they solve. Here’s the full picture.
What page builders are and why they’re popular
Page builders like Elementor, Divi, WPBakery, and Beaver Builder sit on top of WordPress and let you build pages visually — dragging and dropping elements, adjusting layouts in a live preview, making changes without touching code.
The appeal is real. The barrier to entry is low. A designer with no PHP knowledge can prototype a layout in an afternoon. A client can update a hero headline without filing a support ticket. For smaller budgets and simpler sites, the value proposition makes sense.
The problem isn’t that page builders exist. The problem is what they produce under the hood — and what that means for performance, maintainability, and longevity.
The problems page builders create
Bloated output
A hand-coded WordPress theme generates lean, purposeful HTML. A page builder generates the same visual result with roughly ten times the markup — nested divs, inline styles, generated class names, and JavaScript that loads regardless of whether the page uses it.
This isn’t an exaggeration. Run a page builder page through a source view and compare it to a hand-coded equivalent. The difference is stark. Every element that could be expressed in two lines of clean HTML becomes twenty lines of builder output.
Performance drag
All that extra code has a cost. Page builder sites consistently underperform on Core Web Vitals — Google’s metrics for loading speed, interactivity, and visual stability. Largest Contentful Paint suffers because there’s more to load. Cumulative Layout Shift suffers because builders often defer rendering decisions to JavaScript. Total Blocking Time suffers because multiple builder scripts are executing on load.
This matters because Core Web Vitals are a ranking signal. A slower site doesn’t just frustrate users — it ranks lower.
Lock-in
This is the one clients rarely think about upfront. When a site is built with Elementor, the content — the actual text, images, and layout decisions — is stored in the database in Elementor’s proprietary format. If you ever want to move away from Elementor, you’re not migrating content. You’re rebuilding the site.
The plugin becomes load-bearing infrastructure. You can’t remove it. You can’t easily switch to another builder. You’re committed for the life of that site.
Unpredictable updates
Page builders are complex pieces of software with their own update cycles, their own compatibility requirements, and their own conflicts with other plugins. A WordPress core update, a PHP version bump, or an incompatible plugin can break a page builder site in ways that are difficult to diagnose and harder to fix — because the builder’s generated output doesn’t fail predictably.
Hand-coded themes fail in understandable ways. Page builder sites fail in ways that require reverse-engineering the builder’s own logic before you can fix the actual problem.
Code that can’t be handed off cleanly
If you’re an agency, this is the one that compounds over time. A hand-coded theme has readable, reasoned code that another developer can pick up and understand. Page builder output is machine-generated markup that no developer would write by hand — and no developer particularly wants to work with. When a client needs ongoing development work, or when an agency needs to bring in another resource, page builder code creates friction at every step.
What agencies specifically need to know
If you’re a marketing or digital agency using a freelancer or white-label developer, page builder sites create specific problems worth understanding before you commit.
White-labelling is harder. Page builder sites carry the builder’s fingerprints everywhere — in the source code, in the admin interface, in the database. Presenting an Elementor-built site as your own custom work is technically possible but uncomfortable, and a technical client will notice.
“Editable” sites often aren’t. One of the selling points of page builders is that clients can edit their own sites. In practice, a non-technical client editing a page builder layout frequently breaks it — reordering sections, accidentally deleting containers, introducing layout bugs that require a developer to fix. The editing experience that looked simple in the demo becomes a support liability in production.
You inherit the technical debt. When your agency takes over a site built by someone else on a page builder, you inherit their builder version, their plugin configuration, their workarounds, and their update debt. A site that hasn’t had its page builder updated in two years is a liability that someone has to deal with — and that someone is usually you.
What I build instead
The alternative to a page builder isn’t a frozen, inflexible site that requires a developer call for every text change. It’s a custom-built WordPress site with a proper content management layer — one that gives clients genuine control over the things they need to change, without exposing the things they shouldn’t touch.
Custom PHP/HTML/CSS themes built from scratch. No builder, no framework bloat, no generated markup. The theme outputs exactly what the design requires and nothing more. Another developer can read it, understand it, and work with it.
ACF (Advanced Custom Fields) for content management. ACF lets me build client-facing content blocks that are straightforward to use — text fields, image uploaders, repeaters, toggles — without giving clients access to the layout itself. The result is a site that’s genuinely easy to update for the people who need to update it, without the breakage risk of a visual editor. I’ve written a comprehensive guide to how I use ACF if you want to understand the approach in detail.
Semantic, structured HTML. Proper heading hierarchy, meaningful class names, accessible markup. The kind of code that Core Web Vitals reward, that screen readers can navigate, and that another developer would be happy to inherit.
No lock-in. The site works without any particular plugin being installed. Content is stored cleanly in the database. If the client ever needs to move, rebuild, or hand off the site, the process is straightforward.
The trade-off, stated honestly
Custom builds take longer to develop and cost more upfront. That’s a real trade-off and I’m not going to pretend otherwise.
A page builder site can be put together faster, especially at the prototyping stage. For clients with tight budgets or short timelines, that speed matters. The question is whether the upfront saving is worth the ongoing costs — in performance, maintenance, update management, and eventual technical debt.
In my experience, for any site that’s going to be maintained and developed over years, the custom build pays for itself relatively quickly. The page builder site accumulates costs — in developer hours spent debugging updates, in performance problems that need addressing, in the eventual rebuild that most page builder sites require after three or four years.
When page builders are actually the right choice
Being fair about this: there are situations where a page builder is genuinely appropriate.
A small brochure site for a local business with a limited budget and no plans for ongoing development. A temporary campaign landing page. An internal tool that only needs to exist for six months. A prototype that will be replaced by a proper build once funding is confirmed.
The problem isn’t page builders existing. It’s using them for complex, long-term, high-performance sites where the trade-offs compound over time — and where the client has been sold “editable and flexible” without a clear explanation of what that actually means in practice.
A note on the no-code trend
The broader no-code movement — of which page builders are a part — has made website creation genuinely accessible to more people, and that’s a good thing. Not every website needs a developer. Not every business can or should pay for custom development.
But there’s a difference between no-code tools that produce clean, portable output and no-code tools that produce tangled, proprietary markup that performs poorly and locks you in. That distinction gets lost in the marketing.
For agencies doing serious work — for clients in regulated sectors, for sites that need to perform, for builds that will be handed off and maintained over years — agency-grade work still needs code. Not because developers are precious about their craft, but because the alternative creates problems that eventually land back on the client, the agency, or both.
If you’re evaluating a WordPress build and want to understand what a custom approach looks like in practice, the work I do for agencies is a good place to start.
