Wie die WordPress-Builder-Industrie gerade antwortet, ohne die Frage verstanden zu haben

Elementor hat 12 Millionen aktive Installationen. Divi läuft auf weiteren Millionen. Zusammen dominieren Elementor und Divi über 70% des WordPress-Page-Builder-Markts, und auf 64% aller WordPress-Sites läuft irgendein Builder (WPBeginner, 2025). Das ist eine industrielle Größenordnung.

Jetzt haben beide KI. Elementor AI generiert Text, Bilder und Code. Divi AI baut Layouts auf Prompt-Basis. Die Pressemitteilungen klangen gut.

Das Problem ist nicht die Ausführung. Das Problem ist die Architektur.

Was Elementor im Hintergrund tut

Wer nie hinter die Oberfläche eines Page Builders geschaut hat, kennt diesen Teil nicht. Also schauen wir.

Wenn ein Nutzer in Elementor eine Seite baut, speichert WordPress das Ergebnis nicht nur als HTML. Der eigentliche Elementor-Datensatz landet als serialisierter JSON-String im Metafeld _elementor_data der Tabelle wp_postmeta. Dieser String beschreibt, welche Widgets in welcher Reihenfolge mit welchen Parametern platziert wurden. Er sieht in etwa so aus:

[{"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: