Warum wir keine Pagebuilder bei WordPress-Projekten einsetzen
Für WordPress werden einige Pagebuilder angeboten und es kommen immer wieder neue Pagebuilder dazu. Wir haben uns aus verschiedensten Gründen dazu entschlossen, keine Pagebuilder bei unseren WordPress-Projekten einzusetzen. In diesem Beitrag beschreibe ich die Gründe. Im Fokus stehen dabei Performance, Sicherheit, Unabhängigkeit, Barrierefreiheit, Nähe zum WordPress‑Core und Kosten.
Was sind Pagebuilder?
Pagebuilder sind zusätzliche Tools für WordPress, die es ermöglichen, Seitenlayouts ohne Programmierkenntnisse zu gestalten. Bekannte Beispiele sind Elementor, Divi oder Beaver Builder. Pagebuilder bieten vorgefertigte Module für Texte, Bilder, Buttons oder Slider, die per Maus einfach platziert werden können.
Natürlich muss an dieser Stelle darauf verwiesen werden, dass es durchaus qualitative Unterschiede bei den verschiedenen Pagebuildern gibt. Da wir keine Pagebuilder verwenden, gehe ich aber an dieser Stelle nicht darauf ein.

Natürlich haben wir auch schon zu verschiedenen Zeitpunkten darüber nachgedacht, einen Pagebuilder einzusetzen. Ich kann mich gut daran erinnern, dass ich mir kurz nach der ersten Veröffentlichung des Block Editors (Dezember 2018 mit der Veröffentlichung von WordPress 5.0) Elementor angesehen habe. Der Block Editor war seinerzeit noch sehr beschränkt und teilweise auch fehlerhaft. Damals war es schon ziemlich beeindruckend, was man mit Elementor machen konnte.
Als wir vor Jahren angefangen haben, uns mit der Barrierefreiheit von Websites zu beschäftigen, kam das Thema auch immer mal wieder auf. In dem Zusammenhang haben wir uns vor ca. einem Jahr den Pagebuilder Bricks genauer angesehen. Dieser Pagebuilder ist durchaus interessant. Aber wir haben uns trotzdem entschlossen, weiterhin den Block Editor zu verwenden und das ist für uns auch gut so.
Bessere Performance
Pagebuilder erzeugen häufig sehr verschachtelten HTML‑Code, zahlreiche Inline‑Styles und zusätzliche Skripte. Das bläht jede Seite auf und verlangsamt Ladezeiten – besonders auf mobilen Geräten.
Mit dem Block‑Editor (Gutenberg) und schlanken Block‑Themes können wir deutlich saubereren Code ausgeben, weniger Assets laden und Caching sowie Performance‑Optimierung effizienter einsetzen, wobei wir häufig auf zusätzliche Cache-Plugins verzichten können. Suchmaschinen wie Google bewerten schnelle Websites besser, was sich positiv auf die Sichtbarkeit auswirkt.
Leider gibt es allgemein ein wenig Verwirrung: In der Regel wird der Block-Editor auch als Gutenberg bezeichnet. Das ist so nicht korrekt, weil es zusätzlich ein Gutenberg-Plugin gibt. Dieses Plugin bietet bestimmte Funktionen an, die man als experimentell betrachten kann. Daher sollte man das Plugin nicht auf Produktivseiten einsetzen. Der Block-Editor ist dagegen der Standard-Editor von WordPress und steht ab der Version 5.0 automatisch als Editor zur Verfügung. Das war nicht immer klar und (nicht nur) deswegen gibt es so viele negative Bewertungen für das Gutenberg-Plugin.
Mehr Sicherheit
Jedes zusätzliche Plugin vergrößert die potenzielle Angriffsfläche. Pagebuilder sind komplexe Erweiterungen mit tausenden Zeilen Code, Integrationen und eigenen Modulen – entsprechend häufig tauchen Sicherheitslücken auf. Plugins sind eine der häufigsten Angriffsflächen in WordPress.
Indem wir auf Pagebuilder verzichten und möglichst nah am Core bleiben, reduzieren wir das Risiko von Sicherheitslücken (Exploits), Konflikten nach Updates und Inkompatibilitäten mit anderen Plugins oder Server‑Konfigurationen.
Exploits sind kleine Programme, die Sicherheitslücken auf Ihrem Computer ausfindig machen und ausnutzen. Die eigentliche Schadsoftware, zum Beispiel Ransomware, wird meist erst später nachgeladen („Payload“).
Quelle: https://www.gdata.de/ratgeber/was-ist-eigentlich-ein-exploit
Unabhängigkeit und Zukunftssicherheit
Viele Pagebuilder binden Inhalte stark an ihre eigene Struktur (Shortcodes, proprietäre Blöcke, eigene Templates). Wechselt man später das Theme oder den Pagebuilder, bleibt oft ein „Shortcode‑Chaos“ zurück, das aufwendig bereinigt werden muss.
Wir setzen auf den Block‑Editor, der als Standard Editor bereits im „Lieferumfang“ von WordPress enthalten ist und viele Blöcke (Bilder, Galerien, Zitate, etc.) zur Verfügung stellt. Dadurch bleiben Inhalte auch in einigen Jahren nutzbar, können leichter migriert werden und sie sind nicht von einem bestimmten Hersteller oder Lizenzmodell abhängig.
Ein weiterer Vorteil besteht darin, dass bei Verwendung des Block Editors im Zusammenhang mit einem Block Theme wie Twenty Twenty-Five später ein Relaunch wesentlich unproblematischer ist und weniger Zeit erfordert. Das vermindert die Kosten für den Kunden.
Ein Relaunch einer Website, die mit einem Pagebuilder erstellt wurde, ist in vielen Fällen fast unmöglich oder sehr aufwendig. In diesen Fällen muss man die Website in der Regel komplett neu erstellen.
Ein WordPress-Relaunch bedeutet die umfassende Überarbeitung einer bestehenden Website. Dabei werden Design, Struktur, Funktionen und oft auch Inhalte modernisiert, um aktuelle Standards, bessere Nutzererfahrung und optimierte Performance zu erreichen.
Typischerweise umfasst er ein neues (Block-)Theme, angepasste Templates, verbesserte Barrierefreiheit (WCAG) und SEO-Optimierungen wie Redirects für alte URLs. Bestehende Inhalte werden analysiert, bereinigt oder migriert.
Bessere Barrierefreiheit
Barrierefreiheit ist abhängig von dem verwendeten Pagebuildern nicht immer oder gar nicht sicherzustellen, weil sie häufig:
- komplexe, verschachtelte DOM‑Strukturen erzeugen
- ARIA‑Attribute und semantische Elemente nur teilweise unterstützen
- Widgets mit Tastatur oder Screenreader schlecht bedienbar machen
Mit Core‑Blöcken und sorgfältig ausgewählten, geprüften Erweiterungen können wir semantisch korrekten HTML‑Code, sinnvolle Überschriftenhierarchien, ausreichende Kontraste und fokussierbare Bedienelemente deutlich besser kontrollieren. Das erleichtert die Einhaltung von WCAG/BITV und reduziert Nachbesserungsaufwand. Aber auch der Block Editor bietet noch nicht alle Möglichkeiten, um eine Website barrierefrei zu erstellen. In dem Fall verwenden wir beispielsweise ein Plugin wie Attributes for Blocks. Ein weiteres Plugin in dem Zusammenhang ist das Plugin WP Accessibility. WP Accessibility fügt eine Reihe hilfreicher Barrierefreiheitsfunktionen mit minimalem Einrichtungsaufwand oder Expertenwissen hinzu.
Nähe zum WordPress‑Core
Der WordPress‑Core (Block‑Editor, Site‑Editor, Theme.json) wird kontinuierlich weiterentwickelt. Viele Funktionen, die früher nur Pagebuilder boten, sind heute direkt im System vorhanden (Patterns, globale Stile, Template‑Teile).
Wenn wir auf diesen Core‑Funktionsumfang setzen, profitieren wir automatisch von zukünftigen Verbesserungen, ohne auf große Drittanbieter‑Updates warten zu müssen. Das verringert Abhängigkeiten und sorgt für eine konsistente Erstellung von Beiträgen und Seiten mit den aktuell vorhandenen Blöcken. Bei jedem Update kommen weitere Blöcke hinzu, wie z. B. der Akkordeon-Block bei WordPress 6.9 oder Breadcrumbs-Block bei WordPress 7.0. Außerdem gibt es häufig Verbesserungen hinsichtlich Funktionsumfang bei den vorhandenen Blöcken, wie z. B. die Lightbox beim Galerie-Box in WordPress 7.0.
Transparentere und geringere Kosten
Bei Pagebuildern muss man gewisse Dinge berücksichtigen:
- Lizenzkosten (jährlich wiederkehrend)
- Zusatz‑Addons für spezielle Module
- höheren Pflegeaufwand bei Updates und Fehlerbehebungen
Durch den Verzicht auf Pagebuilder reduzieren wir die Anzahl kostenpflichtiger Lizenzen, minimieren Support‑Aufwand bei Update‑Konflikten und sparen Zeit bei Wartung und Optimierung. Das macht Projekte kalkulierbarer – sowohl in der Entwicklung als auch im laufenden Betrieb. Das macht sich letztendlich auch für Kunden bezahlt, weil die Kosten für Lizenzen nicht auf die Wartungskosten aufgeschlagen werden müssen. Die Wartung ist durch den Verzicht auf Pagebuilder nicht so aufwendig. Das macht sich bei den Kosten für die Wartung bemerkbar.
Pagebuilder – die Lizenz zum Austoben?
Selbstverständlich muss jede(r) für sich entscheiden, ob sie oder er einen Pagebuilder einsetzen möchte. Als Moderator im deutschsprachigen WordPress-Forum habe ich schon häufig verzweifelte User erlebt, die aus welchen Gründen auch immer ein Problem mit ihrer Website hatten, die mit einem Pagebuilder erstellt wurde. Bei kostenpflichtigen Pagebuildern oder allgemein auch bei kostenpflichtigen Plugins müssen wir auf den Support der Entwickler verweisen, weil uns diese kostenpflichtigen Pagebuilder oder Plugins nicht zur Verfügung stehen.
Ich erlebe auch häufiger, dass sich die Entwickler von WordPress-Websites mit Pagebuildern z. B. bei Animationen „austoben“, d. h. alles dreht sich, alles bewegt sich. Ob damit die Entwickler deutlich machen wollen, was sie so alles drauf haben, entzieht sich meiner Kenntnis. Damit will man offenbar die Kunden beeindrucken. Leider wissen die Kunden aber in der Regel nicht, dass diese Dinge nicht nur einen negativen Einfluss auf die Performance haben können, sondern insbesondere auch einen negativen Einfluss auf die Barrierefreiheit einer Website haben. Auch wenn eine Website rechtlich nicht barrierefrei sein muss, achten wir bei der Entwicklung von Websites sehr darauf, möglichst viele Dinge barrierefrei umzusetzen. Das funktioniert mit dem Block Editor und Block Themes ausgesprochen gut, weil Block Themes wie Twenty Twenty-Five oder Olli bereits barrierefrei sind. Eine Liste mit „accessibility ready“ (also auf Barrierefreiheit geprüften) Themes gibt es übrigens im WordPress Repository.
Weitere Vorteile
Sauberere Codebasis und Wartbarkeit
Entwickler können gezielter eingreifen, weil Templates, Styles und Funktionen klar strukturiert sind. Das erleichtert individuelle Anpassungen, Debugging und langfristige Wartung.
Bessere Kompatibilität mit Plugins
Viele Plugins – insbesondere für E‑Commerce (Shop), Formulare oder Mehrsprachigkeit – sind primär auf den Core‑Editor ausgelegt. Ohne Pagebuilder reduzieren sich Konflikte.
Konsistenteres Design
Mit globalen Stilen und Block‑Patterns lassen sich mit dem Block Editor wiederkehrende Layouts definieren, die User einfach nutzen können, ohne das Design „kaputtzuklicken“. Das Ergebnis sind konsistente, markenkonforme Seiten.
Performance
Remkus de Vries hat in seinem äußerst interessanten Beitrag ausführlich erläutert, wie es mit der Performance bei Pagebuildern aussieht.
Fazit
Wir nutzen WordPress schon seit einigen Jahren mit dem Block‑Editor und Block‑Themes wie Twenty Twenty-Five, Ollie oder unserem eigenen Block Theme Circles WP. So entstehen Websites, die schnell, sicher, (möglichst) barrierefrei, kosteneffizient und langfristig gut wartbar sind. Dabei verzichten wir gerne auf übermäßige Animationen.
Wie seht ihr das? – Wir freuen uns sehr über eure Kommentare zu diesem Beitrag.
Weitere Beiträge zum Thema (Block Neueste Beiträge)
- Buch: Barrierefreie Websites
- News aus dem WordPress-Universum – 4/2026
- STRG + K – Der wichtigste Shortcut in WordPress 7.0
- Overlay-Tools für Barrierefreiheit? – keine gute Idee
- Warum wir keine Pagebuilder bei WordPress einsetzen
Wir freuen uns über eine Kontaktaufnahme
Was hältst du davon?
Wir hoffen, dieser Beitrag hat dir gefallen und wir würden uns über einen Kommentar freuen. Auch über Erweiterungen, Korrekturen, Hinweise oder sonstige Anmerkungen freuen wir uns sehr.
Newsletter: Wenn du über unsere neuesten Beiträge und Neuigkeiten rund um WordPress informiert werden möchtest, kannst du dich gerne bei unserem kostenlosen Newsletter anmelden. Hier die bisher versendeten Newsletter
Blog: Auf der folgenden Seite findest du weitere interessante Beiträge sortiert nach Kategorien und Schlagwörtern.

Schreibe einen Kommentar