Migrer WordPress vers Astro sans casser le SEO

Ce qui casse vraiment le SEO dans une migration Astro

Une migration WordPress vers Astro conserve son référencement quand les URL restent strictement identiques, quand les redirections nécessaires sont des 301 côté serveur, et quand le déploiement est découpé en phases (pages d’abord, articles ensuite). Ce ne sont pas les performances d’Astro qui protègent le trafic, c’est la cartographie des URL faite avant la première ligne de code.

Le contexte : un comparateur de 600 articles

Mai 2026. Chez Peechy, on migre un comparateur télécom français vers Astro déployé sur Netlify. Le site tourne sur WordPress, avec environ 600 articles indexés et un ensemble de pages de comparaison qui font l’essentiel du chiffre d’affaires en affiliation.

On nous fournit 21 pages HTML statiques, produites en amont, comme base du nouveau front. Le SEO du site est son actif principal : chaque URL de comparaison est positionnée sur des requêtes commerciales. Perdre trois positions, c’est perdre une part du revenu du mois. Le cahier des charges tenait en une phrase : rien ne doit bouger dans les SERP.

Cas représentatif d’un problème classique : le site fonctionne, mais son code n’est plus tenable et sa vitesse plafonne. Personne ne veut d’une refonte qui reparte de zéro.

Le problème initial : 141 offres codées en dur

En ouvrant les 21 pages HTML, on trouve le vrai chantier. Chaque page code en dur sa propre liste d’offres. L’accueil affiche 141 offres écrites directement dans le HTML. La page comparateur de forfaits en affiche 56, elles aussi écrites dans le fichier de la page.

Ce n’est pas une bizarrerie de développeur, c’est le résultat naturel d’un site qui a grossi page par page pendant des années. Le coût est simple à décrire : quand un opérateur change un prix, il faut le corriger dans autant de fichiers que de pages qui l’affichent. En pratique, personne ne le fait partout. Les pages divergent, et le comparateur affiche des prix contradictoires selon l’endroit où l’utilisateur atterrit.

Deuxième problème : le lien entre les URL WordPress en production et les nouveaux fichiers Astro n’existait pas. Les 21 pages avaient leurs propres noms de fichiers, sans rapport avec les slugs indexés par Google.

Les quatre décisions structurantes

1. Aligner les slugs sur les URL WordPress en production

Avant tout développement, on a repris la liste des URL réellement en production et on a nommé les routes Astro pour qu’elles produisent exactement les mêmes chemins. Pas une URL réécrite « pour faire plus propre ».

C’est l’étape que Google appelle explicitement le mapping préalable dans sa documentation de migration : préparer le nouveau site, préparer une correspondance des URL actuelles vers leur nouveau format, puis seulement configurer les redirections source : Google Search Central.

Quand les URL sont identiques, il n’y a rien à rediriger. C’est le scénario le plus sûr, et c’est celui qu’on cherche en priorité. Astro le rappelle d’ailleurs dans sa propre documentation de migration depuis WordPress : garder le même domaine chez l’hébergeur pour conserver l’URL du site source : Astro Docs.

Une redirection 301 est une réponse HTTP indiquant qu’une ressource a été déplacée définitivement vers l’adresse donnée dans l’en-tête Location. Les moteurs attribuent alors à la nouvelle URL les liens pointant vers l’ancienne, ce qui transfère la valeur de classement source : MDN, 2026. Le comportement est normé par la RFC 9110, qui définit aussi le 308, à préférer quand la méthode HTTP (un POST de formulaire, par exemple) doit être préservée.

2. Une source unique pour les offres

Les 141 offres de l’accueil et les 56 du comparateur forfaits ont été consolidées dans un seul fichier de données. Chaque page ne code plus ses offres : elle filtre la source commune selon son critère (type d’offre, opérateur, gamme de prix).

Résultat concret : un prix se corrige à un endroit et se propage partout. C’est exactement la logique de source unique de vérité que les éditeurs de CMS headless défendent, avec l’argument de la diffusion multicanale sans duplication du travail source : Sanity, 2026.

Un site headless désigne une architecture où le CMS ne sert que les données, via API, pendant qu’un front séparé se charge du rendu. Astro documente les deux voies avec WordPress : l’API REST native, ou GraphQL via WPGraphQL source : Astro Docs.

3. Laisser les images sur l’ancien domaine

Décision qui surprend souvent : on n’a pas migré les images au premier déploiement. Elles sont restées servies depuis l’ancien domaine jusqu’à validation du nouveau site.

La raison est le risque. Déplacer plusieurs milliers de fichiers médias en même temps que le rendu, c’est mélanger deux sources de panne. Si une image casse, on ne sait plus si c’est le chemin, le déploiement ou la migration. En gelant les médias, on isole une seule variable : le rendu HTML. La bascule des images se fait après, tranquillement, avec ses propres redirections.

4. Phaser : pages d’abord, articles ensuite

Les 21 pages sont passées en phase 1. Les articles ont suivi en phase 2, avec exactement les mêmes URL qu’avant.

Ce phasage n’est pas une prudence d’agence, c’est une recommandation de Google : découper le déplacement en étapes plus petites quand cela a du sens pour le site source : Google Search Central. Sur un site à 600 articles, ça change tout : si un problème d’indexation apparaît en phase 1, il touche 21 URL, pas 621.

Après la bascule : ce qu’on surveille

Google demande explicitement de suivre le trafic sur les anciennes et les nouvelles URL en parallèle. On garde donc les deux propriétés Search Console actives, on compare les impressions jour par jour, et on regarde la courbe d’indexation des nouvelles pages.

Un point rassure peu de monde et devrait : après une 301 correcte, Google peut continuer à afficher occasionnellement l’ancienne URL comme nom alternatif de l’URL canonique, même quand la nouvelle est indexée source : Google Search Central. Voir une vieille URL en SERP trois semaines après la bascule n’est pas un échec, c’est documenté.

Ordre de grandeur pour se situer, à titre illustratif : sur ce type de migration à URL constantes, la réindexation complète d’un site de plusieurs centaines de pages s’étale sur quelques semaines, pas quelques jours. On ne juge rien avant un mois de données.

Le modèle qui suit : mettre à jour en parlant

La conséquence de la source unique de données dépasse la technique. Quand les offres vivent dans un fichier structuré et non dans le HTML, mettre à jour un prix ne demande plus de back-office. Un assistant IA connecté au dépôt lit le fichier, applique la modification demandée en langage naturel, ouvre une modification et déclenche le déploiement.

C’est la suite logique du contenu structuré comme donnée : les workflows deviennent automatisables dès que le contenu n’est plus enfermé dans une page source : Sanity, 2026. Ce modèle ne convient pas à tout le monde, et je ne le vends pas comme universel. Il fonctionne bien quand le contenu est très structuré, comme un catalogue d’offres. Il fonctionne moins bien sur de l’éditorial libre, où un vrai éditeur reste plus confortable, et c’est pour ça qu’un WordPress headless garde du sens dans certains cas.

Les cinq points à retenir

1. La migration se joue avant le code : liste des URL en production, mapping, puis développement. Pas l’inverse.
2. Une URL conservée vaut mieux qu’une URL redirigée. Une URL redirigée vaut mieux qu’une URL perdue.
3. Isolez les variables : ne déplacez pas les images et le rendu dans le même déploiement.
4. Sortez les données dupliquées des pages avant la migration, pas après. C’est le moment où c’est le moins cher.
5. Phasez, et gardez les deux Search Console ouvertes pendant au moins un mois.

Si vous préparez ce chantier, la question à poser à votre prestataire n’est pas « en combien de temps ». C’est : montrez-moi la liste des URL actuelles et leur correspondance dans le nouveau site. Sans ce document, la migration n’a pas commencé. Pour le reste du cadrage, la checklist de migration d’agence à agence et le guide sur changer d’hébergeur sans perdre son référencement couvrent les accès et les DNS, et le comparatif Netlify ou Vercel tranche la question de l’hébergement du front.