DNS erreicht den neuen Server, doch Besucher sehen unterschiedliche Weiterleitungen, fehlende Bilder und sporadische 500-Fehler. wp-admin öffnet nur über die temporäre Anbieteradresse, während Checkout-Rückrufe weiterhin die alte Umgebung erreichen.
Dieser Beitrag zeigt, wie Sie den antwortenden Server bestimmen, die erste Fehlerursache eingrenzen und zwischen Reparatur am Zielsystem und Rollback zum alten Hoster entscheiden.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler und Rollback-Plan
- So unterstützt AIOWS: AIOWS Backup Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was „nach dem Umzug defekt“ bedeutet
Eine migrierte Website ist defekt, wenn der kopierte WordPress-Stand nicht zur neuen Serverumgebung passt. Die Ursache kann vor WordPress bei DNS oder TLS liegen, innerhalb der Installation bei Konfiguration, gespeicherten URLs, Dateien oder Datenbank sowie außerhalb bei Caches, E-Mail, Cronjobs, Webhooks oder externem Speicher.
- Stellen Sie vor der Auswertung von Weiterleitungen und Protokollen fest, welcher Server die jeweilige Antwort geliefert hat.
- Prüfen Sie öffentliche Website, Administration, Hintergrundaufgaben und externe Rückrufe als getrennte Wege.
- Legen Sie fest, welcher Hoster während der Fehlersuche neue Daten annehmen darf.
Ein realistisches WordPress-Beispiel
Ein Kunde im Mobilfunknetz erreicht den neuen Server mit gültigem Zertifikat, doch Produktbilder verweisen noch auf den alten Upload-Pfad. Im Büronetz folgt der Browser einer gespeicherten Weiterleitung zum bisherigen Hoster. Gleichzeitig sendet der Zahlungsanbieter seine Webhooks weiterhin dorthin. Das sind drei verschiedene Ursachen: ein falscher Medienpfad, eine zwischengespeicherte Weiterleitung und eine nicht aktualisierte Rückrufadresse.
Warum es wichtig ist und wann Sie handeln sollten
Beginnen Sie mit der Fehlersuche, sobald Besucher ein Ziel erreichen, auf dem ein wichtiger Ablauf ausfällt, oder wenn Bestellungen, Konten und Formulardaten auf beide Hoster verteilt werden. Ein Darstellungsfehler lässt sich häufig am neuen Server beheben. Geteilte Schreibvorgänge verlangen dagegen sofort eine Entscheidung, welches System maßgeblich bleibt. Läuft das Umschaltfenster ab, wird der Verkehr zurückgeleitet, bevor die Datenbanken weiter auseinanderlaufen.
Der einfache Weg für Einsteiger
- Sichern Sie Protokolle und Konfiguration des neuen Servers. Ermitteln Sie die antwortende IP-Adresse und das ausgelieferte Zertifikat und vergleichen Sie beides mit dem alten Hoster.
- Vergleichen Sie
home,siteurl,wp-config.php, Datenbankzugang, Tabellenpräfix, Rewrite-Regeln und aktiven Document Root mit den Angaben aus dem Umzug. - Verwenden Sie für nötige URL-Änderungen ein Werkzeug, das serialisierte Daten korrekt verarbeitet. Speichern Sie die Permalink-Einstellungen anschließend über WordPress neu und leeren Sie nur die betroffenen Caches.
- Beheben Sie zunächst nur den nachgewiesenen Fehler und testen Sie aus einer frischen Browsersitzung. Ändern Sie DNS, Datenbank, Rechte und Plugins nicht gleichzeitig.
- Testen Sie aus mehreren Netzen Seiten, Medien, wp-admin, Anmeldung, REST, Cron, E-Mail, Formulare, Zahlung, Webhooks, Suche und Weiterleitungen.
Der technische Weg
Lösen Sie die Domain über mehrere öffentliche DNS-Resolver auf und notieren Sie IP-Adresse, Zertifikat, Antwort-Header und Weiterleitungskette. Ordnen Sie jeden fehlgeschlagenen Aufruf den Webserver- und PHP-Protokollen des neuen Hosts zu. Vergleichen Sie PHP-Version und Erweiterungen, Dateieigentümer, Groß-/Kleinschreibung, Proxy-Header, Objektcache und Cron-Ausführung mit dem Quellsystem.
- Aktivieren Sie WordPress-Debugging nur zur gezielten Diagnose, schützen Sie die Protokolle vor öffentlichem Zugriff und schalten Sie die sichtbare Fehlerausgabe danach wieder ab.
- Bei geänderter Domain oder Verzeichnisstruktur verwenden Sie ein WordPress-Werkzeug, das serialisierte Daten korrekt verarbeitet.
- Testen Sie Webhooks und Cronjobs so, dass alter und neuer Hoster nicht dasselbe Ereignis doppelt verarbeiten.
Risiken, häufige Fehler und Rollback-Plan
- Leeren Sie nicht wahllos alle Caches, bevor klar ist, welcher Server die falsche Antwort geliefert hat.
- Gleichzeitige Änderungen an DNS, Datenbank, Rechten und Plugins machen die Wirkung einzelner Korrekturen unkenntlich.
- Aktivieren Sie E-Mail, Cronjobs oder Zahlungsrückrufe während der Diagnose nicht unkontrolliert auf beiden Systemen.
- Bewahren Sie das vor dem Umzug erstellte Paket auf und halten Sie den alten Hoster verfügbar, bis die neue Website abgenommen ist.
Ein einfacher Rollback ist nur möglich, solange ein System die maßgebliche Datenquelle bleibt. Hat der neue Hoster bereits eigene Bestellungen oder Konten angenommen, müssen diese vor der Rückleitung gesichert und anschließend zusammengeführt werden.
So unterstützt AIOWS
AIOWS Backup Manager
Der AIOWS Backup Manager hält das geprüfte Paket von vor dem Umzug verfügbar, während Sie den neuen Hoster untersuchen. Mit dieser Sicherung können Sie den erwarteten Datei- und Datenbankstand vergleichen oder die betroffene WordPress-Komponente wiederherstellen, wenn die migrierte Kopie unvollständig ist.
DNS, Zertifikate, Serverrechte, E-Mail-Routing und Rückrufadressen externer Dienste liegen außerhalb des Moduls. Diese Punkte gehören weiterhin zur Umstellung des Hostings. Prüfen Sie nach jeder unterstützten Wiederherstellung genau die Besucher-, Administrations-, Medien-, Cron- und Zahlungswege, an denen der Fehler sichtbar war.
Ersetzen Sie das letzte nachweislich funktionierende Paket erst, wenn die korrigierte Website die vereinbarte Beobachtungszeit bestanden hat. Bei einem Rollback liefern Paket und alter Hoster den Ausgangspunkt; Daten, die nur am neuen Hoster entstanden sind, müssen separat gesichert werden.
Passende AIOWS-Artikel
- WordPress-Umzug: Website sicher migrieren
- WordPress-Umzugscheckliste: vor und nach der Migration
- WordPress-URLs nach der Migration ändern: sichere Anleitung
Fazit und empfohlener Weg
Ermitteln Sie zuerst, welcher Server antwortet und wo der Fehler entsteht. Beheben Sie eine nachgewiesene Ursache nach der anderen und testen Sie jeweils den betroffenen Benutzerweg. Läuft das Umschaltfenster ab, leiten Sie den Verkehr wie vereinbart zurück, bevor Besucher und neue Daten auf zwei Umgebungen verteilt werden.
