Von Elementor, Divi oder WPBakery zu Bricks

Die kurze Antwort: Einen Knopf, der Elementor-, Divi- oder WPBakery-Seiten verlässlich in saubere Bricks-Seiten verwandelt, kennen wir nicht. Ein Wechsel zu Bricks heißt, die Layouts neu zu bauen. Die Inhalte dagegen ziehen nicht um, sie bleiben in WordPress: Seiten, Beiträge, Medien, Benutzer und die Angaben aus dem SEO-Plugin liegen in der WordPress-Datenbank und überstehen den Wechsel des Builders. Ausnahme sind Daten, die eine Erweiterung des Builders selbst verwaltet, etwa Einträge aus dessen Formularen.

Datenverlust entsteht deshalb nicht beim Wechsel selbst, sondern beim Aufräumen danach. Wer den alten Builder deaktiviert, bevor alle Inhalte aus seinen Layouts herausgeholt sind, findet auf manchen Seiten nur noch Code-Schnipsel statt Text, oder gar nichts mehr. Wie groß dieses Risiko ist, hängt davon ab, wie der jeweilige Builder speichert.

Bei Elementor zum Beispiel landen Layout und Inhalt beim Speichern als JSON in den Metadaten des Beitrags, also in einem benutzerdefinierten Feld ^[1]. Elementor hat dieses Format standardisiert, damit sich Seiten exportieren und in andere Installationen importieren lassen ^[1]. Für einen Umbau ist das hilfreich: Die Texte lassen sich strukturiert auslesen, statt sie Seite für Seite aus dem Frontend zu kopieren. Bei WPBakery und älteren Divi-Versionen stecken die Inhalte dagegen zwischen Shortcodes im normalen Beitragstext ^[2][3].

Warum Agenturen überhaupt wechseln: meist, weil eine Seite ohnehin neu gestaltet werden soll und man die Gelegenheit nutzt, Ballast loszuwerden. Bricks erzeugt schlanken, semantischen Code, und mit eigenen Inhaltstypen für wiederkehrende Inhalte wird die Seite danach leichter zu pflegen. Wie wir das aufbauen, steht unter WordPress mit Bricks ohne Lock-in. Der alte Builder war dabei kein Fehler. Er passt nur nicht mehr zu dem, was die Seite heute können soll.

Shortcode-Reste. Bei WPBakery und älteren Divi-Seiten bleiben nach dem Deaktivieren eckige Klammern im Text stehen ^[2][3]. Auf den großen Seiten fällt das auf, in alten Blogbeiträgen oft erst Monate später. Wir suchen deshalb die ganze Datenbank nach Resten ab, nicht nur die Seiten im Menü.

Erweiterungen des Builders. Slider, Popups, Formulare und Mega-Menüs kommen häufig aus Zusatzpaketen zum Builder. Fallen diese weg, fehlt die Funktion, nicht nur die Optik. Jedes davon braucht einen Ersatz, im besten Fall eine Bricks-Funktion statt eines weiteren Plugins.

Globale Teile. Kopf- und Fußzeilen, Archivseiten und Vorlagen für Beiträge sind im alten Builder oft als eigene Vorlagen angelegt. Sie stehen in keinem Seitenbaum und werden leicht vergessen.

Eigenes CSS und Skripte. Anpassungen in den Einstellungen des Builders, Tracking-Codes, Einbettungen von Karten oder Buchungstools: alles, was nicht im Inhalt steht, muss ausdrücklich übernommen werden.

Adressen. Ändert sich beim Umbau die Seitenstruktur, braucht jede alte Adresse eine Weiterleitung, sonst gehen Links und Suchergebnisse ins Leere. Weiterleitungen gehören bei uns zum Livegang.