Redirects im E-Commerce: das vollständige Kompendium

1. Grundlagen: was ein Redirect ist und wo er greift

Ein Redirect ist eine Anweisung, dass eine angeforderte URL nicht mehr (oder nicht jetzt) den Inhalt liefert, sondern der Client an eine andere URL geschickt wird. Entscheidend ist wo im Request-Lebenszyklus das passiert, denn davon hängen Geschwindigkeit, SEO-Wirkung und Zuverlässigkeit ab:

• Serverseitig (HTTP-Statuscode): Der Server antwortet auf die Anfrage direkt mit einem 3xx-Status und einem Location-Header. Der Browser folgt sofort, noch bevor eine Seite gerendert wird. Das ist die sauberste, schnellste und für Suchmaschinen eindeutigste Variante.
• CDN / Edge: Der Redirect wird vorgelagert am Rand des Netzwerks entschieden, bevor der Ursprungsserver überhaupt kontaktiert wird — ideal für Domain-Kanonisierung (http→https, www) und großvolumige Regel-Sets, weil er Latenz spart.
• Client-seitig (Meta-Refresh, JavaScript): Erst wird eine Seite geladen, dann weist deren Markup oder Skript den Browser an weiterzuleiten. Das ist langsamer (zwei Ladevorgänge), fehleranfällig (JS muss ausführen) und für Suchmaschinen ein schwächeres Signal.

Merksatz: Je früher im Lebenszyklus der Redirect greift, desto besser. Serverseitig oder Edge schlägt client-seitig fast immer.

2. Die Varianten — mit Wirkung je Typ

HTTP-Statuscodes im Vergleich

Die 3xx-Codes unterscheiden sich in drei Dimensionen, die im E-Commerce zählen: permanent vs. temporär (welche URL bleibt maßgeblich?), Methoden-Erhalt (bleibt ein POST ein POST?) und Caching (merkt sich der Browser die Weiterleitung?).

Zwei Punkte werden in der Praxis regelmäßig falsch verstanden. Erstens der Methoden-Erhalt: 301 und 302 führten historisch häufig dazu, dass Clients ein POST beim Folgen auf ein GET umschrieben; 303 erzwingt das sogar. 307 und 308 erhalten Methode und Body — deshalb sind sie das richtige Werkzeug, wenn ein Formular- oder API-Endpunkt umzieht, der ein POST entgegennimmt. [Quelle: MDN — HTTP redirects; RFC 9110 (HTTP Semantics), 308 in RFC 7538.] Zweitens das SEO-Signal: Ein serverseitiger 301 ist das stärkste, eindeutigste Signal für einen permanenten Umzug; Google folgt auch 302/303/307/308 sowie Meta-Refresh- und JS-Redirects, verarbeitet client-seitige aber langsamer und schwächer. [Quelle: Google Search Central — Redirects and Google Search.]

Client-seitige Redirects: Meta-Refresh und JavaScript

Ein <meta http-equiv="refresh"> oder ein window.location-Redirect funktioniert für den Nutzer, ist aber operativ die schlechteste Wahl: Es braucht einen kompletten ersten Ladevorgang, bevor die Weiterleitung startet (Latenz, oft sichtbares Flackern), es scheitert, wenn JavaScript nicht ausführt, und Suchmaschinen behandeln es als schwächeres Signal als einen sauberen HTTP-301. Für dauerhafte Umzüge ist es nie die erste Wahl — es ist der Notnagel, wenn man keinen Server-Zugriff hat.

Sonderfälle: Ketten, Loops und Soft-404

• Redirect-Kette (chain): A → B → C. Jeder Hop kostet einen Roundtrip und Crawl-Aufwand. Regel: immer direkt auf das Endziel mappen, nie auf die nächste Zwischenstufe. Ketten entstehen schleichend, wenn man über Jahre Redirect auf Redirect legt.
• Redirect-Schleife (loop): A → B → A. Der Browser bricht nach einigen Hops mit einer Fehlermeldung ab — die Seite ist praktisch tot. Entsteht häufig durch widersprüchliche Regeln (z. B. www-Erzwingung und trailing-slash-Regel, die gegeneinander arbeiten).
• Soft-404 statt Redirect: Eine gelöschte Produktseite antwortet mit Status 200 (oder wird pauschal auf die Startseite umgeleitet), obwohl der Inhalt weg ist. Google erkennt das als Soft-404 und indexiert es nicht sinnvoll. Richtig ist ein 301 auf ein relevantes Ziel oder ein sauberer 404/410, wenn es kein Äquivalent gibt.

Kanonisierungs-Redirects

Jede Seite sollte unter genau einer URL erreichbar sein. Kanonisierungs-Redirects erzwingen das per 301 auf die eine kanonische Form:

• http → https (Sicherheit + Ranking-Basissignal)
• www vs. non-www — eine Variante wählen, die andere dauerhaft weiterleiten
• Trailing Slash — /schuhe vs. /schuhe/ konsistent halten
• Groß-/Kleinschreibung — /Schuhe vs. /schuhe
• Query-Parameter-Reihenfolge und Tracking-Parameter, die Duplikate erzeugen

Wo eine Variante nur eine alternative Zugangsform derselben Seite ist (z. B. Parameter-Wildwuchs), ist oft ein rel=canonical das mildere Werkzeug als ein harter Redirect — dazu unten mehr.

Geo-/IP-/Sprach-Redirects

Der Reflex, Besucher automatisch anhand ihrer IP in „ihre" Länder- oder Sprachversion umzuleiten, schadet mehr, als er nutzt. Google rät ausdrücklich von automatischer Weiterleitung anhand vermuteter Herkunft ab, weil Nutzer und Crawler dadurch nicht alle Versionen erreichen; da Googlebot überwiegend aus US-IP-Bereichen crawlt, macht ein Geo-Redirect andere Länderversionen für den Crawler faktisch unsichtbar. [Quelle: Google Search Central — Managing multi-regional and multilingual sites.] Das korrekte Werkzeug ist hreflang plus ein sichtbarer, aber nicht erzwingender Länder-/Sprach-Selector. Wie sauberes hreflang aussieht und wann sich ein Sub-Locale-Split lohnt, haben wir in hreflang je Sub-Locale in Shopify im Detail beschrieben.

Redirect vs. Canonical vs. hreflang — wann was

Diese drei werden gern verwechselt, tun aber Unterschiedliches:

• Redirect (301): „Diese URL gibt es so nicht mehr, geh dorthin." Für echte Umzüge — der Nutzer landet auf einer anderen URL.
• rel=canonical: „Diese URL existiert, aber die maßgebliche Version ist eine andere." Für Duplikate/Varianten, die erreichbar bleiben sollen (Parameter, Filter, Print-Ansicht).
• rel=alternate / hreflang: „Diese Seiten sind gleichwertige Sprach-/Regions-Varianten." Kein Umzug, keine Rangordnung — nur Zuordnung, damit sich Varianten nicht kannibalisieren.

3. Impacts — was das Ignorieren verursacht

Der Grund, warum Redirects unterschätzt werden: Der Schaden ist selten sofort sichtbar. Er akkumuliert über Wochen als Ranking-Erosion, verlorene Klicks und kaputte Attribution — bis der Umsatz sinkt und niemand die Ursache im URL-Layer sucht.

• SEO / Link-Equity: Fehlt der Redirect, verpufft das über Jahre aufgebaute Ranking-Signal der alten URL (alte URL → 404). Ein 302 statt 301 lässt das Signal an der alten URL hängen; Ketten verzögern die Übertragung. Zwar verlieren 3xx-Redirects laut Google selbst keinen PageRank mehr — aber nur, wenn sie korrekt gesetzt sind.
• Crawl-Budget: Ketten und Loops verschwenden Crawl-Ressourcen, die Google in deine wichtigen Seiten stecken sollte, und verlangsamen das Neu-Indexieren nach einer Migration — kritisch, wenn zehntausende URLs auf einmal umziehen.
• UX & Conversion: Jeder Hop kostet Zeit; ein 404 auf einem Deep-Link aus einem Newsletter oder einer Ad bricht die Customer Journey genau im teuersten Moment — nach dem bereits bezahlten Klick.
• Performance / Core Web Vitals: Jeder Redirect ist ein zusätzlicher Request-Response-Zyklus, der das Rendern der Zielseite verzögert und TTFB erhöht; Ketten multiplizieren diese Latenz. Lighthouse führt „Avoid multiple page redirects" genau deshalb als Performance-Problem. [Quelle: Chrome / Lighthouse — Avoid multiple page redirects.]
• Tracking / Analytics: Redirects, die Query-Strings nicht sauber weiterreichen, verlieren UTM-Parameter und Klick-IDs (gclid/fbclid) — die Folge ist gebrochene Attribution, auch auf Meta- und Google-Ads-Landingpages, für die du gerade bezahlst.
• Security (Open Redirect): Ein Redirect, dessen Ziel aus einem unvalidierten Parameter stammt (z. B. ?return_url=, Redirect nach Login), lässt sich für Phishing missbrauchen — Angreifer hängen ein fremdes Ziel an eine vertrauenswürdige Domain. Redirect-Ziele deshalb immer gegen eine Allowlist prüfen. [Quelle: OWASP — Unvalidated Redirects and Forwards.]

4. Klassische Fehler-Szenarien im E-Commerce

• Migration ohne 301-Mapping: Replatforming auf Shopify, aber die alten URL-Muster (andere Pfade, andere Handle-Struktur) werden nicht gemappt — tausende alte URLs laufen ins 404, das über Jahre aufgebaute Ranking bricht ein. Der teuerste und häufigste Fehler überhaupt.
• Handle-Änderung ohne Redirect: Ein Produkt oder eine Collection wird umbenannt, der Handle ändert sich, die alte URL ist tot — inklusive aller externen Links und Ad-Deep-Links, die darauf zeigen.
• Saisonale Kampagnen-URLs, die ins Leere laufen: Eine /black-friday-Landingpage wird nach der Aktion gelöscht statt auf die passende Collection weitergeleitet — der Newsletter aus dem Vorjahr und alte Ads führen ins Nichts.
• Markt-/Sprach-Umschaltung, die Deep-Links killt: Beim Aktivieren von Markets oder Locales werden Deep-Links pauschal auf die Startseite geworfen statt auf das Äquivalent in der Zielsprache — ein Soft-404-Muster, das Ranking und Conversion kostet.

5. Shopify-Spezifika

Shopify bietet native URL-Weiterleitungen im Admin (Online-Store → Navigation → URL-Weiterleitungen) inklusive CSV-Bulk-Import; beim Ändern eines Produkt- oder Seiten-Handles bietet der Admin an, automatisch eine Weiterleitung von der alten URL anzulegen — dieses Häkchen sollte man nie übersehen. [Quelle: Shopify Help Center — URL redirects.] Grenzen und Fallstricke der nativen Lösung:

• Nur auf der Shop-Domain: Native Redirects greifen auf deiner Storefront-Domain, nicht auf myshopify.com-URLs oder externen Zielen — für Domain-Kanonisierung braucht es die DNS-/Domain-Ebene.
• Bulk bei großen Katalogen: Bei Migrationen mit zehntausenden URLs stößt die manuelle Pflege an Grenzen; der CSV-Import bzw. App-basierte Bulk-Redirects sind dann Pflicht, ebenso ein sauber vorbereitetes Mapping.
• /collections/all und Handle-Struktur: Shopifys feste Pfad-Präfixe (/products/, /collections/) bedeuten, dass ein Import von einem anderen System praktisch immer ein Pfad-Mapping braucht — 1:1-URL-Übernahme ist selten möglich.
• Markets/Locale-Pfade: Länder-/Sprach-Subfolder (/de, /en-gb) verändern die URL-Struktur; Redirects müssen die Locale erhalten, nicht verwerfen. Das greift direkt in die Internationalisierung — Markets, Preise & Merchant Center zeigt, wie eng URL-, Feed- und Ranking-Ebene zusammenhängen.

6. Best Practices — Entscheidungsbaum & Checklisten

Entscheidungsbaum: welcher Redirect wann

• Ist der Umzug dauerhaft?
  • Ja, und es ist eine normale Seiten-URL (GET) → 301.
  • Ja, aber es ist ein POST-/API-Endpunkt (Methode muss erhalten bleiben) → 308.
• Ist der Umzug temporär (alte URL bleibt maßgeblich)?
  • Normale Seite → 302.
  • POST-Endpunkt, Methode erhalten → 307.
  • Nach einem POST auf eine Ergebnisseite (GET erzwingen) → 303.
• Existiert die Seite noch, aber unter mehreren erreichbaren URLs (Parameter, Filter)? → kein Redirect, sondern rel=canonical.
• Sind es gleichwertige Sprach-/Regions-Varianten? → kein Redirect, sondern hreflang (+ Selector, kein Geo-Zwang).
• Gibt es kein passendes Ziel mehr? → sauberer 404/410, nicht pauschal auf die Startseite (das wäre ein Soft-404).

Migrations-Checkliste (Replatforming / Domain-Wechsel)

1. Vollständige URL-Inventur der alten Site: Crawl + Server-Logs + Sitemap + Search-Console-Export, um jede indexierte und jede Traffic-tragende URL zu erfassen.
2. Redirect-Map erstellen: jede alte URL → genau ein sinnvolles neues Ziel (nicht pauschal Startseite). Prioritär: Seiten mit Rankings, Backlinks und Ad-Traffic.
3. Nur 301 für den dauerhaften Umzug — keine 302 auf Migrationen.
4. Ketten auflösen: jede Regel zeigt direkt auf das finale Ziel, nicht auf eine andere weiterzuleitende URL.
5. Query-/Tracking-Parameter erhalten, damit UTM- und Klick-IDs die Attribution nicht verlieren.
6. Kanonisierung sicherstellen: http→https, www-Variante, trailing slash, Groß-/Kleinschreibung konsistent per 301.
7. Testen vor Go-Live:Statuscode-Stichproben (erwartet 301, nicht 302/404), keine Loops, keine Ketten > 1 Hop.
8. Nach Go-Live überwachen: 404-Spitzen in Logs/Search-Console, neue Ketten nach Deployments, Sitemap neu einreichen, Ranking- und Traffic-Kurven beobachten.

Laufendes Monitoring

Redirects sind kein einmaliges Projekt. Handle-Änderungen, neue Collections und Kampagnen erzeugen fortlaufend neue 404-Risiken. Ein wiederkehrender Statuscode-Check auf den wichtigsten URLs plus ein Alarm bei 404-Spitzen nach Deployments hält die Redirect-Landschaft gesund — genau die Disziplin, die den Unterschied zwischen einem stabilen und einem langsam erodierenden Shop ausmacht.

Die kurze Version

Serverseitiger 301 für dauerhafte Umzüge, 307/308 wenn eine Methode erhalten bleiben muss, 302 nur für echte Temporär-Fälle. Ketten und Loops vermeiden, immer direkt aufs Endziel mappen. Kein Geo-Zwang — hreflang statt Redirect. Bei jeder Migration eine vollständige Redirect-Map, nur 301, und ein Monitoring danach. Der Redirect selbst kostet fast nichts; sein Fehlen kostet Rankings, bezahlte Klicks und Attribution.

Ihr steht vor einem Replatforming, ändert Handles im großen Stil oder vermutet, dass alte URLs still ins Leere laufen? Wir erstellen das 301-Mapping, auditieren Ketten und Loops, richten die Redirect-Map für die Migration ein und setzen ein laufendes Statuscode-Monitoring auf. Gespräch anfragen. Weiter im Kontext: Shopify-Technik & Performance und operative Internationalisierung.