Website Umzug: wie Sie Ihre Website umziehen, ohne Traffic zu verlieren

Ein Website Umzug ist die technische Übertragung einer Webpräsenz auf eine neue Plattform, Domain, Infrastruktur oder URL-Architektur. Eine strukturierte 301-Weiterleitungszuordnung schützt den organischen Traffic, indem sie alte URLs eins zu eins auf neue Zielseiten umleitet, bestehende Rankingsignale überträgt und kritische 404-Fehler für Suchmaschinen verhindert.

Genau in der Lücke zwischen alten Adressen und neuen Zielen entsteht der Schaden. Laut Google Search Central sollen die Weiterleitungen bei einem Umzug mit URL-Änderungen mindestens ein Jahr aktiv bleiben, während sich die Suchergebnisse neu einpendeln. Jeder übersehene Punkt kostet bereits bezahlten Traffic: eine vergessene URL, ein versehentlich übernommenes noindex aus der Staging-Umgebung oder fehlende Tracking-Tags.

Dieser Leitfaden richtet sich an Projektverantwortliche, die den Relaunch freigeben. Er behandelt die vier Migrationsarten, die Inventur vorab, den Weiterleitungsplan, Tests vor dem Go-live, die Reihenfolge am Launch-Tag, das Monitoring im ersten Monat und was in unsere Dienstleistungen und Verträge gehört.

Website Umzug ist ein Sammelbegriff 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.

Der häufigste Anlass ist gleichzeitig der harmloseste: Sie ziehen zu einem anderen Hoster um, und Domain, URLs und Inhalte bleiben unverändert. Hier entscheidet die Reihenfolge. Erst Dateien und Datenbank auf den neuen Server spiegeln, dann die Website dort unter einer Testadresse prüfen, dann Nameserver oder A-Record umstellen und erst danach den alten Vertrag kündigen. Wer die Domain gleich mitnimmt, braucht den AuthCode vom bisherigen Anbieter, und die E-Mail-Postfächer ziehen getrennt von der Website um, weil sie an denselben DNS-Einträgen hängen.

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.

Ein Umzug lohnt sein Risiko, wenn die bestehende Lösung ein geschäftliches Ziel blockiert, nicht bloß weil die Website in die Jahre gekommen ist. Drei Gründe rechtfertigen das Vorhaben: Die Plattform trägt Ihr heutiges Angebot technisch nicht mehr, die laufenden Wartungskosten übersteigen die Kosten eines Neubaus, oder ein Markenwechsel erzwingt eine neue Domainadresse.

Der Plattform-Engpass wird meist zu spät erkannt. In der Praxis zeigt er sich deutlich: Das Anlegen eines Seitentyps erfordert Entwickler statt Redakteure, Schnittstellen brechen bei System-Updates, Ladezeiten knicken unter Kampagnen-Traffic ein und zusätzliche Sprachversionen erfordern eigene Subdomains. Diese strukturellen Probleme lassen sich durch rein optische Anpassungen nicht lösen.

Der Kostenvergleich ist eindeutig. Addieren Sie Lizenzgebühren, Plugin-Abonnements, Hosting und die Arbeitsstunden Ihres Teams für technische Notlösungen. Wenn die Summe dieser Hilfskonstruktionen die Investition in ein modernes System über drei Jahre übersteigt, ist der Umzug wirtschaftlich geboten.

Vermeiden Sie kosmetische Motive: Ein neuer Marketingleiter bevorzugt ein anderes CMS, oder eine Agentur beherrscht nur ihr eigenes System. Wenn es allein um die Optik geht, reicht ein Redesign; die Vorbereitung eines Redesigns ist der kürzere Weg. Wenn Ihr Projekt ein neues Design mit strukturellen URL-Änderungen verbindet, liefert unsere SEO-Relaunch-Checkliste die technischen Prüfpunkte für den Go-live.

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 in der Praxis deutlich häufiger an einer unklaren Reihenfolge als an fehlerhaftem Programmcode. Die nachfolgende Schrittfolge setzt voraus, dass die neue Website auf der Staging-Umgebung vollständig freigegeben und der Weiterleitungsplan als Gesamtheit validiert wurde, sodass der eigentliche Cutover diszipliniert und berechenbar abläuft.

1. Content-Freeze auf der alten Website ausrufen und alle Beteiligten über den Beginn informieren.
2. Einen letzten vollständigen Crawl der produktiven Website als Vergleichsbasis sichern.
3. DNS-TTL 48 Stunden vorab auf 300 Sekunden senken, damit Änderungen weltweit in wenigen Minuten greifen.
4. Neue Website auf dem Produktivserver bereitstellen und Staging-Zugangsbeschränkungen entfernen.
5. 301-Weiterleitungsregeln auf Serverebene aktivieren und DNS-A-Einträge umschalten.
6. SSL-Zertifikate prüfen und die wichtigsten 20 Konversionsseiten manuell im Browser testen.
7. Robots.txt-Sperren aufheben und die neue XML-Sitemap in der Google Search Console einreichen.
8. Bei Domainwechseln den Adresswechsel-Antrag in der Search Console absenden.
9. Server-Zugriffslogs in Echtzeit auf unerwartete 404-Fehler und Crawling-Auffälligkeiten prüfen.

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 einer Migration folgen der technischen Komplexität der Umstellung und nicht der reinen Seitenzahl. Ein reiner Hosterwechsel beansprucht wenige Tage. Ein CMS-Wechsel mit unveränderten URLs umfasst den Neubau der Vorlagen plus Datenexport. Ein Domainwechsel mit neuer URL-Architektur erfordert zusätzlich die vollständige Weiterleitungszuordnung und mehrwöchige Überwachung.

Veröffentlichte Preise geben einen verlässlichen Anhaltspunkt. Unsere Dienstleistungen und festen 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.

Die Dauer wird vor allem durch Vorbereitung und Nachbereitung bestimmt. Die Inventur und der Weiterleitungsplan beanspruchen ein bis drei Wochen unter Einbindung von Marketing, Vertrieb und Recht. Das Überwachungsfenster nach dem Go-live läuft vier bis acht Wochen und gehört als fester Leistungsbestandteil in den Vertrag.

Planen Sie Budget für oft unterschätzte Aufgaben ein: das Überarbeiten des Cookie-Consent-Banners, das Testen aller Kontaktformulare, die Aktualisierung von Ziel-URLs in Werbekonten sowie das Anpassen interner Links in Archivbeiträgen.

Ein Migrationsvertrag, der lediglich verspricht, dass die neue Website den Gestaltungsentwürfen entspricht, klammert die entscheidenden technischen Risiken aus. Abnahmekriterien müssen so formuliert sein, dass sie von Projektverantwortlichen ohne Programmierkenntnisse eindeutig mit bestanden oder nicht bestanden geprüft werden können.

Vereinbaren Sie sieben verbindliche Lieferbestandteile: Einen vollständigen Weiterleitungsplan für alle URLs mit Traffic oder Backlinks der letzten zwölf Monate, verifizierte 301-Weiterleitungen in einem Hop mit 410-Status für entfernte Seiten, den Erhalt von Meta-Tags, Canonical-Links und Sprachauszeichnungen, einen Testplan für Tracking und Formulare, den Nachweis der Barrierefreiheit nach dem Barrierefreiheitsstärkungsgesetz, definierte Core-Web-Vitals-Grenzwerte sowie ein vier- bis achtwöchiges Betreuungsfenster nach dem Launch.

Halten Sie zudem vertraglich fest, dass alle Crawl-Exporte, Mapping-Tabellen und Tracking-Dokumentationen mit Projektabschluss vollständig an Sie übergeben werden.

Diese Checkliste fasst den gesamten Migrationsablauf in chronologischer Reihenfolge zusammen. Übertragen Sie diese Prüfpunkte direkt in Ihr Projektmanagement-Werkzeug, und weisen Sie jedem Punkt eine eindeutige verantwortliche Person, klare Abnahmekriterien und einen festen Erledigungstermin zu.

Vor der Umsetzung

• Produktive Website crawlen und alle URLs mit HTTP-Status, Seitentitel und Canonical-Tag exportieren.
• Zwölf Monate Search Console-Daten, Analytics-Einstiegsseiten und externe Backlink-Ziele sichern.
• Jeder URL eine Entscheidung zuweisen: behalten, zusammenführen, umbenennen oder entfernen.
• Formulare, Drittanbieter-Tools, Tracking-Tags und Pflichtseiten inventarisieren.
• Rollout-Architektur festlegen (Einzelschritt versus gestaffelte Bereitstellung).

Vor dem Launch

• Weiterleitungsplan für die wichtigsten 50 Traffic- und Backlinkseiten manuell prüfen.
• Staging-Umgebung crawlen und Abweichungen zum alten Datenbestand bereinigen.
• Sicherstellen, dass Canonicals auf Produktion zeigen und hreflang wechselseitig gültig ist.
• Formularversand, Consent-Mechanik und Conversion-Events auf Staging testen.
• Core Web Vitals an den Richtwerten von web.dev messen und Mängel beheben.
• Rollback-Plan dokumentieren und DNS-TTL absenken.

Am Launch-Tag und danach

• Noindex-Blockaden entfernen, 301-Engine aktivieren und XML-Sitemap einreichen.
• Wichtigste Ziel-URLs stichprobenartig testen und Serverlogs auf 404-Meldungen prüfen.
• Ziel-Adressen in Werbekampagnen und E-Mail-Vorlagen aktualisieren.
• Kontrollrhythmus einhalten: Täglich in Woche eins, wöchentlich für 30 Tage.
• 301-Weiterleitungen mindestens zwölf Monate aktiv halten und Dokumente 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.