Gutenberg vs. Elementor vs. Divi 2026: Page-Builder im Vergleich

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.3, Elementor bei 4.3.4 (Stand 12. Oktober 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.

#Wie Gutenberg, Elementor und Divi Inhalte speichern

#Gutenberg-Blockmarkup in post_content

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-Daten als JSON in den Postmeta

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-Shortcodes und das neue Format von Divi 5

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 “weg von Shortcodes und hin zu einem moderneren Speicherformat” (eigene Übersetzung), 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 “mindestens für die nächsten 12 Monate” (eigene Übersetzung) 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.

#Marktanteil der Page Builder 2026

Elementor ist mit Abstand der meistgenutzte Page Builder von Drittanbietern: W3Techs erkennt ihn am 12. Oktober 2026 auf 31,5 % aller WordPress-Websites, und das Plugin-Verzeichnis von WordPress.org meldet mehr als 10 Millionen aktive Installationen. Elementor selbst wirbt auf der eigenen Website mit über 22 Millionen gebauten Websites. Das sind zwei verschiedene Messgrößen, die man nicht addieren oder gegeneinander ausspielen sollte. Gutenberg taucht in diesen Listen nicht auf, weil er im Core steckt: Installiert ist er überall, die sinnvolle Frage ist, wie viele Websites ihn als primäres Layoutwerkzeug nutzen.

Zwei Einschränkungen, bevor jemand diese Zahlen in ein Angebot schreibt. Divi ist hier untererfasst, weil es vor allem als Theme ausgeliefert wird und die Plugin-Erkennung von W3Techs die meisten Divi-Seiten nicht sieht. Die Millionenzahlen, die für Divi kursieren, stammen aus dem Marketing von Elegant Themes, nicht aus einer unabhängigen Messung. Außerdem ist der Anteil an Installationen nicht der Anteil an neuen Projekten: Der Wert von WPBakery ist zu großen Teilen ein Erbe älterer ThemeForest-Themes. Für die Entscheidung 2026 heißt das: Elementor hat das größte Ökosystem und den größten Pool an Fachleuten, Divi eine treue, aber schwer messbare Basis, und Gutenberg ist das einzige der drei Systeme, das garantiert auf jeder WordPress-Installation vorhanden ist.

#Gutenberg, Elementor und Divi im Funktionsvergleich

Die Tabelle fasst den Vergleich auf einer Seite zusammen. Interessant sind die Zeilen, nicht die Spalten: dort, wo ein System strukturell etwas kann, was die anderen nicht können.

Das Muster ist eindeutig: Elementor und Divi gewinnen die Zeilen zu freier visueller Kontrolle und fertigen Vorlagen, Gutenberg gewinnt die Zeilen zu Portabilität, Core-Nähe und Erweiterungsmodell. Die Zeile, in der die drei am weitesten auseinanderliegen, ist das Speicherformat, und genau diese Zeile wird zwei oder drei Jahre später zu einem Kostenposten.

#Ist Gutenberg schneller als Elementor

#Lädt WordPress alle Block-Styles auf jeder Seite

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.

#Optimiertes Markup in Elementor aktivieren

In core/experiments/manager.php stehen die relevanten Schalter mit ihren Defaults. e_optimized_markup trägt den Status stabil, laut Beschreibung soll es “die DOM-Größe verringern, indem HTML-Tags in verschiedenen Elementen und Widgets entfernt werden” (Elementor-Quelltext, eigene Übersetzung), 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 “eine Anpassung von eigenem CSS- und JS-Code erfordern kann” (eigene Übersetzung), und das ist der Grund, warum niemand den Schalter umlegt.

#Lazy Loading und fehlende Bildmaße in Elementor

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.

#Performance-Hebel, die für alle drei Builder gelten

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.

#Elementor oder Gutenberg für flexibles Design

#Designvorgaben mit theme.json in Gutenberg

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.

#Breakpoints pro Gerät in Elementor

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 als geschlossenes Ökosystem

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.

#Eigene Gutenberg-Blöcke oder Elementor-Widgets entwickeln

Hier hört der Vergleich auf, ein Vergleich für Endanwender zu sein.

Gutenberg setzt eine Build-Pipeline mit React und modernem JavaScript voraus. Für einen eigenen Block braucht man einen Build-Schritt (meist @wordpress/scripts), eine Metadatendatei block.json und die Registrierung auf Server- und Editorseite. Das Block Editor Handbook beschreibt block.json als die Datei, die “das Definieren und Registrieren eines Blocks vereinfacht” (eigene Übersetzung), mit einer Definition für Server und Editor. Die Lernkurve ist real, vor allem für Agenturen, die mit klassischen PHP-Themes groß geworden sind. Der Gewinn: Eigene Blöcke verhalten sich wie vollwertige WordPress-Bausteine, mit REST-API-Unterstützung, Blockvorlagen, Mustern und theme.json-Vorgaben.

Elementor lässt Nicht-Entwickler Seiten ohne Code veröffentlichen. Eine API für eigene Widgets gibt es, aber die meisten Agenturen nutzen sie nie, sie bauen aus der mitgelieferten Widget-Bibliothek und aus Erweiterungspaketen. Das ist der eigentliche Grund, warum Elementor bei Übergaben an Kunden gewinnt: Der Kunde kann die Seite bearbeiten, ohne sie zu zerstören, und die Agentur bekommt keinen Anruf wegen eines Syntaxfehlers.

Divi liegt dazwischen. Der Divi Builder ist so einsteigerfreundlich wie Elementor, die Modul-API über ein Child-Theme liegt näher am Entwicklermodell von Gutenberg als die Widget-API von Elementor. Freelancer, die gestalten, aber kein React schreiben, landen oft hier.

Wer wissen will, was er lernen sollte: Ein WordPress-Entwickler liefert 2026 Gutenberg-Blöcke und FSE-Templates aus, kennt Elementor gut genug, um Seiten davon wegzumigrieren, und weiß, dass Divi für Betreuungsverträge existiert.

#Brechen Updates Elementor, Divi oder Gutenberg

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.3.4 meldet das Plugin-Verzeichnis von WordPress.org Requires at least: 6.8 und Tested up to: 7.1.3. 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.

#Welcher Page Builder ist besser für SEO

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.

#Barrierefreiheit nach BFSG mit Page Buildern

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.

#Was kosten Gutenberg, Elementor und Divi wirklich

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

Das Abrechnungsmodell steht dagegen fest und ist bei den Herstellern nachlesbar. Elementor rechnet Pro jährlich ab, die Pläne sind nach Anzahl der Websites gestaffelt, und Abonnements verlängern sich zum Listenpreis. Elegant Themes verkauft Divi als jährliche Mitgliedschaft oder als einmalige Lifetime-Mitgliedschaft, beide mit unbegrenzter Anzahl an Websites, eine Abrechnung pro Website gibt es 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.

#Von Elementor zu Gutenberg oder Divi 5 migrieren

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.
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.

#Synchronisierte Muster oder globale Widgets in Elementor

Am deutlichsten unterscheiden sich Gutenberg und Elementor bei redaktioneller Arbeit in großen Mengen.

Gutenberg hat synchronisierte Muster (früher wiederverwendbare Blöcke, mit WordPress 6.3 umbenannt). Die WordPress-Dokumentation ist eindeutig: Wird ein synchronisiertes Muster geändert, erscheint die Änderung an allen Stellen, an denen es verwendet wird, und eine einzelne Instanz lässt sich lösen und lokal bearbeiten. Zusammen mit Blockvorlagen und Template-Teilen im Full Site Editing entsteht echte Vererbung: Wer den Template-Teil unter dem Artikel ändert, ändert ihn in jedem Artikel.

Elementor hat globale Widgets in Pro und Theme-Teile im Theme Builder. Theme-Builder-Vorlagen greifen über Anzeigebedingungen und wirken damit überall. Gespeicherte Vorlagen, die in eine Seite eingefügt werden, kopieren dagegen ihren Inhalt, und spätere Änderungen an der Vorlage erreichen diese Kopien nicht. Redaktionen, die den Unterschied nicht früh lernen, haben am Ende viele Kopien desselben Heros, die auseinanderlaufen.

Divi hat globale Module und einen Theme Builder, ähnlich wie Elementor.

Für eine Inhaltsseite mit 500 Artikeln skalieren synchronisierte Muster und Blockvorlagen als einzige der drei Lösungen, ohne von einer kostenpflichtigen Erweiterung abzuhängen.

#Wann Elementor oder Gutenberg die bessere Wahl ist

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

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 Performance-Hebel an Ihrem konkreten Fall. Einstieg dazu: WordPress-Geschwindigkeitsoptimierung.