WordPress Page Builder im Vergleich: Warum ich Divi und Elementor meide – und was ich stattdessen empfehle

Alle paar Minuten läuft sie wieder: die Werbung mit der fertigen Website in 30 Minuten. Schönes Template, glückliche Inhaberin, fertig.

Was die Werbung nicht zeigt: was passiert, wenn mehr Text in eine Box soll. Wenn das Layout auf dem Smartphone nicht stimmt. Wenn die erste Datenschutzanfrage kommt. Wenn die Seite nach drei Monaten bei Google nicht auftaucht.

Der Builder, mit dem eine Website gebaut wird, ist eine der wichtigsten Entscheidungen überhaupt. Die meisten treffen sie, ohne das zu wissen.

In diesem Artikel zeige ich dir, was ich nach über 20 Jahren Praxis davon halte – und warum ich bestimmte Tools klar empfehle und andere klar meide.

Das “30-Minuten-Website”-Versprechen – und was es verschweigt

Wix, Jimdo, der IONOS Website-Builder – sie alle versprechen dasselbe: einfach ein Template aussuchen, Texte eintragen, fertig.

Das funktioniert – solange man im Raster bleibt.

Ich habe Kund:innen begleitet, die es selbst versucht hatten. Ohne Basiswissen von HTML bleiben bestimmte Dinge schlicht unlösbar. Mehr Text in einer Box, die dann überläuft. Ein Element, das mobil nicht da ist, wo es sein soll. Eine zweite Spalte, die anders aussehen soll als die erste. An diesen Punkten endet das Versprechen – und beginnt die Frustration.

Das eigentliche Problem liegt aber tiefer: Diese Builder geben keinen Zugriff auf den Code. Was du nicht siehst, kannst du nicht kontrollieren. Und was du nicht kontrollierst, kann dir Probleme machen – bei der Ladezeit, beim SEO, bei der Barrierefreiheit, beim Datenschutz.

Kein Builder schreibt dir eine Datenschutzerklärung. Kein Builder macht automatisch Backups. Kein Builder stellt sicher, dass dein Cookie-Banner korrekt eingebunden ist.

Eine Website existiert nicht im rechtsfreien Raum. Das 30-Minuten-Versprechen endet, wenn der erste Kunde eine Datenschutzanfrage schickt.

Warum der Builder wichtiger ist als das Template

Das Template ist der erste Eindruck. Der Builder ist das Fundament.

Und das Fundament entscheidet über alles, was danach kommt: Ladezeit, Google-Ranking, Barrierefreiheit, Wartbarkeit. Schlechter Code verlangsamt die Seite – und Google misst das direkt als Rankingfaktor über die Core Web Vitals.

Sauberes, semantisches HTML hilft nicht nur Google, sondern auch Screenreadern, KI-Systemen und allen, die deine Website mit Einschränkungen besuchen. Was für Menschen mit Einschränkungen funktioniert, funktioniert auch für Maschinen – das ist kein Zufall, sondern gutes Handwerk.

👉 Mehr dazu: Barrierefreiheit im Web: Warum deine Website mehr Menschen ausschließt als du denkst

Die Builder im Überblick – meine ehrliche Einschätzung

Wix, Jimdo, IONOS – für ein ernsthaftes Business keine Basis

Niedrige Einstiegshürde, schnelle erste Ergebnisse – das ist das Versprechen. Und für einen ersten Eindruck reicht das manchmal.

Aber wer ohne HTML-Grundwissen in diese Builder einsteigt, stößt schnell an Grenzen, die sich nicht lösen lassen. Nicht weil man zu wenig versucht hat, sondern weil der Builder es schlicht nicht hergibt.

Das größte Problem: Lock-in. Wer wechseln will, fängt von vorne an. Alle Inhalte, alle Seiten, alle Strukturen müssen neu aufgebaut werden. Ich habe Kund:innen begleitet, die diesen Schritt gemacht haben – immer aus demselben Grund: Die Grenzen wurden sichtbar, meist genau dann, wenn das Business anfing zu wachsen.

Divi und Elementor – populär, aber mit Preis

Hier greift ein Muster, das ich regelmäßig beobachte: Weil etwas populär ist, wird es als erstes genutzt. Die meisten Tutorials gibt es für Elementor und Divi – also werden sie genutzt, oft von Laien, oft ohne tieferes Verständnis für das, was der Builder im Hintergrund tut.

Das gleiche passiert bei SEO-Plugins. Yoast war lange Standard – nicht weil es unbedingt das Beste war, sondern weil es am bekanntesten war. Die bunten Ampeln suggerieren: grün bedeutet gutes SEO. Dabei zeigen sie oft genau nicht die entscheidenden Faktoren – sie täuschen eher etwas vor.

Divi erzeugt Code, der mit unnötigen DIV-Ebenen überladen ist. Ladezeit leidet, semantisches HTML ist kaum umsetzbar, Barrierefreiheit wird schwierig. Ich hatte eine Kundin, deren Divi-Website bei Google kaum sichtbar war. Nach dem Relaunch mit sauberem Quelltext änderte sich das – nicht durch einen SEO-Trick, sondern weil Google endlich lesen konnte, was auf der Seite steht. Natürlich haben wir auch am Inhalt gedreht und Verbesserungen vorgenommen. Aber gutes HTML hilft dir definitiv für Sichtbarkeit. Divi 5 hat mittlerweile die Architektur modernisiert, aber das Grundproblem bleibt für viele bestehende Seiten.

Elementor kenne ich vor allem aus Kundenanfragen: Websites, die von Freelancern oder kleinen Agenturen erstellt wurden – und bei denen die Kund:innen danach auf sich allein gestellt waren. Der Plan war, die Seite selbst zu pflegen. In der Praxis war das oft frustrierend.

Elementor ist nicht in allen Punkten schlüssig. Abstände zwischen Elementen verstecken sich manchmal an Stellen, die man nicht erwartet. Eigenschaften tauchen in Bereichen auf, wo man sie nicht sucht. Wer kein HTML-Grundverständnis hat, kämpft – und selbst wer es hat, bleibt gelegentlich an Dingen hängen, die einfach nicht logisch sind.

Das Grundproblem dieser Builder: Sie bauen Funktionen ein, um HTML-Kenntnisse zu ersetzen. Das klingt hilfreich – führt aber dazu, dass man das Werkzeug benutzt, ohne zu verstehen, was es tut. Und das rächt sich spätestens beim nächsten Update oder beim ersten ernsthaften Layoutproblem.

Bricks Builder – sauberer Code, volle Kontrolle

Bricks nutze ich seit der Erstveröffentlichung. Das ist keine Modeerscheinung, sondern eine bewusste Entscheidung, die ich nie bereut habe.

Bricks schreibt sauberes, semantisches HTML. CSS und JavaScript werden nur geladen, wenn sie tatsächlich gebraucht werden. Barrierefreiheit lässt sich gezielt umsetzen. Die Core Web Vitals sind out-of-the-box deutlich besser als bei Elementor oder Divi.

Optisch ist Bricks noch näher an klassischen Buildern wie Elementor – wer von dort kommt, findet sich schneller zurecht als in Etch. Die Community ist groß, die Basis ausgereift, die Lifetime-Lizenz fair.

Die Lernkurve ist steiler als bei Elementor. CSS-Grundverständnis hilft – wer es nicht hat, wird anfangs kämpfen. Aber wer die Einarbeitung investiert, baut danach schnell, sauber und mit vollem Überblick über das, was er tut.

Etch – eine neue Ära für WordPress

Etch ist kein weiterer Page Builder. Es ist eine vollständige visuelle Entwicklungsumgebung – und sie leitet aus meiner Sicht eine neue Ära ein.

Von Kevin Geary entwickelt, dem Macher von Automatic CSS (ACSS) und Frames. Wer in der professionellen WordPress-Community unterwegs ist, kennt diese Tools – sie sind längst kein Geheimtipp mehr.

Der entscheidende Unterschied zu allen anderen Buildern: Etch speichert Inhalte als native Gutenberg-Blöcke. Kein Lock-in, kein proprietäres Format – die Inhalte gehören dir, auch wenn du den Builder irgendwann wechselst. Bei Divi, Elementor und selbst bei Bricks bist du in gewisser Weise an das Format des Builders gebunden. Bei Etch nicht.

Dazu kommt: direkter Zugriff auf den Quellcode, nahtlose ACSS-Integration, KI-Anbindung, rasante Entwicklungsgeschwindigkeit und eine außergewöhnlich aktive Community.

Ich arbeite bei 95 % meiner neuen Projekte mit Etch – für alle Arten von Seiten, von einfachen Unternehmenswebsites bis zu komplexen Projekten. Etch ist kein Tool für kleine Projekte, sondern mittlerweile ein vollwertiger Top-Builder.

Was mich besonders überzeugt: Etch bringt einem nebenbei HTML und CSS bei. Wer damit arbeitet, versteht nach einer Weile, wie das Web wirklich funktioniert. Das ist das Gegenteil von Buildern, die HTML-Kenntnisse ersetzen wollen.

Gutenberg – unterschätzt und zukunftssicher

Gutenberg ist der native WordPress-Editor – kein extra Plugin, kein extra Code, beste Performance out-of-the-box.

Ich nutze ihn für Beiträge und Ratgeber – also genau für das, wofür er am stärksten ist. Für Layouts und komplexe Seiten kommt Etch oder Bricks obendrauf. Aber für Content-first ist Gutenberg eine schlanke, zukunftssichere Basis – und er wird von WordPress-Core direkt weiterentwickelt.

ACSS – das Framework, das Bricks und Etch besser macht

Automatic CSS ist ein CSS-Framework, das ich bei Bricks und Etch gleichermaßen einsetze. Es standardisiert Farben, Abstände und Typografie – und sorgt dafür, dass das Design konsistent und wartungsfreundlich bleibt.

Für Einsteiger ist es zunächst ein zusätzliches Lernthema. Für professionelle Arbeit ist es nicht mehr wegzudenken. Der Hauptvorteil: Änderungen am Design lassen sich zentral steuern, ohne jede Seite einzeln anfassen zu müssen.

Was kein Builder für dich erledigt

Das muss klar gesagt werden:

Kein Builder ersetzt das Wissen über DSGVO und Datenschutz. Kein Builder macht automatisch Backups. Kein Builder stellt sicher, dass deine Website barrierefrei ist – er kann nur die technische Grundlage dafür liefern.

Eine Website ist ein komplexes Gebilde – auch ohne Programmierung braucht es Verständnis für das, was dahintersteckt.

Das 30-Minuten-Versprechen endet, wenn der erste Kunde eine Datenschutzanfrage schickt oder die Seite nach drei Monaten nicht bei Google auftaucht.

👉 Typische Fehler, die dabei entstehen: Warum deine Website keine Kunden bringt: 9 typische Fehler

Meine Empfehlung – je nach Situation

• Du willst professionell arbeiten und lernst gern: Etch mit ACSS – du baust schnell, sauber und verstehst dabei, was du tust
• Du willst eine ausgereifte Basis mit großer Community: Bricks – bewährt, stabil, sauberer Code seit Erstveröffentlichung
• Du hast Divi oder Elementor: Nicht sofort wechseln – aber beim nächsten Relaunch ernsthaft überdenken
• Du denkst über Wix, Jimdo oder IONOS nach: Investiere lieber von Anfang an in eine solide WordPress-Basis – der Umstieg später kostet mehr als der richtige Start

Wenn du unsicher bist, welcher Weg für deine Website der richtige ist – ich schaue mir das gerne gemeinsam mit dir an.