PrestaShop Sprechende URLs: IDs entfernen, Rewrites, Canonicals

Jeder PrestaShop-Shop kommt nach etwa sechs Wochen bei derselben Frage an: Warum sehen Produkt-URLs immer noch aus wie /12-blaues-widget, obwohl sprechende URLs aktiviert sind - und kann die Zahl weg?

Kurz gesagt: Die Zahl trägt die Route, sie zu entfernen ist möglich, aber teuer, und es gibt drei andere URL-Probleme, die Sie mehr Traffic kosten und deutlich billiger zu beheben sind. Das ist die Reihenfolge, in der ich in Kundenshops tatsächlich arbeite.

Wie PrestaShop eine URL aufbaut

PrestaShop sucht ein Produkt nicht über seinen Slug. Es liest die ID aus dem Pfad und fragt über den Primärschlüssel ab. Der Slug daneben ist Dekoration für Menschen und für Suchmaschinen.

Deshalb sieht die Standard-Produktroute so aus:

/{id}-{rewrite}
/{kategorie}/{id}-{rewrite}

Der Dispatcher greift auf das numerische Segment zu. Ändern Sie den Slug, löst die URL trotzdem auf, weil die ID die Arbeit macht. Dieses Verhalten ist zugleich Ihr Sicherheitsnetz: Ein umbenanntes Produkt läuft nicht in einen 404.

1. Sprechende URLs richtig aktivieren

SEO & URLs → URLs einrichten → Sprechende URL: Ja. Und dann, im selben Bildschirm, die .htaccess neu erzeugen. Diese Neuerzeugung zu überspringen ist der häufigste Grund, warum sprechende URLs "nicht funktionieren" - die Einstellung kippt um, die Rewrite-Regeln werden nie geschrieben, und jede schöne URL läuft in einen 404.

Unter Nginx gibt es gar keine .htaccess, und PrestaShop kann Ihre Konfiguration nicht für Sie schreiben. Sie brauchen den Rewrite-Block in der Serverkonfiguration, und die muss neu geladen werden. Wenn Ihr Hoster Nginx verwaltet, ist das ein Support-Ticket und keine Einstellung.

Prüfen Sie das Ergebnis, indem Sie eine Kategorie-URL direkt aufrufen statt einen Link anzuklicken. Ein Klick beweist, dass der Link erzeugt wurde; ein direkter Aufruf beweist, dass der Rewrite auflöst.

2. Route-Muster vor den IDs in Ordnung bringen

Der Abschnitt "Schema der URLs" auf derselben Seite steuert die eigentlichen Route-Muster, und die Voreinstellungen sind schlechter, als die meisten denken.

Vor allem die Kategorie-Route enthält standardmäßig den vollständigen Kategoriepfad, was bedeutet: Ein Produkt, das über drei Kategorien erreichbar ist, hat drei URLs. Das ist ein Duplicate-Content-Problem, das durch Konfiguration entsteht und nicht durch Inhalte - und es ist das größte URL-Problem der meisten PrestaShop-Shops.

Zwei vertretbare Entscheidungen:

• Produktroute flach halten, /{rewrite} plus ID, sodass ein Produkt genau eine URL hat, unabhängig von der Kategorie. Das mache ich in den meisten Shops.
• Kategorie im Pfad lassen, aber dann absolut sicherstellen, dass die Canonicals auf einen gewählten Pfad zeigen.

Was Sie keinesfalls tun sollten: die Kategorie im Pfad lassen und annehmen, PrestaShop räume die Dubletten schon auf. Tut es nicht.

3. Canonicals

PrestaShop gibt auf Produkt- und Kategorieseiten durchaus ein Canonical-Tag aus, und für den einfachen Fall stimmt es meist. Für diese Fälle stimmt es meist nicht:

• Filternavigation. Filterkombinationen erzeugen URLs mit Query-Strings, die sich entweder selbst kanonisieren oder direkt indexiert werden. Beides ist schlecht. Die Layered Navigation sollte auf die ungefilterte Kategorie kanonisieren, und die Kombinationen, die Sie wirklich im Index wollen, gehören auf eine bewusste, kurze Liste.
• Paginierung. Seite 2, die auf Seite 1 kanonisiert, versteckt Ihre tieferen Produkte vollständig vor dem Index. Seite 2 soll auf sich selbst kanonisieren.
• Multistore. Jeder Shop braucht seinen eigenen Canonical-Host. Das bricht leise und bleibt kaputt.

Bringen Sie Canonicals in Ordnung, bevor Sie IDs anfassen. Es kostet einen Nachmittag und dort liegt der tatsächliche Duplicate Content.

4. Die ID entfernen

Jetzt zu der Frage, mit der alle anfangen.

Der PrestaShop-Kern kann es nicht. Der Dispatcher braucht die ID, um die Route aufzulösen, also bedeutet ihre Entfernung eines von beidem:

• Ein Modul, das die Route abfängt und den Slug selbst zu einer ID auflöst, meist über eine zusätzliche Nachschlagetabelle.
• Ein Override der Klassen Dispatcher und Link, das dasselbe von Hand tut.

Beides funktioniert. Beides trägt dieselben drei Kosten, und Sie sollten mit diesen auf dem Tisch entscheiden:

1. Eine Abfrage bei jedem Request. Sie setzen eine Slug-zu-ID-Auflösung vor den Router. Cachen Sie sie, sonst merken Sie es.
2. Slug-Kollisionen werden zu 404s. Zwei Produkte namens "Blaues Widget" in verschiedenen Kategorien waren in Ordnung, solange die ID sie unterschied. Jetzt nicht mehr.
3. Eine Upgrade-Hypothek. Overrides des Dispatchers gehören zu den ersten Dingen, die bei einem Major-Upgrade brechen. Wenn Sie auf PrestaShop 1.7 oder 8 sind und Richtung 9 gehen: nach der Migration, nicht davor.

Und der ehrliche Teil: Der Ranking-Vorteil ist klein. Google sagt seit Jahren deutlich, dass die URL-Struktur ein schwaches Signal ist. Eine saubere URL lässt sich schöner teilen und ist minimal besser für die Klickrate in den Suchergebnissen. Sie ist nicht der Grund, warum Sie auf Seite zwei stehen.

Wenn Sie einen Shop mit echtem Umsatz und einer stabilen Codebasis haben, ist es eine vertretbare Politur. Wenn Sie doppelte Filter-URLs und kaputte Canonicals haben, bringt deren Behebung deutlich mehr Traffic bei einem Bruchteil des Risikos.

5. Alles weiterleiten, was Sie ändern

Jede URL-Änderung braucht einen 301 vom alten Pfad. PrestaShop ändert den Slug eines Produkts bereitwillig, sobald jemand im Backoffice den Namen bearbeitet - ohne Weiterleitung, lautlos. In einem Shop, in dem mehrere Personen Produkte pflegen, ist das ein langsames Leck.

Die id_product im Pfad rettet Sie hier: Die alte URL löst weiterhin auf. Ein weiterer Grund, bei der Entfernung der ID bedächtig statt eifrig zu sein.

Die Reihenfolge, in der ich tatsächlich arbeite

1. Sprechende URLs an, .htaccess neu erzeugt, Rewrite per direktem Aufruf geprüft
2. Route-Muster so gewählt, dass ein Produkt eine URL hat
3. Canonicals bei Filtern, Paginierung und Multistore in Ordnung gebracht
4. Weiterleitungen für alles, was bereits geändert wurde
5. Dann, wenn die Codebasis stabil und der Shop nicht mitten in einer Migration ist, über das Entfernen der IDs nachdenken

Die meisten Shops brauchen Schritt fünf nie. Fast alle brauchen die Schritte eins bis vier, und die meisten haben Schritt drei nie gemacht.