SEO-URLs in Shopware: Vorlagen planen, Adressen sichern

Die SEO-URL-Vorlagen in Shopware legen fest, aus welchen Bestandteilen die Adresse jeder Produktseite, jeder Kategorie und jeder Landingpage entsteht. Eingerichtet werden sie oft beim Start des Shops und danach kaum noch angefasst. Das geht gut, bis jemand die Vorlage ändert: Nach dem Neuaufbau des Index bekommt dann jede betroffene Seite auf einen Schlag eine neue Adresse. Dieser Leitfaden zeigt, welche Variablen sich für dauerhafte Adressen eignen, wie Länge, Schreibweise, Varianten und Kategoriepfade zusammenspielen und wie eine Änderung abläuft, ohne dass Besucher und Suchmaschinen auf toten Adressen landen. Grundlage sind die Shopware-Dokumentation, der Shopware-Quelltext und die Empfehlungen von Google Search Central. Wer die Vorlagen im Rahmen einer technischen SEO-Betreuung prüfen lassen möchte, findet am Ende einen Überblick, wie wir dabei vorgehen.

Was eine SEO-URL-Vorlage in Shopware festlegt

Die Vorlagen stehen in der Administration unter den Einstellungen im Bereich SEO. Dort gibt es drei Felder: eines für die Produktdetailseite, eines für die Landingpage und eines für die Kategorieseite (Shopware-Dokumentation). Über die Auswahl des Verkaufskanals legen Sie fest, ob eine Vorlage für alle Verkaufskanäle gilt oder nur für einen bestimmten (Shopware-Dokumentation). Die Variablen stehen dabei in doppelten geschweiften Klammern, etwa {{ product.translated.name }}, denn die Vorlagen arbeiten mit der Template-Sprache Twig.

Beachte hierbei, dass die Variablen im Twig-Format angegeben werden müssen.

Shopware-Dokumentation, SEO-Einstellungen

Neben jedem Feld zeigt die Administration an, ob sich die Variablen auflösen lassen: ein grüner Haken für korrekte Variablen, ein rotes X für mindestens eine Variable, die sich nicht auflösen lässt; dann lässt sich die Einstellung erst nach einer Korrektur speichern (Shopware-Dokumentation). Über die Folgen für bestehende Adressen sagt der Haken nichts.

Ab Werk setzt Shopware für Produkte die Vorlage {{ product.translated.name }}/{{ product.productNumber }} ein, für Kategorien den Kategoriepfad über {% for part in category.seoBreadcrumb %}{{ part }}/{% endfor %} und für Landingpages die dort gepflegte Adresse über {{ landingPage.translated.url }} (Shopware-Quelltext).

Bevor eine Adresse gespeichert wird, schickt Shopware jeden ausgegebenen Wert durch eine Slug-Funktion und kodiert ihn für die Adresse (Shopware-Quelltext). Welche Zeichen dabei genau entstehen, hängt von der Konfiguration der Installation ab; ein Blick auf einige echte Produktadressen des Shops zeigt es am schnellsten.

Warum eine Vorlagenänderung den ganzen Katalog betrifft

Shopware erzeugt die Adressen nicht erst beim Seitenaufruf, sondern schreibt sie in die Tabelle seo_url: je Seite, Sprache und Verkaufskanal eine Zeile mit dem lesbaren Pfad und einer Markierung, welche Adresse aktuell gilt (Shopware-Quelltext). Nach einer Änderung an der Vorlage ist es laut Dokumentation erforderlich, den Index neu aufzubauen, damit die Adressen aktualisiert werden (Shopware-Dokumentation). Dieser Lauf rechnet die Adressen aller Seiten neu, auf die die Vorlage wirkt.

Ergibt die Vorlage für eine Seite einen anderen Pfad als bisher, legt Shopware eine neue Zeile als gültige Adresse an und nimmt der alten Zeile die Markierung (Shopware-Quelltext). Die alte Zeile bleibt in der Tabelle stehen, Shopware weiß also weiterhin, zu welcher Seite eine alte Adresse gehört. Was beim nächsten Aufruf dieser Adresse passiert, regelt eine Einstellung, die weiter unten beschrieben ist.

Für Suchmaschinen ist eine solche Umstellung ein Umzug innerhalb derselben Domain. Google zählt geänderte Pfade ausdrücklich zu den Website-Umzügen mit geänderten URLs und rechnet bei größeren Änderungen mit schwankenden Rankings, während die Seiten neu gecrawlt und indexiert werden (Google Search Central). Bei kleinen bis mittelgroßen Websites kann es nach Googles Angaben einige Wochen dauern, bis die meisten Seiten umgezogen sind; größere Websites brauchen länger (Google Search Central). Eine Vorlagenänderung ist deshalb kein Handgriff für zwischendurch, sondern ein kleines Migrationsprojekt.

Variablen wählen: stabil, eindeutig, lesbar

Die Dokumentation listet für Produkte eine lange Reihe von Variablen auf. Zu den übrigen verfügbaren Variablen gibt Shopware einen deutlichen Hinweis: Sie liefern Inhalte, die zu regelmäßigen Änderungen der URL führen, und das beeinflusst das Ranking negativ (Shopware-Dokumentation). Bei Landingpages und Kategorien empfiehlt Shopware ausdrücklich, solche Variablen nicht zu verwenden (Shopware-Dokumentation). Die Auswahl folgt deshalb einer Frage: Ändert sich dieser Wert nur, wenn jemand ihn bewusst ändert?

Google empfiehlt außerdem, in der Adresse Wörter in der Sprache der Zielgruppe zu verwenden, bei einem deutschsprachigen Publikum also deutsche Wörter (Google Search Central). product.translated.name erfüllt das, weil Shopware die Adressen je Sprache erzeugt und dabei den übersetzten Namen einsetzt. Wer einen optionalen Wert wie den Hersteller voranstellen möchte, sichert ihn so ab, dass Produkte ohne Hersteller trotzdem einen sauberen Pfad bekommen:

{# Werkseinstellung #}
{{ product.translated.name }}/{{ product.productNumber }}

{# Hersteller vorangestellt, nur wenn vorhanden #}
{% if product.manufacturer is not null %}{{ product.manufacturer.name }}/{% endif %}{{ product.translated.name }}/{{ product.productNumber }}

Länge, Schreibweise und Trennzeichen

Lange Produktnamen erzeugen lange Adressen. Die Dokumentation zeigt dafür eine Kürzung: Ist ein Produktname länger als beispielsweise 50 Zeichen, lässt er sich mit {{ product.translated.name[:50] }} in der Adresse kürzen (Shopware-Dokumentation). Die eckigen Klammern sind die Kurzschreibweise des Twig-Filters slice, der bei Zeichenketten mit der PHP-Funktion mb_substr arbeitet (Twig-Dokumentation).

Die Kürzung zählt also Zeichen, keine Wörter. Ein Name, bei dem an Stelle 50 gerade ein Wort läuft, endet in der Adresse mit einem Wortstumpf. Wer kürzt, sieht sich vorher die längsten Produktnamen an und wählt die Grenze so, dass die Adressen lesbar bleiben. Die Produktnummer am Ende hält die Adresse eindeutig, auch wenn mehrere Namen gleich beginnen.

Ein zweites Thema ist die Schreibweise. Wer die Adresse durchgängig klein schreiben möchte, setzt laut Dokumentation den Twig-Filter lower ein, bei Kategorien innerhalb der Schleife als {{ part|lower }} (Shopware-Dokumentation). Das ist mehr als Kosmetik: Google unterscheidet in Adressen zwischen Groß- und Kleinschreibung und behandelt /APPLE und /apple als zwei verschiedene URLs mit eigenem Inhalt (Google Search Central). Shopware dagegen vergleicht die Pfade in seo_url ohne Rücksicht auf die Schreibweise (Shopware-Quelltext). Ändert eine Vorlage nur die Schreibweise, überschreibt Shopware die bestehende Zeile, und die alte Schreibweise liefert die Seite ohne 301-Weiterleitung weiter aus (Shopware-Quelltext). Für Server, die beide Schreibweisen gleich behandeln, rät Google, alle Adressen einheitlich zu schreiben (Google Search Central). Beim Test der alten Adressen ist hier keine Weiterleitung zu erwarten.

{# Produkt: Name gekürzt, alles klein #}
{{ product.translated.name[:50]|lower }}/{{ product.productNumber|lower }}

{# Kategorie: Pfad klein #}
{% for part in category.seoBreadcrumb %}{{ part|lower }}/{% endfor %}

Für Trennzeichen empfiehlt Google Bindestriche statt Unterstrichen, weil Bindestriche eine Wortgrenze klar anzeigen (Google Search Central). Eigene Trenner zwischen Variablen sind deshalb Bindestrich oder Schrägstrich. Ein Schrägstrich in der Vorlage selbst bleibt erhalten, weil Shopware nur die ausgegebenen Werte durch die Slug-Funktion schickt (Shopware-Quelltext).

Varianten, Hauptkategorie und Kategoriepfade

Varianten sind in Shopware eigene Produkte und erhalten beim Indexieren eigene Adressen; die Aktualisierung der SEO-URLs geht dabei auch über die Varianten eines Hauptprodukts (Shopware-Quelltext). Mit der Produktnummer in der Vorlage bekommt jede Variante eine eindeutige Adresse. Ob diese Adressen alle in den Index sollen, ist eine eigene Entscheidung: Im SEO-Bereich eines Produkts mit Varianten lässt sich festlegen, dass alle Varianten dieselbe Canonical-URL verwenden, und auswählen, welche Variante sie stellt (Shopware-Dokumentation). Die Abwägung dahinter beschreibt unser Beitrag zur Produktvarianten-SEO.

Wer den Kategoriepfad in die Produktadresse holt, muss wissen, welche Kategorie gemeint ist. Die Dokumentation zeigt dafür einen Breadcrumb-Ausdruck, der die Kategorien des Produkts nach Position sortiert und die erste nimmt (Shopware-Dokumentation). Ist ein Produkt mehreren Kategorien zugeordnet, lässt sich im SEO-Bereich des Produkts je Verkaufskanal zusätzlich eine Hauptkategorie festlegen (Shopware-Dokumentation). Ohne eine klare Regel, welche Kategorie die Adresse bestimmt, kann die Produktadresse mit einer Umsortierung im Kategoriebaum wandern.

Für Kategorieseiten nutzt Shopware ab Werk den Breadcrumb, also die Kategoriestruktur (Shopware-Dokumentation). Das ergibt sprechende Adressen, die aber mit jeder Ebene länger werden und an den Namen aller Elternkategorien hängen: Benennt jemand eine Oberkategorie um, ändern sich die Adressen des ganzen Zweigs. Für Produkte zeigt die Dokumentation ein Beispiel, das die erste Kategorie über |slice(1) auslässt, etwa wenn sie nur Einstiegspunkt ist (Shopware-Dokumentation). Wie Saisonkategorien ohne Jahreszahl im Namen zum Jahreswechsel ihre Adresse behalten, beschreibt unser Beitrag zur Jahreszahl in Seitentitel und URL.

• Wie oft werden Kategorien im laufenden Betrieb umbenannt oder umgehängt?
• Liegen Produkte in mehreren Kategorien, und ist für jedes dieser Produkte eine Hauptkategorie gepflegt?
• Wie tief ist der Baum, und wie lang werden die Adressen der untersten Ebene?
• Gibt es Filter- oder Aktionskategorien, die nicht in eine dauerhafte Adresse gehören? Für Filteradressen hilft unser Beitrag zur Facettennavigation.

Was Shopware mit alten Adressen macht

Ruft jemand eine Adresse auf, die nicht mehr als gültig markiert ist, findet Shopware über die Tabelle seo_url weiterhin die zugehörige Seite und ermittelt deren aktuelle Adresse (Shopware-Quelltext). Was danach geschieht, regelt die Einstellung „Statt Canonical URLs direkt per HTTP 301 auf die aktuellste URL leiten“ in den SEO-Einstellungen. Sie ermöglicht es laut Dokumentation, bei geänderten URLs eine HTTP-301-Weiterleitung auszugeben; ist sie deaktiviert, erhält der Browser keinen Hinweis auf eine Weiterleitung (Shopware-Dokumentation).

Google stuft beide Wege als starkes Signal für die bevorzugte Adresse ein; die Weiterleitung steht in Googles Reihenfolge vor der Canonical-Angabe (Google Search Central). Soll eine Adresse in den Suchergebnissen dauerhaft durch eine andere ersetzt werden, empfiehlt Google eine dauerhafte serverseitige Weiterleitung; die Statuscodes 301 und 308 bedeuten, dass eine Seite dauerhaft an einen neuen Ort umgezogen ist (Google Search Central). Nach dem HTTP-Standard zeigt 301 an, dass der Ressource eine neue dauerhafte Adresse zugewiesen wurde und künftige Verweise eine der neuen Adressen nutzen sollten (RFC 9110). Genau das trifft auf eine Adresse zu, die eine Vorlagenänderung ersetzt hat; wir empfehlen deshalb, die Option vorher zu prüfen und in der Regel einzuschalten.

Eine Vorlagenänderung Schritt für Schritt

Eine Änderung an der Vorlage ist technisch eine Zeile in der Administration. Die eigentliche Arbeit liegt davor und danach. Bewährt hat sich diese Reihenfolge:

1. Bestand sichern. Alle aktuell gültigen Adressen mit Seitentyp, Sprache und Verkaufskanal aus seo_url exportieren. Diese Liste ist die Grundlage für den Vergleich und für die Tests danach.
2. In einer Testumgebung ändern. Die Vorlage auf einer Kopie des Shops anpassen, den Index neu aufbauen und die neuen Adressen exportieren. Eine solche Kopie sollte ohne echte Kundendaten auskommen, wie unser Beitrag zur Shopware-Staging-Umgebung beschreibt.
3. Alt und neu vergleichen. Beide Listen über Seite, Sprache und Verkaufskanal zusammenführen. Doppelte Pfade, leere Abschnitte, abgeschnittene Wörter und ungewollt lange Adressen fallen hier auf und nicht erst im Live-Shop.
4. Weiterleitung einschalten. Die Option „Statt Canonical URLs direkt per HTTP 301 auf die aktuellste URL leiten“ im Live-Shop prüfen und aktivieren, bevor sich die erste Adresse ändert.
5. Vorlage ändern und Index neu aufbauen. Die Vorlage global oder je Verkaufskanal setzen und den Index neu aufbauen; erst dieser Lauf aktualisiert die Adressen (Shopware-Dokumentation).
6. Alte Adressen testen. Die gesicherten Adressen aufrufen und prüfen, ob jede mit 301 auf die neue Adresse derselben Seite antwortet.
7. Sitemap und Search Console. Die Sitemap neu erzeugen, in der Search Console einreichen und danach den Bericht zur Seitenindexierung beobachten.

-- Aktuell gültige Adressen je Seite, Sprache und Verkaufskanal
SELECT
  route_name,
  LOWER(HEX(foreign_key))      AS page_id,
  LOWER(HEX(language_id))      AS language_id,
  LOWER(HEX(sales_channel_id)) AS sales_channel_id,
  seo_path_info,
  is_modified
FROM seo_url
WHERE is_canonical = 1
  AND is_deleted = 0
ORDER BY route_name, seo_path_info;

Der Befehl dal:refresh:index baut den Index neu auf; die Dokumentation nennt ihn ausdrücklich für den Fall einer geänderten Vorlage (Shopware-Dokumentation). Mit der Option --only lässt sich der Lauf auf einzelne Indexer beschränken (Shopware-Quelltext). Die SEO-Adressen von Produkten, Kategorien und Landingpages entstehen, wenn deren Indexer laufen (Shopware-Quelltext). Bei großen Katalogen gehört der Lauf in ein ruhiges Zeitfenster. Google empfiehlt für Umzüge ohnehin, sie nach Möglichkeit in verkehrsschwache Zeiten zu legen (Google Search Central).

Die Sitemap erzeugt Shopware je nach Strategie geplant, live oder nur auf Befehl; bei manueller Erzeugung ist sitemap:generate nach jeder Änderung an den Adressen erneut auszuführen (Shopware-Dokumentation). Das Einreichen der neuen Sitemap hilft Google, die neuen URLs zu finden (Google Search Central).

Nach der Umstellung: prüfen und beobachten

Ob die Umstellung gelungen ist, zeigt der Abgleich mit der gesicherten Liste. Jede alte Adresse sollte mit einer Weiterleitung auf genau die neue Adresse derselben Seite antworten, nicht auf die Startseite und nicht auf eine Kategorie. Google warnt davor, viele alte Adressen auf ein einzelnes, unpassendes Ziel wie die Startseite umzuleiten; das kann Nutzer verwirren und als Soft-404-Fehler behandelt werden (Google Search Central). Für eine Stichprobe genügt ein Abruf der Kopfzeilen:

Weiterleitungsketten entstehen bei Shopware selbst in der Regel nicht. Eine alte Adresse führt direkt zur aktuell gültigen, auch wenn die Vorlage mehrmals geändert wurde, weil Shopware für jede alte Zeile die aktuelle Adresse derselben Seite ermittelt (Shopware-Quelltext). Ketten entstehen dort, wo zusätzlich Regeln im Webserver oder aus einem früheren Umzug greifen und auf eine Adresse zeigen, die inzwischen selbst ersetzt ist. Googlebot folgt bis zu 10 Weiterleitungen in einer Kette, Google rät aber, direkt auf das endgültige Ziel umzuleiten (Google Search Central). Wo das nicht geht, sollten es möglichst nicht mehr als 3 und weniger als 5 Weiterleitungen sein (Google Search Central). Darum gehören auch Weiterleitungsregeln aus früheren Migrationen auf den Prüfstand, etwa aus einem Wechsel von WooCommerce zu Shopware.

Die Weiterleitungen sollten so lange bestehen bleiben wie möglich; Google nennt als Richtwert in der Regel mindestens ein Jahr, damit alle Signale auf die neuen Adressen übergehen können (Google Search Central). Bei Shopware heißt das praktisch: die alten Zeilen in seo_url stehen lassen und die Option eingeschaltet lassen.

In der Search Console erscheinen die alten Adressen nach und nach im Bericht zur Seitenindexierung als Seiten mit Weiterleitung. Das ist gewollt: Eine solche Adresse leitet auf eine andere Seite weiter und wird deshalb nicht indexiert (Search-Console-Hilfe). Kritisch sind dagegen alte Adressen, die mit 404 antworten. Für umgezogene Seiten empfiehlt Google eine 301-Weiterleitung auf den neuen Ort (Search-Console-Hilfe). Wie Sie Seiten einordnen, die gecrawlt, aber nicht indexiert sind, zeigt unser Beitrag zu gecrawlten, nicht indexierten Shopseiten.

• Stichprobe alter Produkt-, Kategorie- und Landingpage-Adressen je Sprache und Verkaufskanal antwortet mit 301 auf die neue Adresse
• Keine alte Adresse endet mit 404 oder auf der Startseite
• Die Canonical-Angabe der neuen Seiten zeigt auf die neue Adresse
• Die Sitemap enthält die neuen Adressen
• Fest eingetragene Verweise in Erlebniswelten, Beschreibungen, Newslettern und Anzeigen sind aktualisiert
• Produktfeeds und Exporte geben die neuen Adressen aus

Verweise, die Shopware selbst erzeugt, etwa im Menü, folgen nach dem Neuaufbau der neuen Adresse; fest eingetragene Adressen nicht. Google empfiehlt, die eigenen Verweise umzustellen, weil Weiterleitungen für Nutzer langsam sind (Google Search Central). Wer den Produktfeed ohnehin überarbeitet, etwa für Fragen und Antworten im Merchant Center, prüft die Adressen gleich in derselben Runde.

Mehrere Verkaufskanäle und Sprachen

In Shops mit mehreren Verkaufskanälen lässt sich jede Vorlage global oder je Verkaufskanal setzen (Shopware-Dokumentation). Das erhöht die Zahl der Stellen, an denen sich Adressen ändern können. Eine Übersicht, welche Vorlage in welchem Kanal gilt, gehört deshalb in die Dokumentation des Shops. Wie mehrere Shops aus einer Installation zusammenspielen, beschreibt unser Beitrag zum Shopware-Multistore.

Für jede Sprache entsteht eine eigene Adresse, weil Shopware die Adressen je Sprache speichert (Shopware-Quelltext). Übersetzte Namen in der Vorlage ergeben übersetzte Adressen, was Googles Empfehlung zur Sprache der Zielgruppe entspricht (Google Search Central). Dabei wird leicht übersehen: Wer Übersetzungen später nachpflegt, ändert damit die Adressen der betroffenen Sprache. Auch das ist eine Adressänderung, für die die Weiterleitungsoption eingeschaltet sein sollte.

Wann sich eine Änderung lohnt

Nicht jede unschöne Adresse rechtfertigt eine Umstellung. Die folgende Übersicht ordnet typische Ausgangslagen ein:

Fällt die Entscheidung für eine Änderung, sollte sie nicht mit anderen großen Umbauten zusammenfallen. Google rät bei Umzügen, eine Sache nach der anderen zu ändern statt alles gleichzeitig (Google Search Central). Wer ohnehin ein Update wie auf Shopware 6.8 plant, trennt Upgrade und Vorlagenänderung besser zeitlich, damit sich Ursachen für Schwankungen auseinanderhalten lassen. Bei einem Systemwechsel ändern sich die Adressen dagegen ohnehin; dort sollte die Vorlage vor dem Start feststehen, damit es nur einen Umzug gibt. Bei einer Shopware-Migration planen wir die Vorlagen deshalb von Anfang an mit.

So begleiten wir die Planung

In Shopware-Projekten unserer Shopware-Agentur gehören die SEO-URL-Vorlagen zu den Einstellungen, die wir vor dem Start und vor jeder größeren Änderung gemeinsam mit Ihnen festlegen. Die Arbeit gliedert sich in drei Abschnitte:

Im laufenden Betrieb gehört die Vorlage in die regelmäßige Shopware-Wartung: Nach Updates und neuen Erweiterungen zeigt ein Abgleich mit der gesicherten Adressliste, ob sich Adressen unbemerkt verändert haben.