Website umziehen

Bevor irgendetwas kopiert wird, lohnt sich die Gegenprobe: Geht es hier wirklich um einen Hosting-Wechsel — oder um etwas anderes, das nur so aussieht? Dieser Leitfaden behandelt ausschließlich den Fall, dass dieselbe Website, mit denselben Inhalten und derselben Domain, auf einen anderen Server oder zu einem anderen Hoster wandert. Kein Wechsel des Systems, mit dem die Seite läuft, kein neues Design, kein Wechsel der Domain. Wer stattdessen von einer Plattform auf eine andere wechseln will, etwa von einem Baukasten-System zu einer selbst gehosteten Lösung oder zwischen zwei Shop-Systemen, braucht ein anderes Vorgehen als das hier beschriebene — die Fallstricke liegen dort weniger bei DNS und E-Mail, sondern beim Datenexport und -import selbst.

Die Anlässe für einen reinen Hosting-Wechsel wiederholen sich in der Praxis: Der bestehende Hoster wird spürbar langsam oder fällt wiederholt aus, der Tarif wird gekündigt oder läuft aus, ein Wechsel zu einem Anbieter mit besserer Serverleistung, besserem Support oder einem Standort in Deutschland steht an, oder eine Agentur übernimmt die technische Betreuung und bringt die Seite auf eine eigene, verwaltete Infrastruktur. In allen diesen Fällen bleibt die Website als solche unverändert — es ändert sich nur, wo sie physisch liegt und über welche Adresse der Server erreichbar ist.

Der Sonderfall: Website ist zu langsam

Ein Hosting-Wechsel wird oft als Lösung für eine langsame Website ins Spiel gebracht — zurecht, aber nicht als erster Schritt. Bevor du wegen der Geschwindigkeit umziehst, lohnt sich eine kurze Diagnose, ob das Hosting überhaupt die Ursache ist oder ob große Bilder, zu viele Skripte oder fehlendes Caching der eigentliche Bremsklotz sind. Diese Diagnose-Reihenfolge — und wo Hosting darin tatsächlich steht — behandeln wir ausführlich in unserem Leitfaden zur Ursachensuche bei langsamen Websites. Steht am Ende dieser Diagnose fest, dass der Server selbst zu schwach oder überlastet ist, beginnt an genau dieser Stelle der vorliegende Leitfaden.

Ein Punkt, der in den meisten Anleitungen zu kurz kommt und der diesen Leitfaden von einer reinen Kopieranleitung unterscheidet: Der Teil, der beim Umzug am häufigsten kaputtgeht, ist nicht die Website selbst, sondern das, was um sie herum hängt — allen voran die E-Mail-Zustellung. Die folgenden Abschnitte gehen deshalb bewusst nicht nur auf das Kopieren der Dateien ein, sondern auf die vollständige Bestandsaufnahme, die Vorbereitung, den DNS-Wechsel, die E-Mail-Frage und die Nachsorge — in der Reihenfolge, in der ein Umzug tatsächlich abläuft.

Der naheliegende Teil eines Website-Umzugs ist das Kopieren der eigentlichen Dateien und der Datenbank — genau darauf konzentrieren sich die meisten Anleitungen, und genau das ist meist auch der unkomplizierteste Teil. Vier weitere Bestandteile hängen an derselben Domain, werden aber regelmäßig vergessen, weil sie im Alltag unsichtbar im Hintergrund laufen, bis sie plötzlich nicht mehr funktionieren.

E-Mail-Postfächer und Weiterleitungen

Wenn die E-Mail-Adressen auf derselben Domain laufen wie die Website — was beim klassischen Website-Hosting häufig der Fall ist —, hängt an jedem Postfach eine eigene Konfiguration: Zugangsdaten, eingerichtete Weiterleitungen, Filterregeln, manchmal ganze Postfach-Inhalte, die nicht automatisch mitziehen, nur weil die Website umzieht. Wie E-Mail und Website beim Umzug technisch auseinanderfallen können, behandelt Abschnitt 06 im Detail.

Zum selben Themenblock gehören SPF- und DKIM-Einträge: zwei TXT-Einträge, die festlegen, welche Server im Namen der Domain E-Mails versenden dürfen, und die beim Empfänger die Echtheit einer Nachricht bestätigen. Wechselt beim Umzug der Server, von dem aus ausgehende E-Mails verschickt werden — etwa weil ein Kontaktformular künftig direkt vom neuen Server aus verschickt wird, statt wie bisher über einen externen Mail-Anbieter zu laufen —, muss der SPF-Eintrag um diesen neuen Absender ergänzt werden. Fehlt diese Anpassung, werden ausgehende Nachrichten beim Empfänger häufig als Spam eingestuft oder gar nicht zugestellt, ohne dass auf dem eigenen Server ein Fehler sichtbar wird.

SSL-Zertifikat

Das Zertifikat, das für das Schloss-Symbol im Browser sorgt, ist an den Server gebunden, auf dem es ausgestellt wurde — es zieht nicht automatisch mit um. Auf dem neuen Server muss ein neues Zertifikat ausgestellt werden, bevor die Domain dorthin zeigt, sonst begrüßt Besucher eine Sicherheitswarnung statt der Website. Mehr dazu in Abschnitt 07.

Subdomains und Zusatzdienste

Neben der eigentlichen Website hängen an derselben Domain oft weitere Subdomains — ein Shop-Bereich, ein Kundenportal, ein Testsystem, ein Formular- oder Statistik-Dienst eines Drittanbieters. Jede dieser Subdomains hat einen eigenen DNS-Eintrag, der beim Umzug einzeln geprüft und, wenn nötig, einzeln angepasst werden muss — sie ziehen nicht automatisch mit, nur weil die Hauptdomain umgezogen ist.

Externe Dienste, die auf die alte Adresse zeigen

Manche Werkzeuge und Integrationen speichern die IP-Adresse oder den Servernamen des alten Hosts fest ab, statt bei jedem Zugriff neu nachzuschlagen — etwa ein Cronjob bei einem externen Anbieter, ein Backup-Dienst, der sich per FTP auf den alten Server verbindet, oder eine Firewall-Freigabe bei einem Zahlungsdienstleister, die nur die alte Server-IP erlaubt. Eine kurze Liste, was aktuell auf die alte IP-Adresse oder den alten Servernamen zugreift, erspart nach dem Umzug unangenehme Überraschungen.

Die eigentliche Sicherheit bei einem Website-Umzug entsteht nicht beim Kopieren, sondern vorher — durch ein vollständiges Backup und eine kurze, aber wichtige Klärung von Datenbank und Zugangsdaten. Für den Fall eines Domain- oder URL-Wechsels beschreibt die offizielle WordPress-Dokumentation die Reihenfolge so: zuerst ein Backup der bestehenden Website-Dateien herunterladen und die Datenbank exportieren, dann — falls sich die Domain oder URL ändert — die neue Adresse in den Website-Einstellungen eintragen und Dateien sowie Datenbank ein zweites Mal exportieren. Bleiben Datenbank und URL dagegen unverändert, was beim reinen Hosting-Wechsel der Normalfall ist, genügt laut derselben Quelle das einfache Kopieren von Dateien und Datenbank, ohne diesen zusätzlichen Zwischenschritt.

Die alte Version aufheben, nicht löschen

Ein Ratschlag aus derselben Quelle, der sich in der Praxis immer wieder auszahlt: die ursprüngliche Datenbank und die ursprünglichen Dateien vorerst aufzuheben, statt sie sofort zu löschen — für den Fall, dass beim Umzug etwas übersehen wurde und ein Vergleich mit dem Original nötig wird. Erst wenn der neue Server nachweislich fehlerfrei läuft, ist der alte Stand entbehrlich.

Zugangsdaten für Datenbank und Konfiguration

Wenn sich beim Wechsel der Datenbankname, der Datenbank-Benutzer oder das Passwort ändern — was bei einem Hosterwechsel praktisch immer der Fall ist —, müssen diese neuen Werte in der Konfigurationsdatei der Website eingetragen werden, bevor sie auf dem neuen Server läuft. Bei WordPress ist das laut offizieller Dokumentation die Datei wp-config.php; bei anderen Content-Management-Systemen liegt die entsprechende Konfigurationsdatei an einer vergleichbaren Stelle. Ohne diesen Schritt zeigt die Website auf dem neuen Server einen Datenbankfehler, selbst wenn alle Dateien korrekt kopiert wurden.

Die Serialisierungs-Falle bei einer Datenbank-Suche-und-Ersetzen

Ein technisches Detail, das gerade bei WordPress-Websites regelmäßig zu kaputten Seiten führt: Wird eine komplette Datenbank per einfacher Text-Suche-und-Ersetzen auf eine neue Adresse umgeschrieben — etwa weil zusätzlich zum Serverwechsel auch die URL sich ändert —, zerstört das regelmäßig sogenannte serialisierte Daten — WordPress speichert dort die Länge jeder Zeichenkette mit ab, und die stimmt nach einer rohen Textersetzung nicht mehr. Betroffen sind vor allem Theme- und Plugin-Einstellungen, die dann still auf Standardwerte zurückfallen. Deshalb gehört für diesen Fall ein Werkzeug her, das serialisierte Felder korrekt behandelt, statt einer Textersetzung über die komplette Datenbank. Bleibt die URL beim reinen Hosting-Wechsel unverändert, tritt dieses Problem gar nicht erst auf — ein zusätzlicher Grund, Serverwechsel und URL-Wechsel nach Möglichkeit getrennt zu behandeln.

Der Fehler, der einen Umzug am zuverlässigsten in einen Ausfall verwandelt, ist die Reihenfolge zu vertauschen: erst die Domain auf den neuen Server umschalten und dann erst prüfen, ob dort alles funktioniert. Richtig herum läuft es umgekehrt — die Website läuft auf dem neuen Server bereits vollständig und wurde geprüft, bevor überhaupt ein Besucher sie dort zu sehen bekommt.

Die Website vorab erreichbar machen, ohne die Domain umzuschalten

Damit sich die neu aufgesetzte Website testen lässt, bevor die Domain dorthin zeigt, braucht es einen Weg, sie trotzdem aufzurufen. Für den Fall, dass zusätzlich zur neuen Serveradresse auch die URL sich ändert, beschreibt die offizielle WordPress-Dokumentation dafür einen konkreten Kniff: die Werte für „siteurl" und „home" vorübergehend direkt in der Datenbank-Tabelle wp_options auf eine testweise nutzbare Adresse zu setzen, die Website darüber zu prüfen, und die Werte erst kurz vor dem eigentlichen Umschalten wieder auf die endgültige Adresse zurückzustellen. Bleibt die URL beim reinen Serverwechsel unverändert, ist dieser Zwischenschritt nicht nötig — hier reicht in der Praxis meist eine vom Hoster bereitgestellte technische Testadresse für den neuen Server oder ein temporärer, lokaler Eintrag, der den eigenen Rechner testweise auf die neue Server-IP verweist, ohne dass andere Besucher davon etwas mitbekommen.

Was auf dem neuen Server vor dem Umschalten geprüft werden sollte

Ein sinnvoller Prüflauf auf dem neuen Server vor der eigentlichen Umschaltung deckt typischerweise ab: Lädt die Startseite vollständig, inklusive aller Bilder und Skripte? Funktionieren Formulare und, falls vorhanden, ein Login-Bereich? Sind alle Unterseiten erreichbar, nicht nur die Startseite? Stimmen serverseitige Einstellungen wie die PHP-Version oder aktivierte Erweiterungen mit dem überein, was die Website benötigt? Erst wenn diese Fragen mit Ja beantwortet sind, ist der Testlauf abgeschlossen und der eigentliche DNS-Wechsel aus Abschnitt 05 an der Reihe.

Warum diese Reihenfolge Ausfallzeit verhindert

Der eigentliche Gewinn dieser Reihenfolge: Wenn die Domain schließlich auf den neuen Server umgestellt wird, ist dort bereits alles geprüft und funktionsfähig — der DNS-Wechsel selbst wird dadurch zur reinen Formsache statt zum Risiko. Wird stattdessen zuerst umgeschaltet und erst danach getestet, sehen die ersten Besucher im schlechtesten Fall eine fehlerhafte oder unvollständige Website, während der DNS-Wechsel bereits läuft und sich nicht mehr sofort rückgängig machen lässt.

Der DNS-Wechsel ist der Moment, in dem eine Domain offiziell von der alten zur neuen Server-Adresse zeigt — technisch eine einzige geänderte Zeile, praktisch der Schritt, der am meisten Vorbereitung verdient. Der zentrale Eintrag dafür ist der A-Record: Laut Cloudflares eigener Dokumentation zu DNS-Eintragstypen bildet dieser Eintragstyp „einen Domainnamen auf eine oder mehrere IPv4-Adressen" ab — genau dieser Eintrag wird beim Serverwechsel von der alten auf die neue Server-IP-Adresse geändert.

Was TTL praktisch bedeutet

Jeder DNS-Eintrag trägt einen sogenannten TTL-Wert (Time to Live). Laut Cloudflares eigener Erklärung ist TTL „ein Feld bei DNS-Einträgen, das steuert, wie lange jeder Eintrag zwischengespeichert wird — und dadurch, wie lange es dauert, bis Aktualisierungen des Eintrags bei den Endnutzern ankommen". Praktisch heißt das: Ein DNS-Resolver, der die alte IP-Adresse bereits zwischengespeichert hat, liefert diese so lange weiter aus, bis die hinterlegte TTL abgelaufen ist — selbst wenn der Eintrag längst geändert wurde. Cloudflare weist zusätzlich darauf hin, dass die tatsächliche Verbreitung einer Änderung in der Praxis länger dauern kann als die reine TTL, weil zwischengeschaltete Resolver eigene, zusätzliche Cache-Zeiten mitbringen.

Die TTL rechtzeitig senken

Daraus folgt die wichtigste Vorbereitungsmaßnahme vor einem geplanten Umzug: die TTL des betroffenen Eintrags einige Tage vorher deutlich zu senken, bevor überhaupt umgeschaltet wird. Ein Eintrag mit einer TTL von einem Tag sorgt dafür, dass nach der eigentlichen Umschaltung noch bis zu 24 Stunden lang manche Besucher auf dem alten Server landen können, während ein vorab auf wenige Minuten gesenkter Wert die Umschaltung innerhalb kurzer Zeit für die meisten Besucher wirksam werden lässt. Nach erfolgreichem Umzug und ein paar Tagen Beobachtung lässt sich die TTL wieder auf einen höheren, für den Alltag üblichen Wert zurückstellen — ein dauerhaft sehr niedriger Wert erzeugt laut Cloudflares Erklärung lediglich unnötig viele DNS-Abfragen, ohne im Alltag einen Vorteil zu bringen.

Der Fahrplan in der richtigen Reihenfolge

Zusammengefasst läuft der DNS-Teil eines Umzugs in drei Schritten: TTL des A-Records einige Tage vor dem geplanten Termin senken, den neuen Server vollständig fertigstellen und testen (Abschnitt 04), und erst dann den A-Record auf die neue IP-Adresse ändern. Die Grafik im Anschluss zeigt diesen Fahrplan noch einmal im Überblick.

Nicht jeder Umzug beschränkt sich auf die Änderung eines einzelnen A-Records. Wechselt mit dem Hoster auch der Anbieter, der die DNS-Zone selbst verwaltet, ändern sich stattdessen die Nameserver-Einträge (NS-Records) beim Domain-Registrar — ein Schritt, der eine eigene, oft längere Übergangszeit mitbringt, weil auch die NS-Einträge selbst eine TTL tragen, die sich nicht ebenso kurzfristig senken lässt wie die TTL eines einzelnen A-Records. Wer in diesem Fall plant, sollte die neue DNS-Zone beim neuen Anbieter vollständig einrichten und prüfen, bevor am Registrar auf die neuen Nameserver umgestellt wird — dieselbe Logik wie beim Testlauf aus Abschnitt 04, nur eine Ebene höher.

Der mit Abstand häufigste Grund, warum ein an sich sauber geplanter Website-Umzug trotzdem zu einem handfesten Problem wird, ist nicht die Website selbst — es ist die E-Mail-Zustellung, die währenddessen unbemerkt ausfällt. Der technische Grund dafür liegt in einer Eigenheit des DNS-Systems, die selten explizit erklärt wird: Website und E-Mail hängen an zwei völlig getrennten Eintragstypen derselben Domain.

Zwei getrennte Einträge für zwei getrennte Aufgaben

Laut Cloudflares eigener Dokumentation zu DNS-Eintragstypen ist der A-Record dafür zuständig, „einen Domainnamen auf eine oder mehrere IP-Adressen" abzubilden — er sorgt dafür, dass Besucher zur Website finden. Für die E-Mail-Zustellung ist dagegen ein eigener Eintragstyp zuständig: Der MX-Record (Mail Exchange) „wird benötigt, um E-Mails an einen Mailserver zuzustellen", wie es in derselben Quelle heißt. Diese Trennung ist der Kern des Problems: Wird beim Umzug ausschließlich der A-Record auf den neuen Server geändert, bleibt der MX-Record unverändert stehen — E-Mails laufen technisch also völlig unabhängig von der Website weiter dorthin, wo sie vorher hingelaufen sind.

Wo die Falle in der Praxis liegt

Kritisch wird es, wenn der neue Hoster ausdrücklich oder implizit erwartet, dass auch die E-Mail-Postfächer zu ihm umziehen — etwa weil das bisherige Postfach beim alten Anbieter mit der Kündigung des alten Vertrags automatisch deaktiviert wird. In diesem Fall reicht es nicht, nur den A-Record umzustellen: Der MX-Record muss zusätzlich und zum richtigen Zeitpunkt auf den neuen Mailserver zeigen, sonst gehen ab dem Kündigungstermin des alten Vertrags eingehende E-Mails ins Leere, während die Website auf dem neuen Server längst einwandfrei läuft. Umgekehrt gilt genauso: Soll die E-Mail-Zustellung unverändert beim bisherigen Anbieter bleiben, während nur die Website umzieht, darf der MX-Record beim Umschalten gar nicht angefasst werden — nur der A-Record ändert sich, der MX-Record bleibt exakt so stehen, wie er war.

Die Klärung, die vor dem Umzug stattfinden muss

Vor dem eigentlichen DNS-Wechsel gehört deshalb eine einzige, klare Entscheidung auf den Plan: Bleibt die E-Mail-Zustellung beim bisherigen Anbieter, oder zieht sie mit auf den neuen Hoster um? Von dieser Entscheidung hängt ab, ob der MX-Record beim Umzug angefasst wird oder nicht — und sie sollte getroffen sein, bevor die TTL aus Abschnitt 05 gesenkt und der eigentliche Wechsel eingeleitet wird, nicht erst danach, wenn die ersten E-Mails bereits verloren gegangen sind.

Ein Testlauf, der sich lohnt

Wo möglich, lohnt sich vor dem eigentlichen Umzugstermin ein Test-E-Mail-Versand an alle betroffenen Adressen, um zu prüfen, dass die Zustellung zum aktuellen Zeitpunkt tatsächlich funktioniert — als Referenzpunkt, gegen den sich nach dem Umzug vergleichen lässt, ob sich etwas verändert hat.

Ein SSL-Zertifikat ist an den Server gebunden, auf dem es ausgestellt wurde — es lässt sich nicht einfach kopieren wie eine Datei und dann auf dem neuen Server weiterverwenden, wenn dieser Server bei einem anderen Anbieter liegt. Bevor die Domain also auf den neuen Server zeigt, muss dort ein eigenes, gültiges Zertifikat vorhanden sein, sonst begrüßt der Browser jeden Besucher mit einer Sicherheitswarnung statt mit der Website.

Wie kurzlebig moderne Zertifikate sind

Bei den heute gebräuchlichen, kostenlosen Zertifikaten von Let's Encrypt ist diese Kurzlebigkeit sogar eingebaut: „Unsere Standard-Zertifikate sind 90 Tage gültig", heißt es in der offiziellen Let's-Encrypt-Dokumentation, mit der ausdrücklichen Empfehlung, „90-Tage-Zertifikate alle 60 Tage zu erneuern". Diese kurze Gültigkeitsdauer ist kein Zufall, sondern bewusst so gestaltet, dass Erneuerung zur Routineaufgabe wird, die automatisiert im Hintergrund läuft, statt zu einer seltenen, manuellen Ausnahme.

Warum Automatisierung hier der Normalfall ist

Genau diese Automatisierung ist der Grund, warum sich kaum jemand um einzelne Zertifikate kümmert, solange alles am gewohnten Ort läuft — ein sogenannter ACME-Client auf dem Server erneuert das Zertifikat im Hintergrund selbstständig, lange bevor es abläuft. Beim Serverwechsel fällt genau diese eingespielte Automatisierung weg: Der neue Server kennt das alte Zertifikat nicht und muss ein komplett neues ausstellen und einrichten, inklusive der dafür nötigen technischen Prüfung, dass die Domain tatsächlich zum neuen Server gehört.

Die richtige Reihenfolge, damit HTTPS ohne Lücke funktioniert

Die sauberste Reihenfolge sorgt dafür, dass auf dem neuen Server bereits ein gültiges Zertifikat aktiv und geprüft ist, bevor die Domain per DNS-Wechsel dorthin zeigt — nicht erst danach. Bei vielen Hosting-Umgebungen lässt sich ein Zertifikat bereits vorab für die Domain vorbereiten oder über eine temporäre Testadresse verifizieren; wie genau das technisch funktioniert, unterscheidet sich zwischen Hosting-Umgebungen und Serverkonfigurationen und sollte vorab beim jeweiligen Anbieter geklärt werden. Fehlt diese Vorbereitung, entsteht zwangsläufig eine Lücke zwischen dem Moment, in dem die Domain auf den neuen Server zeigt, und dem Moment, in dem dort ein gültiges Zertifikat bereitsteht — in dieser Lücke sehen Besucher eine Warnung statt der Website.

Nach dem Umzug: prüfen, nicht annehmen

Nach der eigentlichen Umschaltung gehört eine bewusste Prüfung dazu, statt sich auf die Automatik zu verlassen: die Website im Browser über die reguläre https-Adresse aufrufen und kontrollieren, dass das Schloss-Symbol ohne Warnung erscheint — an mehreren Unterseiten, nicht nur an der Startseite, da einzelne Bereiche gelegentlich noch auf eine unverschlüsselte Adresse verlinken.

Der DNS-Wechsel selbst ist technisch in Sekunden erledigt — die eigentliche Beobachtungsphase beginnt danach und dauert, bedingt durch TTL und DNS-Verbreitung aus Abschnitt 05, typischerweise ein bis zwei Tage. In dieser Zeit lohnt sich eine bewusste, aktive Kontrolle statt der Annahme, dass ohne Beschwerden schon alles funktioniert.

Was in den ersten Stunden geprüft werden sollte

Direkt nach der Umschaltung: die Website von mehreren Geräten und, wenn möglich, mehreren Internetanschlüssen aus aufrufen — ein Mobilfunknetz zeigt oft schneller die neue Adresse als ein Festnetzanschluss mit lang zwischengespeicherten DNS-Einträgen. Formulare testweise absenden und prüfen, ob die Benachrichtigung tatsächlich ankommt. Bei einem Shop oder einer Buchungsfunktion einen Testkauf oder eine Testbuchung durchspielen, sofern das ohne echte Kosten möglich ist. Und, besonders naheliegend, aber leicht vergessen: eine E-Mail an eine Adresse der eigenen Domain senden und prüfen, dass sie ankommt.

Ein Punkt, der in der Checkliste der ersten Stunden leicht untergeht: serverseitig eingerichtete Cronjobs, etwa für ein nächtliches Backup oder den automatischen Versand einer Newsletter-Ausgabe zu einer festen Uhrzeit. Waren diese Aufgaben direkt beim alten Hosting-Anbieter eingerichtet und nicht innerhalb der Website-Software selbst, ziehen sie nicht automatisch mit um — sie laufen auf dem alten Server einfach weiter, solange dieser noch existiert, oder sie laufen gar nicht mehr, sobald er abgeschaltet wird. Ein kurzer Blick in die Cronjob-Verwaltung des neuen Hosting-Kontos gehört deshalb ebenso in die erste Prüfrunde wie der Blick auf Formulare und E-Mail-Zustellung.

Was in den ersten Tagen im Blick bleiben sollte

Über die ersten ein bis zwei Tage hinweg: die Server-Logs oder das Hosting-Dashboard des neuen Servers auf ungewöhnliche Fehlermeldungen prüfen, die bei geringer Last am Anfang möglicherweise noch nicht aufgetreten sind. Falls eine Analytics- oder Tracking-Lösung im Einsatz ist, die Besucherzahlen im Vergleich zu den Tagen vor dem Umzug beobachten — ein plötzlicher, unerklärter Einbruch kann ein Hinweis auf ein technisches Problem sein, das noch nicht offensichtlich geworden ist. Und, falls externe Dienste aus Abschnitt 02 fest auf die alte Server-Adresse eingerichtet waren, kontrollieren, dass sie zwischenzeitlich auf die neue Adresse umgestellt wurden.

Wann der alte Server abgeschaltet werden darf

Der alte Server oder Hosting-Vertrag sollte erst dann gekündigt oder abgeschaltet werden, wenn die TTL-bedingte Übergangszeit sicher abgelaufen ist und die Kontrolle aus den vorigen Absätzen unauffällig verlief — nicht am Tag der Umschaltung selbst. Wer vorschnell kündigt, während noch einzelne Besucher oder E-Mail-Server durch zwischengespeicherte DNS-Einträge auf der alten Adresse landen, riskiert genau den Ausfall, den die sorgfältige Vorbereitung eigentlich verhindern sollte.

Die meisten Ausfälle bei einem Website-Umzug lassen sich auf eine kleine, wiederkehrende Gruppe von Fehlern zurückführen — nicht auf Pech, sondern auf eine Reihenfolge, die an der falschen Stelle abgekürzt wurde.

Fehler 1: Zuerst umschalten, dann testen

Die Domain wird auf den neuen Server umgestellt, bevor dort überhaupt geprüft wurde, ob die Website vollständig läuft. Richtig: Der neue Server wird komplett fertiggestellt und getestet, bevor der DNS-Eintrag überhaupt geändert wird — siehe Abschnitt 04.

Fehler 2: Die TTL nicht rechtzeitig gesenkt

Die TTL des A-Records steht noch auf einem hohen, alltagsüblichen Wert, wenn umgeschaltet wird — die Folge ist eine unnötig lange, unvorhersehbare Übergangszeit, in der manche Besucher noch stunden- oder tagelang auf dem alten Server landen. Richtig: Die TTL einige Tage vor dem geplanten Termin senken, siehe Abschnitt 05.

Fehler 2 betrifft in der Praxis nicht nur den A-Record: Auch der MX-Record trägt eine eigene TTL, die vor einer geplanten Änderung ebenso vorab gesenkt werden sollte. Wird nur die TTL des A-Records gesenkt und die des MX-Records vergessen, liefern manche einliefernden Mailserver noch stunden- oder tagelang an den alten Mailserver aus, selbst wenn der neue längst korrekt eingerichtet ist. Bleibt der alte Mailserver in dieser Zeit erreichbar, kommen die E-Mails dort an, statt am eigentlich gewollten neuen Ziel — und werden leicht übersehen, weil niemand mehr regelmäßig ins alte Postfach schaut.

Fehler 3: Der MX-Record wird versehentlich mitgeändert — oder vergessen

Entweder wird der MX-Record ohne Absicht mitgeändert, obwohl die E-Mail-Zustellung eigentlich beim bisherigen Anbieter bleiben sollte, oder er wird vergessen, obwohl die Postfächer eigentlich mit umziehen sollten. Beide Varianten führen dazu, dass E-Mails ins Leere laufen, während niemand es sofort bemerkt. Richtig: Vor dem Umzug bewusst entscheiden, ob die E-Mail-Zustellung mitzieht oder nicht, siehe Abschnitt 06.

Fehler 4: Kein gültiges Zertifikat auf dem neuen Server vor dem Umschalten

Die Domain zeigt bereits auf den neuen Server, aber dort ist noch kein gültiges Zertifikat eingerichtet — die Folge ist eine Sicherheitswarnung im Browser, die Besucher zuverlässig abschreckt. Richtig: Zertifikat vorab einrichten und prüfen, siehe Abschnitt 07.

Fehler 5: Der alte Server wird zu früh abgeschaltet

Der alte Hosting-Vertrag wird direkt am Tag der Umschaltung gekündigt, weil die Website auf dem neuen Server ja schon zu laufen scheint. Solange DNS-Einträge irgendwo noch zwischengespeichert sind, führen einzelne Besucher, Suchmaschinen-Crawler oder E-Mail-Server aber noch für Stunden oder Tage zur alten Adresse — ist diese bereits abgeschaltet, laufen sie ins Leere. Richtig: Erst kündigen, wenn die Übergangszeit aus Abschnitt 05 sicher vorbei ist und die Kontrolle aus Abschnitt 08 unauffällig war.

Ob sich ein Website-Umzug in Eigenregie lohnt oder besser an jemanden mit Erfahrung geht, hängt weniger vom guten Willen ab als von drei nüchternen Fragen.

Selbst machen liegt nahe, wenn die Website technisch überschaubar ist — ein einzelnes System, keine Sonderkonfiguration, wenige oder keine eigenen E-Mail-Postfächer auf derselben Domain —, wenn eine kurze, klar kommunizierte Ausfallzeit für das Geschäft dahinter kein ernsthaftes Risiko darstellt, und wenn genug zeitlicher Puffer besteht, um die Beobachtungsphase aus Abschnitt 08 tatsächlich in Ruhe durchzuführen, statt sie zwischen anderen Terminen abzuhaken.

Externe Hilfe wird dagegen sinnvoll, sobald mehrere E-Mail-Postfächer, Subdomains oder Zusatzdienste an derselben Domain hängen und die Bestandsaufnahme aus Abschnitt 02 entsprechend umfangreich ausfällt, sobald die Website geschäftskritisch ist und selbst eine kurze, unbemerkte Ausfallzeit spürbaren Schaden anrichten würde, oder sobald die DNS- und Zertifikatsschritte aus den Abschnitten 05 und 07 unbekanntes Terrain sind und ein Fehler dort schwer zu diagnostizieren wäre, während er bereits läuft. Keine dieser Situationen ist ein Grund zur Sorge — sie ist lediglich ein Hinweis darauf, dass sich der Aufwand für eine erfahrene Begleitung an dieser Stelle auszahlt.

Zwischen komplett selbst und komplett extern liegt in der Praxis noch eine dritte, oft übersehene Option: den Umzug selbst durchzuführen, aber die kritischen Punkte — TTL-Timing, MX-Entscheidung, Zertifikatsstatus — von jemandem mit Erfahrung vorab gegenprüfen zu lassen, bevor der eigentliche Schalter umgelegt wird. Diese Zwischenlösung kostet deutlich weniger Aufwand als eine vollständige Übergabe und fängt trotzdem genau die Fehler aus Abschnitt 09 ab, die in der Praxis am teuersten werden — nicht das Kopieren der Dateien, sondern die Reihenfolge und die Nebenschauplätze drumherum. Wer unsicher ist, ob die eigene Vorbereitung vollständig ist, bekommt mit einer solchen Gegenprüfung oft schon die nötige Sicherheit, ohne den Umzug komplett aus der Hand zu geben.

Ein pragmatischer erster Schritt vor der Entscheidung: die Bestandsaufnahme aus Abschnitt 02 einmal vollständig für die eigene Website durchgehen — Postfächer, Subdomains, externe Dienste. Fällt diese Liste kurz aus, ist ein sorgfältig geplanter Umzug in Eigenregie realistisch. Fällt sie länger aus als gedacht, ist das der ehrlichste Indikator dafür, dass sich eine zweite, erfahrene Perspektive lohnt, bevor der erste Server gekündigt wird.

Bei EINSHOCH übernehmen wir Serverumzüge im Rahmen unserer laufenden technischen Betreuung von WordPress-Websites — inklusive DNS-Planung, E-Mail-Absicherung und Zertifikatswechsel, damit der Umzug für deine Besucher unsichtbar bleibt.

Am Ende bleibt die Grundlogik aus Abschnitt 01: Ein reiner Hosting-Wechsel betrifft dieselbe Website, dieselbe Domain, denselben Inhalt — nur der Ort dahinter ändert sich. Die Reihenfolge aus diesem Leitfaden sorgt dafür, dass genau das auch so bleibt: unsichtbar für jeden, der die Website in dieser Zeit besucht oder eine E-Mail an sie schickt.