Migration vers WordPress : guide complet étape par étape

Audit avant migration vers WordPress : contenu, URLs, performances et risques SEO

Avant toute migration vers WordPress, le point de départ reste un audit concret du site actuel. L’objectif est simple : savoir précisément ce qui existe, ce qui fonctionne, et ce qui casse facilement lors d’un transfert. Sans cet état des lieux, les surprises arrivent après la bascule : pages introuvables, médias manquants, balises SEO écrasées, formulaires muets. Et là, le trafic peut décrocher vite 📉.

Pour garder un fil conducteur, imagine le cas de “Atelier Nord”, un site vitrine + blog géré sous Squarespace, avec 120 articles et une dizaine de pages services. Le site génère des leads via un formulaire et quelques pages se positionnent déjà sur Google. Le but est de passer sous WordPress pour gagner en souplesse éditoriale et en SEO, sans perdre l’acquis.

1. 1. Audit des URLs

   Crawl + Search Console + Analytics pour lister toutes les pages et repérer les orphelines.

2. 2. Tri du contenu

   Classe en trois groupes : à garder, à fusionner, à supprimer. Réduis la dette éditoriale.

3. 3. Relevé SEO

   Exporte titles, metas, maillage interne, canonicals. Anticipe les permaliens WordPress.

4. 4. Optimisation des médias

   Compresse les images lourdes, passe en WebP. Conserve les noms de fichiers utiles au SEO.

5. 5. Tests avant mise en ligne

   Utilise un environnement de test pour vérifier les redirections, formulaires et performances.

Cartographier toutes les pages et leurs URL (et repérer les “orphelines”)

Une migration propre commence par une liste exhaustive des URLs. Pas seulement les pages du menu. Il faut aussi compter les anciennes pages encore indexées, les contenus de campagne, les landing pages, voire les PDFs qui ramènent des visites.

Le réflexe opérationnel : extraire les URLs depuis plusieurs sources. Un crawl (type Screaming Frog), les pages indexées via Google Search Console, et les pages réellement visitées via ton outil analytics. Pourquoi croiser ? Parce qu’un crawl voit ce qui est lié, alors que Search Console révèle ce que Google connaît, même si ce n’est plus dans le menu.

Sur “Atelier Nord”, le crawl remonte 260 URLs, mais Search Console en affiche 410. En regardant de près, certaines viennent d’anciens articles supprimés, encore visités via des backlinks. Ces URLs deviennent des priorités de redirection 301 si leur contenu n’est plus repris.

Analyser le contenu : ce qui doit migrer, ce qui doit être fusionné, ce qui doit disparaître

Migrer ne veut pas dire tout copier. Une bonne préparation consiste à classer le contenu en trois groupes : à reprendre tel quel, à mettre à jour, et à retirer. Ce tri réduit la dette éditoriale et évite d’importer des pages faibles qui tirent le site vers le bas.

Un exemple classique : 12 articles quasi identiques sur un même sujet, publiés au fil des ans. Sous WordPress, il est souvent plus efficace de fusionner ces articles en un guide plus solide, puis de rediriger les anciennes URLs vers la nouvelle. Résultat : moins de cannibalisation, une page plus longue, et des signaux SEO mieux concentrés ✅.

Relever l’existant SEO : titles, metas, maillage interne, schema, canonicals

Le SEO ne tient pas qu’aux URLs. Une migration peut modifier les balises, casser les liens internes, ou générer des pages en double. Le minimum : exporter les titles et meta descriptions des pages qui performent, repérer les pages avec beaucoup de liens entrants, et lister les top pages par trafic organique.

Sur un site e-commerce (ou une grosse partie blog), le maillage interne est souvent l’angle mort. Si l’import change les slugs ou si les liens restent en absolu vers l’ancien domaine, tu te retrouves avec des centaines de liens morts. Un simple contrôle après import n’est pas suffisant : il faut anticiper la logique de permaliens WordPress et préparer une stratégie de réécriture.

Mesurer la performance et les éléments techniques qui pèsent sur l’expérience

Pourquoi s’embêter avec la performance avant une migration ? Parce que sans mesure, impossible de savoir si la nouvelle version progresse. Il faut une base : temps de chargement, poids des pages, images trop lourdes, scripts tiers, et stabilité visuelle.

Sur “Atelier Nord”, les pages de services chargent vite, mais les articles contiennent des images de 3 à 6 Mo. En migrant, il y a une occasion nette : recompresser et standardiser les formats (WebP si possible), tout en gardant les noms de fichiers utiles au SEO image. Le gain est immédiat : pages plus rapides, meilleure lecture mobile, et moins d’abandon 📱.

Une migration WordPress réussie commence donc par un inventaire rigoureux. La section suivante passe à l’atelier : hébergement, installation WordPress, et environnement de test pour éviter de casser le site en public.

Préparer l’hébergement WordPress et un environnement de staging sans stress

La différence entre une migration sereine et une migration cauchemar tient souvent à un détail : l’environnement de travail. Travailler directement sur le site en production expose à des interruptions, des bugs visibles, et des soucis de cache impossibles à diagnostiquer. Le bon réflexe : monter un staging propre, puis ne basculer le domaine qu’à la fin 🚦.

Le choix de l’hébergement dépend du scénario. Deux familles dominent : WordPress.org auto-hébergé (tu gères ton hébergeur) et WordPress.com (hébergement géré, options selon le plan). Les deux peuvent convenir, à condition d’aligner le choix avec les besoins réels : plugins, thème sur mesure, e-commerce, contraintes de maintenance.

WordPress.com vs WordPress.org : arbitrer selon les contraintes réelles

WordPress.com séduit par la simplicité : mises à jour du cœur, sécurité infra, CDN intégré. Pour un site éditorial classique, c’est un confort net. En revanche, l’installation de plugins et thèmes tiers dépend du plan. Si le site actuel s’appuie sur des extensions spécifiques, il faut viser un plan qui accepte ces ajouts.

Critère 🧩	WordPress.com 🏢	WordPress.org 🌐
Hébergement	Inclus ✅	À choisir et gérer ⚙️
Maintenance serveur	Gérée 🔒	À ta charge 🧰
Plugins et thèmes tiers	Selon plan (Creator+ conseillé) 🎛️	Libre ✅
Contrôle technique	Plus cadré 📦	Très large 🛠️

Pour une migration qui dépend d’extensions (SEO avancé, formulaires spécifiques, WooCommerce), un plan WordPress.com Creator est souvent le minimum viable, ou alors un WordPress.org bien hébergé. L’idée n’est pas de “prendre le plus gros”, mais de ne pas se retrouver bloqué le jour où il faut réinstaller une brique essentielle.

Monter un staging et sécuriser les accès

Un staging est une copie de travail. Il doit être isolé des moteurs de recherche, protégé par mot de passe, et sans indexation. Sous WordPress, il est facile d’oublier ce point et de laisser Google indexer une version incomplète. Résultat : duplication, pages en “no title”, contenus de test visibles.

Dans le cas “Atelier Nord”, le staging est créé sur un sous-domaine type staging.atelier-nord.fr, protégé via HTTP Auth. Ensuite, WordPress est installé avec un thème de base, et un jeu minimal de plugins : import, redirections, SEO, sécurité. Tout le reste vient après validation.

Sauvegardes : la règle qui évite de perdre des jours 😬

Une migration sérieuse implique une sauvegarde complète avant toute manipulation. Sur WordPress.org, cela couvre la base de données et les fichiers (wp-content, uploads, thèmes, plugins). Sur une autre plateforme, il faut exporter tout ce qui est exportable, puis dupliquer aussi les médias si l’export ne les embarque pas.

Le point souvent négligé : stocker ces sauvegardes hors serveur. Un zip gardé sur le même hébergement n’aide pas en cas de panne ou d’accès bloqué. Un stockage cloud ou un disque externe règle le problème.

Préparer le domaine et le plan de bascule

la bascule du domaine se prépare comme une opération. On réduit le TTL DNS à l’avance, on liste les enregistrements existants, et on identifie qui gère quoi : registrar, DNS, emails, sous-domaines. Combien de migrations “cassent” les emails pro parce que les DNS ont été écrasés ? Beaucoup trop.

Le plan de bascule doit aussi intégrer un filet de sécurité : garder l’ancien hébergement actif au moins 2 à 4 semaines. C’est utile pour récupérer des médias oubliés, vérifier les logs, et revenir en arrière si une fonctionnalité critique lâche. Prochaine étape : exporter le contenu depuis l’ancien CMS et le préparer pour un import propre sous WordPress.

Exporter le contenu depuis n’importe quel CMS vers WordPress : méthodes fiables et pièges fréquents

Une exportation réussie, c’est un transfert qui garde le contenu, les auteurs, les dates, les catégories et si possible les médias. Le souci : chaque plateforme exporte différemment. Certaines génèrent un XML compatible WordPress, d’autres livrent un fichier incomplet, ou oublient les images. Il faut donc adapter la méthode au CMS d’origine.

Cas 1 : migration depuis WordPress.org (export natif XML)

Le scénario le plus simple reste WordPress.org vers WordPress (autre hébergeur ou WordPress.com). L’export natif produit un fichier XML qui contient les articles, pages, taxonomies et commentaires, avec des liens vers les médias.

Le bon geste : exporter “tout le contenu”, puis conserver l’ancien site en ligne le temps que l’import télécharge les images. Si l’ancien hébergement est coupé trop tôt, les liens médias du XML pointent vers le vide. Et tu te retrouves avec une bibliothèque cassée 🧱.

Pour les sites volumineux, il est souvent plus stable de faire plusieurs exports : par période, par type de contenu, ou par auteur. Cela évite les imports qui time-out.

Cas 2 : migration depuis Squarespace, Wix, Blogger

Squarespace fournit un export XML proche de WordPress. C’est une bonne base, mais il faut vérifier la reprise des blocs, des galeries, et des images. Selon les configurations, les médias ne suivent pas toujours. Une étape manuelle est alors nécessaire : retéléverser certaines images ou passer par un outil qui “aspire” les fichiers.

Wix est plus délicat. L’export est limité, et une partie de la structure reste propriétaire. Pour gagner du temps, des services tiers sont souvent utilisés, avec une facturation selon le volume. L’idée n’est pas de tout automatiser aveuglément : un import partiel + reprise manuelle des pages clés peut être plus propre qu’un transfert automatique bourré de divs inutiles.

Blogger est le plus coopératif dans ce trio, car l’importateur est largement supporté. En pratique, cela simplifie la reprise des commentaires et des dates, qui sont souvent critiques pour un blog vivant.

Check-list de ce qui doit être exporté (et vérifié)

Pour éviter d’oublier une brique, une liste de contrôle aide. Elle sert aussi à discuter avec une agence ou un freelance, sans malentendu.

• 🧾 Pages : services, à propos, contact, pages légales
• 📰 Articles : contenu, auteurs, dates, brouillons utiles
• 🗂️ Catégories et tags : structure éditoriale et regroupements
• 🖼️ Médias : images, PDF, vidéos intégrées, tailles et poids
• 💬 Commentaires : utile pour la preuve sociale et l’historique
• 🔁 Redirections existantes : ancien fichier, règles, mapping
• 🧑‍🤝‍🧑 Comptes auteurs : sites multi-rédacteurs, permissions

Nettoyer avant d’importer : encodage, HTML, médias et slugs

Importer du contenu sale dans WordPress coûte cher plus tard. Quand un CMS exporte des balises bizarres, des shortcodes propriétaires, ou des retours à la ligne incohérents, le rendu se dégrade. Un nettoyage ciblé évite des heures de correction.

Exemple concret : un ancien éditeur visuel a inséré des styles inline partout. Dans WordPress, ces styles entrent en conflit avec le thème. Une méthode rapide consiste à normaliser les balises (titres, paragraphes, listes), puis à déplacer la mise en forme vers le thème.

Dernier point : les slugs. Si les URLs sont déjà bien positionnées, il vaut mieux conserver la structure, ou au minimum créer un mapping strict. La prochaine étape consiste justement à importer et reconstruire le site dans WordPress, tout en préparant les redirections et les réglages indispensables.

Après avoir vu comment sortir proprement les données de l’ancien système, le travail continue avec l’import WordPress, la remise en forme via thème, et la sélection des plugins utiles, sans surcharge.

Importer et personnaliser WordPress : thème, plugins, structure et contenus sans mauvaise surprise

Une fois le contenu exporté, l’import dans WordPress n’est pas une simple formalité. C’est le moment où les problèmes remontent : images absentes, pages mal structurées, tableaux cassés, liens internes obsolètes. L’approche la plus sûre : importer, vérifier, corriger, puis seulement personnaliser le design.

Importer les contenus et attribuer correctement les auteurs

Sur WordPress, l’import se fait via les outils natifs ou via un plugin selon la source. L’étape à ne pas rater : l’attribution des auteurs. Si le site est multi-rédacteurs, il faut mapper chaque auteur à un compte existant, ou créer les comptes nécessaires.

Sur “Atelier Nord”, trois rédacteurs externes signent des contenus. Pendant l’import, les auteurs sont associés à des comptes WordPress distincts. Cela garde l’historique, et aide ensuite à gérer les droits d’édition.

Répliquer le design sans recopier les erreurs de l’ancien site

Le design est souvent la tentation numéro une : vouloir “retrouver exactement pareil”. Pourtant, une migration est une chance de corriger des détails qui freinent la conversion : pages trop longues, CTA peu visibles, typographie inégale. Le bon compromis : garder l’identité visuelle (couleurs, ton, logo) tout en améliorant la structure.

Le choix du thème doit suivre des critères pratiques : compatibilité avec Gutenberg, performance correcte, options de personnalisation simples, et maintenance active. Un thème très populaire mais jamais mis à jour devient un risque sécurité.

Plugins : sélectionner peu, configurer bien ✅

Le piège WordPress classique est d’empiler des extensions. Une migration réussie privilégie un set minimal, avec des outils fiables et maintenus. La règle : chaque plugin doit répondre à un besoin clair, mesurable.

Une sélection typique :

• 🔍 SEO : un plugin connu (ou outils natifs si WordPress.com gère une partie)
• 🛡️ Sécurité : durcissement, limitation de login, surveillance
• 🧰 Sauvegarde : planifiée + stockage externe
• ⚡ Cache/performance : selon hébergement, sans doublon avec un CDN
• ✉️ Formulaires : bloc natif ou plugin selon besoins avancés

Sur WordPress.com, certains éléments sont intégrés, ce qui évite des doublons. Un CDN natif réduit l’intérêt d’un plugin de cache lourd. La cohérence compte plus que la quantité.

Structurer les permaliens et verrouiller les réglages critiques

Avant de publier, il faut régler la structure des permaliens. Si l’ancien site utilisait /blog/nom-article/ et que WordPress sort /nom-article/, un choix s’impose : reproduire l’ancienne structure ou assumer un changement massif avec redirections.

Dans un contexte SEO, conserver une structure proche limite les risques. Quand la structure change, le mapping doit être parfait, sinon Google recrawl des 404 et le trafic chute.

Autre point : la gestion des médias. Après import, un contrôle rapide sur 20 à 30 pages permet de repérer si les images sont bien locales (dans la médiathèque) ou si elles pointent encore vers l’ancien domaine. Si elles restent externes, le site dépend d’un serveur qui sera peut-être coupé.

Cas concret : une page service qui convertit mieux après migration

“Atelier Nord” avait une page “Audit SEO” très visitée, mais avec un formulaire en bas, peu visible. Sous WordPress, la page est reconstruite avec un bloc de conversion plus haut, une preuve sociale, et une section “process” en 5 étapes. Le contenu reste similaire, mais la mise en page guide mieux.

Résultat : après bascule, les conversions augmentent sans toucher au budget acquisition. Ce type d’amélioration est souvent plus simple pendant une migration que sur un site figé par un CMS fermé.

La personnalisation terminée, la vraie ligne d’arrivée reste la transition : redirections, tests, suivi Search Console, et contrôle post-bascule. C’est exactement ce que traite la section suivante.

Une fois le site prêt, la dernière phase consiste à basculer sans interruption, sécuriser le référencement, et vérifier chaque parcours utilisateur.

Assurer une transition sans perte de trafic : redirections 301, tests, Search Console et monitoring

La migration vers WordPress se gagne dans les détails de fin. Le site peut être beau, rapide, bien structuré, et pourtant perdre du trafic si les redirections sont mal gérées. Google n’a pas d’affection pour les “nouveaux départs”. Il suit les URLs, les signaux, et la cohérence. La mission est donc de garder la continuité, même si le moteur recalcule tout pendant quelques semaines 🔄.

Construire un plan de redirections 301 basé sur les données

Les redirections 301 doivent couvrir toutes les URLs qui changent. Le meilleur point de départ : le mapping issu de l’audit. Les pages à fort trafic, les pages qui rankent, et celles avec backlinks passent en priorité.

Deux cas fréquents :

1) URLs identiques : idéal. Moins de redirections, moins de risques, recrawl plus propre.

2) URLs modifiées : mapping strict. Chaque ancienne URL doit pointer vers la page la plus proche sémantiquement. Rediriger “en vrac” vers la home est un signal faible, et frustre l’utilisateur 😤.

Sur “Atelier Nord”, 80 articles changent de structure. Un tableau de correspondance est créé, puis testé avec une liste d’URLs réelles issues de Search Console. Après déploiement, un crawl du nouveau site permet de vérifier qu’aucune 404 n’échappe au filet.

Tester avant bascule : parcours, formulaires, tracking, emails

Avant de modifier les DNS, la version staging doit être testée comme un site public. Concrètement : tester les formulaires (et la réception), vérifier les pages légales, simuler une demande de devis, contrôler les liens vers les réseaux sociaux, et tester sur mobile.

Le tracking est souvent oublié. Google Analytics et Google Tag Manager doivent remonter des événements après migration. Sinon, impossible de mesurer l’impact. Un contrôle simple : envoyer un formulaire test et vérifier l’événement dans l’outil de suivi.

Basculer le domaine sans casser la messagerie

Quand le domaine est transféré ou que les DNS changent, la messagerie pro peut tomber si les enregistrements MX ne sont pas recopiés. Le bon process : exporter la zone DNS actuelle, puis reconstruire à l’identique en ne modifiant que ce qui est nécessaire pour pointer le site.

Une fois le DNS basculé, il faut surveiller les variations. Pendant la propagation, certains utilisateurs voient l’ancien site, d’autres le nouveau. Pour limiter l’effet, réduire le TTL 24 à 48 heures avant aide.

Search Console : sitemap, inspection d’URL, suivi des erreurs

Après bascule, soumettre le nouveau sitemap dans Google Search Console accélère la prise en compte. Ensuite, l’onglet pages (indexation) devient le tableau de bord quotidien : erreurs 404, pages exclues, redirections, canonicals.

Si un changement de domaine a eu lieu, l’outil de changement d’adresse peut aider. Si seul le CMS change mais pas le domaine, le travail se concentre sur les redirections, la vitesse, et la cohérence des balises.

Contrôle post-migration : une routine sur 14 jours

La migration ne s’arrête pas le jour de la bascule. Les deux semaines suivantes servent à corriger vite les signaux faibles. Une routine simple :

1. 📌 Contrôler les 404 et ajouter des redirections si besoin
2. 🧭 Vérifier les pages top trafic et leurs positions
3. 🖼️ Repérer les images cassées et les réimporter
4. ⚙️ Surveiller les performances (Core Web Vitals, poids des pages)
5. 📨 Tester les formulaires et la délivrabilité email

Sur “Atelier Nord”, un détail ressort au jour 3 : des liens internes pointent vers l’ancienne structure /blog/. Une règle de réécriture corrige une partie, mais un nettoyage éditorial final règle le reste. Ce type de correction rapide évite que Google crawl des chemins inutiles.

Une migration vers WordPress n’est pas juste un transfert technique. C’est une opération éditoriale, SEO et produit. Quand l’audit, le staging, l’import et les redirections sont traités avec méthode, le site repart sur une base plus saine, et les optimisations deviennent plus simples ensuite 🚀.

Ce que personne ne vous dit ⚠️

Est-ce que je dois migrer toutes mes pages une par une ?

Non, mais il faut lister toutes les URLs existantes, même celles qui ne sont plus dans le menu. Celles qui ont du trafic ou des backlinks méritent une redirection 301.

Combien de temps prend une migration vers WordPress ?

Ça dépend de la taille du site. Pour un site comme Atelier Nord (120 articles), prévois 2 à 4 semaines si tu fais un audit sérieux et des tests.

Faut-il garder les mêmes URLs après migration ?

Idéalement oui, pour préserver le SEO. WordPress permet de personnaliser les permaliens. Si tu changes d'URL, mets en place une redirection 301 systématique.

Quels sont les risques si je saute l'audit ?

Pages introuvables, médias manquants, balises SEO écrasées, formulaires qui ne marchent plus. Bref, une chute de trafic possible. L'audit est la seule protection.

Vous avez essayé ? Racontez-nous dans les commentaires

Laisser un commentaire