Migrer de WordPress sans perdre ses URL : les redirections

Une migration réussit ou échoue sur un seul point : est-ce que les anciennes adresses répondent encore. L’import WordPress d’EmDash produit une carte de redirections après l’analyse, sous forme de JSON, et cette carte est le document le plus important de l’opération. Elle ne s’applique pas toute seule : il faut la porter là où les requêtes arrivent, la compléter des formes d’URL qu’elle n’a pas vues, et surveiller ce qui tombe malgré tout en 404.

Cet article prolonge le tutoriel de migration de WordPress vers EmDash, qui couvre les trois méthodes d’import et la conversion du contenu. Il est vérifié contre la documentation officielle au 23 août 2026, sur la ligne de version 0.34.x.

La carte que l’import vous donne

À la fin de l’import, EmDash produit une carte qui associe chaque ancienne adresse à sa nouvelle, et traite les flux séparément :

{
  "redirects": [
    { "from": "/?p=123", "to": "/posts/hello-world" },
    { "from": "/2024/01/hello-world/", "to": "/posts/hello-world" },
    { "from": "/category/news/", "to": "/categories/news" }
  ],
  "feeds": [
    { "from": "/feed/", "to": "/rss.xml" },
    { "from": "/feed/atom/", "to": "/atom.xml" }
  ]
}

Trois choses méritent d’être remarquées dans cet extrait, parce qu’elles décident du travail qui reste.

D’abord, une même page a plusieurs anciennes adresses. L’identifiant brut /?p=123 et l’adresse à permaliens /2024/01/hello-world/ pointent tous deux vers la même entrée : les deux doivent être redirigées, car les deux ont pu être indexées ou partagées. Ensuite, la barre oblique finale est présente du côté WordPress, qui la sert par défaut, alors que votre nouveau site ne la sert peut-être pas — c’est une source classique de redirections manquées. Enfin, les flux ne sont pas des pages : /feed/ doit atterrir sur votre flux réel, sans quoi les agrégateurs abonnés décrochent silencieusement.

Conservez ce fichier dans votre dépôt, avec la date de la migration. C’est lui qu’on rouvrira dans six mois quand une vieille adresse remontera dans les journaux.

Où appliquer la carte

La documentation d’EmDash cite trois emplacements, et le choix n’est pas indifférent.

Emplacement	Quand le préférer	Limite
Règles de redirection Cloudflare	Le trafic est déjà derrière Cloudflare	Configuration hors du dépôt, donc hors du contrôle de version
Configuration de redirection de l’hébergeur	Déploiement Node ou plateforme d’hébergement	Syntaxe propre à chaque hébergeur
Option `redirects` d’`astro.config.mjs`	On veut les redirections dans le code, versionnées	S’applique au site, pas aux requêtes interceptées en amont

La règle qui simplifie la décision : plus la redirection est traitée tôt dans la chaîne, moins elle coûte. Une règle au niveau du réseau de diffusion répond sans réveiller l’application. À l’inverse, une redirection déclarée dans la configuration Astro vit dans le dépôt, se relit, se revoit en revue de code et ne se perd pas lors d’un changement de compte d’hébergement. Sur un petit volume, la lisibilité vaut mieux que la microseconde gagnée.

Ce qui est déconseillé dans tous les cas : disperser la carte entre les trois emplacements. On ne sait plus alors quelle règle s’applique, et le débogage d’une chaîne de redirections devient un jeu de piste.

Le moteur de redirections d’EmDash

EmDash n’a pas besoin d’un service externe pour cela : le cœur gère des règles de redirection en base, avec un journal des adresses introuvables, et l’administration en propose un écran. La documentation publique ne détaille pas encore cet écran au 23 août 2026 — vérifiez son état sur votre version —, mais le comportement du moteur, lui, est net.

Les statuts acceptés. Une règle porte un statut de redirection — 301, 302, 307 ou 308 — ou un statut terminal, servi directement sans destination : 410 pour une page volontairement supprimée, 451 pour une indisponibilité d’ordre légal. Le statut par défaut d’une règle créée est 301, ce qui est le bon défaut : une migration est permanente.

Le 410 mérite un mot, parce qu’il est sous-employé. Il dit « cette page a été supprimée exprès », là où un 404 dit seulement « je ne trouve pas ». Les moteurs désindexent plus vite un 410. Pour les pages WordPress que vous ne reprenez pas — archives d’auteur vides, pages de pièces jointes, brouillons publiés par accident —, un 410 est plus honnête et plus efficace qu’une redirection vers l’accueil.

Les motifs. Les règles acceptent la syntaxe de routes d’Astro : [param] pour un segment nommé, [...reste] pour un segment attrape-tout. Une seule règle traite ainsi une famille entière d’adresses.

/old-blog/[...path]  →  /blog/[...path]

C’est le mécanisme qui évite d’écrire trois mille règles pour trois mille articles quand la transformation est régulière. Les motifs sont compilés en expressions régulières internes : vous ne fournissez pas d’expression régulière vous-même, ce qui écarte toute une classe de mauvaises surprises.

La détection de boucles. Le moteur vérifie qu’une règle ne crée pas de boucle avant de l’accepter, et sait signaler les boucles existantes dans la liste. C’est une protection utile au moment précis où l’on est le plus susceptible d’en fabriquer une : quand on corrige à la main une carte générée automatiquement.

Les formes d’URL que la carte ne couvre pas toujours

L’import voit ce qui est dans l’export. Il ne voit pas ce que votre site servait par ailleurs. Voici les familles à vérifier une par une, avant de considérer la migration terminée.

Les paginations d’archives : /page/2/, /category/news/page/3/. Elles sont souvent indexées et n’ont pas d’équivalent direct.
Les archives d’auteur et de date : /author/marie/, /2024/, /2024/01/. Décidez si vous les recréez ou si vous les marquez supprimées.
Les pages de pièces jointes, propres à WordPress, qui créent une page par fichier téléversé. Elles n’ont pas d’équivalent et sont de bonnes candidates au 410.
Les chemins de fichiers médias : /wp-content/uploads/…. Si vos images étaient liées depuis l’extérieur, ces adresses doivent aboutir, ce qui suppose de rediriger vers vos nouvelles URL de médias.
Les restes d’extensions : plans de site XML à l’ancien emplacement, points d’entrée de formulaires, pages de recherche indexées.
Les deux formes de barre oblique finale de chaque adresse, si l’ancien et le nouveau site ne la traitent pas pareil.

La méthode la plus fiable pour ne rien oublier ne consiste pas à réfléchir mais à lire : exportez les adresses connues de la Search Console et les journaux d’accès du serveur des trois derniers mois, dédupliquez, et confrontez cette liste à la carte. Ce qui n’y est pas est votre travail restant.

Après la bascule : le journal des 404

Aucune carte n’est complète le premier jour, et c’est normal. Ce qui n’est pas normal, c’est de ne pas le savoir. EmDash enregistre les adresses introuvables et les impacts de redirection sur les requêtes publiques, et expose de quoi les consulter et les résumer.

La conduite des deux semaines qui suivent la migration tient en une boucle simple. Chaque jour, on regarde les adresses les plus demandées qui répondent 404, on décide pour chacune : elle a une destination évidente, on crée une redirection 301 ; elle n’en a pas, on marque un 410 ; c’est un robot qui cherche une faille WordPress — les tentatives sur /wp-login.php arrivent en masse et pour toujours —, on ne fait rien.

Trois règles de conduite valent d’être posées, parce qu’elles se violent facilement sous la pression du moment.

Une redirection par adresse, en un seul saut. Une chaîne de trois redirections dilue le signal et ralentit tout le monde. Quand vous corrigez une règle, corrigez la destination finale, n’empilez pas une règle sur l’autre.

Ne redirigez pas tout vers l’accueil. C’est le réflexe qui semble propre et qui coûte le plus : les moteurs traitent ces redirections comme des 404 déguisés, et le lecteur qui cherchait un article précis n’a aucune raison de rester. Sans destination pertinente, le 410 est le bon choix.

Les redirections ne se suppriment pas. Une règle mise en place pour une migration reste en place indéfiniment : des liens externes vieux de dix ans pointent encore sur les anciennes adresses. C’est aussi pour cela qu’une carte versionnée dans le dépôt vaut mieux qu’une configuration cliquée dans une console.

Vérifier, avant de couper l’ancien site

La vérification se fait avant la bascule du nom de domaine, sur l’environnement de préproduction, et elle est mécanique. Prenez une trentaine d’adresses représentatives — les dix plus visitées, quelques archives, une pagination, un flux, un média lié depuis l’extérieur — et contrôlez pour chacune trois choses : le statut renvoyé est bien 301, la destination est bien la bonne page, et cette destination répond 200 sans redirection supplémentaire.

Gardez l’ancien site accessible pendant la période de recouvrement si votre hébergement le permet : c’est le seul moyen de comparer une page à l’original quand un doute surgit. Et ne supprimez ni l’export WordPress ni la carte de redirections après la migration ; ce sont les deux pièces qu’on regrette d’avoir jetées. Le raisonnement d’ensemble du passage d’une plateforme à l’autre est détaillé dans notre dossier de WordPress vers EmDash, et la comparaison fonctionnelle des deux CMS dans le guide EmDash face à WordPress.

Questions fréquentes

L’import WordPress crée-t-il les redirections automatiquement ?

Il produit une carte de redirections après l’analyse, mais il ne l’applique pas à votre place. Vous portez cette carte dans les règles de votre réseau de diffusion, dans la configuration de redirection de l’hébergeur, ou dans l’option de redirections de la configuration Astro. Tant que ce report n’est pas fait, les anciennes adresses répondent 404.

Quel statut utiliser pour les pages qu’on ne reprend pas ?

410 plutôt que 404 ou qu’une redirection vers l’accueil. Le 410 déclare une suppression volontaire et les moteurs désindexent plus vite qu’avec un 404. EmDash accepte ce statut comme statut terminal d’une règle, servi directement et sans destination.

Faut-il rediriger les adresses avec et sans barre oblique finale ?

Oui, si les deux sites ne la traitent pas de la même façon. WordPress sert ses permaliens avec une barre finale par défaut ; si votre nouveau site sert sans, chaque adresse indexée existe sous une forme que vos règles doivent reconnaître. La carte générée conserve la forme WordPress d’origine, ce qui rend le point facile à vérifier.

Combien de temps faut-il garder les redirections ?

Indéfiniment. Les liens externes ne se mettent pas à jour, et une adresse citée dans un article ou un signet continue d’être suivie des années plus tard. C’est un argument de plus pour garder la carte dans le dépôt, versionnée, plutôt que dans une console d’hébergement dont on peut changer.