Zum Inhalt springen
Hosting

WordPress-Umzug auf einen neuen Server: Schritt für Schritt ohne Ausfall

Hosting-Wechsel ohne Downtime: die erprobte Reihenfolge vom Backup über den Testlauf per hosts-Datei bis zum DNS-Schwenk — inklusive der Fehler, die Umzüge scheitern lassen.

Ein Hoster-Wechsel hat einen schlechten Ruf, den er nicht verdient: Mit der richtigen Reihenfolge zieht eine WordPress-Website ohne eine Sekunde sichtbarer Ausfallzeit um. Die Katastrophen-Geschichten entstehen fast immer durch dieselben zwei Fehler — live schwenken ohne Test, und die E-Mail-Einstellungen vergessen. Hier ist der erprobte Ablauf.

Vorbereitung: drei Dinge, bevor irgendetwas kopiert wird

  1. Vollständiges Backup — Dateien und Datenbank, extern gespeichert. Der Umzug selbst ist risikoarm, aber du arbeitest nie ohne Netz. Anleitung: WordPress-Backup erstellen.
  2. Bestandsaufnahme: Welche PHP-Version läuft aktuell? Der neue Server sollte zunächst dieselbe Version bekommen — ein Umzug ändert immer nur eine Sache auf einmal. Das PHP-Upgrade kommt danach, in Ruhe.
  3. DNS-Inventur — vor allem E-Mail: Notiere alle bestehenden DNS-Einträge, besonders MX, SPF, DKIM. Der häufigste Kollateralschaden eines Website-Umzugs ist tote Firmen-E-Mail, weil die Mail-Einträge beim DNS-Wechsel verloren gehen. Wenn deine Postfächer beim alten Anbieter bleiben, müssen die Mail-Einträge unverändert erhalten bleiben.

Schritt 1: Die Website auf den neuen Server kopieren

Zwei bewährte Wege:

  • Per Umzugs-Plugin: Spezialisierte Plugins — ein bekanntes Beispiel ist Duplicator, vergleichbare Werkzeuge gibt es mehrere — packen Dateien und Datenbank in ein Archiv und bauen die Website auf dem Zielserver mit einem Installer wieder auf. Das erspart das manuelle Übertragen von Dateien und Datenbank und ist für die meisten Websites der bequemste Weg.
  • Manuell: Dateien per SFTP/SSH übertragen, Datenbank per Export/Import umziehen, Zugangsdaten in der wp-config.php anpassen. Volle Kontrolle, mehr Handarbeit.

Bei sehr großen Websites lohnt SSH mit rsync und mysqldump — das läuft robuster als browserbasierte Uploads.

Schritt 2: Testen, bevor die Welt es sieht (hosts-Datei)

Der wichtigste Schritt des ganzen Umzugs — und der am häufigsten übersprungene. Damit du die Website auf dem neuen Server unter ihrer echten Domain testen kannst, bevor DNS umgestellt ist, trägst du die neue Server-IP lokal in deine hosts-Datei ein:

# Windows: C:WindowsSystem32driversetchosts
# macOS/Linux: /etc/hosts
203.0.113.10  deine-domain.de www.deine-domain.de

Danach zeigt dein Rechner auf den neuen Server, der Rest der Welt weiter auf den alten. Jetzt gründlich prüfen: Startseite, Unterseiten, Anmeldung, Formulare, bei Shops die komplette Bestellstrecke. Erst wenn hier alles sitzt, geht es weiter. (Nach dem Umzug den Eintrag wieder entfernen!)

Schritt 3: SSL auf dem Zielserver bereitstellen

Das Zertifikat muss auf dem neuen Server liegen, bevor die Besucher kommen — sonst begrüßt sie eine Zertifikatswarnung. Je nach Anbieter heißt das: Zertifikat vorab ausstellen lassen oder den Automatismus so timen, dass er unmittelbar nach dem DNS-Schwenk greift. Was bei Zertifikatsproblemen zu tun ist, steht im Leitfaden SSL-Zertifikat abgelaufen.

Schritt 4: TTL senken, dann DNS umstellen

  1. Am Vortag: Die TTL (Gültigkeitsdauer) des A-Eintrags auf einen kleinen Wert senken, z. B. 300 Sekunden. So folgt die Welt dem Schwenk innerhalb von Minuten statt Stunden.
  2. Zum Schwenk-Zeitpunkt (verkehrsarme Zeit wählen): A- und ggf. AAAA-Eintrag auf die neue Server-IP stellen. Alle anderen Einträge — besonders MX! — unangetastet lassen.
  3. Inhalts-Stopp beachten: Zwischen letzter Datenübernahme und Schwenk keine Inhalte mehr ändern. Bei Shops: unmittelbar vor dem Schwenk einen letzten Datenbank-Abgleich fahren, damit keine Bestellung verloren geht.

Schritt 5: Nachkontrolle — die ersten 48 Stunden

  • Website unter https:// aufrufen, Zertifikat prüfen, einmal quer durch alle wichtigen Seiten klicken.
  • Formulare testen und prüfen, ob E-Mails ankommen — Website-Mails und Postfächer.
  • Fehlerquellen im Blick behalten: Datenbankverbindungs-Fehler deuten auf falsche Zugangsdaten, Redirect-Schleifen auf SSL-/Proxy-Einstellungen. Auch ein Blick in unseren Leitfaden zu typischen Migrationsfehlern lohnt.
  • Den alten Vertrag erst kündigen, wenn alles nachweislich läuft — bewährt haben sich zwei Wochen Parallelbetrieb. Vorher ein letztes Backup der alten Umgebung archivieren.

Sonderfall: Umzug mit Domain-Wechsel

Ändert sich beim Umzug auch die Domain, kommt ein Schritt hinzu: WordPress speichert die Adresse an vielen Stellen in der Datenbank. Ein Suchen-und-Ersetzen-Lauf (per WP-CLI: wp search-replace alt.de neu.de) samt anschließendem Permalink-Refresh gehört dann zwingend dazu — plus Weiterleitungen von der alten auf die neue Domain, damit Google und Besucher den Weg finden.

So machen wir es bei Ammera

Für Kunden des Host-Moduls übernimmt Ammera den kompletten Umzug nach genau diesem Ablauf — inklusive Testlauf, DNS-Begleitung und zwei Wochen Parallel-Beobachtung durch unser Minutentakt-Monitoring. Die Website läuft dabei einfach weiter. Zu den Modulen — oder prüfe mit dem kostenlosen Website-Check, ob sich bei deiner Website ohnehin gerade Baustellen stapeln.

Häufig gestellte Fragen

Ammera Care Dieser Ratgeber wurde vom Ammera-Care-Team verfasst. Seit 2014 betreuen wir WordPress-Websites für Unternehmen im DACH-Raum.