Plan de redirections des références lors d'un changement de plateforme

Les checklists de migration supposent que l'on peut crawler l'ancien site et cartographier ce qu'on y trouve, ce qui échoue sur un grand catalogue parce que le crawl manque les produits orphelins et en rupture qui portent encore des liens et des positions. Le second échec est de supposer que les références s'apparient une pour une : un changement de plateforme modifie la gestion des déclinaisons, fusionne ou scinde des catégories, et abandonne le plus souvent les chemins de facettes, si bien qu'une partie des anciennes URL n'a aucune destination et se fait rediriger en masse vers la page d'accueil. C'est de cette partie que vient la perte de trafic, et elle se règle avant la mise en ligne si le plan est construit à partir de l'export du catalogue.

Le fichier de compétence

---
name: replatform-sku-redirect-mapping
description: À utiliser lors du transfert d'un catalogue vers une nouvelle plateforme, quand les schémas d'URL des produits, des déclinaisons, des catégories et des facettes changent tous en même temps.
---

# Plan de redirections des références lors d'un changement de plateforme

Les checklists de migration supposent que l'on peut crawler l'ancien site et cartographier ce qu'on y trouve, ce qui échoue sur un grand catalogue parce que le crawl manque les produits orphelins et en rupture qui portent encore des liens et des positions. Le second échec est de supposer que les références s'apparient une pour une : un changement de plateforme modifie la gestion des déclinaisons, fusionne ou scinde des catégories, et abandonne le plus souvent les chemins de facettes, si bien qu'une partie des anciennes URL n'a aucune destination et se fait rediriger en masse vers la page d'accueil. C'est de cette partie que vient la perte de trafic, et elle se règle avant la mise en ligne si le plan est construit à partir de l'export du catalogue.

## Ce qu’il vous faut d’abord

- un inventaire d'URL assemblé depuis quatre sources et dédupliqué : la base de données, les anciens sitemaps, 12 mois de pages Search Console, 12 mois de pages d'entrée analytics
- le nombre de domaines référents par ancienne URL, pour prioriser la traîne qui porte des liens
- les schémas d'URL de la nouvelle plateforme pour les produits, les déclinaisons, les catégories et les éventuelles facettes indexables, confirmés en préproduction et non sur une spécification
- la correspondance des identifiants de références et de catégories, ancien vers nouveau, fournie par l'équipe de migration

## Méthode

1. Assemblez l'inventaire depuis les quatre sources, pas depuis un crawl. Ce sont les historiques Search Console et analytics qui font remonter les URL qui rapportent encore du trafic mais ne sont plus liées nulle part.
2. Joignez l'inventaire à la table de correspondance des identifiants et laissez des règles de motif générer l'essentiel du plan. Des règles sont plus fiables et plus relisibles qu'un tableau de 40 000 lignes construit à la main.
3. Isolez les lignes que les règles n'ont pas pu apparier et classez-les par domaines référents et par entrées organiques. Cette traîne est courte en nombre et lourde en valeur, et c'est la seule partie qui exige des décisions humaines.
4. Résolvez les URL non appariées vers l'équivalent authentique le plus proche et acceptez un 410 pour celles qui n'ont plus rien derrière elles. Les envoyer vers la page d'accueil est lu comme un soft 404 et gaspille du crawl pendant des mois.
5. Tranchez explicitement la gestion des déclinaisons avant de générer quoi que ce soit. Un site qui avait une URL par taille et passe à une page produit unique fait une fusion de plusieurs vers un, et chaque ancienne URL de déclinaison a tout de même besoin de sa propre règle.
6. Testez le jeu de règles contre l'inventaire complet en préproduction, en contrôlant le code de statut, la destination finale et le nombre de sauts. Les chaînes passant par une règle héritée d'une migration précédente sont fréquentes et chaque saut coûte du crawl.
7. Gardez les anciens sitemaps en ligne et soumis quelques semaines après la mise en ligne, pour que les redirections soient découvertes rapidement, puis remplacez-les par les nouveaux.
8. Repassez l'inventaire complet sur la production le jour de la mise en ligne, puis au septième jour, en suivant le nombre d'URL non appariées et d'erreurs plutôt qu'en attendant que les données de trafic révèlent le trou.

## Ce que ça produit

Un plan de redirections ancien vers nouveau, testé, couvrant l'inventaire historique complet des URL, où chaque URL non appariée est soit résolue individuellement soit retirée délibérément.

## Là où ça dérape

- construire le plan depuis un crawl du site en ligne, ce qui omet les produits en rupture et orphelins qui portent encore des liens et des positions
- rediriger en masse les URL non appariées vers la page d'accueil ou une catégorie principale, ce qui est traité comme un soft 404 et abandonné
- mettre en ligne avec des chaînes issues d'une migration antérieure encore dans la pile, si bien que chaque URL héritée coûte plusieurs requêtes pour se résoudre
- retirer les anciens sitemaps à la mise en ligne, ce qui ralentit la découverte des redirections précisément au moment où elle compte le plus

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/replatform-sku-redirect-mapping

Ce qu’il vous faut d’abord

• un inventaire d'URL assemblé depuis quatre sources et dédupliqué : la base de données, les anciens sitemaps, 12 mois de pages Search Console, 12 mois de pages d'entrée analytics
• le nombre de domaines référents par ancienne URL, pour prioriser la traîne qui porte des liens
• les schémas d'URL de la nouvelle plateforme pour les produits, les déclinaisons, les catégories et les éventuelles facettes indexables, confirmés en préproduction et non sur une spécification
• la correspondance des identifiants de références et de catégories, ancien vers nouveau, fournie par l'équipe de migration

Méthode

1. 01 Assemblez l'inventaire depuis les quatre sources, pas depuis un crawl. Ce sont les historiques Search Console et analytics qui font remonter les URL qui rapportent encore du trafic mais ne sont plus liées nulle part.
2. 02 Joignez l'inventaire à la table de correspondance des identifiants et laissez des règles de motif générer l'essentiel du plan. Des règles sont plus fiables et plus relisibles qu'un tableau de 40 000 lignes construit à la main.
3. 03 Isolez les lignes que les règles n'ont pas pu apparier et classez-les par domaines référents et par entrées organiques. Cette traîne est courte en nombre et lourde en valeur, et c'est la seule partie qui exige des décisions humaines.
4. 04 Résolvez les URL non appariées vers l'équivalent authentique le plus proche et acceptez un 410 pour celles qui n'ont plus rien derrière elles. Les envoyer vers la page d'accueil est lu comme un soft 404 et gaspille du crawl pendant des mois.
5. 05 Tranchez explicitement la gestion des déclinaisons avant de générer quoi que ce soit. Un site qui avait une URL par taille et passe à une page produit unique fait une fusion de plusieurs vers un, et chaque ancienne URL de déclinaison a tout de même besoin de sa propre règle.
6. 06 Testez le jeu de règles contre l'inventaire complet en préproduction, en contrôlant le code de statut, la destination finale et le nombre de sauts. Les chaînes passant par une règle héritée d'une migration précédente sont fréquentes et chaque saut coûte du crawl.
7. 07 Gardez les anciens sitemaps en ligne et soumis quelques semaines après la mise en ligne, pour que les redirections soient découvertes rapidement, puis remplacez-les par les nouveaux.
8. 08 Repassez l'inventaire complet sur la production le jour de la mise en ligne, puis au septième jour, en suivant le nombre d'URL non appariées et d'erreurs plutôt qu'en attendant que les données de trafic révèlent le trou.

Ce que ça produit

Un plan de redirections ancien vers nouveau, testé, couvrant l'inventaire historique complet des URL, où chaque URL non appariée est soit résolue individuellement soit retirée délibérément.

Là où ça dérape

• construire le plan depuis un crawl du site en ligne, ce qui omet les produits en rupture et orphelins qui portent encore des liens et des positions
• rediriger en masse les URL non appariées vers la page d'accueil ou une catégorie principale, ce qui est traité comme un soft 404 et abandonné
• mettre en ligne avec des chaînes issues d'une migration antérieure encore dans la pile, si bien que chaque URL héritée coûte plusieurs requêtes pour se résoudre
• retirer les anciens sitemaps à la mise en ligne, ce qui ralentit la découverte des redirections précisément au moment où elle compte le plus

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans SEO e-commerce