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 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 look.

When a user builds a page in Elementor, WordPress doesn't just save the result as HTML. The actual Elementor dataset 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 roughly like this:

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

Das ist kein Webstandard. Das ist Elementors proprietäres Format. In post_content landet zwar gerendertes HTML, aber das ist nur der Ausgabe-Cache. Die eigentliche Quelle, aus der Elementor alles aufbaut, ist das _elementor_data-Feld. Wer diesen Datensatz außerhalb von Elementor lesen will, steht vor einer Black Box. Es rendert nicht. Es lässt sich nicht deployen. Es lässt sich nicht versionieren wie normaler Code.

Divi nutzt einen anderen Ansatz, aber mit demselben Ergebnis: Shortcodes. Blöcke wie [et_pb_section][et_pb_row][et_pb_column type="4_4"][et_pb_text]Inhalt[/et_pb_text] sind außerhalb von WordPress und speziell außerhalb von Divi bedeutungslos.

Diese Formate wurden nicht für Maschinen gebaut. Sie wurden für Datenbanken gebaut, die von einer PHP-Applikation ausgelesen werden. Das war technisch ausreichend für eine Welt ohne KI.

Warum KI damit ein strukturelles Problem hat

Large Language Models wurden auf enormen Mengen an öffentlichem Code trainiert. HTML, CSS, JavaScript, PHP, Python: Milliarden Zeilen, gut dokumentiert, weit verbreitet. Modelle können aus einer natürlichsprachlichen Beschreibung direkt sauberen Webcode erzeugen, weil sie diesen Webcode millionenfach gesehen haben.

Elementors proprietäres JSON? Divis Shortcodes? Das sind Nischenformate mit minimaler Präsenz in Trainingsdaten. Ein Modell, das damit arbeiten soll, muss interpolieren, halluzinieren oder auf generische Muster zurückfallen.

Das ist kein Problem, das sich durch bessere Modelle löst. Es ist ein Datenproblem. Und hinter dem Datenproblem steckt ein Architekturproblem: Die Formate wurden nicht dafür gebaut, von KI verstanden und erzeugt zu werden.

Hinzu kommt der Abstraktions-Stack selbst. KI in Elementor muss nicht nur das proprietäre Format erzeugen. Sie muss:

  1. Die natürlichsprachliche Anfrage verstehen
  2. Diese in Elementors Widget-Taxonomie übersetzen: Welches Widget bildet was ab?
  3. Die korrekten Parameter für dieses Widget kennen: Welche CSS-Eigenschaft liegt hinter welchem Slider?
  4. Das Ergebnis als valides Elementor-JSON serialisieren
  5. Innerhalb der Grenzen bleiben, die Elementors Rendering-Engine setzt

Schritt 1 ist das, was KI gut kann. Die Schritte 2 bis 5 sind Overhead, den die Architektur erzeugt. Jede dieser Schichten erhöht die Fehlerwahrscheinlichkeit und reduziert die Qualität des Outputs.

Direkter Vergleich: "Baue mir eine responsive Hero-Section" an ein Modell ohne Builder-Kontext ergibt sauberes HTML/CSS in unter drei Sekunden. Dasselbe Prompt in Elementor AI läuft durch alle fünf Schichten und produziert ein Ergebnis, das innerhalb des Builder-Systems funktioniert, aber außerhalb davon wertlos ist.

Die Performance-Schuld, die niemand erwähnt

Es gibt noch eine zweite Ebene, die im Kontext von KI-Buildern selten diskutiert wird: Performance.

Elementor lädt Framework-CSS und JavaScript auf jeder Seite, unabhängig davon, welche Widgets tatsächlich genutzt werden. Divi generiert Framework-Level-Code, der unabhängig von der konkreten Seite ausgeliefert wird. Manuelle Konfiguration durch Caching-Plugins ist notwendig, um das zu kompensieren. Branchenvergleiche zeigen konsistent, dass Elementor-Sites ohne gezielte Optimierungsmaßnahmen deutlich schlechter abschneiden als gleichwertige Sites in statischem HTML oder modernen Frameworks. Performance ist keine nachträgliche Konfigurationsaufgabe. Sie ist ein strukturelles Merkmal des Ausgangssystems.

Das ist nicht Elementors Versagen allein. Es ist das strukturelle Ergebnis eines Systems, das für visuelle Flexibilität gebaut wurde, nicht für Ladezeitoptimierung.

KI verändert daran nichts. Ein KI-generiertes Elementor-Layout trägt denselben Framework-Overhead wie ein manuell gebautes. Die KI kann den Layout-Prozess beschleunigen. Sie kann die Architektur nicht reparieren.

Direkter Code, ob manuell oder KI-generiert, hat dieses Problem nicht. Er lädt nur, was gebraucht wird.

Wachstum, das aufgehört hat zu wachsen

Elementors Wachstumskurve ist nicht mehr das, was sie war. Die steile Adoption-Kurve der Jahre 2018 bis 2023 flacht ab. Ein leichter Rückgang vom Peak ist messbar (WPAllImport, 2026). Divi zeigt dasselbe Muster.

Das muss im Makrokontext gelesen werden. WordPress selbst verliert zum ersten Mal in seiner Geschichte sustained Marktanteile: von 65,2% CMS-Anteil in 2022 auf 60,7% in Oktober 2025 (Landbase, 2026). Die Plattformen, die Anteile gewinnen, sind Wix, Squarespace, Shopify. Keine davon ist ein klassischer Open-Source-Builder. Alle sind SaaS-Plattformen mit integrierten Lösungen.

Was das bedeutet: WordPress verliert nicht an besseren CMS-Plattformen. Es verliert an einfacheren. Nutzer wandern nicht zu Drupal oder TYPO3. Sie wandern zu Systemen, die weniger Setup erfordern. Das ist dasselbe Muster wie beim Abstraktions-Kollaps, nur von einer anderen Seite: Nicht KI macht Builder obsolet, sondern noch stärkere Vereinfachung. KI beschleunigt diesen Trend, weil sie den Weg zu direktem Code öffnet.

Was die Builder-Industrie stattdessen tun könnte

Das Naheliegende ist nicht, KI in den Builder zu integrieren. Das Naheliegende ist, den Builder als Ausgangspunkt für KI-generierten Standard-Code zu nutzen.

Konkret: Ein Builder, der KI-Output als sauberes HTML/CSS/JS exportiert und nicht als proprietäres JSON speichert, der Layouts in Standardformate übersetzt statt in plattformspezifische Strukturen, der KI als Designwerkzeug nutzt statt als UI-Automatisierer, hätte eine echte strategische Position in der KI-Ära.

Gutenberg, der native WordPress-Block-Editor, geht in diese Richtung. Blocks sind standardisierter als Elementor-Widgets, näher an HTML, besser für KI-Verarbeitung geeignet. Der Stack WordPress Core plus ACF plus KI-generierte Custom Block Templates hat strukturell mehr Zukunft als Elementor Pro plus KI-Plugin. Er ist performanter, wartbarer und von Sprachmodellen deutlich besser verstanden.

Das bedeutet nicht, dass jeder WordPress-Nutzer sofort migrieren sollte. Netzwerkeffekte sind real. Millionen von Elementor-Sites existieren, werden gepflegt und funktionieren. Diese Websites verschwinden nicht.

Aber wer heute eine neue Entscheidung trifft, ob für ein Kundenprojekt, für die eigene Infrastruktur oder für Investitionen in Builder-Expertise, sollte die Richtung kennen.

Das Fazit

Elementor und Divi haben für eine Dekade echten Mehrwert geliefert. Das ist keine Ironie. Das ist Tatsache. Millionen von Menschen haben Websites gebaut, die sie ohne diese Tools nicht hätten bauen können.

Aber ihre KI-Integration löst das falsche Problem. Sie verbessert den Prozess innerhalb einer Architektur, die für eine Welt gebaut wurde, in der Code unzugänglich war. Diese Welt existiert so nicht mehr.

KI in Elementor ist nicht schlecht. Es ist die bestmögliche Antwort auf eine Frage, die sich gerade verschiebt.

Die Frage war: "Wie baut jemand ohne Programmierkenntnisse eine professionelle Website?"

Die Antwort 2016 lautete: "Mit einem visuellen Builder."

Die Antwort 2026 lautet zunehmend: "Mit einem Prompt."

Das ist der Unterschied. Er ist groß.

Dieser Text ist Teil einer dreiteiligen Serie.
Teil 1: Der Abstraktionskollaps
Teil 3: Warum Webflow das richtige Problem falsch löst

Quellen: