Corriger le SEO après une migration de WordPress vers Astro : chaînes de redirections, sitemaps et nettoyage GSC
Après une migration de WordPress vers Astro, votre site se construit plus vite, se charge plus vite et coûte moins cher à héberger. Mais si vos URLs de blog ont changé pendant la migration — par exemple, de /post-slug/ à /insights/post-slug — vous avez probablement des problèmes SEO qui ne se manifestent que plusieurs semaines plus tard, lorsque Google finit de recrawler votre site.
Google Search Console commencera à envoyer des e-mails au sujet de « Duplicate, Google chose different canonical than user » et de « Not found (404) validation failed ». Vos pages les plus performantes risquent de perdre leur link equity à cause de sauts de redirection inutiles. Et vous avez peut-être deux sitemaps en concurrence l'un avec l'autre sans même le savoir.
Ce guide explique comment identifier et corriger ces problèmes. Nous les avons tous rencontrés lors de notre propre nettoyage SEO post-migration WordPress vers Astro, et nous avons documenté les correctifs ici.
Ce dont vous aurez besoin
- Un accès SSH à votre serveur (configuration nginx)
- Un accès Google Search Console pour votre propriété
curlinstallé en local- Un outil d'analytics (nous utilisons Plausible auto-hébergé)
Ce que ce guide permet de corriger
- Les chaînes de redirections multi-sauts (2 redirections ou plus) ramenées à des 301 en un seul saut
- Les sitemaps concurrents consolidés en une seule source générée automatiquement
- Les pages noindex supprimées du sitemap
- Les propriétés GSC obsolètes et les anciens sitemaps WordPress nettoyés
- La confusion autour des canonicals entre les anciennes et les nouvelles structures d'URL
Étape 1 : Diagnostiquer les chaînes de redirections
Vérifiez combien de redirections vos principales URLs traversent. Si vos URLs WordPress avaient des slashes finaux et que vos URLs Astro n'en ont pas, vous avez probablement une chaîne en deux sauts : une redirection supprime le slash, une autre ajoute le nouveau préfixe de chemin.
curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
-o /dev/null "https://yourdomain.com/old-post-slug/"
Si la sortie affiche Hops: 2, vous avez une chaîne de redirections. Exécutez cette commande pour vos cinq pages les plus visitées — ce sont celles pour lesquelles la perte de link equity est la plus critique.
Croisez les résultats avec vos analytics. Si vous voyez le même article apparaître sous plusieurs variantes d'URL (avec slash, sans slash, avec le nouveau préfixe), vos redirections ne consolident pas le trafic. Nous avons constaté que notre article le plus lu était réparti sur trois variantes d'URL dans Plausible, ce qui a confirmé le problème de chaîne.
Étape 2 : Configurer nginx pour des redirections en un seul saut
La règle nginx standard pour supprimer le slash final ressemble à ceci :
location ~ ^(.+)/$ { return 301 $1; }
Elle supprime bien le slash final, mais ne tient pas compte du changement de chemin de votre blog. La requête atteint ensuite une seconde règle qui redirige /slug vers /insights/slug. Deux sauts.
Remplacez-la par une règle tenant compte du blog, qui vérifie si le slug correspond à un article et redirige directement vers l'URL finale :
# Slugs de blog avec slash final — saut direct vers /insights/
location ~ ^/([^/]+)/$ {
set $slug $1;
if (-f /usr/share/nginx/html/insights/$slug/index.html) {
return 301 https://yourdomain.com/insights/$slug;
}
return 301 https://yourdomain.com/$slug;
}
# Chemins multi-segments — on supprime juste le slash
location ~ ^(.+)/$ { return 301 $1; }
La première règle gère les slugs à la racine (vos anciennes URLs WordPress). Elle vérifie si une page correspondante existe dans /insights/ et redirige directement vers celle-ci. Les chemins hors blog passent à la règle générique de suppression du slash. Après le déploiement, vérifiez :
curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
"https://yourdomain.com/your-top-post-slug/"
# Attendu : Hops: 1
Étape 3 : Consolider les sitemaps
Vérifiez si vous avez plus d'un sitemap. Un scénario courant après une migration : un fichier sitemap.xml statique créé manuellement lors du déménagement, ainsi qu'un sitemap-index.xml généré automatiquement par l'intégration @astrojs/sitemap d'Astro.
# Vérifier les deux curl -sI "https://yourdomain.com/sitemap.xml" | head -1 curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
Si les deux retournent 200, vous avez des sitemaps concurrents. Vérifiez lequel est référencé dans le robots.txt :
curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap
La solution : supprimez le fichier sitemap.xml statique de votre répertoire public/, mettez à jour le robots.txt pour référencer sitemap-index.xml, et laissez l'intégration Astro tout gérer. Les nouveaux articles apparaîtront automatiquement à chaque build.
Vérifiez également si le sitemap statique contient des pages noindex. Si votre sitemap.xml liste des pages comme /legal ou /privacy-policy qui portent la balise <meta name="robots" content="noindex">, vous envoyez des signaux contradictoires à Google. Le sitemap généré automatiquement par @astrojs/sitemap peut être configuré avec des règles de filtrage pour exclure correctement ces pages.
Étape 4 : Nettoyer Google Search Console
Ouvrez GSC et vérifiez deux choses : les propriétés et les sitemaps.
Propriétés : Si vous avez à la fois une propriété de domaine (sc-domain:yourdomain.com) et une propriété de préfixe d'URL (https://www.yourdomain.com/), vous recevez des alertes en double pour les mêmes problèmes. Choisissez-en une. Si vos sous-domaines sont des projets distincts, la propriété de préfixe d'URL est plus propre — elle ne rapporte que le trafic en production.
Sitemaps : Allez dans Indexation → Sitemaps. Supprimez les anciens sitemaps WordPress encore enregistrés (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml, etc.). Soumettez votre nouveau sitemap-index.xml comme seul sitemap.
Validation des 404 : Allez dans Indexation → Pages → « Not found (404) » et vérifiez quelles URLs sont listées. S'il s'agit d'anciens chemins WordPress qui n'existent plus et ne devraient pas exister (pages produit WooCommerce, pages auteur, URLs de flux), ils seront désindexés avec le temps. S'il s'agit d'articles de blog qui devraient être redirigés, vos règles nginx nécessitent une mise à jour. Après avoir corrigé les redirections, cliquez sur « Valider la correction » pour déclencher un recrawl.
Étape 5 : Tout vérifier
Exécutez ces vérifications après avoir déployé vos correctifs :
# 1. Chaînes de redirections résolues
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
-o /dev/null "https://yourdomain.com/your-top-post/"
# Attendu : Hops: 1, URL ends in /insights/your-top-post
# 2. robots.txt pointe vers le sitemap généré
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Attendu : sitemap-index.xml
# 3. L'ancien sitemap statique retourne 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Attendu : 404
# 4. Le sitemap généré retourne 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Attendu : 200
# 5. Le non-www redirige vers www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
"https://yourdomain.com/insights"
# Attendu : 301 https://www.yourdomain.com/insights
Combien de temps avant que Google ne s'aligne
Les redirections en un seul saut prennent effet immédiatement pour les nouveaux crawls. Les modifications de sitemap sont prises en compte en quelques jours. La confusion autour des canonicals — où Google préfère l'ancienne URL à la nouvelle — prend plus de temps à se résorber. Google traite la balise <link rel="canonical"> comme une indication, non comme une directive. Si l'ancienne URL dispose de davantage de backlinks et d'un historique de clics plus fourni, Google peut continuer à la choisir comme canonical pendant plusieurs semaines.
La combinaison de redirections propres, d'un sitemap unique faisant autorité et d'une propriété GSC consolidée envoie à Google le signal le plus clair possible. Dans notre cas, nous avons constaté que les avertissements « Duplicate canonical » commençaient à diminuer deux semaines après le déploiement de ces correctifs.
Nous gérons régulièrement ce type de migrations dans le cadre de nos travaux de performance et de migration WordPress. Si vous faites face à des problèmes SEO post-migration, contactez-nous.