Redirects bei einem Shopware-Relaunch

Bei jedem Relaunch kommt die Frage zu spät: „Woher bekommen wir eigentlich die Liste der alten URLs?" Meist wird sie gestellt, wenn die neue Seite schon steht und der Traffic um dreißig Prozent eingebrochen ist.

Dieser Text beschreibt zwei Dinge getrennt: was Shopware bei URL-Änderungen selbst erledigt, und was Sie selbst erledigen müssen. Die Trennlinie zwischen beiden ist der Ort, an dem die meiste Sichtbarkeit verloren geht.

Was Shopware selbst erledigt

Ändert sich innerhalb von Shopware eine URL — ein Produktname wird angepasst, eine Kategorie umbenannt, ein SEO-Template geändert —, verschwindet die alte URL nicht. Shopware verwaltet sie in der Tabelle seo_url weiter.

Der SeoUrlPersister setzt beim Neuaufbau nicht mehr gültige Einträge auf nicht-kanonisch, statt sie zu löschen:

UPDATE seo_url SET is_canonical = NULL WHERE id IN (…)

Beim nächsten Aufruf findet der SeoResolver den alten Pfad, erkennt an is_canonical, dass es nicht die aktuelle Form ist, und liefert den kanonischen Pfad mit — worauf die Storefront weiterleitet.

Das heißt für Sie: Interne Umbenennungen sind abgedeckt, solange die Einträge in seo_url nicht gelöscht werden. Ein „Aufräumen" dieser Tabelle ist deshalb keine gute Idee. Sie ist kein Datenmüll, sondern Ihre Weiterleitungshistorie.

Was Shopware nicht erledigt

Alles, was außerhalb von Shopware entstanden ist:

Diese URLs kennt Shopware nie. Sie stehen aber in Google, in Backlinks, in Lesezeichen und in E-Mails aus fünf Jahren.

Die vollständige Liste finden — nicht die Top-Liste

Der häufigste Fehler ist nicht Nachlässigkeit, sondern eine zu kleine Stichprobe. Bei unserem eigenen Website-Umzug hatten wir zunächst eine Liste von fünf alten URLs mit Traffic. Sie stammte aus der Top-Seiten-Ansicht der Search Console — und war deshalb unvollständig.

Die vollständige Seitentabelle ergab ein anderes Bild:

Das sind 19 Prozent der Klicks und 87 Prozent der Impressionen der gesamten Tabelle. Fünf URLs abzuarbeiten hätte den kleineren Teil erledigt.

Vier Quellen, die zusammen die Liste ergeben:

1. Search Console, vollständige Seitentabelle. Zeitraum auf 16 Monate stellen, Zeilen pro Seite hochsetzen, alles exportieren. Nicht die Top-Ansicht verwenden.
2. Serverlogs des alten Systems. Sie enthalten auch URLs ohne Impressionen — etwa solche aus E-Mails und Lesezeichen.
3. Das Webarchiv. Über die CDX-Schnittstelle lässt sich der historische URL-Bestand einer Domain abfragen. Wir haben so den Slugbestand des alten Blogs abgesichert, statt ihn zu erraten.
4. Die Sitemap des alten Systems, falls sie noch existiert oder archiviert ist.

Punkt 3 hat bei uns den Unterschied gemacht: Er lieferte den vollständigen Slugbestand samt Umlautschreibweisen. Damit ließ sich sicherstellen, dass keine Regel per Weiterleitung auf eine 404 zeigt.

Die Regeln schreiben

Vier Grundsätze, die wir in unserem eigenen Regelsatz durchgehalten haben:

Nur 301. Kein 302, kein Meta-Refresh, kein JavaScript-Redirect. Ein Relaunch ist dauerhaft, und nur 301 sagt das.

Genau ein Sprung. Jede alte Form muss direkt am Ziel landen. Ketten entstehen fast von selbst — etwa wenn eine Regel für /alt/ auf /neu/ zeigt und eine allgemeine Regel danach den Schrägstrich entfernt. Deshalb gehören spezifische Regeln vor allgemeine, und jede Regel sollte den Schrägstrich am Ende gleich mit abdecken.

Keine Weiterleitung auf eine 404. Das klingt selbstverständlich und ist der häufigste Fehler bei Sammelregeln. Eine Regel wie ^/blog/(.+)$ → /wissen/$1 sieht elegant aus und produziert für jeden Slug, den es nicht mehr gibt, einen 301 auf eine 404. Besser: bekannte Slugs aufzählen, Unbekanntes auf die Übersicht auffangen.

Sinnvolle Ziele. Eine alte Produktseite gehört auf das Nachfolgeprodukt oder in die passende Kategorie, nicht auf die Startseite. Pauschale Startseiten-Weiterleitungen wertet Google in der Regel wie eine 404 — mit dem Nachteil, dass Sie es nicht in Ihren Berichten sehen.

Der Test, der zählt

Ein Regelsatz gilt erst dann als fertig, wenn er gemessen ist. Wir prüfen je URL vier Werte:

Dazu drei Gegenproben, die genauso wichtig sind:

• Alle heutigen URLs müssen weiterhin ohne Sprung mit 200 antworten. Ein Regelsatz, der alte URLs rettet und dabei eine aktuelle Seite verdeckt, ist kein Fortschritt.
• Unbekannte URLs müssen weiterhin 404 antworten. Wer alles auffängt, verliert die Fähigkeit, echte Fehler zu bemerken.
• Schrägstrich-Varianten beider Gruppen prüfen.

In unserem Fall waren das 336 Pfade in vier Gruppen. Der Lauf dauert wenige Minuten und ist der Unterschied zwischen „sollte passen" und „ist gemessen".

Vor dem Ausrollen lässt sich derselbe Test lokal fahren: Webserver im Container starten, die echte Konfigurationsdatei und das echte Build-Verzeichnis einhängen, Testsuiten laufen lassen. Fehler in der Regelsyntax fallen dort auf, statt in Production.

Eine Falle bei Sonderzeichen

Alte Systeme haben oft Umlaute in URLs. Der Webserver sieht sie dekodiert als UTF-8, das Werkzeug, mit dem Sie die Regeln eintragen, behandelt sie möglicherweise anders. Wir haben das umgangen, indem die Regeln auf einem eindeutigen ASCII-Präfix greifen statt auf der vollständigen Zeichenkette. Das trifft die Umlaut- wie die umschriebene Form und übersteht jeden Editor.

Und noch eine Falle aus derselben Arbeit: Regeln, die eine Zeichenklasse mit geschweiften Klammern enthalten, müssen in nginx in Anführungszeichen stehen. Sonst hält der Parser die Klammer für einen Blockanfang und die Konfiguration lädt nicht.

Reihenfolge im Projekt

1. URL-Bestand aus allen vier Quellen sammeln — vor dem Umzug
2. Zielseite je alter URL bestimmen, fachlich, nicht automatisch
3. Zielseiten auf Erreichbarkeit prüfen, bevor eine Regel darauf zeigt
4. Regeln schreiben, spezifisch vor allgemein
5. Lokal gegen die echte Konfiguration testen
6. Ausrollen
7. Production messen — alte URLs, aktuelle URLs, unbekannte URLs
8. Search Console beobachten: der Bericht „Nicht gefunden (404)" ist danach die laufende Kontrolle

Punkt 1 ist der einzige, der sich nicht nachholen lässt, ohne Daten zu verlieren: Die Search Console zeigt Daten aus 16 Monaten. Wer ein Jahr nach dem Umzug anfängt, sieht die alte Struktur nur noch teilweise.

Woher unsere Zahlen stammen

Die Messwerte oben stammen aus unserem eigenen Website-Umzug, nicht aus einem Kundenprojekt — deshalb dürfen sie hier stehen. Die Zielarchitektur war eine statische Auslieferung, nicht Shopware; die Shopware-spezifischen Angaben zu seo_url und SeoResolver haben wir separat in einer laufenden 6.7.13.1-Installation nachgelesen.

Wenn ein Relaunch ansteht und Sie wissen möchten, wie groß Ihr URL-Bestand tatsächlich ist: Die Search-Console-Auswertung ist der erste Schritt und kostet einen Nachmittag. Shopware-Agentur beschreibt, wie wir solche Projekte aufsetzen, SEO-Agentur den Teil, der danach kommt.