- Beiträge, Seiten, Bilder und Menüs bleiben beim Theme-Wechsel vollständig erhalten. Sie liegen in der WordPress-Datenbank, nicht im Theme.
- Verloren gehen Customizer-Einstellungen des alten Themes, theme-spezifische Optionen, Widget-Anordnungen und Custom CSS aus dem Customizer, sofern das neue Theme sie nicht übernimmt.
- Wer einen Page-Builder wie Divi oder Elementor nutzt, steht vor einem anderen Problem: Die Seiteninhalte selbst sind builder-gebunden. Ein Theme-Wechsel wird dort oft zum Teilneuaufbau.
- Sicheres Vorgehen: Backup, Staging-Test, dann produktiv wechseln.
Sie wollen Ihre WordPress-Website neu gestalten und überlegen, das Theme zu wechseln. Die gute Nachricht zuerst: Ihre Inhalte, also Beiträge, Seiten und Bilder, gehören nicht dem Theme. Sie liegen in der WordPress-Datenbank und sind nach dem Wechsel genauso vorhanden wie vorher. Was trotzdem verloren gehen kann und wann ein Theme-Wechsel mehr Aufwand bedeutet als erwartet, erklärt dieser Ratgeber.
Was beim Theme-Wechsel erhalten bleibt
WordPress trennt von Beginn an konsequent zwischen Inhalt und Darstellung. Laut der offiziellen WordPress-Theme-Entwicklerdokumentation steuern Themes ausschließlich die Präsentation von Inhalten („Themes control the presentation of content“). Die Inhalte selbst liegen unabhängig davon in der Datenbank.
Das bedeutet konkret: Alle Beiträge und Seiten mit ihren Inhalten bleiben erhalten. Alle hochgeladenen Bilder und Mediendateien in der WordPress-Mediathek bleiben erhalten. Menüs, die Sie unter Darstellung anlegt haben, bleiben als Menü-Objekte in der Datenbank erhalten, müssen im neuen Theme aber gegebenenfalls den neuen Menü-Positionen zugewiesen werden. Benutzerkonten, Kommentare, Plugins und deren Einstellungen sind vom Theme unabhängig und funktionieren weiter. Custom Post Types und deren Inhalte, sofern sie von einem Plugin kommen, bleiben ebenfalls unangetastet.
Diese Trennung ist eines der Kernprinzipien von WordPress. Ein Theme ist austauschbar, ohne dass der Betreiber seine redaktionellen Inhalte neu erfassen muss.
Was verloren geht und warum
Der WordPress Customizer speichert Einstellungen theme-abhängig. Hintergrundfarbe, benutzerdefiniertes Logo im alten Kontext, Schriftauswahl des alten Themes und ähnliche Optionen werden zwar in der Datenbank hinterlegt, sind aber an das jeweilige Theme geknüpft. Das neue Theme liest sie nicht aus. Es liest seine eigenen Customizer-Einstellungen, die entsprechend leer oder auf Standardwerte gesetzt sind.
Custom CSS aus dem Customizer (Darstellung > Customizer > Zusätzliches CSS) stellt einen Grenzfall dar: Dieses CSS ist in der Datenbank theme-spezifisch gespeichert und geht beim Theme-Wechsel verloren. Zur Sicherheit notieren Sie dieses CSS vor dem Wechsel.
Widget-Bereiche (Sidebars, Footer-Bereiche) sind von jedem Theme selbst registriert. Das neue Theme hat andere Sidebar-Bezeichnungen oder andere Stellen für Widgets. Bestehende Widget-Inhalte landen dann in einem inaktiven „Papierkorb“-Bereich, aus dem Sie sie manuell in die neuen Positionen ziehen müssen.
Theme-Optionen und -Einstellungen gehen komplett verloren, wenn das neue Theme sie nicht kennt. Viele Premium-Themes bieten eigene Einstellungsseiten im Backend (oft unter Darstellung oder einem eigenen Menüpunkt). Diese Einstellungen sind spezifisch für das alte Theme und können vom neuen nicht verwendet werden.
Menü-Positionen müssen neu zugewiesen werden. Die Menüinhalte selbst bleiben erhalten, aber welches Menü an welcher Position im neuen Theme erscheint, müssen Sie nach dem Wechsel unter Darstellung > Menüs neu konfigurieren. Das gilt, weil jedes Theme seine Menü-Positionen selbst benennt und registriert.
Page-Builder-Seiten: der kritische Sonderfall
Hier liegt ein wichtiger Unterschied: Der Builder selbst ist meist ein Plugin, das unabhängig vom Theme läuft. Die mit dem Builder erstellten Inhalte und Daten bleiben in der Datenbank. Was sich ändert, ist das visuelle Ergebnis im Frontend.
Divi ist gleichzeitig Theme und Builder. Wechseln Sie weg von Divi zu einem anderen Theme, gehen die Divi-spezifischen Layouteinstellungen verloren. Der Seiteninhalt liegt im Raw-Format als Divi-Shortcodes in der Datenbank. Diese sind ohne das Divi-Theme oder -Plugin nicht darstellbar und erscheinen im Quelltext als unlesbarer Code-Block. Wenn Sie beim Builder bleiben wollen, besteht die Lösung darin, Divi als Plugin weiter zu verwenden und nur das Child-Theme zu wechseln. Wenn Sie komplett weg von Divi wollen, müssen die Seiten neu aufgebaut werden.
Elementor läuft als eigenständiges Plugin und ist damit theme-unabhängiger. Wechseln Sie das Theme, bleiben Elementor-Seiten grundsätzlich funktionstüchtig, weil Elementor seine eigenen Rendering-Mechanismen mitbringt. Allerdings können Abstände, Schriftgrößen und Farbvoreinstellungen aus dem Elementor-eigenen Style-System überschrieben werden, wenn das neue Theme eigene Stile einbringt. Globale Elementor-Stile und Widget-Einstellungen bleiben erhalten; was sich ändert, ist der Bereich außerhalb des Elementor-Inhaltsbereichs, also Header, Footer und Seitenrahmen.
Gutenberg-Block-Editor ist der WordPress-eigene Editor. Inhalte, die mit Gutenberg erstellt wurden, bleiben beim Theme-Wechsel vollständig erhalten. Das neue Theme kann die Darstellung der Blöcke beeinflussen, aber die Inhalte selbst sind nicht bedroht.
Der Ratgeber Divi vs. Elementor vs. Gutenberg geht tiefer auf die Unterschiede zwischen den Buildern ein.
Übersicht: was bleibt, was geht
| Element | Bleibt erhalten? | Hinweis |
|---|---|---|
| Beiträge und Seiteninhalte | Ja | In der WordPress-Datenbank gespeichert, theme-unabhängig |
| Mediathek (Bilder, Dokumente) | Ja | Liegen im Dateisystem, nicht im Theme |
| Menüs (Inhalte) | Ja, aber Zuweisung weg | Menüpositionen müssen im neuen Theme neu zugewiesen werden |
| Widgets (Inhalte) | Teils, im „Papierkorb“ | Widget-Bereiche des neuen Themes unterscheiden sich, Widgets manuell neu anordnen |
| Customizer-Einstellungen | Nein | Theme-spezifisch gespeichert, neues Theme liest sie nicht aus |
| Custom CSS (Customizer) | Teils | Vor dem Wechsel sichern, Übernahme nicht garantiert |
| Theme-Optionen (eigene Seiten) | Nein | Spezifisch für das alte Theme, gehen beim Wechsel verloren |
| Plugin-Einstellungen | Ja | Plugins laufen unabhängig vom Theme |
| Divi-Layouts (Divi als Theme) | Darstellung verloren | Inhalte in DB, aber ohne Divi als Builder nicht darstellbar |
| Elementor-Seiten | Funktionell ja | Außenbereiche (Header/Footer) ändern sich mit dem Theme |
| Gutenberg-Block-Inhalte | Ja | Theme beeinflusst Darstellung, nicht die Inhalte |
| Custom Post Types (aus Plugins) | Ja | Plugin-gebunden, nicht theme-gebunden |
Sicheres Vorgehen: Schritt für Schritt
Ein Theme-Wechsel ohne Vorbereitung ist ein unnötiges Risiko. Die folgende Reihenfolge hat sich in der Praxis bewährt.
Backup anlegen
Bevor Sie irgendetwas ändern, sichern Sie die gesamte Umgebung: Datenbank und alle Dateien. Automatisierte Backups schützen vor Fehlern, nicht vor einem gezielten Schritt ohne aktuelle Sicherung. Welches Plugin dabei wirklich zuverlässig arbeitet, haben wir in WordPress Backup automatisieren getestet.
Custom CSS notieren
Öffnen Sie Darstellung > Customizer > Zusätzliches CSS und kopieren Sie den gesamten Inhalt in eine Textdatei. Das ist Ihre Sicherung, falls das neue Theme dieses CSS nicht übernimmt.
Theme-Optionen dokumentieren
Falls Ihr altes Theme eine eigene Optionsseite hat, halten Sie alle wichtigen Einstellungen schriftlich fest: Farbpaletten, Schriftauswahl, Layout-Einstellungen, Header/Footer-Konfiguration. Screenshots helfen.
Staging-Umgebung nutzen
Testen Sie den Theme-Wechsel niemals zuerst auf der Live-Website. Eine Staging-Umgebung ist eine Kopie Ihrer Website auf einem separaten Server oder Verzeichnis, auf der kein echter Besucher landet. Dort wechseln Sie das Theme, prüfen jede Seite und lösen Darstellungsprobleme, bevor die Änderung live geht. Warum jede WordPress-Website eine Testkopie braucht, erklärt der Ratgeber zur Staging-Umgebung.
Neues Theme aktivieren und prüfen
Auf dem Staging-System aktivieren Sie das neue Theme und arbeiten eine Prüfliste ab: Alle Seiten-Templates funktionieren? Menüs erscheinen an der richtigen Stelle? Widgets sind korrekt angeordnet? Formulare senden ab? Keine defekten Links oder Bilder?
Customizer und Optionen neu konfigurieren
Im neuen Theme richten Sie den Customizer neu ein: Logo, Farben, Schriften nach Markenrichtlinie. Custom CSS aus Ihrer Sicherung einfügen, soweit noch benötigt. Menü-Positionen den neuen Theme-Slots zuweisen.
Auf Live-System übertragen
Wenn der Staging-Test ohne offene Punkte ist, übertragen Sie die Änderungen auf das Live-System. Der ideale Zeitpunkt ist eine Schwachlast-Phase, also nachts oder am frühen Morgen, wenn wenig Besucher auf der Seite sind.
SEO und Performance beim Theme-Wechsel
Ein Theme-Wechsel ohne URL-Änderungen bedeutet für Google: Die Seiten sind weiterhin unter denselben Adressen erreichbar. Google braucht keine Weiterleitungen und muss keine Signale neu zuordnen. Kurzfristige Schwankungen im Ranking nach dem Wechsel sind normal, weil Google die veränderten Seiten neu crawlt und bewertet. Laut den Google Search Central-Richtlinien zu Site-Moves ist das Monitoring in den ersten Wochen nach einer strukturellen Änderung empfehlenswert, um Crawl-Fehler frühzeitig zu erkennen.
Was SEO tatsächlich schadet: Wenn das neue Theme keine saubere Überschriften-Hierarchie ausgibt (H1 fehlt oder erscheint mehrfach), wenn Seiten durch schlechtes Rendering langsamer werden, wenn strukturierte Daten eines bisherigen SEO-Plugins durch Theme-Code überschrieben werden, oder wenn beim neuen Theme bestimmte Seiten-Templates wegfallen und dadurch URLs nicht mehr antworten. All das ist zu prüfen.
Performance-Aspekte: Manche Themes laden deutlich mehr CSS und JavaScript als nötig. Ein Theme-Wechsel kann Ladezeiten spürbar verbessern oder verschlechtern. Messen Sie die Core Web Vitals vor und nach dem Wechsel, am besten auf dem Staging-System, bevor Sie live gehen.
Für Fortgeschrittene · überspringbar
Profi-Sicht: Classic Theme vs. Block Theme
Ab WordPress 5.9 gibt es zwei grundlegend verschiedene Theme-Typen. Dieser Unterschied ist beim Wechsel relevant.
Classic Themes funktionieren mit PHP-Templates, einer functions.php, Customizer-Unterstützung, Menü-Positionen und Sidebars für Widgets. Fast alle WordPress-Themes vor 2022 und die meisten kommerziellen Premium-Themes fallen in diese Kategorie.
Block Themes (auch Full Site Editing Themes genannt) wurden mit WordPress 5.9 eingeführt. Laut der offiziellen WordPress-Dokumentation zu Block Themes nutzen sie Blöcke für alle Teile der Website, einschließlich Navigationselemente, Header und Footer. Der Customizer ist bei Block Themes nicht verfügbar, weil derselbe Effekt über den Site-Editor erreicht wird. Widgets werden durch Blöcke ersetzt.
Was das konkret bedeutet: Wenn Sie von einem Classic Theme zu einem Block Theme wechseln, verlieren Sie den Customizer als Werkzeug vollständig. Alle Widget-Bereiche des alten Themes werden aufgelöst, Widget-Inhalte landen im inaktiven Bereich. Die neue Oberfläche ist der Site-Editor (Darstellung > Editor), der ein völlig anderes Bedienkonzept mitbringt. Für Nutzer, die mit dem Customizer vertraut sind, ist das ein Lernaufwand, den man einplanen muss.
Der umgekehrte Weg, von Block Theme zu Classic Theme, ist seltener, aber ebenfalls möglich. Hier gehen Site-Editor-Anpassungen verloren, weil Classic Themes den Site-Editor nicht kennen.
Aus der Praxis: wenn der Wechsel zur Baustelle wird
In einem Projekt sahen wir eine mittelständische Kanzlei, die nach fünf Jahren von einem alten Premium-Theme zu einer modernen Variante wechseln wollte. Das alte Theme war ein Classic Theme mit eigenem Page-Builder, einem Vorgänger der heutigen Ansätze. Alle Seiten bestanden aus Theme-eigenen Shortcodes, die das neue Theme nicht kannte.
Das Ergebnis nach dem Theme-Aktivieren auf dem Staging-System: Alle Seiten zeigten statt des Inhalts eine Kolonne unlesbarer Shortcode-Tags. Die Texte selbst waren in der Datenbank vorhanden, konnten aber ohne den alten Builder nicht dargestellt werden. Der „Theme-Wechsel“ war de facto ein Website-Neuaufbau. Die Seiteninhalte wurden aus dem alten Backend abgepflegt und im neuen Theme neu strukturiert.
Das ist kein Einzelfall. Wer ein Theme mit integriertem Page-Builder nutzt, bei dem Layout und Inhalt eng verwoben sind, sollte vor einem Wechsel ehrlich einschätzen, ob ein Neuaufbau effizienter ist als der Versuch, alten Inhalt in ein neues System zu übertragen. Die Erkenntnis aus dem Projekt: Frühzeitig mit einem Staging-Test herausfinden, was übertragbar ist und was nicht, spart die Überraschung nach dem Go-live. Wenn nach dem Ergebnis ein Neuaufbau sinnvoller ist als ein mühsamer Umbau, zeigen wir auf unserer Leistungsseite für Websites und Onlineshops, wie wir neue WordPress-Projekte aufbauen.
Checkliste vor und nach dem Wechsel
Vor dem Theme-Wechsel:
- Vollständiges Backup von Datenbank und Dateien angelegt?
- Custom CSS aus dem Customizer gesichert?
- Alle Theme-Optionen und Einstellungen dokumentiert?
- Menü-Positionen und Widget-Anordnungen notiert?
- Staging-Umgebung eingerichtet und Theme dort zuerst getestet?
- Alle Seiten auf dem Staging-System durchgeklickt und geprüft?
- Formulare, Downloads und spezielle Funktionen getestet?
- Page-Builder-Inhalte auf Kompatibilität geprüft?
- Ladezeiten auf dem Staging-System gemessen?
Nach dem Theme-Wechsel:
- Menüs den neuen Theme-Positionen zugewiesen?
- Widgets in die neuen Bereiche übertragen?
- Custom CSS eingefügt und Darstellung geprüft?
- Logo, Farben und Schriften im neuen Customizer eingerichtet?
- Alle Seiten-Templates auf Darstellungsfehler geprüft?
- Core Web Vitals nach dem Wechsel gemessen?
- Überschriften-Hierarchie auf allen Seiten korrekt?
- Keine defekten internen Links oder Bilder?
- Search Console auf Crawl-Fehler überprüft?
- Inhalte, Bilder und Menüs gehören der WordPress-Datenbank, nicht dem Theme. Sie bleiben beim Wechsel vollständig erhalten.
- Customizer-Einstellungen, Widget-Anordnungen und Theme-Optionen gehen verloren und müssen im neuen Theme neu konfiguriert werden.
- Bei Page-Builder-Seiten ist der Theme-Wechsel komplexer: Divi-Layouts sind builder-gebunden, Elementor-Seiten bleiben funktionell, Gutenberg-Inhalte sind unproblematisch.
- Staging-Test und Backup vor dem Wechsel sind keine optionalen Extras, sondern die Grundbedingung für einen risikofreien Ablauf.
Häufige Fragen
Gehen meine Seiteninhalte beim Theme-Wechsel verloren?
Nein. Beiträge, Seiten und Bilder liegen in der WordPress-Datenbank und sind vom Theme unabhängig. Ein Theme steuert nur die Darstellung, nicht die Inhalte selbst.
Was passiert mit meinen Menüs nach dem Theme-Wechsel?
Die Menüinhalte bleiben gespeichert. Was sich ändert: Das neue Theme registriert eigene Menü-Positionen mit eigenen Namen. Sie müssen nach dem Wechsel unter Darstellung > Menüs manuell festlegen, welches Menü an welcher Position erscheint.
Gehen Customizer-Einstellungen verloren?
Ja. Customizer-Einstellungen wie Farben, Hintergrundbilder oder theme-spezifische Optionen sind an das jeweilige Theme gebunden. Das neue Theme liest sie nicht aus und startet mit seinen eigenen Standardeinstellungen.
Was passiert mit meinen Widgets?
Widget-Inhalte bleiben in der Datenbank, aber die Sidebar-Bezeichnungen ändern sich mit dem Theme. Bestehende Widgets landen in einem inaktiven Bereich und müssen manuell in die neuen Widget-Positionen des neuen Themes übertragen werden.
Ich nutze Divi. Was passiert, wenn ich das Theme wechsle?
Divi ist gleichzeitig Theme und Builder. Wenn Sie weg von Divi wechseln, sind die Seiteninhalte zwar in der Datenbank vorhanden, aber als Divi-Shortcodes gespeichert. Ohne Divi als Theme oder Plugin sind diese nicht darstellbar. Ein Wechsel weg von Divi bedeutet in der Regel, die mit Divi aufgebauten Seiten neu erstellen zu müssen.
Hat ein Theme-Wechsel Auswirkungen auf mein Google-Ranking?
Bei einem Wechsel ohne URL-Änderungen sind die direkten SEO-Auswirkungen begrenzt. Kurzfristige Schwankungen sind möglich, während Google die veränderten Seiten neu bewertet. Kritisch wird es, wenn das neue Theme die Seitenstruktur, Ladezeiten oder die Überschriften-Hierarchie verschlechtert. Mehr zu SEO bei Relaunches im Ratgeber zu Content-Migration beim Relaunch.
Kann ich ein Theme auch ohne Staging direkt wechseln?
Technisch ja, aber es ist nicht empfehlenswert. Ohne Staging-Test sehen alle Besucher sofort die unfertige oder fehlerhafte Darstellung. Besonders bei komplexen Seiten mit Page-Builder oder vielen Plugins ist der Staging-Test die einzige Möglichkeit, Probleme zu erkennen, bevor sie live gehen.
Was ist der Unterschied zwischen einem Classic Theme und einem Block Theme?
Classic Themes nutzen PHP-Templates, Customizer, Sidebars und Menü-Positionen. Block Themes, eingeführt mit WordPress 5.9, nutzen Blöcke für alle Seitenbereiche und den Site-Editor statt des Customizers. Ein Wechsel zwischen diesen zwei Typen ist technisch anspruchsvoller als ein Wechsel innerhalb derselben Kategorie.