Website-Redesign und Migration ohne SEO-Verlust: ein praktischer Plan für Unternehmen

Website-Redesign ohne SEO-Verlust erfordert eine schrittweise Vorbereitung und Kontrolle. Stellen Sie sich folgende Situation vor: Ein Unternehmen bereitet mehrere Monate lang eine neue Website vor, stimmt das Design ab, überträgt den Katalog und startet die aktualisierte Version. Optisch wirkt alles modern, die Seiten öffnen sich, Bestellungen gehen ein. Doch nach einigen Tagen beginnt der organische Traffic zu sinken. Ein Teil der alten Adressen liefert einen 404-Fehler, Suchmaschinen sehen Duplikate, und Kategorieseiten, die jahrelang Kunden gebracht haben, verschwinden aus den Suchergebnissen.

Das Problem ist, dass ein Redesign oft nur als Arbeit an der Oberfläche verstanden wird. Tatsächlich ist es für ein Unternehmen eine Veränderung eines digitalen Produkts, in dem Design, Struktur, CMS, Katalog, Analytics und SEO miteinander verbunden sind. Wird ein Element ohne Prüfung der anderen geändert, kann die neue Website zwar schöner sein, aber ihre aufgebaute Sichtbarkeit in der Suche und einen Teil des Umsatzes verlieren.

Website-Redesign ohne SEO-Verlust beginnt nicht mit Layouts und nicht am Tag des Releases. Es beginnt mit einer Bestandsaufnahme der bestehenden Website, einer URL-Migrationskarte und einem klaren Kontrollplan. Sehen wir uns an, wie man eine Migration so vorbereitet und durchführt, dass wichtige Seiten, Daten und die Steuerbarkeit des Geschäfts erhalten bleiben.

Website-Redesign ohne SEO-Verlust und Migration: der Unterschied

Ein Redesign verändert das Erscheinungsbild und die Art, wie Nutzer mit der Website interagieren. Eine Migration verändert die technische Umgebung: CMS, Domain, URL-Struktur, Server, Datenschema oder die Art, wie Seiten erzeugt werden. Diese Prozesse können getrennt ablaufen, werden in realen Projekten aber oft kombiniert.

Ein Unternehmen kann zum Beispiel die Oberfläche erneuern, ohne die Seitenadressen zu ändern. In diesem Fall betreffen die wichtigsten SEO-Risiken Inhalte, interne Links, Rendering und Geschwindigkeit. Ändern sich dagegen gleichzeitig CMS und URLs, kommen Risiken durch fehlerhafte Weiterleitungen, Indexierungsverlust, doppelte Seiten und Brüche in den Analysedaten hinzu.

Google empfiehlt, nach Möglichkeit nicht mehrere große Änderungen gleichzeitig vorzunehmen. Wechselt ein Unternehmen zugleich auf eine neue Domain, ein neues CMS und ein neues Design, lässt sich jedes Problem nach dem Start schwerer eingrenzen. Deshalb sollten große Änderungen in kontrollierte Etappen aufgeteilt oder zumindest klar dokumentiert werden.

Wann ein Redesign wirklich nötig ist

Es gibt keine allgemeine Regel, nach der eine Website alle zwei oder drei Jahre erneuert werden muss. Gleichzeitig kann ein veraltetes Erscheinungsbild allein schon ein gewichtiger Grund sein, über ein Redesign nachzudenken — besonders wenn die Website optisch hinter der Konkurrenz zurückbleibt, kein Vertrauen weckt oder nicht mehr dem entspricht, wie sich das Unternehmen präsentieren möchte. Die endgültige Entscheidung sollte durch Daten zum Nutzerverhalten und Geschäftskennzahlen gestützt werden.

Signale für ein Redesign können sein:

• sinkende Conversion auf wichtigen Seiten;
• hohe Absprungrate auf Mobilgeräten;
• ein komplizierter Weg vom Katalog bis zum Checkout;
• langsames Laden und Probleme mit den Core Web Vitals;
• CMS-Einschränkungen, wegen derer neue Funktionen teure Anpassungen erfordern;
• Schwierigkeiten bei der Verwaltung von Katalog, Sprachversionen oder Inhalten;
• angesammelte technische Fehler und inkompatible Module;
• Änderungen des Geschäftsmodells, des Sortiments oder des Verkaufsprozesses;
• keine Möglichkeit, CRM, ERP, Versand, Zahlung oder Analytics korrekt zu integrieren.

Vor Projektbeginn empfiehlt sich ein SEO-Audit der Website sowie eine Prüfung der Analytics für Oberflächenänderungen. So lassen sich echte Probleme von subjektiven Wünschen trennen und Basiskennzahlen festhalten, mit denen die neue Version verglichen wird.

Was vor Beginn des Redesigns gesammelt werden muss

Die erste Phase ist die Bestandsaufnahme. Das Team muss verstehen, welche Seiten existieren, wie sie Traffic erhalten, welche externen Links sie haben und welche Rolle sie im Verkauf spielen.

In das Register vor der Migration gehören:

• alle erreichbaren URLs der Website;
• der Typ jeder Seite: Startseite, Kategorie, Produkt, Artikel, Filter, Serviceseite;
• HTTP-Status;
• Canonical;
• Indexierungsstatus;
• Title, Description und H1;
• organische Impressionen und Klicks;
• Sitzungen, Conversions und Umsatz;
• interne und wichtige externe Links;
• Sprachversion und hreflang;
• Vorhandensein strukturierter Daten;
• die künftige Adresse nach der Migration.

Gesondert müssen Seiten erfasst werden, die wenig Traffic haben, aber für das Geschäft kritisch sind: Versand-, Zahlungs-, Garantie- und Rückgabebedingungen, rechtliche Dokumente, Partnerseiten und Landingpages von Werbekampagnen.

Die URL-Karte als Grundlage einer sicheren Migration

Eine URL-Karte zeigt, wohin jede alte Adresse nach dem Start führen soll. Sie darf nicht automatisch nur anhand ähnlicher Wörter erstellt werden. Für jede wichtige Seite muss eine relevante neue Entsprechung gewählt werden.

Eine Arbeitstabelle kann folgende Spalten enthalten:

Man sollte nicht alle gelöschten Seiten auf die Startseite umleiten. Solche Weiterleitungen helfen dem Nutzer nicht und können von der Suchmaschine als Soft 404 gewertet werden. Gibt es keine gleichwertige Entsprechung, ist eine korrekte 404- oder 410-Antwort oft besser als ein formaler 301 auf eine irrelevante Seite.

Für dauerhafte Umzüge werden serverseitige 301- oder 308-Weiterleitungen verwendet. Google weist darauf hin, dass dauerhafte Weiterleitungen Seitensignale übertragen, die Migration aber nicht sofort erfolgt. Die Suchmaschine muss alte und neue Adressen erneut crawlen, daher sind vorübergehende Sichtbarkeitsschwankungen auch bei korrekter Umsetzung möglich.

Wie man Staging vorbereitet und von der Indexierung fernhält

Die neue Version der Website muss in einer separaten Umgebung getestet werden. Staging ermöglicht es, Katalog, Integrationen, Weiterleitungen, Formulare und Analytics zu prüfen, bevor Kunden die Änderungen sehen.

Die Testumgebung darf nicht in die Suche gelangen. Am zuverlässigsten ist es, den Zugang per Authentifizierung oder IP zu beschränken. Eine robots.txt allein reicht zum Schutz einer vertraulichen Umgebung nicht aus, und ein nach dem Release versehentlich auf der Live-Website verbliebenes noindex kann die Indexierung wichtiger Seiten blockieren.

Auf dem Staging werden geprüft:

• alle Seitenvorlagen und die Responsivität;
• Statuscodes und Weiterleitungslogik;
• Canonical, Robots-Meta und hreflang;
• XML-Sitemap;
• interne Links und Navigation;
• strukturierte Daten;
• Verfügbarkeit der Inhalte ohne JavaScript-Fehler;
• Geschwindigkeit und Core Web Vitals;
• Formulare, Suche, Warenkorb, Zahlung und Versand;
• Analytics-Events und Werbepixel;
• E-Mails, Benachrichtigungen und CRM/ERP-Integrationen.

Eine eigene Checkliste für Onlineshops

Eine E-Commerce-Migration ist komplexer als der Umzug einer Unternehmenswebsite. Hier kann ein einziger technischer Fehler gleichzeitig SEO, Lagerbestände, Zahlungen und die Auftragsabwicklung beeinträchtigen.

Kategorien und Katalog

Prüfen Sie, ob die Logik von Kategorien, Unterkategorien und Produkten erhalten geblieben ist. Wichtige Seiten müssen über normale HTML-Links erreichbar sein, nicht nur über die Suche oder JavaScript-Filter. Lässt sich ein Produkt nur über eine Eingabe in der internen Suche finden, entdeckt der Suchroboter es möglicherweise nicht.

Filter und facettierte Navigation

Filter können Tausende URL-Kombinationen erzeugen. Vor dem Start muss festgelegt werden, welche Filterseiten indexiert werden sollen und welche nicht. Canonical, interne Links, Sitemap und Indexierungsregeln müssen abgestimmt zusammenwirken.

Produkte und Varianten

Bei Produkten müssen Namen, Beschreibungen, Preise, Verfügbarkeit, Bilder, Bewertungen, strukturierte Daten und Varianten geprüft werden. Hat eine Farbe oder Größe eine eigene Adresse, muss eine kanonische Logik festgelegt werden, ohne widersprüchliche Signale zu erzeugen.

Warenkorb und Checkout

Führen Sie Testbestellungen für jedes Szenario durch: Gast und registrierter Nutzer, Online-Zahlung und Nachnahme, Lieferung an eine Abholstelle und an eine Adresse, Gutscheincode, Rückgabe, Zahlungsfehler. Prüfen Sie, ob sich Status korrekt ändern, Bestände reserviert werden und Daten im CRM oder Buchhaltungssystem ankommen.

Analytics

Nach einem Redesign können sich alte Selektoren, Buttons und Pfade ändern, deshalb müssen die GA4-Events erneut geprüft werden. Ein minimales E-Commerce-Set umfasst in der Regel Produktansicht, In-den-Warenkorb, Checkout-Beginn, Versand- und Zahlungsdaten, Kauf und Rückerstattung.

Was am Tag des Starts zu prüfen ist

Am Release-Tag sollte das Team nach einer Checkliste arbeiten, statt zu improvisieren. Wichtig sind Verantwortliche für Infrastruktur, SEO, Analytics, Integrationen und Geschäftsprozesse.

Kritische Reihenfolge der Prüfung:

1. Sicherstellen, dass die veröffentlichte Website erreichbar ist und korrekte Statuscodes liefert.
2. Vorübergehende Indexierungssperren nur von den benötigten Seiten entfernen.
3. 301/308-Weiterleitungen aktivieren und testen.
4. Canonical, hreflang, robots.txt und Sitemap prüfen.
5. Die wichtigsten Nutzerszenarien auf Mobilgerät und Desktop durchgehen.
6. Eine Testbestellung mit der echten Integration durchführen.
7. Sicherstellen, dass Analytics Events ohne Duplikate erhält.
8. Die Fehlerprotokolle von Server, CRM und Zahlungssystem prüfen.
9. Die neue Sitemap in der Search Console einreichen.
10. Startzeitpunkt und alle Änderungen für die weitere Analyse festhalten.

Ändert sich die Domain oder Subdomain, kann in der Search Console das Tool zur Adressänderung erforderlich sein. Für einen Wechsel zwischen Pfaden innerhalb derselben Domain wird es nicht verwendet.

Kontrollplan für 7, 30 und 90 Tage

Ein erfolgreicher Start endet nicht mit der Meldung „die Website läuft“. Die ersten Wochen nach der Migration dienen dazu zu beobachten, wie Nutzer und Suchmaschinen mit der neuen Version interagieren.

Die ersten 7 Tage

• täglich 404-, 5xx-Fehler und Weiterleitungsketten prüfen;
• Käufe, Formulare und Integrationen kontrollieren;
• die Indexierung wichtiger Seiten überprüfen;
• Traffic und Conversions mit dem Basiszeitraum vergleichen;
• Fehler in strukturierten Daten prüfen;
• Geschwindigkeit und Stabilität des Servers überwachen.

Die ersten 30 Tage

• Veränderungen bei Impressionen, Klicks und Einstiegsseiten analysieren;
• prüfen, ob alte URLs in der Suche durch neue ersetzt wurden;
• interne Links korrigieren, die über eine Weiterleitung führen;
• neue 404-Fehler aus externen Quellen prüfen;
• mobile und Desktop-Conversion vergleichen;
• prüfen, ob Kategorien oder Produkte massenhaft aus dem Index fallen.

Bis zu 90 Tage

• die Stabilisierung des organischen Traffics bewerten;
• Seiten ermitteln, die zusätzliche Inhalte oder interne Verlinkung benötigen;
• langfristige Veränderungen der Core Web Vitals prüfen;
• Umsatz, durchschnittlichen Bestellwert und Funnel analysieren;
• vorübergehende technische Lösungen abschließen und die Dokumentation aktualisieren.

Dauerhafte Weiterleitungen sollten mindestens ein Jahr bestehen bleiben, für Nutzer ist es oft sinnvoll, sie länger beizubehalten. Interne Links sollten dagegen sofort aktualisiert werden, um unnötige Umwege und Last zu vermeiden.

Wann ein Rollback nötig ist

Vor dem Start muss nicht nur der Release-Plan, sondern auch das Kriterium für die Rückkehr zur vorherigen Version festgelegt werden. Ein Rollback kann gerechtfertigt sein, wenn der Checkout nicht funktioniert, die Bestandssynchronisation gestört ist, massenhaft 5xx-Fehler auftreten, kritische Daten verloren gehen oder das System der Last nicht standhält.

Eine kleine Schwankung der Rankings ist an sich kein Grund, sofort die alte Website zurückzuholen. Die Suchmaschine braucht Zeit für das erneute Crawlen. Technische Nichterreichbarkeit, Indexierungsfehler oder nicht funktionierende Geschäftsprozesse erfordern dagegen eine schnelle Reaktion.

Wie man ein Redesign kontrolliert durchführt

Ein Website-Redesign ohne SEO-Verlust ist kein Versprechen von null Schwankungen. Es ist ein Prozess, in dem Risiken bekannt, Änderungen dokumentiert sind und das Team ein Problem schnell finden und beheben kann.

Bei GL.ua (Glyanets) betrachten wir ein Redesign als gemeinsame Arbeit von UX, Entwicklung, SEO, Analytics und Business. Vor Beginn der Website-Entwicklung ist es wichtig, Daten zu sammeln, Ziele zu definieren, eine URL-Karte vorzubereiten und Abnahmekriterien abzustimmen. Dann zerstört die neue Oberfläche nicht das aufgebaute digitale Kapital, sondern schafft die Grundlage für die weitere Entwicklung.

Wenn Ihre Website eine Erneuerung braucht, beginnen Sie mit einem technischen und einem SEO-Audit. Es zeigt, was erhalten bleiben muss, was vereinfacht werden kann und welche Einschränkungen wirklich eine neue Architektur oder ein neues CMS erfordern.