Doppelte Hersteller-URL-Pfade in Shopware 6: ein Audit-Fund und die saubere Konsolidierung

von Der Atilla | Juni 5, 2026 | Shopware 6, Shopware Einstellungen, Shopware SEO | 0 Kommentare

Bei einem routinemäßigen SEO-Audit eines Shopware-6-Shops sind uns doppelte URL-Pfade für die Hersteller-Seiten aufgefallen. Sie waren bereits korrekt per Canonical ausgezeichnet – wir haben sie zusätzlich per 301-Weiterleitung konsolidiert, damit Suchmaschinen kein Crawl-Budget auf die Alias-Pfade verwenden. Dieser Beitrag beschreibt sachlich, was wir gefunden und wie wir es gelöst haben. Einen kausalen Zusammenhang mit konkreten Traffic-Zahlen behaupten wir dabei ausdrücklich nicht.

Ausgangslage

Der Shop (Barfußschuhe, Shopware 6.7.8.2) nutzt das Plugin Hersteller Professional von coolbax – eine etablierte, über 1.000-fach installierte Erweiterung, die die in Shopware 6 im Standard fehlenden Hersteller-/Markenseiten nachrüstet. Wie man es einrichtet, steht in unserer Plugin-Referenz im Wiki.

Das Plugin legt pro Marke eine kanonische URL /hersteller/marke/ an und zusätzlich eine Kurzform /marke/ als Alias. Bei URL-erzeugenden Erweiterungen ist das ein verbreitetes, normales Verhalten – kein Defekt.

Was uns aufgefallen ist

Beide Pfade – Lang- und Kurzform – lieferten HTTP 200. Bei genauerem Hinsehen zeigte der Canonical-Tag der Hersteller-Detailseiten allerdings nicht auf die SEO-URL, sondern auf den internen Routing-Pfad (/cbax/manufacturer/detail/…) – die bevorzugte Version war also nicht sauber markiert.

Pfad	Beispiel	HTTP	Canonical
Langform (kanonisch)	`/hersteller/vivobarefoot/`	200	Zielseite
Kurzform (Alias)	`/vivobarefoot/`	200	→ verweist auf Langform

Ein Canonical-Tag ist allerdings nur ein Hinweis an die Suchmaschine, keine Weiterleitung. Die Alias-Pfade dürfen weiterhin gecrawlt werden. Bei vielen Herstellern summiert sich das und kann Crawl-Budget binden, das man lieber auf die kanonischen Seiten lenkt. Das war unser einziger Ansatzpunkt – keine Fehlerbehebung, sondern eine Feinjustierung.

Größenordnung – mit Vorbehalt

Die betroffenen Hersteller-Seiten erzeugen in der Search Console zusammen rund 500.000 Impressionen. Ob unsere Maßnahme diese Zahl messbar beeinflusst, beobachten wir noch – ein Ursache-Wirkungs-Zusammenhang ist damit ausdrücklich nicht belegt. Wir haben die saubere Variante umgesetzt, weil sie unabhängig davon richtig ist.

Das Audit: vier Prüfungen

Bevor man etwas ändert, misst man. Vier Schnellprüfungen zeigen, ob Alias-Pfade offen erreichbar sind – bei jeder Shop-Übernahme sinnvoll:

Trailing Slash: /hersteller/marke und /hersteller/marke/ aufrufen – idealerweise liefert eine 200, die andere 301 auf die kanonische Variante.
Kurz- vs. Langpfad: /marke/ und /hersteller/marke/ – liefern beide 200, sind die Alias-Pfade offen crawlbar.
Groß-/Kleinschreibung: /hersteller/Vivobarefoot/ vs. /hersteller/vivobarefoot/ – liefern beide 200, ist der Server case-insensitiv.
Sitemap: sitemap.xml öffnen – idealerweise stehen nur die kanonischen /hersteller/…-Pfade darin.

Der Canonical-Tag: per Twig-Override korrigiert

Neben den doppelten Pfaden fiel ein zweiter Punkt auf – der Canonical-Tag selbst. Auf den Hersteller-Detailseiten verwies er nicht auf die SEO-URL, sondern auf den internen Routing-Pfad:

<!-- vorher -->
<link rel="canonical" href="https://…/cbax/manufacturer/detail/[UUID]">

<!-- gewünscht -->
<link rel="canonical" href="https://…/hersteller/affenzahn/">

Dieses Verhalten steckt fest in der Plugin-Logik (gesetzt per setCanonical() im Controller) und lässt sich nicht über die Konfiguration ändern. Bei URL-erzeugenden Erweiterungen ist das kein seltener Fall – und gut update-sicher lösbar, ohne den Plugin-Code anzufassen.

Unsere Lösung: ein Twig-Override im ohnehin aktiven Customizing-Plugin, der den Block layout_head_canonical überschreibt und den korrekten Wert aus Shopwares eigener Meta-Information nutzt (befüllt aus der seo_url-Tabelle):

{% block layout_head_canonical %}
    {% if page.metaInformation.canonical %}
        <link rel="canonical" href="{{ page.metaInformation.canonical }}">
    {% else %}
        {{ parent() }}
    {% endif %}
{% endblock %}

Warum so? Den Plugin-Quellcode direkt zu ändern wäre bei jedem Update verloren, ein eigener Controller-Override aufwendig und fragil. Der Twig-Override ist update-sicher, minimal-invasiv und nutzt ein im Shop bereits etabliertes Muster.

Validierung nach Deployment und Cache-Leeren, stichprobenartig im Quelltext geprüft: /hersteller/affenzahn/, /hersteller/tapir/ und /hersteller/xero-shoes/ – Canonical jeweils korrekt auf die SEO-URL; Produkt- und Kategorieseiten unverändert korrekt.

Die Konsolidierung

Schritt 1 – Paare per SQL ermitteln. Das Plugin schreibt seine Routen in Shopwares seo_url-Tabelle; eine gezielte Abfrage paart Kurz- und Langform:

SELECT su_short.seo_path_info AS kurze_url, su_long.seo_path_info AS lange_url
FROM seo_url su_short
JOIN seo_url su_long ON su_short.path_info = su_long.path_info
  AND su_long.seo_path_info LIKE 'hersteller/%'
  AND su_long.is_canonical = 1
WHERE su_short.seo_path_info NOT LIKE 'hersteller/%'
  AND su_short.route_name = 'frontend.cbax.manufacturer.detail'
GROUP BY su_short.seo_path_info, su_long.seo_path_info;

Ergebnis: 30 Paare.

Bei der Analyse zeigte sich zudem, dass in der seo_url-Tabelle pro Hersteller zwei identische kanonische Einträge lagen – insgesamt 208 Dubletten, die wir direkt in der Datenbank bereinigt haben (per Stage-Vergleich abgesichert, kein funktionaler Schaden). Auch die Kurzformen der drei Hauptkategorien (/damen/, /herren/, /kinder/) wurden per 301 auf ihre kanonischen Kategorie-Pfade geleitet.

Schritt 2 – 301-Weiterleitungen. Der Canonical markiert die bevorzugte URL; mit den 301-Weiterleitungen erzwingen wir sie zusätzlich serverseitig. Jede Kurzform wurde dauerhaft auf die Langform umgeleitet (hier über Dreischild SEO Pro → URL-Weiterleitungen): /marke/ → /hersteller/marke/, Typ 301. Fünf Stichproben bestätigten danach sauberes Verhalten.

Schritt 3 – Groß-/Kleinschreibung normalisieren. Hier zeigt sich die Grenze einfacher Einzelregeln: Eine nginx-Regel pro Marke deckt nur eine Schreibweise ab. Bei mehrteiligen Markennamen wächst die Zahl der Kombinationen schnell (zwei Wörter = vier Varianten, plus Vollcaps und Mischformen). Die saubere Lösung ist eine nginx-map-Direktive mit case-insensitivem Regex (~*):

# im http{}-Block
map $uri $normalized_hersteller {
    ~*^/hersteller/cosy-roots/$   /hersteller/cosy-roots/;
    ~*^/hersteller/affenzahn/$    /hersteller/affenzahn/;
    # ... weitere Hersteller
    default "";
}

# im server{}-Block
if ($normalized_hersteller != "") {
    if ($normalized_hersteller != $request_uri) {
        return 301 $normalized_hersteller;
    }
}

Das ~* matcht jede Schreibweise auf denselben Zieleintrag; der Vergleich mit $request_uri verhindert Redirect-Schleifen, wenn die URL bereits korrekt klein geschrieben ist.

Schritt 4 – Sitemap & GSC. Sitemap neu generieren (php bin/console sitemap:generate), bereinigte URLs in der Search Console zur Neuerfassung einreichen.

Technische UUID-Adressen → sprechende SEO-URLs

Ein weiterer Befund mit Lehrwert: Mehrere Kategorien hatten keinen eigenen SEO-Slug. In dem Fall erzeugt Shopware zwangsläufig eine technische UUID-Adresse der Form /navigation/<UUID> – der fest im Core verankerte Fallback. Gleichzeitig sperrt die robots.txt alle /navigation/-Pfade vom Crawling (Disallow: /navigation/). Das ergab einen direkten Widerspruch: Dieselben URLs standen in der Sitemap („bitte crawlen“), waren aber per robots blockiert.

Für jede betroffene Kategorie haben wir eine sprechende SEO-URL vergeben (z. B. /barfussschuhe-zubehoer/, /service/faq-barfussschuhe/); die alten UUID-Pfade leiten serverseitig per 301 (nginx/ISPConfig) auf die neuen Adressen – 18 Weiterleitungen, jeweils genau ein Schritt, ohne Ketten. Die Lehre: Jede Kategorie, die in Navigation oder Sitemap auftauchen soll, braucht einen eigenen SEO-Slug – sonst landet sie im /navigation/-Fallback und damit im robots-Disallow.

Die Hürde: Managed Hosting

Ein praktisches Detail: Bei Managed-Hosting (Timme/ISPConfig) hat der Shell-Account keinen Zugriff auf die nginx-Konfiguration – nginx -s reload läuft ins Leere, nginx läuft als root im separaten Kontext. Drei Wege bleiben: den Hoster bitten, die map-Regel einzutragen, eine Lösung auf Shopware-Applikationsebene per Event-Subscriber, oder – falls freigeschaltet – ISPConfig Custom Directives.

Sitemap-Hygiene: nur das Wertvolle drinlassen

Zum Abschluss der Welle haben wir die Sitemap aufgeräumt – das ist der Hebel, der bei Suchmaschinen tatsächlich zählt (mehr dazu im Wiki-Eintrag Sitemap-Prioritäten in Shopware 6):

Rechtliche & Info-Seiten (Impressum, AGB, Datenschutz, Widerruf, Versand/Retoure, Zahlungsarten) auf noindex gesetzt – sie haben keinen SEO-Wert und fallen damit aus der Sitemap.
Verwaistes Test-Produkt entfernt: eine tote Test-Seite (/barfussschuhe/kugelschreiber-test) stand noch in der Sitemap – raus.
Sitemap neu generiert (php bin/console sitemap:generate) und in der Google Search Console zur Neuerfassung eingereicht – so lässt sich die Wirkung sauber dieser Welle zuordnen.

Der Effekt: Das Crawl-Budget konzentriert sich auf die umsatzrelevanten Inhalts-Seiten statt auf rechtliche Pflichtseiten oder tote Test-URLs.

Fazit

URL-erzeugende Plugins legen häufig zusätzliche Alias-Pfade an – das ist normal und meist per Canonical sauber geregelt. Wer das letzte bisschen Sauberkeit möchte, konsolidiert die Alias-Pfade zusätzlich per 301, um Crawl-Budget zu schonen. Genau das haben wir hier vorsorglich getan – ohne damit einen bestimmten Effekt auf die Impressionen zu behaupten. Wie das Plugin im Detail funktioniert und korrekt eingerichtet wird, steht in der Plugin-Referenz im Wiki.

Du übernimmst einen Shopware-Shop oder möchtest die URL- und Crawl-Hygiene deines Shops prüfen lassen? Wir schauen sachlich drauf und konsolidieren, was sinnvoll ist – mit Blick auf die Search Console. Mehr auf unserer Seite Shopware-Suchmaschinenoptimierung.