The page only one program can read

A page builder is a program that lets you design a web page by dragging boxes around, without writing anything. It is the most popular way to make a WordPress site. It is also the reason I have twice been called in to a website that nobody could repair.

October 2026

If you build your website with Divi 5, and then switch to a new theme or builder, you’ll start with a blank slate instead of with unwanted shortcodes in the post content.

Elegant Themes, the makers of Divi, on what their own rewrite finally fixes

Both times the brief was the same, and both times it was phrased carefully, the way people phrase things when they suspect the answer is expensive. The site worked, more or less. It was slow. Small changes broke other things. The person who built it was no longer around. Could I have a look.

And both times I found the same thing, which I want to describe precisely rather than angrily, because the anger is not useful and the mechanism is.

First, a distinction that matters

People use “block editor” and “page builder” as if they were the same thing. They are not, and the difference is the entire subject of this piece.

The block editor comes with WordPress itself. It arrived in December 2018, in version 5.0. When you save a page with it, what lands in the database is HTML — headings, paragraphs, lists — with small comments around them saying which block each piece came from. Switch off the theme, change to another one, export the site, read the database by hand: the words are still there, still marked up, still readable.

A page builder — Divi, Elementor, WPBakery and a dozen others — is a commercial product from a company, installed on top of WordPress. It has its own editor, its own storage, its own styling system, and its own idea of what a page is. It does not use the block editor. In most cases it switches it off.

2011: a real problem, solved by whoever got there first

It is worth remembering why these things exist, because they were not a mistake.

For the first decade of WordPress, making a page meant typing into a text box. Anything that looked like a layout — two columns, a banner, a row of three boxes — had to be built by somebody who wrote code. Clients could write; they could not arrange. That gap was real, and it was wide, and it lasted for years.

The first page builder appeared in May 2011. Others followed through the early 2010s and the market became enormous — these are among the most widely installed pieces of software in the WordPress world, and they made a great many websites possible for people who could never have afforded a developer.

WordPress itself did not answer until December 2018, seven years later. By then the builders had millions of sites, their own customers, their own economics, and no reason at all to hand that back.

Where your words actually end up

This is the part nobody explains when the site is being sold, and it is the part that decides what happens to you in five years.

Divi, in the version that is on most sites today, stores a page as nested shortcodes inside the normal content field. Your page in the database does not read as a paragraph about opening hours. It reads as [et_pb_section][et_pb_row][et_pb_column][et_pb_text], then a fragment of your sentence, then the closing tags. Switch the theme off and the visitor does not see a plain version of your page. They see those brackets, printed on the screen, as text.

Elementor takes the other route. The page is stored as a block of JSON in a hidden custom field, which their own developer documentation describes as a serialised representation of the layout and its settings. The ordinary content field, the one every other tool in the WordPress world reads from, is often very nearly empty. Switch the plugin off and the page is not full of brackets. It is blank.

Either way, the thing in your database has stopped being a document. It has become instructions, in a private format, for one specific program. You still own it in the legal sense. You just cannot read it without buying the reader.

You do not have to take my word for the consequences, because the makers of Divi have published them. Explaining why Divi 5 abandons shortcodes, Elegant Themes list the problems with their old system — slower to parse, certain characters break the page outright, some structures impossible — and note that with the new format, somebody who moves to another builder will start with a blank slate instead of with unwanted shortcodes in their content. That is the admission. It only took a rewrite that is still being rolled out, version by version, years after it began.

Why it is shaky, and not by accident

The instability my clients described is not bad luck or a bad developer. It follows from the arrangement.

• The design is in the database, not in files. Colours, spacing, fonts and the layout of every page live in the builder’s own settings and in rows of a table. There is nothing to put in version control, nothing to compare between yesterday and today, nothing to review, and no way to see what changed when something breaks.
• So there is no safe place to try anything. A staging copy only helps if you can move your change back. When the change is three hundred database rows, you cannot. People end up editing the live site, carefully, on a Friday.
• The layers accumulate. The builder, the theme that belongs to it, a pack of extra modules, a cache plugin bought to fix the speed the builder cost, and a plugin to add the CSS the builder will not let you write. Each one updates on its own schedule, and each update is a small bet.
• The markup gets deep. A row of three boxes can arrive as a dozen nested containers, each with generated class names. That is what makes the page heavy, and it is also why a developer cannot simply go in and fix one thing: there is no file to open and no name to search for.

That last point is the one my clients felt without being able to name it. They thought they had a website that needed a repair. What they had was a document stored in a format only one commercial program could open, and that program was now the website.

And the part the visitor pays

There is an accessibility bill too, and it is quieter. Builder output tends to be full of generic containers where headings should be, because a heading in these tools is a styling choice rather than a structural one — you pick a size, not a level. Somebody using a screen reader navigates by heading level. Pick sizes for six years and there is nothing left to navigate by.

The order on the screen and the order in the code drift apart, because boxes get moved visually and the underlying sequence does not follow. Colours are chosen by eye in a colour picker with nothing checking the contrast. None of this is forced by the tool. All of it is made easy by the tool, and difficult to notice.

In fairness, which is also the useful part

I am not arguing that everybody who uses a page builder has made a mistake. That would be both rude and wrong.

A person who runs a shop, has a small budget, and wants to move a photograph above a paragraph on a Tuesday evening without emailing anybody — that is a real need, and for a long time only the builders met it. If a site exists, earns, and the owner can maintain it themselves, the arrangement is doing its job. I would not walk into that and tell them it was built wrong.

Two things have changed, though. The block editor plus a well-made theme now does most of what people actually used a builder for, and it stores the result in a format anybody can read. And the builders themselves are moving: Divi 5 exists precisely because the old way of storing a page turned out to be the wrong way.

So the question is not whether page builders are bad. It is what you are agreeing to, and whether anybody told you.

Which gives a short list, worth running before the decision is made rather than after:

What a rescue actually was

In both cases the answer turned out to be the same, and I did not reach it quickly or gladly, because starting again is the most expensive advice anybody can give.

There was nothing left to adjust. Every repair ran into the builder, every workaround added another layer, and the site would have been in the same state again within a year with more products stacked on it. So I took the content out, dropped the whole arrangement, and built it back in plain code: a small theme, templates in files, in version control, with the pages as ordinary HTML in the database.

What the owner got back was not mainly a faster site, although it is faster. It was a site that somebody else can open. The next person does not have to buy anything, learn a product, or ask me. That is the thing worth paying for, and it is the one thing a builder cannot sell you, because selling it would mean giving it away.

Read the originals

Read the first one even if you never touch Divi. It is a company explaining, in public, why the thing they sold for a decade stored your content the wrong way.

• Divi 5 and the move away from shortcodes — Elegant Themes. The problems with shortcode storage, listed by the people who built it, including what you are left with when they leave.
• Data Structure — Elementor developer documentation. Short and clear: the page is JSON in a hidden custom field. Everything in this essay follows from that one sentence.
• Divi 5 update status — Elegant Themes. The running log of a rewrite that is still arriving, with its own migration guide and its own rollback instructions. Read it as a measure of how deep the format went.
• WordPress 5.0 “Bebo” — December 2018, the release that finally put an editor with layout into WordPress itself, seven years after the first builder.
• A brief history of WordPress website builders — for where it started, in May 2011, and why.