Ein Serverwechsel scheitert selten an der Technik. Er scheitert daran, dass Schritte in der falschen Reihenfolge passieren. Wer den DNS-Eintrag umstellt, bevor die Weiterleitungen stehen, produziert für einige Stunden massenhaft 404-Fehler, und genau diese Stunden erwischt der Crawler.

Der eigentliche Umzug dauert Minuten. Die Vor- und Nacharbeit entscheidet über das Ergebnis. Der folgende Ablauf hat sich bei Umzügen mit mehreren tausend URLs bewährt und lässt sich auf kleine Projekte problemlos herunterbrechen.

Bestandsaufnahme vor dem ersten Handgriff

Ohne vollständige Liste des Ist-Zustands lässt sich hinterher nicht prüfen, ob etwas fehlt. Diese vier Datensätze gehören vor dem Umzug gesichert.

  • Ein vollständiger Crawl der Live-Seite mit URL, Statuscode, Title und Canonical, exportiert als CSV
  • Die Liste der am häufigsten aufgerufenen URLs aus dem Logfile oder der Analytics-Auswertung der letzten zwölf Monate
  • Der aktuelle Stand aller DNS-Einträge, insbesondere A, AAAA, MX, TXT und CNAME
  • Ein vollständiges Backup aus Dateien und Datenbank, getestet durch eine Rücksicherung in eine Testumgebung

Der Punkt mit den MX-Einträgen wird am häufigsten übersehen. Wer beim Providerwechsel nur an die Website denkt, stellt die Nameserver um und kappt damit den Mailempfang, weil die MX-Records beim neuen Anbieter nicht existieren. Ein Screenshot der alten Zonendatei kostet zwei Minuten und rettet den Tag.

TTL absenken, bevor irgendetwas umzieht

Die Time to Live legt fest, wie lange Resolver eine DNS-Antwort zwischenspeichern. Steht sie auf den üblichen 86.400 Sekunden, sehen einzelne Besucher noch einen ganzen Tag lang den alten Server. Mindestens 48 Stunden vor dem Umzug wird sie deshalb auf 300 Sekunden gesenkt. Ob die Änderung greift, lässt sich mit einem DNS Lookup unter Windows prüfen, der neben der Adresse auch die verbleibende TTL ausgibt.

Parallel dazu gehört das TLS-Zertifikat vorbereitet. Eine Ausstellung über die HTTP-Validierung funktioniert erst, wenn die Domain bereits auf den neuen Server zeigt, was zu einer Lücke führt. Sauberer ist die DNS-Validierung, weil sich das Zertifikat damit ausstellen lässt, während die Domain noch am alten Ort liegt.

Die Reihenfolge am Umzugstag

Bewährt hat sich ein Vormittag unter der Woche, weil Support auf beiden Seiten erreichbar ist. Freitagnachmittag ist die schlechteste denkbare Wahl.

  • Dateien und Datenbank auf das Ziel spiegeln und die Anwendung dort vollständig testen, erreichbar über eine Vorschau-Adresse oder einen Eintrag in der lokalen hosts-Datei
  • Die robots.txt der Zielumgebung prüfen, weil Staging-Systeme fast immer ein Disallow für alles enthalten
  • Weiterleitungen auf dem Zielserver einrichten und mit der exportierten URL-Liste testen, solange die Domain noch nicht umgestellt ist
  • Erst danach die A- und AAAA-Einträge auf die neue IP setzen, MX und TXT unverändert übernehmen
  • Das alte System mindestens vier Wochen erreichbar lassen, damit Nachzügler nicht ins Leere laufen

Für den Betrieb selbst spielt es eine Rolle, ob der Zielserver Weiterleitungen serverseitig verarbeitet. Bei geteiltem Webspace läuft das über die .htaccess, bei einem eigenen Server über die Konfiguration von nginx oder Apache. Wer ohnehin wechselt, sollte beim Vergleich der Webhosting Anbieter darauf achten, ob HTTP/2, Brotli-Komprimierung und eine aktuelle PHP-Version verfügbar sind, weil diese drei Punkte die Ladezeit stärker beeinflussen als die reine CPU-Ausstattung. Anbieter wie hosttech weisen die eingesetzten Versionen im Tarifvergleich direkt aus.

Datenbank und interne Verweise

Bei Content-Management-Systemen steckt die Domain an vielen Stellen gleichzeitig. Neben der Konfiguration liegt sie verstreut in der Datenbank, weil WordPress absolute Adressen in Beiträgen, Menüs und Optionen speichert. Ein Teil davon steht in serialisierten Feldern, und ein einfaches Suchen und Ersetzen per SQL zerstört diese Felder, weil die gespeicherten Längenangaben anschließend nicht mehr zur Zeichenkette passen.

Sauber arbeiten Werkzeuge, die serialisierte Daten vor dem Ersetzen entpacken, etwa die WP-CLI mit dem Parameter für Serialisierung oder ein dediziertes Ersetzungsskript. Bleibt die Domain gleich und wechselt nur der Server, entfällt dieser Schritt vollständig, was ein weiteres Argument dafür ist, Domainwechsel und Serverwechsel nicht am selben Tag zu erledigen.

Weiterleitungen entscheiden über das Ranking

Technisch trägt eine einzige Statuszeile das gesamte Umzugsrisiko. Der Statuscode 301 signalisiert eine dauerhafte Verschiebung, und die Spezifikation beschreibt in RFC 9110 zum Status 301 Moved Permanently, dass Clients die neue Adresse für künftige Anfragen übernehmen dürfen. Ein 302 dagegen bedeutet eine vorübergehende Verschiebung und führt dazu, dass die alte Adresse indexiert bleibt.

Drei Regeln haben sich in der Praxis bewährt. Jede alte URL zeigt auf ihr inhaltliches Gegenstück, nicht pauschal auf die Startseite. Weiterleitungsketten werden auf einen Sprung reduziert, weil jeder zusätzliche Hop Ladezeit kostet und Signale verwässert. Und die Zielseiten liefern selbst einen Status 200, was sich mit einem Massentest über die exportierte URL-Liste in wenigen Minuten prüfen lässt.

Kontrolle in den ersten Tagen

Nach der Umstellung zeigt der eigene Rechner oft noch tagelang den alten Server, weil Windows die Auflösung zwischenspeichert. Wer den DNS-Cache leert, sieht sofort den tatsächlichen Stand und vermeidet die Fehlersuche an einem Problem, das nur lokal existiert.

In den ersten 72 Stunden lohnt der tägliche Blick in drei Quellen. Das Serverlog zeigt 404-Fehler mit Referrer und damit die vergessenen Weiterleitungen. Die Search Console meldet Crawling-Fehler und die Indexabdeckung, wobei die Zahlen dort mit einigen Tagen Verzögerung eintreffen. Und ein einfaches Uptime-Monitoring auf mehrere Unterseiten statt nur auf die Startseite deckt Fälle auf, in denen einzelne Verzeichnisse fehlen oder Rechte falsch gesetzt wurden.

Die Fehler, die sich wiederholen

Vier Muster tauchen bei fast jedem misslungenen Umzug auf. Eine vergessene robots.txt aus der Staging-Umgebung sperrt die gesamte Seite aus. Fehlende Weiterleitungen für Bilder und PDF-Dateien kosten Treffer in der Bildersuche. Ein Wechsel der URL-Struktur gleichzeitig mit dem Serverumzug macht die Fehlersuche unmöglich, weil sich zwei Ursachen überlagern. Und interne Links, die absolut auf die alte Domain zeigen, erzeugen dauerhaft unnötige Umleitungen.

Wer den Serverwechsel und die inhaltliche Überarbeitung sauber trennt und zwischen beiden Schritten zwei bis drei Wochen liegen lässt, kann jede Veränderung eindeutig zuordnen. Diese Disziplin kostet Geduld und erspart im Zweifel eine Woche Ursachensuche an einem Rankingverlust, der am Ende gar nichts mit dem Umzug zu tun hatte.