Die Kernaussage: Ein WordPress-Umzug verursacht Ausfallzeit, wenn die Schritte in der falschen Reihenfolge passieren — DNS wird umgestellt, bevor die neue Site geprüft ist, oder Inhalte werden auf der alten Site geändert, nachdem die Datenbank bereits exportiert wurde. Die Arbeit parallel auf der neuen Umgebung zu erledigen, sie vor der Umstellung vollständig zu testen und die DNS-TTL im Voraus zu senken, macht die Umstellung für Besucher unsichtbar.
Warum Umzüge normalerweise Ausfallzeit verursachen
Der standardmäßige, ungeplante Weg, eine WordPress-Site umzuziehen — Datenbank exportieren, Dateien kopieren, DNS auf den neuen Server zeigen lassen, dann anfangen zu reparieren, was kaputt ist — schafft ein Zeitfenster, in dem die Site entweder komplett down ist oder eine halb umgezogene, kaputte Version ausliefert. Jeder Schritt in dieser Abfolge passiert direkt an der Live-Site selbst, sodass jeder Fehler sofort für Besucher sichtbar ist.
Ein Umzug ohne Ausfallzeit löst das, indem die Reihenfolge umgekehrt wird: die neue Umgebung aufbauen und vollständig prüfen, während die alte unberührt weiter Traffic bedient, und erst umstellen, sobald alles nachweislich funktioniert. Die Live-Site befindet sich nie in einem zwischenzeitlichen, kaputten Zustand, weil die Umzugsarbeit nie direkt an ihr passiert.
Checkliste vor dem Umzug
- Ein vollständiges Backup der aktuellen Dateien und der Datenbank der Site erstellen, gespeichert irgendwo außerhalb des aktuellen Hosting-Kontos.
- Die DNS-TTL im A-Record der Domain mindestens 24-48 Stunden vor der geplanten Umstellung auf 300 Sekunden (5 Minuten) senken — siehe das technische Detail unten dazu, warum das rechtzeitige Timing wichtig ist.
- Aktive Plugins und Themes inventarisieren, Versionen notieren, da die neue Umgebung die PHP-Version und Erweiterungsanforderungen erfüllen muss.
- Bestätigen, dass der neue Host vollständig eingerichtet ist — WordPress installiert, bereit, die umgezogenen Dateien und die Datenbank zu empfangen, aber noch nicht öffentlich mit der Domain verknüpft.
Schritt 1: DNS-TTL senken, bevor du beginnst
DNS-TTL (time to live) steuert, wie lange Resolver im gesamten Internet die aktuelle IP-Adresse einer Domain zwischenspeichern, bevor sie erneut prüfen. Eine typische Standard-TTL von mehreren Stunden (manchmal 24 oder mehr) bedeutet, dass selbst nachdem DNS aktualisiert wurde, um auf den neuen Server zu zeigen, ein bedeutender Teil der Besucher weiter den alten Server erreicht, bis die zwischengespeicherte Kopie ihres Resolvers abläuft. Cloudflares eigene Erklärung zu DNS-TTL behandelt diesen Mechanismus technisch vertiefter.
Die TTL ein oder zwei Tage vor der eigentlichen Umstellung auf 300 Sekunden zu senken bedeutet, dass die Propagierungsverzögerung zum Zeitpunkt der DNS-Umstellung Minuten statt Stunden beträgt — der wirkungsvollste einzelne Vorbereitungsschritt für eine wirklich ausfallzeitarme Umstellung.
Schritt 2: Die neue Umgebung parallel aufbauen
WordPress auf dem neuen Host vollständig unabhängig von der Live-Site einrichten — gleiche PHP-Version, gleiche benötigten Erweiterungen, bereit, Inhalte zu empfangen, aber noch nicht öffentlich sichtbar mit der Live-Domain verknüpft. Das ist der Schritt, der "ohne Ausfallzeit" möglich macht: die gesamte Einrichtungsarbeit passiert auf einer Infrastruktur, die noch niemand besucht.
Schritt 3: Dateien und Datenbank migrieren
Tools wie Duplicator oder das All-in-One WP Migration-Plugin verpacken die Dateien und die Datenbank der Site in ein einziges übertragbares Archiv und übernehmen die technischen Details eines sauberen Datenbank-Exports und -Imports. Für Agenturen, die häufige Umzüge durchführen, übernimmt ein in verwaltete Hosting-Plattformen integriertes Host-zu-Host-Migrationstool (Kinsta, WP Engine und andere bieten das an) den Prozess oft mit weniger manueller Arbeit.
Eine spezifische technische Falle, die es hier zu vermeiden gilt: keine einfache Suchen-und-Ersetzen-Operation in der Datenbank ausführen, um die Domain von der alten URL auf die neue zu aktualisieren. WordPress speichert serialisierte PHP-Daten — verwendet von vielen Widgets, manchen Plugin-Einstellungen und Theme-Optionen — als Strings mit einem eingebetteten Zeichenlängen-Präfix. Eine naive Textersetzung ändert die Länge des Strings, ohne dieses Präfix zu aktualisieren, und beschädigt die Daten dabei unbemerkt. WP-CLIs search-replace-Befehl ist speziell dafür gebaut, serialisierte Daten korrekt zu handhaben, und ist das Standardwerkzeug für genau diesen Schritt.
Schritt 4: Die neue Site über die eigene Hosts-Datei testen
Bevor du das öffentliche DNS anfasst, bearbeite die lokale Hosts-Datei deines eigenen Computers, um die Domain auf die IP-Adresse des neuen Servers zeigen zu lassen — das betrifft nur deine Maschine und lässt dich die neue Site über den echten Domainnamen durchsuchen (Login, Checkout, Kontaktformulare und alles andere testen, was von der übereinstimmenden Domain abhängt), ohne dass ein anderer Besucher betroffen ist. Das ist der Schritt, der Migrationsprobleme abfängt, bevor sie öffentlich werden.
Schritt 5: Während des Migrationsfensters entstandene Inhaltsänderungen abgleichen
Wenn die Live-Site nach dem Datenbank-Export weiter Kommentare, Bestellungen oder Formulareinsendungen erhalten hat, existiert dieser Inhalt auf der alten Site, aber nicht auf der neuen. Für die meisten Broschüren-Sites ist dieses Fenster klein genug, um es zu ignorieren; für alles Transaktionale (E-Commerce, Mitgliedschaftsinhalte) exportiere nur die während des Migrationsfensters neu erstellten Datensätze und importiere sie vor der Umstellung in die neue Datenbank.
Schritt 6: DNS umstellen
Wenn die neue Site über die Hosts-Datei-Methode vollständig getestet und etwaige Inhaltslücken abgeglichen sind, aktualisiere den A-Record der Domain, um auf den neuen Server zu zeigen. Da die TTL vorher gesenkt wurde, lösen die meisten Besucher innerhalb von Minuten statt Stunden zum neuen Server auf.
Schritt 7: Nach der Umstellung prüfen und überwachen
- Bestätigen, dass SSL für die Domain auf dem neuen Server aktiv ist, da ein fehlendes oder falsch konfiguriertes Zertifikat den HTTPS-Zugriff sofort unterbricht.
- Auf Mixed-Content-Warnungen prüfen, verursacht durch verbliebene fest codierte http://-URLs in der Datenbank oder den Theme-Dateien.
- Prüfen, dass Weiterleitungen noch funktionieren, falls der Umzug eine Änderung der URL-Struktur umfasste, und in den folgenden Tagen die Google Search Console auf einen Anstieg von Crawling-Fehlern prüfen.
- Serverprotokolle auf 404-Fehler bei zuvor funktionierenden URLs überwachen, was meist auf eine übersehene Datei oder eine unvollständige Suchen-Ersetzen-Operation hinweist.
Migrationszeitplan auf einen Blick
| Phase | Timing | Wichtigste Maßnahmen |
|---|---|---|
| Vor der Migration | 24-48 Stunden vorher | DNS-TTL senken, Backup erstellen, neuen Host als bereit bestätigen |
| Paralleler Aufbau | Vor der Umstellung | Neue Umgebung einrichten, Dateien/Datenbank mit geeignetem Tool migrieren |
| Prüfung | Vor der Umstellung | Über lokale Hosts-Datei mit der echten Domain testen |
| Umstellung | Migrationstag | Etwaige Inhaltslücken abgleichen, DNS umstellen |
| Nach der Migration | Erste 48-72 Stunden | SSL prüfen, auf Mixed Content prüfen, Protokolle und Search Console überwachen |
Häufige Migrationsfehler
- Das Senken der DNS-TTL überspringen, wodurch die Propagierung der Umstellung dem überlassen bleibt, worauf die alte TTL zufällig eingestellt war.
- Eine einfache Suchen-und-Ersetzen-Operation in der Datenbank ausführen statt eines serialisierungsbewussten Tools wie WP-CLIs search-replace, was Widget- und Theme-Einstellungen unbemerkt beschädigt.
- DNS umstellen, bevor die neue Site getestet wurde, ein defektes Plugin oder eine fehlende Datei erst entdecken, nachdem Besucher bereits darauf zugreifen.
- Während des Migrationsfensters erstellte Inhalte vergessen, Kommentare, Bestellungen oder Einsendungen verlieren, die nach dem Export auf der alten Site landeten.
- SSL auf dem neuen Server vor der Umstellung nicht bestätigen, was in dem Moment, in dem DNS umschaltet, eine sichtbare Zertifikatswarnung verursacht.
Wann Hilfe holen, um einem Kunden Fortschritt zu zeigen
Agenturen, die die Site eines Kunden umziehen, müssen oft die parallele neue Umgebung vor der eigentlichen Umstellung zur Freigabe zeigen — ohne Hosting-Zugangsdaten weiterzugeben oder einen verwirrenden Hosts-Datei-Workaround, dem ein nicht-technischer Kunde folgen müsste. Ein Tool wie Erdo Client Preview oder Erdo Draft Links gibt einem Kunden einen einfachen Link, um die neue Site direkt zu prüfen, was sich natürlich mit den Testgewohnheiten aus unserem WordPress-Staging-Leitfaden und unserem umfassenderen WordPress-Geschwindigkeits- und Hosting-Leitfaden zur Bewertung des Zielhosts selbst kombinieren lässt.
Zusammenfassung
Kurz gesagt: Ein WordPress-Umzug ohne Ausfallzeit kommt auf die Reihenfolge an: DNS-TTL rechtzeitig im Voraus senken, die neue Umgebung parallel aufbauen und über die eigene Hosts-Datei statt über öffentliches DNS vollständig testen, für jede URL-Aktualisierung ein serialisierungsbewusstes Tool verwenden, und erst DNS umstellen, sobald alles nachweislich funktioniert. Diese Reihenfolge einhalten, und die Live-Site befindet sich nie in einem zwischenzeitlichen, kaputten Zustand — Besucher lösen einfach zum neuen Server auf, sobald dieser bereits als bereit bestätigt wurde.