Il y a trois ans, un client m'a appelé un jeudi après-midi en panique absolue. Il avait confié une migration Drupal vers WordPress à une agence bon marché, le site est devenu en ligne vendredi, et dès lundi son trafic organique avait chuté de 67 %. Disparu. Six ans d'équité SEO, simplement... évaporés. Pas de redirections. Des milliers d'URL cassées. Le budget de crawl de Google grillé.
Point clé : les migrations de Drupal vers WordPress échouent sur le mappage des URLs et la traduction des taxonomies, non pas sur le changement de CMS ; livrez une carte de redirection complète et transportez les métadonnées pour conserver vos classements.
J'ai reconstruit ce genre de catastrophe plus de fois que je ne souhaite m'en souvenir. Après plus de 12 000 migrations chez Seahawk Media, je peux vous le dire avec une certaine confiance : la transition technique de Drupal vers WordPress est en réalité la partie facile. La préservation du SEO, c'est là que tout déraille, et c'est là aussi que ça ne devrait absolument pas dérrailler.
Voici le playbook que je suis. Chaque fois.
---
Pourquoi les migrations Drupal vers WordPress sont un champ de mines SEO
Drupal et WordPress génèrent les URLs différemment. Le système de chemins par défaut de Drupal, combiné avec des modules comme Pathauto, produit souvent des structures d'URLs qui n'ont aucun chevauchement avec ce que WordPress génère en standard. Un nœud Drupal à /content/our-services/web-design devient /our-services/web-design ou même /web-design sur WordPress, selon comment vous configurez les permaliens. Ce sont des URLs différentes. Google les voit comme des pages différentes. Sans redirection, l'ancienne est morte.
Et ce n'est pas qu'une question d'URLs. Le système de taxonomie de Drupal correspond aux catégories et tags WordPress, mais pas parfaitement. Les types de contenu personnalisés dans Drupal deviennent des Custom Post Types dans WordPress, et si vous ne construisez pas ces CPT avant la migration, votre contenu atterrit dans le mauvais dossier. J'ai vu un site d'actualités propulsé par Drupal où 800 nœuds « article » ont tous été importés comme des Posts WordPress standard, en écrasant la structure d'archive personnalisée sur laquelle reposait leur linking interne.
Voici ce que la plupart des devs oublient : chaque décision structurelle que vous prenez dans WordPress avant la migration affecte directement les redirections dont vous aurez besoin après. Arrondissez d'abord l'architecture. Les redirections sont un pansement, pas un plan.
---
Étape 1 : Audit pré-migration, connaître ce que vous déplacez avant de le déplacer
Ne touchez pas à l'installation Drupal tant que vous n'avez pas un crawl complet du site en direct. J'utilise Screaming Frog configuré pour crawler jusqu'à 500 000 URLs (la version payante). Exportez tout : les URLs, les codes de statut, les balises titre, les méta-descriptions, les H1, les balises canoniques, les liens internes entrants, les comptages de mots.
Tirez aussi vos données Google Search Console. Filtrez par clics sur les 16 derniers mois (pas 3, pas 6-16, parce que vous voulez attraper le contenu saisonnier). Exportez chaque URL qui a reçu au moins un clic. Ce sont vos URLs protégées. Perdre des rankings sur l'une d'entre elles et le client le remarquera.
Ce que je cherche spécifiquement :
- Contenu en doublon déjà existant sur le site Drupal (corrigez-le avant la migration, pas après)
- Les pages de contenu mince de moins de 200 mots qui ne classent pour rien, celles-ci peuvent être consolidées ou supprimées plutôt que migrées
- Modèles d'URLs non standard comme
/node/1234URLs que Drupal expose parfois même quand Pathauto est actif - Les pages d'archive de taxonomie qui classent, les chemins
/tags/,/category/,/topic/qui génèrent des impressions réelles dans Search Console
Celui-là prend les gens à chaque fois. Les pages de termes de taxonomie Drupal classent souvent pour des requêtes de longue traîne. Si vous ne recréez pas les archives de taxonomie WordPress équivalentes et ne redirigez pas les anciens chemins, vous venez de jeter la circulation passive à la poubelle.
---
Étape 2 : Mappage des URLs, le tableur que personne ne veut construire
Ennuyeux ? Oui. Non-négociable ? Aussi.
Construisez une table de correspondance des URLs dans Google Sheets (ou Airtable si vous préférez, j'ai utilisé les deux). La colonne A est chaque URL Drupal. La colonne B est l'URL WordPress correspondante vers laquelle elle résoudra. La colonne C est un statut : correspondance exacte, redirection nécessaire, consolider, ou supprimer.
Pour un site de 300 pages, cela prend une demi-journée. Pour un site de 8 000 pages, que Seahawk a géré pour un client de l'enseignement supérieur en 2021, cela prend une équipe de trois personnes environ quatre jours ouvrables plus un vendredi soir très fastidieux. Ça en vaut toujours la peine.
Voici quelques règles que je respecte :
- Préservez les slugs autant que possible. Si Drupal a
/blog/how-to-fix-crawl-errors, utilisez le même slug sur WordPress. La plupart du temps, c'est possible. Les paramètres de permalien dans WordPress Réglages → Permaliens vous permettent de faire correspondre le schéma que Drupal utilisait. - Ne redirigez jamais vers la page d'accueil. Les devs flemmards font ça. Ça tue le jus de lien et confond les utilisateurs. Chaque ancienne URL doit avoir une destination spécifique.
- Attention aux URLs paginées. La pagination Drupal ressemble à
?page=1. WordPress utilise/page/2/. Mappez-les ou laissez-les en 404 (ce qui est généralement acceptable, les pages paginées conservent rarement une équité de lien significative, mais confirmez d'abord dans GSC). - Documentez séparément les chaînes de requête. Des trucs comme
/search?keys=wordpressn'ont pas besoin de redirections./events?date=2023-06en aurait peut-être besoin, selon que ces pages se classent ou non.
---
Étape 3 : Migration de contenu, FG Drupal to WordPress et ce qui se passe réellement
Le plugin FG Drupal to WordPress fait le gros du travail pour la plupart des migrations. Il se connecte directement à votre base de données Drupal, extrait les nœuds, utilisateurs, termes de taxonomie et médias. Pour Drupal 7, ça marche brillamment. Pour Drupal 9/10, vous aurez besoin de la version premium, qui coûte environ €99 dernière fois que j'ai vérifié. Ça vaut chaque centime comparé à une migration manuelle.
Ce que le plugin gère bien :
- Le contenu du corps des nœuds (y compris les images intégrées si vous configurez correctement le chemin des médias)
- Les termes de taxonomie mappés aux catégories/tags WordPress
- Les champs personnalisés basiques si vous êtes sur la version premium
Ce qu'il ne gérera pas et que vous devrez corriger manuellement :
- Les Drupal Views, ce sont des mises en page personnalisées/requêtes. Vous les reconstruirez dans WordPress en utilisant des plugins comme WPGridBuilder ou simplement des boucles WP_Query personnalisées
- Formulaires web, mappez-les manuellement sur Gravity Forms ou WPForms ; la logique ne se transfère pas
- Groupes de champs complexes, l'API de champs de Drupal supporte certaines structures de données vraiment étranges. Vous devrez exporter ces données en CSV et les importer via WP All Import
- Régions de contenu en bloc, le système de blocs de Drupal n'a rien à voir avec les widgets WordPress/blocs FSE. C'est une décision de conception, pas une tâche de migration
Une chose que je fais toujours après que FG Drupal to WordPress ait terminé : exécuter un comptage de lignes. Combien de nœuds y avait-il dans Drupal ? Combien d'entrées posts/CPT y a-t-il maintenant dans WordPress ? Elles devraient correspondre (sauf ce que vous avez volontairement exclu). Une divergence de 3% sur un site de 5 000 nœuds, c'est 150 pages manquantes. Allez les trouver.
---
Étape 4 : Implémenter les Redirections Sans Casser Votre Serveur
Une fois la carte d'URL construite et le contenu en direct dans l'environnement de staging WordPress, c'est le moment des redirections. Deux outils : le plugin Redirection pour les petits sites (moins de ~1 000 redirections) et les règles .htaccess pour tout ce qui est plus grand sur Apache, ou les blocs nginx.conf sur Nginx.
Pourquoi cette distinction ? Le plugin Redirection traite les redirections via PHP, ce qui signifie un appel serveur à chaque vérification de redirection. Avec 5 000 redirections et 50 000 pages vues quotidiennes, c'est une véritable surcharge. Les redirections au niveau du serveur sont plus rapides d'un ordre de grandeur.
Pour les grandes migrations, j'exporte la carte d'URL depuis Google Sheets, j'écris un petit script pour générer les blocs RewriteRule, et je les mets dans .htaccess avant le lancement. Ça prend 20 minutes. Ça économise des heures de débogage d'un site lent après le lancement.
Un truc auquel les gens ne pensent pas : les chaînes de redirection. Si Drupal avait déjà des redirections en place (beaucoup de sites Drupal matures en ont, via le module Redirect), vous avez besoin de les trouver et de réduire la chaîne. A → B → C doit devenir A → C. La documentation de Google elle-même est assez claire : les chaînes ralentissent le transfert de PageRank, même si elles ne l'éliminent pas.
---
Étape 5 : Après le lancement, la fenêtre de 72 heures
Allez en direct un mardi ou un mercredi. Jamais le vendredi. Je l'ai appris à mes dépens avec un client en 2018, nous avons lancé une migration de 1 200 pages un vendredi après-midi et découvert une structure de permalien mal configurée à 18h. Dès le lundi, Google avait déjà rampé et indexé une vague d'URLs cassées.
Voici ce que je surveille dans les 72 premières heures :
- Rapport de couverture GSC, surveillez une augmentation des erreurs 404. Certaines sont attendues (anciens chemins du système Drupal). Une augmentation sur vos pages monétisées ne l'est pas.
- Re-crawl Screaming Frog, rampez le site WordPress en direct le lendemain du lancement. Comparez le nombre d'URLs à votre baseline pré-migration.
- Vérifications ponctuelles des redirections, testez manuellement vos 20 URLs Drupal avec le plus de trafic depuis GSC. Collez-les dans un navigateur. Arrivent-elles où elles devraient ?
- Balises canoniques, confirmez que WordPress affiche la bonne balise canonique sur chaque page. Yoast et Rank Math le font automatiquement tous les deux, mais vérifiez quand même.
- Soumission du sitemap XML, soumettez le nouveau sitemap dans GSC immédiatement. N'attendez pas que Google le découvre.
Une chose que je fais et que la plupart des gens omettent : soumettez aussi l'ancien plan de site XML Drupal dans GSC après le lancement, pointant vers l'ancien domaine ou sous-domaine si vous l'avez conservé temporairement. Cela indique à Google exactement quelles anciennes URLs explorer, suivre les redirections et mettre à jour son index plus rapidement.
---
Étape 6 : Le contrôle de santé SEO de 30 jours
Une migration n'est pas terminée au lancement. L'indexation prend du temps. Voici ce que j'examine au repère des 30 jours :
- Les changements de positions de classement, utilisez Ahrefs ou Semrush pour comparer les positions des mots-clés 30 jours avant la migration versus 30 jours après. Attendez-vous à des fluctuations mineures (5-10 positions) sur certains termes. Une baisse de 30+ positions sur un mot-clé primaire nécessite une investigation.
- Les cibles de backlinks, si vous aviez des backlinks externes pointant vers des URLs Drupal spécifiques, vérifiez que ces URLs redirigent correctement. Le rapport Lost Backlinks d'Ahrefs met cela en évidence. Les cibles de backlinks cassées, c'est de l'équité de lien que vous êtes activement en train de perdre.
- Régression de la vitesse de page, les sites WordPress sont parfois plus lents que les sites Drupal bien optimisés. Lancez un audit Lighthouse sur vos 5 pages les plus importantes et comparez avec votre baseline de pré-migration.
- Taux d'indexation, combien de vos URLs soumises sont indexées ? À 30 jours, vous voulez au moins 80% de vos pages de contenu principal indexées. Moins de 60% suggère un problème de crawlabilité (vérifiez robots.txt et assurez-vous que vous n'avez pas accidentellement bloqué Googlebot dans WordPress Paramètres → Lecture).
Seahawk avait un client fintech l'année dernière où la vérification de 30 jours a révélé que 340 pages produit avaient accidentellement été mises en noindex par une action en masse Yoast mal configurée pendant la migration. Détecté à 30 jours : réparable en une après-midi. Détecté à 6 mois : probablement un trou de classement que vous essayez toujours de combler.
---
FAQ
Combien de temps prend réellement une migration de Drupal vers WordPress ?
Cela dépend entièrement de la taille du site et de la complexité du contenu. Un site brochure de 50 pages : 2-3 jours incluant QA. Une archive de news de 5 000 pages avec des types de contenu personnalisés : 6-10 semaines. Le travail SEO, l'audit, la cartographie des URLs, l'implémentation des redirections, le monitoring post-lancement, cela ajoute typiquement 30-40% à quelque estimation de développement core que ce soit. Ne laissez personne vous dire le contraire.
Vais-je perdre mes classements après une migration de Drupal vers WordPress ?
Les fluctuations à court terme sont normales et presque inévitables. Si vous avez bien fait le mappage d'URL, les redirections et les balises canoniques, la plupart des classements se stabilisent en 6-12 semaines. Les sites que j'ai vus souffrir de pertes permanentes avaient tous le même problème : soit pas de redirections, soit des redirections en masse pointant vers la page d'accueil. Faites le travail. Les classements reviennent.
Dois-je migrer tout le contenu de Drupal ou recommencer de zéro ?
Cela dépend de ce que le contenu fait pour vous. Extrayez vos données GSC. Tout contenu avec zéro clics sur 16 mois et aucun backlink est un candidat pour la suppression plutôt que la migration. Migrer du contenu mince et de faible valeur gonfle votre site WordPress et peut diluer le crawl budget. Soyez impitoyable. Cela dit, ne supprimez jamais une URL qui a des backlinks externes, même si la page elle-même est pourrie, redirigez-la vers quelque chose de pertinent.
Quel est le meilleur thème WordPress à utiliser après une migration de Drupal ?
Honnêtement, le choix du thème a presque aucun impact SEO si vous utilisez du HTML bien structuré et que vous gardez la vitesse de page sous contrôle. Je passe par défaut à GeneratePress pour son markup propre et sa surcharge minimale, ou Kadence si le client veut plus de flexibilité de design. Évitez les thèmes lourds en page builder qui sortent 400 KB de CSS inutilisé à chaque chargement de page.
Ai-je besoin d'un développeur ou puis-je le faire moi-même ?
Pour un petit site de moins de 50 pages avec du contenu simple et aucun type de post personnalisé ? Vous pouvez probablement gérer avec FG Drupal to WordPress et le plugin Redirection, en suivant les étapes ci-dessus. Pour quelque chose de plus grand, ou quelque chose avec des CPTs, des taxonomies complexes, ou une empreinte SEO existante significative, engagez un développeur. Le coût de la correction d'une migration bâclée est toujours plus élevé que le coût de la faire correctement la première fois.
---
La migration elle-même représente peut-être 40% du travail. Les autres 60% constituent l'infrastructure SEO que vous construisez autour, la cartographie, les redirections, le monitoring, la patience d'observer les données pendant 30 jours avant de déclarer victoire. J'ai vu des sites WordPress magnifiquement construits s'effondrer en recherche parce que le travail de redirection était négligé, et j'ai vu des installations WordPress bâclées, à peine thémées, conserver chaque classement parce que la cartographie des URLs était méticuleuse.
Faites bien les trucs chiants. Le reste a tendance à suivre.