Homepage Mistakes Costing Small Businesses Leads
A practical homepage teardown for small business websites: the mistakes we see most often, why they matter, and what to fix first.
Read articleYou commissioned a website. You paid for it. The invoice said "web design and development" and you got something that looked good in the browser. Then, a year or two later, you decide to switch agencies — and that's when things get complicated.
This post is about what actually happens when a website is built on a page builder, what you own (and don't own) when you pay for it, and why the performance problems that seem to appear out of nowhere are usually baked in from day one.
What is a page builder, and why does it matter?
Elementor, Divi, WPBakery, Beaver Builder, Wix, Squarespace — these are all tools that let designers build websites visually, by dragging and dropping components onto a canvas. They're fast to use, require minimal coding knowledge, and produce sites that photograph well in a browser screenshot.
The problem isn't the visual output. The problem is what's underneath it.
Page builders generate code. A lot of it. Elementor, for example, wraps every element in multiple nested divs, loads its own JavaScript framework, and registers dozens of CSS stylesheets on every page load — regardless of whether those stylesheets are used on that specific page. A simple homepage built in Elementor can load 600–900KB of CSS and JavaScript before a single image is counted. A site built by a developer writing clean, purposeful code for the same design might load 40–80KB.
That difference shows up in your Core Web Vitals, your Google rankings, and the experience your visitors have on mobile.
The vendor lock-in problem
Here's where it gets painful. Page builder content — your layouts, your sections, your text — isn't stored as standard HTML or CSS. It's stored as serialised data inside your database, tied to that specific plugin. If Elementor is removed, or if the plugin is abandoned, or if you move to a different CMS, your content doesn't come with you.
This means:
- You can't just hand your site over to a new agency. Any agency that doesn't work with the same page builder will have to rebuild your pages from scratch — because the content isn't in a portable format.
- Plugin updates break layouts. Elementor has a track record of major version updates that introduce visual regressions. If your agency isn't maintaining the site, a routine plugin update can silently break sections across your site. You often won't notice until a customer mentions it.
- Plugin abandonment is real. The WordPress plugin ecosystem is littered with abandoned tools that once powered popular websites. When a plugin stops receiving security updates, you're faced with a choice: stay on an insecure version, or remove the plugin and lose your layouts.
What happens when the agency disappears?
Small agencies close. Freelancers move on. What happens to your website?
If your site was built with a page builder and the agency used a premium licence key to activate it, that licence is tied to their account. When they disappear, the plugin may stop receiving updates — or in some cases, stop working entirely if it requires a licence check to function.
Beyond the licence issue, there's the knowledge problem. Page builder sites are often built with no documentation, no design system, no style guide. The visual logic of the site exists only in the page builder's database. A new developer inheriting the project has to reverse-engineer every layout to understand how it works — and making changes without breaking something is genuinely difficult.
The performance debt
Performance problems on page builder sites tend to compound over time. Every new plugin added to solve a specific problem — contact forms, popups, cookie banners, SEO tools, social feeds — adds more JavaScript, more CSS, and more database queries to every page load.
After two or three years, a site that started at a respectable 3-second load time might be sitting at 6–8 seconds. The CSS payload is enormous. There are JavaScript conflicts between plugins causing console errors. Half the installed plugins haven't been updated in 18 months. The database has thousands of rows of orphaned post meta from plugins that were installed and removed.
The instinct is to throw a caching plugin at it. Sometimes this helps. Often it papers over the problem without solving it.
What "owning your website" actually means
You should be able to hand your website files and database to any competent developer, and they should be able to understand, maintain, and extend it without specialist knowledge of a particular drag-and-drop tool.
That's what custom development delivers. Your content is in standard database tables or files. Your templates are PHP, HTML, and CSS that any developer can read. Your design system is documented. There's no plugin dependency managing your layout. If you switch agencies tomorrow, the new team can pick up where the last one left off.
Custom-built sites are also built for the performance profile of your specific content — not for the performance profile of every possible thing a page builder might ever need to render. The CSS covers your design. The JavaScript does your interactions. Nothing else is loaded.
If you're reading this because you're already in the page builder trap — slow site, confusing codebase, worried about what happens next — we can help. Get in touch and we'll take an honest look at your situation. If you want to understand what a custom build might look like for your business, reach out and we’ll talk it through properly.