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 compile plus vite, se charge plus vite et coûte moins cher à héberger. Mais si vos URL 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 d’explorer à nouveau 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 passent peut-être par des sauts de redirection inutiles. Et vous maintenez peut-être deux sitemaps dont le contenu se recoupe 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’analyse d’audience (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 en double 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 entre les URL canoniques des anciennes et des nouvelles structures d’URL
Étape 1 : Diagnostiquer les chaînes de redirections
Vérifiez combien de redirections vos principales URL traversent. Si vos URL WordPress avaient des barres obliques finales et que vos URL Astro n’en ont pas, vous avez probablement une chaîne en deux sauts : une redirection supprime la barre oblique, 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 les sauts supplémentaires ont le plus d’importance.
Croisez les résultats avec vos données d’audience. Si vous voyez le même article apparaître sous plusieurs variantes d’URL (avec ou sans barre oblique finale, 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 nous a incités à effectuer la vérification des redirections décrite ci-dessus.
Étape 2 : Configurer nginx pour des redirections en un seul saut
La règle nginx standard pour supprimer la barre oblique finale ressemble à ceci :
location ~ ^(.+)/$ { return 301 $1; }
Elle supprime bien la barre oblique finale, 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://www.yourdomain.com/insights/$slug;
}
return 301 https://www.yourdomain.com/$slug;
}
# Chemins multi-segments — on supprime juste le slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$1; }
La première règle gère les slugs à la racine (vos anciennes URL WordPress). Elle vérifie si une page correspondante existe dans /insights/ et redirige directement vers celle-ci. Pour les autres chemins à la racine, cette même règle supprime la barre oblique finale en une seule redirection ; les chemins à plusieurs segments correspondent à la seconde règle, générique. 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 de la migration, 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 maintenez deux sitemaps qui peuvent se désynchroniser. 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 compilation.
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. Vous pouvez conserver les deux, mais si les e-mails en double vous encombrent, choisissez-en une. Si vos sous-domaines sont des projets distincts, la propriété de préfixe d’URL est plus claire — elle ne rend compte que des URL sous ce préfixe exact, par exemple celles de votre hôte www de 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 URL 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, URL 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 une nouvelle exploration.
É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 faut-il à Google pour prendre en compte les corrections ?
Les redirections en un seul saut prennent effet immédiatement pour les nouvelles explorations. Les modifications de sitemap sont prises en compte en quelques jours. La confusion entre les URL canoniques — 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 liens entrants et d’un historique de clics plus fourni, Google peut continuer à la choisir comme URL canonique pendant plusieurs semaines.
La combinaison de redirections propres et d’un sitemap unique faisant autorité envoie à Google le signal le plus clair possible ; une propriété GSC consolidée facilite le suivi des rapports restants. 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.