drupal-to-wordpress-migration-seo.html
< BACK Terminal d'ordinateur vintage aux reflets ambrés sur un bureau en bois avec des feuilles de calcul manuscrites et une tasse de thé fumante, appartement à Londres, lumière diffuse d'une fenêtre par temps couvert

Migration Drupal vers WordPress : Un playbook SEO pour 12 000 sites

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é.Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.

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.Drupal to WordPress migrations fail on URL mapping and taxonomy translation, not the CMS swap; ship a complete redirect map and transport metadata to keep rankings.

J'ai reconstruit ce genre de dégâts plus de fois que je ne voudrais le compter. Après 12 000+ migrations chez Seahawk Media, je peux vous affirmer avec une certaine confiance : le déplacement technique de Drupal à WordPress est en réalité la partie facile. La préservation du SEO est là où tout s'effondre -- et où absolument ça ne devrait pas arriver.Seahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong -- and where it absolutely doesn't have to.

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./content/our-services/web-design becomes/our-services/web-design or even/web-design on WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.

Et ce ne sont pas que les URLs. Le système de taxonomie de Drupal se mappe 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 CPTs avant de migrer, votre contenu se retrouve dans le mauvais endroit entièrement. J'ai vu un site d'actualités propulsé par Drupal où 800 nœuds « article » ont tous été importés en tant que Posts WordPress standard, écrasant la structure d'archive personnalisée sur laquelle s'appuyait 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.every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a plan.

---

Étape 1 : Audit Pré-Migration -- Sachez 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.Screaming Frog set to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.

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.protected URLs. Lose rankings on any of these and the client will notice.

Ce que je cherche spécifiquement :

  • Contenu en doublon déjà existant sur le site Drupal (corrigez-le avant la migration, pas après) already existing on the Drupal site (fix it before migrating, not after)
  • Les pages de contenu mince sous 200 mots qui ne rankent pour rien -- celles-ci peuvent être consolidées ou supprimées plutôt que migrées under 200 words that rank for nothing -- these can be consolidated or deleted rather than migrated
  • Modèles d'URLs non standard comme /node/1234 URLs que Drupal expose parfois même quand Pathauto est actif like/node/1234 URLs that Drupal sometimes exposes even when Pathauto is active
  • Les pages d'archive de taxonomie qui rankent -- des chemins /tags/, /category/, /topic/ qui ont des impressions réelles dans Search Console that rank -- /tags/,/category/,/topic/paths that have actual Search Console impressions

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.and redirect the old paths, you've just thrown away passive traffic.

---

Étape 2 : Mapping d'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.exact match,redirect needed,consolidate, or delete.

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 environ quatre jours de travail plus un vendredi soir très fastidieux. Ça en vaut toujours la peine.

Voici quelques règles que je respecte :

  1. 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.If Drupal has/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using.
  2. 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.Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
  3. Faites attention aux URLs paginées. La pagination Drupal ressemble à ?page=1. WordPress utilise /page/2/. Mappez-les ou laissez-les en tant que 404s (ce qui est habituellement acceptable -- les pages paginées conservent rarement du link equity significatif, mais confirmez dans GSC d'abord).Drupal pagination looks like?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine -- paginated pages rarely hold meaningful link equity, but confirm in GSC first).
  4. Documentez séparément les chaînes de requête. Des trucs comme /search?keys=wordpress n'ont pas besoin de redirections. /events?date=2023-06 en aurait peut-être besoin, selon que ces pages se classent ou non.Things like/search?keys=wordpress don't need redirects./events?date=2023-06 might, depending on whether those pages rank.

---

É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.FG Drupal to WordPress plugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual migration.

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 :

  • Drupal Views -- il s'agit de mises en page/requêtes personnalisées. Vous les reconstruirez dans WordPress en utilisant des plugins comme WPGridBuilder ou simplement des boucles WP_Query personnalisées -- these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
  • Webforms -- mappez-les manuellement à Gravity Forms ou WPForms ; la logique ne se transfère pas -- map these to Gravity Forms or WPForms manually; the logic doesn't transfer
  • Groupes de champs complexes -- l'API Field de Drupal supporte certaines structures de données véritablement étranges. Vous devrez les exporter en CSV et importer via WP All Import -- Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
  • Régions de contenu en blocs -- le système de blocs de Drupal n'a rien à voir avec les widgets/blocs FSE de WordPress. C'est une décision de conception, pas une tâche de migration -- Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task

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.Redirection plugin for smaller sites (under ~1,000 redirects) and.htaccess rules for anything larger on Apache, or nginx.conf blocks on 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.RewriteRule blocks, and drop them into.htaccess before go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-launch.

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.redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentation is pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.

---

Étape 5 : Après le lancement -- la fenêtre de 72 heures

Lancez-vous un mardi ou un mercredi. Jamais 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. Le lundi, Google avait déjà crawlé et indexé une vague d'URL cassées.

Voici ce que je surveille dans les 72 premières heures :

  1. Rapport Coverage de GSC -- surveillez un pic de 404. Certains sont attendus (anciens chemins du système Drupal). Un pic sur vos pages monétisées ne l'est pas. -- watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
  2. Re-crawl Screaming Frog -- crawlez le site WordPress en direct le lendemain du lancement. Comparez le nombre d'URL à votre référence pré-migration. -- crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
  3. Vérifications des redirections -- testez manuellement vos 20 URLs Drupal avec le plus de trafic à partir de GSC. Collez-les dans un navigateur. Atterrissent-elles où elles le devraient ? -- manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
  4. Balises canoniques -- confirmez que WordPress affiche le bon canonical sur chaque page. Yoast et Rank Math le font tous deux automatiquement, mais vérifiez quand même. -- confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
  5. Soumission du plan du site XML -- soumettez le nouveau plan du site dans GSC immédiatement. N'attendez pas que Google le trouve. -- submit the new sitemap in GSC immediately. Don't wait for Google to find it.

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.submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.

---

É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 :

  • Changements de position de classement -- utilisez Ahrefs ou Semrush pour comparer les positions des mots-clés 30 jours avant la migration vs. 30 jours après. Attendez-vous à des fluctuations mineures (5-10 positions) sur certains termes. Une baisse de 30+ positions sur un mot-clé principal nécessite une investigation. -- use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5-10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
  • Cibles de backlinks -- si vous aviez des backlinks externes pointant vers des URL Drupal spécifiques, vérifiez que ces URL redirigent correctement. Le rapport Lost Backlinks d'Ahrefs l'affichera. Les cibles de backlinks brisées sont une équité de lien que vous perdez activement. -- if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
  • Régression de vitesse de page -- les sites WordPress sont parfois plus lents que les sites Drupal bien optimisés. Exécutez un audit Lighthouse sur vos 5 pages les plus importantes et comparez à votre référence pré-migration. -- WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
  • Taux d'indexation -- combien de vos URL 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 d'accessibilité (vérifiez robots.txt et assurez-vous que vous n'avez pas accidentellement bloqué Googlebot dans WordPress Paramètres → Lecture). -- how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).

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.noindex by a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.

---

FAQ

Combien de temps prend réellement une migration de Drupal vers WordPress ?

Dépend entièrement de la taille du site et de la complexité du contenu. Un site de brochure de 50 pages : 2-3 jours y compris l'assurance qualité. Une archive d'actualités de 5 000 pages avec des types de contenu personnalisés : 6-10 semaines. Le travail SEO -- audit, mappage d'URL, implémentation des redirections, surveillance post-lancement -- ajoute généralement 30-40% à l'estimation de développement de base. Que personne ne vous dise 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 ?

Dépend de ce que le contenu fait pour vous. Tirez vos données GSC. Tout contenu avec zéro clic sur 16 mois et aucun backlink est un candidat à la suppression plutôt qu'à la migration. Migrer du contenu mince et de faible valeur gonfle votre site WordPress et peut diluer votre budget de crawl. Soyez impitoyable. Cela dit, ne supprimez jamais une URL qui a des backlinks externes, même si la page elle-même est mauvaise -- 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.GeneratePress for its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.

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 un contenu simple et sans types de contenu personnalisés ? 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 avec des CPT, des taxonomies complexes, ou une empreinte SEO existante significative -- engagez un développeur. Le coût de corriger une migration ratée est toujours plus élevé que le coût de bien la faire la première fois.

---

La migration elle-même, c'est peut-être 40% du travail. Les 60% restants, c'est l'infrastructure SEO que vous construisez autour -- le mappage, les redirections, la surveillance, la patience d'observer les données pendant 30 jours avant de crier 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 bricolées à peine thématisées conserver chaque classement parce que la carte d'URL était minutieuse.

Faites bien les trucs chiants. Le reste a tendance à suivre.

< BACK