Shopware 6 Free Guide · SEO-URLs · UUID-Suffix · seo_url · Indexing · Cleanup

Shopware 6: SEO-URLs mit UUID-/Hex-Suffix analysieren und bereinigen

Q: Ist der Hex-Suffix wirklich ein Hash?

Im Alltag wird er oft Hash genannt. Technisch handelt es sich meist um einen UUID- oder Hex-ähnlichen Suffix, der zur Eindeutigkeit des SEO-Pfads genutzt wird. Ein echtes # wäre ein URL-Fragment.

Wenn Shopware-6-Produkt-URLs plötzlich wie produktname-019c98ab028c71ca92b1dba1225b3fd0 aussehen, liegt die Ursache häufig nicht im Frontend, sondern in persistierten SEO-URL-Daten. Diese kostenlose Anleitung zeigt einen kontrollierten Workflow: erst messen, Backup erstellen, gezielt verwaiste Einträge bereinigen, neu indizieren und anschließend verifizieren.

Shopware 6 SEO-URL Cleanup seo_url Tabelle SQL Diagnose Indexing Backup zuerst Free Guide

Worum geht es?

Shopware muss SEO-URLs eindeutig halten. Wenn ein gewünschter Slug durch alte Einträge blockiert ist, kann Shopware einen UUID-/Hex-Suffix anhängen. Das sieht aus wie ein „Hash“, ist aber meist ein Eindeutigkeits- oder Canonical-Problem in der SEO-URL-Persistenz.

SEO URL

Symptom Produkt-URLs enden auf einen 32-stelligen Hex-Suffix, obwohl eigentlich ein sauberer Slug erwartet wird.

Häufige Ursache Alte oder verwaiste Einträge in seo_url blockieren den gewünschten SEO-Pfad.

Sicherer Ansatz Nicht blind löschen, sondern erst zählen, sichern, gezielt bereinigen und danach neu indexieren.

Wichtigste Messwerte orphan_cnt und uuid_canonicals zeigen, ob du wirklich ein Datenproblem hast.

Wording: Ein echtes # in einer URL ist ein Fragment/Anchor. In diesem Guide geht es um einen angehängten 32-stelligen Hex-/UUID-ähnlichen Suffix am Ende des SEO-Pfads.

Diagnose · Cleanup · Shopware Snippets

Typische Symptome

Diese Anzeichen sprechen dafür, dass die Shopware-SEO-URL-Persistenz geprüft werden sollte.

Symptome

Produkt-URLs enden auf -32hex oder einen UUID-ähnlichen Suffix.
Nach „Produkt gelöscht und neu angelegt“ wird der alte schöne Slug nicht mehr vergeben.
SEO-URL-Regeneration wirkt im Admin so, als ob nichts passiert.
Die betroffenen URLs bleiben trotz Cache-Löschen bestehen.
Ein SEO-Plugin wird verdächtigt, obwohl das Problem auch aus der Datenbasis kommen kann.

Gute Nachricht: In vielen Fällen ist nicht der ganze Shop kaputt. Häufig ist es ein bereinigbarer Daten-/Index-Zustand.

Was diese Anleitung nicht ist

Der Guide hilft bei einem bestimmten technischen Muster. Er ersetzt keine vollständige SEO-, Redirect- oder Datenbankprüfung.

Grenzen

Kein Ersatz für ein sauberes Redirect-Konzept.
Keine Garantie, dass jedes URL-Problem dieselbe Ursache hat.
Kein Freifahrtschein für blindes Löschen in seo_url.
Keine Garantie für Rankings oder sofortige Indexänderungen bei Google.
Kein Ersatz für Staging-Test, Backup und technische Prüfung.

Diagnose: erst messen, dann handeln

Die folgenden SQL-Abfragen sind read-only. Sie zeigen, ob verwaiste Produkt-SEO-URLs vorhanden sind und wie viele Canonical-URLs auf einen 32-stelligen Hex-Suffix enden.

SQL

1. Verwaiste Produkt-SEO-URLs zählen

SQL – Orphans zählen

SELECT COUNT(*) AS orphan_cnt


FROM seo_url su
LEFT JOIN product p ON p.id = su.foreign_key
WHERE su.route_name = 'frontend.detail.page'
AND p.id IS NULL;

2. Canonicals mit UUID-/Hex-Suffix zählen

SQL – UUID-Canonicals zählen

SELECT COUNT(*) AS uuid_canonicals


FROM seo_url
WHERE route_name = 'frontend.detail.page'
AND is_canonical = 1
AND seo_path_info REGEXP '-[0-9a-f]{32}$';

3. Saubere Canonicals zählen

SQL – Saubere Canonicals zählen

SELECT COUNT(*) AS clean_canonicals


FROM seo_url
WHERE route_name = 'frontend.detail.page'
AND is_canonical = 1
AND seo_path_info NOT REGEXP '-[0-9a-f]{32}$';

Interpretation: Wenn orphan_cnt deutlich größer als 0 ist und gleichzeitig viele uuid_canonicals existieren, ist ein gezielter Orphan-Cleanup ein plausibler nächster Schritt.

Auswertung

Was die Counts grob bedeuten.

Counts

orphan_cnt = 0 Dann liegt die Ursache wahrscheinlich nicht in verwaisten Produkt-SEO-URLs.

orphan_cnt hoch Gelöschte Produkte können alte Slugs blockieren.

uuid_canonicals hoch Viele aktuelle Canonicals enden auf Hex-Suffix und sollten nach dem Cleanup erneut geprüft werden.

Nach Indexing erneut messen Entscheidend ist nicht Gefühl, sondern Vergleich vor und nach dem Vorgang.

Cleanup: Backup erstellen und nur gezielt bereinigen

Der sicherere Ansatz ist minimal-invasiv: Erst die Tabelle sichern, dann nur verwaiste Produkt-SEO-URLs löschen, deren Produktdatensatz nicht mehr existiert.

Cleanup

Vorher prüfen: Diese Schritte nur ausführen, wenn du Zugriff auf ein Backup hast und weißt, wie du im Notfall zurückrollen kannst. Im Idealfall zuerst in Staging testen.

0. Backup der seo_url-Tabelle erstellen

SQL – Backup von seo_url

CREATE TABLE IF NOT EXISTS seo_url_backup_fix AS


SELECT * FROM seo_url;

1. Verwaiste Produkt-SEO-URLs löschen

SQL – Nur Orphans löschen

DELETE su


FROM seo_url su
LEFT JOIN product p ON p.id = su.foreign_key
WHERE su.route_name = 'frontend.detail.page'
AND p.id IS NULL;

2. Optional: verbliebene UUID-Canonicals gezielt entfernen

Dieser Schritt ist optional und sollte erst nach Orphan-Cleanup, Indexing und erneuter Messung geprüft werden. Er entfernt Canonical-Einträge mit Hex-Suffix, damit Shopware sie neu erzeugen kann.

SQL – UUID-Canonicals löschen, optional

DELETE FROM seo_url


WHERE route_name = 'frontend.detail.page'
AND is_canonical = 1
AND seo_path_info REGEXP '-[0-9a-f]{32}$';

Redirect-Hinweis: Wenn du bewusst alte Produkt-URLs als Redirect-Historie behalten möchtest, brauchst du ein separates Redirect-Konzept. Dieser Guide fokussiert auf Slug-Blockaden und verwaiste SEO-URL-Datensätze.

Neu indizieren und Cache leeren

Nach dem Cleanup müssen SEO-URLs und Indizes neu aufgebaut werden. Wenn Shopware über Queue arbeitet und kein Worker läuft, wirkt der Admin-Indexer manchmal so, als würde nichts passieren.

Indexing

Index neu bauen

SSH / CLI – Index neu bauen

bin/console dal:refresh:index


bin/console cache:clear

Queue Worker starten, falls dein Setup async arbeitet

SSH / CLI – Queue verarbeiten

bin/console messenger:consume async low_priority -vv

Praxis-Tipp: Nach dem Indexing im Inkognito-Fenster testen, alte Browser-Caches vermeiden und die Diagnose-Queries erneut ausführen.

Test-Checkliste nach dem Cleanup

Nach dem Cleanup geht es nicht um Bauchgefühl, sondern um messbare Verifikation.

Orphans erneut zählen orphan_cnt sollte nach dem Cleanup bei 0 liegen oder deutlich reduziert sein.

UUID-Canonicals prüfen uuid_canonicals sollte nach Indexing sinken oder auf 0 laufen.

Betroffene Produkte öffnen Mehrere Produkte direkt im Frontend prüfen, auch Produkte mit Varianten.

Cache und CDN beachten Shopware Cache, HTTP-Cache, CDN und Browsercache können alte Zustände zeigen.

Redirects prüfen Falls alte URLs erhalten bleiben sollen, braucht es ein sauberes Redirect-Konzept.

Google nicht sofort erwarten Suchergebnisse aktualisieren sich nicht direkt nach dem technischen Fix.

Messbar statt Gefühl: Zähle vor und nach dem Eingriff. Wenn die Counts sinken und neue Produkt-URLs sauber erzeugt werden, ist die Richtung technisch plausibel.

FAQ zu Shopware 6 SEO-URLs mit UUID-/Hex-Suffix

Kurze Antworten zu Ursache, Sicherheit, Indexing, SEO-Risiko, Plugins und Support.

6 Fragen

Ist der Hex-Suffix wirklich ein Hash?

Im Alltag wird er oft „Hash“ genannt. Technisch handelt es sich meist um einen UUID- oder Hex-ähnlichen Suffix, der zur Eindeutigkeit des SEO-Pfads genutzt wird. Ein echtes # wäre ein URL-Fragment.

Ist das Löschen von Orphans SEO-gefährlich?

Wenn wirklich nur verwaiste SEO-URL-Einträge ohne zugehöriges Produkt gelöscht werden, ist der Eingriff deutlich gezielter als ein pauschales Leeren der Tabelle. Trotzdem sind Backup, Test und Redirect-Prüfung wichtig.

Warum ändert sich die URL nicht sofort?

SEO-URLs sind persistent und werden nicht immer sofort neu erzeugt. Zusätzlich können Shopware Cache, HTTP-Cache, CDN, Browsercache oder nicht verarbeitete Queue-Jobs alte Zustände ausliefern.

Warum passiert im Admin-Indexer scheinbar nichts?

Viele Shopware-Setups arbeiten mit Queue-Jobs. Ohne laufenden Worker werden Jobs erzeugt, aber nicht verarbeitet. In solchen Fällen ist ein CLI-Index-Refresh oder laufender Worker wichtig.

Ist immer ein SEO-Plugin schuld?

Nein. Auch ohne SEO-Plugin kann Shopware Suffixe erzeugen, wenn der gewünschte Slug blockiert ist oder Canonical- beziehungsweise SEO-URL-Daten nicht sauber neu erzeugt wurden.

Kann borban bei der Bereinigung helfen?

Ja. Bei Unsicherheit, Live-Systemen, fehlendem Staging, komplexem Datenbestand oder mehreren SEO-/Cache-Plugins kann eine individuelle Prüfung oder ein kontrollierter Cleanup sinnvoll sein.

Transparenz-Hinweis: Dieser Free Guide ist eine technische Anleitung für Shopware 6. Datenbankbefehle sollten nur mit Backup, ausreichender Berechtigung und Verständnis für das jeweilige Setup ausgeführt werden. Der Guide ersetzt keine individuelle Prüfung bei komplexen Live-Systemen.