Ein Website-Umzug zu einem neuen Hoster gelingt ohne Ausfallzeit, wenn die DNS-TTL-Werte 24 bis 48 Stunden vorher abgesenkt werden, die Website beim neuen Hoster parallel aufgebaut und vollständig getestet wird, bevor der DNS-Eintrag umgestellt wird, und die alte Umgebung erst nach bestätigter Umstellung abgeschaltet wird. Anders als bei einem Domain- oder Design-Wechsel ändert sich dabei weder an der URL noch an Inhalten irgendetwas – nur der Server im Hintergrund wird ausgetauscht.
Warum ein Hosterwechsel anders ist als ein Domain- oder Design-Wechsel
Google unterscheidet in der eigenen Migrationsdokumentation ausdrücklich zwischen Änderungen, bei denen sich die URL ändert, und reinen Infrastrukturwechseln ohne sichtbare URL-Änderung. Ein Hosterwechsel gehört zur zweiten Kategorie: Domain, Seitenstruktur und Inhalte bleiben identisch, nur der Server, auf dem die Website läuft, wird ausgetauscht. Das bedeutet in der Praxis: Es gibt keine 301-Weiterleitungen einzurichten und kein Tool zur Adressänderung einzureichen – das eigentliche Risiko liegt stattdessen vollständig auf der technischen Seite: Ausfallzeit, verlorene E-Mails oder eine unvollständig übertragene Datenbank.
Typische Auslöser für einen Hosterwechsel
Ein Hosterwechsel wird selten aus Langeweile angestoßen, sondern meist aus einem von wenigen wiederkehrenden Gründen: Der alte Hoster kündigt eine veraltete PHP-Version ab, ohne die die Website nicht mehr sicher betrieben werden kann; die Ladezeiten sind trotz technisch sauberer Website spürbar langsam, weil der gebuchte Tarif zu knapp bemessen ist; oder der Support reagiert bei einem Ausfall zu langsam, um akute Probleme zeitnah zu lösen. In allen drei Fällen ist die Website selbst unverändert gut – nur die technische Umgebung darunter passt nicht mehr, was den Hosterwechsel zur reinsten aller Migrationsformen macht: kein Grund, an Struktur, Design oder Inhalten überhaupt etwas zu ändern.
Die TTL vorbereiten: der wichtigste Schritt Tage vorher
Jeder DNS-Eintrag besitzt eine TTL (Time to Live), die festlegt, wie lange andere Server auf der Welt diesen Eintrag zwischenspeichern, bevor sie erneut nachfragen. Laut Cloudflares eigener Anleitung für Website-Migrationen sollte diese TTL mindestens 24 bis 48 Stunden vor dem geplanten Umzug auf einen kurzen Wert wie 300 Sekunden abgesenkt werden – ein üblicher Wert für Migrationen. Der Effekt: Sobald der DNS-Eintrag am eigentlichen Umzugstag auf den neuen Server umgestellt wird, verbreitet sich diese Änderung weltweit innerhalb weniger Minuten statt womöglich stundenlang an alten, noch zwischengespeicherten Einträgen festzuhalten. Wird dieser Schritt übersprungen, sehen manche Besucher je nach Internetanbieter und vorheriger TTL-Einstellung noch stundenlang die alte Website oder Fehlermeldungen, während andere bereits die neue Version erreichen.
Checkliste: Was beim Umzug alles mitziehen muss
| Baustein | Worauf zu achten ist |
|---|---|
| E-Mail-Postfächer (MX-Records) | Separat von der Website migrieren oder die MX-Records unverändert lassen, wenn E-Mail woanders gehostet wird |
| SSL-Zertifikat | Beim neuen Hoster neu ausstellen lassen, bevor der DNS-Eintrag umgestellt wird |
| Datenbank | Vollständigen, aktuellen Export erst unmittelbar vor der Umstellung ziehen, nicht Tage vorher |
| Dateien und Medien | Bilder, Dokumente und Uploads vollständig übertragen, nicht nur den reinen Datenbankinhalt |
| Cronjobs und automatisierte Skripte | Auf dem neuen Server neu einrichten, sie werden bei einem Umzug nie automatisch mit übernommen |
Ein Beispiel zur Einordnung: Ein Malerbetrieb zieht mit seiner Website zu einem neuen Hoster um, vergisst dabei aber, dass die Kontaktformular-Benachrichtigungen über einen täglichen Cronjob auf dem alten Server versendet wurden. Die Website selbst läuft nach dem Umzug einwandfrei, Anfragen über das Kontaktformular verschwinden aber unbemerkt ins Leere, weil der Cronjob auf dem neuen Server schlicht nie neu eingerichtet wurde – ein Fehler, der erst auffällt, wenn ein Kunde sich nach Wochen ohne Rückmeldung meldet. Ebenso gehört die robots.txt zu den Dateien, die nach jedem Umzug geprüft werden sollten – wie eine versehentlich übernommene Sperre die komplette Website für Suchmaschinen blockieren kann, zeigt unser Ratgeber zu robots.txt.
Der Umzugstag: paralleler Betrieb statt Blackout
Am eigentlichen Umzugstag läuft die Website im Idealfall bereits vollständig getestet auf dem neuen Server, erreichbar über eine temporäre Test-URL oder einen lokal angepassten Eintrag in der eigenen Hosts-Datei – so lässt sich jede einzelne Seite, jedes Formular und jede Funktion prüfen, bevor überhaupt ein einziger Besucher etwas davon mitbekommt. Erst wenn dieser Test vollständig erfolgreich verläuft, wird der DNS-Eintrag umgestellt. Die alte Umgebung bleibt dabei bewusst noch einige Tage aktiv und erreichbar, statt sofort gekündigt zu werden – falls doch ein Problem auftaucht, lässt sich der DNS-Eintrag innerhalb der abgesenkten TTL genauso schnell wieder zurückstellen, wie er umgestellt wurde.
Interaktiv: Ihr Hosterwechsel-Check
Haken Sie ab, was für Ihren geplanten Umzug bereits vorbereitet ist:
Fazit: Der unauffälligste aller Website-Umzüge – wenn man ihn vorbereitet
Ein Hosterwechsel ist von allen Migrationsarten die technisch unauffälligste für Google, weil sich weder URL noch Inhalte ändern – er ist aber auch die einzige, bei der Ausfallzeit und Datenverlust die größere Gefahr sind als ein Rankingverlust. Wer die TTL rechtzeitig senkt, alles auf dem neuen Server vor der Umstellung testet und die alte Umgebung nicht überstürzt abschaltet, kommt in aller Regel ganz ohne spürbare Unterbrechung durch den Umzug. Geht mit dem Hosterwechsel gleichzeitig auch ein neuer Domainname einher, gelten zusätzlich die Regeln aus unserem separaten Ratgeber zum Domainwechsel – inklusive der Frage, ob dafür eine 301- oder eine 302-Weiterleitung infrage kommt, wie unser Ratgeber zu Weiterleitungen zeigt. Wird bei der Gelegenheit auch gleich die gesamte Struktur und das Design überarbeitet, empfiehlt sich zusätzlich ein Blick in unseren Ratgeber zum Website-Relaunch.