La plupart des guides de transfert d’un blog WordPress te promettent une méthode « sans stress ». Tu exportes le contenu en XML, tu importes ailleurs, tu rediriges les URLs, et le tour est joué. On a démonté cette promesse sur trois migrations lourdes, et à chaque fois le même résultat : une perte de trafic organique de 30 à 45 % dans les deux semaines, des URLs fantômes en Search Console, et un TTFB multiplié par trois que personne n’avait vu venir.
Le problème n’est pas WordPress. C’est le script de migration qu’on nous vend comme un couteau suisse alors qu’il oublie la moitié des signaux que Googlebot consomme.
L’export XML ignore vos signaux d’indexation réels
Quand tu exportes un blog WordPress avec l’outil natif, tu obtiens un fichier WXR qui contient les articles, les pages, les catégories et les auteurs. Ce qu’il ne contient pas, c’est la manière dont ces contenus sont réellement crawlés. Les directives de robots.txt spécifiques à certaines sections, les en-têtes X-Robots-Tag ajoutées par le CDN, les règles de canonicalisation qui ne sont pas stockées en base mais injectées par le thème ou un plugin SEO. Le jour de la bascule, ces éléments disparaissent.
On a observé un cas précis : un blog e-commerce de 800 articles, migré vers un SSG. L’export XML contenait bien toutes les URLs. Mais le nouveau site a recalculé les canoniques automatiquement, et 200 fiches produit se sont retrouvées en canonical vers la page d’accueil, simplement parce que le nouveau template ne distinguait plus les variantes. Résultat : Google a déréférencé ces URLs en cinq jours. Le XML ne vous sauvera pas.
⚠️ Attention : Avant toute migration, ne vous fiez pas au fichier exporté. Faites un crawl complet de votre site actuel avec un outil comme Screaming Frog, et exportez la liste des URLs réellement indexées avec leurs en-têtes HTTP de réponse. C’est cette liste qui doit dicter votre mapping de redirections, pas le WXR.
La redirection one-to-one étouffe le budget de crawl
On entend souvent dire qu’il faut préserver chaque URL, rediriger l’ancienne vers la nouvelle, et Google s’y retrouvera. Sur un blog de 200 articles, ça passe. Sur un média de 5 000 URLs avec des archives de tags, des pages d’auteur et des paginations, c’est une hémorragie de crawl budget.
Rediriger une à une chaque URL génère une masse de réponses 301 que Googlebot va devoir suivre pendant des semaines pour mettre à jour son index. Pendant ce temps, le robot consomme votre quota de crawl sur des chemins morts plutôt que de découvrir vos nouveaux contenus. Sur une migration qu’on a auditée, le nombre de pages crawlées par jour a chuté de 40 % le mois suivant la migration, alors que le nouveau site était plus rapide.
Ce qui fonctionne mieux : identifier les URLs qui ont réellement du trafic ou des backlinks, et ne rediriger que celles-là. Les archives de tags sans lien externe ni impressions dans la Search Console, vous pouvez les laisser partir en 410, après avoir vérifié qu’elles ne trampent aucun maillage interne pertinent. Un sitemap XML propre sur le nouveau domaine fera le reste.
Changer la stack dynamique pour du statique n’améliore pas le LCP par magie
L’argument marketing qui vante le headless ou le statique comme solution miracle aux Core Web Vitals nous a coûté quelques nuits. On a vu un blog WordPress migré vers un générateur Headless avec une note Lighthouse qui passait de 65 à 95. Le client jubilait, jusqu’à ce que la Search Console remonte un LCP réel de 5,2 secondes sur mobile, soit 1,8 seconde de plus que l’ancien site.
La raison était simple : le rendu côté client était devenu dépendant d’un bundle JavaScript de 400 ko qui hydratait le contenu après le chargement initial. Lighthouse simulait un chargement statique, mais le navigateur réel bloquait le rendu du texte le plus long. Sans mesurer les métriques de terrain avant et après, on se berce d’illusions. Le passage d’un CPU serveur à une edge function peut aggraver le TTFB si la logique de cache n’est pas réglée finement.
Avant de migrer, instrumentez l’ancien site avec l’API CrUX ou le module Web Vitals. Relevez le p75 du LCP, du CLS, de l’INP sur mobile et desktop. Répétez la mesure après la mise en ligne définitive, pas sur un staging vide. Une régression de 300 ms sur une métrique de champ annule souvent les gains théoriques.
Réécrire les slugs pour faire « propre » détruit le patrimoine sémantique
Quand on transfère un blog, la tentation de normaliser les slugs est grande. Supprimer les stop words, raccourcir, aligner sur une nouvelle convention. Résultat : l’URL perd les termes qui faisaient l’ancre de liens entrants naturels. On a hérité d’un site où le slug /comment-choisir-sa-plateforme-ecommerce est devenu /plateforme-ecommerce. Le trafic longue traîne a fondu, parce que Google associait l’ancienne URL à la requête « comment choisir sa plateforme e-commerce » avec une correspondance quasi exacte.
Si vous devez absolument changer les slugs, la redirection 301 n’est qu’une rustine. Appliquez-la en amont avec une règle de correspondance sémantique, pas une correspondance de chaîne. Regroupez les anciennes URLs qui partagent une même intention sous une nouvelle, en vérifiant que le contenu répond toujours au besoin. C’est plus long, mais ça évite le syndrome de la page orpheline.
Profiter de la migration pour tailler dans le gras
Une migration est le seul moment où vous pouvez supprimer du contenu sans que Google l’interprète comme une perte de qualité soudaine. En conditions normales, effacer 200 pages d’un coup envoie un signal négatif. Pendant un transfert, le changement d’URL principal et de structure atténue la perception de l’algorithme, à condition que vos redirections aillent vers des ressources pertinentes et que votre taux d’erreurs 404 ne dépasse pas 5 à 8 % du volume total d’URLs.
On a conseillé à un client éditorial de profiter de sa migration pour supprimer ses 300 « brèves » de 150 mots qui n’avaient jamais reçu un clic. Plutôt que de les rediriger une par une, il les a regroupées sous une page d’archives thématique. Le crawl budget économisé a été réalloué aux contenus piliers, et le taux d’indexation du nouveau site a grimpé plus vite que prévu.
Ce que le nouveau front-end change pour Googlebot
Quand vous quittez le rendu PHP traditionnel de WordPress pour une app React, Vue ou un générateur, Googlebot ne voit plus la même chose. Le DOM livré côté serveur peut être vide, ou partiel, si l’hydration est mal configurée. Les données structurées JSON-LD ajoutées par le plugin SEO disparaissent si vous ne les réinjectez pas dans le build. Et les balises meta robots que votre thème injectait automatiquement sur les pages de catégorie risquent de ne plus exister.
On a débuggé un site JAMstack fraîchement migré qui ne faisait plus apparaître les étoiles de notation dans les résultats de recherche, juste après la bascule. La cause : le composant d’étoiles était rendu côté client, et le JSON-LD n’était pas dans le HTML statique. Ces détails ne sont pas dans l’export XML. Ils sont dans l’ancien DOM. Inspectez les sources d’une dizaine de templates avant de coder quoi que ce soit.
Un mauvais choix de state management peut aussi ralentir la réhydratation et dégrader l’interactivité sur des pages qu’on croyait légères. Des approches minimales comme Zustand limitent la surcouche d’abstraction et facilitent un chargement progressif sans exploser le main thread, ce qui devient critique dès que votre blog dépasse le millier de visites mensuelles.
Questions fréquentes
Faut-il transférer les images du blog ou les laisser sur l’ancien CDN WordPress ?
Les laisser sur l’ancien CDN expose à des temps de chargement qui échappent à votre contrôle. Rapatriez-les sur le nouveau domaine, mais compressez-les au passage. N’appliquez pas de lazy-loading natif sur l’image de hero sans vérifier le LCP : elle a besoin d’une priorité de fetch haute.
La migration est-elle l’occasion de passer à un nom de domaine plus court ?
Changer de domaine pendant un transfert multiplie les risques : vous perdez l’autorité, les redirections sont plus complexes et la période de flottement est plus longue. Si vous y tenez, faites-le six mois avant ou après la migration technique, jamais en même temps.
Que faire des commentaires WordPress natifs après la migration ?
Les commentaires natifs alourdissent la page sans valeur SEO ajoutée. Exportez-les sous forme de contenu statique si leur modération est déjà close, ou basculez vers un système externe désactivable côté client. N’importez pas les formulaires dynamiques sans un pré-rendu serveur qui fournit le contenu aux robots.
