Migrer de WordPress vers EmDash : les redirections d'abord

Une migration ne se juge pas le jour de la bascule, mais six mois après, sur le trafic conservé. Et ce qui décide de ce résultat n’est presque jamais le transfert du contenu — qui prend une journée — mais le traitement des URL, des redirections et des médias.

L’ordre de ce guide reflète cet ordre de priorité : l’inventaire d’abord, le contenu ensuite.

Étape 0 : l’inventaire, avant de toucher à quoi que ce soit

C’est la seule étape qu’on ne peut pas rattraper après coup.

Exporter la liste complète des URL du site WordPress. Trois sources à croiser, parce qu’aucune n’est complète seule :

le sitemap XML, qui donne ce que WordPress considère comme publiable ;
les pages indexées connues de Search Console, qui incluent souvent des URL oubliées ;
les pages qui reçoivent des liens entrants, que le sitemap ignore et qui sont les plus précieuses.

Cette troisième liste est celle qu’on oublie, et c’est elle qui coûte le plus cher quand elle manque.

Relever les motifs d’URL. WordPress produit, selon les réglages, des adresses en /2019/03/mon-article/, en /categorie/mon-article/, ou en /mon-article/. À quoi s’ajoutent les archives de catégories, d’étiquettes, d’auteurs et de dates, les pages de pagination, et les pages de pièces jointes.

Décider quoi conserver. Toutes ces URL n’ont pas la même valeur. Une archive d’étiquette sans trafic ni lien entrant peut mourir ; une page d’article qui reçoit des visites doit survivre, à l’identique ou par redirection.

Étape 1 : la table de correspondance

C’est le livrable central de la migration. Un tableau à deux colonnes : ancienne URL, nouvelle URL.

Trois principes.

Conserver l’URL à l’identique quand c’est possible. La meilleure redirection est celle qu’on n’a pas à faire. Si vos articles sont en /mon-article/, gardez ce motif : la structure d’EmDash le permet sans difficulté.

Une redirection permanente, jamais une temporaire. Le code 301 transmet l’historique ; le 302 dit au moteur que l’ancienne adresse reviendra.

Pas de chaîne de redirections. Ancienne URL vers nouvelle URL, en un saut. Une chaîne de trois redirections perd du signal et ralentit tout le monde. Si vous aviez déjà des redirections dans WordPress, aplatissez-les : l’origine la plus ancienne doit pointer directement vers la destination finale.

Le cas particulier à traiter explicitement : les archives que vous supprimez. Une archive d’étiquette sans valeur ne se redirige pas vers l’accueil — cette redirection massive vers la racine est mal interprétée. Elle se redirige vers la page de rubrique la plus proche, ou elle renvoie un 410 assumé.

Étape 2 : les médias

Le poste le plus volumineux, et celui où les liens se cassent silencieusement.

WordPress stocke ses fichiers sous /wp-content/uploads/2023/05/photo.jpg, et ce chemin est écrit en dur dans chaque article. Deux stratégies.

Conserver l’arborescence. On téléverse les fichiers en gardant le chemin /wp-content/uploads/.... Les articles n’ont rien à réécrire, les liens externes qui pointent vers une image continuent de fonctionner. C’est moins élégant, et c’est beaucoup plus sûr.

Réorganiser. On adopte une arborescence propre et on réécrit les chemins dans le contenu. Plus propre, mais tout lien externe vers un média est cassé, et il faut être exhaustif dans la réécriture.

Sur un site qui a de l’historique, la première option gagne presque toujours. Le fonctionnement du pipeline média côté EmDash — déclinaisons, formats, génération à la demande — est décrit dans notre article sur les images et médias dans EmDash.

Les vignettes ne se transfèrent pas. WordPress génère plusieurs tailles par image ; EmDash les régénère à la demande. On ne transfère que les originaux, ce qui divise généralement le volume par trois ou quatre.

Étape 3 : le contenu

C’est l’étape la plus rapide, et celle qui inquiète le plus à tort.

Exporter au format natif WordPress, pas en HTML rendu. L’export conserve les relations, les catégories, les étiquettes, les dates et les auteurs.

Nettoyer avant d’importer, pas après. Les shortcodes de l’ancien thème, les blocs de constructeur de page et les scripts inline n’ont aucun sens dans EmDash : ils apparaîtront tels quels dans le texte. Un passage de nettoyage sur l’export, avant import, évite de reprendre trois cents articles à la main.

Vérifier les liens internes. Ils pointent vers les anciennes URL absolues. S’ils sont conservés à l’identique, tout va bien ; sinon, ils doivent être réécrits en même temps que le contenu — sans quoi chaque lien interne du site passera par une redirection.

Contrôler un échantillon avant d’importer tout. Dix articles représentatifs : un avec un tableau, un avec une galerie, un très long, un très ancien. C’est là qu’apparaissent les surprises de formatage.

Étape 4 : la bascule

L’ordre compte.

Monter le site EmDash complet sur une adresse de préproduction, avec son contenu et ses médias.
Charger la table de redirections et la tester ligne par ligne sur la préproduction.
Vérifier : un échantillon d’articles, la page d’accueil, les pages de rubrique, le formulaire de contact, le flux RSS.
Basculer le DNS.
Retester les redirections en production, parce qu’une configuration de préproduction n’est jamais tout à fait celle de la production.
Soumettre le nouveau sitemap dans les outils de webmaster.
Garder l’ancien site accessible quelque part pendant quelques semaines, hors ligne mais restaurable.

Cette dernière précaution suppose une sauvegarde complète et testée des deux côtés — la méthode est dans notre article sur sauvegarder et restaurer un site EmDash.

Les six semaines qui suivent

Une migration réussie se surveille, elle ne se déclare pas.

Semaine 1 : contrôler quotidiennement les erreurs 404. Chaque 404 sur une URL qui recevait du trafic est une ligne manquante dans la table de redirections, et elle s’ajoute immédiatement.

Semaines 2 à 4 : une baisse de trafic de 10 à 20 % est fréquente et se résorbe. Une baisse de 50 % signale un problème structurel — redirections absentes, blocage d’indexation, ou contenu tronqué à l’import.

Semaine 6 : le trafic doit être revenu à son niveau d’avant, ou l’avoir dépassé. Si ce n’est pas le cas, reprendre l’inventaire des URL : il manque quelque chose dans la table.

Ce que la migration fait gagner

Il faut être honnête sur le motif : on ne migre pas pour le plaisir de migrer.

Ce qu’on gagne en passant d’un WordPress chargé d’extensions à un site statique : un temps de réponse divisé par plusieurs, une surface d’attaque réduite à presque rien, et la fin des mises à jour hebdomadaires d’extensions. Le modèle de permissions qui rend cette réduction possible est décrit dans notre article sur les limites du bac à sable des plugins.

Ce qu’on perd : l’écosystème d’extensions de WordPress, et la facilité de trouver quelqu’un qui connaît déjà l’outil. Sur un site éditorial, l’échange est largement favorable ; sur un site qui repose sur trois extensions métier très spécifiques, il faut vérifier l’équivalent avant de s’engager.

En résumé

Le contenu se migre en une journée. Les redirections font la migration. Consacrez-leur les trois quarts du temps, et gardez le tableau des correspondances comme document de référence : c’est lui qu’on rouvrira dans six mois quand une URL oubliée refera surface.