Serverumzug und DNS: Die Reihenfolge, bei der niemand etwas merkt

Ein Hosting-Wechsel gilt als riskant, und das ist er auch – aber nicht aus den Gründen, die meist genannt werden. Die Adressen bleiben gleich, die Inhalte bleiben gleich, es gibt keine Weiterleitungen zu planen. Was schiefgeht, geht an zwei Stellen schief: bei der Umschaltung selbst und bei den Dingen, die mit der Website zusammen am alten Server hingen.

Warum die TTL vorher sinken muss

Die TTL eines DNS-Eintrags sagt Auflösern, wie lange sie das Ergebnis zwischenspeichern dürfen. Steht sie auf 24 Stunden, verwenden Auflöser bis zu einen Tag lang die alte Adresse – auch nachdem du umgestellt hast.

Googles Empfehlung: die TTL mindestens eine Woche vor dem Umzug auf einen konservativ niedrigen Wert senken, etwa wenige Stunden. Damit verbreiten sich die Einstellungen schneller bei den Anbietern.

Der Punkt, der dabei oft übersehen wird: Die Senkung braucht selbst noch die alte TTL, um überall anzukommen. Wer am Umzugstag die TTL senkt, hat nichts gewonnen. Deshalb die Woche Vorlauf.

Der Ablauf

Zeile sieben und acht sind Googles ausdrückliche Empfehlung: Die Protokolle beider Anbieter im Blick behalten, und erst wenn der Verkehr zum alten Anbieter auf null gesunken ist, die alte Infrastruktur abschalten. Wie man solche Protokolle liest, steht in Logfile-Analyse.

Der Fehler, der daraus entsteht, wenn man zu früh abschaltet: Ein Teil der Besucher und Crawler landet noch beim alten Anbieter und bekommt dort nichts. Für Google sieht das aus wie Serverfehler – mit der Folge, die in 404-Seiten und Statuscodes beschrieben ist: gedrosseltes Crawling.

Was danach normal ist

Googles Anleitung nennt es konkret: Direkt nach dem Start ist ein vorübergehender Rückgang der Crawl-Rate zu erwarten, gefolgt von einem stetigen Anstieg über die nächsten Tage. Solange Googlebot keine ernsten Probleme oder Verlangsamungen bei der neuen Infrastruktur feststellt, wird es so schnell crawlen, wie notwendig und möglich ist.

Praktisch heißt das: Wer am Tag nach dem Umzug in der Search Console einen Rückgang bei der Crawl-Aktivität sieht, muss nichts tun. Wer ihn eine Woche später noch sieht, schon.

Die Punkte, die mit umziehen müssen

Das ist die Liste, an der die meisten Umzüge tatsächlich scheitern – und keiner der Punkte hat mit SEO zu tun:

• E-Mail. MX-Einträge sind unabhängig von der Website. Lagen beide beim gleichen Anbieter, muss das vorher geklärt sein.
• Zertifikat. Auf dem neuen Server vorhanden und automatisch verlängerbar? Siehe HTTPS und SEO.
• Zeitgesteuerte Aufgaben. Backups, Importe, Newsletter-Versand – alles, was per Cron lief, läuft nach dem Umzug nicht mehr, bis es neu eingerichtet ist.
• Mailversand aus der Website. Der neue Server hat andere Absenderrechte. Formular-Mails landen danach gern im Spam – die Vorsorge dazu steht in Formulare, die ankommen.
• SPF- und DKIM-Einträge. Müssen auf den neuen Versandweg angepasst werden.
• Bestätigung der Search Console. Bei Bestätigung über eine HTML-Datei oder ein Meta-Tag muss die Datei mitwandern.
• Weiterleitungen aus der Serverkonfiguration. Was in einer .htaccess oder Serverkonfiguration stand, ist auf dem neuen System nicht automatisch vorhanden – siehe Weiterleitungen.

Die letzte Zeile ist besonders tückisch, weil sie erst Wochen später auffällt: Alte Adressen, die jahrelang korrekt weitergeleitet wurden, liefern plötzlich Fehler.

Wenn sich zugleich die Adressen ändern

Dann ist es kein Hosting-Wechsel mehr, sondern ein Umzug mit URL-Änderung – ein anderes Verfahren mit Weiterleitungen, Adressänderung in der Search Console und Wochen an Übergangszeit. Beides gleichzeitig zu machen ist möglich, aber es verdoppelt die Fehlerquellen und macht die Ursachensuche schwer.

Die Empfehlung: erst umziehen, zwei Wochen beobachten, dann umstrukturieren. Die Reihenfolge für den zweiten Schritt steht in Website-Relaunch und SEO, die Entscheidung über Host und Pfad in Subdomain oder Unterverzeichnis. Worauf es bei der Auswahl des neuen Anbieters ankommt, steht in Hosting für kleine Unternehmen.