Une refonte fait rarement chuter un site à cause de son design. Elle le fait chuter parce que les URL changent sans plan de redirections, et parce que le contenu se raccourcit au passage. La méthode tient en trois temps : inventorier avant de toucher à quoi que ce soit, rediriger une ancienne URL vers une nouvelle page équivalente, puis surveiller pendant plusieurs semaines. Google demande des redirections permanentes, conservées au moins un an, et compte quelques semaines pour migrer la majorité des pages d’un site de taille petite à moyenne.
Sommaire
Le scénario est toujours le même. Le nouveau site est plus beau, plus rapide, enfin conforme à ce que l’entreprise est devenue. Trois semaines après la mise en ligne, le trafic a fondu de moitié et personne ne comprend pourquoi, puisque « le site est mieux qu’avant ».
Il l’est peut-être. Mais Google ne note pas un site, il indexe des adresses. Une refonte qui change les adresses sans dire à Google où sont parties les pages efface d’un coup l’historique de chacune. Voici comment on évite ça, dans l’ordre.
01Ce qu’une refonte casse réellement
Trois mécanismes expliquent la quasi-totalité des chutes post-refonte. Aucun n’a de rapport avec l’esthétique.
Les adresses changent, et l’historique reste derrière
Chaque URL indexée porte des années de signaux : les liens qui pointent vers elle, son ancienneté, ses positions acquises. Quand /nos-services/plomberie.html devient /services/plomberie/ sans redirection, Google se retrouve devant une erreur 404 d’un côté et une page inconnue de l’autre. Rien ne relie les deux, et la nouvelle page repart de zéro.
Le contenu maigrit sans que personne le décide
C’est la cause la plus fréquente, et la plus discrète. Le nouveau design est épuré, donc les longs textes deviennent des accroches de trois lignes. Les pages qui se positionnaient parce qu’elles répondaient précisément à une question ne répondent plus à rien. Le trafic baisse sur des URL pourtant correctement redirigées, et on cherche le problème du mauvais côté.
La structure interne se reconstruit au hasard
Un nouveau menu, de nouveaux gabarits, et la circulation interne change du tout au tout. Des pages qui recevaient dix liens internes n’en reçoivent plus un seul, d’autres se retrouvent à trois clics de l’accueil au lieu d’un. La façon dont les liens internes se distribuent se refait entièrement lors d’une refonte, et presque jamais volontairement.
02L’inventaire, avant de toucher à quoi que ce soit
Tout ce qui suit devient impossible si on ne l’a pas relevé pendant que l’ancien site est encore en ligne. C’est le seul moment où l’information existe.
| Ce qu’on relève | Où | À quoi ça sert ensuite |
|---|---|---|
| Toutes les URL indexées | Search Console, sitemap, crawl complet | Bâtir le plan de redirections |
| Les pages qui apportent du trafic | Search Console, statistiques | Savoir lesquelles ne doivent surtout pas bouger |
| Positions et requêtes de départ | Search Console, 3 à 6 mois | Mesurer après, sur la même base |
| Les liens externes entrants | Outil de netlinking | Repérer les URL qu’on ne peut pas se permettre de perdre |
| Le texte de chaque page qui compte | Export du contenu | Vérifier qu’il n’a pas maigri après |
Sur le texte, le contrôle le plus utile tient en une comparaison bête : le nombre de mots de chaque page avant, le même après. Une page qui passe de 900 mots à 200 a perdu ce qui la faisait ressortir, quelle que soit la qualité du nouveau gabarit. Cette liste se dresse en une heure et elle explique, après coup, la moitié des chutes qu’on met sur le dos des redirections.
Ce relevé sert de référence pendant six mois. Sans lui, la seule question qui compte après la mise en ligne, « est-ce qu’on a perdu quelque chose ou est-ce la saison ? », restera sans réponse. C’est aussi ce qui distingue une refonte pilotée d’une refonte subie, et le point de départ de l’audit que je livre avant tout chantier.
03Le plan de redirections
C’est la pièce maîtresse, et c’est aussi la plus bâclée. Google demande des redirections permanentes côté serveur, les codes 301 et 308, et précise qu’une redirection permanente lui sert de signal pour désigner la nouvelle adresse comme canonique. Une redirection temporaire, elle, laisse l’ancienne page dans les résultats.1
Une ancienne page, une nouvelle page équivalente
La règle tient en une phrase : chaque ancienne URL part vers la page qui traite le même sujet. Ni vers l’accueil, ni vers une catégorie fourre-tout. Une redirection massive vers la page d’accueil est traitée comme une erreur 404 déguisée, et fait perdre exactement ce qu’on cherchait à sauver.
Les chaînes et les impasses
Une ancienne URL qui redirige vers une deuxième, qui redirige vers une troisième, finit par diluer le signal et ralentir l’exploration. On aplatit tout : chaque ancienne adresse pointe directement vers sa destination finale. Et on vérifie qu’aucune redirection ne boucle sur elle-même, ce qui rend la page inaccessible sans que rien ne le signale.
Le cas du changement de domaine
Changer d’adresse en même temps que de site cumule les deux risques, et demande en plus une demande de changement d’adresse dans la Search Console.2 C’est faisable proprement : sur une refonte avec migration de domaine portant vingt-cinq ans d’archives, le plan de redirections a été écrit avant la mise en ligne et les positions ont tenu.
Dernier point, celui qu’on oublie tous : Google demande de conserver les redirections aussi longtemps que possible, au moins un an.2 Elles ne se démontent pas au bout de deux mois parce que « ça a l’air d’être passé ».
04La mise en ligne, et les semaines qui suivent
L’ordre du jour J
Google donne une séquence : mettre les redirections en place, vérifier les balises rel="canonical", tester les redirections, envoyer la demande de changement d’adresse s’il y a lieu, puis soumettre le nouveau sitemap.2 Dans les faits, la vérification passe avant tout : on teste le plan sur l’environnement de préproduction, ligne par ligne, avant que le public ne voie quoi que ce soit.
Combien de temps ça prend
Comptez quelques semaines pour que la majorité des pages d’un site de taille petite à moyenne soient migrées, davantage pour un gros site.2 Une baisse pendant cette fenêtre est normale et ne prouve rien. C’est après qu’il faut regarder.
Un compte rendu récent donne des repères plus fins. Le 2 octobre 2026, au Search Central Live Deep Dive Europe de Barcelone, Gary Illyes, de Google, a présenté des fourchettes de délais qui, d’après le compte rendu d’un participant, reposent sur une analyse interne de Google.3 Google n’avait pas publié les diapositives à la date de l’article de Search Engine Journal, et le compte rendu ne donne ni taille d’échantillon ni définition de ce que « typique » recouvre.3 Ces chiffres servent donc de repères pour savoir si une étape est encore en cours ou bloquée.
Les repères, étape par étape
Le tableau retient les étapes qui concernent une refonte. Chaque ligne donne le délai typique rapporté, le cas lent, et l’endroit de la Search Console où l’on voit si l’étape est franchie.
| Étape | Typique3 | Cas lent | À vérifier dans la Search Console |
|---|---|---|---|
| Découverte d’une nouvelle URL | environ 20 heures | des semaines, voire jamais | Outil d’inspection d’URL : la mention « Google ne reconnaît pas cette URL » signifie qu’elle n’a jamais été détectée4 |
| Réexploration d’une URL connue | environ 30 jours | des semaines, voire jamais | Le même outil donne la date de la dernière exploration4 |
| Traitement d’un sitemap | environ 24 heures | jusqu’à 14 jours, ou jamais (qualité) | Rapport Sitemaps : état et date de la dernière lecture5 |
| Indexation de bout en bout | environ 1 h 30 | des mois, ou jamais (qualité) | Rapport sur l’indexation des pages, qui compte les URL explorées et indexées6 |
| Changement de canonique | 1 à 3 semaines | des mois (signaux contradictoires) | Outil d’inspection d’URL : champ « URL canonique sélectionnée par Google »4 |
| Nouveau titre de page | 1 à 2 jours | plusieurs semaines à plusieurs mois | Date de dernière exploration : elle dit si Google a revu la page depuis le changement4 |
| Déménagement de site | 1 à 3 mois | 6 mois à plus d’un an | Rapport Sitemaps avec l’ancien et le nouveau sitemap : les pages indexées du premier tombent vers zéro, celles du second montent2 |
Ces étapes sont liées : selon le compte rendu, Gary Illyes a prévenu qu’une page doit être explorée avant d’être indexée, si bien que les retards s’additionnent.3 Le même compte rendu définit l’indexation de bout en bout comme le moment où tous les processus critiques ont abouti, et note qu’un petit déménagement peut se faire en quelques semaines.3
Pour les canoniques, le guide de dépannage de Google indique que des pages peuvent rester jusqu’à deux semaines dans un groupe de doublons après la correction de leur contenu.7
Dans les cas lents, plusieurs étapes finissent par « jamais ». Pour le traitement d’un sitemap comme pour l’indexation de bout en bout, le compte rendu y ajoute la qualité entre parenthèses.3 La documentation de la Search Console va dans ce sens pour un sitemap non lu : elle cite parmi les causes une demande d’exploration faible, qui monte avec la qualité du contenu du site.5 Avant de conclure à un problème de qualité, on écarte les causes courantes qui empêchent Google de lire un sitemap valide, du blocage par le robots.txt à une action manuelle non résolue.5
Un déménagement encore incomplet au bout de trois mois se situe en haut de la fourchette typique rapportée, alors que les cas lents vont de six mois à plus d’un an.3 Trois mois sans retour des positions justifient de reprendre l’inventaire de départ et le plan de redirections.
Le compte rendu chiffre aussi des cas étrangers à une refonte : 1 à 2 semaines pour lever une action manuelle, et 3 à 6 mois pour se remettre d’une mise à jour principale, jusqu’à la mise à jour suivante dans les cas lents.3 La documentation de Google sur les mises à jour principales va dans le même sens : certaines modifications prennent effet en quelques jours, les systèmes peuvent mettre plusieurs mois à confirmer que le site produit durablement des contenus utiles, et il faut parfois attendre la mise à jour suivante.8 Elle recommande aussi d’attendre une semaine complète après la fin du déploiement d’une mise à jour avant d’analyser le site dans la Search Console.8
Ce qu’on surveille
- Les erreurs 404 qui apparaissent, dans la Search Console et dans les journaux du serveur. Chacune est une redirection oubliée.
- La couverture d’indexation, pour vérifier que les nouvelles URL entrent aussi vite que les anciennes sortent.
- Les positions sur les requêtes relevées avant, page par page. Une moyenne globale ne dira rien.
- Les données structurées, qui disparaissent silencieusement neuf fois sur dix lors d’un changement de gabarit. Le balisage qui alimente les résultats enrichis ne survit jamais tout seul à une refonte.
- Les impressions dans les fonctionnalités d’IA, qui se relèvent désormais séparément dans la Search Console. J’ai détaillé ailleurs ce que ce rapport permet réellement de mesurer, et surtout ce qu’il ne dit pas.