Une migration WordPress peut conserver l’apparence du site tout en dégradant son référencement : URL modifiées, redirections absentes, balises canoniques incorrectes, robots bloqués ou pages devenues inaccessibles. L’objectif réaliste n’est pas de garantir l’absence de toute fluctuation, mais de préserver les signaux utiles, détecter les écarts rapidement et rendre chaque changement explicable.
Pour relier ce guide à une mise en œuvre concrète, consultez la migration et la reprise d’un site WordPress : cette page présente l’inventaire, la copie, la bascule, les redirections et le retour arrière.
Avant la migration, exportez les URL connues grâce au plan de site, à un crawl et, si disponibles, aux données de la Search Console et des outils d’analyse. Pour chaque page importante, relevez le code HTTP, la balise title, la description, le H1, la canonique, les directives d’indexation et les principaux liens internes.
Identifiez les pages qui reçoivent des visites organiques, des impressions ou des liens externes. Ajoutez les fichiers non HTML utiles, comme les PDF ou images visibles dans la recherche. Cet inventaire sert à prioriser les contrôles ; il ne faut pas se limiter aux pages accessibles depuis le menu.
Lors d’un simple changement d’hébergement, conservez autant que possible le domaine, les chemins et la structure. Une refonte simultanée peut justifier des modifications, mais chacune doit répondre à un besoin réel. Changer plusieurs dimensions à la fois complique le diagnostic si les performances baissent.
Créez une table de correspondance entre chaque ancienne URL utile et sa destination la plus pertinente. Une redirection vers la page d’accueil n’est pas un remplacement acceptable pour des contenus différents. Les pages supprimées sans équivalent peuvent retourner un statut adapté, après vérification de leurs liens et de leur valeur.
Implémentez des redirections permanentes directes, sans chaînes ni boucles. Testez-les sur l’environnement de validation lorsque la configuration le permet. Incluez les variantes de protocole, de domaine et les anciens chemins réellement utilisés. Les paramètres d’URL nécessaires à une campagne ou à une fonction ne doivent pas être supprimés sans analyse.
Mettez à jour les liens internes, menus, images, données structurées et balises canoniques pour viser les URL finales plutôt que de compter sur les redirections. Cela accélère l’exploration et réduit les dépendances à l’ancienne architecture.
Le site de préproduction doit être protégé par authentification et exclu de l’indexation. Évitez de compter uniquement sur une directive robots.txt : elle n’empêche pas toujours qu’une URL connue apparaisse dans les résultats. Les canoniques de test ne doivent pas remplacer celles de production.
Au moment de la bascule, retirez les protections propres au test. Contrôlez les directives robots, les balises noindex, les en-têtes HTTP, les canoniques et le plan de site depuis l’adresse publique. Une case WordPress restée cochée peut empêcher l’indexation de toutes les pages.
Comparez les pages importantes avant et après migration. Le texte, les titres, les descriptions, les données structurées, les images et leurs attributs doivent être préservés ou modifiés volontairement. Un nouveau thème peut cacher une partie du contenu, multiplier les H1 ou supprimer des liens contextuels.
Vérifiez la navigation et le maillage entre pages mères, services et guides. Les pages orphelines deviennent plus difficiles à découvrir. Contrôlez aussi la pagination, les archives et les règles de canonisation afin de ne pas créer de nombreuses variantes indexables.
Le nouvel hébergement doit répondre correctement sous HTTPS, sans erreurs intermittentes ni redirections multiples. Mesurez des pages représentatives sur mobile et surveillez les journaux serveur. Une amélioration visuelle ne compense pas un serveur instable, des ressources bloquées ou une génération très lente.
Validez également les codes des pages inexistantes. Une page d’erreur qui retourne un statut de succès brouille l’exploration. Les restrictions par adresse IP, pare-feu ou CDN doivent laisser passer les robots légitimes sans exposer l’administration.
Relancez un crawl des URL de référence et comparez les codes, canoniques, métadonnées et liens. Soumettez le plan de site final dans la Search Console et observez les erreurs d’exploration, l’indexation et les performances par page. Les données demandent du temps ; évitez de modifier encore l’architecture sur la base d’une variation isolée.
Conservez l’ancien environnement pendant la période prévue pour le retour arrière, sans le laisser indexable. Documentez les corrections et leurs dates afin de relier les évolutions observées aux actions réelles.
La protection SEO dépend d’une préparation technique et éditoriale commune. Pour faire inventorier les dépendances, préparer les redirections et contrôler la bascule, consultez la page migration et reprise de site WordPress.
AdnProg peut analyser l’existant, préciser le périmètre et réaliser les changements nécessaires. La prestation associée est présentée sur la page Migration et reprise de site WordPress.