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.
La réponse courte. Un changement de nom de domaine ne fait pas perdre de référencement durablement si chaque ancienne URL redirige en 301 vers son équivalent exact (pas vers l’accueil), si tu déclares le changement d’adresse dans la Search Console, et si tu gardes l’ancien domaine et ses redirections au moins un an ; en pratique, pour toujours. Attends-toi à quelques semaines de fluctuation. Le jour J, rebranche aussi e-mails (MX, SPF, DKIM, DMARC), webhooks de paiement, Merchant Center et pubs. Sur PrestaShop, un ancien domaine simplement pointé sur la boutique renvoie tout vers la page d’accueil : il faut une règle qui conserve le chemin. Sur WordPress, il ne redirige rien du tout et sert le site en double.
