Changer le domaine d'une boutique PrestaShop : checklist SEO et redirections 301

1. Cartographie d'architecture et audit des routes d'URLs avant bascule

Changer le nom de domaine principal d'une boutique PrestaShop en production constitue l'une des opérations d'ingénierie les plus délicates pour un site marchand. Lorsqu'une boutique opère depuis cinq ans, son empreinte dans les index des moteurs de recherche repose sur un maillage complexe de pages indexées, de paramètres d'URL, de métadonnées canoniques et de backlinks accumulés. Procéder à une migration sans avoir dressé un inventaire exhaustif et mathématique de chaque route expose immédiatement votre infrastructure à une perte d'équité de liens et à une chute brutale de trafic organique.

La première étape consiste à extraire l'intégralité des routes actives directement depuis la base de données relationnelle MySQL ou MariaDB, plutôt que de vous fier à un simple crawl externe qui omettrait les URLs orphelines, les facettes non maillées ou les routes profondes. Les tables ps_product_lang, ps_category_lang, ps_cms_lang et ps_meta fournissent la vérité terrain sur les identifiants et les réécritures d'URLs. Lors de la structuration de votre plan de redirection, vous devez isoler chaque gabarit pour valider le comportement du contrôleur frontal et des règles de réécriture. Par exemple, sur une référence précise comme le t-shirt imprimé colibri, l'identifiant numérique et le slug textuel doivent converger sans ambiguïté vers la nouvelle adresse.

De la même façon, les sections mères et les têtes de rayon comme le catalogue de vêtements pour hommes ou les rayons de fournitures de papeterie concentrent un historique de positionnement considérable. Si ces pages changent de FQDN (Fully Qualified Domain Name) sans une correspondance stricte de leurs paramètres de pagination et de tri, l'arborescence descendante perd instantanément son autorité thématique. L'extraction initiale doit également isoler les routes personnalisées définies dans le module de réécriture ou le fichier routes.yml de votre thème afin de ne laisser aucune route applicative sans correspondance explicite.

2. Mise à jour de la base de données PrestaShop : ps_shop_url et ps_configuration

L'erreur la plus répandue consiste à tenter de modifier le nom de domaine exclusivement depuis l'interface d'administration de PrestaShop (Préférences > SEO & URLs). Si le cache mémoire ou le cache opcode est actif, cette action via l'interface graphique peut déclencher une déconnexion immédiate de votre session administrateur tout en laissant les tables de configuration dans un état intermédiaire incohérent. Pour garantir une exécution atomique, la mise à jour doit être réalisée directement en ligne de commande SQL, après avoir figé les écritures applicatives et généré un dump physique de sauvegarde.

PrestaShop s'appuie sur deux tables maîtresses pour résoudre le domaine d'une boutique : ps_shop_url et ps_configuration. La table ps_shop_url contient les variables physiques de routage (domain, domain_ssl et physical_uri), tandis que ps_configuration stocke les directives globales PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL. Pour une architecture multisite ou conteneurisée, vous pouvez vous appuyer sur notre guide technique de migration de domaine afin de contextualiser ces modifications dans votre pipeline d'infrastructure.

Voici la séquence SQL exacte à appliquer dans votre client MySQL ou MariaDB pour basculer le routage de votre instance vers le nouveau domaine :

-- Vérification préalable de la configuration existante
SELECT id_shop, domain, domain_ssl, physical_uri FROM ps_shop_url;

-- Transaction de mise à jour atomique
START TRANSACTION;

UPDATE ps_shop_url
SET domain = 'nouveau-domaine.fr',
    domain_ssl = 'nouveau-domaine.fr',
    physical_uri = '/'
WHERE id_shop = 1;

UPDATE ps_configuration
SET value = 'nouveau-domaine.fr'
WHERE name = 'PS_SHOP_DOMAIN';

UPDATE ps_configuration
SET value = 'nouveau-domaine.fr'
WHERE name = 'PS_SHOP_DOMAIN_SSL';

COMMIT;

Une fois les tables de routage alignées, une vérification approfondie des contenus textuels stockés en base s'impose. Des liens internes absolus pointant vers l'ancien nom de domaine sont fréquemment codés en dur dans les descriptions de produits, les blocs CMS ou les configurations de modules tiers. Utilisez des requêtes ciblées pour identifier ces occurrences sans effectuer de remplacement aveugle qui risquerait de corrompre des données sérialisées :

-- Détection des liens résiduels dans les descriptions de produits
SELECT id_product, id_lang, description 
FROM ps_product_lang 
WHERE description LIKE '%ancien-domaine.fr%' 
LIMIT 10;

-- Détection des URLs absolues dans les pages CMS
SELECT id_cms, id_lang, content 
FROM ps_cms_lang 
WHERE content LIKE '%ancien-domaine.fr%';

Après validation des requêtes, le cache applicatif de PrestaShop doit être purgé intégralement depuis le système de fichiers pour forcer la recompilation du conteneur d'injection de dépendances Symfony et des templates Smarty :

# Purge du cache applicatif Symfony
rm -rf var/cache/prod/* var/cache/dev/*

# Réinitialisation du cache mémoire si actif
redis-cli flushdb

3. Configuration Nginx : règles de redirection 301 stricte et gestion du mapping

Traiter les redirections 301 au niveau du code PHP via des modules ou le contrôleur de tête de PrestaShop est une mauvaise pratique architecturale. Chaque requête envoyée à l'ancien domaine nécessiterait le démarrage du runtime PHP, le chargement de l'autoloader Composer, la connexion à la base de données et l'initialisation du framework, consommant inutilement des dizaines de mégaoctets de mémoire vive par requête. Sur un pic de crawl où les robots de Google explorent simultanément plusieurs dizaines de milliers d'URLs obsolètes, ce mécanisme sature rapidement les workers PHP-FPM.

Le traitement des redirections permanentes doit être intégralement délégué au serveur web Nginx, en amont de PHP. Nginx gère les connexions HTTP avec une architecture événementielle asynchrone non-bloquante, capable de délivrer une réponse 301 en moins de deux millisecondes avec une empreinte processeur quasi nulle. Vous pouvez vous référer à la documentation du module rewrite de Nginx pour explorer les spécifications complètes des directives de réécriture et d'évaluation des expressions régulières.

« Sur une infrastructure e-commerce en production, déléguer les redirections d'un changement de domaine à PHP ou à des modules tiers est une erreur de conception. Le traitement doit impérativement s'effectuer au niveau du serveur web Nginx, en amont du runtime. Une redirection 301 native répond en moins de deux millisecondes sans consommer de worker PHP, garantissant aux robots des moteurs de recherche un crawl fluide de plusieurs dizaines de milliers de pages sans saturation mémoire. »

— Alexandre Carette

Dans le cas le plus fréquent où la structure des chemins d'URLs demeure rigoureusement identique entre l'ancien et le nouveau domaine, la configuration d'un bloc serveur dédié sur l'ancien FQDN permet de réexpédier l'ensemble du trafic de façon déterministe avec la variable $request_uri, laquelle préserve nativement le chemin et les query strings :

# Bloc de redirection pour l'ancien domaine (HTTP)
server {
    listen 80;
    listen [::]:80;
    server_name ancien-domaine.fr www.ancien-domaine.fr;
    return 301 https://nouveau-domaine.fr$request_uri;
}

# Bloc de redirection pour l'ancien domaine (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ancien-domaine.fr www.ancien-domaine.fr;

    ssl_certificate /etc/letsencrypt/live/ancien-domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ancien-domaine.fr/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Préservation intégrale du chemin et des paramètres de requête
    return 301 https://nouveau-domaine.fr$request_uri;
}

Lorsque la migration de domaine s'accompagne d'une refonte des structures d'URLs (par exemple, la suppression des identifiants numériques dans les slugs ou la réorganisation des catégories), l'utilisation d'une table de hachage via la directive map de Nginx offre des performances optimales en complexité algorithmique O(1), bien supérieures à une accumulation de règles rewrite séquentielles :

# Définition de la table de mapping dans le contexte http
map $uri $new_target_uri {
    default "";
    /ancien-chemin/guide.html /nouveau-chemin/guide/;
    /promotions-hiver /destockage;
}

server {
    listen 443 ssl http2;
    server_name ancien-domaine.fr;

    ssl_certificate /etc/letsencrypt/live/ancien-domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ancien-domaine.fr/privkey.pem;

    # Si une correspondance explicite existe dans le mapping
    if ($new_target_uri != "") {
        return 301 https://nouveau-domaine.fr$new_target_uri;
    }

    # Redirection générique par défaut
    return 301 https://nouveau-domaine.fr$request_uri;
}

4. Déploiement DNS, double certification TLS et gestion des sitemaps XML

L'orchestration réseau et la synchronisation avec les moteurs de recherche conditionnent la fluidité de la transition. Une bascule DNS mal calibrée peut entraîner une indisponibilité temporaire ou des erreurs de certificat SSL qui interrompent net le transfert du signal de confiance accumulé au fil des années. La méthodologie requiert un calendrier d'exécution strict étalé sur plusieurs jours.

Quarante-huit heures avant la date prévue pour la bascule, vous devez abaisser le TTL (Time To Live) de vos enregistrements DNS pour l'ancien comme pour le nouveau domaine à 300 secondes (5 minutes). Cette précaution garantit que la propagation des nouvelles adresses IP s'effectuera de façon quasi instantanée sur les résolveurs publics du monde entier le jour de l'opération.

Le déploiement des certificats TLS constitue un autre point critique souvent négligé. Pour que la redirection 301 soit lue et exécutée par un navigateur ou par un crawler, la négociation TLS (le handshake HTTPS) doit aboutir sans avertissement de sécurité. Vous devez donc maintenir un certificat SSL valide et renouvelé pour l'ancien domaine pendant au minimum douze mois, tout en installant le certificat du nouveau domaine sur le serveur cible.

Concernant les sitemaps XML et la console d'administration des moteurs de recherche, la démarche rigoureuse s'articule autour des étapes suivantes :

1. Conservation de l'ancien sitemap XML : Maintenez l'ancien fichier sitemap accessible sur l'ancien domaine, pointant vers les anciennes URLs qui répondent désormais en 301. Cela incite les robots à revisiter régulièrement l'ancien catalogue pour enregistrer le déplacement permanent des pages.
2. Génération et soumission du nouveau sitemap : Générez un sitemap propre et exhaustif sur le nouveau domaine (via le module natif gsitemap ou un script dédié) listant uniquement les URLs en code HTTP 200, puis soumettez-le sur la nouvelle propriété Google Search Console.
3. Validation au niveau du domaine dans Google Search Console : Créez une propriété de type Domaine (via enregistrement DNS TXT) pour le nouveau domaine afin d'englober tous les protocoles et sous-domaines potentiels.
4. Déclaration du changement d'adresse : Activez l'outil officiel de changement d'adresse dans les paramètres de l'ancienne propriété Search Console, en sélectionnant le nouveau domaine validé. L'outil effectue une validation préliminaire des redirections 301 avant de confirmer la prise en compte du transfert.

5. Surveillance active des logs Nginx et plan d'éradication des erreurs 404 sur 90 jours

Le jour du basculement ne marque pas la fin du travail d'ingénierie, mais le début d'une phase de veille active de 90 jours. C'est durant ce trimestre que les algorithmes de crawl redistribuent le PageRank et que les plateformes tierces mettent à jour leurs index. Une surveillance rigoureuse des journaux d'accès (access logs) de Nginx permet d'intercepter immédiatement les erreurs 404 avant qu'elles ne dégradent votre profil d'indexation.

Les erreurs 404 post-migration proviennent généralement de trois sources distinctes : des règles de réécriture mal calibrées sur des URLs spécifiques, des backlinks historiques pointant vers des formats oubliés, ou des requêtes générées par des applications tierces dont les flux d'API n'ont pas été réorientés. L'analyse directe des journaux Nginx en ligne de commande fournit un diagnostic immédiat et sans biais.

Voici un pipeline de commandes bash permettant d'extraire quotidiennement les 20 URLs les plus fréquemment sollicitées qui retournent un code HTTP 404 sur votre serveur :

# Extraction des URLs en 404 triées par volume de requêtes
awk '($9 ~ /404/)' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -n 20

Pour remonter à la source de l'erreur et déterminer quel site externe ou quel script génère ces requêtes orphelines, l'analyse du champ HTTP Referer s'avère indispensable :

# Identification des referers générant des réponses 404
awk '($9 ~ /404/)' /var/log/nginx/access.log | awk -F'"' '{print $4 " -> " $2}' | sort | uniq -c | sort -rn | head -n 20

Le protocole de suivi sur 90 jours doit être rythmé par un calendrier d'actions précises :

• Jours 1 à 7 : Analyse quotidienne des journaux Nginx et des rapports d'indexation Search Console. Correction immédiate des chemins d'URLs oubliés via des ajouts ciblés dans la table de mapping Nginx.
• Jours 8 à 30 : Comparaison hebdomadaire des courbes d'impressions et de clics entre l'ancienne et la nouvelle propriété. Vérification de la disparition progressive des pages de l'ancien domaine dans les résultats de recherche au profit du nouveau.
• Jours 31 à 60 : Cartographie des backlinks externes majeurs qui transitent encore par une redirection 301. Contact direct avec les partenaires éditoriaux stratégiques pour mettre à jour les liens sources et éliminer la latence liée à la redirection.
• Jours 61 à 90 : Stabilisation finale des métriques de trafic organique, vérification des positions sur les requêtes clés de votre catalogue et clôture formelle du dossier de migration.

6. Synthèse d'ingénierie et sécurisation de votre environnement e-commerce

Migrer le nom de domaine d'une boutique PrestaShop sans dégrader son autorité SEO exige une rigueur méthodique à chaque niveau de la pile technique : intégrité des données en base SQL, configuration déterministe des redirections 301 sous Nginx, maintien du handshake TLS sur l'ancien FQDN et surveillance continue des journaux système. Lorsqu'elle est exécutée selon ces principes d'artisan-ingénieur, la transition s'opère sans rupture de trafic ni perte de visibilité.

Chaque couche d'infrastructure, de la base de données relationnelle aux directives de proxying inverse, joue un rôle déterminant dans la préservation de vos positions organiques. En traitant les redirections au plus près du noyau réseau et en monitorant activement les réponses HTTP 404, vous éliminez tout risque de déperdition de PageRank.

Pour aller plus loin et garantir qu'aucun point de friction technique ne bride votre croissance organique après une telle opération, vous pouvez demander votre Note de Mesure personnalisée. Ce diagnostic technique complet évalue en profondeur la performance Core Web Vitals, la conformité SEO technique, la sécurité et l'architecture de votre boutique PrestaShop, réalisé sur-mesure par Alexandre Carette.