Website Migration: Anleitung für einen Umzug ohne Traffic-Verlust

Eine Website Migration ist jedes Projekt, das eine Website auf eine neue Adresse, ein neues System oder eine neue Struktur bringt: ein Wechsel des CMS, ein Wechsel der Domain, der Umstieg von HTTP auf HTTPS oder ein Relaunch, der jede URL umbenennt. Die Inhalte überleben den Umzug. Die Adressen, auf die Google, fremde Websites und Ihre eigenen Newsletter zeigen, oft nicht.

Genau in dieser Lücke entsteht der Schaden. Laut Google Search Central sollen die Weiterleitungen bei einem Umzug mit URL-Änderungen mindestens ein Jahr bestehen bleiben, und die Rankings schwanken, solange der Umzug verarbeitet wird. Alles, was in diesem Zeitfenster übersehen wird, kostet Traffic, für den Sie bereits bezahlt haben: eine nicht zugeordnete URL, eine robots.txt aus der Testumgebung, ein Tracking-Tag, das nie in die neuen Templates gewandert ist.

Dieser Leitfaden richtet sich an die Person, die das Projekt freigibt, nicht an die Person, die das Deployment fährt. Er behandelt die vier Umzugsarten und ihr jeweiliges Risiko, die Planung vor dem Bau, den Weiterleitungsplan, die Tests vor dem Launch, die Reihenfolge am Launch-Tag, die Beobachtung in den ersten 30 Tagen und das, was in den Vertrag gehört.

Migration ist ein Wort für vier verschiedene Projekte, und sie tragen nicht dasselbe Risiko. Die erste Frage lautet deshalb: Was ändert sich tatsächlich? Der Ort, an dem die Dateien liegen, das System, das die Seiten ausliefert, der Hostname in der Adresszeile oder die URL-Pfade selbst. Ein Systemwechsel mit unveränderten URLs ist ein ruhiges Wochenende. Ein Domainwechsel, der zusätzlich jede Seite umbenennt, landet später im Post-mortem.

In der Praxis sind die meisten Projekte eine Mischung. Ein Unternehmen ersetzt ein altes CMS, das Marketing wünscht sich bei der Gelegenheit eine neue Navigation, die Rechtsabteilung möchte die Länderdomain aufgeben. Drei Migrationen werden zu einem Launch gebündelt, und wenn der Traffic fällt, kann niemand sagen, welche der drei Ursachen es war.

Wenn Sie aus diesem Leitfaden eine Entscheidung mitnehmen, dann diese: ändern Sie eine Variable nach der anderen, wo der Kalender es zulässt. Erst das System umziehen und die URLs unangetastet lassen, prüfen, ob die Zahlen gehalten haben, dann in einem zweiten Release die Struktur ändern. Das kostet ein zusätzliches Deployment und liefert Ihnen eine Antwort, wenn etwas schiefgeht.

Traffic verschwindet nicht, weil eine Website umgezogen ist. Er verschwindet, weil einige wenige Verbindungen gerissen sind und niemand nachgesehen hat. In der Praxis wiederholen sich fünf Fehler über Projekte jeder Größe, und vier davon findet ein Crawl an einem Nachmittag.

URLs ohne Ziel. Jede alte Adresse, die 404 zurückgibt, verliert ihre Rankings, ihre Verlinkungen und den Kampagnen-Traffic, den sie hatte. Die Lösung ist unspektakulär: eine Zeile pro alter URL in einer Zuordnungsdatei, geprüft von einem Menschen.

Weiterleitungen, die auf einer Seite zusammenlaufen. Eine Sammelregel, die 400 eingestellte Produktseiten auf die Startseite schickt, vermeidet formal die 404-Fehler und zerstört gleichzeitig die Relevanz. Google behandelt eine Weiterleitung auf eine unpassende Seite ähnlich wie einen Soft 404.

Ketten und Schleifen. Alte URL auf Zwischen-URL auf Ziel-URL verbrennt Crawl-Budget und bremst jeden Besucher, der über einen alten Link kommt. Ein Sprung ist das Ziel, und Ketten prüft man vor dem Launch, nicht danach.

Sperren aus der Testumgebung. Staging-Systeme sind für Crawler absichtlich geschlossen. Die Zeile Disallow: / und das noindex-Tag sind die beiden Teile des Testsystems, die niemals in die Produktion dürfen, und sie sind der Grund für die schwersten Einbrüche.

Interne Links, die weiter auf den alten Baum zeigen. Navigation, Footer, Links im Fließtext und XML-Sitemaps mit alten Pfaden zwingen jeden Crawler durch die Weiterleitungsschicht und verwässern die interne Verlinkung, die Sie über Jahre aufgebaut haben.

Eine Migration ist ihr Risiko wert, wenn die heutige Lösung etwas blockiert, das das Unternehmen braucht, nicht wenn die Website altmodisch wirkt. Drei Auslöser tragen das Projekt allein: Die Plattform kann nicht mehr abbilden, was Sie heute verkaufen, der Betrieb kostet mehr als der Ersatz, oder eine rechtliche Änderung zwingt die Adresse zum Umzug.

Das Plattform-Argument kommt meistens zu spät. In der Praxis sieht es so aus: Ein neuer Seitentyp braucht einen Entwickler statt einer Redakteurin, jede Anbindung hängt an einem Plugin, das beim nächsten Update bricht, die Ladezeit bricht unter Kampagnen-Traffic ein, und eine zweite Sprache wird zu einer zweiten Website. Das sind die Symptome einer Website, die ihrem Fundament entwachsen ist, und kein Design-Budget behebt sie.

Das Kostenargument lässt sich nachrechnen. Addieren Sie Lizenzen, Plugin-Abos, Hosting und die Stunden, die Ihr Team mit Umwegen verbringt. Stellen Sie dem einen Neubau gegenüber, verteilt auf drei Jahre. Sobald die Summe der Umwege größer ist, hat sich die Entscheidung selbst getroffen.

Es gibt auch schlechte Gründe, und die sind teuer: eine neue Marketingleitung mit Vorliebe für einen anderen Stack, eine Agentur, die nur ein System baut, oder ein Design-Wunsch, der sich als Template-Update im bestehenden System umsetzen ließe. Wenn sich nur das Aussehen ändert, brauchen Sie einen Relaunch, und die Vorbereitung eines Redesigns ist der kürzere und günstigere Weg.

Planung ist hier eine Inventur, und sie passiert vor dem Design, vor der Entwicklung und vor der Systemauswahl. Sie beantworten eine Frage: Was existiert heute, und was ist jede Position davon wert? Wer die Inventur überspringt, überlässt die Entscheidung dem Zufall, meistens dem, was sich leicht exportieren ließ.

Beginnen Sie mit vier Exporten. Ein vollständiger Crawl der Live-Website liefert jede URL mit Statuscode, Titel und Canonical. Die Search Console liefert jede Seite, die in zwölf Monaten Impressionen hatte. Die Webanalyse liefert Einstiegsseiten und Conversions pro Seite. Ein Backlink-Export liefert die Seiten, auf die fremde Websites zeigen, und genau diese dürfen niemals 404 werden.

Führen Sie die vier Listen in einer Tabelle zusammen und markieren Sie jede URL mit einer Entscheidung: behalten, zusammenlegen, umbenennen oder einstellen. Eine Seite ohne Traffic, ohne Ranking und ohne Verlinkung darf verschwinden. Eine Seite mit zwei Backlinks und ohne Traffic braucht trotzdem ein Ziel. Diese Tabelle ist gleichzeitig Weiterleitungsplan, Content-Plan und Abnahmeliste.

Derselbe Durchgang beantwortet die Fragen, die Projekte sonst spät überraschen: Wie viele Formulare gibt es und wohin laufen die Einsendungen, welche Systeme schreiben in die Website, wie viele Sprachen werden bedient, welche Seiten tragen Rechtstexte, und wer verwaltet die DNS-Einträge.

Der Weiterleitungsplan ist eine Tabelle mit einer Zeile pro alter URL und genau einem Ziel je Zeile. Er ist das Dokument, das Sie namentlich einfordern, vor dem Launch prüfen und nach Projektende behalten. Wer keinen vorlegen kann, migriert nach Gefühl.

Drei Regeln halten ihn ehrlich. Jedes Ziel muss die inhaltlich nächste Seite sein, keine Kategorie und nicht die Startseite. Jede Weiterleitung ist dauerhaft, also 301, damit die alten Signale weitergereicht werden. Und jede alte URL ohne Entsprechung liefert 410, was den Crawlern sagt, dass die Seite absichtlich weg ist, statt einen Umzug vorzutäuschen.

Prüfen Sie den Plan selbst, in einer Tabelle, auf den Zeilen, die zählen: Ihre 50 stärksten Seiten nach Traffic, Ihre 50 stärksten nach Backlinks und jede Seite, die in einer laufenden Kampagne oder einer E-Mail-Signatur vorkommt. Das ist eine Stunde Ihrer Zeit gegen den Preis, denselben Fehler drei Monate später in der Auswertung zu finden.

Die Sichtbarkeit in der Suche bekommt die Aufmerksamkeit, weil sie öffentlich messbar ist. Teurer sind meistens die Ausfälle, die wochenlang unsichtbar bleiben: ein Kontaktformular, das ins Leere sendet, ein Consent-Banner, das jede Messung blockiert, oder Transaktions-E-Mails, die nicht mehr ankommen, weil die DNS-Einträge mit dem Hosting umgezogen sind.

Consent verdient eine eigene Zeile. Eine neue Website heißt ein neues Cookie-Banner, und nach DSGVO zusammen mit dem TDDDG dürfen nicht notwendige Cookies erst nach der Einwilligung gesetzt werden. Teams, die das Tracking unter Zeitdruck neu aufbauen, liefern häufig ein Banner aus, das entweder alles blockiert, wodurch die Auswertung wie ein Traffic-Einbruch aussieht, oder nichts blockiert, was dann kein Reporting-Problem mehr ist, sondern ein rechtliches.

Die Tabelle unten ist die Kurzfassung des Übergabegesprächs. Jede Zeile braucht eine verantwortliche Person und einen Test auf dem Testsystem, nicht die Zusage, das nach dem Launch zu prüfen.

Der Test vor dem Launch ist ein Vergleich, keine Meinung. Sie crawlen das Testsystem mit demselben Werkzeug wie zuvor die Live-Website und legen beide Bestände nebeneinander. Alles, was im alten Crawl vorkommt und im neuen fehlt, ist entweder eine gewollte Abschaltung mit 410 oder ein Fehler. Eine dritte Möglichkeit gibt es nicht.

Fünf Prüfungen fangen das meiste ab. Seitenzahl und Titel zwischen alt und neu vergleichen. Prüfen, dass jedes Canonical auf die Produktionsdomain zeigt und nicht auf das Testsystem. Prüfen, dass hreflang wechselseitig ist, denn Google verlangt, dass jede Sprachversion alle anderen und sich selbst auflistet. Prüfen, dass auf indexierbaren Seiten kein noindex steht. Und den Weiterleitungsplan als Stapel durchlaufen lassen: alte URLs an den Crawler geben und bestätigen, dass jede mit genau einer 301 auf eine lebende Seite antwortet.

Die Ladezeit gehört in denselben Durchgang. Die Core Web Vitals werden am 75. Perzentil echter Seitenaufrufe bewertet, ein Template kann auf Ihrem Laptop also gut aussehen und im Feld trotzdem durchfallen. Messen Sie die neuen Templates gegen die auf web.dev veröffentlichten Schwellen und behandeln Sie eine Verschlechterung als Launch-Blocker, nicht als spätere Optimierung. Unsere Notizen zur Ladezeit-Optimierung beschreiben, was zuerst zu beheben ist, wenn der Neubau langsamer startet als sein Vorgänger.

Barrierefreiheit gehört seit 2025 in dasselbe Gespräch. Die Richtlinie (EU) 2019/882 gilt seit dem 28. Juni 2025, in Deutschland umgesetzt durch das Barrierefreiheitsstärkungsgesetz, und eine neu gebaute oder wesentlich veränderte Dienstleistung gilt als neu, nicht als Bestand. Wer an Verbraucher verkauft, baut Barrierefreiheit beim Umzug ein, statt sie zu verschieben.

Der Launch-Tag scheitert häufiger an der Reihenfolge als am Code. Die Liste unten setzt voraus, dass die neue Website auf dem Testsystem abgenommen und der Weiterleitungsplan als Stapel geprüft wurde. Dann ist der Tag selbst Mechanik.

1. Redaktionsstopp auf der alten Website, mit angesagtem Beginn für das Team.
2. Letzter Crawl der Live-Website. Das ist die letzte Momentaufnahme zum Vergleichen.
3. DNS-TTL 48 Stunden vorher senken, damit die Umstellung in Minuten statt in einem Tag greift.
4. Neue Website ausrollen, weiterhin für Crawler gesperrt, und die kritischen Wege durchklicken.
5. Sperren entfernen: zuerst robots.txt, dann alle noindex-Tags in den Templates.
6. Weiterleitungen scharf schalten und 20 URLs von Hand prüfen, ausgewählt nach Traffic und Backlinks.
7. Neue XML-Sitemap veröffentlichen und in der Search Console einreichen.
8. Bestätigen, dass Messung, Consent und Formulare in der Produktion aufzeichnen, nicht nur im Test.
9. Serverlogs den Rest des Tages auf 404-Fehler beobachten und beheben, was auftaucht.

Halten Sie die alte Umgebung nach der Umstellung noch eine Weile erreichbar. Nicht live, aber wiederherstellbar. Ein Rollback-Plan, der nur als Satz im Angebot existiert, ist kein Rollback-Plan.

Der erste Monat entscheidet, ob der Umzug ein Projekt war oder ein Vorfall. Suchmaschinen brauchen Zeit, um die neuen Adressen zu crawlen und zu verarbeiten, ein Rückgang in den ersten zwei Wochen ist normal, ein Rückgang, der sich in Woche vier vertieft, ist es nicht. Beobachten Sie Seitengruppen statt der Gesamtzahl, denn ein Durchschnitt verdeckt genau den Bereich, der kaputt ist.

Legen Sie den Rhythmus vor dem Launch fest: täglich in der ersten Woche, zweimal in der zweiten, danach wöchentlich. Geben Sie einer Person die Aufgabe, das zu berichten. Migrationen scheitern selten laut, sie scheitern als langsamer Rückgang, bei dem jeder annimmt, dass jemand anderes hinsieht.

Die Kosten folgen der Art des Umzugs, nicht der Seitenzahl. Ein Hosting-Wechsel ist ein Arbeitstag. Ein Systemwechsel mit unveränderten URLs ist ein Neubau der Templates plus ein Datenexport. Ein Domainwechsel mit neuer URL-Struktur bringt Zuordnung, Tests und Beobachtungsfenster obendrauf.

Veröffentlichte Preise geben einen Anhaltspunkt. Unsere eigenen Preise beginnen bei €1.500 für eine Landingpage mit zwei bis drei Tagen Lieferzeit, €4.500 für eine Unternehmenswebsite mit 10 bis 30 Seiten und ein bis drei Wochen Lieferzeit sowie €9.000 für ein Portal ab 50 Seiten mit einem bis drei Monaten. Der Umzug einer bestehenden Website derselben Größe liegt im selben Rahmen, mit Zuordnung und Prüfung obendrauf, weil der Neubau derselbe ist und die Inventur zusätzlich anfällt. Stand August 2026.

Überraschend ist selten der Bau, sondern sind die beiden Enden. Inventur und Zuordnung brauchen bei einer mittelgroßen Website ein bis drei Wochen Kalenderzeit, weil sie Zuarbeit aus Marketing, Vertrieb und Recht benötigen und nicht nur Entwicklerstunden. Das Beobachtungsfenster nach dem Launch läuft vier bis acht Wochen und gehört als bezahlte Leistung in den Vertrag, nicht in die Kulanz.

Kalkulieren Sie separat, was regelmäßig vergessen wird: das Consent-Setup neu aufbauen, jedes Formular und jede Anbindung erneut testen, Kampagnen-URLs in Anzeigen- und E-Mail-Werkzeugen aktualisieren und die internen Links in alten Beiträgen korrigieren, die auf umbenannte Seiten zeigen.

Ein Migrationsvertrag, der nur zusagt, dass die neue Website den Entwürfen entspricht, lässt alles weg, was schiefgehen kann. Abnahmekriterien sollten von jemandem prüfbar sein, der nicht entwickelt, also als Prüfungen mit Ergebnis bestanden oder nicht bestanden formuliert werden.

Fordern Sie diese sieben Punkte schriftlich. Einen Weiterleitungsplan über alle URLs, die in zwölf Monaten Traffic oder einen Backlink hatten, zur Prüfung vor dem Launch. Die Bestätigung, dass alte URLs mit genau einer 301 auf eine passende Seite antworten und eingestellte Seiten 410 liefern. Den Erhalt von Titeln, Beschreibungen, Canonicals und hreflang oder eine dokumentierte Begründung für Änderungen. Einen Testplan für das Tracking mit jedem Ereignis, Ziel und Formular, das am Launch-Tag funktionieren muss. Eine Aussage zu den Pflichten aus dem Barrierefreiheitsstärkungsgesetz, soweit die Website in den Anwendungsbereich fällt. Im Feld gemessene Ladezeit-Ziele für die wichtigsten Templates. Und ein benanntes Beobachtungsfenster von vier bis acht Wochen mit Reaktionszeiten für die dort gefundenen Mängel.

Ergänzen Sie eine Klausel, die nichts kostet und Streit erspart: Weiterleitungsplan, Crawl-Exporte und Tracking-Plan werden bei Projektabschluss als Dateien übergeben. Das sind Ihre Unterlagen. Die nächste Agentur wird danach fragen, und Sie ebenfalls.

Das ist die Kurzfassung von allem oben, in der Reihenfolge der Arbeit. Übernehmen Sie sie in Ihr Projektwerkzeug und geben Sie jeder Zeile eine verantwortliche Person und ein Datum.

Vor dem Bau

• Live-Website crawlen und jede URL mit Status, Titel und Canonical exportieren.
• Zwölf Monate Search Console, Einstiegsseiten aus der Webanalyse und verweisende Domains exportieren.
• Jede URL markieren: behalten, zusammenlegen, umbenennen oder einstellen.
• Formulare, Anbindungen, Tracking-Tags, Feeds und Rechtstexte mit Verantwortlichen listen.
• Entscheiden, ob System, Struktur und Domain in einem Release wechseln oder in mehreren.

Vor dem Launch

• Weiterleitungsplan von Hand geprüft für die 50 stärksten Seiten nach Traffic und nach Backlinks.
• Testsystem gecrawlt und mit dem Live-Bestand verglichen.
• Canonicals zeigen auf die Produktion, hreflang ist wechselseitig, kein verirrtes noindex.
• Formulare, Consent-Wege und Analyse-Ereignisse auf dem Testsystem geprüft.
• Core Web Vitals der neuen Templates gemessen, Verschlechterungen sind Blocker.
• Rollback-Plan schriftlich, DNS-TTL gesenkt.

Launch-Tag und danach

• Sperre entfernt, Weiterleitungen aktiv, Sitemap eingereicht.
• Zwanzig Weiterleitungen von Hand geprüft, Serverlogs auf 404 beobachtet.
• Anzeigen- und Newsletter-Ziele auf die neuen Adressen umgestellt.
• Beobachtungsrhythmus vereinbart: eine Woche täglich, danach einen Monat wöchentlich.
• Weiterleitungen mindestens ein Jahr aktiv lassen und den Plan mit den Projektunterlagen archivieren.

Diesen Fall können wir von innen beschreiben, weil es unsere Website ist. Vezert läuft auf Englisch, Deutsch, Spanisch, Französisch und Niederländisch, und jede Sprache hat einen eigenen URL-Slug statt einer übersetzten Seite unter einer englischen Adresse. Bei jeder Slug-Änderung bekommt die alte Adresse eine dauerhafte Weiterleitung, und die Datei, die sie sammelt, enthält aktuell 329 davon.

Zwei Entscheidungen haben die Arbeit getragen. Jeder Beitrag trägt eine feste Kennung, die sich nie ändert, sodass hreflang aus dieser Kennung erzeugt wird und nicht aus einem Dateinamen. Eine Umbenennung in einer Sprache kann die Verbindung zu den anderen vier deshalb nicht kappen. Und die Weiterleitung entsteht automatisch in demselben Skript, das die Datei umbenennt, wodurch der Schritt entfällt, den Menschen vergessen.

Die Lehre daraus gilt für jede Migration: Die Weiterleitung ist Teil der Umbenennung, keine Aufgabe danach. Sind die beiden getrennt, benennt irgendwann jemand am Freitag eine Seite um, und die Weiterleitung kommt am Montag, falls sie kommt. Wer beim Umzug zusätzlich Sprachen aufnimmt, findet in unserem Leitfaden zu mehrsprachigen Websites die URL-Entscheidungen, die sich später schwer zurückdrehen lassen, und in der Website-Struktur den Seitenbaum, dem der Weiterleitungsplan folgen muss.