301-Weiterleitungen und 404 nach einer Migration prüfen

Was ein Shop verliert, wenn sich Adressen ändern

Suchmaschinen, externe Links, Lesezeichen und Kampagnen verweisen auf bestimmte Adressen. Antworten diese Adressen nach einer Migration oder einer URL-Änderung mit 404, indexiert Google sie nicht: Laut der Dokumentation von Google werden URLs, die einen 4xx-Code zurückgeben, nicht indexiert, und bereits indexierte werden aus dem Index entfernt. Eine dauerhafte Weiterleitung sagt dagegen, dass die Seite existiert und verschoben wurde: Google nutzt sie als Signal, dass das Ziel die kanonische URL ist, und erklärt, dass 301 und andere dauerhafte Weiterleitungen keinen PageRank-Verlust verursachen. Wie viel Traffic tatsächlich verloren geht, hängt von der Website ab, und deshalb misst man es mit der Search Console, statt sich auf allgemeine Zahlen zu verlassen.

Die HTTP-Codes, auf die es ankommt

Dieselbe RFC stellt klar, dass 410 gegenüber 404 vorzuziehen ist, wenn der Server weiß, dass der Zustand wahrscheinlich dauerhaft ist.

Was PrestaShop 9.1 von selbst tut

Das Folgende wurde im Code von PrestaShop 9.1.5 überprüft, mit den in den Quellen genannten Dateien.

Zur kanonischen URL weiterleiten

Unter Shop-Einstellungen, Traffic & SEO, URL-Einstellungen hat die Option „Zur kanonischen URL weiterleiten“ (PS_CANONICAL_REDIRECT) den Wert 0 (keine Weiterleitung), 1 (302) oder 2 (301). Im FrontController antwortet PrestaShop bei GET-Anfragen, wenn die angeforderte URL nicht mit der kanonischen übereinstimmt, mit einer 301, wenn die Option 2 ist, sonst mit einer 302, und unternimmt bei 0 nichts. Die offizielle Dokumentation empfiehlt 301, sobald die Änderungen abgeschlossen sind, und warnt, dass es ohne Weiterleitungen doppelte URLs geben kann. Im Entwicklungsmodus erscheint anstelle der Weiterleitung eine Debug-Seite: Denken Sie beim Testen daran.

Der Slug eines Produkts oder einer Kategorie ändert sich

Die Standardregeln setzen die ID in die URL ({id}{-:id_product_attribute}-{rewrite}.html bei Produkten, {id}-{rewrite} bei Kategorien). Die alte URL mit dem früheren Slug findet daher weiterhin das Objekt, und der Controller vergleicht sie mit der aktuellen: Steht die Option auf 301, leitet er weiter, bei 0 antworten beide Adressen, und die Duplikate bleiben.

Das URL-Schema ändert sich

Der Dispatcher geht vom Controller pagenotfound aus und ersetzt ihn nur, wenn der URI zu einer der aktuellen Routen passt, den Standardrouten oder den benutzerdefinierten (PS_ROUTE_*). Der Code behält die früheren Schemata nicht bei: Alte Adressen, die keiner Route mehr entsprechen, landen auf einer Seite, die mit einem echten 404-Status antwortet. Weiterleitungen von den alten Schemata müssen separat angelegt werden.

Produkt deaktiviert oder nicht mehr verfügbar

Das Feld „Weiterleitung wenn Artikel deaktiviert“ der Produktseite (redirect_type) hat zehn Werte: default, 404 und 410 (Fehlerseite), 200-displayed, 404-displayed und 410-displayed (Produkt wird mit diesem Code als nicht mehr im Katalog angezeigt), 301-category und 302-category (Weiterleitung auf eine Kategorie), 301-product und 302-product (Weiterleitung auf ein anderes Produkt). Bei default gilt „Default behavior for disabled products“ (PS_PRODUCT_REDIRECTION_DEFAULT). Ein gelöschtes Produkt existiert nicht mehr, und die Seite antwortet mit 404.

Kategorie deaktiviert oder gelöscht

Eine deaktivierte Kategorie folgt dem Feld „Redirection when not displayed“: standardmäßig 301, auf die nächste aktive übergeordnete Kategorie, wenn Sie keine andere wählen, oder 302, 410, 404. Eine gelöschte Kategorie antwortet mit 404, und Category::deleteRedirections() setzt die Produkte und Kategorien, die auf sie weitergeleitet haben, auf das Standardverhalten zurück.

Migration von einer anderen Plattform

Beim Wechsel der Plattform ändern sich fast alle URLs in ihrer Form: Produkte, Kategorien, Seiten, Bilder und Dateien. PrestaShop kann die alten Adressen nicht erraten, sie müssen gesammelt und zugeordnet werden.

1. Sammeln Sie die alten URLs. Google schlägt vor, von den Sitemaps, den Server-Logs oder der Analytics für die meistbesuchten URLs, vom Bericht „Links“ der Search Console und von der Liste des CMS auszugehen. Der Bericht „Leistung“ hat die Dimension „Seiten“ und eine Export-Schaltfläche. Beziehen Sie Bilder, Videos, JavaScript und CSS ein.
2. Ordnen Sie jede URL zu. Google schreibt, dass es wichtig ist, die URLs der alten Website denen der neuen zuzuordnen und zu entscheiden, wohin jede zeigen soll: auf die passendste Seite, eins zu eins.
3. Behandeln Sie, was kein Äquivalent hat. Google verlangt, dass gelöschte Inhalte mit 404 oder 410 antworten. Vermeiden Sie es, viele alte URLs auf ein einziges, nicht passendes Ziel wie die Startseite zu leiten: Laut Google kann das Nutzer verwirren und als Soft 404 behandelt werden. Wenn mehrere Seiten zu einer zusammengeführt wurden, ist diese ein legitimes Ziel.
4. Vermeiden Sie häufige Fehler: Weiterleitungsketten (Googlebot folgt bis zu 10, aber Google rät, auf das endgültige Ziel zu verweisen und, wenn das nicht möglich ist, idealerweise bei höchstens 3 Schritten zu bleiben und jedenfalls unter 5); Schleifen; 302 statt 301; interne Links, Canonical-Tags, hreflang und Sitemaps, die auf den alten URLs geblieben sind; Weiterleitungen auf nicht existierende URLs; noindex oder robots.txt-Sperren aus der Entwicklungsphase, die aktiv geblieben sind; zu früh entfernte Weiterleitungen.

Was in der Search Console zu prüfen ist

• Bericht „Seitenindexierung“: „Nicht gefunden (404)“, „Soft 404-Fehler“, „Seite mit Weiterleitung“ und „Weiterleitungsfehler“ (zu lange Kette, Schleife, zu lange oder ungültige URL). Der Bericht selbst sagt, dass ein 404 nicht zwingend ein Problem ist, wenn die Seite ohne Ersatz entfernt wurde, und dass man eine 301 verwenden soll, wenn sie verschoben wurde.
• „URL-Prüftool“: Der Test der veröffentlichten URL folgt Weiterleitungen, gibt aber nicht an, dass er einer gefolgt ist, und zeigt nicht die endgültige URL. Um Codes und Kette zu sehen, braucht man ein Befehlszeilen-Tool oder ein Skript.
• Sitemap: Senden Sie die mit den neuen URLs. Die mit den alten kann Hinweise zu Weiterleitungen anzeigen, und das ist normal.
• „Adressänderung“: Sie dient nur beim Wechsel von einer Domain oder Subdomain zu einer anderen, nicht für HTTP zu HTTPS, www oder ohne www und auch nicht für Pfade derselben Domain.
• Zeitrahmen: Für eine kleine bis mittelgroße Website nennt Google einige Wochen für die meisten Seiten, mit vorübergehenden Schwankungen der Sichtbarkeit.

Checkliste

1. Liste der alten URLs mit Besuchen und Links, aus Sitemaps, Logs und Search Console.
2. Zuordnung eins zu eins; 404 oder 410 für das, was kein Äquivalent hat.
3. 301 serverseitig für verschobene Inhalte, 302 nur wenn vorübergehend.
4. Keine Ketten: Jede alte URL verweist auf das endgültige Ziel, mit einem Skript über die ganze Liste geprüft.
5. Interne Links, Canonical-Tags, hreflang und Sitemaps auf den neuen URLs.
6. „Zur kanonischen URL weiterleiten“ auf 301, wenn der Shop online ist.
7. Überwachung der 404 und der „Seitenindexierung“ in den Wochen nach der Migration; Weiterleitungen so lange wie möglich beibehalten, in der Regel mindestens ein Jahr.

So macht es das Modul SEO-Weiterleitungen - Verwaltung von 301/302/404 (SEO Redirects)

• 301-, 302- und 410-Regeln mit einfachem Pfad, Wildcard (* und ?) oder validierter Regex sowie Optionen zum Query-String (ignorieren, die vollständige URL vergleichen oder einen Parameter verlangen). Die 410 antwortet mit einem echten 410-Status und X-Robots-Tag: noindex, bevor das Theme geladen wird.
• Die Weiterleitung wird im Hook actionDispatcher ausgelöst, bevor die Seite aufgebaut wird: Einfache Regeln werden mit einer indizierten Suche über den Hash des Pfads gefunden, Wildcards und Regex werden der Reihe nach ausgewertet.
• Der 404-Monitor erfasst fehlende URLs mit Anzahl der Anfragen, letztem Zugriff, Referer und User-Agent (bis zu 5.000 verschiedene URLs, änderbar); „301 erstellen“ füllt die Regel vor.
• Legt eine 301 an, wenn sich der Slug eines Produkts, einer Kategorie oder einer CMS-Seite ändert, für jede Sprache, sofern nicht schon eine Regel diese URL abdeckt.
• Importiert und exportiert CSV (Spalten source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), mit der Anzahl der importierten und übersprungenen Zeilen: praktisch, um die Zuordnung einer Migration zu laden.
• Lehnt externe Ziele ab, die nicht im Shop oder in einer Liste autorisierter Hosts stehen (Schutz vor Open Redirect).

Sehen Sie die Modulseite oder lesen Sie die Anleitung zur Installation und Konfiguration.

Quellen

• RFC 9110, HTTP Semantics: Abschnitte 15.4.2, 15.4.3, 15.4.9, 15.5.5 und 15.5.11
• Google Search Central: Weiterleitungen und die Google Suche, Website-Migration mit URL-Änderungen, HTTP-Statuscodes
• Search Console-Hilfe: Seitenindexierung, URL-Prüftool, Adressänderung, Leistung
• Code von PrestaShop 9.1.5 auf GitHub: FrontController, ProductController, CategoryController, Dispatcher
• PrestaShop-Dokumentation: SEO und URLs, Produktverwaltung

Häufige Fragen

301 oder 302 bei einer Migration?

301 (oder 308) für dauerhaft verschobene Inhalte: Google verwendet es als starkes Signal, während 302 ein schwaches Signal ist. Die Dokumentation von Google empfiehlt dauerhafte Weiterleitungen, wenn man sicher ist, dass sie nicht rückgängig gemacht werden.

Sollte man alle alten URLs auf die Startseite weiterleiten?

Nein. Google rät davon ab, viele alte URLs auf ein einziges, nicht passendes Ziel zu leiten: Das kann Nutzer verwirren und als Soft 404 behandelt werden. Besser ist die passendste Seite oder ein 404 oder 410, wenn es kein Äquivalent gibt.

Wie lange sollten Weiterleitungen beibehalten werden?

Google empfiehlt, sie so lange wie möglich beizubehalten, in der Regel mindestens ein Jahr, damit die Signale auf die neuen URLs übergehen und externe Links neu zugeordnet werden.

Leitet PrestaShop die alte URL von selbst weiter, wenn sich der Slug ändert?

Ja, wenn die ID in der URL steht und „Zur kanonischen URL weiterleiten“ auf 301 steht (bei 302 ist die Weiterleitung temporär, bei 0 gibt es keine Weiterleitung). Das geschieht nicht, wenn sich das URL-Schema ändert: Alte Adressen, die keiner Route mehr entsprechen, liefern 404.

404 oder 410 für gelöschte Seiten?

Der Standard bevorzugt 410, wenn die Entfernung wahrscheinlich dauerhaft ist. Für Google werden die beiden Codes gleich behandelt, wie alle 4xx außer 429.

Reicht das Modul allein?

Nein. Das Modul verwaltet Regeln, 404-Monitor, CSV und automatische 301-Weiterleitungen, aber die Zuordnung müssen Sie selbst vorbereiten. Es prüft keine Ketten und Schleifen zwischen den Regeln und korrigiert keine internen Links, Canonical-Tags, hreflang und Sitemaps: Diese bleiben mit einem Skript und mit der Search Console zu prüfen.