Webhosting und ServerRatgeber
Webhosting wechseln ohne Ausfall: Ablauf in sechs Schritten
Für einen Hostingwechsel ohne Ausfall laufen alter und neuer Hoster eine Zeit lang parallel. Du senkst vorab die TTL der DNS-Einträge, kopierst und testest die Website beim neuen Hoster und stellst dann die DNS-Einträge um. Den alten Vertrag kündigst du erst, wenn dort kein Verkehr mehr ankommt.

Ein Hostingwechsel bedeutet, dass deine Website samt Datenbank, Postfächern und Einstellungen auf die Server eines anderen Anbieters zieht. Die Adresse bleibt gleich, für Besucher ändert sich nichts. Der eigentliche Umzug ist ein einziger Schritt: die Änderung der DNS-Einträge, damit die Domain auf den neuen Server zeigt. Alles davor ist Vorbereitung, alles danach Kontrolle [1]. Wenn alter und neuer Hoster für ein paar Tage gleichzeitig laufen, gibt es keine Lücke, in der die Seite nicht erreichbar ist.
Die Domain selbst muss dabei nicht umziehen. Sie kann beim bisherigen Registrar bleiben, solange du dort die DNS-Einträge ändern kannst. Willst du auch die Domain zum neuen Anbieter holen, ist das ein eigener Vorgang mit Auth-Code, beschrieben unter Domain umziehen. Mach die beiden Umzüge besser nacheinander.
Was alles mitkommen muss
Bevor du anfängst, schreib auf, was beim alten Hoster läuft. Vergessene Teile fallen sonst erst auf, wenn der alte Vertrag schon gekündigt ist:
- die Dateien der Website und alle Datenbanken
- die DNS-Zone mit allen Einträgen, auch TXT-Einträge für SPF, DKIM und Bestätigungen von Diensten
- Postfächer, Weiterleitungen und Abwesenheitsnotizen
- Cronjobs, also zeitgesteuerte Aufgaben auf dem Server
- Regeln für Weiterleitungen und Zugriffsschutz, etwa in der .htaccess-Datei
- Dateien zur Bestätigung bei Google Search Console oder anderen Diensten [1]
- Subdomains und ihre Verzeichnisse
Ein Punkt verdient besondere Aufmerksamkeit: Wer betreibt die Nameserver deiner Domain? Bei vielen Paketen beantwortet der alte Hoster auch das DNS. Endet der Vertrag, verschwindet mit ihm die Zone, und die Domain löst nicht mehr auf, selbst wenn die Website längst beim neuen Hoster liegt. In diesem Fall überträgst du zuerst alle Einträge zu einem DNS-Anbieter, der bleibt, und stellst beim Registrar die Nameserver um. Wie das geht, beschreibt Nameserver ändern. Welche Nameserver gerade zuständig sind, zeigt dir eine NS-Abfrage im DNS-Check.
Schritt 1: neuen Hoster einrichten, alten behalten
Schließ den neuen Vertrag ab, bevor du den alten kündigst. Lies beim alten Anbieter nach, welche Kündigungsfrist gilt, und plane den Umzug so, dass genug Zeit bleibt. Wie du bei bekannten Anbietern kündigst, steht auf vertrag-kuendigen.com. Die Kündigung schickst du am besten erst ab, wenn der neue Server läuft und getestet ist, und nimmst als Termin das Ende der Frist.
Beim neuen Hoster legst du die Domain an, ohne die DNS-Einträge schon umzustellen. Verarbeitet der neue Anbieter personenbezogene Daten für dich, etwa Kontaktformulare, Bestellungen oder Postfächer, brauchst du mit ihm einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO [6]. Was darin stehen muss, erklärt Hosting und DSGVO.
Schritt 2: die TTL senken
Resolver speichern DNS-Antworten so lange, wie die TTL des Eintrags erlaubt. Steht sie auf einem Tag, landen manche Besucher nach der Umstellung noch bis zu 24 Stunden beim alten Server. Google rät, die TTL mindestens eine Woche vor dem Umzug auf einen niedrigen Wert zu senken, etwa einige Stunden [1]. Viele DNS-Anbieter erlauben deutlich weniger. Bei Cloudflare liegt das Minimum für Einträge ohne Proxy bei 60 Sekunden, bei Enterprise-Konten bei 30 Sekunden, die Einstellung "Auto" entspricht 300 Sekunden [2].

Wichtig ist der Zeitpunkt. Die neue, kurze TTL wirkt erst, wenn die alte, lange TTL einmal abgelaufen ist. Senkst du sie erst am Umzugstag, hilft sie nicht mehr. Genaueres steht unter TTL bei DNS.
Schritt 3: kopieren und testen
Lade die Dateien auf den neuen Server und spiel die Datenbank ein. Bei WordPress genügt es, Dateien und Datenbank zu kopieren, solange Domain und Adressen gleich bleiben. Ändern sich Name, Benutzer oder Passwort der Datenbank, trägst du die neuen Werte in die Datei wp-config.php ein [3].

Danach testest du gründlich: Seiten, Bilder, Formulare und Downloads [1], dazu Anmeldung und Bestellvorgang, falls die Website sie hat. Google schlägt eine Testumgebung vor, die nur bestimmte IP-Adressen sehen, oder einen vorübergehenden Namen wie beta.beispiel.de. Damit diese Kopie nicht in den Suchergebnissen landet, setzt du dort die Regel noindex [1]. WordPress speichert die eigene Adresse in der Datenbank. Wer die Kopie unter einem anderen Namen testen will, muss die Werte siteurl und home vorübergehend ändern [3].
Einfacher ist oft ein Eintrag in der hosts-Datei deines Rechners. Dort trägst du die Domain mit der IP-Adresse des neuen Servers ein [8]. Nur dein Rechner ruft dann die Seite beim neuen Hoster ab, alle anderen Besucher landen weiter beim alten. Ein Zertifikat für die echte Domain hat der neue Server zu diesem Zeitpunkt oft noch nicht, deshalb siehst du beim Test über HTTPS möglicherweise eine Warnung.
Achte beim Test auch auf die Unterschiede zwischen den Servern. Läuft beim neuen Hoster eine andere PHP-Version, können ältere Erweiterungen Fehler werfen. Hat die Website eigene Regeln für schöne Adressen, empfiehlt WordPress, die .htaccess beim Umzug zu deaktivieren und die Permalinks nach dem Livegang neu zu speichern [3]. Google weist außerdem darauf hin, dass eine Firewall oder ein Schutz gegen Überlastungsangriffe beim neuen Hoster den Googlebot nicht aussperren darf. Ob er die neue Umgebung erreicht, prüfst du mit dem URL-Prüftool der Search Console [1].
Schritt 4: DNS umstellen
Ist alles getestet, entfernst du vorübergehende Sperren auf dem neuen Server, etwa ein Disallow in der robots.txt oder noindex-Regeln aus der Testphase [1]. Dann änderst du die A- und AAAA-Einträge der Domain und der www-Subdomain auf die neuen IP-Adressen. Mit diesem Schritt beginnt der Umzug [1].
Ab jetzt laufen beide Server parallel. Über die Abrufe in den Protokollen siehst du, wie der Verkehr auf dem alten Server abnimmt und auf dem neuen steigt. Mit DNS-Prüfdiensten kannst du kontrollieren, ob Resolver an verschiedenen Orten schon die neuen Werte liefern [1]. Die aktuellen Einträge deiner Domain fragst du mit dem DNS-Check auf dieser Website ab.
Schritt 5: E-Mail und Zertifikat
Liegen auch die Postfächer beim Hoster, legst du sie beim neuen Anbieter vorher mit denselben Adressen an. Dann stellst du den MX-Eintrag um. Ein paar Stunden Übergang sind für den Mailverkehr kein Problem: Kann ein sendender Server eine Mail nicht zustellen, versucht er es nach RFC 5321 frühestens nach etwa 30 Minuten erneut und gibt in der Regel erst nach vier bis fünf Tagen auf [4]. Mails, die in der Übergangszeit noch im alten Postfach ankommen, musst du aber selbst herüberholen, etwa per IMAP mit deinem Mailprogramm.
Denk an den SPF-Eintrag. Er legt fest, welche Server Mails im Namen deiner Domain verschicken dürfen [7]. Verschickt künftig der neue Hoster die Mails, etwa die Nachrichten aus dem Kontaktformular, muss er dort stehen. Wie das geht, steht unter SPF-Eintrag erstellen und prüfen.
Ein Let's-Encrypt-Zertifikat kann der neue Server bei der üblichen HTTP-Prüfung erst bekommen, wenn die Domain auf ihn zeigt, denn Let's Encrypt ruft eine Prüfdatei über die Domain auf Port 80 ab [5]. Fordere das Zertifikat also direkt nach der DNS-Umstellung an. Wer schon vorher eines braucht, nutzt die DNS-Prüfung, bei der ein TXT-Eintrag die Kontrolle über die Domain belegt [5].
Schritt 6: kontrollieren und den alten Vertrag beenden
Nach einem Hostingwechsel crawlt Google oft erst etwas langsamer und dann wieder schneller, manchmal sogar häufiger als vorher. Das liegt daran, dass Google die Crawlrate aus vielen Signalen berechnet, die sich mit dem Hosting ändern [1]. Prüf in der Search Console, ob die Bestätigung deiner Website noch funktioniert, und beobachte die Berichte zur Indexierung [1].

Abschalten solltest du den alten Server erst, wenn dort laut Protokoll kein Verkehr mehr ankommt [1]. Vorher lädst du dir eine vollständige Sicherung herunter, auch der Postfächer. Danach setzt du die TTL wieder auf einen längeren Wert, zum Beispiel eine Stunde.
Ziehst du gleichzeitig auf neue Adressen um, etwa auf eine andere Domain oder eine neue Struktur, ist das kein reiner Hostingwechsel mehr. Dann brauchst du Weiterleitungen für jede alte Adresse, siehe Website-Relaunch ohne Rankingverlust. Bei WordPress stehen die alten Adressen zudem in der Datenbank. Ein einfaches Suchen und Ersetzen über die ganze Datenbank kann Daten beschädigen, weil manche Themes und Widgets die Länge der Adresse mitspeichern. WordPress nennt dafür WP-CLI mit dem Befehl search-replace oder spezielle Plugins, die mit solchen Daten umgehen können [3].
- Organisation Changing your hosting. Google Search Central. Stand 10.12.2025. abgerufen am 29.10.2026
- Organisation Time to Live (TTL). Cloudflare. Stand 16.04.2026. abgerufen am 29.10.2026
- Organisation Migrating WordPress (Advanced Administration Handbook). WordPress.org. Stand ohne Datum. abgerufen am 29.10.2026
- Gesetz RFC 5321: Simple Mail Transfer Protocol, Abschnitt 4.5.4.1. IETF. Stand Oktober 2008. abgerufen am 29.10.2026
- Organisation Challenge Types. Let's Encrypt (ISRG). Stand 12.02.2026. abgerufen am 29.10.2026
- Gesetz Art. 28 DSGVO Auftragsverarbeiter (Verordnung (EU) 2016/679). Europäische Union, Textausgabe dsgvo-gesetz.de. Stand 27.04.2016. abgerufen am 29.10.2026
- Gesetz RFC 7208: Sender Policy Framework (SPF), Version 1. IETF. Stand April 2014. abgerufen am 29.10.2026
- Organisation So bearbeitest du die Hosts-Datei in Windows 10. Kinsta. Stand 01.10.2025. abgerufen am 29.10.2026
Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.
Weitere Artikel
HostingHosting und DSGVOWarum dein Hoster Auftragsverarbeiter ist, was im Vertrag nach Art.
HostingPleskWie du in Plesk Obsidian Domains und Subdomains anlegst, DNS-Zonen einstellst und mit SSL It!
HostingHTTP-Statuscodes von 200 bis 503Was HTTP-Statuscodes wie 200, 301, 404, 410 und 503 bedeuten, wie Browser und Google sie auswerten und welcher Code in …
SSLSSL für SubdomainsWildcard-, SAN- oder Einzelzertifikat für deine Subdomains?