301-Redirects in PrestaShop nach einer Migration einrichten

Redirects verstehen und warum 301 die einzig richtige Wahl ist

Wenn Sie einen PrestaShop-Shop migrieren, aendern sich URLs. Produkte, die unter einer Adresse erreichbar waren, befinden sich nun an einer anderen. Kategorien, die einen bestimmten Slug hatten, haben jetzt einen anderen. Ohne Redirects wird jede alte URL zu einer Sackgasse, die sowohl Besuchern als auch Suchmaschinen einen 404-Fehler zurueckgibt. Der kumulative Effekt ist verheerend: verlorener Traffic, verlorene Rankings und verlorene Umsaetze.

Ein Redirect ist eine Anweisung Ihres Servers, die Browsern und Suchmaschinen-Crawlern mitteilt, dass eine Seite umgezogen ist. Wenn ein Besucher oder Googlebot die alte URL anfordert, antwortet der Server mit dem neuen Standort, und der Client folgt automatisch. Aber nicht alle Redirects sind gleich, und die Verwendung des falschen Typs kann Ihre gesamte Migration untergraben.

301 vs 302: Ein entscheidender Unterschied

Ein 301-Redirect signalisiert einen dauerhaften Umzug. Er teilt Suchmaschinen mit, die angesammelte Link-Equity (den SEO-Wert, der durch Backlinks, Inhaltsqualitaet und Nutzerinteraktion aufgebaut wurde) von der alten URL auf die neue zu uebertragen. Im Laufe der Zeit ersetzt Google die alte URL in seinem Index durch die neue. Das ist genau das, was Sie nach einer Migration wollen.

Ein 302-Redirect signalisiert einen temporaeren Umzug. Er teilt Suchmaschinen mit, dass die alte URL irgendwann zurueckkehren wird, sodass sie die alte URL im Index behalten und keine Link-Equity uebertragen sollen. Die Verwendung von 302-Redirects nach einer dauerhaften Migration bedeutet, dass Google weiterhin versucht, Ihre alten URLs zu indexieren, Ihre neuen URLs kaempfen, um Autoritaet zu gewinnen, und Sie Rankings unnoetig verlieren.

Es gibt auch den 307-Redirect, der das HTTP/1.1-Aequivalent von 302 ist, und den 308-Redirect, der das HTTP/1.1-Aequivalent von 301 ist. Fuer PrestaShop-SEO-Zwecke ist 301 die Standard- und universell unterstuetzte Wahl.

Die Regel ist einfach: Wenn die Seite dauerhaft umgezogen ist, verwenden Sie 301. Nach einer Migration ist die Seite dauerhaft umgezogen. Verwenden Sie immer 301.

Redirects in der .htaccess einrichten (Apache)

Die meisten PrestaShop-Installationen laufen auf Apache, und die .htaccess-Datei ist der Ort, an dem Sie Redirects konfigurieren. Diese Datei befindet sich in Ihrem PrestaShop-Stammverzeichnis neben der index.php.

Die Platzierung ist entscheidend

Die .htaccess-Datei von PrestaShop enthaelt Rewrite-Regeln, die Friendly URLs verarbeiten, HTTPS erzwingen und Anfragen an die richtigen Controller weiterleiten. Ihre Redirect-Regeln muessen vor den PrestaShop-Rewrite-Regeln platziert werden. Wenn Sie sie danach platzieren, koennten die PrestaShop-Regeln die Anfrage zuerst abfangen und Ihre Redirects werden nie ausgefuehrt.

Suchen Sie nach der Kommentarzeile # Dispatcher oder dem Block, der mit RewriteRule ^api beginnt. Ihre benutzerdefinierten Redirects gehoeren ueber diesen Abschnitt, aber nach RewriteEngine On.

Individuelle Seiten-Redirects

Die einfachste Form eines Redirects ordnet eine bestimmte alte URL einer bestimmten neuen URL zu:

Redirect 301 /alte-kategorie/altes-produkt.html https://www.beispiel.de/neue-kategorie/neues-produkt

Die Redirect-Direktive ist Teil des Apache-Moduls mod_alias. Das erste Argument ist der HTTP-Statuscode (301), das zweite ist der alte Pfad (relativ zum Dokumentenstamm) und das dritte ist die vollstaendige neue URL.

Wichtige Details: Der alte Pfad muss mit einem Schraegstrich beginnen und darf den Domainnamen nicht enthalten. Die neue URL muss eine vollstaendige URL einschliesslich Protokoll und Domain sein. Der alte Pfad wird exakt abgeglichen, einschliesslich abschliessender Schraegstriche und Dateiendungen.

Musterbasierte Redirects mit RewriteRule

Wenn viele URLs einem vorhersagbaren Aenderungsmuster folgen, werden individuelle Redirects unpraktisch. Apaches mod_rewrite ermoeglicht es Ihnen, musterbasierte Regeln mit regulaeren Ausdruecken zu schreiben:

RewriteEngine On
RewriteRule ^alte-kategorie/(.*)$ /neue-kategorie/$1 [R=301,L]

Diese Regel erfasst alles nach alte-kategorie/ und haengt es an neue-kategorie/ an. Das $1 ist eine Rueckreferenz auf die erste erfasste Gruppe (der Teil in Klammern). Die [R=301,L]-Flags spezifizieren einen 301-Redirect und dass dies die letzte zu verarbeitende Regel ist, wenn sie uebereinstimmt.

Gaengige musterbasierte Redirect-Szenarien fuer PrestaShop-Migrationen:

.html-Endungen entfernen:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Wechsel von ID-basierten Kategorie-URLs zu namensbasierten:

RewriteRule ^3-alter-kategoriename(.*)$ /neuer-kategoriename$1 [R=301,L]

Ein ganzes Unterverzeichnis umleiten:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Bedingte Redirects

Manchmal benoetigen Sie Redirects, die nur unter bestimmten Bedingungen gelten. RewriteCond bietet diese Moeglichkeit:

RewriteCond %{HTTP_HOST} ^altedomain\.de$ [NC]
RewriteRule ^(.*)$ https://www.neuedomain.de/$1 [R=301,L]

Dies leitet alle Anfragen von altedomain.de auf neuedomain.de um und bewahrt dabei den Pfad. Das [NC]-Flag macht die Bedingung gross-/kleinschreibungsunabhaengig.

Um nur umzuleiten, wenn die angeforderte Datei auf dem neuen Server nicht existiert (nuetzlich bei einer schrittweisen Migration):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^alter-pfad/(.*)$ /neuer-pfad/$1 [R=301,L]

Redirects in Nginx einrichten

Wenn Ihr PrestaShop auf Nginx laeuft, werden Redirects in der Server-Block-Konfigurationsdatei konfiguriert, die sich typischerweise unter /etc/nginx/sites-available/ihredomain.conf oder /etc/nginx/conf.d/ihredomain.conf befindet.

Individuelle Redirects

location = /alte-kategorie/altes-produkt.html {
  return 301 https://www.beispiel.de/neue-kategorie/neues-produkt;
}

Der =-Modifikator spezifiziert einen exakten Abgleich. Ohne ihn behandelt Nginx den Location als Praefix-Abgleich, was mehr URLs als beabsichtigt umleiten koennte.

Musterbasierte Redirects

location ~ ^/alte-kategorie/(.*)$ {
  return 301 /neue-kategorie/$1;
}

Der ~-Modifikator aktiviert Regex-Abgleich. Die erfasste Gruppe $1 funktioniert genauso wie bei Apache.

Map-basierte Redirects fuer grosse Listen

Die map-Direktive von Nginx ist ideal fuer die Verwaltung von Hunderten oder Tausenden individueller Redirects, ohne den Server-Block zu ueberladen:

map $request_uri $redirect_target {
  /altes-produkt-1.html /neues-produkt-1;
  /altes-produkt-2.html /neues-produkt-2;
  /altes-produkt-3.html /neues-produkt-3;
}

server {
  if ($redirect_target) {
    return 301 $redirect_target;
  }
}

Der Map-Block wird nur einmal pro Anfrage ausgewertet und ist selbst mit Tausenden von Eintraegen hocheffizient. Sie koennen die Map sogar aus einer externen Datei laden, indem Sie die include-Direktive verwenden.

Denken Sie daran, Ihre Konfiguration mit nginx -t zu testen und mit systemctl reload nginx nach Aenderungen neu zu laden.

Massen-Redirects mit CSV

Bei Migrationen mit Tausenden von Produkten ist das manuelle Schreiben von Redirect-Regeln nicht machbar. Ein CSV-basierter Ansatz vereinfacht den Prozess.

Die CSV erstellen

Exportieren Sie Ihre alten URLs aus Ihren Pre-Migrations-Crawl-Daten oder der Datenbank. Exportieren Sie Ihre neuen URLs aus der neuen Installation. Ordnen Sie sie in einer Tabelle mit zwei Spalten zu: alter URL-Pfad und neuer URL-Pfad. Speichern Sie als CSV.

Ihre CSV koennte so aussehen:

/3-alte-kategorie,/neue-kategorie
/alte-kategorie/altes-produkt-1.html,/neue-kategorie/neues-produkt-1
/alte-kategorie/altes-produkt-2.html,/neue-kategorie/neues-produkt-2
/content/5-ueber-uns,/content/ueber-uns

CSV in .htaccess-Regeln umwandeln

Ein einfacher Ansatz ist die Umwandlung jeder CSV-Zeile in eine Redirect-Direktive. Mit einem Texteditor mit Suchen-und-Ersetzen oder einem einfachen Kommandozeilen-Tool:

awk -F',' '{print "Redirect 301 " $1 " https://www.beispiel.de" $2}' redirects.csv >> .htaccess

Dies liest die CSV-Datei, teilt jede Zeile am Komma und generiert eine Redirect-Direktive fuer jede Zeile.

Eine Datenbanktabelle verwenden

Fuer sehr grosse Redirect-Listen (10.000+ Eintraege) sollten Sie erwaegen, Redirects in einer Datenbanktabelle zu speichern und sie auf Anwendungsebene zu verarbeiten. Erstellen Sie eine Tabelle mit Spalten fuer alten und neuen Pfad und schreiben Sie ein kleines PrestaShop-Modul oder Override, das 404-Fehler abfaengt, die Tabelle prueft und bei einem Treffer einen 301-Redirect zurueckgibt. Dieser Ansatz ist ueber eine Admin-Oberflaeche einfacher zu verwalten, fuegt aber eine kleine Datenbankabfrage zu jeder 404-Antwort hinzu.

Modul-basierte Redirect-Loesungen

Mehrere PrestaShop-Module bieten Redirect-Verwaltung ueber das Back Office und eliminieren die Notwendigkeit, Server-Konfigurationsdateien direkt zu bearbeiten.

Vorteile modul-basierter Redirects

Ein Redirect-Modul bietet eine benutzerfreundliche Oberflaeche zum Hinzufuegen, Bearbeiten und Loeschen von Redirects. Es umfasst typischerweise Import-/Export-Funktionalitaet fuer Massenvorgaenge, Protokollierung zur Nachverfolgung verwendeter Redirects und die Moeglichkeit fuer nicht-technische Teammitglieder, Redirects ohne Serverzugang zu verwalten.

Wie modul-basierte Redirects funktionieren

Die meisten Redirect-Module funktionieren, indem sie sich in PrestaShops Anfrageverarbeitung einklinken. Wenn eine Anfrage eingeht, die normalerweise zu einem 404-Fehler fuehren wuerde, faengt das Modul sie ab, prueft seine Redirect-Datenbank auf eine uebereinstimmende alte URL und sendet bei einem Treffer eine 301-Redirect-Antwort an die neue URL.

Einige Module gehen weiter, indem sie automatisch Redirects erstellen, wenn Sie die Friendly URL eines Produkts im Back Office aendern. Dies verhindert das haeufige Problem, alte Links zu brechen, wenn Sie Ihre URL-Slugs optimieren.

Performance-Ueberlegungen

Modul-basierte Redirects fuegen einen kleinen Overhead zu jeder 404-Anfrage hinzu, da sie die Datenbank abfragen muessen. Fuer die meisten Shops ist dies vernachlaessigbar, aber wenn Sie Tausende von Redirects haben und erheblichen Bot-Traffic auf alten URLs, koennen sich die Datenbankabfragen summieren. Erwaegen Sie die Verwendung einer Caching-Schicht oder verschieben Sie die meistgenutzten Redirects in die .htaccess fuer optimale Performance.

Regex-Redirects: Macht und Gefahr

Regulaere-Ausdruck-Redirects sind maechtige Werkzeuge, die komplexe URL-Transformationen mit einer einzigen Regel bewaeltigen koennen. Sie sind auch die haeufigste Quelle fuer Redirect-Fehler und Endlosschleifen.

Wann Regex-Redirects verwenden

Verwenden Sie Regex-Redirects, wenn die URL-Aenderung einem konsistenten, vorhersagbaren Muster folgt. Gute Kandidaten sind: Dateiendungen bei allen URLs entfernen oder hinzufuegen, ein URL-Praefix fuer einen ganzen Bereich der Website aendern, Sprachpraefixe entfernen oder hinzufuegen sowie Query-Parameter entfernen.

Gaengige Regex-Muster fuer PrestaShop

Entfernung des Kategorie-ID-Praefixes, das PrestaShop 1.6 zu Kategorie-URLs hinzufuegt:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Dies stimmt mit URLs wie /3-schuhe ueberein und leitet zu /schuhe weiter.

Ein Sprachpraefix hinzufuegen:

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/
RewriteRule ^(.+)$ /de/$1 [R=301,L]

Doppelte Schraegstriche entfernen:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Regex-Regeln sicher testen

Testen Sie Regex-Redirects gruendlich, bevor Sie sie in der Produktion einsetzen. Verwenden Sie einen Online-Regex-Tester (wie regex101.com), um zu verifizieren, dass Ihr Muster die beabsichtigten URLs trifft und keine URLs trifft, die es nicht sollte.

Beginnen Sie waehrend des Testens mit einem 302-Redirect. Dies verhindert, dass Suchmaschinen falsche Redirects cachen. Sobald Sie bestaetigt haben, dass die Regel korrekt funktioniert, aendern Sie sie auf 301.

Testen Sie Randfaelle: URLs mit Query-Parametern, URLs mit Sonderzeichen, URLs mit mehreren uebereinstimmenden Mustern. Jeder davon kann Probleme aufdecken, die bei einfachen Test-URLs nicht offensichtlich sind.

Redirects testen

Redirects ohne gruendliches Testen bereitzustellen, ist ein Rezept fuer eine Katastrophe. Hier sind die Methoden, die Sie verwenden sollten, um Ihre Redirects vor und nach dem Go-Live zu ueberpruefen.

Kommandozeilen-Tests mit curl

Der curl-Befehl ist der zuverlaessigste Weg, Redirects zu testen, da er Ihnen genau zeigt, was der Server zurueckgibt:

curl -I https://www.beispiel.de/altes-produkt.html

Das -I-Flag fordert nur die Header an. Suchen Sie in der Antwort nach:

HTTP/1.1 301 Moved Permanently
Location: https://www.beispiel.de/neues-produkt

Ueberpruefen Sie, dass der Statuscode 301 ist (nicht 302) und dass der Location-Header auf die korrekte neue URL zeigt.

Um der Redirect-Kette zu folgen und jeden Hop zu sehen:

curl -IL https://www.beispiel.de/altes-produkt.html

Das -L-Flag weist curl an, Redirects zu folgen und zeigt Ihnen die Header bei jedem Schritt.

Massentests

Fuer grosse Redirect-Listen automatisieren Sie das Testen mit einer Schleife:

while IFS=, read -r old new; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.beispiel.de$old")
  echo "$old -> $status"
done < redirects.csv

Dies liest Ihre CSV-Datei, testet jede alte URL und gibt den HTTP-Statuscode aus. Jede URL, die nicht 301 zurueckgibt, erfordert Aufmerksamkeit.

Browser-Tests

Oeffnen Sie die Entwicklertools Ihres Browsers (F12), gehen Sie zum Netzwerk-Tab und navigieren Sie zu einer alten URL. Der Netzwerk-Tab zeigt die Anfragekette einschliesslich aller Redirects. Ueberpruefen Sie den Statuscode, das Redirect-Ziel und die endgueltige Seite, die geladen wird.

Google Search Console Inspektion

Verwenden Sie nach der Bereitstellung das URL-Inspektionstool in der Google Search Console, um zu pruefen, wie Google Ihre umgeleiteten URLs sieht. Geben Sie eine alte URL ein und sehen Sie, ob Google den Redirect erkennt und die neue URL entdeckt hat.

Redirect-Ketten und wie man sie vermeidet

Eine Redirect-Kette entsteht, wenn ein Redirect zu einem anderen Redirect fuehrt, der moeglicherweise zu noch einem weiteren fuehrt. Zum Beispiel: URL A leitet zu URL B weiter, die zu URL C weiterleitet, die schliesslich den Inhalt ausliefert. Jeder Hop fuegt Latenz hinzu und verwaessert die Link-Equity.

Warum Redirect-Ketten schaedlich sind

Google hat erklaert, dass es Redirect-Ketten folgen wird, aber mit Grenzen. Nach einer bestimmten Anzahl von Hops (typischerweise 5-10) gibt Googlebot auf und behandelt die URL als Fehler. Selbst bei kuerzeren Ketten verzoegert jeder Hop die Seitenauslieferung und verliert eine kleine Menge Link-Equity.

Fuer Besucher fuegt jeder Redirect 50-200 Millisekunden Latenz hinzu, abhaengig von Netzwerkbedingungen und Server-Antwortzeit. Eine Kette von 3 Redirects kann eine halbe Sekunde oder mehr zur wahrgenommenen Ladezeit hinzufuegen.

Haeufige Ursachen von Redirect-Ketten in PrestaShop

Die haeufigste Kette entsteht, wenn eine Migration Redirects auf bestehende Redirects aufbaut. Zum Beispiel koennten Sie alte Redirects von einer frueheren URL-Strukturaenderung haben, und die neue Migration fuegt eine weitere Schicht hinzu. URL A leitet zu URL B weiter (von der ersten Migration), und URL B leitet zu URL C weiter (von der zweiten Migration).

Eine weitere haeufige Ursache ist die Interaktion zwischen PrestaShops eingebautem kanonischem Redirect und Ihren benutzerdefinierten Redirects. PrestaShop koennte von einer nicht-kanonischen URL zur kanonischen Version weiterleiten, und wenn Ihr benutzerdefinierter Redirect ebenfalls uebereinstimmt, erhalten Sie eine Kette.

Die HTTPS-Erzwingung fuegt einen weiteren potenziellen Hop hinzu. Wenn Ihr Redirect auf eine HTTP-URL zeigt und der Server dann auf HTTPS weiterleitet, ist das eine Kette mit zwei Schritten.

Redirect-Ketten beheben

Pruefen Sie Ihre Redirects regelmaessig mit einem Crawling-Tool, das Ketten erkennt. Wenn Sie eine Kette finden, aktualisieren Sie den ersten Redirect so, dass er direkt auf das endgueltige Ziel zeigt. URL A sollte direkt zu URL C weiterleiten und URL B umgehen.

Pruefen Sie beim Hinzufuegen neuer Redirects waehrend einer Migration immer, ob die Ziel-URL selbst ein Redirect ist. Falls ja, setzen Sie den neuen Redirect so, dass er stattdessen auf das endgueltige Ziel zeigt.

Haeufige Fallstricke und wie man sie vermeidet

Endlose Redirect-Schleifen

Eine Endlosschleife entsteht, wenn URL A zu URL B weiterleitet und URL B zurueck zu URL A weiterleitet. Der Browser erkennt dies und zeigt einen ERR_TOO_MANY_REDIRECTS-Fehler an. Haeufige Ursachen sind widerspruechliche Regeln in der .htaccess (eine Regel leitet www auf non-www um, waehrend eine andere non-www auf www umleitet), widerspruechliche Redirects zwischen .htaccess und einem Redirect-Modul sowie Regex-Regeln, die zu breit sind und ihre eigenen Ziel-URLs treffen.

Um eine Schleife zu beheben, deaktivieren Sie zunaechst alle benutzerdefinierten Redirects und aktivieren Sie sie einzeln wieder, bis die Schleife erneut auftritt. Dies identifiziert die widerspruechliche Regel.

Query-Parameter vergessen

Standardmaessig leitet Apaches Redirect-Direktive Query-Parameter an die neue URL weiter. Allerdings leitet RewriteRule Query-Parameter nicht weiter, es sei denn, Sie fuegen das [QSA]-Flag (Query String Append) hinzu. Wenn Ihre alten URLs wichtige Query-Parameter enthalten (wie ?id_product=123), stellen Sie sicher, dass diese korrekt behandelt werden.

Gross-/Kleinschreibung

Auf Linux-Servern sind URLs gross-/kleinschreibungssensitiv. /Produkt.html und /produkt.html sind unterschiedliche URLs. Wenn Ihre alte Website gemischte Gross-/Kleinschreibung in URLs hatte und Ihre neue Website auf Kleinbuchstaben normalisiert, benoetigen Sie Redirects, die beide Faelle abdecken. Verwenden Sie das [NC]-Flag in RewriteRule fuer gross-/kleinschreibungsunabhaengigen Abgleich.

Nicht alle URL-Variationen umleiten

Eine einzelne Produktseite kann ueber mehrere URLs erreichbar sein: mit und ohne abschliessendem Schraegstrich, mit und ohne .html-Endung, mit und ohne Kategoriepfad-Praefix, mit und ohne www. Jede Variation, die indexiert wurde, benoetigt ihren eigenen Redirect zur neuen kanonischen URL.

Redirects fuer immer beibehalten

Waehrend Redirects mindestens 12 Monate nach einer Migration bestehen bleiben sollten (Google empfiehlt mindestens ein Jahr), sollten sie nicht unbegrenzt bestehen bleiben. Nach einem Jahr oder mehr sollten die alten URLs nicht mehr in Suchergebnissen erscheinen oder nennenswerten Traffic erhalten. Pruefen Sie Ihre Redirect-Logs, entfernen Sie Regeln, die nicht mehr ausgeloest werden, und halten Sie Ihre Konfiguration sauber.

Zusammenfassung

Die korrekte Einrichtung von 301-Redirects ist die wichtigste technische Aufgabe bei einer PrestaShop-Migration. Jede alte URL, die Traffic, Backlinks oder Suchmaschinen-Sichtbarkeit hatte, muss mit einem 301-Statuscode zu ihrem neuen Gegenstueck weiterleiten. Die Implementierungsmethode haengt von Ihrem Server ab (Apache .htaccess oder Nginx-Konfiguration), von der Anzahl der URLs (individuelle Regeln, Regex-Muster oder datenbankgestuetzte Module) und von den technischen Faehigkeiten Ihres Teams. Testen Sie jeden Redirect vor dem Go-Live mit curl oder Browser-Entwicklertools. Achten Sie auf Redirect-Ketten, Endlosschleifen und Gross-/Kleinschreibungsprobleme. Ueberwachen Sie die Google Search Console nach der Bereitstellung, um zu verifizieren, dass Google Ihre Redirects korrekt verarbeitet. Und denken Sie daran: Ein 302, wo ein 301 sein sollte, ist nie harmlos. Es ist immer die falsche Wahl fuer eine dauerhafte Migration.