Gutenberg, Elementor, Divi: what your page builder really decides
It quietly determines who can maintain your site, what it costs, and how stuck you are.
Most owners never chose a page builder. The designer picked one, or the theme came with one, and the site simply looked the way it looked. It’s treated as a matter of taste, like picking a font.
It isn’t. The builder decides how your pages are physically saved, and that one technical detail ends up shaping a surprising number of business decisions years later.
What a page builder actually is
WordPress on its own stores a page as a block of content, and your theme decides how it looks. A page builder is a tool that lets you arrange that page visually: drag in a heading, add a column, set a background colour, move a button, all without writing code.
Since WordPress 5.0 in December 2018, WordPress has shipped with its own block-based editor, usually called Gutenberg. Many sites also use a separate builder plugin on top. Elementor is the best known: W3Techs reports it is used by 12.7% of all websites. Others include Divi, WPBakery, Beaver Builder and Bricks.
On screen they feel similar. Underneath, they save your work in quite different ways.
Same page, very different storage
Here is where each one keeps what you built, according to their own documentation:
- Gutenberg saves ordinary HTML in the page’s main content, with HTML comments marking where each block starts and ends. WordPress’s developer docs explain that this is deliberate: the post remains mostly intact even if the saved HTML is rendered as is.
- Elementor stores the page layout as JSON in WordPress post metadata, a hidden custom field that isn’t visible in the WordPress dashboard.
- Bricks stores its header, content and footer as serialised arrays in post metadata, each under its own key.
- WPBakery works through shortcodes, short bracketed tags like
[vc_row]that the plugin turns into layout. Its own troubleshooting guide says the most common reason a page shows shortcodes instead of its elements is that the plugin has been deactivated. - Divi 4 also used shortcodes: Elegant Themes describes how each element you added was saved as a shortcode holding its settings. Divi 5, which left beta on 26 February 2026, moved to a block-based format and includes a migrator to convert older pages.
- Beaver Builder takes a gentler line on exit: when you deactivate it, a stripped-down HTML version of your layout is copied to the WordPress editor. It may not look the same, but the content isn’t lost.
You don’t need to remember any of this. You just need to know that “where does my page live?” has a different answer depending on the tool, and that answer matters later.
The day you want to leave
Lock-in rarely shows up on day one. It shows up when you redesign, change agencies, or find the builder no longer suits you.
If your pages are shortcodes, switching the builder off can leave visitors looking at bracketed tags where your layout used to be. If your layout lives in hidden metadata, the main content field may hold little of what you see on screen, so another tool has nothing sensible to pick up. In both cases “switching” usually means rebuilding pages, not converting them. Even a well-supported move, like Divi 4 to Divi 5, is a migration you’d want to test before trusting it on a live site.
A page builder is easy to start with and expensive to leave. Those are both features of the same decision.
Who can maintain it, and what a change costs
The builder also decides who can help you. A developer who knows Gutenberg well may be slow in Bricks. An Elementor specialist may not want to touch a WPBakery site. When your original designer moves on, the pool of people who can confidently change your site is whoever knows that particular tool.
That shows up in the cost of small jobs. Changing a phone number is trivial in any builder, if you know where the builder put it. Someone unfamiliar with your set-up spends the first part of every job just finding their way around. And a change made the wrong way, for example editing the underlying content directly when the builder keeps its own copy elsewhere, can simply not appear, or be overwritten the next time someone saves.
Questions to ask before you choose or switch
- Where does it store my pages? In the normal content field as readable HTML, or somewhere only the builder understands?
- What happens if I switch it off? Ask the vendor, or check their docs. Beaver Builder, for example, documents it plainly.
- Who else can work on it? If your designer disappeared tomorrow, how easy would it be to find someone who knows this tool?
- What does it add to every page? Builders load their own code. Rather than trusting anyone’s claims, test a few of your own pages with a speed tool before and after.
- Does it have a clear upgrade path? Builders change their own formats too, as Divi did. Look for a documented migration, not a promise.
- Is switching worth a rebuild? If the site works and people can maintain it, staying put is often the cheaper decision.
Where Kepteo fits
Kepteo was built for the reality that most sites weren’t made in one tidy way. When you ask for a change, it first detects which builder that page uses, then edits it the way that builder stores content, rather than treating every page as plain text.
It supports Gutenberg, the Classic editor, Elementor, Divi, WPBakery, Beaver Builder, Bricks, Oxygen, Avada (Fusion Builder) and SiteOrigin. For Breakdance, Brizy, Visual Composer Website Builder and Themify, it recognises the builder and declines to edit rather than risk breaking the page. Whatever the builder, every change is saved as a draft that waits for your approval before anything goes live.