De Drupal à WordPress : quand est-ce le bon choix, et à quoi devez-vous renoncer ?.

Ce qui est transféré de Drupal vers WordPress, et ce qui ne l’est pas?

Le plugin gratuit FG Drupal to WordPress transfère vos types de contenu par défaut, vos catégories, vos étiquettes et vos fichiers médias. Mais pas tout. Pour migrer vos comptes utilisateurs et leurs mots de passe hachés, ainsi que vos types de publication personnalisés, menus, commentaires et redirections 301 automatiques, il faut la version Premium. Si vous n'avez pas besoin de migrer vos utilisateurs (c'est le cas de beaucoup de sites), la version gratuite suffit, comme le souligne Kinsta.

Votre thème ne sera pas transféré. Il faudra le recréer de zéro, car Drupal 8 et ses versions ultérieures tournent sous Twig, tandis que WordPress utilise des modèles PHP. Le plus gros morceau, ce seront vos paragraphes : pour chaque type, vous devrez choisir un bloc Gutenberg personnalisé ou un champ ACF, puis coder les blocs de remplacement. Ensuite vient le nettoyage. Après l'export global, vous corrigerez à la main les champs personnalisés, les balises méta, les chemins de médias cassés et les relations entre entités. Et gardez du temps pour cette reprise manuelle : ces oublis, vous ne les verrez souvent qu'en comparant les anciennes pages avec la nouvelle version.

Comment planifiez-vous la structure des URL et les redirections afin de préserver votre trafic de recherche ??

Cartographiez vos chemins dans un tableur : en colonne A, toutes les URL Drupal ; en colonne B, l'URL WordPress cible ; en colonne C, le statut, qu'il s'agisse d'une correspondance exacte, d'une redirection nécessaire, d'une consolidation ou d'une suppression. Extrayez les alias directement depuis la table « path_alias ». Ajoutez les enregistrements Pathauto, puis exportez les lignes de votre module Redirect pour éviter les chaînes de redirection. Sans ce travail de correspondance sur les URL Pathauto, ClonePartner constate que les sites perdent généralement entre 20 et 40 % de leur trafic organique au cours des 90 premiers jours. Certains chemins passent souvent entre les mailles du filet : vérifiez les fichiers déplacés de `sites/default/files/` vers `wp-content/uploads/`, les barres obliques finales ajoutées ou retirées sur les archives de taxonomie, ainsi que les structures de pagination modifiées. Et les pages de termes génèrent souvent du trafic sur la longue traîne : reconstruisez vos modèles de taxonomie et redirigez les anciennes routes. Personne n'y pense avant que le trafic ne baisse.

Configurez des redirections 301 ou 308 côté serveur, sans chaînes de redirection, comme le recommande Google Search Central. Et surveillez la suite de près : suivez vos indicateurs de recherche sur les deux propriétés dans Search Console, envoyez votre nouveau plan du site et gardez ces redirections actives pendant au moins un an. Le lancement n'est pas la ligne d'arrivée, c'est le début de la surveillance.

Comment le contenu est-il transféré depuis Drupal : exportation, API ou exploration ??

Migrez votre base de données avec un plugin pour gérer les gros volumes, puis traitez les cas particuliers à la main. Mais le crawl de vos pages publiques doit servir au contrôle de la migration, pas à l'extraction des données sources. Codeable décrit bien cette méthode en deux temps : laissez le plugin FG migrer vos articles, vos médias et vos termes, puis repassez manuellement sur les champs personnalisés non mappés, les chemins manquants et les scripts qui relient les relations entre entités personnalisées.

Un crawl ne capture que ce que voit le navigateur : le HTML affiché, les en-têtes de réponse HTTP, les balises d'en-tête, le balisage Schema et les balises canoniques. Tout le back-office lui échappe. Les nœuds de brouillon, le schéma des champs en base de données et les autorisations de rôle restent invisibles : impossible, donc, de reconstituer la structure de votre contenu uniquement depuis le front-end. Avant de lancer la migration, extrayez directement de la base les alias de chaque chemin, la table du module Redirect, les balises méta générées et les balises hreflang alternatives. Et un crawl public ne révélera aucun point de terminaison privé de l'API : vérifiez l'accès au backend avec vos développeurs avant de concevoir le pipeline.

Quels sont les avantages dont bénéficient vos rédacteurs sur WordPress par rapport à Drupal ??

Votre équipe éditoriale part d’un tableau de bord standard avec deux types intégrés : les « Articles », avec leurs dates de publication, leurs catégories et leurs balises, puis les « Pages », hiérarchisées et non classées. C’est la base. Mais dès que votre site demande des structures plus précises, enregistrez des types de publication et des taxonomies dédiés plutôt que de tout ranger au même endroit. Le plugin « Custom Post Type UI », actif sur plus d’un million de sites, vous permet de configurer ces définitions depuis l’interface d’administration (sans écrire de code personnalisé).

Vous abandonnez la rigueur relationnelle, et la différence se voit vite dans vos champs. Les champs d’entité Drupal, les vocabulaires, les autorisations d’accès et les graphes de traduction n’ont pas d’équivalents dans le noyau d’une installation WordPress « propre ». Commencez donc par le modèle. Avant de migrer les données brutes, vous devez le reconstruire avec des types de publications personnalisés et des groupes de champs ACF. Si vous sautez cette étape, votre contenu atterrit dans les mauvaises tables, comme dans l’étude de cas de Gautam Khorana, où 800 nœuds d’articles ont été importés directement dans la table « Posts » standard. Vos paragraphes deviennent alors des blocs Gutenberg ou des mises en page « Flexible Content » d’ACF, ce qui suppose de savoir écrire des interfaces de blocs personnalisées avec React. Ce n’est pas un réglage à activer ou désactiver : c’est une compétence qui vous manque et qu’il faudra acquérir.

Si votre site reste petit, surtout rédactionnel, avec peu de types de contenu, ce compromis peut passer. Sinon, il va vous coûter cher.

Combien de temps dure une migration de Drupal vers WordPress, et quels sont les facteurs qui déterminent l'ampleur de la tâche ??

Le calendrier de votre projet dépend de cinq facteurs : le volume total d’URL, la diversité des types de contenu, la taille de la médiathèque, les intégrations tierces. Et les localisations actives. Aucun outil de référence externe ne peut vous donner une date de livraison exacte. Chaque type de contenu conservé ajoute du travail. Pour chacun, vous devez enregistrer un type de publication personnalisé, définir des schémas de champs ACF et écrire un code de modèle dédié. Et votre interface utilisateur demande une vraie réécriture, pas un simple portage de feuille de style.

Un grand nombre de pages augmente le volume d’URL et alourdit le contrôle qualité des redirections. Plusieurs locales compliquent encore le sujet : il faut produire des exportations hreflang distinctes et mener des audits de parité manuels sur tous les domaines de préproduction. Les paragraphes, eux, font bouger l’estimation. Si vos pages reposent sur des paragraphes, réservez de la capacité supplémentaire dans votre sprint pour l’ingénierie des blocs. La liste de contrôle SEO de Pagepro compte 8 étapes (de l’analyse comparative initiale au suivi post-lancement), et chacune mérite sa propre ligne budgétaire.

Cette évaluation gratuite ancre vos estimations dans des données techniques. Elle analyse votre page d’accueil et jusqu’à huit pages choisies au hasard, puis attribue une note sur 100 répartie sur huit critères. Mais vous n’en voyez qu’une partie. L’analyse vérifie la taille des charges utiles des scripts, les en-têtes de réponse et le balisage Schema avant que vous ne validiez des estimations de sprint. Elle ne peut pas consulter vos données analytiques privées ; recensez donc vous-même vos types de contenu, sans vous en remettre uniquement à l’outil.

Dans quels cas ne faut-il pas passer de Drupal à WordPress ??

Ne changez pas de plateforme si votre site Drupal contient beaucoup de contenu : vous perdrez en général davantage sur les champs, les taxonomies, les autorisations et la structure multilingue que vous ne gagnerez ailleurs. Et restez sur Drupal si votre site est stable, si vos rédacteurs l’apprécient et si vos pages obtiennent de bons résultats lors de l’évaluation.

Vérifiez la version de votre noyau : Drupal 7 a atteint sa fin de vie le 5 janvier 2025, et Drupal 10 atteindra officiellement sa fin de vie le 9 décembre 2026. N’attendez pas. Il vous faut une feuille de route active, que ce soit pour une mise à niveau sur place ou pour une migration complète de la plateforme.

Pour les sites éditoriaux et marketing statiques, tournez-vous vers Astro. Si vous gérez des applications web dynamiques, des sessions personnalisées ou de vastes équipes éditoriales, envisagez plutôt Next.js avec Sanity ou Contentful. Mais chaque option a son prix. Astro supprime le constructeur visuel de pages et le moteur de plugins auquel vos rédacteurs sont habitués, et une architecture « headless » vous oblige à configurer, puis à financer, un backend séparé. Mon travail consiste à analyser votre architecture technique et à bâtir les plans de migration. Ensuite, je bascule vos installations existantes et vos configurations WordPress vers ces environnements d’exécution modernes, tout en confiant les développements WordPress standards à des agences partenaires.

Vos questions, nos réponses.

À lire ensuite.

1. 01Alternatives à DrupalMettez à niveau, dissociez ou déplacez, en fonction de vos pages.
2. 02De Drupal à Next.jsDissociez ou remplacez, tout en conservant le modèle de contenu intact.