Anbieterwechsel: Website umziehen ohne Datenverlust

01Warum Umzüge schiefgehen (und was dabei wirklich verloren geht)

Die kaputten Fälle sehen alle ähnlich aus. Die Ursache liegt fast immer vor dem ersten technischen Schritt.

Wenn ein Umzug schiefgeht, redet danach niemand über Server oder Datenbanken. Es geht um die Bilder, die nur noch als graue Kästchen erscheinen. Um das Kontaktformular, das seit drei Wochen ins Leere sendet, ohne dass es jemandem auffällt. Um zwölf Seiten, die es nach dem Wechsel nicht mehr gibt und die trotzdem noch in Google stehen. Und um das Postfach, in dem seit Dienstag keine Anfrage mehr ankommt. Das sind vier verschiedene Probleme, aber sie haben dieselbe Wurzel: Es wurde umgeschaltet, bevor klar war, was alles dranhängt.

Der zweite Klassiker ist die Reihenfolge. Ein Umzug hat eine natürliche Abfolge, und jeder Schritt setzt voraus, dass der vorherige abgeschlossen ist. Wer die Domain umstellt, bevor die neue Seite unter einer Testadresse vollständig läuft, hat kein Testfenster mehr, sondern eine Live-Baustelle. Wer das alte Hosting kündigt, bevor die neue Umgebung bestätigt läuft, hat keine Rückfallebene. Beides passiert häufiger, als man denkt, weil es sich in dem Moment nach Fortschritt anfühlt.

Der dritte Punkt ist der unangenehmste: fehlende Zugänge. In vielen Bestandsprojekten liegen Domain, Hosting, Analytics und E-Mail bei drei bis fünf verschiedenen Stellen, und der bisherige Dienstleister hat alles in seinen eigenen Konten. Solange das Verhältnis gut ist, ist das lösbar. Wenn der Wechsel im Streit passiert oder der Anbieter schlicht nicht mehr antwortet, wird aus einem Tagesprojekt eine Sache über Wochen. Wem Domain, Code und Inhalte rechtlich gehören, ist ein Thema für sich und steht im Ratgeber zur Eigentumsfrage bei Websites.

Die gute Nachricht: Datenverlust im wörtlichen Sinn ist selten. Was verloren geht, sind meistens Rankings, Erreichbarkeit und Zeit. Und genau diese drei kannst du mit Vorbereitung fast vollständig schützen.

02Was genau umzieht: die vier Ebenen

"Die Website umziehen" ist kein Vorgang, sondern vier voneinander unabhängige.

Bevor du irgendetwas anfasst, trenne gedanklich vier Ebenen. Sie hängen zusammen, aber sie ziehen nicht gemeinsam um, und du kannst jede einzeln testen. Wer diese Trennung nicht macht, schaltet am Ende alles gleichzeitig um und weiß bei einem Fehler nicht, wo er suchen soll.

1. Die Domain: das Nutzungsrecht am Namen, verwaltet beim Registrar. Die Domain muss nicht zwingend mit umziehen. Es reicht oft, die DNS-Einträge zu ändern. Ein Registrarwechsel ist trotzdem sinnvoll, wenn die Domain bisher im Konto des Dienstleisters lag.
2. Das DNS: die Zuordnung von Name zu Server. Hier stehen A- und AAAA-Einträge für die Website, MX-Einträge für E-Mail, TXT-Einträge für SPF, DKIM und diverse Verifizierungen. Das DNS ist der Schalter, an dem der eigentliche Umzug passiert.
3. Die Website selbst: Dateien, Datenbank, Bilder, Konfiguration, Zertifikat. Das ist der Teil, der kopiert und getestet wird, und der bis zur Umschaltung parallel laufen kann.
4. Die Anhängsel: E-Mail-Postfächer, Analytics, Search Console, Newsletter-Tool, Terminbuchung, Chat, Bewertungs-Widgets, Zahlungsanbieter. Diese Dienste merken vom Umzug nichts, brechen aber, wenn Domain-Verifizierungen oder eingebundene Skripte nicht mitgenommen werden.

Die Ebene, die am häufigsten unterschätzt wird, ist die vierte. Eine Firmenwebsite hat nach ein paar Jahren typischerweise fünf bis fünfzehn externe Verbindungen, von denen niemand mehr alle kennt. Geh vor dem Umzug einmal durch den Quelltext deiner Startseite und einer Unterseite und schreib jedes eingebundene Fremdskript auf. Das ist unspektakulär und findet zuverlässig zwei Dinge, an die keiner mehr gedacht hat.

Die E-Mail ist der Sonderfall. Sie hängt am selben Domainnamen wie die Website, ist aber ein völlig getrennter Dienst. Genau deshalb entsteht der teuerste Umzugsfehler überhaupt: Jemand setzt beim neuen Hoster das DNS neu auf, übernimmt dabei die MX-Einträge nicht, und ab dem Moment gehen alle eingehenden Mails an einen Server, auf dem keine Postfächer liegen. Der Absender bekommt oft nicht einmal eine Fehlermeldung. Die Nachrichten sind einfach weg.

03Die Zugänge-Checkliste: was du vor dem Start beisammen haben musst

Ein einziger fehlender Zugang kann den ganzen Umzug blockieren. Prüfe alle, bevor du einen Termin festlegst.

Das ist der Teil, der über Erfolg und Chaos entscheidet. Geh die Tabelle einmal komplett durch und hake nur ab, was du selbst gerade eben eingeloggt gesehen hast. "Der Dienstleister hat gesagt, das läuft auf uns" ist kein Haken. Ein Screenshot aus dem Konto ist einer.

04Die Reihenfolge: Umzug Schritt für Schritt

Jeder Schritt hat einen Grund und einen Platz. Wer die Reihenfolge ändert, verliert die Rückfallebene.

Der folgende Ablauf funktioniert für praktisch jede normale Firmenwebsite, unabhängig davon, ob dahinter WordPress, ein individuelles System oder statische Dateien liegen. Die Zeitangaben beziehen sich auf einen Umzug ohne Redesign. Wenn gleichzeitig neu gebaut wird, ändert sich Schritt 3 bis 5, der Rest bleibt gleich.

Warum Schritt 6 wichtiger ist, als er aussieht

Die TTL ist die Zeitspanne, für die andere Server einen DNS-Eintrag zwischenspeichern dürfen. Steht sie auf 86400 Sekunden, also 24 Stunden, dann sehen Teile des Internets nach einer Umschaltung noch bis zu einen Tag lang den alten Server. Das ist unproblematisch, solange beide Versionen funktionieren. Es wird zum Problem, wenn du zurückwechseln musst, denn dann dauert auch der Rückweg wieder bis zu 24 Stunden.

Deshalb: TTL ein bis zwei Tage vor dem Termin auf 300 Sekunden senken, umschalten, ein paar Tage beobachten und die TTL danach wieder auf einen normalen Wert setzen. Das kostet zwei Minuten und verwandelt einen möglichen Ausfalltag in fünf Minuten.

05Weiterleitungen: der Teil, der über deine Rankings entscheidet

Google kennt deine alten Adressen. Wenn die nicht mehr existieren, verlierst du das, was daran hing.

Eine Website ist für Suchmaschinen kein Gebäude, sondern eine Sammlung von Adressen. Jede einzelne dieser Adressen hat einen eigenen Stand: Sie ist indexiert, sie hat vielleicht Verlinkungen von außen, sie rankt für bestimmte Suchbegriffe. Wenn beim Umzug eine Adresse verschwindet oder sich ändert, ohne dass klar ist, wohin, verliert sie diesen Stand. Nicht sofort, aber innerhalb weniger Wochen.

Der Mechanismus dagegen ist eine Weiterleitung mit dem Statuscode 301, also "dauerhaft verschoben". Sie sagt Browsern und Suchmaschinen: Diese Adresse gibt es nicht mehr, der Inhalt liegt jetzt hier. Suchmaschinen übertragen die Bewertung dann auf die neue Adresse. Wichtig ist der Unterschied zu 302, also "vorübergehend": Der Code signalisiert, dass die alte Adresse zurückkommt, und die Bewertung bleibt an der alten Stelle hängen. Für einen Umzug ist 301 fast immer richtig.

Bevor du weiterleiten kannst, brauchst du die Liste aller alten Adressen. Drei Quellen zusammen ergeben ein gutes Bild: die vorhandene XML-Sitemap, der Bericht über indexierte Seiten in der Google Search Console und ein Crawl der alten Seite mit einem SEO-Tool. Aus den drei Listen entsteht ein Mapping: alte Adresse links, neue Adresse rechts. Diese Tabelle ist das wichtigste Dokument des ganzen Umzugs.

Zwei Dinge noch, die regelmäßig übersehen werden. Erstens: Weiterleitungsketten. Wenn Adresse A auf B zeigt, B auf C und C auf D, funktioniert das zwar, kostet aber Ladezeit und ist fehleranfällig. Löse jede Kette direkt auf, sodass A sofort auf D zeigt. Zweitens: Der Test gehört nach der Umschaltung wiederholt, nicht nur davor. Zieh dir zwanzig zufällige Adressen aus deiner alten Liste, ruf sie auf und prüfe, ob du jeweils auf der richtigen Seite landest, nicht nur irgendwo.

Der Klassiker: noindex vom Testsystem

Während die neue Seite unter einer Testadresse läuft, wird sie üblicherweise für Suchmaschinen gesperrt, entweder über die robots.txt oder einen noindex-Hinweis im Seitenkopf. Genau diese Sperre bleibt nach der Umschaltung erstaunlich oft stehen. Die Folge: Die Seite ist online, sieht gut aus, verschwindet aber innerhalb von zwei bis vier Wochen aus dem Index. Prüfe das am Umschalttag als allerersten Punkt, bevor du irgendetwas anderes testest.

06E-Mail, Formulare und die stillen Ausfälle

Der Teil, der nicht sichtbar kaputt geht. Genau deshalb fällt er wochenlang niemandem auf.

Wenn eine Website nicht erreichbar ist, merkst du es in Minuten. Wenn E-Mails nicht mehr ankommen oder Formulare ins Leere senden, merkst du es unter Umständen erst, wenn ein Kunde anruft und fragt, warum sich niemand meldet. Diese stillen Ausfälle sind der teuerste Teil eines misslungenen Umzugs, weil dabei echte Anfragen verloren gehen.

Bei E-Mail sind drei Dinge zu tun, und sie gehören zeitlich getrennt vom Website-Umzug. Erstens: Notiere die bestehenden MX-Einträge samt Prioritäten sowie alle TXT-Einträge (SPF, DKIM, DMARC, Verifizierungen von Diensten) und übernimm sie unverändert, wenn die Postfächer bleiben, wo sie sind. Zweitens: Wenn die Postfächer mit umziehen, werden sie per IMAP kopiert, nicht neu angelegt. Es gibt Werkzeuge, die das ganze Postfach mit Ordnerstruktur synchronisieren. Drittens: Nach der Umstellung sendest du je eine Testmail von außen an jedes Postfach und von jedem Postfach nach außen.

Beim Versand ist SPF der Punkt, an dem es später hakt. Wenn dein neuer Server Mails verschickt (Kontaktformular, Bestellbestätigung, Newsletter) und im SPF-Eintrag steht nur der alte Anbieter, landen diese Mails im Spam oder werden abgewiesen. Das passiert nicht sofort und nicht bei allen Empfängern, sondern nach und nach. Deshalb gehört ein SPF-Check zur Nachkontrolle.

Kontaktformulare sind der zweite stille Punkt. Nach dem Umzug ändert sich der versendende Server, manchmal auch die Absenderadresse. Teste jedes Formular auf der Live-Seite und nicht nur einmal: einmal mit einem eigenen Postfach als Empfänger und einmal mit einer Adresse bei einem großen Freemail-Anbieter. Wenn nur der zweite Test scheitert, hast du ein Zustellungsproblem und kein Formularproblem.

07Was schiefgehen kann und wie du sofort reagierst

Die häufigsten Pannen mit Symptom, wahrscheinlicher Ursache und der Maßnahme, die am schnellsten hilft.

Fast jede Umzugspanne hat ein charakteristisches Symptom, aus dem sich die Ursache eingrenzen lässt. Die folgende Tabelle deckt ab, was in der Praxis am häufigsten vorkommt. Wichtig ist die Grundregel: Bei einem größeren Problem schaltest du erst zurück und suchst dann in Ruhe. Genau dafür hast du die TTL gesenkt und das alte Hosting behalten.

Ein Punkt zur Ehrlichkeit: Ein sauber vorbereiteter Umzug einer normalen Firmenwebsite ist kein Drama. Wenn du die Zugänge hast, die neue Umgebung getestet ist und die Weiterleitungen stehen, ist der eigentliche Umschalttag langweilig, und genau so soll er sein. Aufwendig wird es in zwei Fällen: wenn das alte System technisch verwahrlost ist (veraltete PHP-Version, kaputte Plugins, gewachsener Wildwuchs) oder wenn Zugänge fehlen. Dann ist der ehrliche Rat oft, nicht umzuziehen, sondern neu zu bauen und den Umzug als Anlass zu nehmen. Wann sich das rechnet, ist eine eigene Rechnung und steht im Ratgeber zum Relaunch.

08Rankings nach dem Umzug: was normal ist und was nicht

Ein kleiner Ausschlag nach unten ist zu erwarten. Ab wann du eingreifen solltest.

Nach einem Umzug bewegen sich Positionen. Das liegt daran, dass Suchmaschinen die Seite neu crawlen, Weiterleitungen verarbeiten und den Server neu einschätzen müssen. Nach der Erfahrung aus Projekten normalisiert sich das bei einem reinen Hosterwechsel ohne Adressänderungen innerhalb von ein bis zwei Wochen. Bei einem Umzug mit neuer URL-Struktur dauert es in der Regel zwei bis sechs Wochen, bei einem echten Domainwechsel eher ein bis drei Monate. Das sind Erfahrungswerte, keine Garantien, und sie hängen stark von der Größe der Seite ab.

Was nicht normal ist: ein Einbruch, der nach drei Wochen weiter zunimmt statt sich zu erholen. Ein vollständiges Verschwinden aus dem Index innerhalb weniger Tage. Oder ein plötzlicher Anstieg der Fehlerseiten in der Search Console. In allen drei Fällen liegt kein "Google braucht Zeit" vor, sondern ein technischer Fehler, und die üblichen Verdächtigen sind: noindex vergessen, robots.txt zu streng, Weiterleitungen falsch oder gar nicht gesetzt, Server zu langsam oder zeitweise nicht erreichbar.

Zwei Dinge helfen konkret. Erstens: Reich nach dem Umzug eine aktuelle XML-Sitemap in der Search Console ein. Das beschleunigt das Neu-Crawlen spürbar. Zweitens: Nutze bei einem echten Domainwechsel die Funktion zur Adressänderung in der Search Console. Sie ist genau für diesen Fall gebaut und gilt nicht für einen reinen Serverwechsel.

Und eine Sache, die du dir sparen kannst: Panik in Woche eins. Wer drei Tage nach dem Umzug anfängt, an Titeln und Texten zu schrauben, weil eine Position gefallen ist, macht die Diagnose unmöglich. Ändere nach einem Umzug zwei Wochen lang möglichst nichts an den Inhalten, damit du Ursache und Wirkung noch auseinanderhalten kannst.

09Fazit: Vorbereitung schlägt Technik

Was du diese Woche tun kannst, unabhängig davon, ob du wirklich wechselst.

Der wichtigste Teil eines Anbieterwechsels passiert, bevor irgendjemand einen Server anfasst. Wenn du die Zugänge hast, weißt, welche Adressen existieren, ein getestetes Backup besitzt und die neue Umgebung unter einer Testadresse läuft, ist der Umschalttag Routine. Fehlt einer dieser vier Punkte, wird jeder technische Schritt zum Risiko, und keine noch so gute Umsetzung gleicht das aus.

Konkrete Empfehlung, auch ohne akuten Wechselwunsch: Nimm dir eine Stunde und geh die Zugänge-Checkliste aus diesem Artikel durch. Logg dich überall selbst ein. Was du nicht selbst öffnen kannst, gehört auf eine Liste, und diese Liste schickst du deinem aktuellen Dienstleister mit der Bitte, dir Zugang einzurichten. Das ist eine völlig normale Bitte, und die Reaktion darauf sagt dir sehr viel über die Zusammenarbeit. Wer sofort Zugänge einrichtet, arbeitet sauber. Wer ausweicht, hat einen Grund.

Wenn du tatsächlich wechselst, halte dich an drei Regeln: erst testen, dann umschalten. Alte Umgebung mindestens 30 Tage parallel behalten. Nicht am Freitag umschalten. Diese drei Sätze verhindern den größten Teil aller Umzugsschäden, die es in die Nachbesprechung schaffen.

Und wenn beim Durchgehen herauskommt, dass die Seite ohnehin technisch am Ende ist: Dann ist der Umzug die falsche Frage. Dann geht es um einen Neubau, bei dem du von vornherein festlegst, dass Domain, Code und Zugänge auf deinen Namen laufen. Bei Pixylmedia ist genau das Standard, und zwar nicht als Zusatzleistung, sondern weil ein Projekt, aus dem du nicht wieder herauskommst, kein gutes Projekt ist. Egal für wen du dich entscheidest: Frag vor der Unterschrift, wie ein Wechsel weg von diesem Anbieter aussehen würde. Die Antwort auf diese Frage ist der beste Qualitätstest, den es gibt.