Page-Builder wie Elementor: Chance oder Risiko?

Am 19. August 2026 veröffentlichte Elementor ein Update. Wer es nicht sofort einspielte, hatte ein Problem: In Elementor Pro klaffte eine kritische Sicherheitslücke, über die Angreifer ohne jede Anmeldung PHP-Dateien auf den Server laden und die komplette Website übernehmen konnten. Innerhalb weniger Tage zählte der Sicherheitsdienst Wordfence fast 200.000 Angriffsversuche. Betroffen: ein Plugin mit über sechs Millionen aktiven Installationen.

Für kleine Agenturen ist das ein unbequemer Moment. Viele haben halbe Kundenportfolios auf Page-Builder gebaut, weil sie schnell, visuell und ohne tiefes Code-Wissen zu bedienen sind. Der Vorfall ist kein Grund zur Panik – aber ein guter Anlass, die Rechnung einmal ehrlich aufzumachen: Was gewinnst du mit einem Page-Builder, und was zahlst du dafür?

Page-Builder wie Elementor: der Reiz und die Rechnung

Page-Builder wie Elementor, Divi oder WPBakery haben die WordPress-Welt verändert. Statt Themes zu programmieren, ziehst du Bausteine per Drag-and-drop zusammen und siehst das Ergebnis sofort. Der Reiz ist real: schnellere Umsetzung, direkte Kontrolle über das Layout und die Möglichkeit, dass auch der Kunde später kleinere Änderungen selbst vornimmt.

Wie dominant diese Werkzeuge sind, zeigen die Zahlen. Elementor läuft laut Marktdaten von BuiltWith auf rund 13 Prozent aller WordPress-Websites und hält damit etwa die Hälfte des Page-Builder-Markts – vor Divi und WPBakery. Über zehn Millionen aktive Installationen weist allein das kostenlose Elementor im offiziellen Plugin-Verzeichnis aus. Rechnet man WordPress' Anteil am gesamten Web ein, läuft geschätzt jede zwanzigste Website weltweit auf Elementor. Diese Verbreitung ist der Grund, warum eine einzelne Lücke wie die vom August so viele Seiten auf einen Schlag angreifbar macht – und warum sie sich für Angreifer lohnt.

Die Sicherheitsrechnung: mehr Code, mehr Angriffsfläche

Der Kern des Problems ist strukturell. Jedes Plugin, das du installierst, ist fremder Code auf dem Server deines Kunden – und damit potenzielle Angriffsfläche. Page-Builder sind dabei keine kleinen Plugins, sondern umfangreiche Systeme, oft ergänzt um ein Ökosystem an Zusatz-Add-ons für Formulare, Slider oder Popups. Jede dieser Erweiterungen vergrößert die Fläche weiter.

Die Statistik untermauert das. Laut dem State-of-WordPress-Security-Bericht von Patchstack entfielen 96 Prozent aller gemeldeten Schwachstellen auf Plugins – Core und Themes machten zusammen nur 4 Prozent aus. 2024 wurden fast 8.000 neue Schwachstellen dokumentiert, ein Plus von 34 Prozent gegenüber dem Vorjahr, im Schnitt 22 pro Tag. Besonders unangenehm: 43 Prozent der Lücken ließen sich ohne Anmeldung ausnutzen – genau die Kategorie, in die auch der Elementor-Vorfall fällt. Und ein Drittel der Schwachstellen war zum Zeitpunkt der Veröffentlichung noch nicht gepatcht.

Der konkrete Fall macht das greifbar. Die Lücke (geführt als CVE-2026-32475, von Wordfence als kritisch mit dem Höchstwert 9,8 eingestuft) betraf alle Versionen bis 4.2.1 und ließ sich nur ausnutzen, wenn eine Seite ein veröffentlichtes Elementor-Formular mit Datei-Upload-Feld enthielt. Ein Detail, das zeigt, wie schwer Risiken einzuschätzen sind: Nicht jede Elementor-Seite war verwundbar, aber welche genau, wusste ohne Prüfung kaum jemand. Wer den Notfall im Ernstfall beherrschen will, muss zuerst wissen, was überhaupt auf den Seiten läuft.

Praktisch heißt das: Du brauchst einen Überblick, welche Kundenseiten welchen Builder in welcher Version einsetzen, und einen Prozess, der kritische Updates in Stunden statt Wochen einspielt. Der Elementor-Fall zeigte das Zeitfenster überdeutlich – zwischen Patch und massenhaften Angriffen lagen nur Tage. Automatische Updates für sicherheitskritische Plugins, ein Monitoring, das Alarm schlägt, und regelmäßige Backups sind kein Luxus, sondern die Mindestausstattung, sobald ein Page-Builder im Spiel ist.

Die Performance-Rechnung: Komfort kostet Ladezeit

Der zweite Preis ist Geschwindigkeit. Page-Builder erzeugen ihr flexibles Layout über zusätzliche HTML-Verschachtelung sowie eigenes CSS und JavaScript, das mitgeladen werden muss – auch für Funktionen, die eine konkrete Seite gar nicht nutzt. Das Ergebnis sind schwerere Seiten, mehr Anfragen und eine trägere Darstellung, besonders auf Mobilgeräten.

Das ist kein Randthema. Die Ladezeit fließt über die Core Web Vitals in die Google-Bewertung ein, und langsame Seiten kosten Conversions. Elementor hat in neueren Versionen spürbar an der Performance gearbeitet, und mit sauberer Konfiguration, Caching und dem Verzicht auf überflüssige Add-ons lässt sich viel herausholen. Aber die Grundregel bleibt: Ein Page-Builder ist selten die schnellste Lösung, und wer maximale Performance braucht, zahlt beim Komfort. Wie du an den entscheidenden Stellschrauben drehst, zeigt unser Leitfaden zu den Core Web Vitals.

Der Lock-in: Wem gehört das Layout?

Der am wenigsten beachtete Preis ist die Abhängigkeit. Inhalte, die in Elementor gebaut sind, stecken in dessen eigenem Format. Deaktivierst du das Plugin, bleibt an vielen Stellen nicht der schöne Aufbau übrig, sondern ein Wust aus Shortcodes und unformatiertem Text. Ein Wechsel des Page-Builders oder ein Umzug auf ein schlankes Theme ist damit kein Knopfdruck, sondern oft ein Neuaufbau.

Für dich als Agentur hat das zwei Seiten. Der Lock-in bindet den Kunden – solange die Zusammenarbeit gut läuft, ist das bequem. Aber er bindet auch dich: an ein Produkt, dessen Preismodell, Sicherheitsdisziplin und Fortbestand du nicht kontrollierst. Wer sein halbes Portfolio auf ein einziges Plugin stützt, macht sich von dessen Herstellern abhängig – ein Risiko, das im weiteren Sinne zur Verwundbarkeit über die Software-Lieferkette gehört.

Die Alternative heißt oft: weniger

Bevor du reflexhaft zum Page-Builder greifst, lohnt der Blick auf das, was WordPress inzwischen selbst mitbringt. Der native Block-Editor hat in den letzten Jahren stark aufgeholt: Mit Block-Themes, dem Full-Site-Editing und wiederverwendbaren Block-Mustern lassen sich heute Layouts bauen, für die man früher zwingend ein Zusatz-Plugin brauchte – ohne dessen Code-Ballast und ohne dessen zusätzliche Angriffsfläche. Für viele Standard-Unternehmensseiten reicht das völlig aus.

Der Vorteil ist doppelt. Erstens bleibt der Inhalt im WordPress-eigenen Format, was das Lock-in-Problem entschärft: Deaktivierst du ein Block-Theme, zerfällt die Seite nicht in Shortcode-Reste. Zweitens ist weniger fremder Code fast immer die sicherere und schnellere Wahl. Wer eine schlanke, langlebige Seite bauen will, fährt mit einem gut gewählten Block-Theme und einer Handvoll bewusst ausgewählter Plugins oft besser als mit einem schweren Builder plus Add-on-Zoo.

Das heißt nicht, dass der Block-Editor jeden Page-Builder ersetzt – bei komplexen, pixelgenauen Designs oder wenn ein Kunde die gewohnte Drag-and-drop-Oberfläche ausdrücklich will, spielt ein Builder weiter seine Stärken aus. Aber die Frage sollte lauten: Brauche ich für dieses Projekt wirklich das schwere Werkzeug, oder tut es das leichte auch? Diese Frage ehrlich zu stellen, ist ein Qualitätsmerkmal – und spart deinem Kunden auf Dauer Wartungsaufwand.

Wann sich ein Page-Builder lohnt – und wann nicht

Nichts davon heißt, Page-Builder wären schlecht. Sie sind ein Werkzeug mit klaren Stärken und klaren Kosten, und die Kunst liegt in der bewussten Wahl. Für eine überschaubare Unternehmenswebsite, bei der Tempo in der Umsetzung, einfache Pflege durch den Kunden und ein knappes Budget im Vordergrund stehen, ist ein Page-Builder oft die richtige, wirtschaftliche Entscheidung. Der Kunde kann später selbst Texte tauschen, und du hast schneller ausgeliefert.

Zurückhaltender solltest du sein, wenn maximale Ladegeschwindigkeit geschäftskritisch ist, wenn eine Seite auf Dauer angelegt ist und über Jahre unabhängig bleiben soll, oder wenn viele identisch aufgebaute Seiten eher nach einem sauberen, individuell entwickelten Theme verlangen. Und unabhängig von der Entscheidung gilt: Ein Page-Builder verlangt Wartungsdisziplin. Updates gehören zeitnah eingespielt, Add-ons regelmäßig ausgemistet, unnötige Funktionen deaktiviert. Genau das ist der Kern eines belastbaren WordPress-Wartungsvertrags – und der Elementor-Vorfall vom August ist das beste Verkaufsargument dafür, warum Kunden ihn brauchen.

Fazit

Der Elementor-Vorfall im September 2026 ist keine Abrechnung mit Page-Buildern, sondern eine Erinnerung an ihren Preis. Sie kaufen Tempo und Komfort – bezahlt wird mit einer größeren Angriffsfläche, mehr Ladegewicht und einer Abhängigkeit, die schwer rückgängig zu machen ist. Für kleine Agenturen ist die Lehre nicht „nie wieder Elementor", sondern die bewusste Entscheidung pro Projekt: Passt das Werkzeug zum Ziel, und ist die Wartung sichergestellt? Wer diese Rechnung offen aufmacht, statt den Builder reflexhaft auf jede Seite zu setzen, baut sicherere, schnellere Kundenseiten – und kann im Ernstfall erklären, warum er sich so entschieden hat.