Sie können Ihre Website ohne oder mit minimaler Ausfallzeit zu einem neuen Hoster umziehen, wenn Sie eine feste Reihenfolge einhalten: Backup, vollständiges URL‑Mapping mit 301‑Weiterleitungen, ein Test auf Staging, danach DNS und TTL umstellen, zum Schluss Monitoring. Wer einen dieser Schritte überspringt, riskiert Rankingverluste oder tagelangen E‑Mail‑Ausfall.
Die drei größten Gefahren beim Website Umzug sind fehlende Redirects, eine zu hohe TTL beim DNS‑Wechsel und vergessene MX‑Records. Zentrale Werkzeuge dafür: die Google Search Console mit ihrem Change‑of‑Address‑Feature, saubere 301‑Weiterleitungen und eine korrekt konfigurierte CMS‑Installation, etwa bei WordPress.
- Backup von Dateien und Datenbank vor jedem Schritt
- Komplette 1:1‑Redirect‑Map statt pauschaler Weiterleitung auf die Startseite
- Testumzug auf einer Staging-Domain durchführen, bevor DNS umgestellt wird
- TTL rechtzeitig senken, MX‑Records separat prüfen
- Nach dem Launch mindestens acht Wochen aktiv beobachten
Profi-Tipp: Ziehen Sie bei eine große Anzahl von URLs, bei einem Onlineshop oder bei gleichzeitigem Domainwechsel eine Agentur hinzu. Der technische Aufwand ist überschaubar, das SEO‑Risiko bei Fehlern dagegen nicht.
Wichtige Erkenntnisse
Ein erfolgreicher Website Umzug steht und fällt mit vollständigem URL‑Mapping, korrekt gesetzten 301‑Weiterleitungen und mehrwöchigem Monitoring nach dem Livegang.
| Thema | Details |
|---|---|
| Reihenfolge einhalten | Backup, Redirect‑Mapping, Staging‑Test, DNS/TTL‑Wechsel, Monitoring, in genau dieser Abfolge. |
| Redirects vollständig planen | Jede alte URL braucht eine eigene 301‑Weiterleitung, keine pauschale Umleitung auf die Startseite. |
| TTL rechtzeitig senken | DNS‑Einträge mehrere Tage vor dem Cutover auf einen niedrigen TTL‑Wert setzen. |
| Search Console richtig nutzen | Change‑of‑Address nur bei Domainwechsel einsetzen, Sitemap und URL‑Inspektion begleitend prüfen. |
| Übergabe an Profis erwägen | Einfach-sichtbar übernimmt Testumzug, Redirect‑Map und Nachsorge bei Shops, Domainwechseln und größeren Projekten. |
Inhaltsverzeichnis
- Vorbereitung: Welche Zugänge und Entscheidungen Sie für den Website Umzug brauchen
- Backup und Export: Dateien und Datenbank richtig sichern
- Wie übertragen Sie Dateien und Datenbank auf den neuen Server?
- Domain, DNS und TTL: Wann ist der richtige Zeitpunkt für die Umstellung?
- Wie schützen Sie Ihr Ranking mit Redirects und der Search Console?
- Staging und Launch‑Tag: Was gehört auf die Start‑Checkliste?
- Wie überwachen Sie die Website in den ersten Wochen nach dem Umzug?
- Sonderfälle: Baukästen, Shops, HTTPS und Domainwechsel
- Aus der Praxis: Wann übernehmen wir den Umzug?
- Migration abgeben statt selbst durchführen: Was Einfach-sichtbar übernimmt
- Quellen
Vorbereitung: Welche Zugänge und Entscheidungen Sie für den Website Umzug brauchen
Bevor Sie eine einzige Datei verschieben, brauchen Sie Zugriff auf sechs Stellen: FTP/SSH, das Kontrollpanel des Hosters, phpMyAdmin, den CMS‑Admin, den Domain‑Registrar und den E‑Mail‑Provider. Fehlt einer davon, steht der Umzug still, oft genau am Tag, an dem Sie ihn geplant hatten.
Erstellen Sie parallel eine Inventarliste: die komplette Verzeichnisstruktur, alle Datenbanken, installierte Plugins und Themes, SSL‑Zertifikate, DNS‑Einträge und die MX‑Records für den E‑Mail‑Verkehr. Diese Liste ist Ihre Referenz, falls nach dem Umzug etwas fehlt.
Drei Entscheidungen fallen jetzt, nicht später:
- Big‑Bang oder gestaffelt? Ein kompletter Wechsel an einem Tag ist bei kleinen Seiten meist einfacher, bei Shops mit hohem Traffic ist ein gestaffelter Umzug schonender.
- Domain behalten oder wechseln? Ein reiner Hostingwechsel ohne Domainänderung ist technisch deutlich risikoärmer als ein gleichzeitiger Domainwechsel.
- Wann ist das Cutover‑Fenster? Wählen Sie ein Zeitfenster mit wenig Traffic, etwa nachts oder am Wochenende.
Bei der Wahl des neuen Hosters entscheiden Servertyp, aktuelle PHP‑Version und reale Ladezeiten über spätere Performance. Ein Blick auf passende Hosting‑Angebote für kleine Unternehmen hilft bei der Vorauswahl.
Profi-Tipp: Machen Sie einen kompletten Testumzug auf eine Staging‑Domain oder Subdomain, bevor der eigentliche Cutover ansteht. Das kostet eine halbe Stunde, spart aber im Ernstfall einen ganzen Tag Fehlersuche unter Zeitdruck.
Backup und Export: Dateien und Datenbank richtig sichern
Ohne vollständiges Backup ist jeder Umzugsversuch ein Blindflug. Sichern Sie zuerst alle Server‑Dateien per SFTP oder rsync, inklusive der Verzeichnisse public_html, wp-content und aller Upload‑Ordner mit Bildern und Dokumenten.
- Server‑Dateien komplett per SFTP oder rsync auf einen lokalen Rechner oder externen Speicher kopieren.
- Datenbank per
mysqldumpexportieren, alternativ über phpMyAdmin mit der Exportfunktion. - Beim Export auf den richtigen Zeichensatz achten, meist
utf8mb4, sonst drohen kaputte Sonderzeichen nach dem Import. - PHP‑Version, MySQL‑ oder MariaDB‑Version und CMS‑Version notieren und mit dem neuen Server abgleichen.
- Einen Rollback‑Plan festlegen: Was passiert, wenn der Cutover fehlschlägt und Sie zur alten Umgebung zurückkehren müssen?
Ein Rollback bedeutet meist nur, DNS auf die alte Adresse zurückzustellen und die alte Umgebung noch ein paar Tage aktiv zu lassen. Genau deshalb sollte niemand die alte Website sofort nach dem Umzug löschen.
Profi-Tipp: Bewahren Sie zwei Backup‑Kopien an getrennten Orten auf, etwa lokal und in einem Cloud‑Speicher. Ein einziger korrupter Datenbank‑Dump kann sonst den gesamten Zeitplan zunichtemachen.
Wie übertragen Sie Dateien und Datenbank auf den neuen Server?
Der eigentliche Transfer läuft in zwei parallelen Strängen: Dateien und Datenbank. Laden Sie zuerst alle Dateien per SFTP, rsync oder über das Controlpanel des neuen Hosters hoch, und prüfen Sie danach die Dateirechte, denn falsche Berechtigungen sind eine der häufigsten Ursachen für weiße Seiten nach dem Upload.
- Neue Datenbank beim Zielhoster anlegen und Zugangsdaten notieren.
- Datenbank‑Dump importieren, dabei erneut auf
utf8mb4achten. - Zugriffsdaten in der CMS‑Konfiguration anpassen, bei WordPress in der Datei
wp-config.php, dort Datenbankname, Nutzer, Passwort und Host eintragen. - Permalinks, Plugin‑Aktivierung und Theme‑Darstellung prüfen.
- Bei Joomla die Konfigurationsdatei
configuration.phpentsprechend anpassen und den globalen Konfigurationscheck im Backend durchlaufen lassen.
Bei Shop‑Plattformen kommen meist zusätzliche Schritte hinzu, etwa das Neuverbinden von Zahlungs‑APIs oder Cronjobs. Für die Fehlersuche helfen das PHP‑Error‑Log, die im CMS integrierten Debug‑Modi und ein Blick in die Server‑Fehlerprotokolle. Wer hier systematisch vorgeht, findet die meisten Probleme innerhalb weniger Minuten statt Stunden.
- Prüfen Sie, ob alle Bilder und Medien tatsächlich geladen werden, nicht nur die Textseiten.
- Kontrollieren Sie, ob Formulare, Suchfunktion und interne Verlinkung fehlerfrei funktionieren.
- Testen Sie mehrere Unterseiten verschiedener Content-Typen, nicht nur die Startseite.
Domain, DNS und TTL: Wann ist der richtige Zeitpunkt für die Umstellung?
Ein Domain‑Transfer und eine DNS‑Änderung sind zwei verschiedene Dinge, die oft verwechselt werden. Beim Domain‑Transfer wechselt die Domain den Registrar, dafür brauchen Sie einen Auth‑Code (EPP‑Code) und müssen die Domain‑Sperre beim bisherigen Registrar aufheben. Bei einer reinen DNS‑Änderung bleibt die Domain beim gleichen Registrar, nur die Nameserver oder einzelne DNS‑Einträge zeigen auf den neuen Server.
Die TTL, also die Time‑to‑Live eines DNS‑Eintrags, bestimmt, wie lange Provider und Browser einen alten Eintrag zwischenspeichern. Senken Sie die TTL mehrere Tage vor dem geplanten Cutover auf einen niedrigen Wert, etwa 300 Sekunden, damit die Umstellung schneller wirksam wird. Nach dem Wechsel kann die vollständige weltweite Propagation je nach Provider einige Stunden dauern.
- TTL rechtzeitig senken, mindestens 24 bis 48 Stunden vor dem Cutover.
- Cutover‑Fenster mit wenig Traffic wählen und Verantwortliche informieren.
- MX‑Records separat prüfen und erst umstellen, wenn E‑Mail auf dem neuen System sauber läuft.
- Alte Umgebung nach dem Wechsel noch einige Tage aktiv lassen, für den Fall eines Rollbacks.
Profi-Tipp: Stellen Sie MX‑Records nie gleichzeitig mit den Website‑DNS‑Einträgen um. E‑Mail‑Ausfälle durch verfrühte MX‑Änderungen fallen oft erst auf, wenn längst Kundenanfragen verloren gegangen sind, wie Praxisleitfäden zum Homepage‑Umzug betonen.
Ein weiterer Punkt, der bei DNS‑Timing oft übersehen wird: Manche Teams machen die neue Domain schon sieben bis 14 Tage vor dem finalen 301‑Cutover für Suchmaschinen crawlbar, um die Indexierung besser zu steuern, wie aktuelle Migrations‑Checklisten beschreiben. Das ist kein Muss, aber ein nützlicher Kniff bei größeren Seiten.
Wie schützen Sie Ihr Ranking mit Redirects und der Search Console?
Der teuerste Fehler beim Website Umzug ist eine pauschale Weiterleitung aller alten URLs auf die neue Startseite. Google verliert dadurch jeden Kontext, welche neue Seite zu welcher alten gehört, und die Rankings brechen ein. SEO‑Experten sehen genau das als einen der häufigsten und schädlichsten Fehler bei Migrationen überhaupt: Migration ist eben ein SEO‑Projekt, kein reiner technischer Transfer.
Google empfiehlt eine klare Vorgehensweise: serverseitige permanente Redirects vom Typ 301 oder 308, eine saubere 1:1‑URL‑Mapping‑Strategie, keine Redirect‑Ketten und das Beibehalten der Weiterleitungen möglichst lange, idealerweise mindestens ein Jahr. Vermeiden Sie 302‑Weiterleitungen, Meta‑Refresh und JavaScript‑Redirects. Diese Signale interpretiert Google als temporär, nicht als dauerhaften Umzug.
So läuft das Mapping in der Praxis ab:
- Crawlen Sie die alte Website vollständig mit einem Tool wie Screaming Frog und exportieren Sie alle URLs.
- Erstellen Sie eine Mapping‑Tabelle: alte URL in Spalte eins, neue Ziel‑URL in Spalte zwei.
- Implementieren Sie die Redirects serverseitig, etwa in der
.htaccess‑Datei oder über ein Plugin. - Testen Sie jede Weiterleitung einzeln mit einem Statuscode‑Checker, bevor die Domain live geschaltet wird.
Für WordPress bietet sich das Plugin Redirection an, besonders wenn kein direkter Serverzugriff für die .htaccess‑Datei besteht. Es verwaltet Weiterleitungen direkt im CMS und protokolliert 404‑Fehler, die nach dem Umzug auftauchen.
- Nutzen Sie das Change‑of‑Address‑Tool in der Google Search Console nur bei einem echten Domainwechsel, nicht bei einem reinen Hostingwechsel ohne URL‑Änderung.
- Reichen Sie die aktualisierte Sitemap auf der neuen Domain ein und nutzen Sie die URL‑Inspektion für stichprobenartige Prüfungen.
- Prüfen Sie canonical Tags und robots.txt auf beiden Seiten, alte wie neue Domain.
Das Change-of-Address-Signal öffnet ein mehrmonatiges Fenster, in dem Google Ranking‑ und Vertrauenssignale von der alten auf die neue Domain überträgt. Es ersetzt aber keine korrekten 301‑Weiterleitungen, sondern ergänzt sie nur.
Profi-Tipp: Löschen Sie funktionierende Redirects nicht nach ein paar Wochen. Google und andere Suchmaschinen brauchen teils Monate, um alle alten URLs neu zu bewerten, gerade bei größeren Websites.
Staging und Launch‑Tag: Was gehört auf die Start‑Checkliste?
Vor dem eigentlichen Go‑Live steht ein Testlauf auf Staging, keine Ausnahme. Prüfen Sie mindestens mehrere zufällig ausgewählte URLs quer durch alle Seitentypen, testen Sie Kontaktformulare und bei Shops den kompletten Checkout‑Pfad bis zur Bestellbestätigung.
- SSL‑Zertifikat auf dem neuen Server installieren und aktivieren, HSTS‑Header prüfen und nach Mixed‑Content‑Warnungen suchen.
- Mobile und Desktop‑Performance testen, etwa mit den gängigen Browser‑Entwicklertools.
robots.txtund Meta‑Tags aufnoindexdurchsuchen, diese Sperren müssen vor dem Livegang entfernt werden.- Aktualisierte Sitemap auf der neuen Domain hochladen und bei der Search Console einreichen.
- Zeitplan und Kommunikationsweg für das Launch‑Fenster festlegen, inklusive Ansprechpartner für den Ernstfall.
- Testen Sie die neue Umgebung über eine Testdomain oder durch Anpassen der lokalen Hosts‑Datei, bevor DNS live geschaltet wird.
- Kontrollieren Sie systematisch alle HTTP‑Statuscodes, kein einziger 404 sollte unbemerkt bleiben.
- Informieren Sie alle beteiligten Personen über das genaue Zeitfenster des Cutovers.
Ein vergessenes noindex im Staging‑robots.txt ist einer der häufigsten Gründe, warum eine frisch umgezogene Website plötzlich aus dem Suchindex verschwindet.
Wie überwachen Sie die Website in den ersten Wochen nach dem Umzug?
Die ersten sieben Tage nach dem Cutover verlangen tägliche Kontrolle. Prüfen Sie die Search Console auf Crawling‑Fehler, kontrollieren Sie Analytics auf ungewöhnliche Traffic‑Einbrüche und beobachten Sie Ihr Ranking‑Tracking auf plötzliche Ausschläge.
Ab Woche zwei reicht ein wöchentlicher Rhythmus, den Sie über insgesamt acht bis zwölf Wochen durchhalten sollten. Praktiker empfehlen genau dieses Zeitfenster, weil sich viele Probleme erst mit Verzögerung zeigen, wenn Google die neue Domain vollständig neu bewertet hat.
Typische Probleme in dieser Phase:
- Fehlende Redirects für URLs, die beim ersten Mapping übersehen wurden.
- Redirect‑Ketten, bei denen eine alte URL über drei oder vier Zwischenschritte zur finalen Seite führt.
- Blockaden durch eine versehentlich zu restriktive
robots.txt. - Verlorene interne Verlinkung, weil interne Links noch auf alte URLs zeigen.
Die passenden Gegenmaßnahmen sind meist schnell umgesetzt:
- Fehlende Redirects sofort nachpflegen, sobald sie in den Crawl‑Daten auftauchen.
- Canonical Tags auf allen wichtigen Seiten kontrollieren.
- Sitemap nach größeren Korrekturen erneut bei der Search Console einreichen.
- Interne Links, die noch auf alte URLs verweisen, systematisch austauschen, wie es auch der Leitfaden zur internen Verlinkung empfiehlt.
Viele Websites erleben laut gängigen Migrations‑Checklisten eine anfängliche Traffic‑Delle mit anschließender Erholung innerhalb weniger Wochen, sofern die Redirects sauber sitzen. Werkzeuge wie die Search Console, ein Site‑Audit, Server‑Logs zur Aufdeckung von Redirect‑Ketten und ein Rank‑Tracker gehören in diese Phase fest dazu.
Profi-Tipp: Exportieren Sie vor dem Umzug eine vollständige Liste aller aktuell rankenden URLs samt ihrer Top‑Keywords. Nach dem Launch vergleichen Sie diese Liste wöchentlich mit den aktuellen Rankings, das zeigt Probleme oft Tage früher als ein Blick auf den Gesamttraffic.
Sonderfälle: Baukästen, Shops, HTTPS und Domainwechsel
Bei Homepage‑Baukästen wie Wix oder Jimdo ist ein direkter technischer Umzug meist gar nicht möglich, da diese Systeme keinen klassischen Datei‑ oder Datenbankexport anbieten. Inhalte müssen dann größtenteils manuell übertragen werden, oder eine Agentur übernimmt den kompletten Aufbau neu.
Bei Onlineshops kommen zusätzliche Baustellen dazu: Zahlungsanbieter neu verbinden, Webhooks aktualisieren, Bestellhistorie sichern und Cronjobs für automatisierte Prozesse neu einrichten. Ein Wechsel von HTTP zu HTTPS zählt technisch als vollständige URL‑Änderung und braucht daher ebenfalls 301‑Weiterleitungen, sonst drohen Mixed‑Content‑Fehler. Wichtig für die Search Console: Das Change‑of‑Address‑Tool greift nur bei einem echten Domainwechsel, nicht bei einem reinen Hostingwechsel.
Aus der Praxis: Wann übernehmen wir den Umzug?
Bei Onlineshops, eine große Anzahl von URLs, einem gleichzeitigen Domainwechsel oder einem parallelen Redesign empfiehlt sich aus unserer Sicht die Übergabe an Profis. Das Risiko für Umsatz und Rankings steigt in diesen Fällen überproportional zum technischen Aufwand.
Übernehmen wir einen Umzug, gehören ein vollständiger Testumzug, eine geprüfte Redirect‑Map und mehrwöchige Nachsorge standardmäßig dazu, nicht als Zusatzoption. Genau diese drei Bausteine entscheiden meist darüber, ob eine Migration reibungslos verläuft oder Wochen an Ranking kostet.
Migration abgeben statt selbst durchführen: Was Einfach-sichtbar übernimmt
Einfach-sichtbar ist die Alternative zum eigenhändigen Website Umzug für Unternehmen in Konstanz und am Bodensee, die keine Zeit für Redirect‑Tabellen und DNS‑Feineinstellungen haben, aber trotzdem keinen Rankingverlust riskieren wollen. Statt sich durch Server‑Logs und .htaccess‑Dateien zu arbeiten, übergeben Sie den kompletten Ablauf.
Im Leistungspaket enthalten sind ein vollständiger Testumzug auf Staging, eine geprüfte 1:1‑Redirect‑Map, die korrekte Einrichtung der Search Console samt Sitemap und ein Monitoring‑Zeitraum über mehrere Wochen nach dem Livegang. Für kleine Unternehmen mit Shop, für einen anstehenden Domainwechsel oder wenn parallel gleich ein neues Design entstehen soll, ist das der Weg mit dem geringsten Risiko. Werfen Sie einen Blick auf unsere Leistungen rund um Website‑Relaunch und SEO‑Sicherung oder kontaktieren Sie uns direkt über unsere Website, um Ihren Umzugstermin und Umfang zu besprechen.
Quellen
Für die Umsetzung lohnt sich ein Blick auf wenige, aber verlässliche Werkzeuge:
Prüfen Sie zuerst die Search Console, dann die Redirect‑Tests, erst danach die Sitemap.