Migration PrestaShop : conservez le référencement lors d’un changement de domaine

En bref

• Une migration PrestaShop vers un nouveau domaine exige une correspondance entre chaque ancienne adresse et son adresse officielle.
• Inforeole livre le plan de redirection 301 : correspondances vérifiées avant l’activation générale, back-office, modules et scripts intacts, et changement d’adresse déclaré dans Search Console, à partir de 1 200 € HT.
• L’ancien domaine doit continuer à répondre avec des redirections directes pendant au moins un an.

Une migration PrestaShop vers un nouveau domaine conserve le référencement acquis lorsque chaque ancienne adresse atteint directement sa destination officielle, en une seule redirection. C’est exactement ce qu’Inforeole met en place avec son plan de redirection 301 : une table de correspondance construite depuis le nouveau site, un module réversible, une activation progressive et des contrôles livrés, à partir de 1 200 € HT.

Le cas qui sert de fil conducteur, présenté de façon anonyme, est celui d’une boutique PrestaShop 1.6 migrée vers une installation PrestaShop 8 sur un nouveau domaine. La boutique regroupait près de 74 000 références, environ 2 000 catégories et cinq langues. Le client a conservé l’ancienne boutique en ligne pour son administration, tandis que le nouveau domaine devait recevoir le trafic public.

La vidéo ci-dessous déroule les sept étapes de cette migration et les quatre erreurs qui coûtent du trafic, avec le récit du lendemain de la mise en ligne.

Préparez votre migration PrestaShop vers un nouveau domaine

Une migration PrestaShop commence par deux inventaires distincts : les données à reprendre et les adresses qui reçoivent encore des visites. La sauvegarde protège la boutique existante, tandis que la table de correspondance prépare les redirections.

Sauvegardez la base de données et les fichiers séparément

PrestaShop documente une restauration qui passe par la désactivation de la boutique, le téléchargement de la sauvegarde, le contrôle de son intégrité et son import dans la base de données. La sauvegarde de base de données ne contient toutefois ni les images ni les fichiers du thème, qui restent stockés sur le serveur. La documentation PrestaShop demande donc de préserver aussi ces fichiers.

PrestaShop recommande de configurer la nouvelle boutique avant l’import, puis de reprendre les données dans un ordre qui commence par l’arborescence des catégories et les produits. Inforeole vérifie cet ordre avant de construire la moindre redirection.

Distinguez les rôles de l’ancienne boutique et du nouveau site

L’ancienne boutique a conservé le back-office et ses services internes. Le nouveau site a reçu les visiteurs et les moteurs de recherche sur le nouveau domaine. L’ancienne boutique garde aussi ses modules de facturation, ses flux vers les places de marché et ses scripts planifiés, qui continuent d’appeler l’ancien domaine.

Cette séparation impose des exclusions dans les règles de redirection. Une règle qui attrape l’administration, le webservice, un module ou un script planifié peut couper les opérations encore réalisées sur l’ancienne installation.

Conservez les identifiants lorsque la migration le permet

Sur cette boutique, la copie de la base de données a conservé les identifiants des produits, catégories, pages et marques entre les deux installations. Inforeole a utilisé cette continuité pour retrouver l’adresse officielle de chaque objet sur le nouveau site.

Si une migration recrée ou modifie les identifiants, Inforeole établit une autre clé de correspondance, par référence ou par code EAN, avant toute redirection.

Le cas montre pourquoi le même chemin ne suffit pas

Une règle qui envoie chaque chemin identique vers le nouveau domaine paraît simple. Elle échoue dès que les deux boutiques fabriquent des adresses différentes.

Comparez les anciennes adresses avec les adresses officielles

Inforeole a constaté que la base copiée ne garantissait pas des chemins identiques. Certains libellés d’URL avaient changé sur le nouveau site, malgré la conservation des identifiants.

L’adresse à viser ne correspond donc pas forcément au chemin historique. Elle doit correspondre à l’adresse officielle renvoyée par le nouveau site pour l’objet et la langue concernés.

Évitez les chaînes qui ajoutent une redirection temporaire

Le nouveau site renvoyait une redirection temporaire 302 lorsqu’une adresse approchante devait rejoindre son adresse officielle. Une ancienne adresse envoyée par erreur vers ce chemin approchant créait alors une chaîne 301 puis 302.

Google recommande de préparer une correspondance entre anciennes et nouvelles URL, puis d’envoyer chaque ancienne adresse par une redirection permanente côté serveur vers la destination finale. Google conseille aussi d’éviter les chaînes, qui ajoutent de la latence. Le guide de déplacement de site de Google précise ce principe pour les changements d’URL et de domaine.

Repérez les adresses dont le libellé a changé

Les adresses de produits, catégories, pages, marques, articles de blog et images doivent être examinées selon leur type. Le webservice PrestaShop expose notamment les produits, catégories, pages de contenu, fabricants, langues et images, ce qui facilite cet inventaire par ressource.

Chaque installation PrestaShop fabrique ses adresses à sa façon, selon sa version, ses réglages et ses modules. La correspondance part donc des adresses réellement renvoyées par le nouveau site, jamais d’une règle supposée.

Construisez des redirections PrestaShop vers chaque adresse officielle

La redirection doit retrouver un objet, sa langue et son adresse finale. Inforeole a construit cette relation avant d’activer les règles sur l’ancien domaine.

Inventoriez les ressources par type et par langue

Inforeole a interrogé le webservice du nouveau site en lecture seule pour inventorier les produits, catégories, pages, marques et images. Chaque ressource a été lue avec son identifiant et son adresse officielle dans chaque langue.

Cet inventaire sert aussi à déceler les objets qui n’ont plus de destination sur le nouveau site.

Associez chaque identifiant à son adresse officielle

Inforeole a constitué une table qui associe un identifiant PrestaShop, une langue et une adresse officielle. Le script de redirection reconnaît la forme de l’ancienne adresse, retrouve l’identifiant dans cette table, puis renvoie directement vers la cible.

Le script et le module font appliquer cette table à chaque visite, sans reconstruire l’adresse à partir d’une règle approximative.

Renvoyez directement chaque ancienne adresse vers sa cible

Le dispositif reconnaît les anciennes adresses de produits, catégories, pages, marques, articles de blog et images. Lorsqu’il trouve une correspondance, il émet une redirection 301 vers l’adresse officielle du nouveau domaine.

Toute adresse virtuelle inconnue, sans fichier correspondant sur l’ancien serveur, repart vers le même chemin sur le nouveau domaine. Les pages importantes méritent toutefois une correspondance validée une par une.

Traitez les contenus qui ne possèdent plus de cible

Google recommande de renvoyer une réponse HTTP 404 ou 410 lorsqu’un contenu supprimé ne reprend pas sur le nouveau site. Rediriger de nombreuses anciennes adresses vers une page sans rapport, telle que la page d’accueil, peut désorienter les visiteurs et conduire Google à traiter ces pages comme des erreurs souples.

Une refonte de site Internet qui préserve le référencement demande donc d’identifier les contenus réellement repris avant de définir leurs destinations.

Installez le dispositif de migration PrestaShop sans gêner l’administration

Inforeole a livré le script et sa table dans un module PrestaShop installable depuis le back-office. Le module donne accès à un bouton Activer et à un bouton Désactiver.

Sauvegardez le fichier .htaccess avant toute activation

Le module crée une sauvegarde horodatée du fichier .htaccess avant d’ajouter ses règles. Il place son bloc en tête du fichier, hors de la zone que PrestaShop régénère.

Cette position protège les règles lors d’une régénération normale du fichier par PrestaShop, et la sauvegarde permet un retour arrière immédiat.

Excluez tout ce que l’ancienne boutique utilise encore

L’administration, ses ressources et le webservice de l’ancienne boutique doivent rester accessibles. Inforeole les a exclus des règles de redirection dès la première activation.

PrestaShop réécrit aussi en interne le chemin du webservice vers un autre dossier. Cette réécriture interne doit recevoir une exclusion adaptée, sinon les appels du service web peuvent basculer vers le nouveau domaine.

Le cas réel a montré que cette liste ne suffisait pas. Le lendemain de l’activation générale, le client ne pouvait plus télécharger ses factures depuis l’ancienne boutique, et son flux vers les places de marché signalait un flux principal inaccessible : la synchronisation des commandes, lancée toutes les cinq minutes, et l’export du catalogue partaient en 301 vers le nouveau domaine. Les adresses des modules du front ont donc rejoint les exclusions, avec ou sans code de langue.

Le jour suivant, les scripts planifiés de l’ancien serveur étaient à leur tour redirigés depuis vingt-deux heures : la mise à jour horaire des stocks et des statuts de commandes n’avait plus tourné, et un lancement manuel depuis le back-office aboutissait sur le nouveau domaine. La règle finale tient en une phrase : un fichier qui existe réellement sur l’ancien serveur est servi par l’ancien serveur, scripts planifiés, robots.txt et sitemaps compris. Un répertoire ne compte pas, et les adresses virtuelles du catalogue, images comprises, restent redirigées.

Ces requêtes redirigées ont atteint le nouveau domaine pendant tout l’incident. Lorsque le nouveau site héberge des scripts du même nom, ils ont pu s’y exécuter : ce point se vérifie pendant la migration.

La leçon dépasse ce cas : l’ancienne boutique n’est pas morte. Inforeole inventorie désormais ce qui l’appelle encore, facturation, flux, scripts planifiés et webservice, avant d’activer les règles, puis lit les journaux du serveur après l’activation. Une redirection 301 qui revient à heure fixe signe un script planifié ou un flux oublié.

Activez les règles par étapes avec un mode d’essai

Le mode d’essai affiche l’adresse cible sans rediriger. Inforeole a d’abord validé cinq adresses avec le client, puis a activé les règles sur l’ensemble du site.

Cette séquence réduit le risque de découvrir une erreur de correspondance après l’activation générale.

Vérifiez que PrestaShop ne supprime pas le bloc ajouté

Un script de sécurité ou une régénération du fichier .htaccess peut supprimer le bloc de redirection. Inforeole a prévu une vérification après chaque intervention sur l’ancienne boutique.

Un module PrestaShop doit aussi employer des noms de méthodes propres au module. Sur cette boutique, une méthode portant le même nom qu’une méthode de la classe Module faisait tomber la liste des modules, défaut corrigé avant l’installation définitive.

Testez votre migration PrestaShop avant et après son activation

Une redirection valide suit un chemin court : une réponse 301 sur l’ancienne adresse, puis une réponse 200 sur l’adresse officielle du nouveau site.

Contrôlez une réponse 301 suivie d’une réponse 200

Inforeole a vérifié les cinq adresses validées avec le client avant l’activation générale. Les contrôles ont ensuite couvert les 40 pages les plus cliquées selon la Search Console, puis 40 pages tirées au hasard, sur plusieurs langues et plusieurs types d’URL : chacune a répondu par un seul code 301, puis un code 200 sur le nouveau site.

Google indique que l’outil d’inspection d’URL sert aux contrôles unitaires, tandis que les outils ou scripts en ligne de commande conviennent à un volume important d’adresses.

Utilisez un outil en ligne de commande plutôt qu’un navigateur

Un navigateur peut mettre une redirection 301 en cache. Un test répété dans le navigateur peut donc masquer une modification récente ou laisser croire qu’une ancienne règle fonctionne encore.

Un outil en ligne de commande lit les réponses HTTP sans s’appuyer sur ce cache de navigation. Il permet de contrôler séparément le code 301, l’adresse indiquée dans l’en-tête de redirection et le code 200 final.

Surveillez les pages importantes et les journaux serveur

Google conseille de commencer par les URL importantes, repérées dans les sitemaps, les journaux serveur, les données analytiques et Search Console. Les images doivent aussi rejoindre le plan de migration lorsqu’elles sont intégrées aux pages.

Après le lancement, les journaux serveur permettent de repérer les explorations de Googlebot, les erreurs HTTP inattendues et le trafic réel.

Vérifiez les redirections après chaque intervention sur l’ancien site

Chaque modification du fichier .htaccess, chaque passage d’un script de sécurité et chaque action de maintenance peuvent affecter le bloc de redirection. Inforeole recommande donc de contrôler quelques adresses représentatives après chaque intervention sur l’ancien site.

Le mode maintenance de l’ancienne boutique sert de filet : si le bloc de redirection disparaît, les visiteurs voient une page de maintenance au lieu d’une copie de la boutique qui concurrencerait le nouveau site.

Déclarez le changement de domaine dans Search Console

Le changement de domaine se prépare dans Search Console lorsque les redirections fonctionnent déjà. L’outil Changement d’adresse vient compléter les redirections 301, qui restent indispensables.

Vérifiez les deux propriétés avant le changement d’adresse

Le même compte Google doit détenir le rôle de propriétaire sur les propriétés de l’ancien et du nouveau site. Un utilisateur délégué ne peut pas valider l’étape finale.

L’outil Changement d’adresse contrôle la propriété des deux sites et vérifie aussi quelques redirections 301 avant d’envoyer la demande.

Choisissez une vérification DNS lorsque vous le pouvez

Une propriété de domaine demande une vérification par DNS. Cette méthode reste liée au domaine, même lorsque les pages publiques redirigent.

Une vérification par fichier HTML suppose d’exclure ce fichier des redirections, et une vérification par balise dans la page d’accueil cesse d’être lue dès que cette page redirige. Inforeole recommande donc la vérification par DNS avant toute migration.

Gardez l’ancien domaine et ses redirections pendant au moins un an

Google recommande de conserver les redirections aussi longtemps que possible, généralement au moins un an. Cette durée laisse à Google le temps de transférer les signaux vers les nouvelles URL.

Le renouvellement de l’ancien domaine doit donc rester prévu dans le calendrier de migration.

Évitez les pièges qui dégradent une migration PrestaShop

Une migration peut répondre correctement sur une partie des adresses tout en laissant des chaînes ou des exclusions incorrectes ailleurs. Les contrôles d’Inforeole visent les comportements réellement observés, pas la règle sur le papier.

Utilisez l’adresse officielle qui inclut le code EAN lorsqu’il existe

Inforeole a vérifié que PrestaShop 8 ajoutait le code EAN à la fin de certaines adresses officielles de produits. Une cible sans ce code recevait ensuite une redirection 302 vers l’adresse canonique.

La table de correspondance doit donc reprendre l’adresse officielle complète renvoyée par le nouveau site.

Distinguez la redirection canonique du nouveau site du dispositif de migration

Le réglage de redirection canonique du nouveau site répond à un problème distinct : il ramène des adresses approchantes vers l’adresse officielle. Sur cette boutique, ce réglage utilisait une 302 par défaut, et PrestaShop permet de le passer en 301 dans ses paramètres de trafic et de référencement.

Cette optimisation relève du nouveau site, alors que les redirections de migration relèvent de l’ancien domaine.

Évitez de rediriger un contenu supprimé vers une page sans rapport

Une catégorie ou un produit absent du nouveau site ne doit pas recevoir une destination inventée. Google déconseille d’envoyer massivement des anciennes URL vers une page sans rapport.

La décision doit suivre le contenu réellement conservé, fusionné ou supprimé.

Donnez une réponse 404 ou 410 lorsque le contenu ne reprend pas

Lorsqu’aucune cible pertinente n’existe, une réponse 404 ou 410 décrit la situation au navigateur et au moteur de recherche. Google recommande ces réponses pour les contenus supprimés ou non repris.

Estimez le tarif de votre migration PrestaShop

Inforeole réalise le plan de redirection 301 de votre migration à partir de 1 200 € HT. Ce forfait ne comprend pas la migration de la boutique elle-même, qui reste à la charge de votre agence ou de votre hébergeur : il couvre ce qui conserve votre référencement. Le forfait de base comprend une boutique jusqu’à 5 000 références en une langue, les redirections des produits, catégories, pages et marques vers l’adresse officielle du nouveau site, le module installé depuis le back-office avec activation et retour arrière, l’activation progressive avec validation d’un échantillon par vos soins, la vérification après activation sur un échantillon de pages et un rapport des contrôles.

L’estimateur ci-dessous vous donne un ordre de grandeur en trente secondes. Le devis définitif est établi après un échange d’une trentaine de minutes sur votre boutique, vos langues et vos contenus. Vous pouvez dès maintenant demander un devis de migration à Inforeole.

FAQ

Faut-il placer l’ancienne boutique en maintenance ?

Ce n’est pas nécessaire pour rediriger, car les règles agissent avant PrestaShop. Le mode maintenance sert de filet si le bloc de redirection disparaît un jour du fichier .htaccess, et le back-office reste accessible dans les deux cas.

Combien de temps faut-il garder les redirections ?

Google recommande de les garder aussi longtemps que possible, généralement au moins un an, afin de transférer les signaux vers les nouvelles URL.

Comment pouvez-vous vérifier une redirection sans navigateur ?

Utilisez un outil en ligne de commande qui affiche les réponses HTTP. Vous devez constater une réponse 301 unique sur l’ancienne adresse, puis une réponse 200 sur la destination officielle.

Que faites-vous des produits supprimés du nouveau site ?

Lorsqu’aucune page pertinente ne reprend le produit, l’ancienne adresse doit renvoyer une réponse 404 ou 410. Une redirection vers une page sans rapport, notamment la page d’accueil, ne décrit pas correctement la disparition du contenu.

Le client conserve-t-il son back-office ?

Oui. Les règles de redirection excluent le back-office, ses ressources et le webservice de l’ancienne boutique, qui restent accessibles comme avant.

Mes factures, mes flux et mes crons continuent-ils de fonctionner sur l’ancienne boutique ?

Oui. Les adresses des modules et tout fichier réellement présent sur l’ancien serveur, scripts planifiés compris, restent servis par l’ancienne boutique. L’inventaire de ces intégrations fait partie de la préparation, et les journaux du serveur sont relus après l’activation pour repérer un appel oublié.

Combien de temps dure la prestation ?

Quelques jours ouvrés après la réception des accès, selon la taille du catalogue et le nombre de langues. L’activation se fait à l’heure que vous choisissez, après validation de l’échantillon.