TL;DR. Ein Online-Shop Relaunch ist mehr als ein Redesign: Plattform-Wechsel, Datenmigration, Redirect-Strategie und SEO-Schutz laufen parallel. Wir zeigen, wie ein Online-Shop Relaunch in unseren Projekten geplant wird, welche typischen Fehler den Online-Shop Relaunch zum Risiko machen und wie du den Go-Live ohne Ranking-Crash hinbekommst.
Ein Relaunch ist nicht einfach ein Update. Es ist eine Bewährungsprobe für deinen Shop, dein Team und deine Geduld. Wir begleiten Shop-Relaunches seit 2011 und sehen immer wieder die gleichen Fehler. Mit diesem Leitfaden weißt du von Anfang an wo die Gefahren liegen, wie du realistische Timelines setzt und warum dein SEO-Ranking nicht automatisch in den Keller gehen muss.
Inhaltsverzeichnis
- Wann ist ein Relaunch wirklich nötig?
- Relaunch vs. Weiterentwicklung
- Der typische Ablauf: Fünf Phasen
- Die vier Ausbaustufen als Kostenreferenz
- SEO-Risiken beim Relaunch und wie du sie vermeidest
- Datenmigration: Das unterschätzte Risiko
- Die sieben häufigsten Fehler
- Realistische Timelines
Wann ist ein Relaunch wirklich nötig?
Nicht jeder wackelige Shop braucht einen Relaunch. Manchmal ist ein gutes Facelift genug.
Du brauchst einen Relaunch wenn:
- Deine Plattform ist veraltet und wird bald nicht mehr supported (z.B. Magento 1 oder alte Shopware-Versionen)
- Die Performance ist chronisch schlecht und Optimierungen helfen nicht wirklich
- Du wechselst die Plattform (z.B. von Magento zu Shopware oder zu Shopify), mehr dazu in unserem Leitfaden zum Replatforming
- Dein Geschäftsmodell hat sich grundlegend verändert (z.B. B2C zu B2B Commerce)
- Du brauchst Funktionalität die deine aktuelle Plattform nicht liefert (z.B. Headless, Multi-Marketplace)
- Dein Design ist nicht responsiv und mobiler Traffic leidet
Ein Facelift oder eine Weiterentwicklung reicht wenn:
- Deine Plattform funktioniert stabil und wird aktiv supported
- Es sind einzelne Funktionen oder Prozesse die nicht passen
- Dein Shop läuft gut, sieht aber einfach nur in die Jahre gekommen aus
- Du brauchst neue Features die Plugins/Extensions liefern können
Der Unterschied ist entscheidend. Ein Relaunch bindet ein ganzes Team für 6-18 Monate. Eine Weiterentwicklung dauert 2-4 Monate und hat weniger Risiko.
Relaunch vs. Weiterentwicklung
Hier ist die ehrliche Einschätzung: Viele Relaunches sind massiver Overkill.
Ich treffe Gründer die sagen "Unser Shop braucht einen Relaunch" und meinen eigentlich "Unser Shop sieht veraltet aus und die Checkout-Conversion ist zu niedrig". Das sind zwei verschiedene Probleme.
Ein Relaunch ist eine strategische Entscheidung. Es bedeutet: Wir bauen das System neu und migrieren alle Daten. Ein Relaunch kostet Zeit, Geld und Risiko.
Eine Weiterentwicklung heißt: Wir bauen neue Features, optimieren bestehende Prozesse, vielleicht geben wir dem Design einen Kick. Der Shop läuft die ganze Zeit normal weiter. Das Risiko ist deutlich kleiner.
Wir arbeiten mit Kunden oft an einem hybriden Ansatz: Wir bauen neue Features während der Shop produziert. Das ist möglich wenn die Infrastruktur stabil ist. Aber ab einem bestimmten Punkt macht es einfach mehr Sinn einen Cut zu machen und neu zu starten.
Die Faustregel: Wenn mehr als 40% des Systems neu sein muss, rechnet sich ein Relaunch meistens. Darunter ist eine Weiterentwicklung klüger.
Der typische Ablauf: Fünf Phasen
Unsere Faustregeln für Relaunches:
- Immer unter 9 Monaten (besser 6). Länger wird kompliziert.
- MVP-First Ansatz: Nicht alle Features zum Launch. Wichtigste 20% zuerst.
- "Agiler Wasserfall": Du willst Kosten, Dauer und Scope kennen. Das ist nicht klassisch Wasserfall, aber auch nicht wild agil.
Ein gut geplanter Relaunch folgt dieser Struktur.
Phase 1: Discovery (4-6 Wochen)
Du verstehst nicht was du bauen sollst, also fängst du mit Verstehen an. Discovery ist kein Luxus, es ist der Grund warum viele Relaunches schiefgehen.
Was passiert in Discovery:
- Analyse des aktuellen Shops (technisch und geschäftlich)
- Interviews mit dem Team (Versand, Buchhaltung, Marketing)
- Anforderungen sammeln und priorisieren
- Technologie-Entscheidung treffen (bleibt ihr auf der Plattform? Wechsel?)
- Scope und MVP definieren
- Realistische Kosten und Timeline aufstellen
Die wichtigste Erkenntnis aus langjähriger Praxis: 80% der Anforderungen sind kein echtes Problem des alten Shops. Sie sind Wünsche oder Features die es aus Gründen nie gab. In Discovery musst du unterscheiden zwischen echten Anforderungen und optionalen Wünschen.
Das ist der Punkt wo du auch ehrlich entscheidest: Machen wir einen Relaunch oder eine Weiterentwicklung?
Phase 2: Konzept und Design (6-10 Wochen)
Jetzt wird das konkret. Wie sieht der neue Shop aus? Wie funktionieren die kritischen Prozesse (Checkout, Kundenkonto, Bestellungen)?
Design ist nicht nur Farben und Fonts. Design ist auch die Architektur. Wie ist der Shop strukturiert? Wo leben die Daten? Wie sprechen die Systeme miteinander?
In dieser Phase passiert auch die technische Architektur-Entscheidung. API-first? Monolith? Headless? Welche Drittsysteme werden angebunden?
Parallel läuft die Datenmigrations-Strategie. Wie viele alte Produkte werden migriert? Gibt es Datenqualitätsprobleme im alten System? Wie werden Kundenkonten übertragen?
Typische Dauer: 2-3 Monate. Das klingt lang, aber es spart dir Monate an Nacharbeit.
Phase 3: Frontend- und Backend-Entwicklung (12-24 Wochen)
Das ist die längste Phase. Hier wird tatsächlich gebaut. Frontend, Backend, APIs, Payment-Integration, Versand-Integration, ERP-Anbindung.
Parallel laufen:
- Entwickler-Tests
- QA-Testing auf Staging
- Datenmigrations-Skripte testen
- Payment-Provider testen
- Marketing bereitet sich auf den Launch vor
Die kritische Erkenntnis hier: Je länger diese Phase läuft, desto komplexer wird sie. Der alte Shop wird weiterhin gepflegt und es entstehen Datendrifts. Das wird exponentiell komplizierter.
Deswegen arbeitet dasistweb nach einem MVP-Ansatz. Nicht alle Features am Launch-Tag. Features die später gebraucht werden, werden später gebaut.
Phase 4: Migration und Testing (3-6 Wochen)
Alle Daten vom alten Shop in den neuen. Das ist nicht nur ein Datenkopieren, es ist eine Transformation.
Produkte werden migriert. Kundenkonten werden migriert. Bestellhistorie wird migriert. Aber nicht alle Kundenkonten und nicht alle Produkte. Alte Kunden mit nur einer Bestellung vor drei Jahren? Die werden schlicht nicht repliziert. Das ist eine Entscheidung die ihr treffen müsst.
Dann folgt eine QA-Phase. Der neue Shop wird mit realen Daten getestet. Checkout wird getestet. Jede Integration wird getestet.
Das ist auch der Punkt für URL-Weiterleitungen. Alte URLs müssen auf neue URLs umgeleitet werden. 301-Weiterleitungen damit Google weiß, das ist kein neuer Shop sondern ein umgezogener. Das ist kritisch für SEO.
Phase 5: Launch und Stabilisierung (1-2 Wochen nach Launch)
Der Moment der Wahrheit. DNS wird umgeleitet oder der neue Shop wird live geschaltet. Das sollte Freitag oder Samstag Mittag sein, nicht Freitagabend.
Was passiert am Launch-Tag:
- Der alte Shop wird auf Read-Only gesetzt oder offline
- Der neue Shop geht live
- DNS wird aktualisiert
- SSL-Zertifikat geprüft
- Kundenservice-Team sitzt bereit
- Monitoring läuft
- Google und andere Suchmaschinen werden benachrichtigt
Die Woche danach ist für Stabilisierung. Bugs werden gefixt. Performance wird optimiert. Kundenunterstützung läuft auf Hochtouren.
Ein gutes Launch-Monitoring ist unverzichtbar. Nicht nur ob der Shop online ist, sondern: Funktioniert der Checkout? Funktioniert Payment? Wie sieht die Performance aus?
Die vier Ausbaustufen als Kostenreferenz
Relaunch-Kosten sind nicht abstrakt. Hier sind die vier Ausbaustufen die wir im Relaunch sehen:
Stufe 1: Standard-Relaunch mit Theme-Anpassung
- Theme-basiertes Design (Shopware, Shopify Standard)
- Standard-Integrationsumfang (ERP, PIM, Payment, Versand)
- Keine oder minimale Custom-Entwicklung
- Migration: Produkte, Kategorien, Basis-Kundendaten
- Zeitrahmen: 3-4 Monate
- Kosten: 25.000+ EUR
Das ist das Einstiegsmodell. Für Shops mit Standard-Anforderungen.
Stufe 2: Individuelle Anpassungen und Anbindungen
- Design-Anpassung (Theme wird angepasst, aber nicht komplett neu)
- Umfangreiche Integrationen (ERP, PIM, CRM, Custom-APIs)
- Custom-Features für spezielle Prozesse (z.B. individuelle Checkout-Logik, Kundensegmentierung)
- Migration: Komplette Produktdaten, Kundenkonten, Bestellhistorie
- Zeitrahmen: 4-6 Monate
- Kosten: 50.000+ EUR
Das ist das Standardmodell für Shops mit individuellen Anforderungen. Wo du nicht einfach ein Theme nehmen kannst sondern anpassen musst.
Stufe 3: Individuelles Frontend + tiefe Integration
- Komplett eigenes Frontend-Design (nicht theme-basiert, sondern von Grund auf neu)
- Umfangreiche Custom-App-Entwicklung (individuelle Funktionalität)
- Tiefe Systemintegration (ERP mit komplexer Geschäftslogik, Multi-Channel)
- Migration: Alles inklusive
- Zeitrahmen: 6-10 Monate
- Kosten: 100.000+ EUR
Das ist der Punkt wo ein individuell entwickeltes Frontend Sinn macht. Weil die Anforderungen so spezifisch sind dass ein Theme immer ein Kompromiss wäre.
Stufe 4: Headless Commerce
- Vollständig entkoppeltes Frontend (Nuxt, Next.js, React)
- Backend und Frontend haben eigene Update-Zyklen
- Volle Flexibilität für die Darstellung
- Hochperformant weil das Frontend komplett unabhängig ist
- Zeitrahmen: 8-14 Monate
- Kosten: 120.000+ EUR
Headless Commerce ist nicht automatisch teurer. Headless ist eine Architektur-Entscheidung. Wenn du diese Flexibilität brauchst zahlt sich Headless aus.
Die ehrliche Einschätzung: Stufe 4 hat höhere Initialkosten, aber der Gesamtbetrieb wird über die Zeit günstiger weil Updates einfacher sind. Wenn dein Shop komplexe Anforderungen hat oder du schnell Features deployen musst ist Headless die richtige Wahl.
SEO-Risiken beim Relaunch und wie du sie vermeidest
Das größte Risiko bei einem Relaunch ist dein Ranking. Ein Relaunch kann dein Ranking massiv beschädigen wenn du nicht aufpasst.
Das größte Problem: Alte URLs verschwinden einfach.
Wenn du alte URLs nicht auf neue URLs weiterleitest sieht Google einen 404. Das ist keine Umleitung, das ist eine Seite die nicht mehr existiert. Dein Ranking für die alte URL geht auf null.
Die Weiterleitungs-Strategie
Ihr müsst ein 1-zu-1 URL-Mapping erstellen. Alte URL zu neue URL.
Beispiel:
/produkte/ein-schoenes-shirt-rot -> /shop/bekleidung/hemden/ein-schoenes-shirt
Diese Weiterleitungen müssen 301-Weiterleitungen sein (permanent). Das teilt Google mit: Die Seite ist umgezogen, nicht gelöscht.
Im Code sieht das so aus (Beispiel in Nginx):
rewrite ^/produkte/(.*)$ /shop/bekleidung/$1 permanent;
Oder in .htaccess (Apache):
Redirect 301 /produkte/ein-schoenes-shirt-rot /shop/bekleidung/hemden/ein-schoenes-shirt
Wenn du diese Weiterleitungen nicht hast verlierst du SEO-Kraft (Page Rank). Wenn du keine exakte 1-zu-1 Zuordnung hast leite auf eine ähnliche Kategorie-Seite weiter. Besser eine Weiterleitung auf eine Kategorie als ein 404.
Meta-Daten und Strukturierte Daten
Alle Meta-Titles, Meta-Descriptions und Schema.org Daten sollten auf dem neuen Shop identisch sein zu den alten. Wenn du die Meta-Descriptions änderst, muss das bewusst sein.
Strukturierte Daten (JSON-LD für Products, Organization, etc.) müssen mitgezogen werden.
Google Search Console Konfiguration:
- Neue Property für neue Domain (wenn domain sich ändert)
- Unter "Tools" die URL-Änderung dokumentieren
- Neue Sitemap einreichen
- Alte Sitemap aus alter Property entfernen
Die Crawl-Phase nach Launch
In den ersten Tagen nach Launch crawlt Google deinen neuen Shop intensiv. Dein Monitoring sollte laufen:
- Sind alle wichtigen Seiten indexiert?
- Gibt es unerwartete Crawl-Fehler?
- Funktionieren die Weiterleitungen?
Wenn es Probleme gibt musst du die schnell sehen und fixen. Ein Relaunch ist nicht am nächsten Tag vorbei, das dauert 2-4 Wochen bis alles neu indexiert ist.
Unser Tipp: Plane einen Relaunch nicht für Freitag Abend oder direkt vor Weihnachten. Plant für Montag/Dienstag morgens. So habt ihr Zeit um Probleme zu fixen wenn was schiefgeht. Am Launch-Tag sollte jemand mit Monitoring im Office sitzen, nicht im Home Office.
Datenmigration: Das unterschätzte Risiko
Datenmigration ist der Part wo 70% der Relaunch-Probleme entstehen.
Es geht nicht darum, dass die Daten von A nach B kopiert werden. Es geht um Datentransformation. Der alte Shop speichert Produktdaten anders als der neue. Die alte Plattform speichert Attribute anders. Kategorien sind anders strukturiert.
Das Datenmigrations-Projekt
Eine gute Datenmigrations-Strategie sieht so aus:
Schritt 1: Datenqualität im alten System prüfen
Wie viele Produkte sind aktiv? Wie viele sind Duplikate? Wie viele Attribute sind leer oder haben ungültige Werte? Wie viele Kundenkonten sind Spam?
Das ist nicht glamorös, aber unverzichtbar. Wenn du 50.000 Produkte hast und 30% sind Duplikate oder inaktiv dann migrierst du auch nicht alle 50.000. Du migrierst die guten 35.000 und tagst die Duplikate.
Schritt 2: Mapping definieren
Wie werden die Daten transformiert? Welche Felder des alten Systems gehen auf welche Felder des neuen?
Beispiel:
- Altes Feld "color_rgb" -> Neues Feld "hex_color" (mit Transformation)
- Alte Kategorie "Sommer 2023" -> Neue Struktur "Saison / Sommer / 2023"
Schritt 3: Migrationsskripte schreiben und testen
Das sind typischerweise SQL-Skripte oder Python-Skripte. Die Skripte werden geschrieben und getestet gegen eine Kopie der alten Datenbank. Nicht gegen die produktive. Das ist wichtig.
Schritt 4: Mehrmals testen
Migration wird gegen Test-Datenbank gemacht. Dann wird geprüft ob die Daten sinnvoll aussehen. Sind Bilder migriert? Sind SEO-Texte migriert? Funktionieren die Links noch?
Schritt 5: Go / No-go Entscheidung
24 Stunden vor Launch macht ihr eine finale Migration gegen eine aktuelle Kopie des Systems. Wenn was schief läuft habt ihr noch Zeit zu fixen.
Typische Datenmigrations-Fehler
- Zu viele Daten migrieren. Alte Bestände, inaktive Produkte, Spam-Kundenkonten. Die Migration wird langsamer und die Datenqualität ist schlechter.
- Bilder vergessen. Bilder sind nicht einfach eine URL. Bilder können Rechte-Probleme haben, falsche Größen sein, kaputte Links. Eine Bild-Validierung ist unverzichtbar.
- Kategorien-Hierarchie nicht re-strukturiert. Der alte Shop hat vielleicht 200 Kategorien weil nie jemand aufgeräumt hat. Im neuen Shop machst du eine saubere Struktur.
- URLs nicht neu generiert. Deine alten Produkt-URLs waren vielleicht "shop.de/produkte/123-schoenes-shirt". Im neuen System hast du vielleicht "shop.de/bekleidung/herren/hemden/schoenes-shirt". Das ist nicht nur ein Rewrite, das ist eine neue URL-Logik. Das braucht Planung.
Die sieben häufigsten Fehler
Wir sehen diese Fehler immer wieder. Wenn du nur einen Part aus diesem Artikel merkst dann diesen:
Fehler 1: Zu viel auf einmal bauen
Du brauchst nicht alle Features zum Launch. MVP-Ansatz: MVP heißt "Minimum Viable Product". Das ist das Produkt mit den 20% Features die 80% des Umsatzes generieren.
Der Rest wird nach Launch gebaut. Neue Features können eine Woche nach Launch kommen. Das ist OK. Ein Relaunch der zwei Monate läuft ist keine Verbesserung, das ist ein Debakel.
Symptom: "Aber wir brauchen dieses Feature noch vor Launch". Nein, ihr braucht das vielleicht, aber nicht für den Launch. Launch ist: Der Shop läuft stabil und die wichtigsten Prozesse funktionieren.
Fehler 2: Keine klare Launch-Checkliste
Was muss am Launch-Tag passieren? In welcher Reihenfolge? Wer ist verantwortlich?
Eine Launch-Checkliste sieht so aus:
- Backup des alten Shop-Systems
- Alte DB auf Read-Only
- Neue Daten-Migration ausführen
- DNS aktualisieren
- SSL-Zertifikat prüfen
- Payment-System testen
- Versand-Integration testen
- E-Mail-Versand testen
- Wichtige Produkt-Seiten testen
- Login testen
- Checkout bis zum Ende testen
- Monitoring starten
- Team-Kommunikation starten
Jeder Punkt hat einen Verantwortlichen. Wenn einer schiefgeht weiß jeder wo das Problem ist.
Fehler 3: SEO vergessen
Das haben wir schon erwähnt aber es passiert. Weiterleitungen vergessen. Meta-Daten nicht mitgezogen. Robots.txt bei Launch zu restriktiv (Staging-Konfiguration gehört auf Staging, nicht auf Production mit noindex).
Symptom: Nach zwei Wochen sind 50% der Keywords aus dem Ranking. Das ist nicht normal und ein Zeichen dass SEO schlecht geplant war.
Fehler 4: Keine Fallback-Strategie
Was passiert wenn der Launch schiefgeht? Wenn der neue Shop nicht stabil ist und 500er-Fehler wirft?
Strategie: Du hast einen alten Shop als Fallback. Wenn was schiefgeht kannst du schnell via DNS zurück auf den alten Shop.
Das klingt einfach, aber die Realität: Viele haben keinen Fallback. Sie hoffen dass alles gut geht. Und dann geht etwas schief. Und dann ist der Feierabend vorbei.
Fehler 5: Performance ist unteroptimal
Der neue Shop ist live aber langsam. Das passiert wenn du nicht proaktiv Performance-Optimierung machst.
Prüfen vor Launch:
- Pagespeed Insights Score > 80 für wichtige Seiten
- Bilder sind optimiert und komprimiert
- CSS/JS ist minifiziert
- Caching ist konfiguriert
- CDN ist aktiv
Ein langsamer neuer Shop ist schlechter als ein alter Shop. Schnell schlägt neu.
Fehler 6: Das Team wurde nicht vorbereitet
Der Relaunch ist live und das Customer-Service-Team weiß nicht wie die neuen Systeme funktionieren.
Das ist ein Kommunikationsfehler. Zwei Wochen vor Launch sollte dein Team bereits auf dem neuen System trainiert sein. Wie sieht das Admin-Panel aus? Wie erstelle ich ein neues Produkt? Wie bearbeite ich eine Bestellung?
Das Training dauert einen Tag. Es spart dir später zwei Wochen Chaos.
Fehler 7: Launch-Date ist nicht realistisch
Du sagst "Launch ist in drei Monaten" und dann sind die ersten zwei Monate vorbei und es ist nichts fertig. Das ist ein Planungsfehler, kein Ausführungsfehler.
Realistische Planung:
- Rechne 30% Puffer auf jede Phase
- Relaunch dauert 6-18 Monate je nach Komplexität
- Standard-Relaunch: 8-10 Monate
- Nicht unter 6 Monate planen außer bei kleinen, simplen Shops
- Q4 vermeiden, zu viele Dinge im November/Dezember
Realistische Timelines
Hier sind die realistischen Timelines die wir aus langjähriger Erfahrung sehen:
Kleine Shops (unter 500 Produkte, Standard-Features)
- Discovery: 3-4 Wochen
- Design: 4-6 Wochen
- Development: 8-12 Wochen
- Migration & Testing: 3-4 Wochen
- Gesamt: 4-6 Monate
Mittelgroße Shops (500-5000 Produkte, einige Custom-Features)
- Discovery: 4-6 Wochen
- Design: 6-8 Wochen
- Development: 12-16 Wochen
- Migration & Testing: 4-6 Wochen
- Gesamt: 6-10 Monate
Große/komplexe Shops (über 5000 Produkte, umfangreiche Integration, B2B)
- Discovery: 6-8 Wochen
- Design: 8-12 Wochen
- Development: 16-24 Wochen
- Migration & Testing: 6-8 Wochen
- Gesamt: 10-14 Monate
Diese Timelines sind ehrlich. Nicht optimistisch, nicht pessimistisch. Das ist was wir sehen.
Der kritische Punkt: Diese Timelines sind mit Vollzeit-Team. Mit Freiberuflern oder Teilzeit-Team dauert alles deutlich länger.