Ein Hostingwechsel wirkt zunächst wie ein technischer Adresswechsel, kann aber schnell zu Ausfällen, fehlenden E-Mails oder verlorenen Bestellungen führen. Wer eine Website umziehen möchte, braucht deshalb einen klaren Ablauf für Backup, Datenübertragung, DNS, SSL und Tests. Ich zeige, welche Variante zu welchem Szenario passt, wie viel Zeit und Kosten realistisch sind und wie sich unnötige SEO-Verluste vermeiden lassen.
Ein sauber geplanter Umzug schützt Erreichbarkeit, E-Mail und SEO
- Vollständiges Backup von Dateien, Datenbanken, E-Mails und DNS-Einstellungen erstellen und testen.
- Neue Umgebung zuerst prüfen, bevor die Domain auf den neuen Server zeigt.
- Die DNS-TTL idealerweise 24 bis 48 Stunden vorher auf etwa 300 Sekunden reduzieren.
- Bei einem Domainwechsel sind 301-Weiterleitungen, Canonical-Tags und aktualisierte Sitemaps entscheidend.
- Den alten Server erst abschalten, wenn mindestens mehrere Tage keine Fehler mehr auftreten.
Was bei einem Website-Umzug tatsächlich verändert wird
Ein reiner Hostingwechsel verschiebt die Website auf einen anderen Server, während die Domain gleich bleibt. Für Besucher ändert sich die Adresse nicht. Geändert wird lediglich das Ziel hinter den DNS-Einträgen, also die technische Zuordnung der Domain zur Server-IP.
Ein Domainwechsel ist anspruchsvoller. Dabei ändert sich beispielsweise die Adresse von einer alten Firmen-Domain zu einer neuen Marke. Hostingmigration und Domainmigration sollten möglichst nicht gleichzeitig mit einem kompletten Relaunch, einer neuen URL-Struktur und einem CMS-Wechsel stattfinden. Zu viele Änderungen erschweren die Fehlersuche und erhöhen das SEO-Risiko.
| Variante | Was sich ändert | Typisches Risiko |
|---|---|---|
| Nur neuer Hoster | Server, IP-Adresse und möglicherweise die PHP- oder Datenbankumgebung | Fehlende Dateien, falsche DNS- oder SSL-Konfiguration |
| Neuer Hoster und neue Domain | Technik und öffentliche Webadresse | Rankingverluste durch fehlende Weiterleitungen |
| Migration mit Relaunch | Server, Domain, Design, CMS oder URL-Struktur | Mehrere Fehlerquellen und schwer messbare Auswirkungen |
Ich empfehle fast immer, zuerst nur den Hoster zu wechseln. Wenn die Website stabil läuft, kann die Domain später folgen. Diese Trennung wirkt weniger spektakulär, macht den gesamten Vorgang aber deutlich kontrollierbarer.
Die Vorbereitung entscheidet über Erfolg oder Ausfall
Vor dem eigentlichen Kopieren brauche ich eine vollständige Bestandsaufnahme. Dazu gehören das CMS, die PHP-Version, Datenbanken, Cronjobs, Upload-Verzeichnisse, SSL-Zertifikate, externe Schnittstellen und alle Domains oder Subdomains. Gerade unsichtbare Abhängigkeiten wie Zahlungsanbieter, Newsletter-Systeme oder externe APIs werden bei einem Umzug gern übersehen.
Diese Daten sollten gesichert werden
- Alle Website-Dateien inklusive Uploads, Konfigurationen und versteckten Systemdateien
- Die vollständige Datenbank als geprüfter Export
- E-Mail-Postfächer, Weiterleitungen und Archive
- DNS-Zone mit A-, AAAA-, CNAME-, MX-, TXT- und gegebenenfalls SRV-Einträgen
- SSL- und Sicherheitseinstellungen
- Liste aller aktiven Weiterleitungen und wichtigen URLs
Ein Backup ist erst dann verlässlich, wenn sich daraus eine Wiederherstellung durchführen lässt. Ich würde deshalb nicht nur eine Datei herunterladen, sondern mindestens einen Testimport der Datenbank und eine stichprobenartige Wiederherstellung von Uploads durchführen. Ein Backup, das nie getestet wurde, ist nur eine Hoffnung auf Sicherheit.
Kompatibilität und Kosten realistisch einschätzen
Der neue Tarif muss nicht nur genügend Speicherplatz bieten. Entscheidend sind auch Arbeitsspeicher, CPU-Leistung, PHP-Version, Datenbanktyp, maximale Dateigrößen und verfügbare Cronjobs. Bei WordPress-Projekten mit vielen Plugins kann ein technisch passender, aber sehr knapp dimensionierter Tarif nach dem Umzug langsamer sein als der alte.
| Umfang | Realistischer Zeitbedarf | Typische externe Kosten |
|---|---|---|
| Kleine statische Website | 2 bis 5 Stunden | Etwa 50 bis 250 Euro |
| WordPress-Website mit Datenbank | 4 bis 12 Stunden | Etwa 150 bis 600 Euro |
| Shop oder individuelle Anwendung | 1 bis 3 Arbeitstage | Etwa 600 bis 2.500 Euro oder mehr |
Die Werte sind keine Festpreise. Ein einfacher Umzug kann bei einem Anbieter kostenlos enthalten sein, während ein Shop mit Bestellungen, Warenwirtschaft und individuellen Schnittstellen deutlich mehr Planung benötigt. Die teuerste Variante ist meist ein ungeplanter Ausfall, nicht die sorgfältige Vorbereitung.
So läuft die Migration Schritt für Schritt ab
Der sichere Ablauf besteht aus mehreren klar getrennten Phasen. Ich plane den Umschalttermin bevorzugt an einem Werktag mit gut erreichbaren Ansprechpartnern und möglichst wenig Bestell- oder Formularverkehr. Freitagabend ist dafür selten ein guter Zeitpunkt.
1. Neue Umgebung einrichten
Auf dem Zielserver werden Domain, Datenbank, Benutzer, PHP-Version und notwendige Erweiterungen vorbereitet. Danach kopiere ich Dateien und Datenbank in die neue Umgebung. Bei größeren Projekten sollte die Datenübertragung automatisiert oder per Kommandozeile erfolgen, weil manuelle Uploads fehleranfällig und langsam sind.
2. Website vor dem DNS-Wechsel testen
Die neue Installation lässt sich über eine temporäre Adresse, eine Staging-Subdomain oder einen lokalen Hosts-Eintrag prüfen. Wichtig ist, dass interne Links, Bilder und Weiterleitungen bereits mit der späteren Domain funktionieren. Die DNS-Umschaltung darf nicht der erste Funktionstest sein.
Ich prüfe mindestens Startseite, wichtige Unterseiten, Login, Suchfunktion, Kontaktformulare, Datei-Uploads, Checkout, Benutzerkonten und mobile Darstellung. Bei einem Shop kommt ein Test mit Gutschein, Versand, Zahlung und Bestellbestätigung hinzu.
3. DNS-TTL rechtzeitig reduzieren
Die TTL bestimmt, wie lange DNS-Resolver einen Eintrag zwischenspeichern. Eine Reduzierung auf etwa 300 Sekunden rund 24 bis 48 Stunden vor dem Wechsel kann die Umstellung beschleunigen. Sie garantiert jedoch nicht, dass jeder Besucher exakt nach fünf Minuten den neuen Server erreicht, weil Provider und lokale Systeme eigene Caches verwenden können.
4. E-Mail und SSL nicht vergessen
Für die Website braucht der neue Server ein eigenes gültiges SSL-Zertifikat. Erst danach sollte die Domain umgeschaltet werden. Ebenso wichtig sind MX-Einträge für den Mailverkehr sowie SPF, DKIM und DMARC. Diese DNS-Einträge steuern, ob Nachrichten zugestellt und als vertrauenswürdig eingestuft werden.
Wenn die E-Mail-Postfächer den Anbieter wechseln, müssen sie vorher eingerichtet und die Inhalte synchronisiert werden. Ich lasse den alten Maildienst nach der Umschaltung noch einige Tage aktiv, damit keine Nachricht während der DNS-Propagation verloren geht.
5. DNS kontrolliert umstellen
Für die Website werden meist der A-Record und gegebenenfalls der AAAA-Record angepasst. Wer einen vorgeschalteten CDN- oder Sicherheitsdienst nutzt, ändert möglicherweise nur das Ziel innerhalb dieses Dienstes. Nach der Änderung sollten die DNS-Auflösung, das Zertifikat und die Erreichbarkeit aus verschiedenen Netzen geprüft werden.
6. Daten bei dynamischen Projekten synchronisieren
Bei einer statischen Website reicht meist eine einmalige Kopie. Ein Shop, Forum oder Portal schreibt dagegen laufend neue Daten. Kurz vor dem Umschalten sollte ich deshalb den Schreibzugriff vorübergehend sperren oder eine letzte Datenbanksynchronisation durchführen. Sonst können Bestellungen, Kommentare oder Registrierungen auf dem alten Server zurückbleiben.
Ein Domainwechsel braucht eine eigene SEO-Strategie
Der Wechsel des Hosters allein verursacht normalerweise keinen direkten Rankingverlust. Kritisch wird es, wenn sich zusätzlich URLs, Inhalte, interne Verlinkungen oder die Domain ändern. Google weist bei Standortwechseln darauf hin, dass DNS-Umstellungen eine gewisse Zeit benötigen und der Traffic während der Verteilung schrittweise vom alten auf den neuen Server wandert.
Bei einer neuen Domain erstelle ich deshalb eine vollständige URL-Zuordnung. Jede wichtige alte Adresse erhält eine serverseitige 301-Weiterleitung auf die thematisch passende neue URL. Eine pauschale Weiterleitung aller Seiten auf die Startseite ist bequem, aber für Nutzer und Suchmaschinen meistens die schlechtere Lösung.
Diese SEO-Signale gehören auf die Prüfliste
- 301-Weiterleitungen von allen relevanten alten URLs
- Canonical-Tags mit der jeweils gültigen Zieladresse
- XML-Sitemap mit den neuen URLs
- Robots.txt ohne versehentliche Sperre des Crawlers
- Interne Links, strukturierte Daten und hreflang-Angaben
- Aktualisierte Domain in Analyse-, Consent- und Marketingtools
- Neue Property in der Google Search Console
Bei einem Domainwechsel sollte die alte Website nicht sofort verschwinden. Die Weiterleitungen müssen erreichbar bleiben, solange alte Links, Bookmarks und Suchmaschineneinträge existieren. Mindestens mehrere Monate sind sinnvoll, bei stark verlinkten oder etablierten Domains oft deutlich länger.
Besonders riskant ist die Kombination aus Domainwechsel und neuer URL-Struktur. Wenn beispielsweise aus vielen Produktseiten plötzlich eine einzige Kategorieseite wird, lassen sich Rankingverluste nicht mehr eindeutig dem Hostingwechsel zuordnen. Für mich gilt deshalb die einfache Regel, bei einer Migration so wenig Variablen wie möglich gleichzeitig zu verändern.
Nach dem Umschalten beginnt die eigentliche Kontrolle
Die Website kann technisch erreichbar sein und trotzdem wichtige Funktionen verlieren. Deshalb prüfe ich nach dem DNS-Wechsel erneut die Startseite, zentrale Landingpages, Formulare, Login-Prozesse, Transaktionen und E-Mail-Zustellung. Bei Shops kontrolliere ich zusätzlich Zahlungsstatus, Webhooks und Bestellbestätigungen.
Auch Serverlogs und Monitoring liefern wichtige Hinweise. In den ersten 24 Stunden achte ich besonders auf 404-, 403- und 500-Fehler, ungewöhnliche Antwortzeiten, Datenbankfehler und fehlgeschlagene Cronjobs. Ein einfacher Uptime-Monitor reicht für kleine Projekte, während Shops und Portale zusätzlich Fehlertracking und Performance-Monitoring brauchen.
Lesen Sie auch: Azure Data Lake Storage Gen2 produktiv aufbauen
Ein sinnvoller Rückfallplan
Der alte Server bleibt erreichbar, bis die neue Umgebung stabil läuft. Wenn wichtige Daten fehlen oder der Checkout ausfällt, kann der DNS-Eintrag vorübergehend zurückgesetzt werden. Das funktioniert nur zuverlässig, wenn die alte Installation nicht parallel verändert wird und klar dokumentiert ist, welche Daten seit dem Umschalten entstanden sind.
Nach erfolgreicher Migration erhöhe ich die TTL wieder auf einen normalen Wert, entferne nicht mehr benötigte Testzugänge und prüfe, ob Backups und Updates auf dem neuen System tatsächlich laufen. Den alten Vertrag kündige ich erst, wenn mindestens einige ruhige Betriebstage ohne kritische Fehler vergangen sind.
Selbst umziehen oder Unterstützung beauftragen
Eine kleine statische Website lässt sich mit etwas technischer Erfahrung gut selbst migrieren. Auch eine überschaubare WordPress-Seite ist häufig machbar, wenn Backup, Datenbank und DNS sauber dokumentiert sind. Ich würde den Eigenversuch jedoch nicht an einem Projekt starten, von dem täglich Verkäufe, Leads oder wichtige Kundenkommunikation abhängen.
| Vorgehen | Geeignet für | Worauf es ankommt |
|---|---|---|
| Manuelle Migration | Statische Seiten und kleine CMS-Projekte | Technisches Grundverständnis und getestete Backups |
| Migrationstool des Hosters | Standardinstallationen mit kompatibler Umgebung | Nachkontrolle von Pfaden, E-Mails, SSL und Plugins |
| Agentur oder DevOps-Fachkraft | Shops, Portale und individuelle Anwendungen | Testplan, Monitoring und klarer Rückfallplan |
Automatische Migrationsassistenten sparen Zeit, übertragen aber nicht immer Cronjobs, Sonderkonfigurationen oder externe Integrationen. Meine Erfahrung ist, dass sie als Werkzeug sehr nützlich sind, die Verantwortung für den Funktionstest aber nicht ersetzen.
Der sichere Umzug endet erst nach der ersten ruhigen Woche
Ein erfolgreicher Wechsel ist mehr als eine neue Server-IP. Entscheidend ist die Reihenfolge aus Inventar, geprüftem Backup, vorbereiteter Zielumgebung, kontrollierter DNS-Umschaltung und konsequenter Nachkontrolle. Bei einer neuen Domain kommen Weiterleitungen und die Pflege alter Adressen hinzu.
Wer dynamische Inhalte betreibt, sollte zusätzlich einen kurzen Wartungszeitraum einplanen und die Daten während des Umschaltens schützen. Wenn die Website geschäftskritisch ist, sind ein Testsystem, Monitoring und ein dokumentierter Rückfallplan keine Luxusmaßnahmen, sondern die pragmatischste Form von Risikomanagement.
