Si tu cherches à migrer WordPress vers EmDash sans perdre ton SEO, tu es au bon endroit. EmDash est présenté comme un « successeur spirituel » de WordPress, avec un modèle moderne (TypeScript, Astro, serverless, et une approche plugin beaucoup plus sandboxée). Sur le papier, c’est tentant.
Le piège, c’est de croire que « migration » veut dire export/import et basta. Côté Google, une migration, c’est un changement de plomberie. Et Google ne pardonne pas les fuites. Tu peux faire un site plus rapide, plus secure, plus clean… et te retrouver à regarder ton trafic fondre parce que tu as raté un détail d’URLs, de canonical, de sitemap, ou parce que tes pages ne renvoient pas le bon HTML au crawler.
Je te donne ici les 12 pièges qui font le plus mal dans une migration WordPress → EmDash, avec un protocole pré-prod et post-prod qui tient en vrai. Pas une migration « théorique ». Une migration qui ne casse pas ton business.
Avant la migration : fige une baseline, sinon tu vas déboguer dans le vide
Piège 1 : migrer sans inventaire des URLs qui comptent
Le truc le plus fréquent, c’est de migrer « tout le contenu » sans migrer « toutes les URLs ». En SEO, ce ne sont pas les articles qui rankent, ce sont des URLs précises, avec une structure précise, des trailing slashes parfois, des pages d’archives, des paginations, des médias, des vieilles pages qui ont encore des backlinks. Si tu n’as pas une liste propre de ce que Google connaît déjà, tu ne sauras même pas ce que tu as cassé.
Avant de toucher à quoi que ce soit, je veux un crawl du WordPress en prod (Screaming Frog, Sitebulb, ou n’importe quel crawler sérieux), une export des URLs qui reçoivent du trafic (Search Console + analytics), et une liste des pages qui ont des backlinks (si tu as accès à un outil type Ahrefs/Semrush, tant mieux, sinon tu fais sans). C’est ta « vérité » de départ.
Piège 2 : ne pas définir la règle du jeu côté indexation (préprod vs prod)
Une préprod accessible, c’est un grand classique. Et un jour tu te rends compte que Google a indexé ta version de staging, ou qu’un « noindex » traîne en prod parce que quelqu’un a copié la conf. Une migration, c’est exactement le moment où ces erreurs sortent du bois.
Ma règle est simple : la préprod doit être bloquée (auth, IP allowlist, ou au minimum un vrai verrouillage), et la prod doit être crawlable. Et surtout, tu prévois le moment où tu vérifies explicitement que tu n’as pas de X-Robots-Tag: noindex ou de meta robots qui te flingue tout le site après le switch.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
URLs WordPress : c’est là que tu gagnes ou perds la migration
Piège 3 : changer les permaliens « un peu » (et créer un autre site aux yeux de Google)
WordPress te laisse faire à peu près toutes les structures : /%postname%/, /%category%/%postname%/, des dates dans l’URL, des pages avec ou sans slash final, etc. Si ton EmDash sort des URLs différentes « parce que c’est plus joli », tu viens de requalifier une bonne partie de ton site. Google peut suivre… mais il va te faire repasser des étapes de confiance.
Mon avis (assumé) : tant que tu n’as pas une raison béton pour changer la structure, tu ne changes rien. Tu reproduis la structure existante. Tu te gardes les refontes d’URL pour plus tard, quand la migration est digérée et que tu peux absorber une baisse temporaire.
Piège 4 : faire des redirections 301 approximatives (ou des chaînes)
La redirection 301 n’est pas un « bonus ». C’est la colonne vertébrale de la migration. Mais une 301 mal fichue, c’est presque pire que pas de 301. Les chaînes (A → B → C) te mangent du crawl budget, ralentissent le passage des signaux, et génèrent des comportements bizarres côté bots. Les boucles (A → B → A) c’est le jackpot de la catastrophe.
Ce que je vise : une redirection en un saut, stable, déterministe, testée. Pas une pile de règles au fil de l’eau.
# Exemple : redirections en 1 saut via un mapping (à adapter à ton infra)
# Objectif : /ancien-slug/ => /nouveau-slug/ sans chaîne.
map $request_uri $redirect_to {
default "";
/mon-ancien-article/ /mon-ancien-article/; # idéalement identique si tu gardes les URLs
/categorie/ancien-slug/ /categorie/ancien-slug/;
/old-page/ /new-page/;
}
server {
if ($redirect_to != "") {
return 301 $scheme://$host$redirect_to;
}
}
Si tu es chez Cloudflare (ce qui est logique si EmDash t’attire), regarde aussi les Redirect Rules / Bulk Redirects. L’idée reste la même : un mapping clair, versionné, et une exécution sans surprises.
Host, canonical, sitemap : les détails qui font « je suis le même site »
Piège 5 : www/non-www, http/https, trailing slash… et les variantes qui se battent entre elles
Une migration est souvent le moment où tu « normalises » tout. Très bien. Mais Google déteste l’ambiguïté : si tu exposes plusieurs variantes accessibles (http ET https, www ET non-www, slash final ou pas), tu crées de la duplication et tu dilues les signaux. Le résultat n’est pas toujours une baisse immédiate. Parfois c’est plus vicieux : ça plafonne, ça oscille, ça indexe mal.
Tu dois choisir une version canonique du site (host + protocole + format d’URL) et t’y tenir. Les autres doivent rediriger en 301 en un saut, et tes liens internes doivent pointer directement vers la version canonique, pas vers une variante qui redirige.
Piège 6 : des canonical incohérents (ou générés à partir du mauvais host)
Le canonical, c’est ton « je déclare l’URL officielle ». Si tu migres et que tu te retrouves avec des canonical qui pointent encore vers l’ancien domaine, ou vers http au lieu de https, ou vers un host de preview, tu peux te retrouver à envoyer un signal contradictoire à Google. Et oui, j’ai déjà vu des migrations où le site était accessible, crawlable… mais Google refusait d’indexer proprement parce que les canonicals racontaient une autre histoire.
Sur un CMS moderne type EmDash (Astro, rendu server-side / build), tu peux être tenté de calculer des URLs à partir d’une variable d’environnement. C’est bien. Vérifie juste que cette variable est correcte en prod, et qu’elle ne dépend pas d’un header instable. Le canonical doit être boring. Stable. Prévisible.
Piège 7 : sitemap absent, incomplet, ou « lastmod » fantaisiste
Après migration, le sitemap est ton accélérateur. Mais beaucoup le sabotent. Soit il manque des types de pages importants (articles, pages, catégories), soit il liste des URLs qui redirigent, soit il met un lastmod sur toutes les URLs à la date du jour (ce qui ressemble vite à du bruit), soit il n’est pas déclaré dans robots.txt et jamais soumis dans Search Console.
Tu veux un sitemap propre, qui ne contient que des 200 indexables, et un lastmod qui reflète une vraie date de mise à jour du contenu, pas la date de déploiement. Et tu le soumets dans GSC juste après le switch, pour lancer la machine.
Contenu et meta : tu peux perdre du ranking sans avoir changé une ligne de texte
Piège 8 : perdre des morceaux de contenu « invisibles » mais SEO-critiques
Dans WordPress, le contenu n’est pas juste « le body ». Tu as des excerpts, des champs ACF, des blocs, des shortcodes, parfois des éléments injectés par des plugins (table des matières, FAQ, encarts). En migration, tu peux te retrouver avec des pages qui ont l’air ok à l’œil, mais qui ont perdu des sections que Google aimait bien, ou qui structurent le document (titres H2/H3, ancres).
EmDash vise une compatibilité fonctionnelle, mais ta migration réelle dépend de ton WordPress réel. Si ton site est un Frankenstein de plugins, tu dois identifier ce qui est « du contenu » et ce qui est « de la déco ». Et migrer au moins le premier, proprement.
Piège 9 : titles, meta descriptions, Open Graph… et un CTR qui s’effondre
On parle beaucoup de position, moins de CTR. Pourtant, perdre un title travaillé, une meta description cohérente, ou des balises sociales qui évitent des previews moches, ça peut te coûter des clics même à position identique. Et si tu as une marque un peu installée, tu le vois très vite sur les pages qui faisaient beaucoup d’impressions.
Vérifie que chaque page importante a un <title> unique, une meta description pas tronquée n’importe comment, et des balises Open Graph/Twitter Cards correctes. Ce n’est pas « du SEO gadget ». C’est du trafic.
Piège 10 : données structurées cassées (et rich results qui disparaissent)
FAQ, HowTo, Article, BreadcrumbList, Organization… si tu avais des données structurées via un plugin SEO WordPress, tu peux perdre ces blocs du jour au lendemain. Google ne te « punit » pas, mais tu peux perdre des enrichissements dans les SERP, donc de la visibilité, donc des clics.
Le bon réflexe : comparer l’ancien et le nouveau HTML pour quelques pages clés, et passer ça dans le test des résultats enrichis. Si tu n’avais pas de schema avant, ce n’est pas le moment de te lancer dans une usine à gaz. Mais si tu en avais, évite de le perdre pendant la migration.
Techniques vicieuses : pagination, médias, rendu HTML… là où les migrations se font humilier
Piège 11 : pagination, archives, tags, recherche interne… et l’explosion d’URLs inutiles
WordPress génère des pages d’archives (catégories, tags, auteurs, dates) et des paginations (/page/2/) qui, selon ton site, peuvent être précieuses ou juste du bruit. En migration, tu peux soit les supprimer et casser des URLs qui rankaient, soit les garder sans contrôle et créer une masse d’URLs faibles qui dilue ton crawl.
Ce que je fais en pratique : je décide. Certaines archives méritent de vivre et doivent être migrées avec leurs URLs et leurs titres. D’autres doivent être noindexées proprement. Et la recherche interne, c’est souvent un nid à paramètres et à contenu mince. Si tu la laisses indexable « par défaut », tu invites Google à crawler des milliers d’URLs sans valeur.
Piège 12 : servir un DOM joli, mais un HTML pauvre (et Google n’indexe pas ce que tu crois)
Celui-là est brutal, surtout quand on passe sur une stack moderne. Tu ouvres la page dans ton navigateur, tout est là, nickel. Sauf que le HTML initial renvoyé par le serveur est presque vide, et que les meta (title, description, canonical) sont injectées côté client. Résultat : certains crawlers voient une page « maigre », des canonicals absents, et ton indexation devient erratique.
Avec EmDash basé sur Astro, tu as les outils pour faire les choses proprement (SSR/SSG, rendu HTML complet). Mais tu dois quand même le vérifier. Pas au feeling. Avec des requêtes qui te montrent la réponse serveur, sans exécuter de JavaScript.
# Vérifie ce que le serveur renvoie VRAIMENT (pas ce que le navigateur reconstruit)
URL="https://example.com/mon-article/"
curl -sL "$URL" | sed -n '1,120p'
curl -sL "$URL" | grep -i -E "<title>|rel=\"canonical\"|og:title|application/ld\+json"Et oui, va aussi dans Search Console sur quelques URLs clés, avec « Inspecter l’URL » et « Afficher la page testée ». Si le rendu Googlebot ne ressemble pas à ce que tu crois servir, tu veux le savoir avant que ça devienne un problème de trafic.
Le protocole qui évite les surprises : crawl + diff avant, logs + GSC après
En pré-prod, je fais un crawl de l’ancien site et un crawl du nouveau (sur un domaine de preview ou une URL temporaire), puis je compare. Je ne compare pas « le nombre de pages ». Je compare des choses bêtes et méchantes : les codes HTTP, les canonicals, les titles, les H1, et surtout le mapping des URLs. Là, tu vois immédiatement les trous, les 404, les redirections en chaîne, les pages qui ont disparu.
Au moment du switch, je veux un monitoring des 404 et des 500, et je veux regarder ce que fait Googlebot. Pas besoin de fantasmer, c’est dans les logs. Est-ce qu’il tombe sur des boucles ? Est-ce qu’il passe son temps sur des URLs inutiles ? Est-ce qu’il crawl les sitemaps et suit les 301 correctement ? Dans Search Console, je surveille l’état d’indexation, les sitemaps, et la courbe de « Crawl stats ». Une chute d’exploration ou une explosion des « pages introuvables », ça se traite tout de suite. Pas trois semaines plus tard quand le trafic est déjà au sol.
Conclusion : EmDash peut être une super idée, mais la migration SEO ne se fait pas « à l’instinct »
La promesse d’EmDash est séduisante, surtout si tu en as marre de l’écosystème plugins WordPress et des risques que ça traîne. Mais côté SEO, Google se fiche de la beauté de ta stack. Il veut des URLs stables, des 301 propres, un HTML clair, et des signaux cohérents.
Si tu traites la migration comme un projet d’exécution (inventory → mapping → redirects → validation HTML → GSC/logs), tu peux migrer sans drame. Et après seulement, tu pourras te faire plaisir avec des changements plus ambitieux. D’abord, tu sauves le trafic. Ensuite, tu optimises.
