Migration SEO et refonte de site : ce qui casse entre l'ancien site et le nouveau
La bascule est prévue jeudi, 22 h. Le nouveau site est validé, l'équipe a passé trois semaines en recette, tout le monde est content du design.
Le lundi suivant, la courbe de la Search Console décroche. Aucune panne, aucune erreur serveur. Les pages répondent. Elles ne ressortent simplement plus.
Ce scénario a rarement une cause exotique. Une migration SEO se joue sur un fichier de correspondance d'URL et sur le code HTTP posé au bout de chaque ligne. Le reste relève de l'intendance.
Migration SEO et refonte de site : cinq chantiers sous un seul mot
Le mot « migration » recouvre des opérations qui n'ont ni le même coût ni le même risque. Les risques d'une migration dépendent d'abord de ce qu'on déplace.
Le changement de nom de domaine est le cas extrême. Tout change : l'adresse, l'autorité accumulée, les signaux que Google associait à l'ancien site. C'est aussi le seul cas où la Search Console propose un outil dédié.
Le changement de CMS déplace la technique sans forcément toucher aux adresses. Un WordPress qui devient un site sur mesure peut garder ses URL à l'identique. S'il les garde vraiment, la moitié du risque disparaît.
La refonte d'arborescence, elle, ne change ni le domaine ni la technologie. Elle réécrit les chemins. C'est le cas le plus fréquent, et celui où les équipes sous-estiment le volume de travail.
Restent le passage en HTTPS et le changement d'hébergement. Le premier est une migration d'un site web à part entière du point de vue des moteurs de recherche. Le second ne l'est pas du tout, sauf si les adresses bougent au passage.
Une refonte de site cumule souvent trois de ces chantiers d'un coup. C'est pour ça qu'elle rate plus souvent qu'un déménagement de serveur.
Le plan de redirection d'URL est un fichier exécutable, pas un tableau d'intentions
Le plan de redirection lors d'une migration SEO n'est pas un document de cadrage. C'est un fichier que quelqu'un va lire et transformer en règles serveur.
Le format minimal tient en quatre colonnes : ancienne URL, nouvelle URL, code, règle. La dernière colonne est celle qui manque partout, et c'est la plus importante.
Une règle « exacte » vise une adresse et une seule. Une règle « pattern » couvre une famille entière avec une expression régulière. Cinq cents produits qui passent de /produit/xxx à /p/xxx, c'est une ligne, pas cinq cents.
Le piège du pattern, c'est qu'il attrape aussi ce qu'on n'avait pas prévu. Il faut donc le tester contre la liste réelle des URL, pas contre trois exemples choisis à la main.
L'autre décision structurante concerne les pages sans équivalent. Rediriger tout ce qui n'a pas de destination vers la page d'accueil est le réflexe le plus courant, et la première erreur à éviter lors d'une migration. Google traite ces redirections comme des soft 404 : la page n'existe plus, mais le serveur prétend le contraire.
Pour ces pages, une vraie 404 ou une 410 vaut mieux qu'un mensonge. Google le recommande explicitement dans sa documentation sur les migrations de sites, qui demande aussi d'éviter les chaînes de redirections : Googlebot suit jusqu'à 10 sauts, mais rediriger directement vers la destination finale reste la règle.
Reste la partie que personne n'inventorie. Les paramètres d'URL, les facettes de filtrage, la pagination, les versions imprimables. Et les fichiers : la même documentation demande d'inclure images, vidéos, JavaScript et CSS dans l'identification des anciennes URL.
Un plan de redirection qui ne couvre que les pages HTML est un plan à moitié fait.
Le code de redirection que vous posez décide de ce qui casse
Toute la SERP française vous dira de poser des 301. C'est un bon conseil dans le monde d'Apache, et il devient faux dès qu'on ouvre une configuration moderne.
La norme HTTP est explicite sur un point que les articles SEO ignorent. Une 301 autorise le navigateur à transformer une requête POST en GET, pour des raisons historiques. La RFC 9110 recommande la 308 quand ce comportement n'est pas souhaité.
Concrètement : une 301 posée sur une route qui reçoit des envois de formulaire peut casser la fonctionnalité sans qu'aucun crawl SEO ne le voie.
Le second point est plus lourd de conséquences. Une 301 est mise en cache par le navigateur par défaut, sans durée imposée. Un visiteur qui l'a reçue continue de la suivre même après correction côté serveur.
Une erreur de mapping ne se rattrape donc pas simplement. C'est le vrai argument pour tester avant la bascule, et pas seulement après.
| Code | Permanence | Méthode HTTP préservée | Mis en cache par le navigateur | Traité comme permanent par Google |
|---|---|---|---|---|
| 301 | permanente | non | oui, par défaut | oui |
| 308 | permanente | oui | oui, par défaut | oui |
| 302 | temporaire | non | non | non |
| 307 | temporaire | oui | non | non |
| meta refresh 0 s | permanente | sans objet | non | oui |
JavaScript location |
interprétée | sans objet | non | en dernier recours |
C'est aussi pour ça que Next.js émet par défaut des 308 et des 307 plutôt que des 301 et des 302 — la propriété statusCode reste disponible si un client HTTP ancien impose l'inverse. Sa documentation l'explique par la préservation de la méthode HTTP.
Et ça ne pose aucun problème de référencement naturel. Google range la 308 exactement au même niveau que la 301 : des redirections HTTP permanentes, toutes les deux.
Figer l'état zéro avant d'ouvrir le plan de migration
Un développeur ne déploie pas sans savoir comment revenir en arrière. Un plan de migration SEO devrait suivre la même discipline, et c'est rarement le cas.
L'état zéro, c'est la photo de l'ancien site la veille de la bascule. Sans elle, « le trafic a baissé » n'est pas une observation, c'est une impression.
Cinq éléments à capturer, dans cet ordre :
- Le crawl complet de l'ancien site : chaque URL, son code de réponse, son title, sa meta description, sa canonical.
- L'export Google Search Console sur 16 mois, pages et requêtes séparément. C'est la seule mesure de trafic organique que personne ne pourra contester ensuite.
- L'inventaire des backlinks, avec les pages qui en concentrent le plus. Ce sont elles qui doivent être redirigées en premier, et vérifiées en premier.
- Le snapshot des positions sur les requêtes qui comptent pour le business.
- Une copie du
robots.txtet des sitemaps, tels qu'ils sont en production.
Cet inventaire recoupe largement un audit technique classique. La différence tient au moment : ici, il sert de référence de comparaison, pas de liste de corrections.
Les backlinks méritent une attention particulière. Une redirection permanente transfère les signaux vers la nouvelle adresse, mais elle dépend d'un serveur qui doit rester debout. Sur les liens les plus forts, demander la mise à jour de l'URL à la source reste plus solide.
Ce que le nouveau site web perd sans que personne le voie
Le mapping peut être parfait et la migration rater quand même. Un template neuf ne reconduit pas automatiquement ce que l'ancien portait.
Les title tags et les meta descriptions sont souvent régénérés par le nouveau système. Parfois mieux, souvent moins bien, presque toujours différemment.
La hiérarchie des titres change avec le design. Les canonicals suivent la nouvelle logique de routage, qui n'est pas l'ancienne.
Ce point est le trou le plus net de la concurrence sur ce sujet. Presque personne n'en parle, et c'est exactement ce qu'un nouveau template casse en premier.
Viennent ensuite trois pièges de bascule, tous les trois classiques :
- La balise
noindexposée sur la préproduction et oubliée en production. - Le
robots.txtde préprod déployé tel quel, qui bloque l'exploration du site entier. - Les liens internes qui pointent encore vers les anciennes URL.
Le troisième est le plus insidieux. Google demande de mettre à jour les liens internes vers les nouvelles adresses, pas de les laisser traverser une redirection posée lors de la migration.
Sur un site web en framework JavaScript, il y a une couche de plus. En Next.js avec le Pages Router, la navigation côté client ne passe pas par les redirections de configuration. Le crawler voit un site propre, l'utilisateur tombe sur des liens morts.
Migrer le site, puis surveiller les quinze premiers jours
L'ordre des opérations le jour J tient en peu de lignes. Déployer, vérifier en production un échantillon de la mise en place des redirections, soumettre le nouveau sitemap, retirer les blocages temporaires.
Si l'adresse du site change, la demande de changement d'adresse dans la Search Console arrive juste après. Son fonctionnement mérite d'être connu : l'outil transmet le signal pendant 180 jours. Passé ce délai, Google ne reconnaît plus aucune relation entre l'ancien et le nouveau site.
Ce chiffre en croise un autre, et les deux ne disent pas la même chose. La documentation de Google recommande de conserver les redirections « aussi longtemps que possible, généralement au moins un an ».
C'est cette durée-là qui fait foi. Les 180 jours ne sont que la fenêtre de l'outil.
Pendant les quinze premiers jours, quatre choses se surveillent. Les erreurs 404 qui remontent, la courbe d'indexation des nouvelles URL, les temps de réponse du serveur, et le trafic organique comparé à l'état zéro.
La charge serveur n'est pas anecdotique. Google explore plus fréquemment après la migration, et un hébergement calibré au trafic normal peut saturer au pire moment.
Reste le sujet dont personne n'écrit une ligne : le plan de retour arrière. Les règles serveur sont réversibles tant qu'elles ne sont pas massivement en cache chez les visiteurs, ce qui donne quelques heures, pas quelques jours. Le temps de réindexation, lui, ne se rembobine pas.
Décider à froid du seuil qui déclenche le retour arrière évite de le décider en panique. C'est le genre d'arbitrage qu'un expert SEO technique pose avant la bascule, pas pendant.
Après la migration : combien de temps avant que le trafic revienne
Deux chiffres circulent, ils se contredisent en apparence, et les deux sont exacts.
Google annonce que « quelques semaines peuvent être nécessaires à la migration de la majorité des pages d'un site de petite à moyenne taille ». Ça décrit la réindexation : le temps que les nouvelles adresses remplacent les anciennes dans l'index.
La donnée terrain raconte autre chose. Sur 1 052 changements de nom de domaine analysés par SALT.agency, 22,8 % seulement retrouvent leur niveau de trafic organique à 90 jours. La médiane est à 304 jours.
Trois réserves avant de brandir ce chiffre. L'échantillon vient des migrations de l'agence et de cas remontés par la communauté, donc biaisé vers celles qui ont marqué.
Le trafic y est estimé par un outil tiers, pas mesuré dans la Search Console. Et il ne porte que sur des changements de domaine, l'opération la plus violente du lot.
Les deux mesures ne parlent donc pas de la même chose. Les URL sont réindexées en quelques semaines.
Le retour au niveau de trafic antérieur prend plus longtemps. Il dépend aussi de la concurrence, du contenu et de la qualité du nouveau site.
Une migration SEO réussie ne se juge pas à trois semaines. Elle se juge sur la comparaison avec l'état zéro, à trois mois, avec les positions à côté du trafic.
Faire poser les redirections par quelqu'un qui lit la configuration serveur
La partie qui casse une migration ne se joue pas dans un tableau Excel. Elle se joue dans un .htaccess, un next.config.js ou une règle de redirection au niveau du CDN.
J'ai passé huit ans à écrire du Angular et du Java avant de faire du SEO. Sur la migration de votre site, je lis le plan de redirection et la configuration qui l'exécute. Ça évite l'aller-retour habituel entre le consultant et l'équipe technique.
Un seul interlocuteur, pas d'agence. Je regarde la structure d'URL actuelle de votre site avant qu'on se parle, et je vous dis où le plan de redirection va coincer. Premier mois remboursé si vous n'êtes pas convaincu.
Questions fréquentes
Quelle est la différence entre une migration et une refonte ?
Une refonte change le site : design, contenu, technologie. Une migration change les adresses auxquelles ce site répond.
Les deux arrivent souvent ensemble, ce qui brouille le vocabulaire. Une refonte qui garde toutes ses URL n'a presque pas de risque de référencement. La migration d'un site internet sans refonte, comme un changement de nom de domaine, en a beaucoup.
Combien de temps faut-il garder les redirections en place ?
Au moins un an, selon la documentation de Google. Ce délai lui laisse le temps de transférer les signaux vers les nouvelles URL et de réattribuer les liens externes.
Rien n'oblige à les retirer ensuite. Une règle de redirection ne coûte quasiment rien à maintenir, et les vieux liens continuent d'exister sur le web longtemps après.
Pourquoi mon trafic baisse alors que mes redirections 301 sont bonnes ?
Parce que les redirections ne sont qu'une moitié du problème. L'autre moitié, c'est ce que le nouveau site fait des pages une fois qu'on y arrive.
Les suspects habituels : title tags régénérés, contenu raccourci pendant la refonte, maillage interne appauvri, canonicals qui pointent ailleurs, temps de chargement dégradé. La comparaison avec l'état zéro tranche en quelques minutes.
Faut-il utiliser l'outil de changement d'adresse pour un passage en HTTPS ?
Non. L'outil de la Search Console sert au changement de nom de domaine, pas au changement de protocole.
Pour un passage en HTTPS, la redirection permanente et la mise à jour des canonicals suffisent. Même chose pour un basculement entre www et sans www.