Migration weg von Shopify ohne Bestell- oder SEO-Verlust: ein Playbook

„Ohne SEO wäre ich morgen weg von Shopify.“ Hören wir von jedem zweiten Kunden, der die Plattform entwachsen ist. Die Sorge ist berechtigt — eine schlechte Migration kann organischen Traffic in 3 Monaten um 40-60 % erdrosseln. Dann ist die Migration ein technischer Erfolg und ein Geschäftsdesaster.

Das hier ist das Playbook vom MessyPlay-Umzug. Keine Theorie — nur die Schritte, die wir gemacht haben, um ein Custom-System auszuliefern und gleichzeitig Suchrankings zu halten und keine Bestellung zu zerbrechen.

Schritt 1: Vollständiges URL-Audit vor der ersten Codezeile

Aus der Google Search Console jede URL exportieren, die mindestens 1 Besuch/Monat bekommt. Aus Ahrefs/Semrush eine Tabelle der Backlinks und Ziel-URLs. Aus der Shopify-sitemap.xml alle Produkt- und Kategorie-URLs.

Output: ein CSV mit ~3 Spalten — oldUrl, newUrl, notes. Für MessyPlay waren das ~400 URLs. Jede haben wir per Hand geprüft, ob das neue System ein 1:1-Äquivalent hat. 12 URLs nicht — das waren alte Kollektionen, die im neuen System wegfielen. Die bekamen Redirect auf die nächste Alternative, NICHT auf die Homepage.

Diese Phase ist die langweiligste und wichtigste. Wenn Sie sie überspringen, beginnt Google 72 Stunden nach Cutover URLs aus dem Index zu entfernen, weil sie 404 zurückgeben. Sie kommen 2-8 Wochen später zurück. Dazwischen: nichts.

Schritt 2: 301-Redirects ab der ersten Sekunde

Das neue System muss beim Start ALLE alten URLs bedienen. Jede gibt HTTP 301 mit Location-Header auf die neue URL zurück. Kein 302 (temporär, Google aktualisiert den Index nicht), kein JS-Redirect (Bot sieht es nicht), kein Meta-Refresh.

Technisch: Middleware (in .NET/Next.js), die vor allem anderen eine redirects-Tabelle prüft und bei Treffer 301 zurückgibt. Die Tabelle befüllen Sie aus dem CSV aus Schritt 1.

Für MessyPlay haben wir die 301-Tabelle auf mindestens 12 Monate geplant. Nach einem Jahr könnten Redirects mit Null-Traffic entfernt werden, aber meist unnötige Arbeit — besser drin lassen.

Schritt 3: Kundenkonten werden übertragen, Passwörter nicht

Den Shopify-Password-Hash-Algorithmus kennen Sie nicht, also können Sie die Hashes nicht übernehmen. Identität (E-Mail, Name, Adresse, Bestellhistorie) wird übertragen; beim ersten Login im neuen System bekommen Nutzer automatisch eine Password-Reset-E-Mail.

Die Kommunikation muss vorher raus. Für MessyPlay haben wir 3 Tage vor Cutover eine E-Mail verschickt: „Wir wechseln auf ein neues System; beim ersten Login werden Sie aufgefordert, ein neues Passwort zu setzen.“ Wer sie übersehen hat, hat es beim ersten Versuch selbst verstanden. Beschwerden: null.

Schritt 4: Parallelbetrieb während des Cutovers

Am Tag X, an dem DNS von Shopify auf das neue System umschaltet, können Bestellungen im Zwischenzustand hängen: Shopify hat eine Bestellung, die das neue System nicht hat (oder umgekehrt). Wege zur Milderung:

• Cutover außerhalb der Peak-Hours (ideal 2-4 Uhr MEZ) — Minimum Bestellungen im Flug
• DNS-TTL eine Woche vorher auf 300 s gesenkt — schnellere Propagation
• Letzter Shopify-Bestell-Export im Cutover-Moment (nicht Snapshot eine Stunde vorher) — alles was Shopify hat, landet im neuen System
• Wartungs-Banner auf dem Shopify-Checkout 10 Min vor Cutover — stoppt neue Bestellungen

Für MessyPlay dauerte der Cutover 32 Minuten. 2 Bestellungen im Flug abgefangen — administrativ in einer Stunde gelöst. Der Kunde hat es nicht bemerkt, die Käufer erhielten Bestätigungs-E-Mails wie gewohnt.

Schritt 5: Monitoring in den ersten zwei Wochen

Nach Cutover 3 Dinge beobachten:

• Search Console Coverage-Report — neue 404-Fehler = fehlende Redirects
• Ahrefs/Semrush Position-Tracker für Top-20-Keywords — Abfall um 2-3 Positionen ist normal, 10+ ist ein Migrations-Bug
• Checkout-Funnel in Analytics — wenn Conversion > 5 % fällt, ist UX irgendwo kaputt

Für MessyPlay erste Woche: 7 neue 404s (mit Redirect-Rules gefixt), organischer Traffic +3 % gegenüber Vorwoche, Conversion stabil. Nach einem Monat: Traffic +11 %, Rankings stabil oder besser. Nach einem Quartal: +23 %.

Was sich nicht überspringen lässt

Diese Migration hat keine Abkürzung. Vier Dinge, die nach Nice-to-have aussehen, aber keine sind:

• Alle 400 URL-Mappings von Hand prüfen — lässt sich nicht automatisieren. Google verzeiht nicht.
• 301s auf Staging vor Cutover testen — einen Crawler (Screaming Frog) gegen alle alten URLs laufen lassen.
• Cutover außerhalb der Peak-Hours — spart mehr Nerven als zwei zusätzliche Arbeitsstunden.
• Ganzheitliches 14-Tage-Monitoring — nicht nur „Homepage funktioniert“. Ein 404 auf einer Produkt-URL ist eine Conversion, die Sie im Log nicht sehen, nur in der Search Console.

Wer das macht, dessen Migration ist für Google und Kunden unsichtbar. Wer eine Phase umgeht, sehen wir 3 Monate später mit „können Sie das zurückholen?“ Meist ja, aber es kostet ~2× mehr als beim ersten Mal richtig gemacht.