Der Branchen-Benchmark für den Rückgang des organischen Traffics nach einer Shop-Migration liegt bei 15–30% in den ersten drei Monaten, mit einer Erholung auf das Ausgangsniveau über die folgenden 6–12. Für einen Shop mit mehreren bis über zehn Millionen Złoty Jahresumsatz ist das keine Statistik — das ist ein oder zwei Quartale unter Plan, messbar in verlorener Marge.
In unseren Migrationen liegt der durchschnittliche Rückgang unter 3%. Dieser Unterschied entsteht nicht durch bessere Werkzeuge und nicht durch Magie — er entsteht durch die Reihenfolge der Schritte. Im Folgenden zeigen wir, warum Migrationen organischen Traffic vernichten, und den konkreten SEO-first-Prozess, mit dem wir den Verlust unter 3% halten. Am Ende finden Sie eine Liste von Fragen, mit denen Sie Ihren eigenen Dienstleister prüfen, bevor Sie einen Vertrag unterschreiben.
Warum eine Migration organischen Traffic vernichtet — sechs Mechanismen
Organischer Traffic verschwindet am Umschalttag nicht wegen eines abstrakten „Plattformwechsels". Er verschwindet wegen sechs konkreter, technischer Mechanismen. Jeder davon ist vermeidbar — vorausgesetzt, Sie kümmern sich vor der Umsetzung darum und nicht danach.
1. Alte URLs beginnen 404 zurückzugeben
Jede Plattform bildet Adressen anders. Was in PrestaShop /123-produktname.html war, wird in Shopify zu /products/produktname. Erhält die alte Adresse keine 301-Weiterleitung auf die neue, liefert sie einen 404. Nach einigen Besuchen entfernt Google sie aus dem Index, und mit ihr verschwindet die gesamte historische Linkkraft — extern und intern —, die diese Seite über Jahre aufgebaut hat. Das ist die größte einzelne Ursache für Einbrüche.
2. Die Weiterleitungen sind da, aber falsch gemacht
Das bloße Vorhandensein einer 301 genügt nicht. Weiterleitungsketten (301 → 301 → 200), Schleifen oder — der Klassiker — die Weiterleitung aller alten Adressen auf die Startseite statt auf die entsprechende Unterseite. Letzteres behandelt Google als „Soft 404" und überträgt keine Kraft. Die Weiterleitungskarte muss eins zu eins sein: eine konkrete alte URL auf eine konkrete neue mit derselben Intention.
3. Metadaten und strukturierte Daten fallen auf die Standardeinstellungen zurück
Die neue Plattform erzeugt eigene title-Tags, Meta-Descriptions und H1 — meist aus Vorlagen. Ausgefeilte Titel verschwinden, Canonicals zeigen plötzlich auf falsche Adressen, und schema.org (Product, Offer, BreadcrumbList, Review) wird nicht wiederhergestellt. Die Folge: Sie verlieren Rich Results in den Suchergebnissen — Sterne, Preise, Verfügbarkeit. Die Position kann gleich bleiben, während die CTR sinkt, weil Ihr Ergebnis plötzlich dürftiger aussieht als das der Konkurrenz.
4. Rendering und Performance verändern sich
Eine Migration auf Headless oder eine Single-Page-Application verlagert das Rendering oft auf die Client-Seite (JavaScript). Wird der Inhalt nicht serverseitig gerendert, sieht der Googlebot beim ersten Durchgang eine leere Seite. Dazu kommen die Core Web Vitals: ein langsamerer TTFB und LCP sind ein reales Problem — ein TTFB über 500 ms korreliert mit einem Konversionsrückgang von 5–10%, und langsamere Seiten indexiert Google seltener.
5. Crawl-Budget wird verschwendet
Nach dem Umschalten trifft der Googlebot auf tausende Weiterleitungen, 404-Seiten und Duplikate. Bei einem Katalog mit zehntausenden Adressen verbrennt der Bot sein Crawl-Budget damit, Müll erneut zu besuchen, statt neue Seiten zu indexieren. Je größer der Shop, desto länger warten neue Adressen auf die Indexierung — und eine Seite ohne Index erzeugt keinen Traffic.
6. Vorübergehende Instabilität des Index
Selbst eine perfekte Migration löst 2–6 Wochen „Umbau" aus: Google crawlt, rendert und bewertet die Seiten von neuem. Positionen schwanken. Das größte Risiko in dieser Phase ist Panik — das Team beginnt, mitten im Prozess Dinge zu ändern, wodurch die Bewertung wieder bei null startet. Ein guter Prozess beseitigt diese Phase nicht, aber er verkürzt sie und flacht ihre Amplitude ab.
SEO-first heißt: SEO entscheidet zuerst, es repariert nicht zuletzt
Die meisten Agenturen führen eine Migration technisch zuerst durch. Erst entsteht der Shop, die Daten werden übertragen, und SEO kommt am Ende — als Reparaturschicht, wenn der Rückgang in der Google Search Console schon sichtbar ist. In dieser Reihenfolge entsteht die Weiterleitungskarte unter Druck und nachträglich, und Metadaten sowie Schema sind „bei Gelegenheit nachzuliefern".
Wir drehen diese Reihenfolge um. Jeder Sprint beginnt mit einer SEO-Entscheidung und erst danach mit einer technischen. Die URL-Struktur des neuen Shops wird entworfen, bevor die erste Zeile Frontend-Code existiert — und nicht nach dem Go-live entdeckt. Das ist eine einzige Änderung im Prozess, aber sie ist verantwortlich für den Unterschied zwischen einem Rückgang von 15–30% und einem Rückgang unter 3%.
SEO-first bedeutet nicht „alles einfrieren, wie es war". Manchmal ist die alte URL-Struktur schlecht und es lohnt sich, sie zu verbessern — flache Kategoriehierarchie, doppelte Parameter, Adressen mit IDs statt Schlüsselwörtern. Der Unterschied ist, dass im SEO-first-Ansatz jede solche Änderung eine bewusste Entscheidung mit zugeordneter Weiterleitung ist und nicht ein zufälliger Nebeneffekt der neuen Plattform. Sie ändern, was Sie ändern wollen, und wissen genau, wohin jede alte Adresse führt.
Wenn ein Dienstleister SEO als Phase nach dem Go-live behandelt, ist ein Rückgang von 15–30% kein Risiko — er ist im Plan vorgesehen. Die Frage ist nur, wann Sie ihn sehen.
Der SEO-first-Prozess Schritt für Schritt
Nachfolgend der reale Ablauf — derselbe für eine Migration PrestaShop → Shopify Plus und für das Neuschreiben von Legacy-PHP in Symfony. Die Dauer unterscheidet sich, die Reihenfolge nicht.
Schritt 1 — Audit und SEO-Baseline (Woche 1–2)
Ein vollständiges Audit des aktuellen Shops: URL-Struktur, indexierbare Seiten, interne Verlinkung, Schema-Markup, Core Web Vitals. Dazu eine Traffic-Baseline aus der Google Search Console und Ahrefs. Es entsteht ein Dokument „Was wir unbedingt erhalten" — eine Liste der 200–500 wichtigsten Adressen nach Traffic und Konversion. Ohne diese Liste führt man eine Migration im Blindflug durch.
Schritt 2 — Informationsarchitektur und URL-Mapping (Woche 2–4)
Wir entwerfen die Struktur des neuen Shops mit einem Eins-zu-eins-Mapping für alle indexierten Seiten. Das entscheidende Detail: Jede URL validiert ein SEO-Spezialist, nicht nur ein Entwickler. Die Weiterleitungskarte entsteht genau hier — vor der Umsetzung — und geht in Regressionstests, nicht in ein Backlog „für nach dem Launch".
Schritt 3 — Entwicklung mit SEO-Tests nach jedem Sprint (Woche 4–18)
Iterative Entwicklung mit Validierung auf Staging. Nach jedem zweiwöchigen Sprint starten wir automatische SEO-Tests: Korrektheit des Weiterleitungs-Mappings, Vorhandensein von Schema-Markup, Core Web Vitals, Indexierbarkeit. Dazu eine manuelle Prüfung durch einen SEO-Spezialisten. Eine in Woche 8 auf Staging entdeckte Regression kostet eine Arbeitsstunde; dieselbe Regression nach dem Launch auf Produktion entdeckt kostet Positionen.
Schritt 4 — Cutover in einem Fenster mit geringem Traffic (Wochenende)
Die Produktivmigration erfolgt im Fenster mit dem geringsten Traffic — typischerweise Sonntagnacht — mit fertigem Rollback-Plan und 24/7-Monitoring in den ersten 72 Stunden. Das Umschalten geschieht ohne Verkaufsunterbrechung: Kunden kaufen während des gesamten Prozesses. Änderungen am Freitagnachmittag oder im Verkaufshoch einzuspielen ist ein unnötiges Risiko, das Sie schon durch die Terminwahl ausschließen.
Schritt 5 — 90 Tage Monitoring nach dem Go-live (inklusive)
Nach dem Cutover beginnt die Phase, in der der meiste Traffic zu gewinnen oder zu verlieren ist. 90 Tage lang gibt es wöchentliche Berichte zum organischen Traffic, 404-Monitoring, Prüfung der Indexierung neuer Seiten und Alarme bei Core-Web-Vitals-Regressionen. Wir haben eine Schwelle festgelegt: einen Rückgang über 5% in den ersten 30 Tagen beheben wir ohne Zusatzkosten. In der Praxis war in rund 95% unserer Migrationen kein Post-Launch-Fix nötig — weil das Problem in der Entwurfsphase gelöst wurde und nicht beim Feuerlöschen.
Parallel Run oder Big-Bang-Cutover?
Das Umschalten des Traffics vom alten auf das neue System lässt sich auf zwei Wege erledigen, und die Wahl dazwischen wirkt sich direkt auf das SEO-Risiko aus.
Big-Bang-Cutover ist das einmalige Umschalten von allem in einem Fenster. Schneller, günstiger und einfacher — er bewährt sich bei kleineren Katalogen und bei Migrationen SaaS → SaaS, wo das alte System vorhersehbar und gut dokumentiert ist. Das Risiko ist dann so gering, dass der Parallelbetrieb zweier Umgebungen nicht zu rechtfertigen ist.
Parallel Run bedeutet, dass das alte und das neue System eine Zeit lang nebeneinander laufen. Er erlaubt, Daten, Weiterleitungen und Performance an echtem Produktions-Traffic zu validieren, bevor Sie den alten Shop abschalten. Er ist teurer und komplexer — man muss zwei Infrastrukturen betreiben und zwischen ihnen Daten synchronisieren, die sich über die Zeit ändern: Lagerbestände, Bestellungen, Kundenkonten. Aber bei Legacy-Systemen ohne Dokumentation und einem Katalog mit zehntausenden Adressen ist es der einzige Weg, die Abhängigkeiten zu finden, an die sich niemand mehr erinnert, bevor sie die Produktion treffen.
Die Regel ist einfach: je mehr Unbekannte im alten System und je größer der Katalog, desto stärker neigt sich die Waage zum Parallel Run. Eine falsche Empfehlung kostet in beide Richtungen — ein unnötiger Parallel Run bei einer klaren SaaS-Migration verbrennt Budget, und ein Big Bang dort, wo ein Parallel Run nötig war, verbrennt Traffic. Genau diese Entscheidung möchten Sie begründet hören und nicht als Standard gesetzt bekommen.
Beweis: tausende Adressen und nahezu alle Positionen erhalten
Das schwierigste Szenario, das wir begleiten, ist eine Legacy-Migration. Bogart Meble lief zwölf Jahre auf Custom-Code in PHP 5.4 — ohne Dokumentation, mit Datenbankabfragen von mehreren Sekunden. Wir haben den Shop nach dem Strangler-Fig-Muster Modul für Modul in rund 16 Wochen auf Symfony 6.4 neu geschrieben.
Aus SEO-Sicht zählen drei Entscheidungen:
301-Mapping für alle URLs — eins zu eins, unter Beibehaltung einer identischen semantischen Struktur, und keine Sammelweiterleitung auf Kategorien.
Zwei Wochen Parallel Run — das alte und das neue System liefen parallel, wodurch Daten und Weiterleitungen an Produktions-Traffic validiert werden konnten, bevor endgültig umgeschaltet wurde.
DNS-Umstellung außerhalb der Spitzenzeiten, mit Positions-Monitoring ab der ersten Stunde nach dem Cutover.
Ergebnis: nahezu alle Google-Positionen erhalten, der Rückgang des organischen Traffics im ersten Monat unter unserer Schwelle von 3% gehalten, ohne Ausfall und ohne verlorene Bestellungen. Nebenbei fiel der LCP der Produktseite von mehreren Sekunden auf unter eine Sekunde, und die Konversion stieg nach drei Monaten deutlich — denn eine schnellere Seite verkauft besser, unabhängig von der Position.
Das zweite Beispiel zeigt, dass ein Plattformwechsel kein Feind des Traffics ist, wenn er gut gemappt wird. Topeshop migrierte von PrestaShop auf Shopify Plus samt Marketplace-Integration und verzeichnete +58% Konversion. Dasselbe Prinzip: Übertragen Sie erst eins zu eins, was im SEO schon funktioniert, und legen Sie erst danach Wachstum obendrauf.
Wie Sie Ihren eigenen Dienstleister prüfen
Sie müssen sich nicht mit SEO auskennen, um zu beurteilen, ob ein Dienstleister eine Migration sicher führt. Ein paar Fragen genügen, plus der Vergleich der Antworten mit dem, wie ein SEO-first-Prozess gegenüber einer typischen Migration „technisch zuerst" aussieht.
PhaseSEO-first-MigrationMigration „technisch zuerst"301-WeiterleitungskarteEntsteht in Woche 2–4, vor dem FrontendNach dem Go-live, wenn der Rückgang schon sichtbar istWer validiert die URLsEin SEO-Spezialist, nicht nur ein EntwicklerNiemand oder ein Entwickler „nebenbei"SEO-TestsNach jedem Sprint, automatisch und manuellEin Blick vor dem LaunchCutover-TerminFenster mit geringem Traffic, Rollback-Plan, 72 h Monitoring„Wir spielen es Freitagnachmittag ein"Positions-Monitoring90 Tage inklusive, Alarm bei Regression über 5%Der Kunde bemerkt den Rückgang selbst in der GSCTypischer Traffic-RückgangUnter 3%15–30%, Erholung in 6–12 Monaten
Eine Frage wiegt am schwersten: wann entsteht die 301-Weiterleitungskarte? Lautet die Antwort „darum kümmern wir uns nach dem Go-live" oder „wir generieren sie am Ende automatisch" — dann haben Sie Ihre Antwort, unabhängig vom Rest des Angebots.
Fazit
Eine Migration verliert Traffic nicht wegen des Plattformwechsels — sie verliert ihn wegen einer fehlenden Weiterleitungskarte, verlorener Metadaten und einer schlechteren Performance als vorher. Alle drei sind vermeidbar, wenn SEO zuerst entscheidet und nicht zuletzt repariert. Der Benchmark von 15–30% beschreibt technisch geführte Migrationen; ein Rückgang unter 3% ist erreichbar, wenn URL-Struktur, Weiterleitungen und Monitoring vor der Umsetzung geplant werden und nicht danach.
Wenn Sie eine Migration planen und wissen möchten, wie viel Traffic Sie real riskieren, beginnen Sie mit einem Shop-Audit — es erstellt die Liste „Was wir unbedingt erhalten". Sehen Sie sich außerdem an, wie unser Prozess der Shop-Migration aussieht, sowie konkrete Projekte, und wenn Sie Fragen zu Ihrem Fall haben, schreiben Sie uns.repariert