Vous avez migré votre site WordPress: nouveau domaine, nouvel hébergement, peut-être HTTP vers HTTPS. Tout semble correct. Puis vous commencez à cliquer. Les images manquent. Les boutons ne mènent nulle part. Vos liens internes sont devenus un labyrinthe d’erreurs 404.

Cela arrive parce que WordPress stocke les URLs complètes dans les articles, menus, widgets, champs personnalisés et constructeurs de pages. Lorsque vous déménagez, ces liens écrits en dur ne se mettent pas à jour automatiquement, tandis que les réglages essentiels comme l’URL du site et les permaliens survivent généralement, tout le reste peut se casser.

La bonne nouvelle ? Vous n’avez pas à les corriger manuellement. Voici comment.

Avant de faire quoi que ce soit

1. Gardez l’ancien site accessible pendant 48 heures (si possible) comme solution de secours.
2. Faites une sauvegardeUne copie des fichiers et de la base de données de votre si... More fraîche de la base de donnéesL'endroit où tout le contenu, les réglages et les données... More et des fichiers de votre nouveau site.
3. Travaillez sur un environnement de staging si vous le pouvez: ne testez jamais les corrections de liens sur un site de production en direct.

Trouver les liens cassés : 3 méthodes

Méthode 1 : Screaming Frog (meilleur pour les grands sites) – Gratuit jusqu’à 500 URLs. Parcourt tout votre site et affiche chaque erreur 404.

Méthode 2 : Vérificateurs de liens cassés en ligne – Des outils comme Dr. Link Check ou W3C Link Checker. Rapides mais moins complets.

Méthode 3 : Google Search Console – Allez dans Couverture → Erreurs → 404. Affiche ce que Google a trouvé.

Vérification manuelle rapide : Après la migration, cliquez sur vos pages principales, articles de blog, boutique et menus. Notez les éventuelles erreurs 404.

Corriger les liens en masse (la méthode sûre)

La règle d’or : n’effectuez jamais de recherche/remplacement brut dans la base de données

WordPress sérialise les données (stocke les longueurs de chaînes). Une recherche/remplacement brut corrompra votre base de donnéesL'endroit où tout le contenu, les réglages et les données... More.

Les bons outils :

Option 1 : Better Search Replace (extensionUn logiciel qui ajoute des fonctionnalités spécifiques à ... More gratuite)

• Installez et activez.
• Recherchez http://anciensite.com
• Remplacez par https://nouveausite.com
• Sélectionnez toutes les tables.
• Faites d’abord un essai à blanc → puis exécutez en réel.
• Sans danger pour les données sérialisées.

Option 2 : WP CLI (pour les développeurs)

wp search-replace 'http://anciensite.com' 'https://nouveausite.com' --all-tables

Option 3 : Migrate DB Pro ou WP Migrate (payant) – Gère parfaitement la sérialisation. Idéal pour les migrations complexes.

Corrections manuelles pour les cas difficiles

Certains liens ne seront pas détectés par la recherche/remplacement en masse :

Menus de navigation : Allez dans Apparence → Menus. Vérifiez chaque lien personnalisé. Mettez à jour manuellement.

Widgets : Apparence → Widgets. Ouvrez chaque widgetUn petit bloc qui ajoute un contenu ou une fonctionnalité s... More (surtout Texte et HTMLLe langage de balisage standard pour créer des pages web, s... More personnalisé). Mettez à jour les URLs.

Contenu du constructeur de pages : Ouvrez chaque pageUn contenu statique (ex. : "À propos", "Contact") qui ne fa... More dans Elementor, Beaver Builder ou WPBakery. Réenregistrez la pageUn contenu statique (ex. : "À propos", "Contact") qui ne fa... More, de nombreux constructeurs réécrivent les URLs lors de l’enregistrement.

Fichiers de thème codés en dur : Recherchez dans votre dossier de thème anciensite.com. Mettez à jour manuellement ou via la fonction « Rechercher dans les fichiers » de votre IDE.

Liens de l’éditeur de blocs : Ouvrez les articles concernés. Cliquez sur les blocs liés. Mettez à jour l’URL dans les paramètres du bloc.

Le danger caché : la sérialisation de la base de données

WordPress stocke certaines données de manière « sérialisée », cela inclut la longueur de la chaîne. Si vous effectuez une recherche/remplacement brut, modifier la longueur de l’URL corrompt les données.

Les outils comme Better Search Replace et WP CLI gèrent cela automatiquement. N’utilisez jamais la recherche/remplacement brut de phpMyAdmin sauf si vous savez exactement ce que vous faites.

Après la correction : liste de validation

• Réesenregistrez les permaliens (Réglages → Permaliens → Enregistrer les modifications)
• Videz tous les caches (cache d’extensionUn logiciel qui ajoute des fonctionnalités spécifiques à ... More, CDN, navigateur)
• Relancez Screaming Frog: confirmez zéro erreur 404 interne
• Vérifiez Google Search Console: pas de nouvelles erreurs 404 après 48 heures
• Testez les parcours utilisateur clés : Accueil → produit/article → paiement/contact
• Vérifiez les images sur quelques articles aléatoires

Prévention : stratégies de liens prêtes pour la migration

Pour votre prochaine migration :

• Utilisez des chemins relatifs pour les liens internes : /contact/ au lieu de https://site.com/contact/
• Utilisez la fonction WordPress home_url() dans les fichiers de thème au lieu d’URLs codées en dur
• Stockez uniquement des chemins relatifs dans les champs personnalisés quand c’est possible
• Documentez chaque endroit où vous avez codé des URLs en dur

Réflexions finales

Les liens internes cassés après une migration sont normaux. Ils sont corrigeables. La clé est d’utiliser le bon outil, un outil qui respecte les données sérialisées.

Rappelez-vous les règles d’or :

1. Faites toujours une sauvegardeUne copie des fichiers et de la base de données de votre si... More avant de toucher à la base de donnéesL'endroit où tout le contenu, les réglages et les données... More
2. N’utilisez jamais de recherche/remplacement brut dans phpMyAdmin
3. Faites toujours un essai à blanc d’abord
4. Testez sur un environnement de staging avant la production

Corrigez vos liens une fois, correctement, et votre site migré fonctionnera mieux que l’original.