Changer le nom de domaine d'une boutique PrestaShop sans perdre son référencement

Les fondations d'une migration réussie : sauvegardes et préparation technique

Changer le nom de domaine d'une boutique PrestaShop ne se résume pas à pointer un nouveau DNS vers un hébergement web. Pour un site e-commerce en production, chaque URL indexée représente un historique d'autorité, des positions acquises et un flux régulier de commandes. Une modification d'adresse mal orchestrée peut désindexer des milliers de fiches produits en quelques jours ou rompre les tunnels d'achat. Pour sécuriser l'opération, la phase préparatoire doit figer l'environnement existant et prévenir toute perte de données transactionnelles.

Avant d'effectuer la moindre modification dans la base de données ou sur vos fichiers de configuration, vous devez isoler votre plateforme et suspendre l'activité commerciale le temps de la bascule. Cette isolation évite qu'une commande ne soit validée pendant que vous manipulez les tables ou que des sessions d'utilisateurs ne se retrouvent corrompues entre deux domaines.

• Sauvegarde intégrale de la base de données : Réalisez un dump SQL complet via la ligne de commande ou un outil d'administration de base de données. Vérifiez que les tables InnoDB, les déclencheurs (triggers) et les routines sont intégralement exportés sans coupure de délai d'exécution.
• Sauvegarde du système de fichiers : Archivez l'intégralité du répertoire racine de PrestaShop, en accordant une attention particulière au dossier des images produits, aux modules personnalisés et au dossier de configuration.
• Activation du mode maintenance : Basculez votre boutique en maintenance depuis le panneau d'administration de PrestaShop afin de bloquer les tunnels de commande tout en ajoutant votre propre adresse IP dans la liste blanche pour conserver l'accès au catalogue.
• Inventaire des dépendances externes : Listez l'ensemble des services connectés à votre boutique : passerelles de paiement, transporteurs automatisés, outils ERP, places de marché et plateformes de synchronisation des stocks.

La gestion des versions : PrestaShop 1.7, 8 et 9

Les versions récentes de PrestaShop reposent sur le framework Symfony, ce qui modifie profondément la façon dont le moteur gère le routage et le cache interne par rapport aux anciennes branches comme PrestaShop 1.6. Sur PrestaShop 1.7, 8 et 9, une modification de domaine non répercutée dans le conteneur de services compilé provoque immédiatement des erreurs de routage ou des redirections erratiques vers l'ancien nom d'hôte. La procédure doit donc combiner la mise à jour des enregistrements relationnels en base de données et l'évacuation physique des artefacts de compilation.

Mise à jour de la base de données et purge intégrale des caches PrestaShop

PrestaShop stocke le nom de domaine de la boutique à deux endroits stratégiques de sa base de données : dans la table de routage dédiée aux boutiques et dans la table générale de configuration. Si vous tentez de modifier le domaine uniquement depuis le back-office sans anticiper la propagation DNS ou le certificat SSL, vous risquez de vous enfermer hors de votre propre panneau d'administration. L'approche la plus fiable consiste à intervenir directement en base de données, puis à purger les caches en ligne de commande.

Deux tables principales gouvernent le nom de domaine au sein du schéma de données. Vous devez remplacer les valeurs de l'ancien domaine par le nouveau, en veillant à conserver scrupuleusement le chemin physique d'installation (généralement une simple barre oblique pour une boutique installée à la racine de l'hébergement) :

1. Table ps_shop_url : Cette table définit l'adresse principale et l'adresse sécurisée associées à l'identifiant de votre boutique. Les colonnes domain et domain_ssl doivent recevoir votre nouveau nom de domaine, sans préfixe de protocole (sans http:// ni https://) et sans barre oblique finale.
2. Table ps_configuration : Deux clés fondamentales doivent être mises à jour : PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL. Elles servent de référence pour de nombreux modules tiers et pour la génération de certains liens internes.
3. Contrôle du fichier de configuration : Sur PrestaShop 1.7, le fichier app/config/parameters.php stocke les accès à la base de données et la clé secrète du site. Sur PrestaShop 8 et 9, ces éléments se trouvent dans config/parameters.php ou sont relayés par un fichier de variables d'environnement. Si la migration de domaine s'accompagne d'un changement de serveur ou de base de données, ajustez ces paramètres avec précision.
4. Suppression physique des caches applicatifs : Ne comptez pas sur le bouton de vidage du cache du back-office, car celui-ci ne supprime pas l'ensemble des conteneurs compilés par Symfony. Connectez-vous en SSH à votre serveur et supprimez récursivement le contenu des dossiers var/cache/prod/ et var/cache/dev/. Cette étape force PrestaShop à reconstruire son arborescence de dépendances avec le nouveau nom de domaine dès la première requête.
5. Purge du cache Smarty : Videz les répertoires de compilation du moteur de rendu Smarty afin d'éliminer tout fragment HTML compilé contenant encore les anciennes URLs absolues en dur dans les gabarits de votre thème.

Redirections 301 au niveau serveur : pourquoi bannir les modules PrestaShop

La transmission du capital de référencement d'un domaine vers un autre repose exclusivement sur la mise en place de redirections permanentes, identifiées par le code de statut HTTP 301. Ces redirections indiquent aux moteurs de recherche que chaque ressource a définitivement changé d'adresse et qu'il convient de transférer les signaux de popularité, l'historique d'indexation et les liens entrants vers la nouvelle URL correspondante. Le choix de l'emplacement technique de ces redirections détermine la survie de votre référencement.

De nombreux marchands commettent l'erreur d'installer un module PrestaShop dédié aux redirections sur leur nouvelle boutique ou de maintenir une installation PHP sur l'ancien domaine pour traiter la bascule. Cette méthode introduit une dégradation sévère du temps de réponse (TTFB), surcharge inutilement le serveur et expose le site à des ruptures critiques en cas d'erreur logicielle.

Sur le terrain, la majorité des pertes de trafic constatées après un changement de domaine ne proviennent pas d'une mauvaise volonté des moteurs de recherche, mais d'une cascade d'oublis techniques invisibles au premier coup d'œil. Une redirection 301 qui saute sur les déclinaisons de produits, un cache applicatif qui continue d'injecter des URLs canoniques périmées ou des passerelles de paiement qui voient leurs webhooks rejetés : chaque détail non vérifié fragilise l'ensemble de la boutique. Notre règle est simple : on ne coupe l'ancien domaine et son hébergement qu'après avoir constaté l'extinction complète de son trafic au profit du nouveau.

— Alexandre Carette

L'impératif du traitement en amont par Nginx ou Apache

Pour qu'un moteur de recherche traite efficacement des dizaines de milliers de redirections sans épuiser son budget d'exploration, la réponse HTTP 301 doit être renvoyée en quelques millisecondes, sans charger le noyau PHP, sans interroger la base de données et sans démarrer le framework PrestaShop. Le traitement doit s'effectuer au niveau le plus bas de la pile d'hébergement : le serveur web.

Sur un serveur Nginx, la configuration s'effectue dans un bloc serveur dédié à l'ancien domaine. Ce bloc écoute les ports HTTP et HTTPS, applique le certificat SSL de l'ancien domaine et renvoie instantanément vers le nouveau nom d'hôte en conservant l'intégralité de la chaîne de requête :

• Conservation absolue de l'URI : La variable de requête doit être transmise sans altération pour que l'adresse d'un produit sur l'ancien domaine redirige strictement vers le même produit sur le nouveau domaine.
• Gestion obligatoire du SSL sur l'ancien domaine : Vous devez impérativement maintenir un certificat SSL valide sur l'ancien domaine. Si un internaute ou un robot suit un lien externe vers une adresse sécurisée de l'ancien domaine et que le certificat est expiré ou absent, le navigateur affichera une alerte de sécurité bloquante avant même de pouvoir lire l'en-tête de redirection 301.
• Règles de réécriture sous Apache : Si vous utilisez Apache, configurez les directives de réécriture à la racine de l'ancien hébergement via le fichier de configuration de l'hôte virtuel ou un fichier de règles serveur dédié, en interdisant toute réécriture interne avant la redirection globale.

Tableau comparatif : les étapes critiques de la bascule et leurs points de contrôle

Une migration d'adresse e-commerce réussie repose sur une séquence chronologique stricte. Sauter une étape ou exécuter les actions dans le désordre entraîne presque systématiquement des boucles de redirection ou des indisponibilités partielles. Le tableau suivant synthétise les phases opérationnelles, les composants techniques concernés et les points de vigilance majeurs à vérifier.

Les pièges techniques fréquents : boucles, médias en dur et webhooks bancaires

L'expérience montre que les dysfonctionnements observés après le changement de domaine proviennent rarement de la configuration générale de PrestaShop, mais plutôt de résidus techniques ancrés dans les contenus éditoriaux, de configurations de serveurs contradictoires ou de liaisons applicatives externes ignorées lors du chantier.

Le premier piège concerne les boucles infinies de redirection (redirection loops). Ce phénomène survient généralement lorsque PrestaShop est configuré pour forcer le protocole SSL (option activer le SSL sur tout le site) alors que le serveur web ou le répartiteur de charge en amont n'envoie pas l'en-tête de transfert adéquat. Le serveur redirige la requête vers le protocole sécurisé, tandis que l'application, ne détectant pas l'état chiffré, renvoie une nouvelle directive de redirection vers la même ressource. Pour résoudre ce blocage, vérifiez la cohérence entre la directive de réécriture du serveur web et les paramètres de détection HTTPS de PrestaShop.

Le nettoyage des images et liens codés en dur dans le contenu

Au fil des années d'exploitation d'une boutique PrestaShop, les éditeurs de contenu, les modules de blog ou les générateurs de pages insèrent fréquemment des liens absolus pointant vers l'ancien nom de domaine directement au cœur du code HTML des fiches produits et des pages de contenu. Si vous ne traitez pas ces références, vos nouvelles pages contiendront des centaines de liens internes pointant vers l'ancien domaine qui déclencheront inutilement des redirections 301 à chaque clic, ralentissant la navigation et brouillant les signaux d'exploration.

De plus, si certaines images de description ou certains éléments graphiques appellent l'ancien domaine et que ce dernier vient un jour à expirer ou à présenter une défaillance de certificat SSL, vos fiches produits afficheront des erreurs de contenu mixte ou des images brisées. Une opération de recherche et remplacement ciblée dans les tables linguistiques de la base de données s'avère indispensable pour assainir le code :

• Description des fiches produits : Appliquez une fonction de remplacement textuel SQL sur les colonnes de description de la table dédiée aux langues des produits pour substituer l'ancienne URL par la nouvelle.
• Pages CMS et blocs de pied de page : Répétez l'opération sur les contenus éditoriaux institutionnels pour mettre à jour les mentions légales, conditions générales et guides d'achat.
• Modules de menu et bannières : Inspectez les tables des modules de navigation personnalisés, qui enregistrent très souvent des adresses absolues lors de la création manuelle des liens de menu.

Les modules de paiement et les webhooks de notification

Il s'agit d'un point névralgique qui peut paralyser l'activité commerciale d'un site e-commerce dès sa réouverture. Les solutions de paiement modernes (cartes bancaires, prestataires de paiement fractionné, portefeuilles électroniques) fonctionnent grâce à des communications asynchrones : une fois le paiement validé par la banque du client, les serveurs de la passerelle envoient une notification HTTP directe (webhook ou URL de notification instantanée) à votre boutique pour transformer le panier en commande confirmée et modifier les stocks.

Or, la quasi-totalité des passerelles bancaires refusent catégoriquement de suivre les redirections 301 pour des raisons de sécurité cryptographique. Si votre passerelle tente d'envoyer la confirmation de paiement sur l'ancien domaine et reçoit une réponse 301, la notification est immédiatement rejetée comme invalide. Le client voit son compte débité, mais la boutique n'enregistre jamais la commande. Vous devez impérativement vous connecter aux consoles d'administration de chacun de vos prestataires de paiement pour actualiser manuellement les URLs de notification et les adresses de retour d'authentification.

Google Search Console et signaux SEO : la déclaration officielle de changement d'adresse

Dès que les redirections serveur sont opérationnelles et que la nouvelle boutique répond parfaitement sous son nouveau nom d'hôte, vous devez officialiser la transition auprès des moteurs de recherche. La transmission du signal de redirection 301 au niveau HTTP est nécessaire, mais elle doit être consolidée par les outils d'administration web pour accélérer la prise en compte de la nouvelle marque et synchroniser l'indexation.

La Search Console propose un outil spécifique de changement d'adresse conçu pour avertir les robots qu'un domaine entier glisse vers une nouvelle destination. Cet outil déclenche une priorité d'exploration sur les anciennes URLs afin de constater rapidement les redirections et de mettre à jour les résultats de recherche au profit du nouveau domaine.

• Validation des deux propriétés : Vous devez disposer d'un accès vérifié au niveau propriétaire sur l'ancien domaine et sur le nouveau. Privilégiez systématiquement la validation par enregistrement DNS TXT (propriété de domaine), qui englobe l'ensemble des sous-domaines et des protocoles sans omission.
• Activation de l'outil de changement d'adresse : Dans les paramètres de la propriété de l'ancien domaine, lancez la procédure de changement d'adresse. L'outil effectue une série de vérifications préliminaires automatisées sur quelques URLs représentatives afin de s'assurer que la redirection 301 vers le nouveau domaine est bien fonctionnelle.
• Soumission immédiate du sitemap XML : Générez un sitemap neuf depuis PrestaShop reflétant exclusivement les nouvelles adresses canoniques, puis soumettez-le sur la propriété Search Console du nouveau domaine. Cela aide les robots à découvrir immédiatement l'exhaustivité de votre arborescence sous sa nouvelle identité.
• Contrôle des balises canoniques : Inspectez le code source de plusieurs typologies de pages (accueil, catégories, fiches produits, pages informatives) pour vérifier que la balise d'URL canonique présente dans l'en-tête HTML mentionne rigoureusement le nouveau domaine et ne génère aucun conflit d'auto-référencement avec l'ancienne adresse.

Surveillance post-migration : l'analyse des logs et le calendrier de contrôle

La bascule technique ne constitue que la première phase de l'opération. Les semaines qui suivent la mise en ligne du nouveau domaine exigent une surveillance rigoureuse pour détecter les éventuels décrochages d'indexation, identifier les liens brisés et s'assurer que les robots explorent activement la nouvelle plateforme. Le suivi des positions ne doit pas être guidé par des suppositions, mais par l'analyse objective des données d'exploration et d'affichage.

L'observation quotidienne des fichiers de logs du serveur web constitue le moyen le plus rapide d'évaluer la santé de la migration. En filtrant les requêtes selon les agents utilisateurs des robots d'exploration, vous pouvez mesurer avec précision le rythme de découverte du nouveau domaine et constater l'extinction progressive des requêtes aboutissant sur l'ancien.

Analyse des codes de statut dans les journaux d'accès :

Vérifiez que 100 % des requêtes arrivant sur l'ancien domaine renvoient immédiatement un code HTTP 301. La présence de codes 404 sur l'ancien domaine signale une omission dans vos règles de redirection, tandis que des codes 500 trahissent une défaillance logicielle au niveau de l'hôte virtuel.

Surveillance du rapport d'indexation des pages :

Dans la Search Console, suivez la courbe des pages indexées. Vous devez observer un transfert progressif : la courbe de l'ancien domaine diminue tandis que celle du nouveau progresse de manière symétrique. Tout écart persistant au-delà de plusieurs semaines révèle un goulot d'étranglement dans le maillage ou un problème d'accès robot.

Maintien dans la durée de l'ancien nom de domaine :

Ne commettez jamais l'imprudence de résilier votre ancien domaine ou d'interrompre son certificat SSL au bout de quelques mois. Les liens externes acquis au fil des ans sur d'autres sites web, les favoris de vos clients réguliers et l'indexation profonde continueront de solliciter l'ancienne adresse pendant de longues années. Conservez l'ancien domaine et son routage sécurisé aussi longtemps que possible afin de préserver l'actif numérique de votre entreprise.

Synthèse méthodologique

Changer de nom de domaine sur PrestaShop est une opération délicate mais parfaitement maîtrisable lorsque chaque maillon technique est respecté dans un ordre méthodique. En combinant une mise à jour rigoureuse des tables de données, une purge physique complète des caches du framework, des redirections 301 gérées directement au niveau du serveur web et une surveillance vigilante des passerelles transactionnelles, vous assurez la continuité de votre activité commerciale et préservez durablement l'autorité de votre boutique sur les moteurs de recherche.

À lire aussi

• Coulisses : propulser un Hub Pro avec PrestaShop Headless et Nuxt