Lecture : 8 min · Yoan Gwizdala

Migrer PrestaShop sans perdre son référencement

Une migration PrestaShop ne fait pas perdre de référencement en elle-même. Ce sont les URL qui en font perdre — quand elles changent sans que personne ne l'ait décidé, et que rien ne mène les anciennes vers les nouvelles.

Google connaît vos pages par leur adresse. Une adresse qui disparaît sans redirection, c'est une page qui disparaît de l'index, et avec elle le classement qu'elle avait mis des années à gagner. Tout le travail SEO d'une migration tient dans cette phrase.

Ce qui fait changer les URL sans prévenir

Un réimport du catalogue. C'est le grand classique : on repart d'une installation neuve, on importe les produits, et les identifiants sont redistribués. Comme ils figurent dans l'URL, toutes les fiches produits changent d'adresse d'un coup.
Un changement de structure d'URL. PrestaShop 9 retire par défaut la catégorie de l'URL des produits. C'est un bon réglage ; appliqué sans redirections, c'est une catastrophe.
Le préfixe de langue. PrestaShop 9 permet de l'omettre pour la langue par défaut : /fr/mon-produit devient /mon-produit. Toutes les pages, d'un coup, là aussi.
Les pages qui disparaissent : produits supprimés au passage, catégories fusionnées, pages CMS oubliées dans la reprise.
Le « tant qu'on y est ». Changer de domaine, passer en HTTPS ou refondre l'arborescence le même jour que la version, c'est empiler quatre causes possibles sur un seul symptôme. On ne saura plus laquelle traiter.

Une seule chose à la fois. On migre la version, on stabilise, on mesure. Ensuite, et seulement ensuite, on change la structure d'URL si elle mérite d'être changée. Ce n'est pas de la prudence excessive : c'est ce qui permet de savoir ce qui a marché.

La méthode, dans l'ordre

1. Relever ce qui existe, avant de toucher à quoi que ce soit

Cette photographie ne se refait pas après coup, et c'est pour ça qu'elle passe en premier :

L'export des pages indexées depuis la Search Console, et celui des pages qui apportent réellement des visites.
Le sitemap actuel, tel quel.
Un crawl complet de la boutique : toutes les URL, leurs codes de réponse, leurs balises canoniques.
La liste des redirections déjà en place, souvent héritées d'une migration précédente. On les empile, on ne les efface pas : une chaîne de redirections qui saute une étape casse la chaîne entière.
Les positions et le trafic du mois précédent, comme point de comparaison honnête.

2. Décider ce qui bouge, et l'assumer

La règle par défaut : on ne change rien. Toute URL qui change doit avoir une raison explicite. Si la structure doit évoluer, on le décide, on l'écrit, et on prépare les redirections en conséquence — au lieu de découvrir le changement une fois en ligne.

3. La table de correspondance

Une ligne par URL qui bouge : ancienne adresse, nouvelle adresse. C'est fastidieux et c'est exactement là que se joue la conservation du référencement. Sur un gros catalogue, on la construit par correspondance de références produits, pas à la main — mais on la vérifie à la main sur un échantillon, y compris sur les pages qui rapportent le plus.

4. Des redirections 301, et une par saut

301, jamais 302. La 302 dit « c'est temporaire » et ne transmet pas le signal correctement.
Jamais vers l'accueil. Rediriger cent fiches produits vers la page d'accueil équivaut à les supprimer, avec en prime une mauvaise expérience pour le visiteur. Une page supprimée sans équivalent doit renvoyer vers sa catégorie, ou répondre proprement en 410.
Pas de chaînes. A → B → C se ramène à A → C et B → C.

5. Ce qu'on vérifie le jour de la bascule

Le robots.txt de la préproduction, en Disallow: /, qui part en production. C'est l'erreur la plus fréquente et la plus coûteuse de toutes les migrations, tous outils confondus.
Les balises noindex laissées sur la préproduction.
Les balises canoniques, qui doivent pointer vers les nouvelles adresses.
Le sitemap régénéré, et pas l'ancien fichier resté en place.
Les images : leurs URL changent aussi, et elles apportent du trafic sur un catalogue.
Un échantillon d'anciennes URL testées à la main : les dix pages qui rapportent le plus, une par une.

6. Les semaines qui suivent

Sitemap soumis à nouveau, rapport « Pages » de la Search Console surveillé, 404 relevées chaque semaine et traitées : les vraies erreurs de correspondance apparaissent là, pas le jour de la bascule.

Ce qui est normal, et ce qui ne l'est pas

Normal : un creux de deux à quatre semaines. Google doit re-explorer, suivre les redirections et remettre à jour son index. Une baisse de trafic pendant cette période n'est pas le signe d'un échec.

Pas normal : un trafic toujours au tiers de son niveau deux ou trois mois après. Là, quelque chose n'a pas été fait — le plus souvent des redirections manquantes sur une partie du catalogue, ou un blocage d'indexation resté en place. Ça se diagnostique, et ça se rattrape : les redirections posées tardivement fonctionnent encore.

Ce qu'une migration récente fait gagner

Il n'y a pas que des risques. Une version récente sert le référencement pour des raisons très concrètes : pages plus rapides, images mieux servies, balisage plus propre, et — sur PrestaShop 9 — des réglages qui n'existaient pas avant, comme les redirections paramétrables sur les catégories désactivées ou l'exclusion des pages de filtres de l'indexation. Ces pages de filtres, précisément, sont l'une des causes les plus banales de dilution sur une vieille boutique.

Préparer la migration de ma boutique

Questions fréquentes

Une migration PrestaShop fait-elle perdre le référencement ?

Pas en elle-même. Ce qui fait perdre du référencement, c'est le changement d'URL sans redirection : réimport du catalogue qui redistribue les identifiants, changement de structure d'URL, suppression du préfixe de langue, pages disparues. Une migration où les adresses sont conservées ou correctement redirigées ne coûte rien au classement, et améliore souvent la vitesse.

Faut-il conserver les anciennes URL ?

Quand c'est possible, oui : c'est toujours moins risqué que de les changer. Si elles doivent changer — parce que la structure est mauvaise, ou parce qu'on repart d'une installation neuve — alors il faut une table de correspondance ligne à ligne et des redirections 301. Ce qu'il ne faut pas faire, c'est les laisser changer sans l'avoir décidé.

Combien de temps pour retrouver son trafic ?

Deux à quatre semaines de creux sont normales, le temps que Google re-explore le site et suive les redirections. Sur un gros catalogue, la ré-exploration complète peut prendre plus longtemps. Si le trafic n'est pas revenu à son niveau au bout de deux à trois mois, ce n'est plus un délai d'indexation : il manque des redirections, ou une consigne bloque l'indexation.

Faut-il rediriger les produits supprimés ?

Vers leur catégorie ou vers un produit équivalent, oui. Vers la page d'accueil, non : Google traite ces redirections comme des pages supprimées, et le visiteur qui cherchait un produit précis se retrouve nulle part. Pour un produit définitivement abandonné et sans équivalent, une réponse 410 est plus honnête et plus efficace qu'une redirection trompeuse.

PrestaShop 9 change-t-il les URL des produits ?

Oui, par défaut : la catégorie n'apparaît plus dans l'URL du produit, et le préfixe de langue peut être omis pour la langue principale. Ce sont de bons réglages sur une boutique neuve. Sur une boutique existante, ils doivent être décidés consciemment et accompagnés de redirections — ou repoussés à plus tard, une fois la migration de version stabilisée.

Faut-il prévenir Google d'une migration ?

Il n'y a rien à annoncer, mais il y a des choses à faire : soumettre à nouveau le sitemap une fois la nouvelle version en ligne, surveiller le rapport « Pages » de la Search Console, et traiter les 404 qui remontent semaine après semaine. Si le domaine change, l'outil de changement d'adresse de la Search Console existe pour ça, et il s'utilise en plus des redirections, jamais à leur place.