PrestaShop-URLs, Canonicals und Weiterleitungen

So würden wir vorgehen

Wir würden die Aufgabe vor der Werkzeugwahl einordnen: eine Korrektur der aktuellen URL-Regeln, eine neue Routing-Anforderung oder ein Umzug des Shops selbst. Der richtige Weg hängt von Ihrem bestehenden Shop ab: konfigurierten Mustern, Modulen, Theme, Katalogdaten, Integrationen, Sprachen und Zielmärkten sowie davon, wer die Weiterleitungen anschließend pflegt. Beziehen Sie vom Theme und von Modulen erzeugte Links, importierte Slugs und Integrationsendpunkte in diese Bewertung ein.

Nehmen Sie die vereinbarte Änderung auf einer geschützten Staging-Kopie mit denselben Routing-Komponenten und repräsentativen Katalogdaten vor. Isolieren Sie die Kopie von produktiven Kunden-E-Mails, Zahlungen und Bestands- oder ERP-Exporten. Erproben Sie die Routenzuordnung und Kaufabläufe und planen Sie dann die Live-Umschaltung mit einer benannten zuständigen Person, gesicherter Konfiguration und einer Möglichkeit, die Änderung rückgängig zu machen. Bewahren Sie die freigegebene Zuordnung und Testergebnisse gemeinsam auf, damit die Live-Veröffentlichung die tatsächlich getesteten Regeln verwendet.

Wenn Sie Belege und Prioritäten vor der Umsetzung prüfen lassen möchten, bietet das PrestaShop SEO Audit & Action Plan eine schreibgeschützte Prüfung und einen geordneten Maßnahmenplan; die Umsetzung ist separat.

Native URLs vor einer Änderung verstehen

Prüfen Sie die tatsächlichen Routen des Shops vor einer Umstrukturierung. Nutzen Sie in modernen Versionen Shop-Einstellungen > Traffic & SEO. In PrestaShop 1.6 nutzen Sie Voreinstellungen > SEO & URLs.

• Benutzerfreundliche URL: PS_REWRITING_SETTINGS aktiviert lesbare Routen. Apache benötigt funktionierende Rewrite-Konfiguration; Nginx eigene passende Serverregeln.
• URL mit Akzentzeichen: PS_ALLOW_ACCENTED_CHARS_URL steuert Slugs mit Akzentzeichen. Wählen Sie eine konsistente Zeichenrichtlinie und testen Sie Kodierung, statt Nicht-ASCII-URLs für ungültig zu halten.
• Kanonische Weiterleitung: PS_CANONICAL_REDIRECT steuert native Weiterleitungen zu bevorzugten URLs für unterstützte Seiten. Testen Sie die tatsächliche Antwort, nicht nur die Einstellung.

Native Produkt-, Kategorie- und CMS-Routen verwenden Kennungen. Produktmuster in PrestaShop 1.7/8 können Kategorieinformationen enthalten. Die Standardproduktregel in PrestaShop 9 lautet {id}{-:id_product_attribute}-{rewrite}.html, ohne Kategorie. Aktualisierte Shops können konfigurierte Muster behalten.

Die Zuordnung eines Produkts zu zwei Kategorien lässt native Links nicht automatisch jede Kategorie verwenden. Alternative Kategoriepfadanfragen können aufgelöst werden, während normale Linkgenerierung und kanonische Weiterleitung sie zusammenführen. Prüfen Sie generierte Links, HTML-Canonical-Tags und HTTP-Antworten vor einer Strukturänderung.

Eine ID beizubehalten ist eine gültige Gestaltungsentscheidung. Benötigen Sie ein Muster ohne ID wie /blue-wallet, brauchen Sie Routing, das es auflöst. Einfach {id} zu löschen oder auf einen schöneren Pfad weiterzuleiten implementiert diese Route nicht.

Ändern Sie eine funktionierende Struktur, um ein definiertes Problem zu lösen, etwa defektes Routing oder dauerhaft inkonsistente Links. Nehmen Sie nicht an, das Entfernen von IDs, Erweiterungen oder einer Kategoriekomponente verbessere allein die Rankings.

Slugs, Sprachen, Shops und Routenkollisionen prüfen

Die Werte von link_rewrite liegen in Sprachtabellen wie product_lang, category_lang und cms_lang. Sie können auch shopbezogen sein. Eine Slugprüfung muss Sprach- und Shopkontext erhalten.

Dieses schreibgeschützte Beispiel prüft wiederholte Produktslugs in Shop 1 und Sprache 1. Ersetzen Sie Tabellenpräfix und Geltungsbereich nach Bedarf.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS distinct_products
FROM ps_product_lang
WHERE id_shop = 1 AND id_lang = 1
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1
ORDER BY distinct_products DESC, link_rewrite;

Ein wiederholter Slug ist auf nativen ID-basierten Routen nicht zwingend eine Kollision. Prüfen Sie bei einem Resolver ohne IDs den vollständigen generierten Pfad über Produkte, Kategorien, CMS, Marken, Lieferanten und Modulrouten hinweg. Zwei unterschiedliche Entitätstypen können denselben Pfad beanspruchen, auch wenn jede Tabelle intern keine Dubletten hat.

Testen Sie die gewählte Kollisionsrichtlinie und ergänzte Suffixe. Ein Manager für lesbare URLs kann eine ID, laufende Nummer, Referenz oder andere Unterscheidung anhängen. Versprechen Sie niemals, jede resultierende URL sei zahlenfrei.

Führen Sie ein Routeninventar für jede veröffentlichte Sprache und jeden Shop. Prüfen Sie leere Slugs, alternative Kodierungen, Groß-/Kleinschreibung, Entscheidungen zu Suffixen und abschließenden Schrägstrichen, Sprachpräfixe und etwaige Installationsunterverzeichnisse.

Kanonische URLs, Domains und Parameter abstimmen

Wählen Sie eine bevorzugte Host- und HTTPS-Form. Sobald HTTPS mit einem gültigen Zertifikat funktioniert, prüfen Sie die PrestaShop-Einstellungen „SSL aktivieren“ und „SSL auf allen Seiten aktivieren“, auch für Anfragen über ein CDN oder einen Proxy. Testen Sie Varianten mit und ohne www sowie mit HTTP und HTTPS gemeinsam, auch über das CDN. Verwenden Sie Ihren vertrauenswürdigen konfigurierten Host als Weiterleitungsziel, um Schleifen oder unsicheres Verhalten durch nicht vertrauenswürdige Host-Header zu vermeiden.

Stellen Sie native kanonische Weiterleitung, wo passend, auf dauerhaft um und testen Sie dann Produkt- und Kategorieanfragen. In PrestaShop 1.7.8 und 9 verwendet PS_CANONICAL_REDIRECT 0 für keine Weiterleitung, 1 für temporäre 302 und 2 für permanente 301. Die kanonische Core-Weiterleitung gilt für GET-Anfragen; prüfen Sie daher eine echte GET-Antwort. Ein Canonical-Tag ist ein Präferenzsignal; es verhindert nicht, dass Besucher eine andere URL öffnen.

• Generieren Sie interne Links im bevorzugten Format.
• Nutzen Sie für gleichwertige Varianten mit Trackingparametern einen passenden Canonical.
• Prüfen Sie Seitennavigation und gefilterte Seiten nach tatsächlichem Inhalt und Indexierungsrichtlinie.
• Lassen Sie Sprachalternativen auf ihre eigenen korrekten, indexierbaren URLs zeigen.
• Fassen Sie tatsächlich unterschiedliche Seiten nicht nur deshalb kanonisch zusammen, weil ihre Adressen ähnlich aussehen.

Wenden Sie keine websiteweite Schrägstrich-Entfernungsregel auf Dateien, Verzeichnisse und Routen an, ohne deren Semantik zu prüfen. Funktionale Parameter können Variante, Filter, Sprache oder Sitzungsaktion wählen. Sie unterscheiden sich von entbehrlichem Kampagnentracking.

Prüfen Sie HTML-Quelltext, Antwortheader, interne Links und Sitemap-Einträge auf widersprüchliche Signale. Siehe Googles Hinweise zu kanonischen URLs.

Enthält der Quelltext konkurrierende Canonical-Tags, ermitteln Sie deren Quellen: Theme, SEO-Modul oder individueller Code. Legen Sie fest, welche Komponente diese Ausgabe verantwortet, statt ein weiteres Tag hinzuzufügen. Ändert sich die Ausgabe erst nach einer Cache-Leerung, prüfen Sie Anwendungs- und CDN-Caching, bevor Sie die Regel bewerten. Vergleichen Sie neben dem Standard-Frontoffice auch die betroffene Sprache und den Shop; eine korrekte Seite in der Standardsprache belegt keine Korrektheit in anderen Kontexten.

Die Zuordnung alter zu endgültigen URLs erstellen

Inventarisieren Sie aktuellen Katalog und Routenkonfiguration, crawlen Sie erreichbare Seiten, prüfen Sie Sitemaps und Serverprotokolle und ergänzen Sie Leistungs-/Linkdaten der Search Console sowie bekannte externe Links. Der Indexierungsbericht der Search Console liefert Beispiele, keine vollständige Liste aller indexierten URLs; siehe seine Berichtsdokumentation.

Erfassen Sie alte URL, Shop/Sprache, Status, aktuellen Canonical, relevanten Traffic/Backlinks, vorgesehene endgültige URL und erwartete Antwort. Lassen Sie unveränderte URLs unverändert. Beziehen Sie bei Umzügen Bilder, Downloads und wichtige Modulseiten ein.

Ergänzen Sie die Belegquelle und die Entität, die jede Zeile repräsentiert. Ein aktueller Crawl kann keine historische Adresse entdecken, auf die keine aktuelle Seite verlinkt, und Protokolle decken nur den aufbewahrten Zeitraum ab. Markieren Sie unbekannte Ziele zur Prüfung, statt sie stillschweigend wegzulassen. Priorisieren Sie wertvolle Einstiegsseiten und defekte Kauflinks, werten Sie eine leere Traffic-Spalte aber nicht als Beweis dafür, dass eine Adresse ungenutzt ist.

1. Konfigurieren und testen Sie zuerst das Zielrouting.
2. Ordnen Sie geänderte Seiten direkt ihrem entsprechenden endgültigen Ziel zu.
3. Prüfen Sie wichtige eingestellte Seiten auf einen relevanten Ersatz oder eine gleichwertige zusammengeführte Seite.
4. Nutzen Sie 404 oder 410, wenn eine Seite entfernt ist und keine passende Entsprechung hat.
5. Richten Sie frühere Weiterleitungsketten auf die endgültige URL aus.

Eine übergeordnete Kategorie ist nicht automatisch ein gleichwertiges Ziel für ein eingestelltes Produkt. Pauschale Startseiten- oder Kategorieweiterleitungen können Nutzer irreführen und als Soft-404 behandelt werden. 410 garantiert keine schnellere Entfernung als 404; siehe Googles Hinweise zu gelöschten Seiten.

Nutzen Sie 301 oder 308 für dauerhafte Umzüge und den passenden temporären Status für vorübergehende. 302 verhindert die Zusammenführung von Signalen nicht grundsätzlich; seine Indexierungsabsicht unterscheidet sich. Permanente Weiterleitungen verlieren nicht zwangsläufig bei jedem Sprung PageRank. Kürzen Sie Ketten für geringere Latenz, effizienteres Crawling und weniger Fehlerstellen. Siehe Googles Weiterleitungshinweise.

Ziele anhand von Praxisbeispielen testen

Ein Produkt hat alte Kategoriepfade

Angenommen, Ihre Prüfung findet die historischen Adressen /bags/42-blue-wallet.html und /sale/42-blue-wallet.html für dasselbe Produkt, und Sie geben /42-blue-wallet.html als endgültige Route frei. Bestätigen Sie die Produktidentität, bevor Sie beide Aliase direkt dieser Adresse zuordnen. Wird das Produkt später aus der Sale-Kategorie entfernt, darf der alte Sale-Link nicht auf eine allgemeine Angebotsliste führen.

Testen Sie einen gespeicherten Link, der auch eine Produktvariante auswählt. Folgen Sie ihm bis zur Produktseite, legen Sie den Artikel in den Warenkorb und prüfen Sie die resultierende Größe, den Preis und die Bestandsauswahl. Eine Weiterleitung, die zwar beim richtigen Produkt endet, aber die gewählte Kundenvariante stillschweigend verwirft, besteht diesen Test nicht. Prüfen Sie denselben Ablauf über einen Feed- oder Kampagnenlink, statt nur einen frisch vom Shop erzeugten Link zu testen.

Ein Produkt und eine Inhaltsseite beanspruchen denselben Slug

Angenommen, ein Produkt ohne ID in der URL und eine CMS-Seite beanspruchen beide /summer-sale. Eine Prüfung nur der Produktslugs deckt diesen Konflikt nicht auf. Entscheiden Sie, welche Entität die Adresse behält, und geben Sie der anderen eine eigene Route, bevor Sie eine der Änderungen veröffentlichen. Dokumentieren Sie diese Zuordnung in der Übersicht; eine Änderung der Weiterleitungspriorität kann dieselbe Adresse nicht beide vorgesehenen Seiten ausliefern lassen.

Exakte Apache-Weiterleitungen implementieren

Platzieren Sie individuelle Regeln außerhalb und vor PrestaShops generiertem Rewrite-Block. Halten Sie ein Konfigurationsbackup vor, validieren Sie den Server und testen Sie auf Staging, bevor Sie das Produktivsystem neu laden. Nutzen Sie einen bewusst gewählten Weiterleitungsmechanismus; eine Mischung aus mod_alias und mod_rewrite kann überraschende Reihenfolgen erzeugen.

Diese Beispiele gehören in eine .htaccess im Shopstamm einer Rootinstallation. Sie ordnen exakte alte Pfade getesteten nativen Endrouten auf der Beispieldomain zu.

RewriteEngine On
RewriteRule ^old-wallet\.html$ https://www.example.com/42-blue-wallet.html [R=301,L]
RewriteRule ^old-category/$ https://www.example.com/3-wallets [R=301,L]

Die Anker machen diese Pfadabgleiche exakt. RewriteRule sieht in diesem Kontext keinen führenden Schrägstrich und gleicht den Pfad ohne Queryargumente ab. Diese Regeln erhalten vorhandene Argumente standardmäßig. Nutzen Sie QSD nur, wenn Sie sie bewusst verwerfen und bestätigt haben, dass sie keinen erforderlichen Zustand tragen.

Passen Sie bei einem Shop unter /shop/ sowohl den Regelkontext als auch die Zielpfade an. Eine alte Anfrage an index.php?id_product=42&controller=product benötigt eine Behandlung mit Berücksichtigung der Query-Parameter oder ein getestetes natives Canonical-Verhalten; eine reine Pfadregel für index.php würde viele nicht zusammengehörige Seiten erfassen.

Die einfache Anweisung Redirect nutzt Pfadpräfixabgleich und hängt nicht abgeglichene Pfadinformationen an. Nutzen Sie verankertes RedirectMatch oder eine getestete verankerte Rewrite-Regel für exakte Zuordnungen. Siehe die Apache-Redirect-Dokumentation.

Nutzen Sie keine pauschale Regel zum „Entfernen numerischer Präfixe“ oder „Entfernen von .html“, bevor jede Zielroute nachweislich funktioniert. Solche Regeln können Produkte, Kategorien und andere Endpunkte betreffen und bei aufeinanderfolgender Ausführung Ketten erzeugen.

Eine Pfadzuordnung in Nginx implementieren

Definieren Sie für eine größere reine Pfadzuordnung map im http-Kontext und nutzen Sie es im relevanten Serverblock. Dieses Beispiel verwendet verankerte, groß-/kleinschreibungssensitive reguläre Ausdrücke und erhält Queryargumente bewusst.

# http context
map $uri $migration_target {
    default "";
    ~^/old-wallet[.]html$ /42-blue-wallet.html;
    ~^/old-category/$ /3-wallets;
}

# inside the intended server block
if ($migration_target != "") {
    return 301 https://www.example.com$migration_target$is_args$args;
}

$uri ist der normalisierte aktuelle Pfad ohne Argumente; $request_uri enthält den ursprünglichen Query-String. Eine Zuordnung mit Pfadschlüsseln gegen $request_uri würde /old-wallet.html?utm_source=email nicht erfassen. Wählen Sie den Abgleich der vollständigen Anfrage nur, wenn die Query selbst zum vorgesehenen Schlüssel gehört. Siehe Nginx-URI-Variablen.

Soll ein Ziel Argumente bewusst ersetzen oder verwerfen, passen Sie den Aufbau der Return-Anweisung entsprechend an. Testen Sie maskierte Zeichen und wiederholte Schrägstriche anhand Ihrer Normalisierungsregeln. Platzieren Sie die Logik so, dass sie den vorgesehenen Pfad sieht, bevor andere interne Rewrite-Vorgänge $uri ändern.

Führen Sie nginx -t aus, prüfen Sie das Ergebnis, laden Sie die vorgesehene Instanz neu und testen Sie repräsentative Anfragen. Beispieldomains und -pfade beschreiben eine konkrete Musterzuordnung; generieren Sie Ihre tatsächliche Zuordnung aus freigegebenen Zielen, statt das Muster in einen anderen Shop zu kopieren.

Domains wechseln und mehrsprachige Routen erhalten

Ein Hostingumzug mit derselben öffentlichen Domain und denselben Pfaden kann URLs erhalten. Testen Sie vor der DNS-Änderung den neuen Server mit dem vorgesehenen öffentlichen Hostnamen und HTTPS-Zertifikat. Planen Sie, wie Anfragen, die während der DNS-Verbreitung noch den alten Server erreichen, zum aktiven Shop gelangen. Bei einer neuen Domain oder einem neuen Basisverzeichnis müssen außerdem die URL-Konfiguration des Shops aktualisiert, Zertifikate bereitgestellt und Weiterleitungen von alten zu neuen Adressen aufrechterhalten werden.

1. Kopieren Sie zusammenpassende Dateien und Datenbank in die neue Umgebung und schützen Sie die Kopie während der Tests.
2. Aktualisieren Sie die vorgesehene Shop-URL über die unterstützten Backoffice-Einstellungen. Prüfen Sie shop_url.domain, domain_ssl, physical_uri und etwaige virtuelle Multistore-URIs.
3. Prüfen Sie relevante Werte von PS_SHOP_DOMAIN und PS_SHOP_DOMAIN_SSL im richtigen Kontext.
4. Ändert sich der Datenbankzugriff, aktualisieren Sie in modernen Versionen app/config/parameters.php. Der Pfad lautet nicht config/parameters.php. Das ältere 1.6 nutzt config/settings.inc.php.
5. Leeren/erneuern Sie Caches und generieren Sie die passenden Apache-Regeln neu oder stellen Sie die entsprechenden Nginx-Regeln bereit.
6. Installieren und testen Sie Weiterleitungen von jeder alten Seite zu ihrer endgültigen Entsprechung. Halten Sie alte Domain und HTTPS-Zertifikat funktionsfähig.
7. Aktualisieren Sie Zahlungs-Callbacks, Cronjobs, Maillinks, Feeds, Analysen und Anzeigenziele.

Ordnen Sie bei mehrsprachigen Katalogen jede Sprache der passenden Sprache zu, erhalten Sie notwendige Sprachunterscheidungen und prüfen Sie Canonical- sowie gegenseitige hreflang-Verweise. Leiten Sie nicht jede Sprache auf Englisch um.

Ein Katalog mit 5.000 Produkten und vier Sprachen kann ungefähr 20.000 Produkt-Sprach-URL-Paare vor Aliasen, Kategorien und altem Verlauf haben. Generieren Sie das Inventar aus tatsächlich veröffentlichten Kombinationen, statt jede Übersetzung für jedes Produkt vorauszusetzen.

Für die Plattform-/Datenseite des Wechsels nutzen Sie den Migrationsleitfaden.

URL- und SEO-Module für Routing und Metadaten nutzen

SEO Revolution bietet Weiterleitungsverwaltung, 404-Prüfung, Behandlung permanenter Weiterleitungsketten, Canonical-/hreflang-Regeln und Sitemap-Abläufe; die Modulhilfe enthält Einrichtung und unterstütztes Abgleichverhalten.

Smart SEO Friendly URL Manager bietet Entitäts-URL-Muster, Kollisionsrichtlinien und Weiterleitungsverlauf, einschließlich der Bedingung, dass ein alter Pfad keiner aktuellen Route gehören darf; nutzen Sie seine Modulhilfe für Einrichtung und Zusammenspiel mit SEO Revolution.

Product Canonical Manager bietet Canonical-Kontrollen je Produkt; siehe seine Modulhilfe vor dem Ändern bevorzugter Ziele.

Hreflang Tags Manager bietet die Verwaltung von Sprachalternativen; seine Modulhilfe behandelt die Konfiguration.

Testen Sie Modulrouten, exakten/Query-Abgleich, Präfixregeln, Kettenenden, Sprachberechtigung und Vorrang aktueller Routen auf einer Kopie. Ein Weiterleitungsmodul braucht weiterhin eine geprüfte Zielzuordnung; es kann nicht für jede fehlende Seite sicher semantische Entsprechungen wählen.

Den Start prüfen und Ergebnisse überwachen

Aktualisieren Sie interne Verweise auf endgültige URLs: Navigation, CMS- und Produktinhalte, Cross-Sells, E-Mail-Vorlagen, Feeds und strukturierte Daten. Weiterleitungen sollten alte externe Verweise auffangen, statt jedem neuen internen Link Sprünge hinzuzufügen.

Generieren Sie Sitemaps mit vorgesehenen indexierbaren kanonischen URLs, die erfolgreiche Antworten liefern. Prüfen Sie alle Shops und Sprachen. Entfernen Sie weitergeleitete, fehlende und noindex-Ziele. Eine Sitemap ist ein Auffindbarkeits-/Canonical-Signal, keine Indexierungsgarantie; siehe Googles Sitemap-Hinweise.

Testen Sie Antwort und endgültigen Inhalt mit normalem Browser und Befehlszeilenanfrage. Manche Anwendungen behandeln HEAD anders; bestätigen Sie daher auch mit GET.

curl -sS -D - -o /dev/null 'https://www.example.com/old-wallet.html?utm_source=email'
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' 'https://www.example.com/old-wallet.html'

• Geänderte URLs: erwarteter permanenter Status, korrekter Location-Header, keine Schleife und eine endgültige 200-Seite mit passendem Inhalt.
• Unveränderte URLs: direkt 200, korrekter Inhalt und Canonical.
• Entfernte Seiten: vorgesehene 404/410 ohne irreführende Erfolgsseite.
• Varianten: Host, Schema, Suffix, Groß-/Kleinschreibung, Kodierung, Argumente, Sprache und Installationsunterverzeichnis.
• Wichtige Abläufe: Varianten, Suche/Facetten, Checkout, Konto und Zahlungs-Callbacks.

Bestätigen Sie alte und neue Search-Console-Properties, reichen Sie die aktuelle Sitemap ein und nutzen Sie bei einem unterstützten Domainumzug die Adressänderung. Prüfen Sie Crawl-/Indexierungsberichte, Protokolle, organischen Einstiegsseitentraffic und Abschlüsse. Bewahren Sie permanente Migrationsweiterleitungen mindestens ein Jahr auf und länger, solange Links oder Besucher sie nutzen.

Bewahren Sie Ausgangswerte vor der Änderung je Einstiegsseite, Sprache und Shop auf und vergleichen Sie die zugeordneten Ziele mit ihren bisherigen Entsprechungen. Shopweite Gesamtwerte können eine defekte Sprachversion oder eine fehlende wertvolle Kategorie verbergen. Trennen Sie Anfragefehler von Änderungen der Suchleistung: Eine Schleife, ein falsches Produkt oder ein blockiertes Ziel benötigt eine technische Korrektur, während eine funktionierende URL mit weniger Besuchen eine Untersuchung von Indexierung, Inhalt und Nachfrage erfordert. Dokumentieren Sie den Änderungszeitpunkt und parallele Kampagnen oder Katalogänderungen, damit sie nicht fälschlich einer anderen Ursache zugeschrieben werden.

Verarbeitungszeiten und Suchergebnisse variieren. Weiterleitungen können weder Erholung garantieren noch verlorene Inhalte, Indexierungsbeschränkungen oder veränderten Wettbewerb ausgleichen. Siehe Googles Hinweise zum Websiteumzug.

Fragen an Ihren Entwickler oder Ihre Agentur

Verlangen Sie eine Übergabe, die Ihnen beim nächsten Import, einer Umbenennung oder einem Modulupdate hilft.

• Welche Komponente verantwortet Host-Weiterleitungen, Seitenrouting, historische Weiterleitungen, Canonicals und hreflang, und in welcher Reihenfolge laufen sie?
• Welche Zuordnungszeilen sind noch ungeklärt, wer gibt deren Ziele frei und wo sind Anfrageergebnisse und Prüfungen der endgültigen Seiten dokumentiert?
• Kann ein Katalogimport manuelle Slugs überschreiben oder neue Kollisionen erzeugen, und wer prüft das Ergebnis?
• Welche Theme-Links, Feeds, Callbacks und geplanten Jobs wurden mit der vorgesehenen Live-Domain und den vorgesehenen Sprachen getestet?
• Wer kann die bisherige Konfiguration wiederherstellen, was löst diese Entscheidung aus und wie bleiben neue Bestellungen und Bestandsänderungen erhalten?
• Wer verantwortet nach der Projektübergabe die Überwachung und eingehende Meldungen defekter Links?

Häufige Fragen von Shopbetreibern

Können wir die URL-Änderung mit einem Datenbankbackup rückgängig machen?

Überschreiben Sie neue Bestellungen, Kundenänderungen oder Bestandsbewegungen nicht mit der Datenbank vor dem Start. Planen Sie die Wiederherstellung anhand der Routing-Konfiguration, Weiterleitungszuordnung und betroffenen konkreten Datenänderungen. Browser und Zwischenstationen können permanente Weiterleitungen zwischenspeichern. Testen Sie deshalb die Wiederherstellung auch für Besucher, die weiterhin den veröffentlichten neuen Zielen folgen. Halten Sie diese Ziele während der Wiederherstellung nutzbar. Erfordert der Rollback eine Datenreparatur, muss Ihr Entwickler die seit dem Start geschriebenen Datensätze abgleichen, statt den gesamten Shop blind wiederherzustellen.

Können wir die Adresse eines eingestellten Produkts für ein anderes verwenden?

Prüfen Sie vor der Freigabe die bisherige Nutzung. Alte Lesezeichen, Kampagnen und Backlinks würden nun das neue Produkt öffnen, und eine historische Weiterleitung wird möglicherweise nicht mehr ausgeführt, wenn eine aktuelle Route den Pfad belegt. Behalten Sie eine eigene Adresse bei, wenn die Produkte nicht dieselbe Absicht bedienen; reservieren Sie wichtige Aliase im Routeninventar, damit ein Import sie nicht beiläufig wiederverwendet.

Müssen Bestellungen bei einem Domainumzug pausieren?

Eine Weiterleitungsprobe entscheidet das nicht. Ziehen Sie auch die Datenbank um, vereinbaren Sie, welche Umgebung Schreibzugriffe annimmt, wie die abschließende Datensynchronisierung funktioniert und ob eine Checkout-Pause nötig ist. Bestellungen, Zahlungsbenachrichtigungen und Bestandsaktualisierungen dürfen sich während der Umschaltung nicht auf unabhängige Kopien verteilen.

Wer pflegt die Zuordnung nach dem Start?

Übertragen Sie einer benannten Person die Verantwortung für freigegebene Ziele und die Begründung jeder Änderung. Bewahren Sie die Weiterleitungskonfiguration zusammen mit den Release-Unterlagen auf und prüfen Sie sie nach Katalogimporten oder Routing-Updates. Beziehen Sie Meldungen fehlender Seiten aus dem Kundensupport ein: Ein defekter Kauflink kann auch bei wenig Suchtraffic wichtig sein.