Domain und Hosting umziehen ohne Datenverlust und Ranking-Einbruch

Von Manuel Hack, ihp media · Aktualisiert am 21. Juni 2026

Ein Hoster-Wechsel ist einer der Momente, in dem viele Betreiber nervös werden. Zu Recht, denn die häufigsten Fehler passieren nicht beim Umzug selbst, sondern vorher und nachher. Wer die Reihenfolge kennt und die paar kritischen Stellen versteht, kann den Wechsel ohne Datenverlust und ohne sichtbare Ranking-Einbrüche durchführen.

Was beim Umzug wirklich schiefgehen kann

Vier Szenarien machen den größten Schaden. Erstens der DNS-Schwenk, bevor der neue Server fertig ist: Besucher und Googlebot landen auf einer halbfertigen oder nicht erreichbaren Seite. Zweitens fehlerhafte 301-Weiterleitungen nach einem Domainwechsel, die auf 404-Seiten zeigen statt auf den richtigen Inhalt. Drittens ein abgelaufenes oder fehlendes SSL-Zertifikat auf dem neuen Server, das im Browser sofort eine Sicherheitswarnung auslöst. Und viertens ein unvollständiger Daten-Transfer, der erst nach dem Umstieg auffällt, wenn kein aktuelles Backup mehr auf dem alten Server liegt.

Was viele unterschätzen: Google bewertet Erreichbarkeit und Ladezeit fortlaufend. Wenn Googlebot die Website während oder kurz nach dem Umzug wiederholt nicht erreicht oder mit Fehlercodes antwortet, kann das die Crawling-Frequenz senken. Ein vollständiger Monitoring-Plan hilft, solche Phasen früh zu erkennen.

Vorbereitung: Backup, Inventar und TTL

Bevor Sie am Server anfassen, müssen drei Vorarbeiten erledigt sein: vollständiges Backup, Inventar aller DNS-Einträge, TTL abgesenkt.

Das Backup deckt drei Ebenen ab: den vollständigen Datenbank-Dump, alle Dateien im Webroot inklusive versteckter Konfigurationsdateien wie .htaccess und wp-config.php, sowie die DNS-Zonendatei. Was eine solide Backup-Strategie konkret bedeutet, erklärt der Ratgeber zum 3-2-1-Backup-Plan im Detail. Fehlt nach dem Umzug etwas oder ist etwas kaputt, können Sie auf genau diesen Stand zurückgehen.

Das Inventar beantwortet: Welche Subdomains gibt es, welche Postfächer hängen an der Domain, und welche Mail-Einträge (MX, SPF, DKIM, DMARC) müssen mitgezogen werden? Ein vergessener MX-Eintrag unterbricht den E-Mail-Empfang, und das fällt Inhabern oft erst Stunden später auf. Rufen Sie die aktuelle DNS-Zone bei Ihrem Registrar ab und dokumentieren Sie jeden Eintrag.

Die TTL-Absenkung ist der am häufigsten übersprungene Schritt. TTL steht für Time to Live und steuert, wie lange DNS-Resolver einen Eintrag im Cache behalten, bevor sie beim autoritativen Nameserver neu anfragen. Viele Anbieter setzen den Standard bei 3600 Sekunden (eine Stunde). Senken Sie die TTL Ihrer A-Records mindestens 24 bis 48 Stunden vor dem geplanten Umzug auf 300 Sekunden ab. Dadurch verbreitet sich die DNS-Änderung später erheblich schneller: Resolver müssen nach spätestens fünf Minuten neu anfragen, statt eine volle Stunde einen veralteten Eintrag auszuliefern.

DNS-Grundlagen: TTL, A-Record und CNAME

Das Domain Name System (DNS) ist das Telefonbuch des Internets: Es übersetzt den menschenlesbaren Domainnamen (z.B. ihp-media.com) in die numerische IP-Adresse des Servers. Beim Hosting-Umzug wechselt der Server und damit die IP-Adresse, der Domainname bleibt gleich. Das DNS-System muss diese neue Zuordnung bekannt machen.

Die wichtigsten Eintragstypen beim Umzug:

• A-Record: Verknüpft einen Domainnamen direkt mit einer IPv4-Adresse. Das ist der Eintrag, den Sie beim Hoster-Wechsel ändern.
• AAAA-Record: Dasselbe für IPv6-Adressen. Wenn Ihr neuer Server IPv6 unterstützt, muss auch dieser Eintrag aktualisiert werden.
• CNAME-Record: Verweist einen Namen auf einen anderen Namen (z.B. www auf ihp-media.com). CNAMEs folgen dem A-Record automatisch, sobald dieser geändert wird.
• MX-Record: Steuert den E-Mail-Empfang. Liegt E-Mail beim selben Anbieter wie Hosting, muss dieser Eintrag beim Hoster-Wechsel mitgezogen werden.
• TTL: Kein eigener Eintragstyp, sondern ein Wert an jedem Eintrag. Er gibt in Sekunden an, wie lange Resolver den Eintrag cachen dürfen.

Die Propagation läuft nicht zentral: Wenn Sie einen A-Record ändern, wird diese Änderung nicht sofort weltweit aktiv. Stattdessen fragt jeder Resolver beim nächsten Ablauf seiner TTL erneut beim Nameserver nach. Mit einer TTL von 300 Sekunden sind nach etwa 5 bis 15 Minuten die meisten Resolver auf dem aktuellen Stand. Mit der Standardeinstellung von 3600 Sekunden kann es eine volle Stunde dauern.

Den neuen Server aufbauen, bevor der DNS wechselt

Der sichere Weg ist die Nutzung einer temporären Adresse für den neuen Server. Viele Hoster stellen dafür eine Subdomain bereit (z.B. ihremseite.hoster-preview.com). Alternativ können Sie auf Ihrem eigenen Rechner die Hosts-Datei (/etc/hosts auf macOS/Linux, C:\Windows\System32\drivers\etc\hosts auf Windows) um einen Eintrag ergänzen, der Ihre Domain temporär auf die neue Server-IP zeigen lässt. Dieser Eintrag gilt nur lokal auf Ihrem Gerät, alle anderen Nutzer und Suchmaschinen sehen weiterhin den alten Server.

Auf dem neuen Server installieren und konfigurieren Sie das vollständige System: PHP-Version prüfen (bei WordPress empfehlen wir PHP 8.2 oder 8.3), alle benötigten Extensions, und die passende PHP-Konfiguration für Uploads und Speicher. Dann importieren Sie Datenbank und Dateien (dazu mehr im nächsten Abschnitt) und passen die Konfigurationsdatei mit den Zugangsdaten des neuen Servers an. Bei WordPress bedeutet das die Datenbankverbindung in der wp-config.php.

Testen Sie anschließend die Seite systematisch: Alle Seiten und Beiträge, Formulare und Login, Shop-Funktionen wenn vorhanden, und die Ladezeit. Als Richtwert für die Core Web Vitals gilt ein Largest Contentful Paint (LCP) unter 2,5 Sekunden als gut. Werte zwischen 2,5 und 4,0 Sekunden gelten als verbesserungswürdig, ab 4,0 Sekunden stuft Google sie als schlecht ein. Idealerweise ist der neue Server hier nicht langsamer als der alte.

Daten sicher übertragen: Datenbank und Dateien

Der Daten-Transfer besteht aus zwei Teilen: der Datenbank und den Dateien. Beide müssen vollständig und konsistent sein.

Exportieren Sie die Datenbank als vollständigen Dump mit mysqldump oder über phpMyAdmin. Prüfen Sie die Dateigröße des Dumps gegen Ihre bekannte Datenbankgröße. Ein unvollständiger Export kann klein sein und trotzdem keine Fehlermeldung enthalten. Importieren Sie auf dem neuen Server und vergleichen Sie anschließend die Tabellenanzahl.

Bei WordPress: Nach dem Import müssen Sie die URL in der Datenbank anpassen, wenn sich die Adresse ändert. Das erledigt wp search-replace 'http://alteseite.de' 'https://neueseite.de' --all-tables. Führen Sie den Befehl auf dem neuen Server aus, nachdem die Datenbank importiert wurde, aber bevor Sie live gehen. Er ersetzt URLs auch in serialisierten PHP-Daten korrekt, was ein manuelles Suchen und Ersetzen zuverlässig verfehlen würde.

Übertragen Sie den kompletten Webroot. Bei WordPress bedeutet das alles unterhalb von /var/www/html/ oder dem konfigurierten Webroot, inklusive wp-content/uploads/, dem Theme und allen Plugins. Vergessen Sie dabei nicht versteckte Dateien: .htaccess (Weiterleitungsregeln, Sicherheitskonfiguration), robots.txt, und eventuell vorhandene .well-known/-Verzeichnisse für SSL-Challenges.

Prüfen Sie nach dem Transfer die Dateianzahl auf beiden Servern. Auf macOS/Linux: find /pfad -type f | wc -l. Stimmt die Zahl nicht überein, fehlen Dateien. Zum Thema Content-Migration beim Relaunch gibt es mehr im Ratgeber zur Content-Migration ohne Ranking-Verlust.

SSL-Zertifikat auf dem neuen Server einrichten

Das SSL-Zertifikat ist an den Server gebunden, nicht an die Domain. Der neue Server braucht deshalb ein eigenes Zertifikat, bevor die Domain auf ihn zeigt. Wenn die Website ab dem ersten Moment nach dem DNS-Schwenk über HTTPS erreichbar ist, gibt es keine Phase, in der der Browser eine Sicherheitswarnung anzeigt.

Die brauchbarste Methode für die Vorauseinrichtung ist die DNS-01-Challenge von Let’s Encrypt. Dabei weisen Sie Kontrolle über die Domain nach, indem Sie einen TXT-Record im DNS setzen. Let’s Encrypt prüft dabei nur, ob Sie DNS-Kontrolle haben, nicht ob der Webserver der Domain schon auf den neuen Server zeigt. Das Zertifikat lässt sich also ausstellen, bevor der A-Record geändert wird.

Die verbreitetere HTTP-01-Challenge dagegen ruft eine Validierungsdatei unter dem Domain-Webroot ab und setzt voraus, dass die Domain schon auf den neuen Server zeigt. Für die Vorauseinrichtung scheidet sie damit aus.

Viele Managed-Hoster stellen Let’s-Encrypt-Zertifikate über ihre Benutzeroberfläche bereit und erneuern sie automatisch. Prüfen Sie in Ihrer Hoster-Dokumentation, wie die Zertifikatsausstellung abläuft, bevor der DNS-Schwenk geplant wird. Was SSL und HTTPS technisch bedeuten, erklärt der Ratgeber zu SSL, HTTPS und Sicherheitsheadern.

Der DNS-Schwenk: Timing und erste Prüfschritte

Erst wenn der neue Server vollständig aufgebaut, getestet, und mit einem gültigen SSL-Zertifikat ausgestattet ist, ändern Sie den A-Record Ihrer Domain auf die neue IP-Adresse. Legen Sie den Zeitpunkt auf eine Phase mit wenig Datenverkehr: typischerweise nachts zwischen 1 und 5 Uhr oder an einem Wochenende.

Unmittelbar nach der Änderung prüfen Sie die Propagation mit einem freien DNS-Check-Dienst wie dnschecker.org. Der Dienst zeigt von verschiedenen Standorten weltweit, welche IP für Ihre Domain ausgeliefert wird. Mit der vorab auf 300 Sekunden gesenkten TTL sind nach etwa 10 bis 20 Minuten die meisten Resolver aktualisiert.

In den ersten 24 bis 48 Stunden läuft der alte Server noch weiter und empfängt Anfragen von Resolvern, die noch den alten Eintrag im Cache haben. Der alte Server sollte in dieser Phase alle eingehenden Anfragen mit einer dauerhaften 301-Weiterleitung auf die entsprechende URL des neuen Servers beantworten, damit auch diese Besucher korrekt weitergeleitet werden.

Nach der vollständigen Propagation setzen Sie die TTL wieder auf einen üblichen Wert von 1800 bis 3600 Sekunden hoch.

Sonderfall: gleichzeitig die Domain wechseln

Wenn Sie nicht nur den Hoster, sondern auch die Domain wechseln, also von altedomain.de auf neuedomain.de ziehen, ist der Aufwand erheblich größer. Der wichtigste Grundsatz laut Google Search Central: Alle URLs der alten Domain müssen dauerhaft per 301-Weiterleitung auf die entsprechenden URLs der neuen Domain zeigen. Nicht nur die Startseite, sondern jede Seite einzeln auf ihr Pendant.

Dazu kommt das Werkzeug zur Adressänderung in der Search Console. Es signalisiert Google explizit, dass Sie einen Domainnamen-Wechsel durchführen. Beide Domains müssen dafür in der Search Console als Eigentümer bestätigt sein. Google empfiehlt, dieses Werkzeug erst nach dem Aktivieren der Weiterleitungen zu nutzen, nicht davor.

Die Weiterleitungen müssen laut Google-Empfehlung so lange bestehen bleiben wie möglich, mindestens aber ein Jahr. Der Grund: Nicht nur Googlebot muss die neue URL lernen, sondern auch alle externen Links auf die alte Domain, RSS-Reader, und andere Crawler. Diese Verknüpfungen sind der übertragene „Linkwert“ aus den Jahren auf der alten Domain, und er überträgt sich nur über aktive Weiterleitungen.

301-Weiterleitungen: technisch korrekt konfigurieren

Eine 301-Weiterleitung ist eine permanente HTTP-Antwort: Der Server antwortet mit dem Statuscode 301 und einem Location-Header, der die neue Zieladresse enthält. Browser und Crawler folgen automatisch. Googlebot interpretiert den 301 als Signal, dass die Ziel-URL die kanonische Adresse sein soll, und aktualisiert seinen Index entsprechend.

Der Unterschied zu einer 302-Weiterleitung ist entscheidend: Eine 302 ist temporär. Googlebot folgt ihr zwar, interpretiert die ursprüngliche URL aber weiterhin als kanonisch und zeigt sie in den Suchergebnissen an. Für einen dauerhaften Umzug ist deshalb immer 301 (oder 308, wenn POST-Methoden erhalten bleiben müssen) zu verwenden.

Auf Apache-Servern konfigurieren Sie Weiterleitungen in der .htaccess:

# Einzelne Seite weiterleiten
Redirect 301 /alte-seite/ https://neuedomain.de/neue-seite/

# Komplette Domain weiterleiten
RewriteEngine On
RewriteCond %{HTTP_HOST} ^altedomain.de [NC]
RewriteRule ^(.*)$ https://neuedomain.de/$1 [R=301,L]

Auf Nginx-Servern entsprechend:

server {
    server_name altedomain.de;
    return 301 https://neuedomain.de$request_uri;
}

Wichtig: Als anerkannte SEO-Praxis gilt, Weiterleitungsketten möglichst kurz zu halten (nicht mehr als rund drei Hops). Googlebot folgt nach Aussagen von Google-Mitarbeitern zwar bis zu zehn aufeinanderfolgenden Weiterleitungen, aber Ketten verlangsamen das Crawling und erhöhen die Fehleranfälligkeit. Direktweiterleitungen von A nach B sind immer besser als Ketten A nach C nach B.

Search Console: Crawling überwachen

Ein reiner Hoster-Wechsel ohne URL-Änderung braucht kein Werkzeug in der Search Console: Google erkennt keinen Unterschied, solange die URLs gleich bleiben und die Seite erreichbar ist. Trotzdem lohnt sich der Blick in die Console in den ersten Tagen nach dem Umzug.

Im Bereich Seitenindexierung sehen Sie, ob neue Fehler auftauchen: ein plötzlicher Anstieg von 404-Meldungen deutet auf eine fehlerhafte .htaccess oder ein Problem mit den URL-Umschreibungsregeln hin. Im Bereich Core Web Vitals erkennen Sie früh, falls der neue Server spürbar langsamer ist als der alte. Und im Crawling-Bericht sehen Sie, ob Googlebot die Seite normal abarbeitet.

Bei einem Domainwechsel melden Sie die neue Domain in der Search Console an, fügen beide Domains als bestätigte Eigentümer hinzu, und nutzen dann das Adressänderungs-Werkzeug. Google gibt an, dass die vollständige Indexierung neuer URLs bei kleinen bis mittleren Websites einige Wochen dauern kann.

Umzugsschritte im Überblick

Ein Beispiel aus der Praxis

Ein typischer Fall: Ein WooCommerce-Shop zieht von einem Shared-Hosting-Anbieter auf einen dedizierten Managed-Server um. Die TTL hat nie jemand angefasst, sie steht auf 86.400 Sekunden (24 Stunden). Das würde bedeuten, dass ein Teil der Besucher nach dem DNS-Schwenk noch 24 Stunden lang auf dem alten Server landet.

Der saubere Weg: die TTL drei Tage vor dem geplanten Termin auf 300 Sekunden senken. Am Umzugstag selbst ist die Propagation dann nach wenigen Minuten weltweit abgeschlossen. Das SSL-Zertifikat wird per DNS-01-Challenge zwei Tage vorher ausgestellt. Nach dem Schwenk läuft die Site sofort mit HTTPS, ohne Warnmeldung, und Googlebot produziert in der Search Console keine einzige Fehlermeldung.

Eine häufige Komplikation: Der SPF-Eintrag enthält noch die IP des alten Mail-Servers. Das fällt nur auf, wenn im Inventar-Schritt alle DNS-Einträge dokumentiert sind, dann wird der SPF-Record parallel zum A-Record aktualisiert. Ohne dieses Inventar fällt der Fehler erst auf, wenn Kunden Bestellbestätigungen nicht erhalten.

Wer dann noch wissen will, worauf beim neuen Hoster zu achten ist, findet eine Übersicht im Ratgeber zu WordPress-Hosting: Tempo und Sicherheit.

Schritt-für-Schritt-Plan: Hosting-Umzug durchführen

Schritt 1: Inventar und Backup erstellen

Dokumentieren Sie alle DNS-Einträge (A, AAAA, MX, TXT, CNAME) der Domain. Erstellen Sie einen vollständigen Datenbank-Dump und sichern Sie alle Dateien im Webroot. Legen Sie das Backup an einem vom alten Server getrennten Speicherort ab.

Schritt 2: TTL absenken

Setzen Sie die TTL des A-Records auf 300 Sekunden. Warten Sie danach mindestens so lange, bis die aktuelle TTL abgelaufen ist (also mindestens die bisherige TTL in Sekunden), damit alle Resolver den neuen Wert übernommen haben. Ideal sind 24 bis 48 Stunden Vorlauf.

Schritt 3: Neuen Server einrichten und testen

Installieren Sie die Serverumgebung (PHP-Version, Extensions, Webserver-Konfiguration). Importieren Sie Datenbank und Dateien. Passen Sie die Konfigurationsdatei mit den Zugangsdaten des neuen Servers an. Testen Sie die Website über die temporäre Adresse des Hosters oder über einen lokalen hosts-Eintrag vollständig.

Schritt 4: SSL-Zertifikat vorab einrichten

Stellen Sie das SSL-Zertifikat für die Produktivdomain per DNS-01-Challenge aus, bevor der DNS-Schwenk stattfindet. Prüfen Sie, ob HTTPS auf dem neuen Server korrekt antwortet.

Schritt 5: DNS-Schwenk durchführen

Ändern Sie den A-Record auf die IP des neuen Servers. Wählen Sie einen Zeitpunkt mit geringem Datenverkehr. Prüfen Sie die Propagation mit dnschecker.org.

Schritt 6: Alten Server überwachen und abschalten

Lassen Sie den alten Server mindestens 48 Stunden laufen und alle eingehenden Anfragen per 301 weiterleiten. Prüfen Sie dessen Zugriffslog auf noch eingehende Anfragen. Erst wenn keine Anfragen mehr ankommen, kündigen Sie den alten Vertrag.

Schritt 7: Search Console und Monitoring prüfen

Kontrollieren Sie in der Search Console täglich die Seitenindexierung und Core Web Vitals. Aktivieren Sie das Uptime-Monitoring auf dem neuen Server.

Sofort-Checkliste: Hosting-Umzug

• Vollständiges Backup erstellt (Datenbank, Dateien, DNS-Zone)?
• Alle DNS-Einträge dokumentiert (A, AAAA, MX, SPF, DKIM, DMARC, CNAME)?
• TTL mindestens 24-48 h vor Umzug auf 300 Sekunden gesenkt?
• Neuen Server vollständig aufgebaut und über temporäre Adresse getestet?
• Datenbank vollständig importiert und Tabellenanzahl geprüft?
• Alle Dateien übertragen, Dateianzahl auf beiden Servern verglichen?
• URL-Ersetzung in der Datenbank durchgeführt (bei Domain- oder Protokollwechsel)?
• SSL-Zertifikat auf neuem Server gültig, HTTPS funktioniert?
• DNS-Schwenk zu einem Zeitpunkt mit geringem Datenverkehr geplant?
• Propagation nach dem Schwenk mit dnschecker.org bestätigt?
• Alter Server noch 48 h aktiv, sendet 301 für alle eingehenden Anfragen?
• Bei Domainwechsel: 301-Weiterleitungen für alle URLs konfiguriert?
• Bei Domainwechsel: Adressänderungs-Werkzeug in der Search Console genutzt?
• E-Mail-Einträge (MX, SPF) beim neuen Anbieter korrekt gesetzt?
• Search Console und Monitoring für erste 7 Tage im Blick?

Häufige Fragen

Verliere ich mein Google-Ranking, wenn ich den Hoster wechsle?

Bei einem reinen Hoster-Wechsel ohne URL-Änderung nicht, wenn die Website während des Umzugs erreichbar bleibt. Google bewertet den Server nicht als Ranking-Faktor, nur Erreichbarkeit und Ladezeit zählen. Rankingverluste entstehen fast ausschließlich durch Fehler im Ablauf: Ausfälle während des Umzugs, oder schlechtere Ladezeiten auf dem neuen Server.

Wie lange dauert die DNS-Propagation nach einem A-Record-Wechsel?

Mit einer vorab auf 300 Sekunden gesenkten TTL sind nach 10 bis 20 Minuten die meisten Resolver weltweit aktualisiert. Mit der Standardeinstellung von 3600 Sekunden kann es bis zu einer Stunde dauern. Manche Resolver und ISPs halten Einträge auch länger als die TTL angibt, weshalb ein sicherer Puffer von 24 Stunden eingeplant werden sollte.

Muss ich bei einem Hosting-Umzug ein neues SSL-Zertifikat beantragen?

Ja. Das Zertifikat ist an den Server gebunden, nicht an die Domain. Der neue Server braucht ein eigenes Zertifikat. Let’s Encrypt stellt kostenlose Zertifikate aus und erneuert sie automatisch. Per DNS-01-Challenge lässt sich das Zertifikat bereits vor dem DNS-Schwenk einrichten.

Was passiert mit meinen E-Mails während des DNS-Umzugs?

Wenn E-Mail und Web bisher beim selben Anbieter lagen und nur das Hosting wechselt, nicht der Mail-Dienst, ändern Sie die MX-Einträge nicht. Sie zeigen weiterhin auf die bisherige Mail-Infrastruktur. Wenn der Mail-Dienst mitumzieht, gibt es ein kurzes Risikofenster. Prüfen Sie in den ersten Stunden beide Postfächer und richten Sie auf dem alten Mail-Server eine Weiterleitung ein.

Muss ich für den Domainwechsel das Adressänderungs-Werkzeug in der Search Console nutzen?

Ja, wenn Sie eine andere Domain nutzen. Das Werkzeug informiert Google aktiv über den Wechsel und beschleunigt die Umindizierung. Ausnahme: der Wechsel von HTTP auf HTTPS bei gleicher Domain. Dafür gibt es kein separates Werkzeug, die Google-Dokumentation empfiehlt hier, HTTPS vollständig einzurichten und dann auf das automatische Crawling zu vertrauen.

Wie lange müssen 301-Weiterleitungen nach einem Domainwechsel aktiv bleiben?

Google empfiehlt, sie so lange wie möglich aktiv zu lassen, mindestens ein Jahr. Das Ranking und der Linkwert der alten Domain übertragen sich über die Weiterleitungen. Schalten Sie sie zu früh ab, verlieren externe Links auf die alte Domain ihre Wirkung, und Google hat keine Möglichkeit mehr, von der alten URL auf die neue zu schließen.

Was ist der Unterschied zwischen einem 301- und einem 302-Redirect?

Ein 301 ist permanent: Google und andere Suchmaschinen aktualisieren ihren Index, ersetzen die alte URL durch die neue und übertragen den Linkwert. Ein 302 ist temporär: Googlebot folgt zwar der Weiterleitung, behandelt die ursprüngliche URL aber weiterhin als kanonisch und zeigt sie in den Suchergebnissen an. Für einen dauerhaften Umzug ist immer der 301 der richtige Code.