Gutenberg vs. Elementor vs. Divi 2026: Die Page-Builder Revolution

Die Builder-Frage ist 2026 keine Geschwindigkeitsfrage mehr, sondern eine Datenfrage: Wo liegen die Inhalte, wer kann sie lesen, und was kostet es, sie wieder herauszuholen. WordPress steht stabil bei 7.1.1 (17. September 2026), Elementor bei 4.2.4 (Stand 31. August 2026), und Divi 5 hat die Beta am 26. Februar 2026 verlassen. Alle drei rendern serverseitig HTML. Der Unterschied beginnt darunter.

Die verbreitete Kurzfassung lautet: Gutenberg schlank, Elementor aufgebläht, Divi dazwischen. Diese Kurzfassung hält der Quelle nicht stand. Der Core lädt seine Blockbibliothek in der Voreinstellung komplett, Elementor liefert seit Version 3.30 ein stabiles Experiment für schlankeres Markup, und Divi hat sein Shortcode-Format ersetzt. Wer 2026 entscheidet, sollte die Mechanik prüfen, nicht die Fahnenfarbe.

Dieser Text vergleicht deshalb entlang von sechs überprüfbaren Achsen: Speicherformat, Asset-Auslieferung, Gestaltungskontrolle, Wartungspfad, Rechtslage in Deutschland und Ausstiegskosten.

#1. Der Architektur-Wandel: Native Blöcke vs. Wrapper

#Gutenberg: der native Weg

Blockmarkup landet in post_content, und zwar als gewöhnliches HTML zwischen HTML-Kommentaren. Ein Absatz sieht in der Datenbank so aus:

<!-- wp:paragraph -->
<p>Text, der auch ohne WordPress lesbar bleibt.</p>
<!-- /wp:paragraph -->

Die verbreitete Behauptung, Blöcke seien “nur HTML-Kommentare in der Datenbank”, stimmt nur für die zweite Sorte. Dynamische Blöcke wie die Query Loop oder die Navigation speichern tatsächlich nur einen selbstschließenden Kommentar mit JSON-Attributen und erzeugen ihr Markup erst beim Request über den render_callback:

<!-- wp:latest-posts {"postsToShow":3,"displayPostDate":true} /-->

Praktisch heißt das: Statischer Inhalt überlebt jeden Themewechsel und jeden Export, dynamischer Inhalt braucht die registrierende Instanz. Der Core-Trunk enthält derzeit 115 Blockverzeichnisse unter src/wp-includes/blocks/. Wer einen davon per Plugin ergänzt und das Plugin später entfernt, hat exakt dasselbe Problem wie bei jedem Builder, nur in kleinerem Maßstab.

#Elementor: JSON neben dem Beitrag

Elementor schreibt die Seitenstruktur nicht in post_content, sondern als JSON in die Postmeta. Die Konstante steht in core/base/document.php:

const ELEMENTOR_DATA_META_KEY = '_elementor_data';
const BUILT_WITH_ELEMENTOR_META_KEY = '_elementor_edit_mode';

Damit ist die häufig zitierte “Shortcode-Hölle” bei Elementor sachlich falsch. Wer das Plugin deaktiviert, sieht keinen Shortcode-Salat, sondern den unveränderten post_content, und der ist bei einer Seite, die von Anfang an in Elementor gebaut wurde, in der Regel leer. Das ist kein besseres Ergebnis, nur ein anderes: statt Datensalat eine weiße Seite.

#Divi: weg vom Shortcode

Bis einschließlich Divi 4 lagen die Module als verschachtelte Shortcodes im Beitragstext, [et_pb_section] und Verwandte. Genau das hat Elegant Themes ersetzt. In der Ankündigung zur neuen Architektur heißt es, man bewege sich “away from shortcodes and towards a more modern storage format”, und die Begründung nennt ausdrücklich die Fehleranfälligkeit verschachtelter Shortcode-Attribute. Divi 5 ist seit dem 26. Februar 2026 offiziell. Die Konvertierung bestehender Divi-4-Seiten läuft nicht von allein: Nach dem Update arbeitet die Seite zunächst im Backward-Compatibility-Modus mit unkonvertierten Divi-4-Modulen weiter, und erst der Divi-5-Migrator unter Divi > Divi 5 Migrator wandelt sie um, laut Elegant Themes mit einem Klick. Elegant Themes sagt zu, Divi 4 “for at least the next 12 months” weiter mit Sicherheits- und Kompatibilitätsfixes zu versorgen.

Lock-in gibt es bei allen dreien. Die ehrliche Frage lautet nicht, ob man gefangen ist, sondern ob ein Migrationsskript das Format überhaupt parsen kann. JSON in einer Postmeta kann es. Tief verschachtelte Shortcode-Attribute konnten es nur mit Schmerzen.

#2. Der Krieg um Performance & Core Web Vitals

#Der Core lädt in der Voreinstellung alles

wp_should_load_separate_core_block_assets() in wp-includes/script-loader.php endet mit einer einzigen Zeile:

return apply_filters( 'should_load_separate_core_block_assets', false );

Der Filter-Default ist false. Ohne Eingriff lädt eine Seite mit einem einzigen Absatz die gesamte wp-block-library. Zwei Dinge ändern das. Blockthemes setzen den Filter in _add_default_theme_supports() automatisch:

add_filter( 'should_load_separate_core_block_assets', '__return_true' );
add_filter( 'should_load_block_assets_on_demand', '__return_true' );

Und seit WordPress 6.9 bekommen klassische Themes dieselbe Behandlung über wp_load_classic_theme_block_styles_on_demand(), das dafür den Template-Output-Buffer einschaltet und die spät gedruckten Styles nach oben zieht. Seit 7.0 hängt diese Funktion an wp_default_styles mit Priorität 0 statt an init.

Wer also behauptet, Gutenberg sei per se schlank, hat entweder ein Blockthema oder eine aktuelle Installation. Auf einem klassischen Theme unter einer älteren WordPress-Version stimmt der Satz nicht.

#Elementor hat die Optimierungen, aber nicht eingeschaltet

In core/experiments/manager.php stehen die relevanten Schalter mit ihren Defaults. e_optimized_markup trägt den Status stabil, in der Beschreibung steht “Reduce the DOM size by eliminating HTML tags in various elements and widgets”, und darunter:

'default' => self::STATE_INACTIVE,
'new_site' => [
    'default_active' => true,
    'minimum_installation_version' => '3.30.0',
],

Neue Installationen ab 3.30.0 bekommen es eingeschaltet. Eine Agenturinstallation aus 2019, die seither nur aktualisiert wurde, nicht. Dasselbe Muster beim Flexbox-Container: 'default' => self::STATE_INACTIVE, aktiv nur für Installationen ab 3.16.0. Das erklärt den Großteil dessen, was in Vergleichsartikeln als “Divitis” bei Elementor beschrieben wird. Es ist meist keine Eigenschaft des Plugins, sondern eine Eigenschaft der Migrationsstrategie des Plugins. Elementor warnt im selben Text, dass der Wechsel “might require updating custom CSS/JS code”, und das ist der Grund, warum niemand den Schalter umlegt.

#Der Bildpfad ist der konkrete LCP-Killer

In includes/controls/groups/image-size.php gibt es zwei Zweige. Liegt eine Anhang-ID vor, ist die gewählte Größe eine registrierte WordPress-Bildgröße und ist der Static Render Mode aus, ruft Elementor wp_get_attachment_image() auf und der Core kann seine Optimierung anwenden. Fällt eine dieser drei Bedingungen weg, etwa bei frei eingegebenen Maßen, baut Elementor das Tag selbst:

'<img src="%1$s" title="%2$s" alt="%3$s"%4$s loading="lazy" />'

Kein width, kein height, dafür ein fest verdrahtetes loading="lazy". Und wp_get_loading_optimization_attributes() in wp-includes/media.php steigt ohne width und height ohnehin früh aus, bevor es über fetchpriority entscheiden könnte. Ein Hero-Bild mit freier Größe wird damit lazy geladen, obwohl es das LCP-Element ist. Das ist kein theoretischer Nachteil, das ist die erste Stelle, an der man bei einem Elementor-Audit nachsieht.

#Was für alle drei gleich gilt

Speculative Loading steckt seit WordPress 6.8 im Core und arbeitet auf Dokumentebene, also unabhängig vom Builder. Die Voreinstellung ist prefetch mit conservative, und sie greift nur bei sprechenden Permalinks und ausgeloggten Besuchern. WordPress 7.1 erlaubt Hostern, diesen Default über WP_SPECULATIVE_LOADING_DEFAULT_MODE und WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS zu verschieben. Wer das für einen Gutenberg-Vorteil hält, misst falsch.

Eine Vergleichsmessung ist nur dann etwas wert, wenn sie dieselbe Seite, dasselbe Hosting und dasselbe Messfenster benutzt und Felddaten statt nur Labordaten heranzieht. Wie man das aufsetzt, steht im INP-Leitfaden.

#3. Design-Flexibilität

#Die Gutenberg-Realität 2026

Der Vertrag zwischen Design und Editor heißt theme.json. Die aktuelle Schemaversion ist 3, und sie steht im Core-Trunk als Konstante:

const LATEST_SCHEMA = 3;

Eine Version 4 gibt es nicht, egal was Jahresrückblicke behaupten. Der praktisch wichtigste Teil ist nicht styles, sondern settings, denn settings bestimmt, was die Redaktion überhaupt anfassen darf:

{
  "version": 3,
  "settings": {
    "color": { "custom": false, "defaultPalette": false },
    "typography": { "fluid": true, "customFontSize": false }
  }
}

Damit verschwindet der freie Farbwähler aus dem Editor. Genau das ist der Grund, warum große Redaktionen zu Blöcken wechseln: nicht wegen der Ladezeit, sondern weil der Editor Grenzen kennt, die im Git liegen.

#Der Elementor-Vorteil

Elementor fühlt sich weiterhin mehr wie ein Grafikwerkzeug an, und das ist keine Beleidigung, sondern eine Arbeitsweise. Der konkrete funktionale Unterschied liegt bei den Breakpoints: Elementor kennt in core/breakpoints/manager.php sieben Geräte, davon aktiv voreingestellt mobile, tablet und desktop. Zusätzlich zuschaltbar sind genau vier: mobile extra, tablet extra, laptop und widescreen. Der Core-Editor bietet das nicht. Er bietet fluide Typografie über settings.typography.fluid, also clamp()-Werte zwischen Minimum und Maximum, und alles Weitere geht über CSS im Theme.

Für ein Design, das pro Gerät eigene Abstände und Reihenfolgen vorsieht, ist das der Punkt, an dem eine Gutenberg-Umsetzung Entwicklerzeit kostet, die eine Elementor-Umsetzung nicht kostet. Wer das wegdiskutiert, verkauft.

#Divi 5

Divi bringt sein Gestaltungssystem im eigenen Interface mit und bleibt dabei ein geschlossenes Ökosystem: Divi liegt nicht im Plugin-Verzeichnis von WordPress.org, Updates kommen über die Mitgliedschaft bei Elegant Themes. Das ist für viele Agenturen kein Nachteil, solange die Mitgliedschaft läuft, und ein klarer Nachteil, sobald ein Kunde die Seite selbst übernehmen soll.

Wer tiefer in Muster, Stilvariationen und Templates einsteigen will, findet die Details im Leitfaden zu Blöcken, Mustern und Full Site Editing.

#4. Stabilität & Wartung

Die alte Formel “Gutenberg bricht fast nie, Builder brechen ständig” ist zu bequem. Die Bruchstellen sind nur unterschiedlich.

Blöcke brechen über die Blockvalidierung. Ändert ein Block sein gespeichertes Markup, ohne dass eine deprecated-Definition den alten Stand abdeckt, meldet der Editor “Dieser Block enthält unerwarteten oder ungültigen Inhalt”. Der Frontend-Ausgabe passiert nichts, der Redaktion schon. Das trifft fast immer eigene Blöcke oder Blöcke aus Plugins, selten Core-Blöcke, weil der Core seine Deprecations pflegt.

Elementor und Divi brechen über Versionsabstände. Für die ausgelieferte Version 4.2.4 meldet das Plugin-Verzeichnis von WordPress.org “Requires at least: 6.8” und “Tested up to: 7.1.1”. Das Plugin folgt also dem Core zügig, aber es folgt ihm eben, statt mit ihm ausgeliefert zu werden. Bei Divi kommt für 2026 ein Datum hinzu: Wer auf Divi 4 bleibt, arbeitet in einem Zeitfenster, das Elegant Themes mit mindestens zwölf Monaten ab dem 26. Februar 2026 beziffert hat.

Praktisch heißt das für einen Wartungsvertrag: Bei Blöcken prüft man nach einem Core-Update die eigenen Blöcke und die Patterns. Bei Elementor und Divi prüft man zusätzlich die Reihenfolge, in der Core, Builder, Theme und Pro-Erweiterung aktualisiert werden, und man tut das auf Staging, nicht auf Produktion.

#5. SEO & KI-Optimierung

Die Behauptung, zu viel Markup “verwässere die Keyword-Dichte”, gehört ins Jahr 2011. Keyword-Dichte ist kein Rankingfaktor, und Wrapper-Divs verändern den Textinhalt nicht.

Was stimmt, ist die indirekte Kette: Markup-Masse und Skriptmasse schlagen auf LCP und INP durch, und Core Web Vitals sind ein Signal. Die Kette ist real, sie ist nur länger, als die Kurzfassung behauptet.

Für Antwortmaschinen zählt etwas anderes, nämlich ob der Inhalt in der ersten HTML-Antwort steht und ob die Überschriftenhierarchie das Dokument beschreibt. Alle drei Systeme rendern serverseitig, damit ist der Grundfall erfüllt. Der Unterschied liegt in der Weiterverarbeitung: Blockmarkup lässt sich mit parse_blocks() aus dem Core in eine Struktur zerlegen, ohne dass man ein fremdes Schema nachbauen muss. Elementor-JSON und Divi-JSON sind ebenfalls maschinenlesbar, folgen aber einem herstellereigenen Schema, das sich mit Versionen ändern darf. Wer aus Inhalten strukturierte Daten, Feeds oder eine Agentenschnittstelle ableiten will, arbeitet mit Blöcken näher an einer dokumentierten API.

Ein Detail, das in der Praxis öfter schadet als jede Wrapper-Tiefe: Überschriftenebenen, die nach Schriftgröße gewählt werden. Das passiert in jedem der drei Editoren, weil jeder von ihnen die Ebene frei wählbar macht. Dagegen hilft kein Builder, sondern eine Vorlage, die H2 und H3 bereits richtig gesetzt hat.

#6. Barrierefreiheit (WCAG 2.2)

Für den deutschen Markt ist das der Abschnitt mit echten Fristen. Das Barrierefreiheitsstärkungsgesetz setzt die EU-Richtlinie 2019/882 um und gilt seit dem 28. Juni 2025. Es erfasst nach Paragraf 2 Nummer 26 “Dienstleistungen im elektronischen Geschäftsverkehr”, also den Verkauf und die Buchung über Website oder App, nicht automatisch jede Unternehmenswebsite. Paragraf 3 Absatz 3 nimmt Kleinstunternehmen bei Dienstleistungen aus, bei Produkten gilt diese Ausnahme nicht.

Die erste Frage ist damit nicht “welcher Builder”, sondern “ist auf dieser Seite ein Bestell-, Buchungs- oder Vertragsabschluss möglich”. Lautet die Antwort ja, ist der Builder nur das Werkzeug, mit dem man die Anforderung erfüllt oder verfehlt.

Kein System liefert Konformität ab Werk. Die Fehler, die in Audits wiederkehren, sind in allen dreien dieselben:

• Buttons, die nur ein Icon enthalten und keinen zugänglichen Namen.
• Karussells und Akkordeons, deren Fokusreihenfolge nach absoluter Positionierung nicht mehr der Lesereihenfolge entspricht.
• Kontraste aus der Markenpalette, die an der Schwelle von 4,5:1 scheitern, weil sie nie geprüft wurden.
• Überschriftenebenen, die einen Sprung von H2 auf H4 enthalten.

Core-Blöcke geben semantische Elemente aus, was die Ausgangslage verbessert, aber die Gestaltungsentscheidung trifft die Vorlage, nicht der Block. Der Editor selbst ist ein eigenes Thema: Die Bedienbarkeit des Block-Editors mit Tastatur und Screenreader war über Jahre Gegenstand von Kritik aus dem WordPress-Accessibility-Team, und “Accessibility First” beschreibt dort einen Anspruch, keinen Auslieferungszustand.

Die zweite deutsche Rechtsfrage betrifft Schriften. Elementors Einstellung “Load Google Fonts Locally” steht im Quelltext auf 'std' => '0', ist also aus, und die Beschreibung des Herstellers nennt selbst die DSGVO als Grund, sie einzuschalten. Das LG München I hat am 20. Januar 2022 (Az. 3 O 17493/20) entschieden, dass die dynamische Einbindung von Google Fonts ohne Einwilligung rechtswidrig ist, weil die IP-Adresse an Google übertragen wird. Auf einer deutschen Seite ist dieser Schalter kein Performance-Detail, sondern eine Checkliste-Position. Mehr dazu im Beitrag zum europäischen Barrierefreiheitsgesetz.

#7. Total Cost of Ownership (TCO)

Konkrete Lizenzpreise stehen hier bewusst nicht, weil sie sich jährlich ändern und Staffeln pro Anzahl Websites haben. Die Kostentreiber ändern sich nicht.

Der Satz “Gutenberg ist kostenlos” ist dabei nur halb wahr. Wer ohne Blockplugins auskommen will, zahlt stattdessen Entwicklerzeit für Patterns und Tokens, und wer Blockplugins einsetzt, zahlt Lizenzen wie überall sonst. Der ehrliche Unterschied liegt nicht beim Einkauf, sondern beim Ausstieg.

#8. Migration: was beim Umstieg tatsächlich passiert

Von Elementor zu Blöcken gibt es keinen Knopf. Der Ablauf, der in der Praxis trägt, sieht so aus:

1. Bestand zählen. Über WP-CLI alle Beiträge mit _elementor_edit_mode auslesen und die vorkommenden Widget-Typen nach Häufigkeit sortieren. Die Liste ist fast immer kürzer als befürchtet, weil zwanzig Widget-Typen achtzig Prozent der Seiten abdecken.
2. Abbildung festlegen. Für die häufigsten Typen je ein Ziel definieren: Core-Block, Pattern oder eigener Block. Alles, was in dieser Liste keinen Platz findet, wird von Hand neu gebaut, nicht automatisch konvertiert.
3. URLs einfrieren. Die Migration ändert das Markup, nicht die Adressen. Wo sich doch ein Slug ändert, gehört die Weiterleitung in denselben Deploy.
4. Vorher messen, nachher messen. Dieselben URLs, dasselbe Werkzeug, und Felddaten über ein ausreichend langes Fenster, nicht ein Lighthouse-Lauf vom Laptop.
5. Erst dann das Plugin deaktivieren. Vorher nicht, denn post_content ist bei Elementor-Seiten meist leer.

Von Divi 4 auf Divi 5 ist der Weg kürzer, weil Elegant Themes ein eigenes Werkzeug für die Konvertierung des Speicherformats mitliefert. Angestoßen wird sie von Hand: Der Divi-5-Migrator scannt die Seiten, meldet Module ohne Divi-5-Pfad und wandelt den Rest auf Klick um, der Schritt gehört also in das Wartungsfenster eingeplant. Die Stelle, die reißt, ist eigenes CSS: Wer Selektoren auf die alten Modulklassen geschrieben hat, prüft das auf Staging, bevor er den Umstieg auf Produktion freigibt. Wer eine Divi-4-Seite ganz verlässt, findet außerdem oft noch et_pb_-Shortcodes im Beitragstext, die nach dem Themewechsel als Klartext erscheinen und vor dem Livegang entfernt werden müssen.

#9. Entscheidungsmatrix: wann welcher Builder

Blockbasiert bauen, wenn mindestens drei dieser Punkte zutreffen:

• Die Inhalte sollen einen Theme- oder Agenturwechsel überleben.
• Das Design ist ein System aus Tokens und Mustern, kein Katalog von Einzelseiten.
• Es gibt jemanden, der theme.json und eigene Blöcke pflegen kann.
• Die Redaktion soll bewusst weniger Regler haben, nicht mehr.
• Die Seite ist groß genug, dass Templating mehr spart, als es kostet.

Elementor oder Divi wählen, wenn eher das zutrifft:

• Eine kleine Marketingabteilung baut regelmäßig Kampagnenseiten ohne Entwicklerkontakt.
• Das Design verlangt pro Breakpoint eigene Werte.
• Die Agentur betreut bereits ein Portfolio auf demselben System und kennt dessen Eigenheiten.
• Es gibt kein Budget für eine Theme-Entwicklung, aber ein Budget für eine Lizenz.

Und die unbequeme Variante: Wenn niemand im Team theme.json anfassen kann und die Redaktion trotzdem freie Gestaltung erwartet, ist eine halbherzige Blockumsetzung schlechter als ein sauber konfigurierter Elementor. Die Technik entscheidet dieses Projekt nicht, die Besetzung tut es.

#Fazit: die native Zukunft

Der Block-Editor ist 2026 die Standardwahl für Projekte, die länger leben als ihr aktuelles Theme, weil das Speicherformat offen im Beitragstext liegt und theme.json verbindliche Grenzen setzt. Elementor und Divi bleiben die schnellere Antwort für Teams, die täglich selbst gestalten, sofern man die Schalter kennt, die auf Bestandsinstallationen aus stehen: Optimized Markup, Flexbox-Container und lokal ausgelieferte Schriften.

Wenn Sie vor der Entscheidung stehen oder eine bestehende Builder-Seite messen lassen wollen, sehen wir uns die Installation an und benennen die Hebel aus Abschnitt 2 an Ihrem konkreten Fall. Einstieg dazu: WordPress-Geschwindigkeitsoptimierung.