Relaunch ohne Ranking-Verlust: das SEO-Risiko beim Shop-Wechsel

Ihre organischen Rankings sind ein Vermögenswert. Sie sind über Jahre entstanden, sie bringen Umsatz, ohne pro Klick zu kosten — und sie stehen in keiner Projektkalkulation. Genau deshalb gehen sie bei Relaunches verloren: nicht weil Google Relaunches bestraft, sondern weil niemand im Projekt für sie zuständig war. Dieser Text erklärt, wo der Verlust technisch entsteht und wie Sie ihn verhindern — als Anforderung an Ihren Dienstleister, nicht als SEO-Kleinarbeit für Sie selbst.

Warum verlieren Shops beim Relaunch ihre Rankings?

Aus drei mechanischen Gründen: URLs verschwinden ohne Weiterleitung, rankende Inhalte werden gekürzt oder gelöscht, und die interne Verlinkung, die den wichtigen Seiten ihr Gewicht gab, existiert im neuen System nicht mehr. Google bewertet keine „Website” — es bewertet einzelne URLs mit ihrer Historie, ihren Inhalten und ihren Verlinkungen. Jeder Relaunch, der URLs, Inhalte oder Linkstruktur ändert (also praktisch jeder), verändert damit die Grundlage jedes einzelnen Rankings.

Das Tückische an diesem Risiko: Es ist am Launch-Tag unsichtbar. Der neue Shop funktioniert, die Testbestellung läuft, alle sind zufrieden. Der Schaden zeigt sich drei bis sechs Wochen später in der Search Console — dann, wenn das Projektteam schon aufgelöst ist.

Welche fünf Fehler kosten am meisten?

1. Keine vollständige Redirect-Map. Der häufigste und teuerste Fehler. Es reicht nicht, „die wichtigsten Seiten” weiterzuleiten — jede indexierte alte URL braucht eine 301-Weiterleitung auf ihr inhaltliches Pendant. Weiterleitungen pauschal auf die Startseite zählen dabei nicht: Google behandelt sie wie gelöschte Seiten.

2. Kategoriestruktur umgebaut ohne Mapping. Der neue Shop schneidet das Sortiment anders — fachlich oft richtig, aber die alten Kategorie-URLs ranken. Jede von ihnen braucht ein definiertes Ziel im neuen Schnitt, sonst verliert das Sortiment seine Einstiegsseiten.

3. Rankende Inhalte „aufgefrischt”. Texte, die seit Jahren auf Position 1 bis 5 stehen, werden im Relaunch-Schwung neu geschrieben oder gestrichen. Beim Relaunch dieser Website haben wir die rankenden Fachartikel bewusst wortgleich übernommen und nur ihre URLs per 301 umgezogen. Inhalte, die ranken, sind Bestand — kein Verbesserungspotenzial.

4. Storefront rendert ohne Server. Headless- und Framework-Storefronts sind architektonisch attraktiv, aber wenn Inhalte erst im Browser entstehen, sieht der Crawler eine leere Seite. Die Rendering-Frage gehört in den Architektur-Review, nicht in die Launch-Woche — wer sie dort zum ersten Mal stellt, baut um.

5. Launch-Tag ohne technische Abnahme. Das noindex aus der Staging-Umgebung geht mit live, die robots.txt sperrt den Crawler aus, die Sitemap zeigt auf alte URLs. Banale Fehler, Standardprüfung — und trotzdem in der Praxis die schnellste Art, komplett aus dem Index zu verschwinden.

Wie plant man den Wechsel, ohne Sichtbarkeit zu verlieren?

Als eigenes Arbeitspaket mit eigenem Verantwortlichen — nicht als Punkt auf der Launch-Checkliste. Konkret in vier Schritten.

Inventur vor dem Design. Welche URLs bringen heute Besucher und Umsatz? Search Console und Analytics beantworten das in einem Nachmittag. Diese Liste ist die Schutzliste des Projekts: Was darauf steht, wird portiert oder bewusst geopfert — aber nie versehentlich vergessen.

Die Redirect-Map als Deliverable. Eine Tabelle: jede alte URL, ihr Ziel, der Statuscode. Sie wird im Projekt gepflegt wie ein Datenmodell und vor dem Launch automatisiert getestet — jede Zeile muss ein echter 301 auf das richtige Ziel sein. Für diese Website liegt sie als Datei im Repository, und ein Test prüft bei jedem Build jede einzelne Zeile in beiden Varianten, mit und ohne abschließenden Schrägstrich. Wenn Ihr Dienstleister auf die Frage nach der Redirect-Map keine Tabelle zeigen kann, existiert sie nicht.

Rankende Inhalte 1:1 portieren. Redaktionelle Verbesserungen sind erlaubt — nach dem Relaunch, gestaffelt, mit Blick auf die Daten. Am Launch-Tag selbst ändert sich für eine rankende URL genau eines: ihre Adresse, per 301.

Launch-Abnahme und Monitoring. Am Launch-Tag: Indexierbarkeit, robots.txt, Sitemap, Stichprobe der Redirect-Map. Danach vier bis acht Wochen Search-Console-Monitoring auf der Schutzliste — Impressionen und Klicks pro URL, nicht nur die Gesamtkurve. Die Gesamtkurve versteckt den Verlust einzelner Geldseiten.

Wie viel Schwankung ist normal — und wann ist es ein Alarm?

Ein Relaunch mit sauberer Redirect-Map zeigt in den ersten zwei bis vier Wochen Bewegung: Google crawlt um, alte und neue URLs stehen kurz nebeneinander im Index, einzelne Positionen springen. Das ist Umbau, kein Schaden.

Ein Alarmsignal ist etwas anderes: Impressionen einer Seite von der Schutzliste, die nach vier Wochen nicht zurückkommen, Crawling-Fehler auf weitergeleiteten URLs oder ein Indexbestand, der weiter sinkt statt sich zu stabilisieren. Dann ist die Ursache fast immer eine der fünf oben — und je früher sie gefunden wird, desto mehr vom alten Ranking-Bestand ist noch zu retten.

Deshalb endet ein Relaunch-Projekt bei uns nicht am Launch-Tag, sondern nach dem Monitoring-Fenster. Wie das im Detail aussieht, steht in der Leistungsbeschreibung zur Shopware-Migration; wie es in einem Projekt mit drei Länder-Shops und fünf Marktplätzen ausgegangen ist, im Case zu thyssenkrupp.