Quitter Magento 2 sans perdre ses positions sur Google

Le scénario est connu des forums de marchands. Une boutique de quelques milliers de produits quitte Magento le temps d'un week-end. Le nouveau site a l'air juste, les commandes arrivent le lundi, tout le monde souffle. Trois semaines plus tard, le trafic naturel a baissé d'un tiers. La Search Console est pleine de 404 sur des adresses en .html, les visites venant de la recherche d'images ont presque disparu, toute une branche d'anciens liens de catégories atterrit sur la page d'accueil, et personne ne sait dire lequel de ces problèmes pèse le plus.

Ce n'est pas toujours aussi net. Dans un fil de discussion, un marchand a perdu environ la moitié de son trafic après avoir quitté Magento alors que des redirections existaient pour les produits, les catégories et les articles ; les réponses pointaient des catégories renommées, un contenu et une structure modifiés, et les semaines qu'il faut aux signaux pour passer par les redirections. Dans un autre, seul le Royaume-Uni a chuté, trois mois après le changement, et les suspects étaient d'anciennes URL que personne n'avait reprises et des balises hreflang manquantes. La leçon est la même : un changement de plateforme est une liste d'URL et de signaux, et ce qui n'est pas sur la liste se perd.

Magento construit ses adresses à partir de plusieurs réglages à la fois. La clé d'URL d'un produit peut porter un suffixe comme .html, être servie avec ou sans le chemin de la catégorie, et se trouver derrière un code de magasin. La documentation d'Adobe sur les réécritures d'URL montre le même produit accessible en gear/bags/impulse-duffle.html et en impulse-duffle.html, selon la configuration.

Derrière tout cela se trouve la table url_rewrite. Elle contient chaque adresse à laquelle Magento répond : les actuelles, les variantes avec chemin de catégorie, et les 301 créées automatiquement à chaque fois que quelqu'un a changé une clé d'URL au fil des années. C'est cette table, et non le sitemap, qui est la vraie liste de ce que Google peut connaître. Exportez-la avant toute chose.

• Le suffixe .html. Ce que l'on voit : tous les produits et catégories renvoient une 404 après le lancement, ou chutent dans les résultats. Pourquoi : presque aucune autre plateforme n'utilise de suffixe, donc /manteau-laine.html devient /manteau-laine ou /products/manteau-laine. La solution : une règle qui retire le suffixe suffit pour commencer, mais vérifiez chaque règle sur l'export réel, car des clés de catégories et de produits peuvent se confondre.
• Le chemin de catégorie dans les URL produit. Ce que l'on voit : l'URL courte du produit redirige, mais /femme/manteaux/manteau-laine.html non. Pourquoi : avec les catégories dans le chemin, un produit a autant d'adresses que de catégories, et des liens externes pointent vers toutes. La solution : faire correspondre chaque request_path de chaque produit à l'unique nouvelle adresse, pas seulement la canonique.
• Les codes de magasin. Ce que l'on voit : une deuxième langue ou un deuxième pays perd tout. Pourquoi : avec Add Store Code to URLs activé, Adobe place le code dans chaque chemin, /en/ ou /fr/, et les liens du sélecteur de magasin peuvent en plus porter un paramètre ___store. La solution : faire correspondre les URL de chaque vue magasin à la version dans la même langue du nouveau site, jamais à la langue par défaut.
• Les anciennes clés d'URL que Magento redirigeait encore. Ce que l'on voit : des liens venant de blogs et d'anciennes newsletters cassent des mois plus tard. Pourquoi : les lignes de url_rewrite avec redirect_type 301 maintenaient en vie des années de produits renommés, et elles disparaissent avec l'ancien serveur. La solution : pointer chacune directement vers la nouvelle adresse finale, pour garder un seul saut.
• La navigation à facettes. Ce que l'on voit : la Search Console signale des milliers d'URL étranges comme ?color=49&size=166 qui renvoient une 404 ou mènent à la page d'accueil. Pourquoi : les filtres Magento sont des paramètres sur les pages de catégorie, et Google les explore. La solution : ne les reprenez pas une par une. Envoyez les URL filtrées vers leur catégorie, et ne recréez en vraies pages que les rares combinaisons qui apportaient des visites. Le guide de Google sur la navigation à facettes explique pourquoi ces URL gaspillent l'exploration.
• Les adresses des images. Ce que l'on voit : le trafic de Google Images s'effondre et ne revient pas. Pourquoi : les photos passent de /media/catalog/product/ au stockage de la nouvelle plateforme, sous d'autres noms. La solution : le guide de Google sur les déménagements de site demande d'inclure les images dans la table de correspondance ; redirigez au moins les images des meilleures ventes, et gardez le texte alternatif et des noms de fichier descriptifs.

• Redirections manquantes, ou tout vers la page d'accueil. Ce que l'on voit : une ligne continue de 404, ou une page d'accueil qui reçoit soudain du trafic sur des recherches de produits. Pourquoi : une règle générale a envoyé les URL sans correspondance vers l'accueil. Google demande de ne pas diriger beaucoup d'anciennes URL vers une page sans rapport, et précise que ces redirections peuvent être traitées comme des soft 404. La solution : une destination pertinente par URL, et une vraie 404 ou 410 quand rien ne convient.
• Les chaînes de redirections. Ce que l'on voit : les anciens liens fonctionnent mais se positionnent moins bien et sont explorés lentement. Pourquoi : une ancienne clé redirigeait vers une plus récente, qui redirige maintenant vers la nouvelle plateforme. La solution : aplatir la chaîne, chaque ancienne adresse directement vers la finale. Google conseille d'aller directement à l'adresse finale et, à défaut, de ne pas dépasser trois sauts ; visez un seul.
• Temporaire au lieu de permanent. Pourquoi : certains outils et réglages utilisent 302 par défaut. Une redirection temporaire garde l'ancienne URL dans les résultats ; les permanentes (301 ou 308) transmettent la position à la nouvelle. Utilisez des redirections côté serveur ; celles en JavaScript sont le dernier recours.
• Balises title et meta description. Ce que l'on voit : les pages sont indexées mais le taux de clic baisse. Pourquoi : beaucoup d'outils d'import reprennent le nom et la description mais pas le meta_title et le meta_description de Magento, si bien que le nouveau titre n'est que le nom du produit. La solution : exporter les deux champs et les recopier, surtout pour les pages qui reçoivent des clics.
• Canoniques et hreflang entre vues magasin. Ce que l'on voit : une langue passe devant une autre dans le mauvais pays, ou des pages apparaissent en double. Pourquoi : les canoniques et les balises hreflang viennent souvent d'une extension ou du thème Magento, et n'existent tout simplement pas sur le nouveau site. La solution : donner à chaque nouvelle page une canonique vers elle-même, et reconstruire les alternatives de langue entre versions.
• robots.txt et noindex oubliés depuis la préproduction. Ce que l'on voit : des pages sortent de l'index quelques jours après le lancement. Pourquoi : le site de préproduction était caché, et le réglage est passé en production avec lui. La solution : vérifier le robots.txt et la balise meta robots sur le vrai domaine dans la première heure.
• Le sitemap. Pourquoi : l'URL de l'ancien sitemap renvoie une 404, et le nouveau n'a jamais été soumis. La solution : soumettre le nouveau sitemap dans la Search Console et, comme Google le suggère, garder quelque temps un sitemap des anciennes URL pour que les redirections soient découvertes plus vite.

1. 1

   Explorer le site Magento en ligne et exporter ses URL

   Passez un crawler sur toute la boutique et enregistrez chaque URL avec son statut, son titre, sa meta description, sa canonique et son H1. Exportez ensuite la table url_rewrite (request_path, target_path, redirect_type, store_id, entity_type, entity_id). Ensemble, c'est votre inventaire.

2. 2

   Ajouter ce que Google et les autres sites connaissent

   Exportez les pages principales du rapport Performances de la Search Console sur les 16 derniers mois, vos pages les plus liées, et les pages d'entrée de vos statistiques. Les anciens sitemaps, les journaux du serveur et la Wayback Machine retrouvent des adresses dont plus personne ne se souvient.

3. 3

   Faire correspondre chaque ancienne URL à une nouvelle

   Un tableur à deux colonnes : ancienne et nouvelle. Les produits par SKU ou identifiant, les catégories par identifiant, les pages CMS à la main. Les produits retirés vont vers la catégorie ou le remplaçant le plus proche, pas vers l'accueil. Marquez les URL qui ont du trafic ou des liens pour les tester en premier.

4. 4

   Reprendre les signaux de chaque page

   Balises title, meta descriptions, titres, descriptions de catégories, textes alternatifs des images et données structurées. Gardez des noms et descriptions de catégories proches des anciens pendant les premiers mois ; un changement de plateforme n'est pas le moment de tout réécrire.

5. 5

   Mettre en place les 301, un saut chacune

   Des redirections permanentes côté serveur, chargées depuis la table de correspondance, chacune directement vers son adresse finale. Décidez où elles vivront (l'outil de redirections de la nouvelle plateforme, le CDN ou un serveur web placé devant) avant le lancement, pas après.

6. 6

   Tester en préproduction, puis à nouveau en production

   Donnez la liste des anciennes URL à un crawler en mode liste et vérifiez que chacune renvoie une seule 301 vers une page 200. Recommencez sur le vrai domaine dans l'heure du basculement.

7. 7

   Ouvrir les portes

   Retirez tout noindex et les règles robots.txt de préproduction, soumettez le nouveau sitemap, gardez les anciennes URL dans un second sitemap, et inspectez quelques pages clés avec l'outil d'inspection d'URL de la Search Console.

8. 8

   Surveiller, corriger et garder les redirections

   Consultez les 404 dans la Search Console chaque jour pendant les deux premières semaines et ajoutez des redirections au fur et à mesure. Gardez-les le plus longtemps possible : Google parle en général d'au moins un an, et pour toujours vaut mieux pour ceux qui suivent d'anciens liens.

Le guide de Google sur les déménagements de site prévient que les positions peuvent fluctuer pendant la nouvelle exploration, et que pour un site de taille moyenne il peut falloir quelques semaines ou plus pour que la plupart des pages soient transférées ; les grands sites prennent plus de temps. Une baisse les premières semaines n'est pas un verdict.

L'outil d'import Magento 2 garde la clé d'URL de chaque produit et catégorie comme handle, et les pages sont à la racine, donc /manteau-laine.html devient /manteau-laine. La table de correspondance devient presque mécanique : retirer le suffixe et le chemin de catégorie. Les images sont copiées dans le stockage de votre boutique, donc leurs adresses changent. L'import lit la vue magasin par défaut, et une deuxième vue magasin devient une deuxième boutique.

Les redirections sont reprises : chaque ancienne adresse .html d'un produit ou d'une catégorie, à n'importe quelle profondeur, mène seule à la nouvelle par une 301, et l'importateur reprend les redirections de Magento, personnalisées comprises, chacune droit vers la page finale. Ce qu'il ne fait pas, franchement : les balises title des produits et catégories ne sont pas importées (chaque produit et collection a son propre titre et sa description SEO à remplir), et les codes de boutique dans les URL (/en/...) et les adresses de filtres de la navigation à facettes ne sont pas reprises seules ; ajoutez-les sous Réglages, Moteurs de recherche, Redirections, à la main ou depuis un CSV. Le sitemap de la boutique liste tous les produits, catégories et pages, avec leurs versions dans chaque langue. Pour les 100 premières boutiques qui quittent Magento, une personne de notre équipe s'occupe du changement et garde vos URL en état de marche : demandez-le sur quitter Magento. Si vous partez parce que votre version perd son support, commencez par la fin du support de Magento 2.