WordPress-Migration: Domain, Hosting, Datenbank und... | WPPoland

Mariusz Szatkowski

WordPress-Migrationsleitfaden 2024

Zuletzt überprüft: 13. Oktober 2026

24 Min. Lesezeit

Tutorial

Full-Stack-Entwickler

500+ WP-Projekte

Das Verschieben Ihrer WordPress-Website kann eine entmutigende Aufgabe sein, aber mit dem richtigen Wissen und der richtigen Vorbereitung wird sie zu einem überschaubaren Prozess. Ob Sie Domains wechseln, Ihr Hosting upgraden oder Ihre Website-Architektur umstrukturieren, dieser umfassende Leitfaden führt Sie durch jeden Schritt des WordPress-Migrationsprozesses.

#Verständnis der WordPress-Site-URLs

Bevor wir uns mit den Migrationstechniken befassen, ist es entscheidend, die zwei grundlegenden URL-Einstellungen in WordPress zu verstehen:

WordPress-Adresse (URL): Hier befinden sich Ihre WordPress-Kerndateien
Site-Adresse (URL): Dies ist die Adresse, die Besucher in ihren Browser eingeben, um Ihre Website zu erreichen

Beide Einstellungen sollten den https://-Teil enthalten und dürfen keinen abschließenden Schrägstrich / am Ende haben. Diese Einstellungen steuern, wie WordPress URLs auf Ihrer gesamten Website anzeigt, einschließlich des Admin-Bereichs und des Frontends.

#Warum WordPress-Migration notwendig wird

Mehrere Szenarien könnten erfordern, dass Sie Ihre WordPress-Website migrieren:

Domain-Änderungen: Rebranding oder Wechsel zu einem besseren Domainnamen
Hosting-Migration: Wechsel zu einem besseren Hosting-Anbieter
Server-Änderungen: Upgrade der Server-Infrastruktur
Site-Restrukturierung: Verschieben von WordPress in ein Unterverzeichnis oder das Root-Verzeichnis
Entwicklung zu Produktion: Verschieben von Staging zu Live-Umgebung
HTTP zu HTTPS: Implementierung von SSL-Zertifikaten

#WordPress-Migration vorbereiten mit Backup und Staging

#Was vor der WordPress-Migration gesichert werden muss

Bevor Sie eine Migration versuchen, erstellen Sie umfassende Sicherungen:

Datenbank-Sicherung: Exportieren Sie Ihre WordPress-Datenbank über phpMyAdmin oder WP-CLI
Datei-Sicherung: Laden Sie alle WordPress-Dateien und Verzeichnisse herunter
Konfigurations-Sicherung: Speichern Sie Ihre wp-config.php-Datei separat
Plugin/Theme-Einstellungen: Dokumentieren Sie benutzerdefinierte Konfigurationen

#Testumgebung einrichten

Testen Sie Migrationen immer in einer Staging-Umgebung, bevor Sie live gehen:

## Test-Unterverzeichnis erstellen
mkdir /var/www/html/test-site
## WordPress-Dateien in Test-Staging kopieren
cp -r /var/www/html/wordpress/* /var/www/html/test-site/

#WordPress-Site-URL nach dem Umzug ändern

#Methode 1: WP_HOME und WP_SITEURL in der wp-config.php setzen

Für temporäre URL-Änderungen fügen Sie diese Zeilen zu Ihrer wp-config.php hinzu:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Vorteile: Schnell und sofort Nachteile: Hardcodierte Werte, können nicht mehr in WordPress Admin bearbeitet werden

#Methode 2: siteurl und home über die functions.php ändern

Wenn Sie FTP-Zugang haben, aber nicht auf WordPress Admin zugreifen können:

Greifen Sie auf die functions.php-Datei Ihres aktiven Themes zu
Fügen Sie diese Zeilen nach dem öffnenden <?php-Tag hinzu:

update_option('siteurl', 'https://example.com');
update_option('home', 'https://example.com');

Laden Sie die Datei hoch und besuchen Sie Ihr Admin-Panel
Wichtig: Entfernen Sie diese Zeilen, nachdem die Website funktioniert

#Methode 3: die RELOCATE-Konstante in der wp-config.php

WordPress enthält eine automatische Relocate-Methode:

Bearbeiten Sie wp-config.php und fügen Sie vor “That’s all, stop editing!” hinzu:

define('RELOCATE', true);

Besuchen Sie https://yoursite.com/wp-login.php
Melden Sie sich normal an
Überprüfen Sie Einstellungen > Allgemein, um URLs zu verifizieren
Entfernen Sie die RELOCATE-Konstante danach

Sicherheitswarnung: Lassen Sie die RELOCATE-Konstante niemals in wp-config.php, da sie Sicherheitslücken schafft.

#Methode 4: siteurl und home in phpMyAdmin bearbeiten

Für präzise Kontrolle bearbeiten Sie URLs direkt in der Datenbank:

Greifen Sie auf phpMyAdmin zu
Wählen Sie Ihre WordPress-Datenbank
Finden Sie die wp_options-Tabelle (Präfix kann variieren)
Bearbeiten Sie die Zeilen ‘siteurl’ und ‘home’
Aktualisieren Sie option_value auf neue URLs

Kritisch: Sichern Sie immer Ihre Datenbank vor direkten Bearbeitungen!

#WordPress auf neuen Server oder neue Domain umziehen

#Verschieben zwischen Servern

Bei der Migration zu einem neuen Server:

Alles sichern: Vollständige Site- und Datenbank-Sicherung
Datenbank exportieren: Verwenden Sie phpMyAdmin oder WP-CLI
Dateien übertragen: Verwenden Sie FTP, SFTP oder rsync
Datenbank importieren: Erstellen Sie neue Datenbank und importieren
wp-config.php aktualisieren: Datenbank-Anmeldeinformationen ändern
URLs aktualisieren: Verwenden Sie eine der obigen Methoden
Gründlich testen: Überprüfen Sie alle Funktionalitäten

#Domain-Namensänderungen

Domain-Änderungen erfordern besondere Aufmerksamkeit für serialisierte Daten:

## WP-CLI verwenden (empfohlen)
wp search-replace 'altdomain.com' 'neuedomain.com' --skip-columns=guid

## Oder spezialisierte Plugins wie:
## - Better Search Replace

Wichtig: Aktualisieren Sie niemals die GUID-Spalte in der wp_posts-Tabelle. GUID steht für Global Unique Identifier und darf niemals geändert werden, um die Kompatibilität mit Feed-Readern zu erhalten.

#Migration von Unterverzeichnis zu Root

Verschieben von WordPress von einem Unterverzeichnis zum Root:

URLs in WordPress Admin aktualisieren: Einstellungen > Allgemein
Dateien kopieren: WordPress-Dateien an neuen Speicherort verschieben
.htaccess aktualisieren: Rewrite-Regeln ändern
Permalinks aktualisieren: Permalink-Struktur neu speichern
Interne Links überprüfen: Hardcodierte URLs aktualisieren

#Multisite-Migration

WordPress Multisite erfordert zusätzliche Überlegungen:

Netzwerk sichern: Alle Sites und Datenbanken
wp-config.php bearbeiten: Multisite-Konstanten aktualisieren
.htaccess aktualisieren: Multisite-Rewrite-Regeln ändern
Datenbank-Updates: wp_blogs und wp_site Tabellen aktualisieren
Optionen einzelner Sites: Options-Tabellen jeder Site aktualisieren

#Checkliste nach dem WordPress-Umzug

#Was direkt nach dem Umzug getestet werden muss

Frontend-Funktionalität testen
Admin-Zugang überprüfen
Alle Formulare und Übermittlungen überprüfen
E-Commerce-Funktionalität testen
Benutzer-Login/Registrierung überprüfen

#301-Weiterleitungen und Sitemap nach dem Domainwechsel

301-Weiterleitungen von alten URLs implementieren
sitemap.xml aktualisieren
Neue Sitemap an Suchmaschinen senden
Google Analytics-Eigenschaft aktualisieren
Google Search Console überprüfen

#Cache, Datenbank und SSL nach dem Umzug prüfen

#Häufige Migrationsprobleme und Lösungen

#White Screen of Death

Normalerweise verursacht durch:

Speicherlimit-Erschöpfung
Plugin-Konflikte
Theme-Inkompatibilität

Lösung: Speicherlimit in wp-config.php erhöhen:

define('WP_MEMORY_LIMIT', '256M');

#Fehler beim Aufbau einer Datenbankverbindung nach dem Umzug

Überprüfen Sie wp-config.php-Einstellungen:

define('DB_NAME', 'database_name');
define('DB_USER', 'username');
define('DB_PASSWORD', 'password');
define('DB_HOST', 'localhost');

#Mixed Content-Probleme

HTTP-Ressourcen auf HTTPS-Seiten verursachen Sicherheitswarnungen:

## Mixed Content finden
grep -r "http://" wp-content/

#Bild- und Medien-Link-Probleme

Medien-URLs in Datenbank aktualisieren:

UPDATE wp_posts SET post_content = REPLACE(post_content,'altdomain.com/wp-content/uploads','neuedomain.com/wp-content/uploads');

#Werkzeuge und Plugins für Migration

#Empfohlene Migrations-Plugins

All-in-One WP Migration: Vollständiges Site-Migrationswerkzeug
Duplicator: Migrationspakete einfach erstellen
WP Migrate Lite (früher WP Migrate DB): Datenbank-Export mit Suchen und Ersetzen
Better Search Replace: Suchen und Ersetzen im Dashboard, mit Unterstützung für serialisierte Daten (Velvet Blues Update URLs ist seit dem 3. Mai 2024 im Plugin-Verzeichnis geschlossen)
Migrator: Backup und Migration als eine Datei, ohne künstliches Größenlimit (laut FAQ von All-in-One WP Migration kommt das Import-Limit von der Upload-Grenze des Hosters, nicht vom Plugin) und mit serialisierungssicherer URL-Ersetzung. Siehe die Anleitung zu Backup und Migration.

#WP-CLI-Befehle für Export, Import und Suchen-Ersetzen

## WP-CLI Datenbank-Export
wp db export backup.sql

## WP-CLI Datenbank-Import
wp db import backup.sql

## Suchen und Ersetzen
wp search-replace 'alte-url' 'neue-url' --dry-run

#Sicherheits-Checkliste für die WordPress-Migration

HTTPS verwenden: Sicherstellen, dass SSL auf neuem Server konfiguriert ist
Dateiberechtigungen aktualisieren: wp-config.php (600) und Verzeichnisse (755) sichern
Migrationsskripte entfernen: Temporäre Dateien und Konstanten löschen
Sicherheitsschlüssel aktualisieren: Neue WordPress-Schlüssel in wp-config.php generieren
Logs überwachen: Auf ungewöhnliche Aktivität nach Migration achten

#WordPress nach dem Umzug schneller machen

#Datenbanktabellen mit OPTIMIZE TABLE optimieren

OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Caching und CDN auf dem neuen Server einrichten

Page-Caching konfigurieren
Browser-Caching einrichten
CDN-Integration aktivieren
Datenbank-Caching optimieren

#WordPress nach der Migration testen

#Menüs, Formulare, Suche und Medien testen

Navigation: Alle Menüpunkte funktionieren korrekt
Formulare: Kontaktformulare und Übermittlungen funktionieren
Suche: Site-Suche liefert Ergebnisse
Kommentare: Kommentarsystem funktioniert
Medien: Bilder und Videos laden korrekt

#Meta-Tags, Canonical-URLs und Schema prüfen

Meta-Tags: Titel und Beschreibungen werden korrekt angezeigt
Kanonische URLs: Zeigen auf neue Domain
Strukturierte Daten: Schema-Markup validiert
Interne Links: Alle Links funktionieren und leiten korrekt weiter

#WordPress nach dem Umzug überwachen

#Uptime, Search Console und 404-Fehler überwachen

Uptime-Überwachung einrichten
Google Search Console auf Fehler überwachen
Traffic-Muster in Analytics verfolgen
404-Fehler in Logs überwachen

#Laufende Wartung nach dem Umzug

Regelmäßige Datenbank-Optimierung
Bild-Optimierung und Kompression
Plugin-Leistungsüberwachung
Sicherheits-Scan-Implementierung

#WordPress ohne Downtime umziehen per DNS-TTL

Ein Resolver darf einen DNS-Eintrag so lange zwischenspeichern, wie seine TTL es erlaubt (RFC 1035, Abschnitt 3.2.1). Daraus ergibt sich die Reihenfolge:

TTL rechtzeitig absenken. Setzen Sie die A- und AAAA-Records auf eine kurze TTL, zum Beispiel 300 Sekunden, und zwar mindestens eine volle alte TTL vor dem Umschalten. Lag der alte Wert bei 86400 Sekunden, heißt das einen Tag vorher, denn bis dahin liefern Resolver weiter die alte IP aus.
Neuen Server über die hosts-Datei testen. Tragen Sie die Domain mit der neuen IP in die lokale hosts-Datei ein und prüfen Sie Checkout, Login und Formulare auf dem Zielserver, bevor der öffentliche Eintrag sich ändert. Besucher landen weiterhin auf dem alten Server.
Schreibzugriffe für den letzten Dump einfrieren. Bestellungen, Kommentare und Formulareingaben, die nach dem letzten wp db export auf dem alten Server eingehen, kommen nicht mit. Versetzen Sie die alte Site für den finalen Export und Import in den Wartungsmodus oder stoppen Sie die Veröffentlichung.

#Große Medienbibliothek mit rsync übertragen

FTP kopiert bei jedem Versuch jede Datei neu. rsync über SSH vergleicht Quelle und Ziel und überträgt nur die Unterschiede, ein zweiter Lauf bewegt also nur, was sich seit dem ersten geändert hat (rsync-Handbuch).

Zweimal laufen lassen. Der erste Durchgang kopiert wp-content/uploads, während die alte Site noch live ist. Der zweite Durchgang während des Schreibstopps holt die zwischenzeitlich hinzugekommenen Dateien nach.
URLs mit WP-CLI ersetzen, nicht mit SQL. WordPress speichert Optionen und Widget-Einstellungen als serialisierte PHP-Arrays mit Zeichenlängen. wp search-replace schreibt diese Längen neu, ein einfaches SQL-REPLACE() nicht.
Vorschaubilder neu erzeugen, wenn sich das Theme ändert. wp media regenerate erzeugt die Vorschaubilder für die auf der neuen Installation registrierten Bildgrößen neu, --only-missing beschränkt das auf Bilder, denen Größen fehlen (WP-CLI: wp media regenerate).

#SEO, SSL und Core Web Vitals nach dem Umzug prüfen

Die alte URL-Liste crawlen. Jede alte URL sollte mit einem 301 auf ihr neues Gegenstück antworten, und kein interner Link darf einen 404 liefern. Google empfiehlt für einen Website-Umzug serverseitige permanente Weiterleitungen von den alten auf die neuen URLs und bei einem Domainwechsel eine Adressänderung in der Search Console (Google Search Central: Website-Umzug mit URL-Änderungen).
TLS und HSTS. Installieren Sie das Zertifikat vor dem Umschalten auf dem neuen Server. HTTP Strict Transport Security zwingt Browser für die gesamte max-age-Dauer auf HTTPS für die Domain (RFC 6797), aktivieren Sie es also erst, wenn HTTPS auf jeder abgedeckten Subdomain funktioniert.
Vorher und nachher messen. Testen Sie mit PageSpeed Insights dieselben Templates auf dem alten und dem neuen Server. Page-Cache, OPcache, Object-Cache und gzip- oder Brotli-Kompression des neuen Hosts zeigen sich in der Server-Antwortzeit.

#Datenschutz und DSGVO-Konformität bei Server- und Standortwechseln

Für eine Website eines Unternehmens in der EU ist ein neuer Hoster auch ein neuer Auftragsverarbeiter:

Auftragsverarbeitungsvertrag mit dem neuen Hoster. Art. 28 DSGVO verlangt einen Vertrag, der Gegenstand, Dauer, Art und Zweck der Verarbeitung festlegt und den Auftragsverarbeiter auf die Sicherheitsmaßnahmen nach Art. 32 verpflichtet (DSGVO, Verordnung (EU) 2016/679).
Datenschutzerklärung anpassen. Kommen mit dem Umzug ein CDN, ein neuer Backup-Standort oder ein neuer Hoster hinzu, ändert sich die Liste der Empfänger in der Datenschutzerklärung mit.
Löschung beim alten Hoster. Nach Art. 28 Abs. 3 lit. g löscht der Auftragsverarbeiter nach Ende der Leistung die personenbezogenen Daten oder gibt sie zurück, nach Wahl des Verantwortlichen. Sobald der neue Server stabil läuft, lassen Sie sich vom alten Hoster bestätigen, dass Dateien, Datenbanken und Backups gelöscht sind.

#WordPress-Deployment per GitHub Actions mit Rollback

Aus dem Repository deployen. Ein Workflow in GitHub Actions oder GitLab CI baut die Theme-Assets und liefert den Code bei jedem Push auf den Hauptbranch aus, auf dem Server liegen also keine von Hand geänderten Dateien.
Das vorherige Release behalten. Jedes Release landet in einem eigenen Verzeichnis, ein Symlink zeigt auf das aktive. Ein Code-Rollback heißt, den Symlink auf das vorherige Release zu setzen. Machen Sie vor jedem Schritt, der die Datenbank ändert, ein wp db export, denn ein Code-Rollback macht Änderungen an Tabellen oder Inhalten nicht rückgängig.
Überall dieselben Versionen. Gleichen Sie PHP- und MySQL- oder MariaDB-Versionen zwischen lokal, Staging und Produktion ab, damit sich eine auf Staging getestete Migration in der Produktion genauso verhält.

#Wie wp search-replace serialisierte Daten behandelt

Das WordPress-Handbuch warnt, dass ein pauschales Suchen und Ersetzen über die Datenbank serialisierte Daten beschädigen kann und dass die guid-Spalte in wp_posts nie geändert werden darf (Moving WordPress). wp search-replace ist für genau diesen Fall gebaut: Es behandelt serialisierte PHP-Daten und ändert keine Primärschlüsselwerte (WP-CLI: wp search-replace). Die Flags, die bei einer Migration zählen:

--dry-run meldet, was sich ändern würde, und speichert nichts.
--skip-columns=guid lässt die GUIDs der Beiträge unverändert.
--precise erzwingt die PHP-Verarbeitung für jede Spalte. Das ist langsamer und bei komplexen serialisierten Daten zuverlässiger.
--network erfasst alle Tabellen eines Multisite-Netzwerks. Ohne das Flag werden nur die Tabellen der aktuellen Site durchsucht.
--all-tables-with-prefix nimmt Tabellen hinzu, die Plugins mit dem WordPress-Präfix angelegt, aber nicht registriert haben, und --all-tables nimmt jede Tabelle der Datenbank.
--export=datei.sql schreibt die geänderten Daten in eine SQL-Datei statt in die Datenbank, was hilft, wenn die Zieldatenbank auf einem anderen Server liegt.

Tabellen ohne Primärschlüssel werden übersprungen, eine Plugin-Tabelle ohne Primärschlüssel braucht also eine eigene Prüfung. Für Multisite nennt das Handbuch außerdem, was von Hand zu prüfen ist: die Tabellen wp_blogs und wp_site sowie die Optionen home, siteurl und fileupload_url jeder Site.

wp db export und wp db import runden das ab. Der Export ruft mysqldump mit den Zugangsdaten aus der wp-config.php auf und nimmt jedes mysqldump-Flag an, wp db export - schreibt nach STDOUT (WP-CLI: wp db export). Der Import legt die Datenbank nicht an, er führt nur das SQL aus der Datei aus, und wp db import - liest von STDIN (WP-CLI: wp db import). Legen Sie die leere Datenbank auf dem Ziel also vorher an.

#Zusammenfassung

WordPress-Migration muss nicht überwältigend sein, wenn sie systematisch angegangen wird. Durch Befolgen dieses umfassenden Leitfadens, gründliche Vorbereitung und sorgfältiges Testen können Sie Ihre WordPress-Website erfolgreich mit minimaler Unterbrechung für Ihre Benutzer und SEO-Leistung migrieren.

Denken Sie daran, dass Vorbereitung der Schlüssel ist, versuchen Sie niemals eine Migration ohne vollständige Sicherungen und einen klaren Rollback-Plan. Nehmen Sie sich Zeit, testen Sie gründlich und zögern Sie nicht, professionelle Hilfe für komplexe Migrationen zu suchen.

Mit richtiger Planung und Ausführung kann Ihre WordPress-Migration ein reibungsloser Prozess sein, der Ihre Website für zukünftiges Wachstum und Erfolg vorbereitet.

#Fallstudien zur WordPress-Migration

#Fallstudie 1: Shop mit 50.000 Produkten auf neue Domain umziehen

Szenario: Ein beliebter Online-Shop mit 50.000+ Produkten musste von shop-alt.com zu brandneu.com migrieren, während SEO-Rankings und Kundenvertrauen erhalten blieben.

Herausforderungen:

Massive Produktdatenbank mit komplexen Variationen
Aktive Warenkorb-Sitzungen während der Migration
Drittanbieter-Zahlungs-Gateway-Integrationen
Kunden-E-Mail-Kampagnen mit alten Domain-Links

Migrationsstrategie:

Vorbereitung vor der Migration (2 Wochen):
- Komplette Site-Sicherung einschließlich Kundendaten erstellt
- Temporäres Staging-Umgebung eingerichtet
- Alle Zahlungs-Gateway-Integrationen getestet
- E-Mail-Vorlagen für Kundenbenachrichtigung vorbereitet
Technische Implementierung (4 Stunden):
- WP-CLI für Datenbank-URL-Ersetzung verwendet
- Benutzerdefinierte 301-Redirect-Regeln implementiert
- Alle Drittanbieter-API-Endpunkte aktualisiert
- SSL-Zertifikat für neue Domain konfiguriert
Optimierung nach der Migration (1 Woche):
- Google Search Console auf Indexierungsprobleme überwacht
- Alle Marketing-Automatisierungs-Workflows aktualisiert
- Verbessertes Tracking für Migrationsauswirkungen implementiert
- Kundenzufriedenheitsumfrage durchgeführt

Ergebnisse:

Nahezu alle SEO-Rankings innerhalb von 2 Wochen erhalten
Kein Datenverlust während der Migration
Kundenbeschwerden durch angemessene Kommunikation deutlich reduziert
Geschwindigkeitssteigerung durch neue Hosting-Infrastruktur

Wichtige Lektionen:

Kundenkommunikation ist genauso wichtig wie technische Ausführung
Testen von Zahlungs-Gateways in Staging-Umgebung verhindert Umsatzverluste
Bereitstellung eines Rollback-Plans gibt Vertrauen während der Ausführung

#Fallstudie 2: Multisite mit 200 Sites in die Cloud umziehen

Szenario: Eine Bildungseinrichtung mit 200+ Subdomain-Sites musste von Shared Hosting zu dedizierter Cloud-Infrastruktur migrieren.

Technische Komplexität:

201 individuelle WordPress-Sites
Benutzerdefinierte Benutzerrollen und Berechtigungen zwischen Sites
Geteilte Mediathek mit 100GB+ Inhalt
Komplexe Plugin-Abhängigkeiten zwischen Sites

Migrationsansatz:

Netzwerkanalyse-Phase:
- Alle Site-Interdependenzen kartiert
- Benutzerdefinierte Plugin-Konfigurationen identifiziert
- Benutzerrollenhierarchien dokumentiert
- Mediathek-Nutzungsmuster analysiert
Staging-Umgebungseinrichtung:
- Exakte Serverkonfiguration repliziert
- Automatisierte Test-Skripte erstellt
- Leistungsüberwachung implementiert
- Rollback-Verfahren eingerichtet
Phasenmigration:
- Zuerst 10 Pilot-Sites migriert
- Prozess dokumentiert und verfeinert
- Verbleibende Sites in Batches migriert
- Kontinuierliche Überwachung und Optimierung

Technische Lösungen:

## Benutzerdefiniertes Skript für Batch-Multisite-Migration
#!/bin/bash
for site in $(wp site list --field=url); do
    echo "Migriere $site"
    wp search-replace 'alte-domain.com' 'neue-domain.com' --url=$site
    wp cache flush --url=$site
done

Ergebnisse:

99,8% Uptime während des Migrationsprozesses
40% Verbesserung der Seitenladezeiten
Keine Datenkorruption auf allen Sites
Vereinfachte Administration durch zentrale Verwaltung

#Fallstudie 3: Blog auf HTTPS umstellen und Mixed Content beheben

Szenario: Ein inhaltsreicher Blog mit 10.000+ Beiträgen und umfangreicher Mediathek benötigte HTTPS-Implementierung.

Mixed-Content-Herausforderungen:

Hardcodierte HTTP-Links in Beitragsinhalten
Externe Ressourcen ohne HTTPS-Alternativen
Eingebettete Iframes von nicht-sicheren Quellen
Benutzerdefiniertes CSS mit HTTP-Referenzen

Umfassende Lösung:

Inhaltsprüfung und -bereinigung:

-- HTTP-Referenzen in Beiträgen finden und ersetzen
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://beispiel.com', 'https://beispiel.com')
WHERE post_content LIKE '%http://beispiel.com%';

-- Die guid-Spalte nicht anfassen: laut WordPress-Doku nie ändern

Plugin-Konfigurationsaktualisierungen:

// Benutzerdefinierte functions.php-Ergänzungen für HTTPS-Erzwingung
add_action('template_redirect', function() {
    if (!is_ssl() && !is_admin()) {
        wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301);
        exit;
    }
});

Erweiterte .htaccess-Konfiguration:

## HTTPS für gesamten Verkehr erzwingen
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Leistungsauswirkung:

Anfänglicher 5% Traffic-Rückgang in der ersten Woche
Vollständige Erholung innerhalb von 3 Wochen
10% Verbesserung der Suchrankings
Verbesserte Benutzer-Vertrauens- und Sicherheitsmetriken

#Große WordPress-Datenbank migrieren

#Datenbank-Migrationsoptimierungsstrategien

#Effiziente Handhabung großer Datenbanken

Für Datenbanken über 1GB versagen Standard-Export/Import-Methoden oft. Hier fortgeschrittene Techniken:

Methode 1: Chunked Export mit WP-CLI

## In Chunks für große Datenbanken exportieren
wp db export chunk1.sql --tables=wp_posts,wp_postmeta --add-drop-table
wp db export chunk2.sql --tables=wp_options,wp_users,wp_usermeta --add-drop-table

## Getrennt kombinieren und importieren
mysql neue_datenbank < chunk1.sql
mysql neue_datenbank < chunk2.sql

Methode 2: Dump per gzip streamen statt eigenes PHP-Skript

## Dump direkt in gzip streamen, keine unkomprimierte Datei auf der Platte
wp db export - --single-transaction --quick | gzip > db.sql.gz

## Auf dem Zielserver aus STDIN importieren
gunzip < db.sql.gz | wp db import -

#Serialisierte Datenbehandlung

WordPress speichert viele Einstellungen als serialisierte PHP-Daten, die bei URL-Längenänderungen brechen:

Serialisierungssichere Ersetzung mit WP-CLI:

## Erst Vorschau, dann ohne --dry-run ausführen
wp search-replace 'https://altdomain.com' 'https://neuedomain.com' --skip-columns=guid --precise --dry-run
wp search-replace 'https://altdomain.com' 'https://neuedomain.com' --skip-columns=guid --precise

#Entwicklung benutzerdefinierter Migrationsskripte

#Automatisierungs-Framework für Migration

Erstellen Sie ein umfassendes Migrationsautomatisierungsskript:

#!/bin/bash
## WordPress-Migrationsautomatisierungsskript

set -e  # Bei jedem Fehler beenden

## Konfiguration
OLD_DOMAIN="alte-site.com"
NEW_DOMAIN="neue-site.com"
BACKUP_DIR="/pfad/zu/backups"
STAGING_DIR="/pfad/zu/staging"
LOG_FILE="$BACKUP_DIR/migration_$(date +%Y%m%d_%H%M%S).log"

## Logging-Funktion
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

## Checkliste für WordPress-Vor-Migrationsprüfungen
pre_migration_checks() {
    log "Starte Vor-Migrationsprüfungen"

    # WordPress-Installation prüfen
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: WordPress-Installation nicht gefunden"
        exit 1
    fi

    # Datenbankverbindung prüfen
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Datenbankverbindung fehlgeschlagen"
        exit 1
    fi

    # Erforderliche Plugins aktiv prüfen
    if ! wp plugin is-active all-in-one-wp-migration --path=/var/www/html; then
        log "ERROR: Erforderliches Migrations-Plugin nicht aktiv"
        exit 1
    fi

    log "Vor-Migrationsprüfungen abgeschlossen"
}

## Deployment-Backup erstellen
create_deployment_backup() {
    log "Erstelle Deployment-Backup"

    local timestamp=$(date +%Y%m%d_%H%M%S)
    local backup_file="$BACKUP_DIR/pre_deploy_$timestamp.sql"

    wp db export "$backup_file" --path=/var/www/html

    # Backup-Integrität verifizieren
    if [ -s "$backup_file" ] && tail -n 1 "$backup_file" | grep -q "Dump completed"; then
        log "Backup erstellt und verifiziert: $backup_file"
    else
        log "ERROR: Backup-Erstellung fehlgeschlagen"
        exit 1
    fi
}

## Migration ausführen
execute_migration() {
    log "Führe WordPress-Migration aus"

    # Site-URLs bei Bedarf aktualisieren
    if [ "$ENVIRONMENT" = "production" ]; then
        wp search-replace "staging.beispiel.com" "beispiel.com" --skip-columns=guid --path=/var/www/html
    fi

    # Alle Caches leeren
    wp cache flush --path=/var/www/html

    # Rewrite-Regeln aktualisieren
    wp rewrite flush --path=/var/www/html

    log "Migration abgeschlossen"
}

## Post-Deployment-Validierung
post_deployment_validation() {
    log "Starte Post-Deployment-Validierung"

    # Site-Zugänglichkeit prüfen
    local site_url=$(wp option get siteurl --path=/var/www/html)

    if curl -f -s "$site_url" > /dev/null; then
        log "Site ist zugänglich: $site_url"
    else
        log "ERROR: Site ist nicht zugänglich"
        exit 1
    fi

    # WordPress-Admin prüfen
    if curl -f -s "$site_url/wp-admin/" > /dev/null; then
        log "WordPress-Admin ist zugänglich"
    else
        log "ERROR: WordPress-Admin ist nicht zugänglich"
        exit 1
    fi

    # Datenbankintegrität verifizieren
    if wp db check --path=/var/www/html; then
        log "Datenbankintegrität verifiziert"
    else
        log "ERROR: Datenbankintegritätsprüfung fehlgeschlagen"
        exit 1
    fi

    # Kritische Plugins prüfen
    local critical_plugins=("all-in-one-wp-migration" "wp-super-cache")

    for plugin in "${critical_plugins[@]}"; do
        if wp plugin is-active "$plugin" --path=/var/www/html; then
            log "Plugin $plugin ist aktiv"
        else
            log "WARNING: Plugin $plugin ist nicht aktiv"
        fi
    done

    log "Post-Deployment-Validierung abgeschlossen"
}

## Haupt-Deployment-Funktion
main() {
    log "Starte WordPress-Deployment für $ENVIRONMENT Umgebung"

    pre_migration_checks
    create_deployment_backup
    execute_migration
    post_deployment_validation

    log "Deployment erfolgreich abgeschlossen"

    # Benachrichtigung senden (optional)
    if command -v slack-cli &> /dev/null; then
        slack-cli send "WordPress-Deployment zu $ENVIRONMENT erfolgreich abgeschlossen"
    fi
}

## Hauptfunktion ausführen
main

#Nginx, PHP und MySQL für WordPress optimieren

#Nginx und PHP nach der Migration anpassen

#Nginx-Konfiguration für migrierte Sites

server {
    listen 80;
    server_name neue-site.com www.neue-site.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name neue-site.com www.neue-site.com;

    root /var/www/html;
    index index.php index.html;

    # SSL-Konfiguration
    ssl_certificate /pfad/zu/ssl/cert.pem;
    ssl_certificate_key /pfad/zu/ssl/private.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;

    # WordPress-spezifische Konfiguration
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

        # Leistungsoptimierungen
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }

    # Caching-Konfiguration
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Sicherheits-Header
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
}

#PHP-Optimierung für Migrationsleistung

; PHP-Konfiguration optimiert für WordPress-Migration
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 3000

; OPcache-Konfiguration für bessere Leistung
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=2
opcache.fast_shutdown=1

#Datenbank-Leistungsoptimierung

#MySQL-Konfigurationsoptimierung

-- MySQL-Optimierung für WordPress
SET GLOBAL innodb_buffer_pool_size = 1073741824; -- 1GB
SET GLOBAL innodb_log_file_size = 268435456; -- 256MB
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SET GLOBAL innodb_flush_method = O_DIRECT;

-- Query-Cache-Konfiguration
SET GLOBAL query_cache_type = ON;
SET GLOBAL query_cache_size = 67108864; -- 64MB

#Datenbank-Indexierungsstrategie

-- Indizes für bessere Leistung hinzufügen
ALTER TABLE wp_posts ADD INDEX idx_post_type_status (post_type, post_status);
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key, meta_value(191));
ALTER TABLE wp_options ADD INDEX idx_autoload (autoload, option_name);

-- Große Tabellen optimieren
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Serialisierte Daten und Speicherfehler nach Migration beheben

#Fehler bei serialisierten Daten, Speicher und Plugins

#Problem 1: Serialisierte Datenkorruption

Problem: Nach URL-Ersetzung werden Theme-Optionen und Plugin-Einstellungen beschädigt.

Diagnose:

<?php
// Optionen auflisten, deren serialisierter Wert sich nicht mehr entpacken lässt (mit wp eval-file ausführen)
global $wpdb;
$rows = $wpdb->get_results( "SELECT option_name, option_value FROM {$wpdb->options}" );
foreach ( $rows as $row ) {
    $v = $row->option_value;
    if ( is_serialized( $v ) && 'b:0;' !== $v && false === @unserialize( $v ) ) {
        echo $row->option_name . "\n";
    }
}

Lösung:

## Dump von vor der Ersetzung zurückspielen und mit WP-CLI wiederholen
wp db import backup-before-replace.sql
wp search-replace 'https://altdomain.com' 'https://neuedomain.com' --skip-columns=guid --precise

#Problem 2: Speichererschöpfung bei großer Datenbankmigration

Problem: PHP-Speicherlimits werden bei Datenbank-Import/Export überschritten.

Lösungen:

Methode 1: Chunked-Verarbeitung

<?php
// Datenbank in Chunks verarbeiten, um Speicherprobleme zu vermeiden
function process_database_in_chunks($table, $chunk_size = 1000) {
    global $wpdb;

    $offset = 0;
    do {
        $results = $wpdb->get_results("
            SELECT * FROM $table
            LIMIT $offset, $chunk_size
        ");

        foreach ($results as $row) {
            // Jede Zeile verarbeiten
            process_row($row);
        }

        $offset += $chunk_size;

        // Speicher freigeben
        $wpdb->flush();

    } while (count($results) === $chunk_size);
}
?>

Methode 2: Streaming-Datenbank-Export

## mysqldump mit Komprimierung für große Datenbanken verwenden
mysqldump --single-transaction --quick --lock-tables=false \
  --host=localhost --user=username --password=password \
  database_name | gzip > backup.sql.gz

## Import mit Streaming
gunzip < backup.sql.gz | mysql -u username -p database_name

#Problem 3: Plugin-Kompatibilität nach Migration

Problem: Plugins funktionieren nach URL-Änderungen aufgrund hardcodierter Referenzen nicht.

Systematische Lösung:

Plugin-Kompatibilitätsprüfer erstellen:

<?php
// Plugin-Kompatibilitätsprüfer
function check_plugin_compatibility() {
    $plugins = get_option('active_plugins');
    $issues = [];

    foreach ($plugins as $plugin_path) {
        $plugin_data = get_plugin_data(WP_PLUGIN_DIR . '/' . $plugin_path);

        // Auf hardcodierte URLs in Plugin-Dateien prüfen
        $plugin_files = glob(WP_PLUGIN_DIR . '/' . dirname($plugin_path) . '/*.php');

        foreach ($plugin_files as $file) {
            $content = file_get_contents($file);

            // Nach potenziellen hardcodierten URLs suchen
            if (preg_match('/https?:\/\/[^\s"\'<]+/', $content, $matches)) {
                $issues[] = [
                    'plugin' => $plugin_data['Name'],
                    'file' => $file,
                    'hardcoded_urls' => $matches
                ];
            }
        }
    }

    return $issues;
}
?>

URLs in Plugin-Einstellungen mit WP-CLI ersetzen:

## Nur wp_options, PHP-Modus für verschachtelte serialisierte Werte
wp search-replace 'https://altdomain.com' 'https://neuedomain.com' wp_options --precise --dry-run

#Migrationsautomatisierung und CI/CD-Integration

#Migrationen in einer CI-Pipeline testen

#GitHub Actions Workflow für automatisierte Tests

name: WordPress-Migrationstest

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  migration-test:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_ROOT_PASSWORD: password
          MYSQL_DATABASE: wordpress_test
        options: >-
          --health-cmd="mysqladmin ping"
          --health-interval=10s
          --health-timeout=5s
          --health-retries=3

    steps:
    - uses: actions/checkout@v3

    - name: PHP einrichten
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.1'
        extensions: mysqli, gd, xml, mbstring

    - name: WordPress installieren
      run: |
        curl -O https://wordpress.org/latest.tar.gz
        tar -xzf latest.tar.gz
        cp -r wordpress/* /var/www/html/

    - name: WordPress konfigurieren
      run: |
        cp wp-config-sample.php wp-config.php
        sed -i "s/database_name_here/wordpress_test/" wp-config.php
        sed -i "s/username_here/root/" wp-config.php
        sed -i "s/password_here/password/" wp-config.php
        sed -i "s/localhost/127.0.0.1/" wp-config.php

    - name: WP-CLI installieren
      run: |
        curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
        chmod +x wp-cli.phar
        sudo mv wp-cli.phar /usr/local/bin/wp

    - name: Migrationstests ausführen
      run: |
        wp core install --url=http://localhost --title="Test Site" --admin_user=admin --admin_password=password [email protected]
        wp plugin install all-in-one-wp-migration --activate
        # Migrationstest-Skripte hier hinzufügen

    - name: Migration validieren
      run: |
        # Validierungsskripte hinzufügen
        wp option get siteurl
        wp option get home

#Automatisiertes Deployment-Skript

#!/bin/bash
## Automatisiertes WordPress-Deployment-Skript

set -e

## Umgebungsvariablen
ENVIRONMENT=${1:-staging}
BACKUP_DIR="/backups/wordpress"
DEPLOY_LOG="/var/log/deploy.log"

## Logging-Funktion
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$ENVIRONMENT] $1" | tee -a "$DEPLOY_LOG"
}

## Vor-Deployment-Prüfungen
pre_deployment_checks() {
    log "Starte Vor-Deployment-Prüfungen"

    # Prüfen, ob WordPress installiert ist
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: WordPress nicht korrekt installiert"
        exit 1
    fi

    # Datenbankkonnektivität prüfen
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Datenbankverbindung fehlgeschlagen"
        exit 1
    fi

    # Erforderliche Plugins aktiv prüfen
    if ! wp plugin is-active all-in-one-wp-migration --path=/var/www/html; then
        log "ERROR: Erforderliches Migrations-Plugin nicht aktiv"
        exit 1
    fi

    log "Vor-Deployment-Prüfungen bestanden"
}

## Deployment-Backup erstellen
create_deployment_backup() {
    log "Erstelle Deployment-Backup"

    local timestamp=$(date +%Y%m%d_%H%M%S)
    local backup_file="$BACKUP_DIR/pre_deploy_${ENVIRONMENT}_$timestamp.sql"

    wp db export "$backup_file" --path=/var/www/html

    # Backup-Integrität verifizieren
    if [ -s "$backup_file" ] && tail -n 1 "$backup_file" | grep -q "Dump completed"; then
        log "Backup erstellt und verifiziert: $backup_file"
    else
        log "ERROR: Backup-Erstellung fehlgeschlagen"
        exit 1
    fi
}

## Migration ausführen
execute_migration() {
    log "Führe WordPress-Migration aus"

    # Site-URLs bei Bedarf aktualisieren
    if [ "$ENVIRONMENT" = "production" ]; then
        wp search-replace "staging.beispiel.com" "beispiel.com" --skip-columns=guid --path=/var/www/html
    fi

    # Alle Caches leeren
    wp cache flush --path=/var/www/html

    # Rewrite-Regeln aktualisieren
    wp rewrite flush --path=/var/www/html

    log "Migration abgeschlossen"
}

## Post-Deployment-Validierung
post_deployment_validation() {
    log "Starte Post-Deployment-Validierung"

    # Site-Zugänglichkeit prüfen
    local site_url=$(wp option get siteurl --path=/var/www/html)

    if curl -f -s "$site_url" > /dev/null; then
        log "Site ist zugänglich: $site_url"
    else
        log "ERROR: Site ist nicht zugänglich"
        exit 1
    fi

    # WordPress-Admin prüfen
    if curl -f -s "$site_url/wp-admin/" > /dev/null; then
        log "WordPress-Admin ist zugänglich"
    else
        log "ERROR: WordPress-Admin ist nicht zugänglich"
        exit 1
    fi

    # Datenbankintegrität verifizieren
    if wp db check --path=/var/www/html; then
        log "Datenbankintegrität verifiziert"
    else
        log "ERROR: Datenbankintegritätsprüfung fehlgeschlagen"
        exit 1
    fi

    # Kritische Plugins prüfen
    local critical_plugins=("all-in-one-wp-migration" "wp-super-cache")

    for plugin in "${critical_plugins[@]}"; do
        if wp plugin is-active "$plugin" --path=/var/www/html; then
            log "Plugin $plugin ist aktiv"
        else
            log "WARNING: Plugin $plugin ist nicht aktiv"
        fi
    done

    log "Post-Deployment-Validierung abgeschlossen"
}

## Haupt-Deployment-Funktion
main() {
    log "Starte WordPress-Deployment für $ENVIRONMENT Umgebung"

    pre_deployment_checks
    create_deployment_backup
    execute_migration
    post_deployment_validation

    log "Deployment erfolgreich abgeschlossen"

    # Benachrichtigung senden (optional)
    if command -v slack-cli &> /dev/null; then
        slack-cli send "WordPress-Deployment zu $ENVIRONMENT erfolgreich abgeschlossen"
    fi
}

## Hauptfunktion ausführen
main

#Fazit