What we learned rebuilding our own site without a page builder

We rebuilt drizzlejar.com this week. The old site ran on Elementor: sixteen pages and eight case studies, every one of them a page-builder document. The new one is a coded WordPress theme: plain PHP templates, a small design system, and content in custom fields.

The homepage went from 152KB of HTML to 42KB. That is not a micro-optimisation. It is the same page, saying the same things, with roughly two-thirds of the weight gone.

Here is what the move actually involved, including the parts that went wrong.

Why leave a page builder at all

Page builders are genuinely good at one thing: letting someone who does not write code change a layout without waiting on a developer. That is a real benefit and we are not dismissive of it.

The cost arrives later. Your content stops being content. In Elementor, a page is not a document with words in it. It is a large blob of JSON stored in the database describing nested containers, widgets and styling. The words are in there somewhere. Getting them out is a parsing exercise.

That has consequences you only feel when you try to leave. You cannot edit the page through the WordPress API, because the API writes to a field the page builder is not reading. You cannot easily move to a different tool, because there is no clean export of what the page says. And every page carries the weight of a rendering engine that exists to make layouts editable, whether or not anyone is still editing them.

Three things that broke

We expected the migration to be tedious. We did not expect these.

The page builder kept rendering after we switched themes

We activated the new theme and the site looked exactly the same. Not broken: unchanged. The new templates simply were not running.

Elementor Pro hooks into the WordPress function that decides which template file handles a request, and takes it over. While the plugin is active, it renders its own header, body and footer, and your theme is reduced to a stylesheet. The page source told the whole story: the body tag carried our theme name and Elementor markup at the same time.

The lesson is about sequencing. We had planned to deactivate the page builder last, after verifying the new site. That order cannot work. There is nothing to verify until it is switched off. If you are doing this, turn it off first and accept a short window where you are looking at the new site for real.

Activating the theme took eight URLs offline

Our case studies are a custom post type. The moment the new theme activated, all eight of their URLs started returning 404.

The post type itself was completely healthy. The API still listed it, still returned all eight entries, still reported the correct permalinks. Only the front-end URLs failed, which sends you looking in exactly the wrong place.

The cause was ordering again. Switching a theme rebuilds WordPress rewrite rules, and it does so at a point in the request that runs before our custom post type is registered. The rules were rebuilt without it. The fix is to rebuild them once more, later in the request, after everything has registered, and to guard that with a stored version number so it happens once per deploy rather than on every page load.

A successful contact form looked like a broken one

Leaving the page builder also meant leaving its form widget, so we wrote our own handler. It worked: the mail arrived. But after submitting, the visitor was thrown to the homepage, where there is no form and therefore no confirmation message. From the outside, a successful send was indistinguishable from a silent failure.

The cause is a small, well-documented WordPress behaviour that is easy to walk straight into. The helper that tells you where a request came from deliberately returns nothing when the source and destination are the same page, and a form that posts back to itself is always that case. There is a second helper that skips the check. We were using the wrong one.

We only found it because we submitted the live form and watched what happened. Nothing in the code review would have caught it.

What we would tell you

Leaving a page builder is not really a technical migration. The templates are the easy part. The work is that your content was never in a portable shape, and you have to put it into one before you can go anywhere.

Budget for that honestly. Assume the content needs rewriting rather than moving. Turn the plugin off early so you are testing reality. And test the things users actually do: submit the form, click through the navigation, load a case study, because the interesting failures are the ones that look like success.

The site you are reading this on is the result. Two fewer plugins, no rendering engine between the content and the page, and templates we can read.