Im ersten Teil dieser kleinen Reihe ging es um die Grundsatzentscheidung für WordPress als System. Dieser Teil dreht sich um die Frage, die danach kommt: Womit baue ich die Seiten innerhalb von WordPress? Page Builder wie Elementor oder Divi versprechen, Webdesign einfach zu machen. Und sie halten einen Teil davon auch ein. Aber sie haben einen strukturellen Haken – und seit es den Block Editor gibt, brauchen wir sie eigentlich nicht mehr.
Webdesign einfach gemacht – Page Builder
Man muss Page Buildern nichts Böses unterstellen. Sie sind Kinder ihrer Zeit: Als WordPress noch ein klassischer Editor war, in dem man Inhalt schrieb, ohne genau zu wissen, wie die Seite am Ende aussieht, und Design faktisch nur mit Code möglich war, machten grafische Oberflächen absolut Sinn. Eine visuelle Ebene über das CMS legen, ziehen und schieben, sofort sehen, was passiert – das war ein echter Fortschritt.
Dann kam Gutenberg. Und mit dem Block Editor hat sich die Grundannahme der Page Builder erledigt: Ich bekomme heute im WordPress-Backend ein sehr gutes Bild davon, wie die Seite am Ende aussieht. Das visuelle Gestalten, das Page Builder einst exklusiv bot, ist Teil des Systems selbst geworden. Was von den Buildern übrig bleibt, ist im Kern eine Parallelstruktur – eine eigene Logik mit eigenen Containern, eigenen Widgets, eigenen Marktplätzen, die über das CMS gelegt wird. Man nutzt dann ein CMS, um faktisch ein anderes System zu betreiben. Das kostet Ressourcen, und es ist erfahrungsgemäß nicht das stabilste Setup.
Page Builder im Vergleich: Elementor – Divi – Beaver Builder
Untereinander gibt es durchaus bessere und schlechtere Vertreter. Die drei Großen im Kurzporträt:
Elementor ist der Marktleader – über zwölf Millionen Installationen, das mit Abstand größte Ökosystem mit eigenem Marktplatz und Tausenden Add-ons. Diese Masse ist seine eigentliche Stärke: So viele Menschen haben dort inzwischen Know-how und Hirnmasse hineingesteckt, dass wirklich vieles funktioniert. Die Kehrseite: ausufernde Feature-Flut, ständige Updates, Paywalls überall dort, wo man schnell etwas umsetzen will – und jede Menge Zusatz-CSS und JavaScript, die die Seite schwer machen. Nicht jedes Plugin ist mit jedem Page Builder kompatibel; gerade bei Elementor kann eine Erweiterung die ganze Seite ordentlich auf den Kopf stellen.
Divi ist eher ein komplettes Design-System als ein Plugin: Theme und Builder aus einer Hand, visuelles Inline-Editing, riesige Layout-Bibliothek, fähiger als der Rest. Dasselbe gilt für seine Schwächen: Divi setzt stark auf Shortcodes – deaktiviert man den Builder, bleibt eine Seite voller kaputter Shortcode-Schnipsel zurück. Wer Divi gegen Beaver Builder abwägt, wägt einen echten Trade-off ab: ein sehr fähiges, aber geschlossenes System gegen ein offeneres, stabileres.
Beaver Builder ist für mich der sympathischste der drei: bewusst konservativ, sauber gecodet, bekannt dafür, dass Updates selten etwas brechen, kooperiert brav mit WordPress core. Dafür kleiner: weniger Module, weniger Vorlagen, weniger Ökosystem – und auch hier bleibt die Parallelstruktur.
Preislich liegen alle drei im Abo-Modell: Elementor Pro startet bei rund 59 $ pro Jahr, Divi bei rund 89 $, Beaver Builder bei rund 99 $ – hinzu kommen bei Elementor erfahrungsgemäß die Add-on-Käufe, wenn man über die Basis hinaus will. Das ist nicht teuer im Verhältnis zum Nutzen. Die Frage ist nur: Welchen Nutzen braucht man 2026 noch?
Das Kernproblem: Speed, Lock-in, Wartbarkeit
Ladezeiten: Page Builder laden zusätzliches CSS und JavaScript, das die Seite schwerer macht. Unabhängige Benchmarks kommen immer wieder zum selben Ergebnis: Block-basierte Setups liefern deutlich bessere PageSpeed- und Core-Web-Vitals-Werte als Elementor- oder Divi-Seiten; dokumentierte Migrationen von Elementor auf GenerateBlocks brachten auf demselben Server Verbesserungen von gut 30 bis 40 Punkten. Eine WordPress-Seite mit Page Builder ohne Caching-Plugin oder serverseitiges Caching laufen zu lassen, kann eigentlich nur langsame Seiten erzeugen.
Lock-in: Hier schließt sich der Kreis zur Grundsatzentscheidung aus Teil 1. WordPress hat mich überzeugt, weil die Inhalte in der Datenbank liegen und das Drumherum austauschbar ist. Page Builder brechen genau dieses Versprechen: Sie betten Inhalte in eigene Container und Shortcode-Strukturen ein. Man hat eine WordPress-Seite – aber sie ist mit einer Parallellogik überzogen. Ein Wechsel des Themes oder der Plattform bedeutet erst, sämtliche Inhalte aus diesen Strukturen zu befreien. Ich habe Kundinnen und Kunden übernommen, die genau in diesem gefangenen Dilemma steckten – das vertraute Bild wie bei manchen Übersetzungs-Plugins, nur eine Ebene tiefer.
Wartbarkeit: Zwei Logs in einem System bedeuten doppelte Update-Risiken, doppelte Kompatibilitätsfragen. Nicht jedes Plugin verträgt sich mit jedem Builder. Das ist kein theoretisches Risiko, sondern etwas, das man bei jeder Übernahme einer Builder-Seite konkret vorfindet.
Die Alternative: GeneratePress + Block Editor
Bevor ich mich für GeneratePress entschieden habe, habe ich lange recherchiert. Die Frage war: Was gibt mir eine ähnliche Gestaltungserfahrung wie ein Page Builder, ist sauberer programmiert und stülpt keine Parallellogik über WordPress? Ich arbeite jetzt seit rund acht Jahren mit GeneratePress und GenerateBlocks – am Ende des Tages ist das schlicht ein Theme plus ein Plugin (GenerateBlocks), die mit WordPress koexistieren, statt es zu überziehen. Alles bleibt im Sinne von WordPress: sauberes CSS, keine Kompatibilitätsprobleme mit anderen Plugins, und ich habe fast alle Benefits, die ich von einem Page Builder erwarten würde – visuelles Gestalten im Editor, sofortiges Feedback, verschiebbare Blöcke, global steuerbare Styles.
Der Speed-Vorteil ist kein Laborwert, sondern Alltag. Ein Beispiel vom letzten Monat: Bei einer Kundenseite, die drei Monate live war und inzwischen ordentlich Inhalt hatte, bin ich erst nach drei Monaten daraufgekommen, dass wir gar kein Caching-Plugin installiert hatten. Weil es nicht nötig war. Die Seite lud und lief schlicht schnell – mit GeneratePress und GenerateBlocks, ohne Optimierungs-Trommelnfeuerwerk. Mit einem Page Builder wäre das undenkbar gewesen.
Update: WordPress und KI
Viele Page Builder implementieren inzwischen eigene KI-Tools – und schaffen sich damit teils neue Paywalls in Form von Token-Modellen. Ich bin einen anderen Weg gegangen: Mittels MCP (Model Context Protocol) habe ich mein go-to-KI-Tool direkt an WordPress angebunden und damit einen WordPress-Editor aus KI gemacht. Dank des sauberen Codings von GeneratePress und GenerateBlocks ist das problemlos möglich – die Block-Struktur ist maschinenlesbar, ohne dass eine Builder-Parallellogik dazwischensteht. WordPress selbst liefert inzwischen so viele gute Kernfunktionen, dass sich die Frage stellt, warum man überhaupt noch eine zusätzliche Schicht aufsetzen sollte. Ich arbeite trotzdem gern mit GeneratePress und GenerateBlocks – die Einstellungsmöglichkeiten kommen mir entgegen. Aber es ist eine Ergänzung auf WordPress‘ eigener Logik, kein Ersatz dafür.
Fazit
Page Builder waren eine gute Antwort auf ein Problem, das WordPress mit Gutenberg gelöst hat. Sie produzieren schwerere Seiten, bauen eine Parallellogik mit echtem Lock-in auf und kosten zusätzlich Geld für etwas, das der Block Editor heute nativ kann. Wer Geschwindigkeit, Stabilität und Unabhängigkeit will – also genau die Kriterien aus Teil 1 –, baut mit dem Block Editor und einem sauberen Theme wie GeneratePress. Und wer visuelles Gestalten mit KI-Unterstützung will, braucht dafür auch keinen Page Builder mehr.