PrestaShop-URL-Struktur: Saubere URLs, Canonicals und Duplicate Content vermeiden

Die URL-Struktur Ihres PrestaShop-Shops zu ändern, ist eine der wirkungsvollsten — und gefährlichsten — SEO-Aufgaben, die Sie in Angriff nehmen können. Richtig umgesetzt, beseitigt sie jahrelang angesammelte technische Schulden, eliminiert doppelte Inhalte und gibt Ihnen eine URL-Architektur, die mit Ihrem Katalog mitwächst. Falsch gemacht, kann sie Monate oder Jahre organischen Traffics über Nacht auslöschen.

Ich habe URL-Migrationen für PrestaShop-Shops durchgeführt, die von kleinen Boutiquen bis zu Katalogen mit über 30.000 Produkten reichten. Dieser Leitfaden handelt nicht davon, was in der Theorie eine „gute URL" ausmacht — davon gibt es genug Artikel. Dies ist die praktische Schritt-für-Schritt-Anleitung für Shopbetreiber, die ihre URLs tatsächlich ändern: wie Sie die Migration planen, 301-Weiterleitungen korrekt implementieren, den Übergang in der Google Search Console überwachen und reagieren, wenn etwas schiefgeht.

Wann sollten Sie Ihre URL-Struktur ändern?

URL-Änderungen bergen echte Risiken — stellen Sie also sicher, dass Sie es wirklich tun müssen. Hier sind berechtigte Gründe für eine URL-Umstrukturierung in PrestaShop:

• Kategoriepfade in Produkt-URLs verursachen Duplikate: PrestaShops Standardkonfiguration schließt den Kategoriepfad in Produkt-URLs ein (/bags/leather/blue-wallet). Wenn ein Produkt mehreren Kategorien angehört, wird es über mehrere URLs erreichbar — ein klassisches Duplicate-Content-Problem.
• Unnötige IDs in URLs: URLs wie /42-wallets oder /123-blue-leather-wallet.html bieten keinen SEO- oder Nutzermehrwert. Das Entfernen von IDs schafft sauberere, besser teilbare URLs.
• Sprachpräfixe bei einsprachigen Shops: Ein Shop, der nur deutschsprachige Kunden bedient, braucht kein /de/ in jeder URL.
• Veraltete .html-Erweiterungen: Einige PrestaShop-Konfigurationen hängen .html an jede URL an. Obwohl harmlos, entstehen durch das Entfernen kürzere, sauberere URLs.
• Plattformmigration: Der Wechsel von einem anderen CMS zu PrestaShop — oder von PrestaShop 1.6 zu 1.7/8.x — ändert oft automatisch die URL-Muster.
• Kategorie-Umstrukturierung: Eine Neuordnung Ihrer Kataloghierarchie ändert Kategorie-URLs und alle Produkt-URLs, die Kategoriepfade enthalten.

Wann Sie URLs NICHT ändern sollten

Wenn Ihre URLs funktionieren, indexiert sind und ranken — lassen Sie sie in Ruhe. Eine URL mit einer ID-Nummer, die auf Seite eins bei Google rankt, ist unendlich wertvoller als eine „sauberere" URL, die bei null anfängt. Kosmetische URL-Änderungen sind das Migrationsrisiko fast nie wert.

Die tatsächlichen Kosten von URL-Änderungen ohne Plan

Ich muss deutlich sagen, was passiert, wenn URL-Änderungen schiefgehen, denn ich habe es zu oft erlebt:

• Sofortiger Traffic-Einbruch von 20-60% — Google muss jede geänderte URL erneut crawlen und bewerten. Während dieser Phase können Seiten vorübergehend aus dem Index fallen.
• Verlorene Backlinks: Jede externe Website, die auf Ihre alten URLs verlinkt, trifft auf einen 404-Fehler, wenn Sie nicht weiterleiten. Diese Backlinks — oft über Jahre aufgebaut — übertragen ohne eine 301-Weiterleitung null Wert.
• Kaputte interne Links: Menüs, Footer, Produkt-Cross-Sells, CMS-Seitenlinks, E-Mail-Templates — alle enthalten fest codierte URLs, die nicht mehr funktionieren werden.
• Erholungszeit von 4-16 Wochen — Selbst bei perfekten Weiterleitungen braucht Google Zeit, um Änderungen zu verarbeiten. Semrush-Daten deuten darauf hin, dass die meisten korrekt durchgeführten Migrationen innerhalb von 8-12 Wochen 90-95% des Traffics zurückgewinnen (Quelle: Semrush).

Trotzdem: Wenn eine Migration notwendig ist — insbesondere zur Behebung doppelter Inhalte durch Kategoriepfade — überwiegt der langfristige SEO-Nutzen die kurzfristigen Kosten. Der Schlüssel ist die korrekte Durchführung.

Schritt 1: Ihre aktuelle URL-Landschaft analysieren

Bevor Sie etwas ändern, brauchen Sie ein vollständiges Bild Ihrer aktuellen URLs. Das bedeutet:

Ihre gesamte Website crawlen

Verwenden Sie Screaming Frog, Sitebulb oder einen beliebigen Crawler, um jede URL auf Ihrer Website zu erfassen. Exportieren Sie die vollständige Liste. Achten Sie bei einem PrestaShop-Shop besonders auf:

• Produkt-URLs mit Kategoriepfaden: Dasselbe Produkt, das unter /category-a/product und /category-b/product erreichbar ist
• URLs mit ID-Nummern: /42-category-name vs. /category-name
• Parameterbasierte URLs: ?id_product=123&controller=product — das sind nicht-SEO-freundliche URL-Versionen, die möglicherweise noch crawlbar sind
• Paginierte URLs: /category?page=2 bis /category?page=50

Google Search Console-Daten exportieren

Gehen Sie zu Search Console → Leistung → Seiten. Exportieren Sie alle URLs, die in den letzten 16 Monaten Impressionen oder Klicks erhalten haben. Das sind Ihre „wertvollen" URLs — diejenigen, die Google aktiv rankt. Jeder Migrationsplan muss jede einzelne davon berücksichtigen.

Backlink-Daten exportieren

Verwenden Sie Ahrefs, Semrush oder den Links-Bericht der Google Search Console, um zu identifizieren, welche Ihrer URLs externe Backlinks haben. Das sind Ihre Weiterleitungsziele mit höchster Priorität — den Backlink-Wert von hochautoritären verweisenden Domains zu verlieren, kann Jahre dauern, bis er wieder aufgebaut ist.

Den aktuellen Zustand dokumentieren

Erstellen Sie eine Tabelle mit Spalten für: aktuelle URL, HTTP-Status, Canonical-Tag-Wert, Anzahl der Backlinks, monatliche organische Klicks und neue Ziel-URL. Dies wird Ihre Migrationsübersicht — das wichtigste Dokument im gesamten Prozess.

Schritt 2: Ihre neue URL-Struktur entwerfen

Für PrestaShop-Shops empfehle ich folgende Prinzipien für die URL-Struktur:

Kategoriepfade aus Produkt-URLs entfernen

Dies ist die häufigste — und wichtigste — URL-Änderung für PrestaShop-Shops. Statt:

/bags/leather-bags/blue-leather-wallet

Verwenden Sie:

/blue-leather-wallet

Warum? Wenn ein Produkt mehreren Kategorien angehört, erzeugt der Ansatz mit Kategoriepfaden mehrere URLs für dasselbe Produkt. PrestaShop versucht, dies mit Canonical Tags zu lösen, aber in der Praxis habe ich gesehen, dass Google trotzdem beide Versionen indexiert und dabei Ranking-Signale über Duplikate verteilt.

Eine flache Produkt-URL-Struktur — bei der Produkte auf der Stammebene liegen — beseitigt dieses Problem vollständig. Jedes Produkt hat genau eine URL, unabhängig davon, wie vielen Kategorien es angehört. Tools wie der Smart SEO Friendly URL Manager machen diese Änderung in PrestaShop unkompliziert.

Kategorie-URLs mit Hierarchie beibehalten (aber flach halten)

Kategorien profitieren von Hierarchie in URLs, weil sie sowohl Nutzern als auch Suchmaschinen die Struktur vermittelt:

/bags/leather-bags    ✓ Gut — klare Eltern-/Kind-Beziehung
/bags/leather-bags/casual/everyday    ✗ Zu tief — auf 2 Ebenen beschränken

IDs, Erweiterungen und unnötige Präfixe entfernen

/42-wallets            → /wallets
/blue-wallet.html      → /blue-wallet
/en/wallets            → /wallets  (einsprachige Shops)
/home/1-home.html      → /         (Startseite)

Bindestriche verwenden, immer Kleinbuchstaben

Google behandelt Bindestriche als Worttrennzeichen (blue-wallet = „blue" + „wallet"), aber Unterstriche als Verbinder (blue_wallet = „bluewallet"). Verwenden Sie immer Bindestriche. Verwenden Sie immer Kleinbuchstaben — URLs unterscheiden Groß- und Kleinschreibung, und /Blue-Wallet ist eine andere URL als /blue-wallet.

Schritt 3: Ihre Weiterleitungszuordnung erstellen

Dies ist der arbeitsintensivste Schritt und derjenige, bei dem Fehler am teuersten sind. Jede alte URL, die jemals indexiert wurde, verlinkt wurde oder Traffic erhalten hat, muss auf ihr neues Äquivalent umgeleitet werden.

Eins-zu-eins-Zuordnung

Die goldene Regel: Jede alte URL leitet auf ihr direktes Äquivalent weiter. Nicht auf die Startseite. Nicht auf eine Kategorieseite. Auf genau denselben Inhalt unter seiner neuen URL.

/42-wallets                      → /wallets
/bags/leather-bags/blue-wallet   → /blue-wallet
/123-blue-wallet.html            → /blue-wallet
/en/bags/wallets                 → /bags/wallets

Gelöschte Seiten korrekt behandeln

Für Produkte, die nicht mehr existieren, haben Sie drei Optionen — in der Reihenfolge der Präferenz:

1. Auf das nächstliegende äquivalente Produkt weiterleiten — wenn Sie „Blaue Geldbörse v1" eingestellt und durch „Blaue Geldbörse v2" ersetzt haben, leiten Sie auf das neue Produkt weiter.
2. Auf die übergeordnete Kategorie weiterleiten — wenn kein direktes Äquivalent existiert, schicken Sie Nutzer auf die Kategorieseite, wo sie Alternativen finden können.
3. Einen 410-Gone-Status zurückgeben — wenn das Produkt kein Äquivalent hat und die Kategorie ebenfalls entfernt wurde, sagt ein 410-Status Google, die URL schneller aus dem Index zu entfernen als ein 404.

Leiten Sie niemals alles auf die Startseite weiter. Google nennt das einen „Soft 404", und es bietet null SEO-Wert — die Ranking-Signale der alten URL gehen einfach verloren.

Weiterleitungsketten vermeiden

Eine Weiterleitungskette entsteht, wenn URL A auf URL B weiterleitet, die wiederum auf URL C weiterleitet. Jeder Sprung fügt Latenz hinzu (typischerweise 50-200ms pro Weiterleitung), und obwohl Google sagt, sie folgen bis zu 5 Sprüngen, kann der Link-Wert durch Ketten abnehmen. Noch wichtiger: Ketten sind ein Wartungsalptraum, der sich bei aufeinanderfolgenden Migrationen potenziert.

Leiten Sie immer direkt von der ursprünglichen URL zum endgültigen Ziel weiter:

✗ Schlecht:  /old-url → /intermediate-url → /final-url
✓ Gut: /old-url → /final-url

Wenn Sie bestehende Weiterleitungen aus einer früheren Migration haben, aktualisieren Sie diese so, dass sie direkt auf die neuen URLs zeigen, anstatt über den Zwischenschritt zu verketten.

Schritt 4: 301-Weiterleitungen in PrestaShop implementieren

Es gibt mehrere Möglichkeiten, Weiterleitungen in PrestaShop zu implementieren, jeweils mit unterschiedlichen Vor- und Nachteilen:

Methode 1: .htaccess-Regeln (Apache)

Die schnellste und server-effizienteste Methode. Weiterleitungen werden auf Webserver-Ebene ausgeführt, noch bevor PrestaShop geladen wird:

# Individuelle Produkt-Weiterleitungen
RewriteRule ^42-wallets$ /wallets [R=301,L]
RewriteRule ^bags/leather-bags/blue-wallet$ /blue-wallet [R=301,L]

# Musterbasierte Weiterleitungen (.html-Erweiterung entfernen)
RewriteRule ^(.+)\.html$ /$1 [R=301,L]

# Musterbasierte Weiterleitungen (ID-Präfix entfernen)
RewriteRule ^[0-9]+-(.+)$ /$1 [R=301,L]

# Sprachpräfix für einsprachige Shops entfernen
RewriteRule ^en/(.*)$ /$1 [R=301,L]

Platzieren Sie Weiterleitungsregeln vor PrestaShops eigenen Rewrite-Regeln in der .htaccess. Die Flags [R=301,L] bedeuten: 301-Status zurückgeben (permanente Weiterleitung) und keine weiteren Regeln mehr verarbeiten.

Vorteile: Schnellste Ausführung, kein PHP-Overhead, funktioniert selbst wenn PrestaShop nicht läuft.
Nachteile: Erfordert manuelle Pflege, Regex-Fehler können die gesamte Website lahmlegen, nur Apache.

Methode 2: PrestaShop-Modul

Ein Weiterleitungsmanagement-Modul bietet eine datenbankgestützte Oberfläche zum Erstellen und Verwalten von Weiterleitungen. Das ist der Ansatz, den ich für die meisten Shops empfehle, weil:

• Nicht-technisches Personal kann Weiterleitungen über das Admin-Panel verwalten
• Massenimport aus CSV — entscheidend für große Migrationen mit Tausenden von Weiterleitungen
• Automatische 404-Erkennung mit Weiterleitungsvorschlägen
• Kein Risiko, die .htaccess-Syntax zu beschädigen

Methode 3: Nginx-Konfiguration

Für Shops, die auf Nginx laufen (einschließlich vieler Docker-basierter Deployments), werden Weiterleitungen in der Serverkonfiguration definiert:

location = /42-wallets {
    return 301 /wallets;
}

# Musterbasierte Weiterleitung
location ~ ^/(\d+)-(.+)$ {
    return 301 /$2;
}

Nginx erfordert nach Konfigurationsänderungen einen Reload (nginx -s reload), aber Weiterleitungen werden schneller ausgeführt als Apaches .htaccess-Ansatz, da die Konfiguration in den Arbeitsspeicher geladen wird statt pro Anfrage von der Festplatte gelesen zu werden.

Schritt 5: Alles aktualisieren, das auf alte URLs verweist

Weiterleitungen sind ein Sicherheitsnetz, keine Lösung. Jede interne Referenz auf alte URLs sollte aktualisiert werden, um direkt auf die neuen URLs zu zeigen. Sich bei der internen Navigation auf Weiterleitungen zu verlassen, verschwendet Crawl-Budget und fügt unnötige Latenz hinzu.

Zu aktualisierende interne Links

• Navigationsmenüs — Hauptmenü, Footer-Links, Seitenleisten-Navigation
• CMS-Seiteninhalte — alle fest codierten Links in „Über uns", „Versandrichtlinien" usw.
• Produktbeschreibungen — Querverweise auf andere Produkte oder Kategorien
• E-Mail-Templates — Bestellbestätigung, Versandbenachrichtigung, Warenkorbabbrecher-E-Mails
• XML-Sitemap — sofort mit ausschließlich neuen URLs regenerieren (siehe unseren Sitemap-Leitfaden)
• Social-Media-Profile — alle Links in Ihrer Bio, angehefteten Beiträgen oder Anzeigen
• Google Merchant Center-Feed — Produkt-URLs in Ihrem Shopping-Feed müssen die neue Struktur widerspiegeln
• Strukturierte Daten — JSON-LD-Markup auf Produktseiten enthält URLs, die aktualisiert werden müssen

URL-Bereinigung auf Datenbankebene

PrestaShop speichert URLs in mehreren Datenbanktabellen. Überprüfen Sie nach der Änderung Ihres URL-Schemas, dass diese Tabellen die neue Struktur widerspiegeln:

• ps_product_lang — die Spalte link_rewrite
• ps_category_lang — die Spalte link_rewrite
• ps_cms_lang — die Spalte link_rewrite

Wenn Sie Ihre SEO-freundlichen URL-Einstellungen geändert haben (Kategoriepfad entfernt, IDs entfernt), regeneriert PrestaShop URLs aus diesen link_rewrite-Werten. Stellen Sie sicher, dass sie sauber sind — keine Sonderzeichen, keine Großbuchstaben, keine Unterstriche.

Schritt 6: Die Canonical-Tag-Strategie

Selbst mit sauberen URLs und korrekten Weiterleitungen bleiben Canonical Tags unverzichtbar. Sie sind Ihre explizite Erklärung an Suchmaschinen: „Dies ist die offizielle Version dieser Seite."

Selbstreferenzierende Canonicals

Jede Seite in Ihrem Shop sollte einen Canonical Tag haben, der auf sich selbst zeigt. Dies schützt vor unbeabsichtigtem Duplicate Content durch Tracking-Parameter, Session-IDs oder andere URL-Variationen:

<link rel="canonical" href="https://yourstore.com/blue-leather-wallet" />

In PrestaShop werden Canonical Tags für Produkt- und Kategorieseiten automatisch generiert — überprüfen Sie aber, dass sie die neue URL-Struktur verwenden und nicht die alte. Das Modul Product Canonical Manager gibt Ihnen detaillierte Kontrolle über die Canonical-Tag-Generierung.

Canonicals für paginierte Inhalte

Kategorieseiten mit Paginierung verdienen besondere Aufmerksamkeit. Google hat die Unterstützung für rel="prev"/rel="next" vor Jahren eingestellt, daher lautet die aktuelle Best Practice:

• Jede paginierte Seite (/wallets?page=1, /wallets?page=2) erhält einen selbstreferenzierenden Canonical
• Alternativ können Sie alle paginierten Seiten auf Seite 1 kanonisieren — aber das bedeutet, dass Produkte auf Seite 2+ nur durch interne Links auffindbar sind, nicht über die Sitemap
• Eine weitere Option sind „Alle anzeigen"-Seiten, wenn Ihre Kataloggröße es erlaubt — eine einzelne Seite mit allen Produkten der Kategorie

Domainübergreifende Canonicals

Wenn Sie ein PrestaShop-Multishop-Setup mit Produkten betreiben, die über mehrere Domains geteilt werden, verhindern domainübergreifende Canonical Tags doppelte Inhalte über Shops hinweg. Der Canonical auf store-b.com/blue-wallet kann auf store-a.com/blue-wallet zeigen, um Ranking-Signale zu konsolidieren.

Schritt 7: Crawl-Budget und warum es wichtig ist

Das Crawl-Budget ist die Anzahl der Seiten, die der Googlebot innerhalb eines bestimmten Zeitraums auf Ihrer Website crawlen wird. Für kleine Shops (unter 1.000 Seiten) ist das Crawl-Budget selten ein Problem. Für größere Kataloge beeinflusst es direkt, wie schnell neue Seiten entdeckt und wie häufig bestehende Seiten erneut gecrawlt werden.

URL-Migrationen beeinflussen das Crawl-Budget auf verschiedene Weise:

• Weiterleitungsverarbeitung verbraucht Crawl-Budget: Jede 301-Weiterleitung, auf die der Googlebot trifft, zählt als eine gecrawlte URL. Wenn Sie 10.000 Weiterleitungen haben und Google sie alle besucht, sind das 10.000 Crawls, die für Weiterleitungen statt für tatsächliche Inhaltsseiten aufgewendet werden.
• Doppelte URLs verdoppeln den Crawl-Bedarf: Wenn alte URLs weiterhin erreichbar bleiben (200 statt 301 zurückgeben), crawlt Google möglicherweise beide Versionen — das verdoppelt den Crawl-Aufwand bei null zusätzlichem Wert.
• Weiterleitungsketten vervielfachen die Kosten: Eine Kette von A → B → C zählt als drei gecrawlte URLs für ein Stück Inhalt.

Die Lösung: Weiterleitungen korrekt implementieren (direkt, keine Ketten), interne Links auf neue URLs aktualisieren (weniger Weiterleitungstreffer) und Ihre XML-Sitemap nur mit neuen URLs regenerieren.

Schritt 8: Die Migration in der Google Search Console überwachen

Nach dem Deployment Ihrer URL-Änderungen und Weiterleitungen ist die Überwachung entscheidend. Hier ist eine wochenweise Anleitung:

Tag 1-3: Überprüfen, ob die Weiterleitungen funktionieren

• Testen Sie 50-100 alte URLs manuell (oder mit einem Crawler). Jede sollte einen 301-Status mit dem korrekten Ziel zurückgeben.
• Prüfen Sie Ihre Serverlogs auf 404-Fehler — jeder Anstieg deutet auf fehlende Weiterleitungen hin.
• Reichen Sie Ihre aktualisierte Sitemap in der Google Search Console erneut ein.

Woche 1-2: Erste Auswirkungsbewertung

• Erwarten Sie einen Traffic-Rückgang von 10-30%. Das ist normal und kein Grund zur Beunruhigung.
• Überwachen Sie den „Seiten"-Bericht in der Search Console auf neue Crawl-Fehler.
• Achten Sie auf „Weiterleitung"-Einträge — diese bestätigen, dass Google Ihre 301s entdeckt und befolgt.
• Prüfen Sie, ob alte URLs im „Leistung"-Bericht schrittweise durch neue URLs ersetzt werden.

Woche 3-6: Erholungsphase

• Der Traffic sollte sich erholen, während Google Weiterleitungen verarbeitet und Rankings neu berechnet.
• Überwachen Sie Seiten, die aus dem Index gefallen sind — prüfen Sie, ob ihre Weiterleitung korrekt funktioniert.
• Achten Sie auf den Status „Gecrawlt – zurzeit nicht indexiert" bei neuen URLs. Dies kann auf dünne Inhalte oder Qualitätsprobleme hinweisen, die nichts mit der Migration zu tun haben.

Woche 8-12: Stabilisierung

• In Woche 8-12 sollte der Traffic bei 90-100% des Niveaus vor der Migration liegen.
• Wenn der Traffic in Woche 12 noch um 20%+ gesunken ist, untersuchen Sie einzelne Seiten — das Problem liegt wahrscheinlich bei individuellen Weiterleitungen, nicht bei der Migration insgesamt.
• Beginnen Sie mit der Überprüfung von Weiterleitungsketten — mit der Zeit aktualisieren Drittanbieter-Websites ihre Links, wodurch einige Weiterleitungen überflüssig werden.

Fortlaufend: Wann Weiterleitungen entfernt werden können

Google empfiehlt, Weiterleitungen mindestens ein Jahr lang beizubehalten. Danach sollten hochwertige Weiterleitungen (Seiten mit Backlinks) dauerhaft bestehen bleiben. Geringwertige Weiterleitungen (Seiten ohne Backlinks und ohne Suchtraffic) können nach 12-18 Monaten entfernt werden und dürfen dann einen 404/410-Status zurückgeben.

Mehrsprachige Shops handhaben

Mehrsprachige PrestaShop-Shops stehen vor zusätzlicher URL-Komplexität. Jedes Produkt existiert unter /en/blue-wallet, /de/blaue-brieftasche, /fr/portefeuille-bleu usw. Bei der URL-Umstrukturierung müssen Sie:

• Sprachpräfixe für mehrsprachige Shops beibehalten (sie erfüllen einen echten Zweck — sie teilen Google mit, welche Sprachversion ausgeliefert werden soll)
• Sicherstellen, dass hreflang-Tags über alle Sprachversionen hinweg auf die neuen URLs zeigen
• Weiterleitungen für jede Sprachvariante erstellen — wenn Sie die englische URL ändern, brauchen Sie entsprechende Weiterleitungen für Deutsch, Französisch und jede andere Sprache
• Die link_rewrite-Werte in der Datenbank für alle Sprachen aktualisieren, nicht nur für die Standardsprache

Die Anzahl der Weiterleitungen multipliziert sich mit der Anzahl der Sprachen. Ein Shop mit 5.000 Produkten in 4 Sprachen benötigt möglicherweise 20.000 Weiterleitungen für eine vollständige URL-Umstrukturierung.

Das Duplicate-Content-Problem in PrestaShop: Grundursachen

Bevor wir abschließen, möchte ich die spezifischen Duplicate-Content-Probleme ansprechen, die ich in PrestaShop am häufigsten sehe — denn das Verständnis dieser Probleme hilft Ihnen, eine URL-Struktur zu entwerfen, die Probleme verhindert, anstatt sie nur zu beheben:

Produkte in mehreren Kategorien

Ein Produkt, das sowohl der Kategorie „Sale" als auch „Geldbörsen" zugeordnet ist, erzeugt zwei URLs. PrestaShop fügt Canonical Tags hinzu, aber die sicherste Lösung ist, Kategoriepfade vollständig aus Produkt-URLs zu entfernen.

www vs. nicht-www

Wenn sowohl www.yourstore.com als auch yourstore.com auf Ihren Shop verweisen, ohne dass eine Weiterleitung eingerichtet ist, wird jede Seite dupliziert. Beheben Sie das mit einer 301-Weiterleitung in der .htaccess oder der Serverkonfiguration — wählen Sie eine Version und leiten Sie die andere weiter.

HTTP vs. HTTPS

Dasselbe Problem wie bei www/nicht-www. Wenn http://yourstore.com noch erreichbar ist, leiten Sie es mit einem 301 auf https:// weiter.

Abschließende Schrägstriche

/wallets und /wallets/ sind technisch gesehen unterschiedliche URLs. Entscheiden Sie sich für eine Konvention und leiten Sie die andere weiter. PrestaShops Standard ist kein abschließender Schrägstrich — bleiben Sie dabei, es sei denn, Sie haben einen bestimmten Grund dagegen.

Session-IDs und Tracking-Parameter

/blue-wallet?utm_source=newsletter&utm_medium=email — wenn Ihre Canonical Tags korrekt sind, wird das abgedeckt. Überprüfen Sie aber, dass PrestaShop keine Canonical Tags generiert, die Tracking-Parameter enthalten.

Fazit: Eine Migration ist ein Projekt, kein Schnellfix

Eine PrestaShop-URL-Migration ist nichts, was man an einem Freitagnachmittag erledigt. Es ist ein Projekt, das eine Analyse, einen Plan, eine Weiterleitungszuordnung, Implementierung, Aktualisierung interner Links, Sitemap-Regenerierung und wochenlange Überwachung erfordert. Aber wenn doppelte Inhalte Ranking-Signale über mehrere URLs verteilen oder eine URL-Struktur Crawl-Budget mit Parametervariationen verschwendet — ist die Migration es wert.

Planen Sie sorgfältig, leiten Sie alles weiter, aktualisieren Sie alle internen Verweise, überwachen Sie wöchentlich in der Search Console und geben Sie Google 8-12 Wochen Zeit, die Änderungen zu verarbeiten. Ich habe noch nie erlebt, dass eine gut durchgeführte Migration sich nicht erholt hat. Ich habe viele schlecht geplante gesehen, die dauerhaften Schaden angerichtet haben.

Nehmen Sie sich die Zeit, es richtig zu machen.