Un site WordPress qui tourne bien depuis deux ans, avec du trafic organique stable et des pages indexées par Google, peut devenir un chantier si on décide de changer son URL sans préparation. Modifier l’adresse d’un site WordPress touche à la fois le référencement, l’expérience utilisateur et l’intégrité technique du contenu.
Que ce soit pour passer d’un sous-domaine à un domaine principal, migrer vers HTTPS ou changer de nom de domaine, chaque lien interne, chaque image, chaque redirection mal gérée peut casser ce qui fonctionnait.
A voir aussi : Comment choisir son hébergeur web
Pour aborder ce type de migration avec méthode, on peut s’appuyer sur ces services dédiés à l’environnement Wordpress qui accompagnent la configuration technique et limitent les erreurs critiques pendant la transition.
Préparer la migration d’URL WordPress avant de toucher aux réglages
On ne change pas l’URL d’un site WordPress dans les réglages généraux sans avoir verrouillé plusieurs points en amont. La première étape concrète, c’est la sauvegarde complète du site et de sa base de données. On parle ici d’un export intégral via un plugin de backup ou via phpMyAdmin, pas d’un simple export XML des articles.
A lire aussi : Comment bien choisir une agence web ?
Pourquoi c’est non négociable : si la migration casse le site (écran blanc, boucle de redirection, perte d’accès au tableau de bord), la sauvegarde est le seul moyen de revenir à l’état précédent sans perdre de contenu.
Vérifier les URL codées en dur dans le thème et les plugins
Beaucoup de thèmes WordPress et certains plugins stockent l’URL du site en dur dans leurs fichiers de configuration ou dans la base de données. Avant toute modification, on lance une recherche dans la base pour repérer toutes les occurrences de l’ancienne URL. Des outils comme WP-CLI ou le plugin Search & Replace permettent de scanner la table wp_options, wp_posts et wp_postmeta.
Si on saute cette étape, on se retrouve avec des images qui pointent vers l’ancien domaine, des liens internes cassés et des feuilles de style qui ne se chargent plus. Le site s’affiche sans mise en forme, les pages renvoient des erreurs 404, et Google commence à désindexer.
Documenter la structure des permaliens actuels
Avant de changer quoi que ce soit, on note la structure de permaliens en place (article/%postname%/, catégorie/nom, etc.). Si la migration modifie aussi cette structure, chaque ancienne URL devra être redirigée manuellement ou via un fichier .htaccess. Changer d’URL et de structure de permaliens en même temps multiplie les risques de perte de positionnement SEO.
Modifier l’URL WordPress sans casser le référencement Google
Une fois la sauvegarde faite et les URL en dur repérées, on passe à la modification proprement dite. Deux champs dans les réglages généraux de WordPress contrôlent l’adresse du site : « Adresse web de WordPress (URL) » et « Adresse web du site (URL) ». On modifie les deux en même temps, avec la nouvelle URL complète incluant le protocole (https://).
Si on perd l’accès au tableau de bord après cette modification (ce qui arrive), on peut corriger les valeurs directement dans la base de données, dans la table wp_options, lignes siteurl et home. C’est pour ça que l’accès à phpMyAdmin ou à WP-CLI reste ouvert pendant toute l’opération.
Redirections 301 : le filet de sécurité SEO
Les redirections 301 indiquent à Google que le contenu a déménagé de façon permanente. Chaque ancienne URL doit pointer vers son équivalent exact sur le nouveau domaine. On ne redirige pas tout vers la page d’accueil, c’est le meilleur moyen de perdre le référencement page par page.
Voici les points à couvrir pour que les redirections protègent le SEO :
- Créer une redirection 301 pour chaque page, article et catégorie qui avait du trafic organique, en ciblant l’URL exacte sur le nouveau domaine
- Vérifier que les redirections fonctionnent en chaîne : si une ancienne URL avait déjà une redirection, il faut pointer directement vers la destination finale pour éviter les chaînes de redirections qui ralentissent le chargement
- Tester les redirections avec un outil de crawl pour s’assurer qu’aucune page ne renvoie de code 404 ou 302 temporaire
- Mettre à jour le fichier sitemap.xml avec les nouvelles URL et le soumettre dans Google Search Console
Une redirection 301 bien configurée transfère la majorité de l’autorité SEO de l’ancienne page vers la nouvelle. Sans elle, Google traite la nouvelle URL comme une page inconnue, sans historique.
Mettre à jour Google Search Console et les outils analytics
On ajoute le nouveau domaine comme propriété dans Google Search Console, on soumet le nouveau sitemap et on utilise l’outil de changement d’adresse si on migre d’un domaine vers un autre. Côté analytics, on met à jour l’URL par défaut du site pour ne pas fausser les données de trafic.
Les retours varient sur le délai de prise en compte par Google : certaines migrations sont reflétées en quelques jours, d’autres prennent plusieurs semaines avant que l’indexation soit complète sur le nouveau domaine.
Rechercher et remplacer les anciennes URL dans la base de données WordPress
Modifier les deux champs dans les réglages ne suffit pas. L’ancienne URL reste présente dans le contenu des articles (liens internes insérés manuellement), dans les widgets, dans les options de certains plugins de cache ou de SEO, et parfois dans les données sérialisées stockées par le thème.
Un remplacement brut avec une requête SQL (UPDATE wp_posts SET post_content = REPLACE(…)) fonctionne pour les champs texte simples. En revanche, les données sérialisées nécessitent un outil capable de recalculer les longueurs de chaînes, sinon la désérialisation échoue et le plugin ou le thème concerné plante.
Outils recommandés pour le remplacement d’URL
- WP-CLI avec la commande search-replace, qui gère nativement les données sérialisées et permet de cibler des tables spécifiques
- Le plugin Better Search Replace, qui offre une interface graphique et un mode simulation pour vérifier les remplacements avant de les appliquer
- Interconnect/it Search Replace DB, un script PHP autonome à déposer sur le serveur puis à supprimer immédiatement après usage pour des raisons de sécurité
Dans tous les cas, on fait tourner l’outil sur une copie de la base d’abord. On vérifie que les pages s’affichent correctement, que les images se chargent depuis le bon domaine, et que les menus de navigation pointent vers les bonnes adresses.
Optimisation post-migration : vitesse de chargement et expérience utilisateur
Une migration d’URL, c’est aussi le bon moment pour auditer la vitesse de chargement du site. Les plugins de cache stockent souvent des fichiers statiques liés à l’ancien domaine. On purge intégralement le cache après la migration, et on vérifie que le plugin régénère les fichiers avec les nouvelles URL.
Les images méritent une attention particulière. Si elles étaient servies depuis un CDN lié à l’ancien domaine, il faut reconfigurer le CDN avec la nouvelle adresse. Des images qui chargent depuis un domaine tiers non redirigé ralentissent le site et génèrent des requêtes mixtes si le nouveau site est en HTTPS et que les images pointent vers du HTTP.
Vérification du thème WordPress et des plugins après changement d’URL
Certains thèmes WordPress stockent des clés de licence liées au domaine. Après migration, la licence peut se désactiver et bloquer les mises à jour du thème. On réactive la licence avec le nouveau domaine depuis le panneau du thème ou depuis le compte éditeur.
Côté plugins, les extensions de formulaire de contact, de SEO (Yoast, Rank Math) et de réseaux sociaux stockent parfois l’URL du site dans leurs réglages internes. Un passage en revue de chaque plugin actif après la migration évite les mauvaises surprises : compteurs de partage remis à zéro, balises canonical qui pointent vers l’ancien domaine, ou formulaires qui envoient les données vers une URL inexistante.
La migration d’URL d’un site WordPress ne se résume pas à deux champs modifiés dans un formulaire. C’est une opération qui touche la base de données, le référencement, le cache, les plugins et le thème. En procédant par étapes, en sauvegardant avant chaque modification et en testant systématiquement après, on préserve le trafic acquis et on évite les semaines de correction technique qui suivent une migration bâclée.
