E-Commerce-Migration: SEO-Checkliste für einen kontrollierten Umzug

1. Umfang und Baseline festhalten

Google empfiehlt für Site Moves eine sorgfältige Vorbereitung, ein URL-Mapping, serverseitige permanente Redirects und anschließendes Monitoring. Ändern Sie nach Möglichkeit nicht gleichzeitig Domain, CMS, Informationsarchitektur, Inhalte und Design. Jede zusätzliche Variable erschwert Diagnose und Rollback.

• Schritt 1: Migrationsumfang, unvermeidbare Änderungen, Verantwortliche und Cutover-Fenster schriftlich festlegen.
• Schritt 2: Eine Baseline für organische Klicks, Impressionen, indexierte URLs, Landingpages, Rankings, Umsatz, Conversion, Crawling-Fehler und Core Web Vitals exportieren.

2. Vollständiges Inventar aller URLs und Dateien

Die Sitemap ist nur eine von mehreren Quellen. Ergänzen Sie CMS- und Produktdaten, Landingpages aus Analytics, Seiten aus der Search Console, Serverlogs und Backlink-Ziele sowie Bilder, PDFs und andere indexierbare Dateien. Saisonale URLs tauchen in kurzen Auswertungszeiträumen unter Umständen gar nicht auf.

• Schritt 3: Alle bekannten HTML-, Bild-, PDF-, Feed- und Sprach-URLs aus Sitemap, CMS, Analytics, Search Console, Logs und Backlinkdaten zusammenführen.
• Schritt 4: Jede URL nach Seitentyp, Indexierungsstatus, Traffic, Links, Umsatzbeitrag, Sprache und Zielaktion einordnen.

3. URL-Mapping ohne Sammelweiterleitungen

Ordnen Sie jede wertvolle alte URL dem inhaltlich nächstliegenden neuen Ziel zu. Viele alte Produkte pauschal auf die Startseite oder eine breite Kategorie umzuleiten, ist keine echte Entsprechung. Für entfernte Inhalte ohne sinnvollen Ersatz liefern Sie 404 oder 410 aus.

• Schritt 5: Eine zeilenweise Zuordnung von alter zu neuer URL anlegen, jeweils mit der Aktion 1:1, Zusammenführen, Entfernen oder unverändert.
• Schritt 6: Serverseitige permanente Redirects planen, Ketten und Schleifen beseitigen und Query-Parameter bewusst behandeln.

4. Gleichwertige Inhalte und interne Signale

Gleichwertige URLs reichen nicht, wenn der Inhalt dahinter nicht mehr derselbe ist. Vergleichen Sie für priorisierte Seiten Hauptinhalt, Title, Überschriften, Produktattribute, Varianten, Bilder, Bewertungen, interne Links und indexierbare Texte. Bewusste Verbesserungen sind erlaubt, sollten aber klar von versehentlichen Verlusten unterschieden werden.

• Schritt 7: Die inhaltliche Gleichwertigkeit je Template und priorisierter URL automatisiert und redaktionell prüfen.
• Schritt 8: Interne Links, Navigation, Breadcrumbs, hreflang und Canonicals vollständig auf die neuen finalen URLs umstellen.
• Interne Links sollten nicht über einen Redirect laufen.
• Canonical und hreflang müssen zueinander passen und als absolute URLs auflösbar sein.
• Für ausverkaufte oder eingestellte Produkte gilt eine dokumentierte Regel, wie lange und in welcher Form die Seiten erhalten bleiben.

5. Rendering und HTTP-Semantik

Google verarbeitet JavaScript in den Phasen Crawling, Rendering und Indexierung. Bei Kategorie-, Produkt- und Contentseiten muss das initial ausgelieferte oder serverseitig gerenderte HTML die indexierbaren Hauptinhalte und Links zuverlässig enthalten. Ein leeres App-Shell-Dokument schafft zusätzliche Abhängigkeiten und erschwert die Fehlersuche.

• Schritt 9: Gerendertes und rohes HTML auf Title, Canonical, Robots, hreflang, Hauptinhalt, Links und strukturierte Daten vergleichen.
• Schritt 10: Statuscodes und Fehlerseiten prüfen: echte 200, 3xx, 404/410 und 5xx statt Soft-404 oder durchgehend 200.

6. Facetten, Sortierung und Pagination steuern

Facetten können nahezu unbegrenzt viele URL-Kombinationen erzeugen und Crawling-Ressourcen binden. Entscheiden Sie je Filterklasse, ob sie eine eigene Suchintention bedient. Indexierbare Facetten brauchen stabilen Inhalt, interne Verlinkung und ein selbstreferenzierendes Canonical. Reine Sortier- und Session-Parameter brauchen das in der Regel nicht.

Google folgt Links in href-Attributen. Eine Oberfläche mit „Mehr laden“ oder Infinite Scroll braucht deshalb crawlbare, paginierte URLs, die sich auch direkt aufrufen lassen. Jede Seite der Folge erhält grundsätzlich eine eigene URL und eine passende Canonical-Angabe.

• Schritt 11: Eine Facettenmatrix mit den Angaben indexierbar, crawlbar, Canonical, intern verlinkt und Parameterregel abstimmen und freigeben.
• Schritt 12: Pagination, „Mehr laden“ und Infinite Scroll mit crawlbaren URLs, echten Links und direktem Seitenaufruf testen.

7. Strukturierte Daten und Produktfeeds

Strukturierte Daten müssen den sichtbaren Seiteninhalt korrekt wiedergeben. Prüfen Sie das Product-Markup und gegebenenfalls das Merchant-Listing-Markup auf Preis, Währung, Verfügbarkeit, Varianten, Bewertungen und Richtlinien. Ein valides Schema ist noch nicht automatisch inhaltlich richtig.

• Schritt 13: Strukturierte Daten je Template validieren und die Werte mit dem sichtbaren Inhalt und den Commerce-Daten abgleichen.
• Schritt 14: Merchant Center, Produktfeeds, Bild-URLs und andere externe Zielsysteme auf die neuen URLs und konsistente Produkt-IDs umstellen.

8. Crawling und Indexierung steuern

Den Schutz des Staging-Systems und die Steuerung in der Produktion sollten Sie getrennt betrachten. Staging gehört hinter eine Authentifizierung oder einen Netzwerkschutz. Vor dem Cutover müssen robots.txt, Meta Robots, X-Robots-Tag, Canonicals und Sitemaps für die Produktion fertig vorliegen.

• Schritt 15: robots.txt, noindex, X-Robots-Tag, Canonicals und hreflang anhand einer freigegebenen URL-Stichprobe testen.
• Schritt 16: Neue XML-Sitemaps nur mit kanonischen URLs mit Status 200 erzeugen, nach Typ aufteilen und die alten Sitemaps für das Monitoring aufbewahren.

9. Test-Gate vor dem Launch

Der Test muss Daten, Templates und Infrastruktur abdecken. Eine einzelne, sorgfältig ausgewählte URL reicht dafür nicht. Ziehen Sie Stichproben je Seitentyp, Trafficklasse, Sprache, Status und Mapping-Aktion, und crawlen Sie die produktionsnahe Umgebung mit der finalen Konfiguration.

• Schritt 17: Einen vollständigen Crawl und Vergleichstests für Statuscode, Redirect, Canonical, Robots, hreflang, Title, H1, Inhalt, interne Links, Schema und Sitemap durchführen.
• Schritt 18: Eine formale Go/No-go-Entscheidung treffen, mit null kritischen Befunden, akzeptierten Restpunkten, getesteter Kapazität und benannten Entscheidern.

10. Cutover in festgelegter Reihenfolge

Legen Sie das Zeitfenster in eine Phase mit geringerem Geschäftsaufkommen, in der das Team trotzdem vollständig verfügbar ist. Google weist darauf hin, dass alte und neue URLs nach einem Umzug verstärkt gecrawlt werden können. Infrastruktur und Redirect-Schicht brauchen dafür ausreichend Kapazität.

• Schritt 19: Redirects, endgültige Robots- und Indexierungsregeln, neue Sitemaps, Analytics, Verifizierung in der Search Console und Monitoring in einer festgelegten Reihenfolge aktivieren.
• Schritt 20: Direkt nach der Aktivierung Smoke Tests für Top-URLs, Templates, Checkout, Statuscodes, Canonicals, Robots, hreflang, Schema und Logs ausführen.

11. Rollback unter klar definierten Bedingungen

Ein Rollback ist mehr als die spontane Rückkehr zum alten Deployment. Seit dem Cutover können Daten, Bestellungen, Kundenkonten und Inhalte weitergelaufen sein. Legen Sie vorab fest, welche Komponenten technisch umkehrbar sind und wie neue Geschäftsdaten erhalten bleiben.

• Schritt 21: Auslöser für den Rollback, Entscheider, maximale Entscheidungszeit und technische Reihenfolge vor dem Launch testen.
• Schritt 22: Den Rollback für Redirects, DNS/CDN, Deployment und Daten je Komponente dokumentieren; neue Bestellungen und Kundendaten dürfen dabei nicht verloren gehen.

12. Monitoring an Tag 1, 7, 30 und 90

Google verarbeitet Site Moves URL für URL, eine feste Dauer gibt es nicht. Bewerten Sie deshalb Muster und Segmente und nicht nur Gesamtwerte. Vergleichen Sie dabei stets mit der Baseline, der Saisonalität und nicht organischen Kontrollsignalen.

• Schritt 23: An Tag 1 und 7 den Betrieb überwachen: 5xx, 404, Redirects, Googlebot-Logs, robots/noindex, Verarbeitung der Sitemaps, Analytics, Checkout und die wichtigsten Landingpages.
• Schritt 24: An Tag 30 und 90 die Übertragung bewerten: Indexierung alter und neuer URLs, Klicks, Impressionen, Suchanfragen und Seitentypen, gewählte Canonicals, Rich Results, Core Web Vitals, Umsatz und verbliebene alte URLs.

13. Abschlusskriterien und langfristige Pflege

Mit dem Livegang des neuen Shops ist eine Migration nicht abgeschlossen. Abgeschlossen ist sie, wenn kritische alte URLs korrekt weiterleiten oder bewusst entfernt wurden, die neuen kanonischen URLs indexiert sind, die Entwicklung der Geschäftszahlen erklärt ist und kein ungeklärtes technisches Fehlermuster mehr besteht.

Google empfiehlt, Redirects mindestens ein Jahr lang beizubehalten; für Nutzer können sie auch länger sinnvoll sein. Bauen Sie alte Domain-, CDN- oder Hosting-Komponenten erst ab, wenn Redirects, Zertifikate, Verifizierung und Logzugriff dauerhaft gesichert sind.

• Die Redirect-Abdeckung für URLs mit Traffic, Links und Umsatz ist vollständig.
• Die Sitemaps enthalten nur kanonische URLs mit Status 200.
• Alte URLs verschwinden wie erwartet aus dem Index, und Google wählt die neuen.
• Es gibt keine systematischen Fehler bei Soft-404, Canonicals, hreflang oder Rendering.
• Strukturierte Daten und Feeds stimmen mit den sichtbaren Produktdaten überein.
• Abweichungen bei organischem Traffic und Geschäftszahlen sind erklärt und einem Verantwortlichen zugeordnet.
• Für Redirects, Zugänge zur Search Console und Monitoring gibt es dauerhaft Verantwortliche.