Case study — our own site

How we rebuilt our own website — WordPress to static, warts and all

In June 2026 we switched off the WordPress site we’d run for years and replaced it with a hand-built static site. This is the full teardown: why we did it, what we kept, what broke, the before-and-after numbers from our own PageSpeed runs, and what it honestly costs to run now. No affiliate links, no “10x your traffic” claims — just what happened. Rated 4.9 on Google.

Get Honest Help Call 01202 775566

● Our own site, our own numbers
● WordPress to static, June 2026
● Family-run since 1995

The decision

Why we left WordPress after years of using it

Our old site was WordPress on SiteGround, and to be fair to WordPress, it worked. But three things wore us down.

The update treadmill. Core updates, theme updates, plugin updates — every week, something wanted attention, and every update carried a small chance of breaking the site.
The security surface. Every plugin is code someone else wrote, running on our server, with an admin login bolted on the front. As an IT firm we spend enough time thinking about other people’s attack surfaces; we didn’t want one of our own that we couldn’t fully see into.
The speed ceiling. However much we tuned it, mobile scores sat in the mid-60s. The database, the theme framework and the plugin stack all sat between the visitor and the page.

One honest caveat: we write code for a living, so a hand-built site costs us time rather than money. That maths is different for most businesses — we’ve set out the balanced version in static site vs WordPress for a small business. WordPress wasn’t broken. It just wasn’t the right tool for us any more.

Continuity

What we kept: hosting, redirects and forms

A rebuild doesn’t have to mean changing everything at once, and deliberately we didn’t.

Hosting stayed put. The new site runs on the same SiteGround hosting the WordPress site did. Static files are undemanding, so there was no need to add a hosting migration to an already fiddly job.
Every old URL still works. We mapped the old WordPress addresses to their new equivalents and wrote 301 redirects into the .htaccess file, so old links, bookmarks and Google results all land somewhere sensible. This is the single most important step in any rebuild — skip it and you throw away years of accumulated search history.
The forms kept working. Our enquiry forms post to HubSpot, and they did before too. Enquiries flowed through the changeover without a gap.

The lesson we’d pass on: separate the decisions. Changing your website, your hosting and your forms on the same weekend is how things get lost.

Under the bonnet

How the site ships now: no CMS, no database, no admin login

The new site is plain HTML, CSS and a little JavaScript, generated by a build script we wrote ourselves. There’s no content management system, no database and no admin login page — which means there’s nothing for the usual automated WordPress attacks to find.

Publishing works like this: we edit the source files, push the change to GitHub, and a GitHub Action automatically uploads the built site to our hosting over FTPS. From saving a change to it being live takes about a minute, and every version of the site is kept in history, so we can wind anything back.

In plain English: the site became a set of finished pages sitting on a server, rather than a program that assembles each page when somebody asks for it. Less machinery means less to slow down, less to update and less to break. The trade-off is real, though — there’s no dashboard where a non-technical person can edit a page, which is exactly why this approach suits some businesses and not others.

Results

The numbers, honestly framed

Here is the before-and-after we can actually stand behind. On our own Google PageSpeed and Lighthouse runs, the mobile performance score went from roughly 65 on the old WordPress site to the high 80s on the new static site (June 2026). Two honest footnotes:

These are our own measurements of our own site. Scores vary run to run — sometimes by several points — depending on network conditions and which page you test. Treat any site that quotes a single exact score with suspicion.
We are not claiming a traffic or revenue jump. The rebuild is recent, search results move for lots of reasons, and pretending we can isolate one cause would be exactly the kind of claim we set out to avoid.

What the speed change does mean is straightforward: pages appear faster on real phones, which matters for the humans using them — and page experience is one of the things Google says it looks at, as we cover in website speed and local SEO.

You can get the same numbers for your own site in about a minute with our free website checker — it runs the checks we ran, and it doesn’t ask for your email address.

We have since done the same for clients and measured it properly. A Dorset builder’s WordPress site and its replacement, both measured on the last day the old one existed — every figure is in what a website rebuild actually changes. And for Beckox Plastic Fabrications of Poole — named with their permission — we ran the same Lighthouse against the same live address before and after: 37 to 88 on mobile, with the main content arriving in 2.1 seconds instead of 43.7.

Full disclosure

What broke on the way, and what we’d do differently

Case studies that go perfectly are usually edited. Here’s what actually went wrong on ours.

Our own animation was tanking our own score. A hero animation on the homepage briefly hid the largest visible element while it played — and Google’s speed measurement clocks when that element appears. Our mobile score sat lower than it should have until we found it. Self-inflicted, and invisible unless you know where to look.
The hosting firewall fought us. The first scripted request to our own API endpoints came back with a 403 error — the host’s web application firewall assumed we were a bot. Fair enough, but it cost an afternoon.
An embedded booking widget rendered blank. We’d used the wrong embed address for a third-party widget and its security headers silently blocked it from loading in the page. The fix was one line; finding it wasn’t.
One hand-edited page kept getting forgotten. Our homepage sits outside the build script, so site-wide changes had to be applied to it by hand — and occasionally weren’t. Document your exceptions.

What we’d do differently: build the redirect map first, not last; take before measurements on the same pages and device you’ll test afterwards; and add no animation until the plain version measures well. If your current site is slow and you’re weighing up tuning versus starting again, we’ve written up that decision separately in slow WordPress site: fix it or rebuild it?

Money

What it honestly costs to run now

A myth worth puncturing: going static did not make our website free. We still pay for the same shared hosting plan we always did, plus the annual domain renewal — those costs didn’t change at all.

What did change is everything around them. There are no plugin licences, no premium theme renewal, no page-builder subscription, and — the big one — no monthly maintenance time spent applying updates and checking nothing broke. For us the saving is mostly measured in hours rather than pounds, and in the background worry that’s gone with the admin login.

The honest flip side: the cost moved from subscriptions to skill. Editing a static site means editing files, which we’re happy doing and most business owners understandably aren’t. If that’s the bit that puts you off, that’s a solvable problem rather than a dealbreaker — it’s precisely the gap our web design & hosting service exists to fill, and it’s worth reading before you decide anything.

What happened next

What we built after — and doing it again for someone else

Once the machinery existed, adding pages became cheap. Over the following weeks we built out nearly forty free browser tools — speed checkers, SSL and domain checkers, generators, a GPU benchmark — all on the same stack: no CMS, no plugins, no database. They’re all in our free tools hub, and every one of them is a page that simply couldn’t have carried its own weight on the old plugin-laden site.

Then we did the whole process again, this time for a client: a long-established Dorset builder whose ageing site needed the same treatment. Same recipe — keep the domain, map every old URL to a 301 redirect, rebuild as fast static pages, keep what already worked. We’re not naming them here without their say-so, which tells you something about how we treat the businesses we work with.

That’s really the point of this page. The rebuild you’ve just read about is the exact process we’ve since productised for other businesses — the same redirect-first, measure-everything, break-nothing approach. If your site needs it, the service version lives at website rebuild. And if you’ve outgrown a website builder rather than WordPress, the same thinking applies — see outgrown Wix or Squarespace?

// RELATED

Frequently asked

Why did you move away from WordPress?

Three reasons: the constant update treadmill (core, theme and plugin updates every week), the security surface of an admin login plus dozens of plugins, and a mobile speed ceiling we couldn’t tune our way past. WordPress wasn’t broken — it just wasn’t the right tool for us any more. For many businesses it still is.

Did your Google rankings drop when you switched?

We kept every old URL alive with 301 redirects in .htaccess before the switch, and we didn’t see a drop we could attribute to the migration. That said, we deliberately make no traffic claims — the rebuild is recent and search results move for many reasons. The redirect map is the part that protects you; skipping it is how rebuilds go wrong.

What does “static site” actually mean?

The pages are finished HTML files sitting on the server, sent to visitors as-is. A WordPress site instead assembles each page on demand from a database using PHP and plugins. Static means less machinery between the visitor and the page — faster, and with far less to update or attack — but no edit-in-your-browser dashboard.

How much faster did the site get?

On our own PageSpeed and Lighthouse runs, mobile performance went from roughly 65 to the high 80s (June 2026). Scores genuinely vary run to run, so we’d rather say “high 80s” than quote a single exact number. You can test your own site free with our website checker at /website-checker/.

Did you have to change hosting?

No. The static site runs on the same SiteGround hosting the WordPress site used. Static files are so undemanding that almost any existing hosting plan handles them easily, which meant one less thing to change — and one less thing to go wrong.

How do you update a site with no CMS?

We edit the source files and push the change to GitHub; an automated action uploads the built site to the hosting within about a minute. Every change is kept in version history, so anything can be rolled back. It suits people comfortable with files — for clients who aren’t, we handle the edits as part of looking after the site.

Would my site get the same speed improvement?

We honestly can’t promise that. Our numbers are measurements of our own site, and every site starts from a different place — some WordPress sites are already quick. The sensible first step is to measure yours: our free checker at /website-checker/ gives you the same scores we used, with no email required.

Is a static site right for my business?

Sometimes, and sometimes not. If your site changes rarely and needs to be fast and low-maintenance, it’s a strong fit. If non-technical staff update content daily, a CMS earns its keep. We’ve written an even-handed comparison at /static-site-vs-wordpress-small-business/ — and we’ll tell you honestly if your current site is fine as it is.

What did the rebuild cost you to run afterwards?

The hosting and domain costs didn’t change at all — going static did not make the site free. What disappeared were plugin licences, theme renewals and the monthly maintenance hours spent applying updates. For us the saving is mostly time and worry rather than a dramatic cash figure, and we’d rather say that plainly than invent one.

Thinking about doing the same to your site?

We’ll tell you straight whether a rebuild is worth it — sometimes it isn’t. Family-run since 1995, 4.9 on Google, Mon–Fri 9–5. Call 01202 775566 or text 07520 615332.