A slow, bloated, poorly structured site and a fast, clean, well-built one can look identical on the surface. Both have a homepage, a services page, a contact form, and a logo. The difference is entirely in what is underneath — and most business owners have no way to evaluate that without technical knowledge they were never expected to have.
I have a client whose website I built somewhere between ten and twelve years ago. Clean HTML, hand-coded CSS, nothing on it that did not need to be there. By every modern measure — PageSpeed, crawlability, AI readability, security — it outperforms most sites built last year. That is not nostalgia. That is architecture. The fundamentals of clean, well-structured code never expired. What changed is what the industry started selling instead.
Use the fact-check buttons at the bottom of this article for an independent AI review. The technical claims here are grounded in documented standards — verify them directly.
What I Recommend
Static HTML
A static HTML site is the cleanest possible foundation for a modern website. No database queries. No CMS overhead. No plugin ecosystem to maintain. The page that gets served to a visitor is the same page that gets served to a crawler — human or AI — because there is nothing dynamic generating it at runtime.
Speed is the default, not the achievement. Core Web Vitals scores that a WordPress developer has to work hard to reach are the baseline for a well-built HTML site. Security is simpler — fewer moving parts means fewer attack surfaces and no plugin vulnerabilities to patch on a monthly basis. Schema and structured data are straightforward to implement because you are working directly in the code rather than through a layer of builder markup.
The honest caveat is that editing requires a developer or someone comfortable with HTML. For a business whose core pages change occasionally — services, contact details, opening hours — that is rarely the limitation it sounds like. If you are paying a developer anyway, having them make occasional updates is a reasonable workflow. The trade-off is fast, clean, crawlable pages that do not degrade over time.
That twelve-year-old site I mentioned at the start is still performing because it was built this way. A site built on a clean HTML foundation in 2014 requires no updates, carries no plugin debt, and loads faster than most sites built in 2024. That tells you something about the quality of what is currently being sold.
Who it suits: Tradespeople, service businesses, consultants, solicitors, accountants — any business whose content does not change weekly and who values performance and longevity over self-editing convenience.
Gutenberg — Native WordPress
When a business needs to self-edit, publish regularly, or run a blog, Gutenberg is the right tool. It is the native WordPress block editor — built into WordPress core, maintained by the WordPress team, and designed to produce clean, server-rendered HTML output without the overhead of a third-party page builder.
A properly built Gutenberg site on a lightweight theme with minimal plugins is competitive with static HTML on Core Web Vitals. It gives non-technical editors a straightforward interface for updating content. SEO plugins like Rank Math integrate cleanly. Schema markup is implementable without fighting the builder.
For complex e-commerce — multiple product variations, payment gateways, shipping rules, membership systems — WordPress with Gutenberg and WooCommerce remains the right evaluation point. That conversation is more nuanced and depends on the specific requirements. But for a standard service business site with blog capability, a lean Gutenberg build is the professional standard.
Who it suits: Businesses that need to self-edit, publish regular content, run news or blog sections, or operate straightforward e-commerce.
Hybrid — HTML Core with Gutenberg Blog
A hybrid build combines static HTML for core pages — home, services, about, contact — with WordPress in a subfolder for content that changes regularly. The core pages stay fast and lean. The blog or news section runs on Gutenberg with full editing capability.
It is the right choice for businesses that want the performance of a static site on their most important pages without giving up the ability to publish. The trade-off is slightly more setup complexity and two systems to maintain rather than one — but when built correctly it offers the best of both approaches.
Who it suits: Businesses that want speed on core pages and regular publishing capability — gyms, restaurants, agencies, businesses with active blogs.
Test Your Current Site
Before we get into what I do not recommend, it is worth knowing where your current site actually stands. The tool below takes you directly to Google PageSpeed Insights — Google's own free performance testing tool. Enter your website address and see the score for yourself. The result has nothing to do with District Zero — it is Google's independent assessment.
Test Your Website Speed
Enter your website address below to test it directly in Google PageSpeed Insights — Google's own free performance tool. The result is completely independent, with no involvement from District Zero.
You will be taken directly to pagespeed.web.dev — Google's official PageSpeed Insights tool. Results open in a new tab.
A score of 90 or above on mobile is a reasonable baseline for a professionally built site. If your site is significantly below that — particularly on mobile — it is worth understanding why before you invest further in SEO, advertising, or content.
What I Do Not Recommend — And Why
This is not about whether these tools can be made to work. A skilled developer can get an Elementor site to 99% on Google PageSpeed Insights. A skilled developer can also build a Gutenberg or HTML site to 99% — with significantly less effort. So even in the best case scenario, you have worked harder to reach the same destination. There is no upside for the client. There is only additional risk.
Page Builders — Elementor, Divi, Beaver Builder
Page builders are built for the developer, not the client. They reduce build time significantly for the person doing the work. That financial incentive exists regardless of what the output means for your site performance. A developer who builds exclusively in Elementor will recommend Elementor to every client — not because it is the right tool, but because it is the only one they know.
The default output of most page builder sites is poor. Slow load times, bloated CSS and JavaScript bundles, poor Core Web Vitals scores, and markup so layered that crawlers struggle to extract the signal from the noise. Most Irish businesses paying €2,500–€3,000 for an Elementor site have no idea this is what they have bought.
The 99% argument comes up whenever this topic is raised. Yes, a skilled developer who knows what they are doing can optimise an Elementor build to perform well on PageSpeed. But there is a second problem that PageSpeed does not measure.
PageSpeed Insights measures performance for humans — load time, visual stability, interactivity. It does not measure what an AI crawler receives when it fetches your page. Page builders like Elementor generate content through JavaScript at render time. AI crawlers like GPTBot typically parse the raw HTML they receive rather than executing JavaScript the way a browser does. A site can score 99% on PageSpeed and still deliver a partially empty page to an AI crawler. A fast-loading page and a machine-readable page are not the same thing.
There is also a third problem that compounds over time. Even a well-optimised Elementor site will degrade as content is added, plugins are installed, and images are uploaded without developer oversight. Maintaining that score requires ongoing involvement from a developer who knows what they are doing. Which raises an honest question: if the client cannot use the site independently without eroding its performance, was the tool the right choice in the first place?
So the question is not whether Elementor can be made to perform. It is: why accept the additional complexity and risk when better alternatives exist at the same price point?
What Does the Client Actually Gain?
Strip away developer familiarity, developer workflow, and developer margins, and the list of genuine client benefits from Elementor over Gutenberg gets very short. The table below compares both on the features a typical small Irish business website actually needs.
| Feature | Gutenberg | Elementor |
|---|---|---|
| Client can edit content | ✓ Yes | ✓ Yes |
| Blog publishing | ✓ Yes | ✓ Yes |
| SEO plugins | ✓ Yes | ✓ Yes |
| Schema markup | ✓ Yes | ✓ Yes |
| Contact forms | ✓ Yes | ✓ Yes |
| Mobile responsive | ✓ Yes | ✓ Yes |
| WooCommerce | ✓ Yes | ✓ Yes |
| Native WordPress support | ✓ Yes | ✗ No |
| Additional plugin dependency | ✗ No | ✓ Yes |
| Additional update cycle | ✗ No | ✓ Yes |
| Server-rendered HTML by default | ✓ Yes | ⚠ Partial |
| Performance baseline | Clean by default | Requires optimisation |
One exception is worth stating clearly. If a client has used Elementor before and specifically wants to keep using it, that is a legitimate reason. If a project genuinely requires highly customised layouts or animation-heavy design that Gutenberg does not easily support, that conversation is worth having. For those projects the calculus is different.
But for a standard service business website — the plumber, the solicitor, the accountant, the gym, the restaurant — the question is not whether Elementor works. It is what the client receives for accepting the additional complexity that Gutenberg already handles without it.
One more claim worth addressing. Build speed is often cited as an Elementor advantage. It is not a platform advantage — it is a developer familiarity advantage. A developer who has spent years building Gutenberg sites with reusable blocks, patterns, and global styles builds a standard brochure site just as quickly as an Elementor developer builds the same site in Elementor. The client is buying a completed website, not paying for the developer's experience of building it. If both sites cost the same and are delivered in the same timeframe, build speed is entirely irrelevant to the client.
Bloated Themes
A theme loaded with demo content, animation libraries, built-in sliders, and bundled page builder integrations carries performance debt before a single line of your content is written. The CSS file alone on some popular themes runs to hundreds of kilobytes of rules your site will never use. That overhead does not disappear with good hosting — it is structural.
Themes like this get sold on their demo sites, which are carefully optimised showcases that bear no resemblance to what a typical build on that theme actually delivers. By the time the developer has added your content, your plugins, and your customisations, the performance characteristics of the demo are long gone.
HTML Templates
This one surprises people. A clean-looking HTML template can be carrying significant JavaScript weight — animation libraries, parallax scroll effects, icon fonts loaded from external CDNs, slider scripts, lightbox scripts. The visible design looks simple. The underlying payload is anything but.
When I am working from a template — which I try to avoid — the process involves stripping the CSS entirely and replacing the JavaScript with vanilla code written for the specific functions the site actually needs. If that is the work required to make a template usable, it raises an honest question about whether starting clean is the more efficient path.
Not all HTML templates are problematic. But the assumption that HTML automatically means lean is wrong. The markup language is not the issue — what gets loaded alongside it is.
Site Builders — Wix, Squarespace, Weebly
For a business with no budget getting online for the first time, a site builder is a legitimate option. Being online is better than not being online.
As a professional deliverable at €2,500 or more, it is not acceptable. Site builders have similar AI crawlability limitations to page builders, lock you into a third-party platform on third-party hosting under third-party terms, and limit what can be done technically. If someone is charging professional rates, you should receive a professionally built site that you own outright.
The Buyer's Problem
Web design in Ireland is an unregulated profession. There is no licensing, no minimum technical standard, no independent body setting quality benchmarks. The only protection available to a buyer is asking the right questions before signing anything.
Before hiring a web developer, ask:
- Can I see PageSpeed scores for sites you have built? Specifically mobile scores. Ask for live examples, not screenshots.
- What editor will I use to update my site? If the answer is Elementor or a proprietary page builder, ask why not Gutenberg.
- Will my core pages be server-rendered HTML? Content that loads via JavaScript may not be read by AI crawlers.
- Do you implement schema markup as standard? If they do not know what schema is, that answers the question.
- Who owns the site and hosting when the project ends? You should own both outright.
A developer who struggles to answer these questions — or who becomes defensive when asked — is telling you something important about what you would be buying.
The Standard You Should Expect
The businesses entering the AI search era in the strongest position are not always the ones with the newest sites. Sometimes they are the ones whose developer did it properly the first time and never gave them a reason to rebuild.
A properly built site — HTML or lean Gutenberg — does not need to be replaced every three years because the platform has moved on or the plugins have become incompatible. It does not accumulate performance debt. It does not require monthly maintenance to stay secure. It loads fast on day one and loads fast on day one thousand.
That is the standard. It is not complicated. It is just not what most people are currently being sold.
Fact-Check This Article with AI
Claude will display a security notice for external prompts — this is standard behaviour, just click send. The AI may not agree with every recommendation. That is fine.
