How the WordPress builder industry is currently answering without having understood the question

Elementor has 12 million active installations. Divi runs on millions more. Together, Elementor and Divi dominate over 70% of the WordPress page builder market, and 64% of all WordPress sites run some kind of builder (WPBeginner, 2025). That's an industrial scale.

Now both have AI. Elementor AI generates text, images and code. Divi AI builds layouts based on prompts. The press releases sounded good.

The problem is not the execution. The problem is the architecture.

What Elementor does in the background

Anyone who has never looked behind the surface of a page builder doesn't know this part. So let's take a look.

When a user builds a page in Elementor, WordPress doesn't just save the result as HTML. The actual Elementor data set ends up as a serialized JSON string in the meta field _elementor_data of the wp_postmeta table. This string describes which widgets were placed in which order with which parameters. It looks something like this:

[{"id":"abc123","elType":"section","settings":{"layout":"boxed"},
"elements":[{"id":"def456","elType":"widget","widgetType":"heading",
"settings":{"title":"Mein Heading","title_color":"#333333"}}]}]

This is not a web standard. This is Elementor's proprietary format. While rendered HTML does end up in post_content, that's only the output cache. The actual source from which Elementor builds everything is the _elementor_data field. Anyone who wants to read this data outside of Elementor faces a black box. It doesn't render. It can't be deployed. It can't be versioned like normal code.

Divi uses a different approach, but with the same result: shortcodes. Blocks like [et_pb_section][et_pb_row][et_pb_column type="4_4"][et_pb_text]Content[/et_pb_text] are meaningless outside of WordPress and specifically outside of Divi.

These formats were not built for machines. They were built for databases that are read by a PHP application. That was technically sufficient for a world without AI.

Why AI has a structural problem with this

Large Language Models were trained on enormous amounts of public code. HTML, CSS, JavaScript, PHP, Python: billions of lines, well documented, widely distributed. Models can generate clean web code directly from a natural language description because they've seen this web code millions of times.

Elementor's proprietary JSON? Divi's shortcodes? These are niche formats with minimal presence in training data. A model that's supposed to work with them must interpolate, hallucinate, or fall back on generic patterns.

This is not a problem that better models will solve. It's a data problem. And behind the data problem is an architecture problem: The formats were not built to be understood and generated by AI.

On top of that comes the abstraction stack itself. AI in Elementor must not only generate the proprietary format. It must:

  1. Understand the natural language request
  2. Translate it into Elementor's widget taxonomy: Which widget represents what?
  3. Know the correct parameters for this widget: Which CSS property is behind which slider?
  4. Serialize the result as valid Elementor JSON
  5. Stay within the limits set by Elementor's rendering engine

Step 1 is what AI does well. Steps 2 through 5 are overhead created by the architecture. Each of these layers increases the probability of errors and reduces the quality of the output.

Direct comparison: "Build me a responsive hero section" to a model without builder context produces clean HTML/CSS in under three seconds. The same prompt in Elementor AI runs through all five layers and produces a result that works within the builder system but is worthless outside of it.

A bridging tool: MCP servers partially change this picture. Tool calls are deterministic. When an MCP server receives the command "create a section with these parameters," the same thing always happens. The execution is reliable, structured, reproducible.

What is not deterministic is the decision beforehand. The LLM stochastically chooses which tool it calls, with which parameters, in which order. The question "which widget represents a hero section?" remains probabilistic, whether via MCP or directly. MCP shifts the non-determinism problem, it doesn't solve it.

This still makes MCP a real advance over raw proprietary JSON. The error surface is smaller, the tool interface clearer than hallucinated builder JSON. But the structural hierarchy remains: Direct web standard code, whether manual or AI-generated, doesn't have this overhead. MCP is a better bridge over the same chasm.

The performance debt nobody mentions

There's a second level that's rarely discussed in the context of AI builders: Performance.

Elementor loads framework CSS and JavaScript on every page, regardless of which widgets are actually used. Divi generates framework-level code that is delivered regardless of the specific page. Manual configuration through caching plugins is necessary to compensate for this. Industry comparisons consistently show that Elementor sites without targeted optimization measures perform significantly worse than equivalent sites in static HTML or modern frameworks. Performance is not a post-hoc configuration task. It is a structural characteristic of the base system.

This is not solely Elementor's failure. It is the structural result of a system built for visual flexibility, not for load time optimization.

AI changes nothing about this. An AI-generated Elementor layout carries the same framework overhead as a manually built one. AI can accelerate the layout process. It cannot repair the architecture.

Direct code, whether manual or AI-generated, doesn't have this problem. It only loads what's needed.

Growth that has stopped growing

Elementor's growth curve is no longer what it was. The steep adoption curve of the years 2018 to 2023 is flattening out. A slight decline from the peak is measurable (WPAllImport, 2026). Divi shows the same pattern.

This must be read in the macro context. WordPress itself is losing sustained market share for the first time in its history: from 65.2% CMS share in 2022 to 60.7% in October 2025 (Landbase, 2026). The platforms gaining share are Wix, Squarespace, Shopify. None of them is a classic open-source builder. All are SaaS platforms with integrated solutions.

What this means: WordPress is not losing to better CMS platforms. It's losing to simpler ones. Users are not migrating to Drupal or TYPO3. They're migrating to systems that require less setup. This is the same pattern as the abstraction collapse, just from a different side: It's not AI making builders obsolete, but even stronger simplification. AI accelerates this trend because it opens the path to direct code.

What the builder industry could do instead

The obvious thing is not to integrate AI into the builder. The obvious thing is to use the builder as a starting point for AI-generated standard code.

Specifically: A builder that exports AI output as clean HTML/CSS/JS and doesn't save it as proprietary JSON, that translates layouts into standard formats instead of platform-specific structures, that uses AI as a design tool instead of as a UI automator, would have a real strategic position in the AI era.

Gutenberg, the native WordPress block editor, is going in this direction. Blocks are more standardized than Elementor widgets, closer to HTML, better suited for AI processing. Its problem: almost nobody loves it.
Nevertheless: the stack WordPress Core plus ACF plus AI-generated Custom Block Templates has structurally more future than Elementor Pro plus AI plugin. It's more performant, more maintainable, and significantly better understood by language models.

This doesn't mean that every WordPress user should migrate immediately. Millions of Elementor sites exist, are maintained, and function. These websites won't disappear overnight.

However, anyone who has to make a decision today, whether for a client project, for their own infrastructure, or for investments in builder expertise, should know the direction.

The conclusion

Elementor and Divi have delivered real value for a decade. That's not irony. That's fact. Millions of people have built websites they couldn't have built without these tools.

But their AI integration solves the wrong problem. It improves the process within an architecture that was built for a world where code was inaccessible. That world no longer exists in that form.

AI in Elementor is not bad. It's the best possible answer to a question that's currently shifting.

The question was: "How does someone without programming knowledge build a professional website?"

The answer in 2016 was: "With a visual builder."

The answer in 2026 is increasingly: "With a prompt."

That's the difference. It's significant.

Sources: