Une refonte de site e-commerce, c’est l’occasion de tout remettre à plat : design, parcours d’achat, back-office. C’est aussi le moment où une boutique peut perdre en quelques jours le trafic organique qu’elle a mis des années à construire. Une URL qui change sans redirection, et c’est une page bien positionnée qui disparaît de Google.
L’an dernier, j’ai piloté la refonte d’une boutique PrestaShop de plus de 6 000 références, dont une bonne partie du chiffre d’affaires venait du référencement naturel. Le changement d’arborescence était inévitable. Voici la checklist que j’ai suivie, et que je réutilise depuis sur chaque migration.
1. Faire l’inventaire complet de l’existant
On ne protège que ce qu’on connaît. Avant tout, je constitue la liste exhaustive des URLs du site actuel, en croisant trois sources :
- Un crawl du site avec un outil dédié (Screaming Frog, par exemple) : toutes les pages accessibles en suivant les liens.
- Les données de la Search Console : les pages qui reçoivent des impressions et des clics, y compris celles que le crawl ne trouve plus, comme d’anciens produits encore indexés.
- Le sitemap XML et l’export du catalogue : toutes les fiches produits et catégories, même mal reliées au reste du site.
Le croisement fait souvent apparaître des surprises : des pages orphelines qui rapportent encore du trafic, ou des URLs en double créées par les filtres de navigation.
Au passage, je repère les pages qui comptent vraiment, celles qui génèrent le plus de clics organiques. Ce sont elles qu’on surveillera de près après la mise en ligne.
2. Construire la table de correspondance
C’est le cœur du travail : un tableur qui associe chaque ancienne URL à sa nouvelle adresse. Sur un catalogue de plusieurs milliers de produits, on ne le remplit pas ligne par ligne. On définit des règles :
- les fiches produits suivent un schéma prévisible, on génère les correspondances à partir de la référence produit ;
- les catégories sont reprises une par une, puisque c’est justement l’arborescence qui change ;
- les produits supprimés renvoient vers leur catégorie la plus proche, jamais vers la page d’accueil.
Rediriger tout ce qui disparaît vers l’accueil est une fausse bonne idée : Google le traite comme une erreur 404 déguisée.
La table se valide avec le client. C’est lui qui connaît les produits arrêtés, les gammes regroupées et les pages qui comptent commercialement.
3. Recetter les redirections avant la mise en ligne
Une table de correspondance non testée ne vaut pas grand-chose. En préproduction, je passe toute la liste des anciennes URLs dans un crawler en mode liste et je vérifie trois points :
- chaque ancienne URL renvoie bien un code 301, et pas une 302 ou une 404 ;
- la destination répond en 200, sans chaîne de redirections ;
- aucune boucle ne s’est glissée dans les règles.
J’intègre cette vérification au plan de recette, au même titre que le tunnel de commande ou les e-mails transactionnels. Elle prend du temps, mais c’est elle qui évite les mauvaises surprises le jour J.
4. Le jour de la mise en production
La bascule suit une checklist courte mais stricte :
- retirer le blocage d’indexation de la préproduction (
noindexourobots.txt), l’oubli classique qui peut faire disparaître un site de Google ; - vérifier que les redirections sont bien actives sur le serveur de production, pas seulement en préprod ;
- soumettre le nouveau sitemap dans la Search Console ;
- contrôler que l’outil d’analytics remonte bien les visites et les conversions.
Mieux vaut programmer la mise en ligne en début de semaine qu’un vendredi soir : si quelque chose casse, l’équipe est là pour corriger.
5. Surveiller pendant un mois
Les premiers jours, Google repasse sur le site et découvre les redirections. C’est la période à risque, et la seule façon de la traverser sereinement, c’est de regarder les données chaque jour.
Pendant le premier mois, je suis quotidiennement dans la Search Console :
- les erreurs 404 qui remontent : une URL oubliée dans la table, une règle mal écrite ;
- l’évolution des clics et impressions par rapport à la période précédente ;
- les positions sur les requêtes principales repérées à l’étape 1.
Une 404 sur une page qui avait du trafic se corrige dans la journée. Sur ce projet, nous n’avons constaté aucune perte de positionnement sur les requêtes principales, et le nouveau parcours mobile a même facilité la commande des clients professionnels.
Une migration réussie ne se voit pas : le site change, le trafic reste. C’est un travail minutieux, peu visible pour le client, mais c’est souvent lui qui fait la différence entre une refonte qui rapporte et une refonte qui coûte. Vous préparez une migration et vous voulez en parler ? Écrivez-moi.