Page Builder ablösen: von Elementor zum Block-Theme wechseln, ohne Inhalte zu verlieren

Page Builder wie Elementor haben vielen Firmen den Einstieg in WordPress erleichtert. Nach einigen Jahren zeigen sich die Kosten: zusätzliche Skripte und Stylesheets auf jeder Seite, Abhängigkeit von einem Plugin für jede Änderung, und bei manchen Buildern Lizenzgebühren. Seit WordPress Block-Themes und den Website-Editor mitbringt, lassen sich Layouts, Kopf- und Fußbereich auch ohne Builder gestalten. Diese Anleitung zeigt, wie Sie den Wechsel planen, Seiten einzeln in Blöcke überführen und den Builder am Ende entfernen, ohne dass Inhalte verloren gehen. Das Verhalten von Elementor beim Umstieg haben wir mit WordPress 7.1.2 und Elementor 4.3.3 getestet.

Voraussetzungen

• WordPress: geprüft mit WordPress 7.1.2 und dem Block-Theme Twenty Twenty-Five in Version 1.5.
• PHP: mindestens 7.4, getestet mit PHP 8.4.
• Zugriff: Rolle Administrator im Backend, SSH mit WP-CLI für die Bestandsaufnahme und das Entfernen der Builder-Markierung. Ohne SSH erledigen Sie die Abfragen mit phpMyAdmin.
• Staging: eine Kopie der Website, auf der Sie den gesamten Umbau durchführen. Auf der Live-Website stellen Sie erst um, wenn alles fertig ist.
• Backup: vollständige Sicherung von Dateien und Datenbank vor Beginn und vor dem Übertragen auf die Live-Website.
• Zeit: je nach Seitenzahl mehrere Tage. Rechnen Sie pro gestalteter Seite mit einer halben bis zwei Stunden Neugestaltung.

Schritt 1: Bestand aufnehmen

Klären Sie zuerst, was der Builder überhaupt gestaltet. Das sind oft mehr Stellen als die sichtbaren Seiten: Kopf- und Fußbereich, Pop-ups, globale Vorlagen, Formulare und Archivseiten. Elementor markiert jede Seite, die mit dem Builder bearbeitet wurde, mit dem Metafeld _elementor_edit_mode und dem Wert builder. Das Layout selbst liegt in _elementor_data. Eine Abfrage zeigt alle betroffenen Inhalte:

wp db query "SELECT p.ID, p.post_title, p.post_type FROM wp_posts p JOIN wp_postmeta m ON m.post_id = p.ID AND m.meta_key = '_elementor_edit_mode' AND m.meta_value = 'builder' WHERE p.post_type NOT IN ('revision','elementor_library') ORDER BY p.post_type, p.post_title"
wp post list --post_type=elementor_library --fields=ID,post_title

Ersetzen Sie das Präfix wp_, wenn wp db prefix ein anderes ausgibt. Die zweite Liste zeigt Vorlagen aus der Elementor-Bibliothek. Im Test enthielt sie nach der Installation bereits den Eintrag „Default Kit“, der die globalen Farben und Schriften speichert.

Legen Sie aus beiden Listen eine Tabelle an: Seite, Adresse, Aufrufzahl (aus Ihrer Statistik), verwendete Elemente und Priorität. Seiten mit wenig Besuchern und veraltetem Inhalt sind Kandidaten zum Löschen statt zum Umbauen. Das senkt den Aufwand oft deutlich. Wenn Sie ohnehin den Plugin-Bestand prüfen, hilft Plugins reduzieren und sauber deinstallieren.

Verifizieren: Sie haben eine vollständige Liste aller Builder-Seiten, Vorlagen und globalen Bereiche mit Entscheidung „umbauen“ oder „entfernen“.

Schritt 2: Staging vorbereiten und Block-Theme wählen

Richten Sie eine Staging-Kopie ein, wie in Staging-Umgebung mit WP-CLI einrichten beschrieben. Installieren Sie dort das Block-Theme, zunächst ohne es zu aktivieren. Twenty Twenty-Five ist ein guter Ausgangspunkt, weil es von WordPress selbst gepflegt wird und viele Vorlagen und Muster mitbringt:

wp theme install twentytwentyfive
wp theme list --fields=name,version,status

Wichtig ist die Reihenfolge. Aktivieren Sie das neue Theme erst, wenn alle Seiten umgebaut sind. Solange der Builder aktiv bleibt, sehen Besucher der Staging-Kopie die alten Seiten, und Sie bauen im Hintergrund um. Wollen Sie das Aussehen parallel prüfen, nutzen Sie unter Design > Themes die Live-Vorschau des neuen Themes.

Verifizieren: Die Staging-Kopie läuft mit Builder und altem Theme wie die Live-Website, und das Block-Theme erscheint in wp theme list mit Status inactive.

Schritt 3: Seiten in Blöcke überführen

Elementor schreibt beim Speichern eine einfache HTML-Fassung der Seite in den normalen Beitragsinhalt. Im Test entstand aus Überschrift, Textblock und Button dieser Inhalt:

<h2>Unsere Leistungen</h2>  <p>Wir betreuen Ihre IT in Dresden.</p>  <a href="/kontakt/"> Kontakt aufnehmen </a>

Texte, Überschriften und Links bleiben also erhalten, Spalten, Abstände, Farben und Button-Gestaltung nicht. Öffnen Sie die Seite über Seiten > Alle Seiten mit „Bearbeiten“ im Block-Editor, nicht über „Mit Elementor bearbeiten“. Der Inhalt erscheint als ein einziger Block „Klassisch“. Wählen Sie ihn aus und klicken Sie in der Werkzeugleiste auf In Blöcke umwandeln. Im Test entstanden daraus ein Überschrift-Block und zwei Absatz-Blöcke. Der Button wurde zu einem Absatz mit Link und überflüssigen Zeilenumbrüchen.

Gestalten Sie die Seite jetzt mit Blöcken neu: Spalten, Gruppen, Buttons und Cover-Blöcke decken das meiste ab, was Builder-Seiten nutzen. Ersetzen Sie den umgewandelten Link durch einen echten Button-Block. Wiederkehrende Abschnitte wie ein Kontaktband legen Sie einmal als synchronisierte Vorlage (Muster) an und setzen es auf allen Seiten ein. Ändern Sie es später, ändert es sich überall.

Speichern Sie die Seite. Die Live-Ansicht ändert sich dadurch noch nicht, und das ist gewollt: Im Test zeigte die Seite bei aktivem Elementor weiterhin die Builder-Fassung, obwohl der Beitragsinhalt schon aus Blöcken bestand. Solange _elementor_edit_mode gesetzt ist, liest Elementor sein eigenes Layout aus _elementor_data.

Verifizieren: wp post get ID --field=post_content zeigt Block-Kommentare wie <!-- wp:heading -->, und die Vorschau im Block-Editor zeigt die neue Gestaltung.

Schritt 4: Builder-Markierung entfernen

Ist eine Seite fertig, entfernen Sie die Markierung, damit WordPress den Block-Inhalt ausliefert:

wp post meta delete 5 _elementor_edit_mode

Im Test antwortete WP-CLI mit Success: Deleted custom field., und die Seite zeigte sofort die Block-Fassung, obwohl Elementor noch aktiv war. Das hat einen praktischen Vorteil: Sie können Seite für Seite umstellen und prüfen. Das Layout in _elementor_data bleibt erhalten. Setzen Sie die Markierung mit wp post meta update 5 _elementor_edit_mode builder wieder, zeigt die Seite wieder die alte Fassung. Löschen Sie _elementor_data deshalb erst, wenn die neue Website eine Weile stabil läuft.

Ohne SSH löschen Sie das Feld in phpMyAdmin in der Tabelle wp_postmeta für die jeweilige post_id. Arbeiten Sie dort mit Vorsicht, eine falsche Bedingung trifft alle Seiten.

Verifizieren: Der Quelltext der Seite enthält keine Klassen elementor-widget-… mehr, sondern wp-block-…, und die Abfrage aus Schritt 1 listet die Seite nicht mehr.

Schritt 5: Theme wechseln und Kopf- und Fußbereich neu bauen

Sind alle Seiten umgestellt, aktivieren Sie das Block-Theme unter Design > Themes oder per WP-CLI:

wp theme activate twentytwentyfive

Kopf- und Fußbereich, Menüs und Seitenvorlagen gestalten Sie jetzt unter Design > Editor. Dort bearbeiten Sie Templates und Template-Teile wie Header und Footer mit denselben Blöcken wie auf Seiten. Übernehmen Sie Farben und Schriften unter „Stile“, damit das Erscheinungsbild zur bisherigen Website passt. Eigene Schriften laden Sie unter Design > Schriften lokal hoch, was auch aus Datenschutzsicht sinnvoll ist, siehe Google Fonts lokal einbinden.

Denken Sie an Bereiche, die der Builder zusätzlich geliefert hat: Kontaktformulare aus Pro-Funktionen, Pop-ups, Cookie-Hinweise oder eigene Archivseiten. Für jeden Bereich brauchen Sie einen Ersatz, bevor Sie den Builder abschalten.

Verifizieren: Startseite, eine Unterseite, ein Beitrag, das Beitragsarchiv und die 404-Seite zeigen Kopf- und Fußbereich des neuen Themes ohne Darstellungsfehler, auch auf dem Smartphone.

Schritt 6: Builder deaktivieren und Ergebnis prüfen

Führen Sie die Abfrage aus Schritt 1 erneut aus. Liefert sie keine Seiten mehr, deaktivieren Sie den Builder:

wp plugin deactivate elementor
wp plugin list --fields=name,status

Übersehene Seiten erkennen Sie daran, dass sie nach der Deaktivierung nur noch die einfache HTML-Fassung ohne Gestaltung zeigen. So sah es im Test aus, bevor die Seite umgebaut war: Überschrift, Absatz und Link standen untereinander, ohne Spalten und ohne Button. Nichts geht dabei verloren, aber die Seite wirkt kaputt. Prüfen Sie deshalb alle Adressen aus Ihrer Liste und zusätzlich mit einem Link-Prüfer die interne Verlinkung. Haben sich Adressen geändert, richten Sie Weiterleitungen ein.

Bevor Sie auf die Live-Website übertragen: Sichern Sie Live vollständig, übertragen Sie Datenbank und Dateien von Staging, und prüfen Sie Formulare, Bestellprozess und Ladezeit. Nach dem Umstieg sinkt die Zahl der Plugins, aber Theme, Muster und Vorlagen brauchen weiter Pflege, und jedes WordPress-Update verändert den Website-Editor. Wer Updates und Backups nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher.

Verifizieren: Der Builder hat den Status inactive, alle Seiten aus der Liste zeigen die neue Gestaltung, und der Quelltext der Startseite enthält keine Stylesheets des Builders mehr.

Typische Fehler

• Änderungen im Block-Editor erscheinen nicht auf der Website. _elementor_edit_mode ist noch gesetzt. Feld löschen wie in Schritt 4.
• Seite zeigt nach Deaktivierung nur unformatierten Text. Die Seite wurde nicht umgebaut, WordPress zeigt die HTML-Fassung. Builder kurz reaktivieren oder Seite nachbauen.
• Button wird zu Absatz mit Zeilenumbrüchen. „In Blöcke umwandeln“ erkennt Builder-Buttons nicht. Durch Button-Block ersetzen.
• PHP-Hinweise „Implicitly marking parameter … as nullable is deprecated“ bei WP-CLI-Befehlen. Im Test gab Elementor 4.3.3 unter PHP 8.4 solche Hinweise aus. Sie stören die Ausgabe, beeinflussen die Befehle aber nicht.
• Kopfbereich fehlt nach Theme-Wechsel. Er kam aus dem Builder. Unter Design > Editor neu anlegen.
• Abfrage liefert „Table doesn't exist“. Das Tabellenpräfix weicht von wp_ ab. Mit wp db prefix prüfen.

Häufige Fragen

Gibt es ein Werkzeug, das Builder-Seiten automatisch in Blöcke umwandelt?

WordPress selbst wandelt nur das einfache HTML um, wie in Schritt 3 gezeigt. Layout und Gestaltung müssen Sie neu aufbauen. Das ist aufwendig, aber auch eine Gelegenheit, Inhalte zu kürzen und Seiten zu vereinheitlichen.

Muss ich den Builder sofort löschen?

Nein. Deaktivieren genügt zunächst. Behalten Sie Plugin und Daten einige Wochen, damit Sie übersehene Seiten nachbauen können. Danach löschen Sie das Plugin unter Plugins > Installierte Plugins.

Lohnt sich der Umstieg für jede Website?

Nicht immer. Bei einer Website mit wenigen Seiten, die ohnehin bald neu gestaltet wird, verbinden Sie den Umstieg am besten mit dem Relaunch. Bei vielen komplexen Seiten und einem laufenden Budget für den Builder kann das Weiterführen günstiger sein.

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4, Elementor 4.3.3, Hello Elementor und Twenty Twenty-Five 1.5: Seite mit Überschrift, Text und Button per Elementor gespeichert, HTML-Fassung im Beitragsinhalt, Metafelder, Ausgabe mit und ohne aktiven Builder, Umwandlung im Block-Editor mit „In Blöcke umwandeln“, Vorrang der Builder-Fassung bei gesetztem _elementor_edit_mode, Löschen des Felds, Theme-Wechsel. Nicht getestet: Elementor Pro, andere Builder, Formulare, Pop-ups und die Übertragung von Staging auf Live.

Fazit

Der Weg vom Page Builder zum Block-Theme ist Handarbeit, lässt sich aber sicher gestalten: Bestand aufnehmen, auf Staging Seite für Seite umbauen, die Builder-Markierung gezielt entfernen und erst am Ende Theme wechseln und Builder deaktivieren. Weil Elementor sein Layout getrennt vom Beitragsinhalt speichert, bleibt der Rückweg bis zum Schluss offen. Für die laufenden Updates und Backups nach dem Umstieg ist die betreute WordPress-Wartung eine Möglichkeit.

Weiterführende Anleitungen und Quellen

• Staging-Umgebung für WordPress mit WP-CLI einrichten
• WordPress-Plugins reduzieren und sauber deinstallieren
• Google Fonts in WordPress lokal einbinden
• WordPress-Dokumentation: Site Editor
• WordPress-Dokumentation: Classic Block
• WordPress Developer: Block Themes
• Twenty Twenty-Five auf wordpress.org
• WP-CLI: wp post meta delete