Page-Builder wie Elementor, WPBakery oder Divi machen das Bauen einfach und das Betreiben teuer: mehr Markup, mehr Skripte, Abhängigkeit von einem Hersteller und meist ein Dutzend Zusatz-Plugins. Der Blockeditor von WordPress kann heute das meiste davon selbst, wenn man ihm eigene Blöcke gibt und ihn für Redakteure einschränkt. Unsere eigene Website haben wir so gebaut: von 36 aktiven Plugins auf fünf, mit lokal gemessenen Lighthouse-Werten von 96 bis 98 für Performance und 100 für Barrierefreiheit. Hier steht, warum, was Redakteure davon haben und wann ein Page-Builder trotzdem die richtige Wahl ist.
Das Problem mit Elementor, WPBakery und Divi
Page-Builder lösen ein echtes Problem: Jemand ohne Programmierkenntnisse soll Seiten gestalten können. Der Preis dafür zeigt sich erst nach dem Launch, an vier Stellen.
- Markup. Ein Textabschnitt wird zu einem Stapel ineinander verschachtelter Container mit eigenen Klassen und Inline-Stilen. Für Suchmaschinen ist das Rauschen um den Inhalt, für Hilfstechnologien ein Hindernislauf. Barrierefreiheit lässt sich damit erreichen, aber gegen den Builder, nicht mit ihm.
- Ladezeit. Der Builder lädt sein eigenes CSS- und JavaScript-Gerüst auf jeder Seite, egal, ob die Seite es braucht. Dazu Icon-Schriften, jQuery, Animationsbibliotheken. Die Core Web Vitals leiden, und die Antwort ist meist ein weiteres Plugin: ein Cache, das die Symptome versteckt.
- Lock-in. Die Inhalte liegen nicht als Text in der Datenbank, sondern als Shortcodes oder als Datenstruktur des Builders. Schaltet man ihn ab, bleibt Zeichensalat. Ein Wechsel des Werkzeugs ist damit ein Neubau. Unsere alte Website hatte alle Inhalte in WPBakery-Shortcodes, wir wissen, wovon wir reden.
- Plugin-Flut. Der Builder bringt Erweiterungspakete mit, dazu kommen Formular-, Slider-, Popup-, Cache- und Security-Plugins, jedes mit eigenem Update-Rhythmus und eigenen Konflikten. Auf unserer alten Website waren es 36 aktive Plugins, darunter drei Security-Plugins parallel.
Fairerweise: Nicht jeder Builder ist gleich. Werkzeuge wie Bricks oder Oxygen erzeugen deutlich saubereres HTML als die klassischen drei. Die Abhängigkeit vom Hersteller und seiner Preispolitik bleibt aber auch dort.
Was der Blockeditor heute kann
Der Blockeditor gehört seit 2018 zum WordPress-Kern und hat sich seitdem in eine Richtung entwickelt, die viele nicht mitbekommen haben. Block-Themes bauen die ganze Website aus Blöcken, auch Kopf und Fuß. Über eine Konfigurationsdatei legt das Theme fest, welche Farben, Schriftgrößen und Abstände es überhaupt gibt, alles andere kann ein Redakteur nicht auswählen. Vorlagen fassen Blöcke zu wiederverwendbaren Abschnitten zusammen, synchronisierte Vorlagen ändern sich an einer Stelle für die ganze Website. Blöcke lassen sich sperren, sodass Struktur und Reihenfolge bleiben und nur der Inhalt bearbeitet wird. Und nicht benötigte Blöcke lassen sich aus dem Menü nehmen.
Der wichtigste Punkt ist unscheinbar: Der Inhalt liegt als lesbares HTML mit Kommentaren in der Datenbank. Ohne Editor, ohne Theme, ohne Plugin bleibt er lesbar. Es gibt keinen Hersteller, keine Lizenz, und die Weiterentwicklung fließt aus dem WordPress-Kern selbst.
Die Schwäche ist ebenso klar: Der Editor „von der Stange“ überfordert Redakteure. Zu viele Blöcke, zu viele Regler an Gruppen und Spalten, und mit etwas Mühe lässt sich jedes Design zerlegen. Roh ist der Blockeditor kein Page-Builder-Ersatz. Zugeschnitten ist er ein besserer.
Eigene Blöcke als Baukasten für Redakteure
Unsere Antwort war, jeden Abschnitt der Website als eigenen Block zu bauen. Seitenkopf mit Kurzantwort, Karten, Ablauf, „Wovon der Aufwand abhängt“, Vergleichstabelle, FAQ, Ansprechpartner, „Passt dazu“, CTA, der Redakteur klickt in den Text und schreibt, direkt im Layout, so wie es später aussieht. Es gibt keine Spalten, Abstände oder Farben einzustellen, weil die Blöcke das mitbringen. Für Sonderfälle gibt es einen flexiblen Abschnitt mit Zeilen und Spalten auf einem Zwölferraster, und jedes Element lässt sich mit ID, Klassen, Sichtbarkeit und Abständen versehen, das Prinzip, das Page-Builder-Nutzer kennen, nur mit unserem HTML.
Dazu kommen Seitenvorlagen: „Neue Leistungsseite“ legt alle Abschnitte in der richtigen Reihenfolge an, mit Hilfstexten in den Feldern. Team, Referenzen, Jobs und Glossar sind eigene Inhaltstypen mit einfachen Formularen; wer eine Person anlegt, hat sie überall verfügbar. Kopf, Fuß und Vorlagen können nur Administratoren ändern. Das Plus-Menü zeigt unsere Blöcke und ein Dutzend Standardblöcke, sonst nichts.
Die Grenze, ehrlich benannt: Ein völlig neuer Abschnittstyp, den es im Baukasten noch nicht gibt, braucht einmalig einen Entwickler. Das ist der Preis dafür, dass niemand das Design versehentlich zerstören kann. Für Unternehmen, die alle paar Wochen ein neues Layout ausprobieren wollen, ist das der falsche Ansatz. Für alle, die eine Website über Jahre pflegen wollen, ist es der richtige.
Das Ergebnis bei unserer eigenen Website
| Alte Website | Neue Website | |
|---|---|---|
| Aktive Plugins | 36 | 5: Rank Math, Contact Form 7, AKT Web Suite, Site-Plugin mit Blöcken und Inhaltstypen, ein kleiner Must-use-Helfer |
| Inhalte | WPBakery-Shortcodes in einem gekauften Theme | Blöcke in einem eigenen Block-Theme, lesbares HTML |
| Performance-Plugins | Mehrere, die sich gegenseitig im Weg standen | Keines, Haupt-Stylesheet minifiziert im Seitenkopf, Bilder als WebP mit srcset, kein jQuery im Frontend |
| Tracking | Mehrere Analytics-Werkzeuge | Matomo, cookielos, im Theme statt als Plugin |
| Lighthouse mobil, lokal gemessen | Vergleich folgt nach dem Go-live | Startseite: Performance 96, Barrierefreiheit 100, Best Practices 100, SEO 100. Leistungsseite: 98 / 100 / 100 / 100 |
Zu den Zahlen gehört eine Einschränkung: Lokal gemessen heißt ohne echtes Netzwerk, ohne Live-Server, ohne Cloudflare. Die Werte zeigen, was das Theme leistet, nicht, was Besucher erleben. Die Felddaten nach dem Go-live und den Vergleich mit der alten Website ergänzen wir im Anwendungsfall zum Relaunch, sobald sie vorliegen. Dass wir sie überhaupt veröffentlichen, ist Teil der Idee: Eine Agentur, die Ladezeit verkauft, muss selbst messbar sein.
Was das für Kunden bedeutet
- Übernahme bestehender Seiten. Texte und Bilder ziehen wir aus dem Builder heraus, die Struktur entsteht neu in Blöcken, jede alte Adresse bekommt eine Weiterleitung. Wie das ohne Rankingverlust geht, steht im Artikel Website-Relaunch ohne Rankingverlust. Redakteure brauchen eine kurze Einweisung, keine Schulungswoche.
- Wartung. Fünf Plugins statt dreißig heißt: weniger Updates, weniger Sicherheitslücken, weniger Konflikte, kürzere Prüfzeit bei jedem WordPress-Release. Das macht die Website-Wartung planbar.
- Kein Lock-in. Theme und Blöcke gehören dir. Jeder WordPress-Entwickler kann sie weiterpflegen, weil es normales WordPress ist, keine Hersteller-API, keine Lizenzverlängerung.
- Barrierefreiheit. Das Markup liegt in unserer Hand, also lassen sich die Anforderungen der WCAG im Theme anlegen statt nachträglich aufzusetzen. Für Unternehmen, die unter das BFSG fallen, ist das der einfachere Weg.
- Aufwand am Anfang. Eigene Blöcke kosten Entwicklungszeit, die ein Builder scheinbar spart. Das lohnt sich, wenn die Website mehrere Jahre leben und regelmäßig gepflegt werden soll. Für eine Website, die in einem Jahr ohnehin ersetzt wird, lohnt es sich nicht.
Wann ein Page-Builder trotzdem ok ist
Wir bauen ohne Page-Builder, aber wir raten nicht jedem davon ab. Es gibt Fälle, in denen er die vernünftige Wahl ist:
- Eine kleine Website mit wenigen Seiten, die jemand im Haus selbst gestaltet und bei der Ladezeit und Barrierefreiheit keine Verkaufsargumente sind.
- Ein Team, das einen Builder mit sauberer Ausgabe, Bricks, Oxygen, gut kennt und ihn diszipliniert einsetzt.
- Landingpages für Kampagnen, die nach ein paar Monaten wieder verschwinden.
- Eine bestehende Builder-Website, die ordentlich gepflegt ist. Oft reicht es, Bilder zu verkleinern, Plugins zu entschlacken und den Cache richtig einzustellen, ein Neubau ist nicht immer die Antwort.
Nicht ok ist ein Page-Builder aus unserer Sicht, wenn Ladezeit, Barrierefreiheit und Unabhängigkeit zum Geschäft gehören, wenn die Website länger als ein paar Jahre leben soll oder wenn die Plugin-Liste bereits die dreißig überschritten hat. Dann kostet der Builder jeden Monat mehr, als er am Anfang gespart hat.
Fazit
WordPress ohne Page-Builder heißt nicht WordPress ohne Baukasten. Der Blockeditor mit eigenen Blöcken ist ein Baukasten, nur einer, der unser HTML ausgibt, keine Lizenz hat und in fünf Jahren noch lesbar ist. Unsere Website ist der Beweis, mit allen Einschränkungen, die zu lokal gemessenen Zahlen gehören. Wenn du wissen willst, was das für deine Website bedeuten würde, ist die Seite Webentwicklung der richtige Einstieg; die Bestandsaufnahme einer bestehenden Builder-Website ist der übliche erste Schritt.
Häufige Fragen
Ist der Blockeditor ein vollwertiger Ersatz für Elementor?
Roh nicht: Der Editor von der Stange hat zu viele Blöcke und Regler und überfordert Redakteure. Mit eigenen Blöcken, festen Farben und Abständen und gesperrten Vorlagen wird er zu einem Baukasten, der sauberes HTML ausgibt. Ein völlig neuer Abschnittstyp braucht dann einmalig einen Entwickler.
Wird meine Website ohne Page-Builder schneller?
Meist ja, weil das CSS- und JavaScript-Gerüst des Builders wegfällt. Wie viel es bringt, hängt aber auch von Bildern, Hosting und den übrigen Plugins ab. Unsere eigenen Werte haben wir lokal gemessen; die Felddaten nach dem Go-live tragen wir im Anwendungsfall nach.
Kann ich meine Elementor- oder WPBakery-Seite umstellen lassen?
Ja. Texte und Bilder ziehen wir aus dem Builder heraus, die Struktur entsteht neu in Blöcken, und jede alte Adresse bekommt eine Weiterleitung. Der übliche Zeitpunkt ist ein Relaunch, weil der Umbau ohnehin fast ein Neubau ist.
Brauche ich ohne Page-Builder für jede Änderung einen Entwickler?
Nein. Texte, Bilder und neue Seiten aus vorhandenen Vorlagen pflegst du selbst im Editor. Einen Entwickler brauchst du erst, wenn ein neuer Abschnittstyp entstehen soll, den es im Baukasten noch nicht gibt.
Gehören mir Theme und Blöcke?
Ja. Es ist normales WordPress ohne Hersteller-Lizenz, und jeder WordPress-Entwickler kann es weiterpflegen. Eine Bindung wie bei einem Builder mit eigenen Shortcodes gibt es nicht.
Stand: September 2026, wir aktualisieren diesen Artikel, wenn sich Rechtslage oder Technik ändern.
