La plupart des catastrophes de trafic ne viennent pas d'une mise à jour de Google : les équipes se les infligent elles-mêmes lors d'un changement de plateforme. Une migration à l'aveugle peut coûter 30 à 70 % du trafic organique, et la récupération prend des mois. Menée dans les règles, elle donne un petit creux de courte durée, souvent suivi d'une croissance (Next.js gagne généralement sur le rendu et la vitesse).
Règle zéro : ne changer qu'une variable à la fois
Les migrations les plus risquées changent la plateforme, la structure d'URL, le design et le contenu en même temps : quand le trafic chute, personne ne sait dire quel changement l'a fait tomber. Étalez dans le temps : migrez la plateforme avec des URL et un contenu gelés, confirmez la stabilité pendant quelques semaines, puis faites évoluer le design et le contenu sur la nouvelle stack.
Avant : construire l'inventaire
On ne préserve pas ce qu'on n'a pas mesuré. Rassemblez par URL :
- Un crawl complet de l'ancien site (Screaming Frog ou un script sur l'ancien sitemap).
- Les meilleures pages de la Search Console (12 mois de clics) et les meilleures pages de conversion de l'analytics : elles reçoivent une attention manuelle.
- Les pages les plus liées (GSC → Liens ou Ahrefs) : perdre une redirection sur une page avec 200 domaines référents, c'est brûler des années d'autorité.
- Les title, description, canonicals, hreflang et données structurées actuels : la base de parité.
La table de redirections, c'est cette migration
Si les URL changent, chaque ancienne URL reçoit une 308/301 en un seul saut vers son équivalent exact, et non vers l'accueil (Google traite les redirections massives vers l'accueil comme des soft 404) :
// next.config.mjs — d'abord les règles à motifs, table explicite pour les exceptions
async redirects() {
return [
{ source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
];
}
Les chaînes sont interdites : si l'ancien site avait déjà des redirections, dirigez leurs sources aussi directement vers les URL finales. Tout ce qui figure dans le sujet sur les redirections s'applique ici doublement.
Préproduction : un contrôle de parité, pas « à l'œil »
- Gardez la préproduction hors de l'index : l'authentification HTTP évite de dépendre d'un réglage
noindexqui pourrait atterrir par erreur en production. - Comparez par script ancien et nouveau pour les pages principales : title, description, canonical, hreflang, H1, JSON-LD, code de réponse. La parité du rendu aussi : faites un
curlsur le HTML de la préproduction et confirmez que le contenu est rendu côté serveur. - Testez la table de redirections sur l'inventaire complet des anciennes URL avant le lancement, pas sur un échantillon.
Jour du lancement et semaines suivantes
- Soumettez le nouveau sitemap dans la Search Console ; servez les redirections des anciennes URL indéfiniment (des années, pas des semaines).
- Surveillez les journaux du serveur pour repérer les 404 de Googlebot : chacune est un trou dans la table de redirections ; corrigez chaque jour la première semaine.
- Attendez-vous à un pic de crawl et à des fluctuations de positions pendant 2 à 6 semaines : Google réévalue le site ; ne faites pas marche arrière par panique.
- Seuils d'alerte : une baisse persistante de plus de 20 % sur les pages qui génèrent du chiffre d'affaires après la troisième semaine mérite une enquête (mise en place de la surveillance), pas de l'espoir.
Checklist :
- Inventaire des URL avec les meilleures pages GSC et les plus liées repérées
- Table de redirections en un saut couvrant 100 % des anciennes URL, testée avant le lancement
- Préproduction derrière authentification ; parité meta/schémas/rendu comparée page par page pour les pages principales
- Plateforme migrée avec URL et contenu gelés ; design ensuite
- Après le lancement : revue quotidienne des 404 de Googlebot, redirections maintenues des années