WordPress-Editoren: Ein Leitfaden für Admins

Neulich bei einem Gespräch mit befreundeten IT-Admins (ich bin Screen-Designer) kamen wir auf das Thema WordPress. Dabei fiel der Satz“ man benutze heutzutage Gutenberg Blocks, weil das modern ist“. Ich wollte zu dem Zeitpunkt nicht einfach den Spruch „warum nicht jemand fragen der sich damit auskennt“ bringen und habe beschlossen, die verschiedenen Ansätze und Ziele, in und mit WordPress zu arbeiten, zu analysieren.

Und wie so oft, die Realität ist komplizierter als „Neu=Besser“, denn es kommt drauf an.

Es gibt im Screen-Design eine feste Regel: Ein Interface, oder ein Werkzeug, muss zu den Menschen passen, die es benutzen sollen. Wenig bis kein Lernaufwand, geringstmögliche Komplexität. Keep it straight an simple.

Dieser Artikel richtet sich daher an Administratoren, die WordPress für andere betreiben: Für Vereine, Abteilungen, Redaktionen, kleine Organisationen und diese Partei. Keine Webentwickler, keine Admins, keine Nerds werden Inhalte erstellen, sondern „User“ die eine Website pflegen, nicht bauen, und die keine Energie haben, sich in ein Werkzeug mit Schulungen lange einzulernen.

Welcher Editor passt zu den Menschen, die die Website später täglich benutzen?

Die Entscheidung, welcher Editor eingesetzt wird, fällt meistens einmal und gilt dann lange. Sie bestimmt, wie viel Schulung die Endnutzer brauchen, wie stabil das Corporate Design bleibt, wie abhängig man von einem Anbieter wird, und wie viel Wartungsaufwand der Administrator dauerhaft einplanen muss. All das steht selten im Vordergrund, wenn jemand mit einem frisch installierten Page Builder wirbt. Es sollte aber.

Vier Ansätze werden hier verglichen: der klassische Editor mit Design-Plugins, Gutenberg mit Block-Bibliotheken, Page Builder wie Elementor oder Divi, und Bricks als Option für Entwickler.

Vorab: Das Plugin-Risiko

Plugins werden von externen Entwicklern gepflegt, nicht vom WordPress-Core-Team. Wer ein Plugin einsetzt, geht eine Abhängigkeit ein, auf unbestimmte Zeit. Wird ein Plugin nicht mehr weiterentwickelt, wird es irgendwann inkompatibel. Oder es enthält Sicherheitslücken, die niemand mehr schließt.

Sicherheitslücken in verbreiteten Plugins sind kein theoretisches Szenario. Sie sind ein reales Angriffsziel, und Patches erscheinen manchmal spät. Je mehr Plugins im Einsatz sind, desto größer die Angriffsfläche, desto höher der Aufwand für den Administrator, der Updates verfolgen, testen und einspielen muss. Das gehört zur Betriebsrealität von WordPress, und sollte bei der Editor-Wahl von Anfang an eingerechnet werden.

Der Classic Editor (TinyMCE) + Design-Plugin

Der klassische Editor ist das, was WordPress vor 2018 war: eine schlichte Textverarbeitung im Browser. Fett, kursiv, Links, Bilder, Absätze, Ausrichtung, Aufzählung etc. wie man es aus einer Textverarbeitung kennt. Das Layout kommt aus dem Theme, das der Administrator einmalig einrichtet. Wer mehr Gestaltungsmöglichkeiten braucht, findet ein breites Ökosystem an Design-Plugins, deren Basisversionen reichen für die meisten Fälle aus und sind kostenlos.

Redaktionsalltag: Das Interface ist selbsterklärend für jeden, der Word oder E-Mail kennt. Eine oder zwei kurze Schulungsstunden reichen: Beitrag anlegen, Bild einfügen, verlinken, das war es. Wer das System nur gelegentlich benutzt und nach Monaten Pause wieder einsteigt, findet sich sofort zurecht. Es gibt kaum etwas zu vergessen, weil es kaum etwas gibt was nicht bekannt ist. Für Endnutzer ohne Weberfahrung ist das der sanfteste und am wenigsten frustrierende Einstieg.

Wissensabhängigkeit: Besteht praktisch nicht, allenfalls interne regeln darüber, wie Überschriften, Absätze oder Aufzählungen zu formatieren sind oder wie Bilder eingefügt werden (rechtsbündig, mit und ohne Textfluss etc.)

Textimport: Neben der visuellen Ansicht mit den oben genannten Möglichkeiten gibt es eine reine Textansicht, in der Inhalte als sauberer Text über die Zwischenablage (Copy & Paste) einfügt werden können. Hier werden keine Formatierungen aus Word, Outlook oder Google Docs übernommen, es ist vollkommen problemlos.

Für Nutzende, die regelmäßig aus anderen Programmen kopieren, ist das ein erheblicher praktischer Vorteil gegenüber allen anderen Ansätzen. Nach dem Einfügen wechselt man wieder in die visuelle Ansicht – und kann dann im Rahmen des Templates gestalten.

Gast- und externer Zugriff: Das Interface bietet kaum Möglichkeiten, etwas außerhalb des eigenen Beitrags zu verändern. Wer wechselnde externe Personen Inhalte beisteuern lässt, macht hier die wenigsten unliebsamen Erfahrungen.

Mehrsprachigkeit: Mit WPML oder Polylang funktioniert der klassische Editor reibungslos. Übersetzungen werden als separate Beiträge angelegt, klar strukturiert, ohne Überraschungen.

Barrierefreiheit: Das Markup ist sauberes, semantisches HTML, vorausgesetzt, der Redakteur formatiert nicht mit wilden Inline-Styles (was nicht zu empfehlen ist). Für Organisationen unter der Barrierefreiheitspflicht nach dem Barrierefreiheitsstärkungsgesetz (BFSG) ist das ein Vorteil: Das HTML bleibt so, wie der Administrator es vorgesehen hat.

Design-Konsistenz: Hoch, nicht weil die Redakteure so diszipliniert sind, sondern weil sie gar keinen Zugriff auf das Design haben. Das Theme bestimmt, wie alles aussieht. Was man nicht anfassen kann, kann man nicht zerschießen.

Kosten: Gering bis null. TinyMCE ist integriert, die meisten Design-Plugins in der Basisversion kostenlos. Das Plugin-Risiko ist überschaubar, solange man sich auf wenige, etablierte, aktiv gepflegte Plugins beschränkt. Hier empfiehlt es sich genau hinzusehne, es gibt einige auf den Verkauf von Premium optimierte Plug-ins.

Wechselaufwand: Niedrig. Inhalte liegen als sauberer HTML-Text in der Datenbank, ohne proprietäre Markup-Strukturen. Lock-in entsteht allenfalls durch Shortcodes einzelner Plugins, werden diese entfernt, bleibt unlesbarer Code im Text stehen. Das ist der einzige echte Fallstrick.

Einschränkung: Wer pro Seite unterschiedliche Layouts will, braucht Hilfe von erfahrenen Admins. Das Template muss vorab gebaut sein. Spontane Layoutänderungen durch den Endnutzer sind nicht vorgesehen, was, je nach Perspektive, ein Nachteil oder ein Vorteil ist.

2. Gutenberg + Block-Bibliothek (z.B. Kadence Blocks, Spectra)

Seit WordPress 5.0 (2018) ist Gutenberg der Standardeditor. Inhalte werden als einzelne Blöcke erfasst: Absatz, Überschrift, Bild, Zitat, Spalte, Schaltfläche. Ohne Erweiterungen ist das für den praktischen Einsatz zu wenig. Sinnvoll wird Gutenberg erst in Kombination mit einer Block-Bibliothek wie Kadence Blocks oder Spectra, die Akkordeons, Preistabellen, erweiterte Spalten und weitere Elemente hinzufügt. Der Funktionsumfang nähert sich damit einem Page Builder an, das Grundprinzip bleibt dasselbe.

Redaktionsalltag: Mehr Möglichkeiten bedeuten mehr Entscheidungen für den Redakteur, und damit mehr Potenzial für Fehler. Die Einführungsschulung wird aufwendiger, realistisch ein halber Tag plus Übungszeit. Wer das System regelmäßig benutzt, gewöhnt sich daran. Wer es nur alle paar Wochen öffnet, fängt jedes Mal ein Stück weit von vorne an. Die Blocklogik ist nicht so selbstverständlich, dass man sie nach längerer Pause intuitiv wiederfindet. Das ist kein Vorwurf an die Nutzer, sondern ein strukturelles Problem, das bei der Planung einkalkuliert werden muss.

Wissensabhängigkeit: Was passiert, wenn die Person, die sich mit der Block-Bibliothek auskennt, krank wird oder die Organisation verlässt? Bei einer komplexen Block-Struktur hängt das Wissen, wie eine Seite aufgebaut ist und wie man sie sicher bearbeitet, oft an einer einzigen Person. Eine Einarbeitungsdokumentation ist hier kein Luxus, sondern Betriebsvoraussetzung und muss einberechnet werden.

Textimport: Eigene Blocktypen der Bibliothek werden beim Einfügen von extern nicht erkannt. Formatierungen aus Word oder andern Quellen können zu kaputten oder falsch dargestellten Blöcken führen. Wer regelmäßig Inhalte aus anderen Quellen übernimmt, sollte das vor der Entscheidung konkret testen, nicht danach feststellen.

Gastautoren und externer Zugriff: Mehr Risiko als beim klassischen Editor. Wer nicht mit der Blocklogik vertraut ist, kann versehentlich Seitenelemente verschieben oder löschen. Rollentrennung und klare Vorgaben durch den Administrator sind notwendig.

Barrierefreiheit: Abhängig von der gewählten Bibliothek. Nicht alle Block-Plugins erzeugen barrierefreies HTML. Wer BFSG-Konformität anstrebt, muss das für die konkret eingesetzte Bibliothek prüfen, nicht pauschal annehmen.

Mehrsprachigkeit: Mit WPML oder Polylang grundsätzlich möglich, Kompatibilität variiert je nach Block-Bibliothek. Vor dem Einsatz prüfen.

Design-Konsistenz: Mittel bis niedrig. Je mehr Blocktypen mit eigenen Stiloptionen verfügbar sind, desto mehr Möglichkeiten hat der Redakteur, das Design zu zerschießen. Aktives Rechtemanagement durch den Administrator ist notwendig, nicht optional.

Kosten: Basisversionen kostenlos, Pro-Versionen 30–100 Euro pro Jahr. Jedes Plugin muss dauerhaft aktiv bleiben. Wird die Bibliothek deinstalliert oder eingestellt, bleiben spezifische Blöcke als unlesbarer Rohcode in den Seiten stehen. Wird das freie Plugin auf einmal kostenpflichtig, muss man bezahlen oder alle umbauen.

Wechselaufwand: Mittel bis hoch. Seiten, die spezifische Blöcke der Bibliothek nutzen, sind ohne das Plugin nicht mehr korrekt darstellbar. Der Wechsel klingt einfach, ist in der Praxis manuelle Arbeit an jeder betroffenen Seite.

3. Page Builder (z.B. Elementor, Divi, WPBakery)

Page Builder ersetzen den WordPress-Editor vollständig durch eine eigene Drag-and-Drop-Oberfläche mit Live-Vorschau. Sektionen, Spalten und Widgets werden visuell zusammengestellt, was auf dem Bildschirm zu sehen ist, soll auch so aussehen. Die bekanntesten Vertreter sind Elementor (über 10 Millionen aktive Installationen), Divi von Elegant Themes und WPBakery. Sie unterscheiden sich in Details, teilen aber dieselben grundlegenden Stärken und Schwächen.

Redaktionsalltag: Das Interface ist auf den ersten Blick einladend. In der Praxis ist ein Page Builder kein einfacher Editor, sondern ein Layoutwerkzeug. Wer damit nur Texte pflegen will, öffnet jedes Mal eine vollständige Design-Umgebung, mit allen Ablenkungs- und Fehlerquellen, die das mit sich bringt. Der Schulungsaufwand ist erheblich: mehrere Stunden bis Tage, abhängig von der Komplexität der Website. Wer das nicht investiert, richtet mehr Schaden an als Nutzen.

Wissensabhängigkeit: Das größte strukturelle Risiko bei Page Buildern. Kenntnisse in einem Page Builder sind nicht intuitiv übertragbar, und zwischen den Produkten wechseln heißt von vorne anfangen. Wer eine damit gebaute Website übernimmt, ohne das konkrete System zu kennen, steht vor einer schwarzen Box. Fällt die einzige Person aus, die weiß, wie die Seite aufgebaut ist, ist externe Hilfe oft unvermeidlich, und teuer.

Gastautoren und externer Zugriff: Ein unerfahrener Gastautor kann in wenigen Klicks das Layout einer ganzen Seite verschieben oder zerstören und merkt es möglicherweise erst, wenn jemand anderes die Website aufruft. Page Builder unterscheiden beim Bearbeiten nicht klar zwischen „Inhalt ändern“ und „Layout ändern“. Strikte Rollentrennung und gesperrte Templates sind notwendig, was wiederum Administrationsaufwand bedeutet.

Textimport: Text lässt sich einfügen, aber Formatierungen werden oft nicht korrekt übernommen oder erzeugen unerwartetes Markup. Direkt ins HTML einzugreifen ist schwerer als im klassischen Editor.

Design-Konsistenz: Gering ohne strikte Vorgaben. Page Builder geben dem Nutzer umfangreiche Kontrolle über Schriften, Abstände, Farben und Layout. Ein einheitliches Erscheinungsbild ist nur dann realistisch, wenn Vorlagen als gesperrte Templates gebaut werden und Redakteure ausschließlich innerhalb definierter Bereiche arbeiten.

Barrierefreiheit: Page Builder erzeugen tendenziell aufgeblähtes HTML mit zusätzlichen Wrapper-Elementen und Inline-Styles. Barrierefreie Ausgabe ist möglich, erfordert aber aktive Konfiguration und Prüfung. Für BFSG-pflichtige Organisationen ist das ein erhöhter Aufwand.

Mehrsprachigkeit: Mit WPML kompatibel, aber komplex. Fehler in der Einrichtung führen dazu, dass Layoutänderungen in einer Sprache ungewollt auch andere Sprachversionen beeinflussen.

Backup und Wiederherstellung: Page Builder speichern Seitenstrukturen als proprietäres Format in der Postmeta-Tabelle der Datenbank, nicht im Standard-Contentfeld. Manche Backup-Plugins erfassen Postmeta nicht vollständig. Nach einer Wiederherstellung kann eine Page-Builder-Seite leer erscheinen, obwohl das Backup als erfolgreich ausgewiesen wurde. Das Backup-System muss explizit auf Postmeta-Vollständigkeit geprüft werden, bevor der Ernstfall eintritt, nicht danach.

Versionierung: WordPress hat eingebaute Revisionen für Beiträge. Bei den meisten Page Buildern werden Layoutänderungen nicht oder nur unvollständig in diesem System erfasst. Die meisten Page Builder haben eine eigene Versionshistorie, die aber begrenzt und nicht mit dem WordPress-System integriert ist. Wer einen Fehler rückgängig machen will, kann sich nicht auf das Standard-Werkzeug verlassen.

Sicherheit: Page Builder sind aufgrund ihrer Verbreitung bevorzugte Angriffsziele. Updates müssen zeitnah eingespielt werden. Vorab sollte geklärt sein: Wer ist zuständig, wenn ein Sicherheitspatch erscheint? Wer räumt auf, wenn die Website trotzdem kompromittiert wird? Das sind keine hypothetischen Fragen.

Kosten: Die Kostenmodelle variieren: Elementor Pro kostet 59 bis knapp 400 Euro pro Jahr, Divi ist als Abo oder Lifetime-Kauf erhältlich, WPBakery wird einmalig lizenziert. Allen gemeinsam ist, dass der Betrieb der Website dauerhaft an die aktive Lizenz gebunden bleibt.

Wechselaufwand: Hoch. Ohne den jeweiligen Page Builder sind die Seiten leer oder unleserlich. Ein Wechsel bedeutet: alle Seiten neu aufbauen. Das ist der stärkste Lock-in unter allen hier verglichenen Ansätzen.

4. Bricks

Bricks ist ein technisch ambitionierter Page Builder, der sich explizit an Webentwickler richtet. Er bietet ähnliche Funktionen wie Elementor oder Divi, erzeugt aber saubereren HTML-Output und gibt Entwicklern mehr Kontrolle über CSS und Markup. Einmalkauf für 149 US-Dollar, kein Abo.

Redaktionsalltag: Bricks ist für den Einsatz durch Endnutzer ohne technischen Hintergrund weder konzipiert noch geeignet. Das Interface setzt Grundkenntnisse in Webentwicklung voraus. Wer Bricks ohne dieses Hintergrundwissen bedient, wird schnell scheitern.

Wissensabhängigkeit: Hoch. Bricks-Kenntnisse sind noch weniger verbreitet als Elementor-Kenntnisse. Fällt die Person aus, die das System aufgebaut hat, ist externe Hilfe schwerer zu finden.

Design-Konsistenz: Stark von der Einrichtung durch den Entwickler abhängig. Mit sauber gebauten Templates und gesperrten Bereichen ist Konsistenz erreichbar, erfordert aber Entwickleraufwand im Vorfeld.

Barrierefreiheit: Bricks erzeugt saubereren HTML-Output als die meisten anderen Page Builder, was barrierefreie Ausgabe erleichtert. Die Umsetzung liegt aber beim Entwickler, nicht im System selbst.

Backup und Versionierung: Wie bei anderen Page Buildern werden Seitenstrukturen in Postmeta gespeichert. Backup-Systeme müssen auf Postmeta-Vollständigkeit geprüft werden.

Kosten: Einmalkauf für 149 US-Dollar. Kein laufendes Abo, aber Updates sind nur im ersten Jahr inklusive.

Wechselaufwand: Hoch. Lock-in vergleichbar mit anderen Page Buildern: Seitenstrukturen sind ohne Bricks nicht lesbar. Ein Wechsel erfordert kompletten Neuaufbau.

Fazit für diesen Kontext: Bricks ist das richtige Werkzeug für Entwickler, die Performance und Codequalität über Bedienkomfort stellen. Für Administratoren ohne Webentwicklungshintergrund, die eine Website für nicht-technische Endnutzer betreiben, ist Bricks keine realistische Option.

Vergleich auf einen Blick

Welcher Ansatz für wen?

Texte und Bilder pflegen, mehr nicht. Klassischer Editor. Eine oder zwei Schulungsstunden reichen. Das Interface kennt jeder, der schon einmal eine E-Mail geschrieben hat. Layout und Design kann man nicht versehentlich kaputtmachen, weil man keinen Zugriff darauf hat. Wer das System selten benutzt und nach Monaten wieder einsteigt, findet sich sofort zurecht. Geringer Administrationsaufwand, geringer Lock-in, keine laufenden Kosten.

Gelegentlich auch Seitenstruktur anpassen, einfache Layouts selbst bauen. Gutenberg mit Block-Bibliothek. Realistisch ein halber Tag Schulung plus Übungszeit. Wer regelmäßig damit arbeitet, gewöhnt sich daran. Wer es nur alle paar Wochen öffnet, fängt jedes Mal ein Stück weit von vorne an. Die Gefahr, das Design unbeabsichtigt zu zerstören, ist real und muss durch Vorgaben und Rollentrennung begrenzt werden. Wichtig: Das aufgebaute Know-how sollte dokumentiert sein, damit nicht alles an einer Person hängt.

Volle Kontrolle über das Layout, Seiten eigenständig gestalten. Page Builder (Elementor, Divi, WPBakery). Mehrere Stunden bis Tage Einarbeitungszeit. Wer das nicht investiert, richtet mehr Schaden an als Nutzen. Dazu kommen das höchste Risiko für Design-Abweichungen, das komplexeste Backup-Szenario, laufende Lizenzkosten und die stärkste Abhängigkeit von Einzelpersonen. Page Builder sind keine schlechten Werkzeuge, aber sie sind die falschen Werkzeuge, wenn die Endnutzer keine Gestaltungserfahrung haben und der Administrator keine Webentwicklung macht.

Was kein Editor löst

Kein Editor löst das eigentliche Organisationsproblem: Wer darf was bearbeiten? Welche Bereiche sind gesperrt? Wie sieht die Schulung aus, und wer pflegt das System in zwei Jahren?

Design-Konsistenz entsteht nicht durch die Wahl des richtigen Editors. Sie entsteht durch klare Vorgaben, eingeschränkte Berechtigungen und Vorlagen, die Fehler schwer machen. Der Unterschied zwischen den Ansätzen liegt darin, wie viel zusätzlichen Aufwand ein Administrator investieren muss, um diesen Zustand herzustellen und zu erhalten.

Die eigentliche Frage vor der Editor-Wahl lautet: Soll der Endnutzer Inhalte pflegen oder Layouts bauen? Für ersteres reicht meistens deutlich weniger, als die verfügbaren Optionen suggerieren. Und wer heute auf einen Plugin-abhängigen Ansatz setzt, sollte sich ehrlich fragen, ob er in drei Jahren noch bereit ist, denselben Aufwand für Updates, Sicherheitspatches und Plugin-Kompatibilität zu betreiben.