Rankings nach Redesign gefallen: So findest du heraus, was kaputtgegangen ist

⏱ 15 Min. Lesezeit

Ein Redesign, das Rankings verliert, verliert sie fast nie durch Pech oder ein mysteriöses Algorithmus-Update. Es verliert sie durch eine konkrete, auffindbare Änderung, die am Launch-Tag live ging. Die neue Seite sieht sauberer aus, das Team ist erleichtert, und zwei Wochen später sind die organischen Klicks in der Search Console um 30 bis 40 Prozent eingebrochen. Die Ursache steckt im Unterschied zwischen alter und neuer Seite, und deine Aufgabe ist, sie schnell zu finden.

Dieser Guide ist für Shopify Shops geschrieben, und der Shopify-Kontext ist wichtiger, als die meisten Artikel zugeben. Ein generischer Beitrag sagt dir, du sollst zuerst fehlende Redirects prüfen. Bei einem reinen Theme-Wechsel ist dieser Rat oft falsch, denn ein Reskin behält fast immer jede URL genau dort, wo sie war. Unten steht die Diagnose, die ein Spezialist wirklich durchläuft, der Reihe nach, mit den Tools, Schwellenwerten und Zahlen, die jede Entscheidung tragen.

Zuerst prüfen: Ist der Traffic Einbruch echt?

Bevor du ein einziges Template anfasst, stelle sicher, dass der Rückgang echt ist und keine kaputte Messung. Redesigns taggen eine Seite häufig neu, und ein falsch reinstalliertes Google Analytics 4 oder ein Google Tag Manager Container zeigt einen Absturz der Sitzungen, während echte Besucher weiter ankommen. Trenne drei Fehlerarten, denn jede zeigt woanders hin:

• Ein Ranking-Einbruch zeigt sich als verlorene Positionen und Impressionen in der Search Console. Das ist ein SEO-Problem.
• Ein Traffic-Einbruch zeigt sich als verlorene Sitzungen im Analytics. Sind die Search-Console-Klicks stabil, die Sitzungen aber am Launch-Tag eingebrochen, ist das Tag kaputt, nicht das Ranking.
• Ein Conversion-Einbruch zeigt sich als stabiler Traffic mit weniger Bestellungen. Das bedeutet meist ein kaputtes Formular, ein langsamer Checkout oder eine Layout-Änderung, kein Suchproblem.

Google beschreibt diesen mess-zuerst-Ansatz in seinem Leitfaden zum Traffic-Einbrüche debuggen, und er ist der richtige Startpunkt. Mobil macht den Check dringend: Mobil ist rund 60 Prozent des E-Commerce-Traffics, ein reiner Mobil-Fehler beim Tracking oder Layout verdeckt also einen großen Teil des Bildes.

Den Einbruch eingrenzen: Seitentyp, Query, Gerät, Land

Ein Einbruch ist erst dann ein Hinweis, wenn du seine Form kennst. Öffne den Search Console Leistungsbericht, stelle den Zeitraum für den Kontext auf 16 Monate und zerlege den Verlust auf vier Arten. Das Muster sagt dir, wo du suchen musst, bevor du eine Theorie bildest.

• Nach Seitentyp. Shopify hat klare URL-Familien: /products/, /collections/, /pages/ und /blogs/. Haben nur Collections Sichtbarkeit verloren, liegt der Fehler im Collection-Template, nicht seitenweit.
• Nach Query. Ein Verlust, der sich auf wenige wertvolle Begriffe konzentriert, deutet auf Content- oder Intent-Änderungen genau auf diesen Seiten.
• Nach Gerät. Ein reiner Mobil-Einbruch deutet stark auf Core Web Vitals oder eine mobile Layout-Regression, da Google die meisten Experience-Signale mobil bewertet.
• Nach Land. Ein auf einen Markt begrenzter Einbruch bei einem DE- und EN-Shop deutet auf hreflang oder Locale-Routing, dazu weiter unten mehr.

Ein Google Update ausschließen, bevor du das Redesign beschuldigst

Zwei Dinge können sich gleichzeitig bewegen. Fiel dein Launch zufällig in ein breites Core Update, jagst du vielleicht einen Template-Bug, den es gar nicht gibt, oder du ignorierst einen echten, weil du annimmst, das Update erkläre alles. Löse das mit Daten. Prüfe im Search Status Dashboard Start und Ende eines aktuellen Core Updates und lege diese Daten neben dein Deploy-Datum.

• Einbruch startet am Launch-Tag, kein Update läuft: das Redesign ist die Ursache. Das ist eine gute Nachricht, denn selbst verursachte Probleme lassen sich diese Woche beheben.
• Einbruch folgt einem Update-Fenster, Templates und URLs intakt: vermutlich eine algorithmische Neubewertung, also ein Content-Qualitäts-Projekt auf einer anderen Zeitachse.

Google empfiehlt, nach dem Abschluss eines Updates eine volle Woche zu warten, bevor du Schlüsse ziehst, handle also nicht am ersten verrauschten Datentag.

Warum Shopify Redesigns SEO anders brechen

Die nützlichste Unterscheidung in dieser ganzen Diagnose ist Redesign gegen Replatforming, denn sie entscheidet, welche Ursachen überhaupt möglich sind. Generische Ratschläge scheitern hier, weil sie annehmen, jedes Redesign ändere URLs.

• Ein Theme-Reskin im selben Shop behält deine Domain, dein Shopify-Backend und fast immer deine URL-Handles. Shopify legt automatisch einen 301-Redirect an, wenn du einen einzelnen Produkt- oder Collection-Handle änderst, doch ein optisches Redesign fasst Handles kaum an. Bei einem reinen Reskin sind Redirects also selten die Ursache. Der Schaden kommt daher, was das neue Theme rendert: weniger Text, andere Überschriften, clientseitiger Content, schwächere Links und eine schwerere Seite.
• Ein Replatforming oder Umbau ist der Gegenfall. Ein Wechsel von WooCommerce oder Magento zu Shopify, oder eine geänderte URL-Struktur, schreibt viele Adressen auf einmal um. Hier sind Redirects, Sitemap-Neugenerierung und Canonical-Verhalten die Hauptrisiken, und ein sorgfältig geplante Shopify Migration schützt die Rankings.

Ursache eins, fehlende oder kaputte Redirects (meist ein Replatforming-Problem)

Kaputte Redirects sind die klassische Ursache, aber sie beißen vor allem, wenn sich URLs tatsächlich geändert haben. Jede alte URL, die Rankings oder Backlinks verdient hat und jetzt einen 404 liefert, ist verlorene Autorität. Benennst du zum Beispiel /collections/damen-stiefel in /collections/stiefel-damen um, ohne einen Redirect, verwandelst du jedes Ranking und jeden Backlink der alten URL in eine Sackgasse. Diagnostiziere es im Search Console Bericht zur Seitenindexierung, indem du nach einem Anstieg von „Nicht gefunden (404)“ nach dem Launch suchst, und gleiche diese URLs mit einem Export deiner Seite vor dem Launch ab.

Bei Shopify liegen Redirects im Admin unter Inhalte und dann URL-Weiterleitungen, und Shopify unterstützt nur permanente 301-Redirects, genau das, was du für einen Umzug willst. Zwei Punkte bringen Teams ins Straucheln. Shopify leitet automatisch weiter, wenn du einen Handle umbenennst, legt aber keinen Redirect an, wenn du eine Seite löschst, gelöschte Collections und ausgelistete Produkte brauchen also manuelle Regeln. Und die Menge ist nicht das Limit: Der Standardplan erlaubt bis zu 100.000 Redirects und Shopify Plus bis zu 20 Millionen, die echte Arbeit ist Vollständigkeit. Shopifys eigene Redirect-Dokumentation erklärt den CSV-Massenimport für große Mappings.

• Mappe jede alte URL auf ihr nächstes neues Pendant, Produkt auf Produkt, Collection auf Collection.
• Leite niemals alles auf die Startseite. Google wertet eine pauschale Startseiten-Weiterleitung als Soft 404 und verwirft das Relevanzsignal.
• Vermeide Ketten. Zeige von A direkt auf C, nicht A auf B auf C, denn jeder Sprung verliert etwas Equity und verlangsamt das Crawling.
• Reiche nach dem Import die Sitemap erneut ein und fordere über die URL-Prüfung ein Recrawling deiner wichtigsten Seiten an.

Ursache zwei, Content-Verlust auf Template-Ebene

Das ist der stille Killer bei Reskins im selben Shop, und Google benennt ihn direkt: In der eigenen Doku stehen „Template-Probleme“ als häufige Ursache, weil ein neues Template große Teile einer Seite auf einmal betrifft. Ein saubereres Design bedeutet fast immer weniger Text, und Google liest weniger Text als weniger Relevanz. Eine Collection-Seite, die 600 Wörter Kategorietext trug und jetzt 90 zeigt, gibt Google deutlich weniger zum Ranken.

Achte auf die konkreten Wege, wie ein Shopify-Rebuild Text entfernt:

• Intro- und Footer-Beschreibungen der Collection für ein aufgeräumteres Raster entfernt.
• Produktbeschreibungen in eingeklappte Akkordeons oder Tabs verschoben, das Detail ist da, aber abgewertet.
• Die alte, keyword-tragende H1 durch ein Logo oder eine generische Hero-Zeile ersetzt.
• Ausführliche Ratgeber auf /pages/ gekürzt, damit es modern wirkt.

Diagnostiziere per Vergleich, nicht aus dem Gedächtnis. Hole die alte Seite aus der Wayback Machine, crawle die archivierte und die Live-Version mit einem Tool wie Screaming Frog und vergleiche Wortanzahl, H1-Text und Title-Tags pro URL. Jede Seite, die einen relevanten Teil ihres indexierbaren Textes verloren hat, ist verdächtig. Diesen Content wiederherzustellen ist oft der schnellste einzelne Gewinn, und er ist zentral für laufendes Shopify SEO.

Ursache drei, JavaScript-Rendering und verlorene strukturierte Daten

Moderne Shopify Themes und Headless-Builds setzen stark auf JavaScript, und das ändert, wie Google die Seite sieht. Clientseitig eingefügter Content, oder Content hinter einer Interaktion, wird womöglich nicht mit demselben Gewicht indexiert wie Content im initialen HTML. Hat dein Redesign wichtige Texte, Bewertungen oder Spezifikationen in eine skript-gerenderte Komponente verschoben, kann die Seite für einen Shopper vollständig und für einen Crawler dünn wirken. Zwei Dinge brechen am häufigsten:

• Indexierbarer Text. Text, der erst nach einem Klick oder nach dem Laden eines Skripts erscheint, kann abgewertet oder ganz übersehen werden.
• Strukturierte Daten. Produkt-Schema, Bewertungs-Markup und Breadcrumbs stammen oft vom alten Theme oder einer App, und ein Rebuild kann sie still verlieren. Verlierst du Rich Results, verlierst du Sterne-Bewertungen und Preis-Snippets, das senkt die Klickrate, selbst wenn sich die Positionen kaum bewegen.

Diagnostiziere beides mit der URL-Prüfung. Sieh dir das gerenderte HTML eines wichtigen Produkts an und bestätige, dass dein wichtiger Text nach dem Rendern vorhanden ist, und schicke dieselbe URL durch den Rich Results Test, um zu bestätigen, dass das Schema weiterhin valide ist. Fehlt im gerenderten HTML Content, den die alte Seite hatte, ist das deine Regression.

Ursache vier, kaputte interne Verlinkung und Navigationstiefe

Interne Links sagen Google, welche Seiten wichtig sind und wie sie zusammenhängen, und ein Redesign schreibt die Navigation komplett neu. Ein vereinfachtes Mega-Menü, ein ausgedünnter Footer oder entfernte Breadcrumbs können still Seiten verwaisen lassen, die früher einen Klick von der Startseite entfernt waren. Seiten, die auf vier oder fünf Klicks Tiefe rutschen, werden seltener gecrawlt und schlechter geranked, weil Crawl-Budget und interner PageRank mit der Tiefe beide dünner werden.

Diagnostiziere es, indem du die neue Seite crawlst und nach Klicktiefe sowie Zahl der internen eingehenden Links sortierst, dann vergleiche die schlimmsten Fälle mit den Seiten, die Rankings verloren haben. Die Überschneidung ist deine Antwort. Baue die wichtigen Pfade neu auf: Kategorielinks zurück in Header oder Footer, kontextuelle Links in Collection- und Blog-Content wiederherstellen und Breadcrumbs behalten, wenn das alte Theme sie hatte.

Ursache fünf, Indexierbarkeit (noindex, robots.txt, Canonicals)

Die schädlichsten Bugs sind die, die Google fernhalten, und sie verstecken sich gut, weil die Seiten für Besucher perfekt laden. Drei Regressionen machen die meisten aus:

• Ein übrig gebliebenes noindex. Staging- und Preview-Builds stehen häufig auf noindex, und diese Direktive kann den Weg in die Produktion überleben. Ein einziges noindex auf Template-Ebene kann einen ganzen Seitentyp über Nacht deindexieren.
• Ein robots.txt Disallow. Eine Sperre, die während der Entwicklung die unfertige Seite aus dem Index halten sollte, kann live gehen und das Crawling abschneiden.
• Canonical-Fehler. Die Canonical-Logik eines neuen Themes kann Seiten auf die falsche URL oder auf die Startseite zeigen, was sie aus dem Index konsolidiert. Googles eigene Fehlerbehebung nennt eine nicht-kanonische Seite als führenden Grund, warum eine Seite aus den Ergebnissen verschwindet.

Diagnostiziere mit der URL-Prüfung an einer Stichprobe je Seitentyp, lies den Bericht zur Seitenindexierung auf einen Sprung bei „Durch noindex-Tag ausgeschlossen“ oder „Durch robots.txt blockiert“ und bestätige, dass jede wichtige Seite sich selbst als Canonical meldet. Das sind meist Ein-Zeilen-Fixes mit überproportionaler Erholung.

Ursache sechs, eine Core-Web-Vitals-Regression durch ein schwereres Theme

Speed ist ein Ranking-Signal, und ein Redesign ist der Ort, an dem er zurückfällt, weil neue Themes mit größeren Hero-Medien, mehr Fonts, Animationsbibliotheken und App-Skripten kommen. Es ist üblich, dass ein Shop mit ein paar Dutzend Apps fünfzehn oder mehr externe Skripte auf jeder Seite lädt, und jedes konkurriert um den Main Thread. Google misst drei Feldmetriken von echten Chrome-Nutzern am 75. Perzentil über ein rollierendes 28-Tage-Fenster, eine Regression braucht also Wochen, um voll sichtbar zu werden, und Wochen, um voll zu verschwinden. Die Core Web Vitals Schwellenwerte sind präzise:

INP hat First Input Delay am 12. März 2024 abgelöst und ist heute die Metrik, an der die meisten Seiten scheitern. Für Shopify ist das relevant, weil die Seiten, die bei INP am meisten kämpfen, genau die kommerziellen sind: ein Varianten-Selektor, der hakt, ein Add-to-Cart-Button, der langsam reagiert, oder eine gefilterte Collection, die stockt, alle führen JavaScript auf dem Main Thread aus. Der HTTP Archive Web Almanac 2025 fand, dass rund 76 Prozent der Shopify-Origins alle drei Core Web Vitals mobil bestanden, gegenüber etwa 35 Prozent der WooCommerce-Origins. Shopify startet also vorn, und ein schweres Redesign ist einer der schnellsten Wege, diesen Vorsprung wieder abzugeben.

Diagnostiziere mit dem Core-Web-Vitals-Bericht in der Search Console und bestätige mit Felddaten in PageSpeed Insights, nicht mit Laborwerten. Erholung ist realistisch: Rakutens auf web.dev dokumentierte Core-Web-Vitals-Arbeit brachte 33 Prozent mehr Conversion Rate, ohne kompletten Rebuild. Ist ein schwereres Theme die Ursache, isoliert ein fokussiertes Shopify PageSpeed Audit die störenden Assets, und die web.dev Referenz erklärt, warum die Latte am 75. Perzentil liegt.

Ursache sieben, kaputtes hreflang bei internationalen Shops

Betreibst du sowohl einen DE- als auch einen EN-Storefront, kann ein Redesign die hreflang-Paarung zerbrechen, die Google sagt, welche Sprachversion welcher Zielgruppe auszuliefern ist. Das zeigt sich in der Länder-Aufschlüsselung aus Schritt zwei als ein auf einen Markt begrenzter Einbruch. Zwei Fehlerbilder dominieren:

• Fehlende oder einseitige Tags. Jede Version muss sich selbst und ihr Gegenstück referenzieren. Zeigt die EN-Seite auf DE, DE aber nicht zurück, ignoriert Google das Paar womöglich und lässt die Versionen konkurrieren.
• Falsches Locale-Routing. Bei einem Multi-Store- oder Multi-Domain-Setup kann ein Redesign das Routing ändern, das ein Locale seinen URLs zuordnet, sodass die falsche Sprache rankt.

Diagnostiziere, indem du nach hreflang-Annotationen crawlst und reziproke Tags mit korrekten Sprach- und Regionscodes bestätigst. Die Korrektur stellt die Aufteilung sauber wieder her, meist innerhalb eines Crawl-Zyklus.

Eine Diagnose-Sequenz für einen Nachmittag

Behandle den Einbruch als Incident, nicht als Marketing-Aufgabe, dann fühlt er sich nicht mehr überwältigend an:

1. Bestimme einen Verantwortlichen. Eine Person hält die Untersuchung, damit Erkenntnisse nicht über drei Postfächer verstreuen.
2. Schreibe das Changelog. Liste alles auf, was am Launch live ging: Theme, Apps, URL-Änderungen, Template-Edits, Tag-Änderungen.
3. Arbeite die Checks der Reihe nach ab. Halte bei der ersten bestätigten Ursache an, statt über alle zu raten.

Diese Tabelle ordnet das Symptom der wahrscheinlichen Ursache und dem Tool zu, das sie bestätigt.

Arbeite sie von oben nach unten ab. Die meisten Einbrüche nach einem Redesign lösen sich in den ersten drei Zeilen, und ein strukturiertes SEO Audit folgt genau dieser Reihenfolge, wenn das interne Team nicht mehr weiterkommt.

Wie lange die Erholung wirklich dauert

Setze Erwartungen, bevor du irgendetwas behebst, denn der größte Fehler nach einem Redesign ist, weiter Dinge zu ändern, während Google noch neu verarbeitet. Verschiedene Fixes erholen sich auf verschiedenen Uhren:

Die Disziplin ist einfach. Behebe die bestätigte Ursache, fordere Recrawls für die wichtigen Seiten an, dann halte still und miss, statt neue Änderungen zu stapeln, die das Signal vernebeln.

Fazit

Ein Redesign, das Rankings verlor, scheiterte nicht, weil die neue Seite hässlich ist. Es scheiterte, weil etwas im Rebuild die Kontinuität brach, auf die Google sich verließ: eine URL, ein Textblock, ein Rendering-Pfad, ein Link, eine Index-Direktive oder ein Speed-Budget. Jedes davon ist in der Search Console und einem Crawler sichtbar, und jedes ist behebbar, sobald du den Einbruch eingegrenzt und die Checks der Reihe nach abgearbeitet hast. Bestätige, dass der Verlust echt ist, grenze seine Form ein, schließe ein Update aus, dann folge den sieben Ursachen von der wahrscheinlichsten zur unwahrscheinlichsten für deine Art Rebuild. Finde die konkrete Änderung, behebe sie und lass Google neu crawlen.