Changer le nom de domaine d’une boutique e-commerce sans perdre le SEO : la méthode complète, de J-60 à J+365

Changer le nom de domaine d’une boutique, c’est rarement la redirection qui pose problème. C’est tout ce qui est accroché au nom sans qu’on y pense : les e-mails de confirmation de commande, le webhook de paiement, le compte Merchant Center, le bouton Apple Pay, le lien de désinscription de la newsletter envoyée il y a huit mois, et les images produits qu’un vieux .htaccess ne sert plus.

Il y a en réalité deux opérations sous le même mot. Soit le nom reste identique et tu changes seulement de registrar, le prestataire qui gère le domaine : aucun impact SEO si c’est bien fait, un vrai risque sur le DNS et la messagerie. Soit la boutique change d’adresse (ancien-nom.fr devient nouveau-nom.fr) : c’est une migration de site au sens de Google, avec toutes les URL qui bougent.

Ce guide couvre les deux, dans l’ordre où je les mène sur des boutiques en production. J’ai croisé la documentation de Google Search Central, les procédures de l’Afnic et de l’ICANN, les docs de PrestaShop, WordPress, WooCommerce et Stripe, et les pièges que je vois revenir. Tu y trouveras le rétroplanning de J-60 à J+365, la matrice de redirections, le DNS sans coupure, les e-mails, le paiement, puis une partie PrestaShop et une partie WordPress / WooCommerce, et 40 points à cocher.

 

Sommaire

1. Transfert de registrar ou nouveau nom : deux chantiers différents
2. Avant de réserver le nom : as-tu vraiment besoin de changer ?
3. Ce que Google fait vraiment pendant une migration
4. Le rétroplanning, de J-60 à J+365
5. L’inventaire : URL, backlinks, zone DNS et services cachés
6. Changer de registrar sans perdre le domaine
7. DNS : basculer sans une minute de coupure
8. E-mails : le chantier que tout le monde oublie
9. HTTPS et ancien domaine : le certificat qu’on ne coupe pas
10. Redirections 301 : la matrice qui sauve ton trafic
11. Search Console, Bing, sitemap, backlinks
12. Paiement, Merchant Center, pubs et outils tiers
13. Changer le domaine d’une boutique PrestaShop
14. Changer le domaine d’un site WordPress ou WooCommerce
15. Le jour J, dans l’ordre
16. Après la bascule : ce qui est normal, ce qui ne l’est pas
17. Les 9 erreurs qui coûtent le plus cher
18. Checklist : 40 points
19. Comment je peux t’aider
20. Questions fréquentes

1. Transfert de registrar ou nouveau nom : deux chantiers différents

Le registrar (bureau d’enregistrement) est la société auprès de laquelle tu loues ton nom : OVHcloud, Gandi, o2switch, IONOS, Domaine.fr, etc. Le registre est l’organisme qui gère l’extension : l’Afnic pour le .fr, Verisign pour le .com. L’hébergeur DNS est celui qui répond quand un navigateur demande « où est ce site ? » ; c’est souvent le registrar, mais pas obligatoirement. Et l’hébergeur web est la machine qui sert la boutique. Quatre rôles, parfois un seul prestataire, parfois quatre.

	Transfert de registrar	Changement de nom de domaine
Exemple	boutique.fr passe de A chez B	ancien-nom.fr devient nouveau-nom.fr
URL du site	Inchangées	Toutes modifiées
Impact SEO	Aucun si le DNS répond pareil	Fluctuation de quelques semaines, perte durable si mal fait
Risque principal	Zone DNS perdue, e-mails coupés	Redirections, e-mails, paiement, Merchant Center
Outil Google	Aucun	Changement d’adresse (Search Console)
Durée technique	Quelques minutes à 8 jours (.fr), 5 jours (.com)	Une journée de bascule, un an de suivi

Il existe une troisième situation, voisine : changer d’hébergeur web sans toucher au nom. Google la classe à part (migration sans modification d’URL) et elle ne demande ni redirection ni outil Search Console, seulement un DNS mis à jour au bon moment et un serveur qui tient. Si c’est ton cas, les sections DNS et e-mails suffisent, avec le guide pour choisir un hébergement e-commerce.

2. Avant de réserver le nom : as-tu vraiment besoin de changer ?

Les bonnes raisons existent : changement de marque, fusion ou rachat, nom devenu trop étroit (bougies-bordeaux.fr qui vend dans toute l’Europe), litige de marque, domaine historique au nom d’un ancien associé. Les mauvaises aussi : « le .com fait plus pro », « un mot-clé dans le domaine va nous faire remonter », « on refait le site, autant tout changer ».

Un domaine avec mot-clé exact n’apporte presque plus rien depuis la mise à jour EMD de Google en 2012. Et « autant tout changer » est exactement ce que Google déconseille : sa documentation demande de mener une modification à la fois, domaine puis design, pas les deux ensemble. Si tu refais la boutique, lis d’abord les 10 points à vérifier avant une refonte PrestaShop et décale le domaine de quelques semaines.

Si tu changes quand même, vérifie le nouveau nom avant de l’acheter

• La marque. Une recherche d’antériorité sur la base de l’INPI et de l’EUIPO, dans tes classes de produits. Un domaine ne protège pas une marque, et une marque déposée par un tiers peut te coûter le domaine.
• Le passé du domaine, s’il a déjà servi : Wayback Machine (archive.org), backlinks douteux, et dès qu’il est vérifié dans la Search Console, le rapport Actions manuelles et l’outil de suppression d’URL. Google rappelle de nettoyer ce qu’a laissé le propriétaire précédent.
• L’éligibilité : le .fr est réservé aux personnes et entreprises établies dans l’Union européenne, en Islande, au Liechtenstein, en Norvège ou en Suisse.
• Les variantes : .fr et .com, la version sans tiret si tu en mets un, une faute de frappe évidente. Quelques euros par an contre un site de phishing qui imite ta marque.
• La lisibilité à l’oral : ton nom sera dicté au téléphone par le SAV et noté sur un bordereau. Pas de chiffres ambigus, pas de double lettre piège.

En cas de rachat, le domaine n’a parfois pas à changer du tout : il change de titulaire. Pour un .fr, c’est une opération de transmission à faire valider par les deux parties auprès du registrar, pas un changement d’adresse du site.

3. Ce que Google fait vraiment pendant une migration

Pas de légende : voici ce que disent la documentation Search Central (mise à jour en août 2026) et l’aide de l’outil Changement d’adresse.

• La migration se fait URL par URL. Google considère le déménagement terminé quand Googlebot a visité chaque ancienne et chaque nouvelle URL au moins une fois. Un catalogue de 20 000 fiches ne se déplace pas en une nuit.
• Les positions fluctuent, et c’est normal. Pour un site de taille moyenne, Google parle de quelques semaines ou plus avant que les nouvelles URL remplacent les anciennes.
• Les redirections 301 et 308 ne font pas perdre de PageRank. Google l’écrit noir sur blanc. Ce qui fait perdre, ce sont les redirections vers une page sans rapport.
• Tout rediriger vers l’accueil est une erreur documentée. Google précise qu’il peut traiter ce schéma comme une soft 404 : l’ancienne page ne transmet rien.
• Pas de chaînes. Googlebot suit jusqu’à 10 sauts, mais Google conseille d’aller directement à la destination finale.
• L’outil Changement d’adresse travaille 180 jours. Pendant cette période, Google privilégie le nouveau site pour l’exploration et les canoniques. Au-delà, si l’ancien site répond encore sans rediriger, il redevient un site à part entière.
• Redirections : au moins 180 jours selon l’aide, au moins un an selon le guide de migration. Et Google recommande de continuer à payer l’ancien domaine au moins un an pour qu’il ne serve pas à quelqu’un d’autre.
• Une migration à la fois. Pas de A vers B puis B vers C dans la foulée, et pas de A, B et C fusionnés vers D en même temps.
• Le serveur doit tenir. Juste après la bascule, Googlebot explore plus que d’habitude, puisqu’il suit les redirections en plus de son crawl normal.

Traduction marchand : une migration propre te coûte quelques semaines de positions instables, pas ton trafic. Une migration bâclée peut te coûter la moitié de l’organique pendant des mois, et une partie ne revient jamais quand des fiches produits ont disparu sans redirection.

4. Le rétroplanning, de J-60 à J+365

Le jour J est le plus court de tout le projet. Ce qui se joue vraiment, c’est l’inventaire à J-30 et la surveillance à J+30.

Jalon	Objectif	Livrable
J-60	Décider	Nom validé (marque, historique), ancien domaine renouvelé plusieurs années, plan écrit avec un responsable par tâche et un critère de retour arrière.
J-30	Inventorier	Liste des URL, des backlinks, export de la zone DNS, liste des services liés au domaine, matrice de redirections commencée.
J-7	Préparer	TTL baissé, certificats installés, préproduction testée sur le nouveau domaine, matrice 301 testée, e-mails testés, sauvegarde restaurée.
Jour J	Basculer	Domaine changé dans le CMS, 301 actives, changement d’adresse déclaré, sitemap soumis, paiement et pubs rebranchés, commande test passée.
J+30	Surveiller	404 corrigées, Merchant Center propre, backlinks forts relancés, trafic comparé.
J+365	Garder	Redirections toujours actives, ancien domaine renouvelé, boîtes mail de l’ancien domaine encore en réception.

Le plan écrit n’est pas une formalité. Il doit dire qui a les accès (registrar, DNS, hébergement, CMS, PSP, Search Console, Merchant Center, Google Ads, Meta), qui décide d’un retour arrière et à partir de quel signal : paiements qui échouent, e-mails qui ne partent plus, taux de 404 anormal. Sans ce document, le jour J se transforme en chasse aux mots de passe.

5. L’inventaire : URL, backlinks, zone DNS et services cachés

Toutes les URL qui comptent

Tu ne peux pas rediriger ce que tu n’as pas listé. Croise plusieurs sources, parce qu’aucune n’est complète :

• le sitemap actuel (PrestaShop via le module Google Sitemap, WordPress via Yoast, Rank Math ou le sitemap natif) ;
• un crawl complet avec Screaming Frog ou équivalent, y compris images et PDF ;
• la Search Console : rapport Performances sur 16 mois (onglet Pages) et rapport Pages indexées ;
• tes statistiques (GA4, Matomo) : pages d’entrée sur 12 mois, pour capter les pages saisonnières ;
• les logs serveur, qui montrent ce que Googlebot et les clients demandent vraiment, y compris des URL que tu croyais mortes ;
• les URL d’e-mails : liens de suivi, de facture, de désinscription, de parrainage envoyés ces derniers mois.

Garde cette liste dans un tableur : c’est la base de ta matrice de redirections et de tes tests après bascule. Si tu utilises la Search Console depuis peu, le guide complet Google Search Console pour PrestaShop montre où trouver ces exports.

Les backlinks

Exporte les liens externes depuis la Search Console (rapport Liens) et, si tu en as un, depuis un outil tiers. Repère les vingt à cinquante liens les plus forts : presse, partenaires, fournisseurs, annuaires professionnels. Tu les relanceras après la bascule pour qu’ils pointent directement sur le nouveau domaine. La 301 transmet, mais un lien direct évite un saut et survit à tout incident de redirection.

La zone DNS, en entier

Exporte la zone complète de l’ancien domaine, pas seulement les enregistrements A et MX. Les oublis classiques : les TXT de vérification (google-site-verification, MS= de Microsoft 365, facebook-domain-verification, Apple, Brevo, Mailjet), les enregistrements DKIM sous selecteur._domainkey, le _dmarc, les SRV d’un logiciel de téléphonie, les CAA qui disent quelle autorité peut émettre un certificat, et les sous-domaines oubliés (pro., b2b., factures., img.).

Les services accrochés au nom

Fais le tour de chaque outil qui connaît ton domaine, et note pour chacun où se trouve le réglage et qui a l’accès. En pratique, sur une boutique moyenne, la liste dépasse souvent trente lignes : PSP, transporteurs, ERP, outil d’avis, bandeau cookies, emailing, CDN, reCAPTCHA, marketplaces, comparateurs de prix, affiliation, chat, outil de facturation, application mobile, profils sociaux. La section 12 détaille les plus sensibles.

6. Changer de registrar sans perdre le domaine

Le transfert est une procédure standard. Ce qui casse, c’est ce qui l’entoure.

La séquence

1. Vérifie l’éligibilité : domaine actif, pas en fin de vie, coordonnées du titulaire à jour (l’adresse e-mail du titulaire doit fonctionner, c’est elle qui reçoit les confirmations).
2. Recrée la zone DNS chez l’hébergeur DNS de destination avant de lancer quoi que ce soit, à partir de l’export. C’est l’étape qui évite la plupart des coupures (voir plus bas).
3. Retire le verrou de transfert chez le registrar actuel.
4. Récupère le code de transfert : AuthInfo, code EPP, AuthCode, ou TAC selon la terminologie. L’Afnic rappelle qu’il est gratuit.
5. Lance le transfert chez le nouveau registrar avec ce code et paie (le transfert inclut en général un an de renouvellement).
6. Valide les e-mails de confirmation reçus par le titulaire.
7. Compare la zone servie après transfert avec ton export, enregistrement par enregistrement.
8. Remets le verrou, active la double authentification sur le nouveau compte, et le renouvellement automatique.

Délais et verrous

Extension	Qui décide	Délai	À savoir
.fr (et .re, .pm, .yt, .wf, .tf)	Afnic	Le registrar sortant a 8 jours pour accepter ou refuser. Sans réponse : transfert au bout de 8 jours. En cas de refus : 22 jours au total.	Souvent validé en quelques minutes. Le transfert prolonge la date d’expiration d’un an. Changement visible tout de suite dans le Whois.
.com, .net, .org et autres génériques	ICANN	Le registrar sortant a 5 jours ; sans réponse, le transfert est validé.	Verrou habituel de 60 jours après une création ou un changement de titulaire. La révision de la politique ICANN votée en 2025 le ramène à 30 jours (720 heures), ajoute 30 jours de verrou après chaque transfert et renomme le code en TAC ; son déploiement est progressif.
.eu, .be, .de et autres nationaux	Chaque registre	Variable	Regarde la règle du registre avant de fixer ta date.

Le piège n°1 : la zone DNS qui part avec l’ancien registrar

Si ton DNS est hébergé chez le registrar que tu quittes, la zone peut être supprimée au départ du domaine ou à la fin de l’abonnement associé. Le domaine arrive chez le nouveau registrar en pointant vers des serveurs DNS qui ne répondent plus pour lui : site et e-mails tombent en même temps, parfois un vendredi soir.

La parade est simple : avant le transfert, recrée la zone à l’identique chez le futur hébergeur DNS (le nouveau registrar ou un DNS neutre), vérifie-la avec dig en interrogeant directement ses serveurs, puis change les serveurs de noms (NS). Attends que tout réponde, et seulement ensuite lance le transfert. Le domaine change alors de registrar sans que rien ne bouge côté DNS.

Le piège n°2 : DNSSEC

Si DNSSEC est actif et que tu changes d’hébergeur DNS en même temps, les signatures ne correspondent plus et les résolveurs qui valident DNSSEC refusent de répondre : le site disparaît pour une partie des internautes seulement, ce qui rend le diagnostic pénible. Désactive DNSSEC (retrait de l’enregistrement DS chez le registrar), attends l’expiration du DS, migre, puis réactive-le chez le nouvel hébergeur.

Regrouper ses noms chez un registrar français

Une migration est une bonne occasion de ranger : tous les domaines de la marque au même endroit, avec une seule date de renouvellement à surveiller et un seul compte à protéger. Beaucoup de marchands choisissent un registrar français pour le support en français et la facturation en euros ; Domaine.fr, par exemple, enregistre et transfère les .fr et .com depuis 1996 (lien sponsorisé). Quel que soit le prestataire, exige la double authentification, le verrou de transfert et, pour un nom stratégique, le verrouillage au niveau du registre (Registry Lock) proposé par l’Afnic via les registrars partenaires.

7. DNS : basculer sans une minute de coupure

Le TTL (time to live) indique combien de temps un résolveur garde une réponse en cache. Avec un TTL de 86 400 secondes, certains visiteurs peuvent voir l’ancienne adresse pendant une journée après ton changement. La règle : baisse le TTL à 300 secondes au moins 48 heures avant la bascule (plus que l’ancien TTL), change les enregistrements le jour J, puis remonte le TTL à une ou quelques heures une fois stabilisé.

Enregistrement	Rôle	Si tu l’oublies
A / AAAA	Adresse IPv4 / IPv6 du serveur	Site injoignable. Un AAAA oublié qui pointe vers l’ancien serveur casse le site pour les connexions IPv6 seulement.
CNAME	Alias (www, sous-domaines, CDN)	www en erreur, images d’un CDN cassées.
MX	Serveurs qui reçoivent le courrier	E-mails perdus ou rejetés, commandes fournisseurs non reçues.
TXT SPF	Serveurs autorisés à envoyer pour le domaine	Confirmations de commande en spam ou rejetées.
TXT DKIM	Clé publique de signature des e-mails	Échec DMARC, délivrabilité en chute.
TXT DMARC	Politique en cas d’échec + rapports	Pas de visibilité sur qui envoie en ton nom.
CAA	Autorités autorisées à émettre un certificat	Let’s Encrypt refuse d’émettre le certificat du nouveau domaine.
TXT de vérification	Google, Microsoft, Meta, Apple, outils emailing	Services qui se déconnectent en silence quelques jours plus tard.
SRV	Téléphonie, messagerie d’équipe	Téléphones et logiciels qui ne se connectent plus.

Pour vérifier ce que le monde voit, interroge plusieurs résolveurs publics, pas seulement ta box :

# Ce que le monde voit, serveur par serveur
dig +short NS nouveau-nom.fr
dig +short A www.nouveau-nom.fr @8.8.8.8
dig +short MX nouveau-nom.fr @1.1.1.1
dig +short TXT nouveau-nom.fr
dig +short TXT selecteur._domainkey.nouveau-nom.fr   # sélecteur donné par ton relais mail
dig +short TXT _dmarc.nouveau-nom.fr

8. E-mails : le chantier que tout le monde oublie

Un changement de domaine, c’est aussi un changement d’adresse e-mail pour toute l’équipe et pour la boutique. Et un domaine neuf n’a aucune réputation auprès de Gmail, Outlook ou Orange.

• Crée les boîtes et alias sur le nouveau domaine (contact@, commandes@, sav@, compta@), dans le même outil (Google Workspace, Microsoft 365, hébergeur) en ajoutant le nouveau domaine comme domaine principal ou secondaire.
• Configure SPF, DKIM et DMARC dès J-7, y compris pour le relais transactionnel (Brevo, Mailjet, Amazon SES, SMTP de l’hébergeur) : chaque relais doit signer avec une clé DKIM du nouveau domaine. Depuis février 2024, Gmail et Yahoo exigent SPF, DKIM et DMARC pour les gros expéditeurs, et Gmail filtre de plus en plus sévèrement les autres.
• Commence DMARC en p=none avec une adresse de rapports, lis les rapports deux ou trois semaines, puis passe en quarantine et reject.
• Fais monter la réputation : les e-mails transactionnels (confirmation, expédition) partent en premier depuis le nouveau domaine, parce qu’ils sont attendus et ouverts. Une newsletter à 40 000 contacts le jour J depuis un domaine inconnu, c’est le meilleur moyen de finir en spam.
• Garde l’ancien domaine en réception au moins un an : alias ou redirection vers les nouvelles boîtes. Tes fournisseurs, ton transporteur et ta banque mettront des mois à mettre à jour leurs fiches.
• Change l’expéditeur dans le CMS : e-mail de la boutique, adresse d’expéditeur des e-mails transactionnels, adresse de réponse, signatures, modèles de facture.
• Préviens tes clients par un e-mail envoyé depuis l’ancien domaine, qui annonce le nouveau et demande de l’ajouter aux contacts.

Teste l’envoi réel depuis la boutique sur une adresse Gmail et une adresse Outlook, et lis les en-têtes : tu veux spf=pass, dkim=pass et dmarc=pass avec le nouveau domaine. Si les e-mails de PrestaShop ne partent plus du tout, le diagnostic est le même que dans pourquoi mes e-mails transactionnels ne s’envoient pas dans PrestaShop.

9. HTTPS et ancien domaine : le certificat qu’on ne coupe pas

C’est le défaut que je retrouve le plus souvent sur les migrations que je reprends : l’ancien domaine redirige bien en HTTP, mais https://ancien-nom.fr affiche une erreur de certificat. Le navigateur bloque avant d’avoir lu la redirection. Or c’est l’URL en HTTPS qui figure dans Google, dans les backlinks récents et dans tous les e-mails envoyés.

• Garde un certificat valide sur l’ancien domaine, avec et sans www, aussi longtemps que les redirections existent. Let’s Encrypt le fait gratuitement et le renouvelle seul.
• Si l’ancien domaine envoyait un en-tête HSTS, c’est encore plus impératif : les navigateurs qui l’ont mémorisé refusent toute connexion non sécurisée et n’offrent aucun contournement à l’internaute.
• Redirige en un saut : http://ancien-nom.fr doit aller directement vers https://www.nouveau-nom.fr/..., pas vers https://ancien-nom.fr puis vers le nouveau domaine.
• Vérifie les CAA du nouveau domaine avant de demander le certificat.
• Chasse le contenu mixte après la bascule : images, polices ou scripts encore appelés en http://ancien-nom.fr dans le thème ou les contenus.

La mise en place du HTTPS côté PrestaShop est détaillée dans le tuto complet HTTPS / SSL avec PrestaShop.

10. Redirections 301 : la matrice qui sauve ton trafic

Deux cas de figure. Si tes chemins restent identiques (/robe-lin-bleue reste /robe-lin-bleue), une seule règle au niveau du serveur suffit : même chemin, même query string, nouveau domaine. Si certains chemins changent (catégories renommées, pages fusionnées), il faut une matrice : une ligne par ancienne URL, avec sa destination exacte.

Apache (.htaccess) : la règle qui garde le chemin

# Tout en haut du .htaccess, AVANT la ligne « # ~~start~~ » de PrestaShop
RewriteEngine On

# 1. Les URL qui changent aussi de chemin, une règle par ligne de ta matrice
RewriteCond %{HTTP_HOST} ^(www\.)?ancien-nom\.fr$ [NC]
RewriteRule ^promo-ete/?$ https://www.nouveau-nom.fr/soldes [R=301,L]

# 2. Tout le reste : même chemin, même query string, nouveau domaine
RewriteCond %{HTTP_HOST} ^(www\.)?ancien-nom\.fr$ [NC]
RewriteRule ^(.*)$ https://www.nouveau-nom.fr/$1 [R=301,L]

Les règles spécifiques passent avant la règle générale, sinon elles ne sont jamais lues. Pour des centaines de redirections qui suivent un motif, les expressions régulières évitent un fichier de 3 000 lignes : j’ai détaillé la méthode dans créer des redirections 301 avec expressions régulières dans PrestaShop.

Nginx : un bloc serveur dédié à l’ancien domaine

server {
    listen 80;
    listen 443 ssl;
    http2 on;
    server_name ancien-nom.fr www.ancien-nom.fr;

    # Certificat valide pour l'ANCIEN domaine, sinon l'erreur SSL passe avant la redirection
    ssl_certificate     /etc/letsencrypt/live/ancien-nom.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ancien-nom.fr/privkey.pem;

    return 301 https://www.nouveau-nom.fr$request_uri;
}

Les règles à respecter

• 301 ou 308, jamais 302 : la 302 dit « temporaire » et Google garde l’ancienne URL.
• Une page vers son équivalent. Un produit supprimé va vers le produit de remplacement ou sa catégorie, pas vers l’accueil. Une page qui n’a vraiment plus d’équivalent peut répondre 410.
• Un seul saut, y compris depuis http:// et depuis la variante www.
• Les paramètres conservés : UTM, identifiants de parrainage, liens de désinscription.
• Images et PDF aussi : ils ont du trafic Google Images et des liens.
• Les appels d’API ne se fient pas à une redirection. Beaucoup de clients HTTP transforment un POST redirigé en 301 en GET, ou ne suivent pas du tout. Webhooks de paiement, connecteurs ERP, transporteurs et applications mobiles doivent être reconfigurés directement sur le nouveau domaine.

Tester avant et après

# Une URL : on veut un seul saut, en 301, vers la bonne page
curl -sI https://www.ancien-nom.fr/robe-lin-bleue | grep -iE "^(HTTP|location)"

# Toute la matrice (une ancienne URL par ligne dans anciennes-urls.txt)
while read -r u; do
  printf "%s  " "$u"
  curl -s -o /dev/null -w "%{http_code}  %{redirect_url}\n" "$u"
done < anciennes-urls.txt

Le résultat attendu pour chaque ligne : 301 et l’URL de destination exacte. Un 200 sur l’ancien domaine signale du contenu dupliqué, un 302 une mauvaise config, une destination en / une redirection vers l’accueil. Screaming Frog, en mode liste, fait le même contrôle avec un export propre.

11. Search Console, Bing, sitemap, backlinks

1. Vérifie les deux domaines dans la Search Console, idéalement en propriété de type Domaine (validation DNS), avec le même compte Google. Pense à toutes les variantes : avec et sans www, et les sous-domaines.
2. Reporte les réglages de l’ancienne propriété : fichier de désaveu s’il en existait un, utilisateurs, liaisons Analytics et Merchant Center.
3. Le jour J, une fois les 301 actives, ouvre l’outil Changement d’adresse sur l’ancienne propriété et désigne la nouvelle. L’outil vérifie quelques redirections avant d’accepter. Répète pour chaque variante de l’ancien domaine, même celles que tu n’utilises pas.
4. Soumets le sitemap du nouveau domaine, et garde un temps l’ancien sitemap soumis sur l’ancienne propriété : Google recommande de suivre la bascule des deux côtés (les avertissements de redirection sur l’ancien sont normaux).
5. Bing Webmaster Tools a son propre outil de déplacement de site. Il alimente aussi DuckDuckGo, Ecosia et une partie des moteurs de réponse. Un ping IndexNow accélère la découverte des nouvelles URL.
6. Canonical, hreflang, données structurées, Open Graph : tout doit afficher le nouveau domaine. Les balises canoniques auto-référentes sur les nouvelles URL, jamais vers l’ancien domaine.
7. Relance les backlinks forts repérés à J-30, en commençant par ceux qui apportent des visites, puis mets à jour tes propres profils : Google Business Profile, réseaux sociaux, annuaires, marketplaces, signatures e-mail, factures.

Pour la suite, le suivi se fait dans les rapports Pages, Sitemaps et Performances des deux propriétés : les URL indexées doivent baisser côté ancien domaine pendant qu’elles montent côté nouveau. Mon guide de migration PrestaShop 1.7 vers 9 sans perdre le SEO utilise la même méthode de suivi.

12. Paiement, Merchant Center, pubs et outils tiers

C’est ici que les migrations « réussies côté SEO » perdent de l’argent, parce que rien ne s’affiche en rouge : la boutique tourne, simplement certains paiements n’aboutissent plus.

Service	Ce qui casse	Ce qu’il faut faire
Stripe	Webhook qui pointe vers l’ancien domaine ; Apple Pay et Google Pay qui disparaissent du checkout	Modifier l’URL du webhook ; enregistrer le nouveau domaine (et le www) dans la page des domaines de moyens de paiement du dashboard.
PayPal, Mollie, PayPlug, banques (Systempay, Monetico…)	URL de retour et de notification (IPN) refusées ou redirigées	Mettre à jour les URL dans le back-office du PSP ; certains contrôlent le domaine déclaré au contrat.
Google Merchant Center	Produits refusés : le domaine des liens ne correspond plus au site revendiqué	Paramètres, Informations sur l’entreprise, modifier la boutique en ligne, puis valider et revendiquer le nouveau domaine ; flux régénéré avec les nouvelles URL.
Google Ads	Annonces refusées pour URL de destination incohérente	URL finales réécrites vers le nouveau domaine, pas laissées derrière une redirection.
GA4, Tag Manager, Matomo	Flux de données mal libellé, filtres d’hôte qui excluent le nouveau domaine	URL du flux, filtres et objectifs mis à jour ; annotation de la date de bascule.
Meta, Pinterest, TikTok	Domaine non vérifié, événements du pixel non attribués	Vérification du nouveau domaine (TXT DNS ou balise), catalogues produits mis à jour.
reCAPTCHA	« Domaine non valide pour la clé de site », formulaires bloqués	Ajouter le nouveau domaine à la clé (voir le tuto reCAPTCHA PrestaShop).
Bandeau cookies (CMP)	Bandeau absent ou consentement non enregistré	Déclarer le nouveau domaine dans la configuration de l’outil.
Avis clients	Profil rattaché à l’ancien domaine, widget vide	Utiliser la procédure de changement de domaine de l’outil au lieu de recréer un profil vide.
ERP, transporteurs, marketplaces, comparateurs	Appels d’API en échec, flux produits en erreur	URL de callback, clés et flux reconfigurés directement sur le nouveau domaine.

Côté légal, le nouveau domaine doit apparaître dans les mentions légales, les CGV, la politique de confidentialité et les modèles de facture. Le nom de domaine fait partie des informations d’identification du site, et un client qui compare sa facture avec l’adresse du site doit retrouver ses petits.

13. Changer le domaine d’une boutique PrestaShop

Valable pour PrestaShop 1.7, 8 et 9. Les chemins de menu changent un peu d’une version à l’autre, pas la logique.

Le réglage dans le back-office

Sans multiboutique : Paramètres de la boutique > Trafic et SEO, bloc de configuration de l’URL de la boutique, champs Domaine de la boutique et Domaine SSL. Avec la multiboutique active, ce bloc disparaît : le domaine se règle boutique par boutique dans Paramètres avancés > Multiboutique, sur l’URL de chaque boutique.

Dès l’enregistrement, le back-office te renvoie sur le nouveau domaine. Si le DNS ne pointe pas encore, tu perds l’accès. Fais ce réglage le jour J, une fois le nouveau domaine résolu vers le serveur et le certificat installé, et garde sous la main la requête SQL de secours plus bas.

Le piège que peu de guides mentionnent : PrestaShop redirige tout vers l’accueil

Si tu te contentes de faire pointer l’ancien domaine sur le même hébergement, PrestaShop reconnaît qu’il ne correspond à aucune boutique et redirige lui-même le visiteur. J’ai relu le code (classes/shop/Shop.php, identique en 8.2 et sur la branche de développement 9) : il renvoie vers l’URL de base de la boutique par défaut, c’est-à-dire la page d’accueil, et ne conserve le chemin que pour la bascule entre version avec et sans www. Toutes tes fiches produits, catégories et articles se retrouvent redirigés vers l’accueil : exactement le schéma que Google traite comme une soft 404.

Deuxième détail dans le même fichier : le code HTTP dépend du réglage Redirection vers l’URL canonique (Trafic et SEO). En « 302 Moved Temporarily », PrestaShop envoie des 302. Vérifie qu’il est en 301.

La solution : la règle Apache de la section 10, qui conserve le chemin, placée tout en haut du .htaccess, au-dessus de la ligne # ~~start~~. PrestaShop réécrit tout ce qui se trouve entre ses balises ~~start~~ et ~~end~~ à chaque régénération, et conserve ce qui est en dehors. Tes règles survivent ainsi aux mises à jour.

Régénère le .htaccess, sinon les images tombent

Autre subtilité vérifiée dans classes/Tools.php : les règles de réécriture des images produits et catégories du .htaccess généré contiennent une condition sur le nom d’hôte (RewriteCond %{HTTP_HOST} ^www.ancien-nom.fr$), même avec une seule boutique. Tant que le fichier n’est pas régénéré, les URL d’images « propres » ne correspondent plus sur le nouveau domaine et répondent en 404. Après le changement de domaine, retourne dans Trafic et SEO et enregistre à nouveau avec les URL simplifiées actives : PrestaShop réécrit le bloc avec le nouveau domaine.

Les URL en dur et les réglages cachés

Le domaine se glisse partout : contenus CMS, descriptions produits et catégories, blocs de texte du thème, configuration de modules, liens du menu. Un balayage SQL en lecture seule avant la bascule te donne la liste :

-- Repérer les URL en dur (préfixe ps_ à adapter)
SELECT name, value FROM ps_configuration WHERE value LIKE '%ancien-nom.fr%';
SELECT id_cms, id_lang FROM ps_cms_lang WHERE content LIKE '%ancien-nom.fr%';
SELECT id_product, id_lang FROM ps_product_lang WHERE description LIKE '%ancien-nom.fr%';
SELECT id_category, id_lang FROM ps_category_lang WHERE description LIKE '%ancien-nom.fr%';

-- Secours si le back-office n'est plus joignable après la bascule
UPDATE ps_shop_url
   SET domain = 'www.nouveau-nom.fr', domain_ssl = 'www.nouveau-nom.fr'
 WHERE id_shop = 1;
UPDATE ps_configuration
   SET value = 'www.nouveau-nom.fr'
 WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');

Corrige les contenus depuis le back-office autant que possible, et ne lance les deux UPDATE qu’en secours, après sauvegarde de la base.

La liste PrestaShop du jour J

• Cache : vide-le depuis Paramètres avancés > Performances, ou directement :

# PrestaShop 1.7, 8 et 9 : vider le cache Symfony et Smarty
rm -rf var/cache/prod/* var/cache/dev/*

• E-mails : Paramètres de la boutique > Contact (e-mail de la boutique), Paramètres avancés > E-mail (expéditeur, SMTP). Le relais SMTP doit signer avec le nouveau domaine.
• PrestaShop Account : le module détecte que l’URL ne correspond plus et affiche un bandeau. Choisis Confirmer le changement d’URL, jamais Créer une nouvelle identité : cette seconde option est irréversible, crée une nouvelle boutique côté services PrestaShop et laisse tes abonnements (PrestaShop Checkout, Marketing with Google, etc.) rattachés à l’ancienne identité.
• Modules sous licence par domaine : plusieurs éditeurs vérifient le domaine au démarrage du module, c’est le cas de mes propres modules sous licence. Mets à jour la licence avant de basculer, sinon la fonction s’arrête le jour J.
• Sitemap et robots.txt : régénère le sitemap (module Google Sitemap ou équivalent) et le robots.txt (bouton dans Trafic et SEO), puis vérifie qu’ils affichent le nouveau domaine.
• Serveurs de médias et CDN : Paramètres avancés > Performances, champs des serveurs de médias ; et configuration du CDN.
• Modules de paiement et transporteurs : URL de notification, webhooks, domaines déclarés chez le PSP.
• Clients connectés : les cookies sont liés au domaine, tout le monde est déconnecté et les paniers invités sont perdus. Les comptes et commandes restent intacts.
• Tâches cron : les URL de cron (exports, flux, relances) appelées par l’hébergeur ou un service externe pointent souvent sur l’ancien domaine. Une redirection ne suffit pas toujours pour un appel de tâche.

Si le changement de domaine accompagne un changement de version, sépare les deux : migre d’abord (voir le guide de migration PrestaShop 1.7 vers 9), change le domaine une fois la nouvelle version stabilisée. Même logique si tu arrives de Shopify : le comparatif PrestaShop ou Shopify en 2026 traite la migration d’URL entre les deux plateformes. Pour les redirections ponctuelles gérées depuis le back-office, voir aussi la redirection d’URL sous PrestaShop.

14. Changer le domaine d’un site WordPress ou WooCommerce

Le piège inverse : WordPress ne redirige rien

Là où PrestaShop redirige tout vers l’accueil, WordPress ne redirige pas du tout un domaine étranger. Dans wp-includes/canonical.php, la redirection canonique ne corrige l’hôte qu’entre la version avec et sans www. Un ancien domaine qui pointe sur la même installation affiche donc le site entier sur l’ancienne adresse, avec des liens internes vers la nouvelle. Pour Google, c’est un site dupliqué. La règle serveur de la section 10 est obligatoire, au-dessus du bloc # BEGIN WordPress.

Changer l’adresse proprement

Les options home et siteurl se modifient dans Réglages > Général, mais la base contient l’ancien domaine à des milliers d’endroits : contenus, menus, widgets, réglages de thème et d’extensions, souvent en données sérialisées. Un REPLACE SQL brut casse ces données, parce que la longueur de chaque chaîne est stockée à côté. La documentation officielle de WordPress recommande WP-CLI :

# 1. Toujours à blanc d'abord : lis le rapport table par table
wp search-replace 'https://www.ancien-nom.fr' 'https://www.nouveau-nom.fr' \
  --all-tables --precise --skip-columns=guid,user_email \
  --report-changed-only --dry-run

# 2. Même commande sans --dry-run, puis :
wp option get home && wp option get siteurl
wp rewrite flush
wp cache flush

• Ne touche jamais à la colonne guid : la documentation WordPress est formelle, les GUID ne changent jamais, même en changeant de domaine. Les lecteurs de flux s’en servent pour savoir ce qu’ils ont déjà lu.
• user_email exclu pour ne pas réécrire les adresses de tes clients si certaines utilisent l’ancien domaine (tes propres comptes, par exemple).
• Les URL échappées : Gutenberg et certains builders stockent du JSON avec des barres obliques échappées (https:\/\/www.ancien-nom.fr). Fais un second passage à blanc sur le seul nom d’hôte et lis le rapport avant de valider. Elementor fournit aussi son outil « Remplacer l’URL » dans ses réglages, suivi d’une régénération des CSS.
• Accès perdu à l’admin : forçage temporaire dans wp-config.php.

// wp-config.php : reprendre la main si l'admin boucle ou pointe encore sur l'ancien domaine
define( 'WP_HOME', 'https://www.nouveau-nom.fr' );
define( 'WP_SITEURL', 'https://www.nouveau-nom.fr' );

La liste WordPress et WooCommerce du jour J

• Permaliens et caches : wp rewrite flush, purge du cache de page (LiteSpeed Cache, WP Rocket, W3 Total Cache), du cache objet (Redis) et du CDN.
• SEO : si le sitemap ou les canoniques de Yoast affichent encore l’ancien domaine, relance l’optimisation des données SEO (Yoast > Outils). Même contrôle avec Rank Math.
• WooCommerce Subscriptions : l’extension mémorise l’URL du site où elle a été activée. Si l’URL change, elle passe en mode staging, coupe les prélèvements automatiques et les e-mails d’abonnement. Après la bascule, accepte le déplacement dans le bandeau d’admin, ou mets à jour l’option wc_subscriptions_siteurl, et vérifie dans WooCommerce > État que le mode est redevenu Live. Ne clique pas sur « Quit nagging me » par réflexe.
• Jetpack détecte le changement d’URL et passe en mode sécurisé : choisis de déplacer la connexion vers le nouveau domaine plutôt que d’en créer une nouvelle.
• Paiement : webhooks Stripe et PayPal, domaine Apple Pay, et clés API REST utilisées par des services externes (ERP, logistique) à reconfigurer sur le nouveau domaine.
• E-mails : WooCommerce > Réglages > E-mails (nom et adresse d’expéditeur), extension SMTP (WP Mail SMTP, FluentSMTP…) avec le relais authentifié sur le nouveau domaine.
• Multisite : le domaine vit aussi dans les tables wp_blogs et wp_site et dans la constante DOMAIN_CURRENT_SITE de wp-config.php. La commande WP-CLI prend alors --network.
• Cookies : si COOKIE_DOMAIN est défini dans wp-config.php, mets-le à jour, sinon plus personne ne peut se connecter.

Pour un site vitrine WordPress sans boutique, la liste raccourcit (pas de paiement ni de Merchant Center), mais les redirections, la Search Console et les e-mails restent identiques. Côté prestations, voir freelance WordPress et freelance WooCommerce.

15. Le jour J, dans l’ordre

Un mardi ou un mercredi matin, pas un vendredi. L’équipe prévenue, le code gelé depuis J-7, les accès testés la veille.

1. Dernière sauvegarde fichiers et base.
2. Pointer le nouveau domaine vers le serveur (TTL déjà à 300 secondes), vérifier la résolution avec dig.
3. Vérifier les certificats : nouveau domaine et ancien domaine, avec et sans www.
4. Changer le domaine dans PrestaShop ou WordPress, régénérer .htaccess, vider les caches.
5. Activer les règles 301 sur l’ancien domaine, puis dérouler le test curl sur la matrice complète.
6. Retirer tout noindex de préproduction, vérifier le robots.txt et quelques canoniques.
7. Déclarer le changement d’adresse dans la Search Console pour chaque variante, soumettre le sitemap, lancer le déplacement de site dans Bing.
8. Reconfigurer PSP, Merchant Center, Google Ads, pixels, reCAPTCHA, CMP, connecteurs.
9. Passer une vraie commande avec une vraie carte : paiement, e-mail de confirmation, facture, e-mail d’expédition, lien de suivi.
10. Envoyer l’e-mail d’annonce aux clients, publier le message sur les réseaux, mettre à jour Google Business Profile.

Garde une personne sur les logs et le tableau de bord du PSP jusqu’au soir. Les 404 de la première journée te montrent exactement les lignes oubliées dans la matrice.

16. Après la bascule : ce qui est normal, ce qui ne l’est pas

Moment	Normal	Anormal, à creuser tout de suite
J+1 à J+7	Crawl plus intense, premières URL nouvelles indexées, positions qui bougent	Paiements échoués, e-mails non reçus, 404 en série, ancien domaine qui répond en 200
J+7 à J+30	Trafic organique un peu en dessous de la normale, bascule progressive des URL dans la Search Console	Nouvelles URL non indexées au bout de trois semaines, « Page avec redirection » côté nouveau domaine, produits refusés dans Merchant Center
J+30 à J+90	Retour vers le niveau d’avant, requêtes de marque sur le nouveau nom qui montent	Organique encore bas de moitié, pages clés absentes de l’index, backlinks importants en 404
J+180	Fin de la notification de migration dans la Search Console	Envie de « nettoyer » en retirant les 301 : non
J+365 et après	Ancien domaine renouvelé, redirections actives, boîtes de l’ancien domaine encore en réception	Domaine laissé expirer, racheté par un tiers

17. Les 9 erreurs qui coûtent le plus cher

1. Tout rediriger vers l’accueil, souvent sans le savoir sur PrestaShop. Le trafic des fiches produits ne revient pas.
2. Laisser l’ancien domaine servir le site sans rediriger, cas typique sur WordPress. Deux sites identiques en concurrence.
3. Oublier le certificat de l’ancien domaine. Les liens en HTTPS finissent sur une erreur de sécurité.
4. Perdre la zone DNS au transfert, avec le site et les e-mails dedans.
5. Combiner changement de domaine, refonte et changement de CMS. Impossible de savoir ce qui a cassé, et Google doit tout réévaluer.
6. Utiliser des 302, par défaut ou par un réglage PrestaShop oublié.
7. Laisser le paiement sur l’ancien domaine : webhooks en échec, Apple Pay disparu, commandes payées mais absentes du back-office.
8. Envoyer la newsletter depuis le domaine neuf le premier jour, sans SPF, DKIM ni DMARC propres.
9. Laisser expirer l’ancien domaine au bout d’un an. Redirections mortes, et un nom que n’importe qui peut racheter pour imiter ta boutique.

18. Checklist : 40 points

Coche dans l’ordre. Si tu es déjà au jour J en lisant ceci, commence par les points 18, 20, 25 et 30 : certificat, test des 301, redirections sur toutes les variantes, paiement.

J-60 à J-30 : 16 points

1. Recherche d’antériorité de marque (INPI, EUIPO) sur le nouveau nom, et disponibilité des comptes sociaux.
2. Audit du nouveau domaine s’il a un passé : Wayback Machine, backlinks, actions manuelles une fois vérifié.
3. Achat du nouveau domaine et de ses variantes utiles (.fr, .com, faute de frappe évidente), compte registrar en double authentification.
4. Renouvellement de l’ancien domaine pour plusieurs années, renouvellement automatique activé.
5. Plan écrit : responsable par tâche, date, accès, critère et procédure de retour arrière.
6. Date de bascule dans un creux de trafic, loin des soldes, du Black Friday et des campagnes.
7. Export de toutes les URL : sitemap, crawl, Search Console 16 mois, statistiques 12 mois, logs, liens d’e-mails.
8. Export des backlinks et repérage des vingt à cinquante plus forts.
9. Export complet de la zone DNS de l’ancien domaine, TXT de vérification, DKIM, CAA et SRV compris.
10. Liste de tous les services liés au domaine, avec l’emplacement du réglage et la personne qui a l’accès.
11. Vérification des deux domaines dans la Search Console (même compte) et dans Bing Webmaster Tools.
12. Matrice de redirections : une ligne par URL indexée, liée ou visitée, avec sa destination exacte.
13. Messagerie du nouveau domaine prête : boîtes, alias, SPF, DKIM, DMARC en p=none.
14. Mentions légales, CGV, politique de confidentialité et modèles de facture préparés avec le nouveau domaine.
15. E-mail d’annonce aux clients et messages réseaux rédigés.
16. Si changement de registrar : zone recréée chez la destination, NS basculés, transfert lancé et terminé avant la bascule du nom.

J-7 : 7 points

17. TTL des enregistrements concernés baissé à 300 secondes, au moins 48 heures avant.
18. Certificats valides sur le nouveau domaine et sur l’ancien, avec et sans www.
19. Préproduction sur le nouveau domaine en noindex, parcours d’achat complet testé.
20. Matrice 301 testée en liste : un seul saut, code 301, bonne destination, zéro 404.
21. E-mails du nouveau domaine testés en envoi et réception, en-têtes spf=pass, dkim=pass, dmarc=pass.
22. Sauvegarde complète fichiers et base, restauration testée.
23. Gel des modifications : pas de nouveau module ni d’extension, pas de refonte en cours.

Jour J : 8 points

24. Domaine changé dans PrestaShop ou WordPress, .htaccess régénéré, caches vidés.
25. Redirections 301 actives sur toutes les variantes de l’ancien domaine (HTTP, HTTPS, www, sans www).
26. noindex retiré, robots.txt vérifié sur le nouveau domaine.
27. Canoniques, hreflang, liens internes, données structurées et sitemap en nouveau domaine.
28. Changement d’adresse déclaré dans la Search Console pour chaque variante, déplacement de site dans Bing.
29. Nouveau sitemap soumis, ping IndexNow.
30. PSP (webhooks, URL de retour, domaine Apple Pay et Google Pay), Merchant Center, Google Ads, pixels, reCAPTCHA, CMP et connecteurs reconfigurés.
31. Commande réelle passée jusqu’à l’e-mail d’expédition.

J+1 à J+365 : 9 points

32. 404, soft 404 et erreurs surveillées chaque jour la première semaine (logs, Search Console), matrice complétée au fil de l’eau.
33. Merchant Center : nouveau domaine revendiqué, produits refusés corrigés.
34. Backlinks forts relancés pour pointer directement sur le nouveau domaine.
35. Profils mis à jour : Google Business Profile, réseaux, annuaires, marketplaces, signatures.
36. Boîtes de l’ancien domaine gardées en réception au moins un an.
37. Trafic et chiffre d’affaires organique comparés à J+30 et J+90, page par page.
38. DMARC du nouveau domaine passé en quarantine puis reject quand les rapports sont propres.
39. Redirections 301 gardées au moins un an, idéalement pour toujours.
40. Ancien domaine renouvelé chaque année, jamais laissé expirer.

19. Comment je peux t’aider

Je suis Arnaud Mérigeau, freelance PrestaShop et WordPress certifié PrestaShop Experts, basé à Bordeaux, missions partout en France. Une bonne partie de mon travail consiste à reprendre des boutiques que je n’ai pas construites, y compris après des migrations qui ont mal tourné : c’est souvent là qu’on découvre le .htaccess jamais régénéré ou la zone DNS partie avec l’ancien registrar.

Sur un changement de domaine, je prends en charge la matrice de redirections, la bascule dans PrestaShop ou WordPress / WooCommerce, les règles serveur, la Search Console, le rebranchement du paiement et des e-mails transactionnels, et le suivi des 404 le premier mois. Je ne remplace pas ton registrar ni ton juriste sur la marque ; je te dis ce qu’il faut leur demander.

Trois portes d’entrée : un ticket d’intervention si tu as un point précis (redirections, e-mails, webhook), un contrat de maintenance si tu veux que la surveillance après bascule soit couverte, ou le formulaire de contact avec l’URL actuelle, le nouveau domaine, la version de PrestaShop ou WordPress et la date visée. Tu peux aussi regarder quel profil appeler selon ton besoin, mes réalisations et la page freelance PrestaShop.

20. Questions fréquentes

Est-ce qu’un changement de nom de domaine fait perdre du référencement ?

Pas durablement si la migration est propre. Google écrit que les redirections 301 ne font pas perdre de PageRank et que les positions fluctuent le temps que chaque URL soit recrawlée. Les pertes qui durent viennent presque toujours d’une erreur : redirections vers la page d’accueil, pages oubliées, noindex resté en place, ou refonte menée en même temps.

Combien de temps pour retrouver son trafic après un changement de domaine ?

Google parle de quelques semaines ou plus pour un site de taille moyenne, davantage pour un gros catalogue. Sur une boutique de quelques milliers d’URL, compte un à trois mois avant d’avoir une lecture fiable. Si le trafic organique est encore bas de moitié à J+60, cherche une erreur technique au lieu d’attendre.

Faut-il garder l’ancien nom de domaine ?

Oui, et le renouveler chaque année. Sans lui, plus de redirections, des liens morts dans tous les anciens e-mails et backlinks, et un domaine que n’importe qui peut racheter pour imiter ta boutique auprès de tes anciens clients. Google recommande de le payer au moins un an ; je conseille de ne jamais le lâcher.

Combien de temps garder les redirections 301 ?

Google demande au moins 180 jours dans l’aide de l’outil Changement d’adresse et au moins un an dans son guide de migration. Prends la durée la plus longue, et dans les faits garde-les indéfiniment : une règle de redirection ne coûte rien, un lien cassé depuis un vieux backlink ou un ancien e-mail coûte une vente.

Redirection 301 ou 302 pour un changement de domaine ?

301 (ou 308). La 302 signale un déplacement temporaire : Google garde alors l’ancienne URL comme référence. Attention sur PrestaShop, le réglage « Redirection vers l’URL canonique » peut être en 302 : vérifie-le dans Trafic et SEO avant la bascule.

Un transfert de domaine coupe-t-il le site ou les e-mails ?

Non si la zone DNS reste servie pendant et après le transfert. La coupure arrive quand la zone était hébergée chez le registrar que tu quittes et qu’elle disparaît avec lui, ou quand un enregistrement MX, SPF ou DKIM n’a pas été recopié à l’identique.

Combien de temps dure le transfert d’un .fr ou d’un .com ?

Pour un .fr, l’Afnic laisse 8 jours au registrar sortant pour répondre ; sans réponse, le transfert se fait au bout de ces 8 jours, et en cas de refus le délai total monte à 22 jours. Souvent, le registrar sortant valide dans l’heure. Pour un .com, le registrar sortant a 5 jours, après quoi le transfert est validé automatiquement.

Qu’est-ce que le code AuthInfo et où le trouver ?

C’est le mot de passe du nom de domaine, aussi appelé code de transfert, code EPP ou AuthCode, et TAC dans la nouvelle politique ICANN. Il se trouve dans l’espace client du registrar actuel ; l’Afnic rappelle que son obtention est gratuite. Il ne se transmet qu’au nouveau registrar, jamais par e-mail à un tiers.

Peut-on changer de nom de domaine et de CMS en même temps ?

Techniquement oui, mais Google conseille explicitement de faire une chose à la fois. Si tu changes de domaine, de structure d’URL et de design le même jour, Google doit tout réinterpréter et tu ne sauras pas quelle modification a fait baisser le trafic. Migre d’abord, change le domaine ensuite, ou l’inverse, avec quelques semaines entre les deux.

Faut-il utiliser l’outil Changement d’adresse de la Search Console ?

Oui pour un changement de domaine, une fois les 301 en place. Il faut être propriétaire des deux propriétés avec le même compte Google, et le lancer pour chaque variante de l’ancien domaine (avec et sans www). Il ne sert à rien pour un simple passage en HTTPS ou un changement d’hébergeur.

Mes clients devront-ils se reconnecter après le changement de domaine ?

Oui. Les cookies de session sont liés au domaine : les clients connectés sont déconnectés et les paniers des visiteurs non connectés sont perdus. Les comptes, mots de passe et commandes restent en base. Préviens tes clients par e-mail et évite de basculer en pleine opération commerciale.

Que deviennent les liens de désinscription et de suivi dans les anciens e-mails ?

Ils pointent vers l’ancien domaine et ne marcheront que si les 301 conservent le chemin et les paramètres. Le lien de désinscription d’une newsletter est une obligation légale : teste-en un envoyé avant la bascule, après avoir activé les redirections.

.fr ou .com pour une boutique française ?

Le .fr si ta clientèle est en France : il inspire confiance et reste lisible. Le .com si tu vises plusieurs pays avec une seule boutique. Achète les deux quand c’est possible et redirige l’un vers l’autre. Le .fr est réservé aux personnes et entreprises établies dans l’Union européenne, en Islande, au Liechtenstein, en Norvège ou en Suisse.

Un domaine avec mot-clé aide-t-il le référencement ?

Très peu. Google a réduit le poids des domaines à mot-clé exact il y a plus de dix ans. Un nom de marque court, facile à dicter au téléphone, rapporte plus sur la durée qu’un « chaussures-pas-cheres-bordeaux.fr ».

Combien coûte un changement de nom de domaine ?

Le nom lui-même coûte entre 10 et 20 € par an en .fr ou .com. Le vrai coût, c’est le temps technique : pour une boutique PrestaShop ou WooCommerce propre, compte en général une à trois journées entre la matrice de redirections, la bascule et le suivi. Multiboutique, plusieurs langues ou des URL sans logique font monter la note.

Pour finir

Un changement de nom de domaine réussi ne se voit pas : les clients arrivent sur la nouvelle adresse, les commandes passent, les e-mails arrivent, et les courbes de la Search Console se croisent tranquillement en quelques semaines. Ce résultat tient à trois choses : une redirection 301 par URL qui conserve le chemin, un inventaire complet de ce qui est accroché au nom, et un ancien domaine qu’on garde vivant.

Sur PrestaShop, méfie-toi de la redirection automatique vers l’accueil et régénère le .htaccess. Sur WordPress, n’oublie pas que rien ne redirige tant que tu ne l’as pas écrit, et passe par WP-CLI plutôt que par une requête SQL.

Envoie-moi l’ancienne et la nouvelle adresse avec ta date cible : je te dis ce qui cassera si on bascule demain, et ce qu’il faut préparer d’ici là.

Transparence : cet article contient un lien sponsorisé vers le registrar français Domaine.fr, signalé comme tel. La méthode et les recommandations sont les miennes.