Le trafic baisse après une mise en ligne, et l'on attend. C'est même le bon réflexe les premiers jours : Google a besoin de temps pour recrawler les nouvelles URLs, les réévaluer et les réindexer. Le rapport « Indexation des pages » de la Google Search Console montre une courbe qui bouge, on la regarde remonter, et l'on se rassure.
Seulement, une courbe agrégée ne dit jamais quelles pages sont restées derrière. Combien d'anciennes URLs ont réellement trouvé leur remplaçante ? Combien de nouvelles pages sont indexées trois semaines après la bascule ? Et parmi celles qui ne le sont pas, lesquelles Google a-t-il écartées, pour quel motif ?
C'est souvent là que les refontes les mieux préparées perdent le plus de terrain.
Ce qu'est une refonte SEO réussie
Une refonte SEO réussie conserve les positions et le trafic organique du site précédent, puis les dépasse. Elle repose sur trois piliers : un inventaire exhaustif des URLs existantes, un plan de redirection sans rupture ni chaîne, et une vérification après la mise en ligne, page par page, de ce que Google a réellement retenu du nouveau site.
Le troisième pilier est celui que la plupart des checklists expédient en une ligne, alors qu'il est le seul à pouvoir confirmer que les deux premiers ont produit l'effet attendu.
Refonte ou migration : la distinction que fait Google
En français, le mot « refonte » recouvre deux opérations que Google traite séparément, dans deux pages de documentation distinctes : le déplacement de site avec changement d'URLs, et le déplacement sans changement d'URLs. Les risques et les vérifications n'ont rien de comparable d'un cas à l'autre.
Sans changement d'URLs, le site change d'apparence, de gabarit, parfois d'hébergement, mais les adresses restent identiques. Aucun plan de redirection n'est nécessaire. Le risque se déplace ailleurs : contenu raccourci lors du remaniement des gabarits, balises perdues au passage, maillage interne reconstruit qui enterre des pages jusque-là accessibles en deux clics, blocages de préproduction oubliés en production. Google documente par ailleurs un effet propre au changement d'hébergement : une baisse temporaire du taux de crawl juste après la bascule, suivie d'une remontée progressive, parfois au-delà du niveau antérieur.
Avec changement d'URLs, tout se joue sur la correspondance entre l'ancien et le nouveau. Le plan de redirection devient la pièce maîtresse, et une question nouvelle apparaît : Google va-t-il retenir votre cible de redirection comme adresse canonique, ou en préférer une autre ? Les deux cas se combinent d'ailleurs souvent, lorsqu'un changement de plateforme s'accompagne d'une refonte graphique.
Savoir dans quel cas on se trouve détermine la checklist à dérouler. Une refonte purement graphique qui conserve les URLs n'a pas besoin d'un plan de redirection de trois cents lignes ; elle a besoin d'une vérification que le contenu n'a pas fondu et que le crawl est reparti.
Pourquoi une refonte fait perdre du trafic
Une refonte fait perdre du trafic quand Google ne retrouve pas, sur les nouvelles adresses, ce qui justifiait les positions des anciennes : le contenu, les liens qui pointaient vers elles, et la possibilité de les explorer rapidement. Les causes se répètent d'un projet à l'autre, et elles se hiérarchisent.
Les URLs oubliées du plan de redirection arrivent largement en tête. Une refonte se prépare le plus souvent à partir du sitemap ou d'un crawl du site. Or ces deux sources ne contiennent pas tout : les anciennes pages détachées du maillage, les landing pages créées hors du CMS, les variantes à paramètres qui recevaient pourtant des clics. Ces adresses-là ne sont dans aucune liste, et personne ne s'aperçoit de leur disparition avant de voir le trafic baisser.
Les chaînes de redirections viennent ensuite. Une ancienne URL redirige vers une adresse intermédiaire, qui redirige vers la nouvelle. Chaque maillon dilue le signal et ralentit le traitement, et les chaînes s'allongent silencieusement quand une refonte succède à une précédente.
Le contenu amputé est plus insidieux. La nouvelle page existe, elle répond en 200, tout semble en ordre. Mais le gabarit refait a supprimé une section de texte, remplacé un paragraphe par un visuel, déplacé les réponses dans un accordéon chargé après coup. Google recrawle, trouve moins de matière, et la page recule. Dans les cas extrêmes, elle bascule en Soft 404 : le serveur répond correctement, mais Google juge la page vide.
L'architecture aplatie ou reconstruite déplace la profondeur des pages. Une fiche produit accessible en deux clics qui passe à quatre reçoit moins de liens internes, donc moins d'attention. C'est invisible dans un rapport de trafic et très visible dans un rapport de crawl.
Le délai de recrawl lui-même, enfin, explique une part de la baisse initiale, et celui-là est normal. La difficulté consiste précisément à distinguer ce creux attendu d'un vrai problème, et c'est l'objet de la dernière partie de cette checklist.
Avant la bascule : l'inventaire des URLs
L'inventaire consiste à établir la liste complète des adresses qui existent aujourd'hui et qui méritent d'être préservées. Trois sources se cumulent, et la troisième est celle qu'on oublie.
Le sitemap XML donne ce que le site déclare. C'est le point de départ, rarement le périmètre réel : un sitemap reflète ce que le CMS sait générer, pas ce que Google connaît.
Un crawl du site complète la liste avec ce qui est accessible par les liens. Il ajoute les pages présentes mais non déclarées, et il révèle la profondeur actuelle de chaque page, une donnée précieuse pour vérifier après coup que la nouvelle architecture ne l'a pas dégradée.
L'export de la Search Console apporte ce que les deux autres ne peuvent pas donner : les URLs qui reçoivent réellement des clics et des impressions, y compris celles qui ne figurent dans aucun sitemap et qu'aucun lien interne ne dessert plus. C'est la liste qui compte vraiment. Une page oubliée dans le plan de redirection n'a d'importance que si elle rapportait quelque chose, et seule la Search Console le sait.
La liste des adresses à protéger en priorité correspond donc à celles qui reçoivent des clics, et pas seulement à celles que déclare le sitemap. Les deux se recoupent largement, et c'est dans l'écart entre elles que se logent la plupart des mauvaises surprises d'une refonte.
Il reste à y ajouter les pages qui reçoivent des liens externes, même sans trafic : elles portent une valeur qui disparaît avec elles.
Le plan de redirection
Le plan de redirection associe chaque ancienne URL à l'adresse qui la remplace le mieux sur le nouveau site. Une correspondance par ligne, sans intermédiaire, et une décision explicite pour chaque page qui ne sera pas remplacée.
Une redirection permanente, pas temporaire. Google traite la redirection 301 comme un signal fort de canonicalisation : elle indique que l'adresse a changé définitivement et que le signal doit être transféré. La 302 annonce l'inverse, un déplacement provisoire, et laisse l'ancienne adresse candidate à l'indexation. Sur une refonte, la 301 est la règle ; la 302 se réserve aux bascules réellement temporaires. Les anciennes adresses apparaîtront ensuite sous le statut Page avec redirection dans le rapport d'indexation, ce qui est le comportement attendu.
Vers l'équivalent le plus proche, jamais vers l'accueil. Rediriger en masse des pages supprimées vers la page d'accueil est le raccourci le plus courant et l'un des plus coûteux. Google considère ces redirections comme des Soft 404, puisque la destination ne répond pas à l'intention de départ. Une page sans équivalent gagne à renvoyer un 404 assumé, ou un 410 si la suppression est définitive, plutôt qu'une redirection trompeuse.
Sans chaîne. Si l'ancien site contenait déjà des redirections, il faut les aplatir : la plus ancienne adresse doit pointer directement vers la destination finale, pas vers un maillon intermédiaire lui-même redirigé.
Avec les ressources. Les images, les fichiers PDF, les flux et les anciens sitemaps ont aussi des adresses. Ils sont régulièrement absents des plans de redirection alors qu'ils se positionnent parfois seuls.
💡 Sur une refonte de quelques centaines d'URLs, ce travail se mène à la main. Au-delà, la question n'est plus d'écrire le plan mais de vérifier qu'il a produit l'effet attendu, adresse par adresse. C'est exactement ce que permet une vérification d'indexation en masse.
Le jour de la bascule
L'ordre des opérations compte autant que leur contenu. Quatre points se vérifient dans l'heure qui suit la mise en ligne.
Lever les blocages de préproduction. Le robots.txt qui interdisait tout, la balise noindex posée sur l'ensemble du gabarit, l'authentification HTTP qui protégeait la recette : ces trois éléments sont conçus pour empêcher l'indexation, et ils sont régulièrement oubliés en production. Une refonte bloquée par son propre robots.txt pendant une semaine coûte beaucoup plus cher que la refonte elle-même. Le statut Bloquée par le fichier robots.txt apparaît alors dans le rapport d'indexation, souvent avec plusieurs jours de décalage.
Soumettre deux sitemaps. C'est la recommandation explicite de Google, et elle est rarement appliquée : garder temporairement le sitemap des anciennes URLs en plus de celui des nouvelles. Le premier doit voir son nombre d'URLs indexées tomber progressivement à zéro, le second le voir monter. Ce croisement est la mesure la plus lisible de l'avancement du transfert. Les avertissements de redirection sur l'ancien sitemap sont normaux et peuvent être ignorés.
Vérifier un échantillon de redirections en direct, en suivant la chaîne complète et en contrôlant le code de statut réellement renvoyé, pas seulement la page affichée.
Mettre à jour les liens internes, plutôt que de compter sur les redirections. Une redirection fonctionne, mais un lien interne qui pointe directement vers la bonne adresse fonctionne mieux, et ne dépendra pas de la durée de vie du plan de redirection.
Après la bascule : vérifier ce que Google a décidé de vos nouvelles URLs
C'est l'étape la plus décisive de la checklist, et celle que la plupart des guides résument en une ligne. La raison est simple : jusqu'ici, tout ce qui précède se contrôle depuis votre propre site. À partir d'ici, la seule réponse valable vient de Google.
Vos nouvelles URLs sont-elles indexées, et lesquelles ne le sont pas ?
Le rapport « Indexation des pages » de la Search Console donne des compteurs agrégés, avec plusieurs jours de décalage. Il montre que le nombre de pages indexées a bougé. Il ne dit pas lesquelles de vos nouvelles adresses ont échoué, ni pourquoi.
L'outil d'inspection d'URL, lui, donne le verdict officiel complet : le statut exact, le motif quand la page n'est pas indexée, la canonique retenue par Google, la date du dernier passage de Googlebot. Il le donne une URL à la fois. Sur une refonte de trois cents pages, la vérification devient fastidieuse ; sur plusieurs milliers, elle n'a simplement pas lieu.
C'est ce décalage qui explique qu'une refonte puisse être déclarée réussie alors qu'une partie du catalogue n'est jamais revenue dans l'index. Les statuts observés après une bascule sont variés — parmi les plus fréquents, Explorée, actuellement non indexée sur des pages que Google a bien vues mais n'a pas retenues, et les statuts de canonique évoqués plus bas.
C'est précisément ce travail qu'IndexProbe automatise : le verdict officiel de Google, pour toute la liste de vos nouvelles URLs, en une analyse.
Google a-t-il retenu votre cible de redirection comme canonique ?
Une redirection 301 constitue un signal fort de canonicalisation, sans pour autant garantir le résultat. Google recoupe plusieurs signaux — la redirection, les balises canoniques déclarées, les liens internes et externes, la similitude des contenus — et retient l'adresse qui lui paraît la plus représentative. Ce n'est pas toujours celle que vous visiez.
Le cas se produit surtout dans deux configurations. Quand plusieurs anciennes adresses redirigent vers une même nouvelle page, Google doit trancher entre des signaux concurrents. Et quand la nouvelle page ressemble beaucoup à une autre page du nouveau site, une fiche produit et sa variante, une catégorie et sa version filtrée, il peut consolider les deux sous une adresse unique qui n'est pas forcément celle que vous aviez prévue.
Le résultat porte un nom dans la Search Console : Page en double, Google a choisi une autre URL canonique que l'utilisateur. La page redirigée arrive bien quelque part, mais pas là où vous pensiez, et les positions suivent la destination réelle, pas la destination prévue.
La vérification consiste à comparer, pour chaque nouvelle URL, la canonique que vous déclarez et celle que Google a effectivement retenue. L'écart entre les deux colonnes est le signal. Regardé segment par segment, il révèle en général un problème structurel plutôt qu'une série de cas isolés : un gabarit, une famille de pages, une règle de génération d'URLs.
Le creux de crawl : normal, mais jusqu'à quand ?
Google documente explicitement ce phénomène pour les changements d'hébergement : il est normal de constater une baisse temporaire du taux de crawl juste après la mise en ligne, suivie d'une remontée progressive sur les jours suivants, éventuellement à un niveau supérieur à celui d'avant. L'explication tient à la manière dont le taux de crawl est déterminé : il repose sur des signaux liés à l'infrastructure, et ces signaux changent quand l'hébergement change.
La conséquence pratique est qu'un creux de crawl après une bascule n'a rien d'inquiétant en lui-même. Ce qui doit alerter, c'est l'absence de remontée dans les jours qui suivent, et la constater suppose d'avoir mesuré le taux de crawl aussi bien avant qu'après.
Google recommande pour cela de lire les journaux du serveur et d'y repérer les passages de Googlebot. C'est la méthode la plus complète, et elle suppose un accès aux logs, une infrastructure pour les traiter et quelqu'un pour les lire, trois conditions rarement réunies au moment précis où une équipe sort d'une refonte.
Il existe une voie plus courte : les données de crawl que Google expose lui-même pour chaque URL inspectée, à savoir la date du dernier passage de Googlebot. Agrégées sur une liste d'adresses, elles donnent un taux de crawl sur trente jours, une fréquence moyenne et une distribution des écarts entre deux passages. Suivies par segment, elles montrent si la remontée a lieu partout, ou si une famille de pages reste en arrière. C'est le même raisonnement que celui du budget de crawl, appliqué au moment où il est le plus utile.
Mesurer la reprise : comparer l'avant et l'après
La seule façon de savoir si une refonte est revenue à son niveau consiste à comparer deux états du même périmètre à quelques semaines d'écart. Une courbe de trafic ne suffit pas, puisqu'elle mélange l'indexation, le positionnement et la saisonnalité. Ce qu'il faut confronter, ce sont deux états d'indexation relevés sur la même liste d'URLs.
La comparaison répond à trois questions que le trafic seul laisse ouvertes. Le nombre de pages indexées est-il revenu à son niveau d'avant la bascule ? Les statuts se sont-ils déplacés dans le bon sens, ou certaines pages sont-elles passées d'indexées à non indexées ? Et la reprise est-elle homogène, ou concentrée sur certains segments ?
Cette lecture segmentée est souvent celle qui débloque un diagnostic. Un site dont l'indexation globale est revenue à 94 % peut très bien avoir laissé un tiers de ses fiches produit derrière, et la moyenne masque l'écart jusqu'à ce qu'on le regarde par famille de pages.
Les erreurs qui coûtent le plus cher
Rediriger toutes les pages supprimées vers l'accueil. La destination ne répond pas à l'intention initiale, Google traite la redirection comme un Soft 404, et le signal de l'ancienne page se perd au lieu d'être transféré. Un 404 assumé vaut mieux, ou un 410 pour une suppression définitive.
Couper les redirections trop tôt. Le plan de redirection n'est pas une opération de quelques semaines. Google continue de solliciter les anciennes adresses longtemps après la bascule, et les liens externes, eux, ne seront jamais mis à jour. Un an est un minimum raisonnable ; sur les pages qui reçoivent des liens, il vaut mieux les garder indéfiniment.
Laisser des chaînes s'installer. Chaque maillon ajoute une étape, dilue le signal et augmente le risque qu'un maillon casse.
Oublier les 404 apparues après la bascule. Une refonte produit toujours un lot d'adresses introuvables non anticipées : liens internes obsolètes, URLs mal réécrites, ressources déplacées. Elles apparaissent dans le rapport d'indexation et se traitent comme n'importe quelle erreur 404 dans la Search Console, à ceci près qu'après une refonte elles arrivent par centaines.
Attendre le retour du trafic pour vérifier l'indexation. Le trafic est un indicateur retardé : quand la baisse devient nette dans les rapports, les pages concernées sont souvent sorties de l'index depuis plusieurs semaines, et le temps de correction viendra s'ajouter à ce délai. Le statut d'indexation de chaque page peut au contraire se relever dès les premiers jours qui suivent la bascule.
Questions fréquentes
Combien de temps le trafic baisse-t-il après une refonte ?
Une baisse de quelques jours à quelques semaines est normale, le temps que Google recrawle les nouvelles adresses, traite les redirections et réévalue les pages. L'ampleur dépend de la taille du site et du nombre d'URLs modifiées. Au-delà de six à huit semaines sans reprise, il ne s'agit plus du délai normal mais d'un problème à diagnostiquer, et la première chose à vérifier est l'indexation des nouvelles pages, pas les positions.
Faut-il utiliser des redirections 301 ou 302 lors d'une refonte ?
Des 301. Google traite la redirection permanente comme un signal fort de canonicalisation, ce qui est exactement l'intention lors d'une refonte : indiquer que l'adresse a changé définitivement. La 302 annonce un déplacement temporaire et laisse l'ancienne adresse candidate à l'indexation. Elle ne se justifie que pour une bascule réellement provisoire, le temps d'un test par exemple.
Peut-on rediriger toutes les anciennes pages vers la page d'accueil ?
Non, c'est l'un des raccourcis les plus coûteux. Quand la destination ne correspond pas à l'intention de la page d'origine, Google considère la redirection comme un Soft 404 et le signal de l'ancienne page n'est pas transféré. Chaque ancienne adresse gagne à pointer vers son équivalent le plus proche, et celles qui n'en ont pas gagnent à renvoyer un 404, ou un 410 si la suppression est définitive.
Combien de temps faut-il conserver les redirections ?
Un an au minimum. Google continue de solliciter les anciennes adresses bien après la bascule, et les liens externes pointant vers elles ne seront jamais mis à jour par leurs auteurs. Sur les pages qui reçoivent des liens entrants de valeur, mieux vaut conserver les redirections sans limite de durée : leur coût technique est négligeable au regard du signal qu'elles transmettent.
Faut-il conserver les anciennes URLs quand c'est possible ?
Oui, quand la refonte est graphique ou fonctionnelle et qu'aucune raison sérieuse n'impose de changer la structure des adresses. Une refonte sans changement d'URLs supprime d'emblée le risque le plus important, celui du plan de redirection incomplet. Les vérifications se concentrent alors sur le contenu, le maillage interne et la reprise du crawl.
Comment savoir si une refonte a réussi ?
En comparant l'indexation avant et après sur le même périmètre d'URLs, plutôt qu'en surveillant la courbe de trafic. Trois indicateurs suffisent : le nombre de pages indexées est-il revenu à son niveau antérieur, les statuts se sont-ils déplacés dans le bon sens, et la reprise est-elle homogène entre les segments du site. Une moyenne satisfaisante peut masquer une famille de pages entière restée hors de l'index.
Vérifier votre refonte page par page
Une refonte mobilise des semaines de travail, et son résultat dépend de ce que Google a retenu du nouveau site. IndexProbe interroge l'API officielle de la Search Console pour la liste d'URLs que vous lui fournissez et rend, pour chaque page, le statut d'indexation, le motif de non-indexation, la canonique que Google a réellement choisie et la date du dernier passage de Googlebot. La vue Comparaison mesure ensuite l'écart entre deux analyses, pour savoir si la reprise a bien eu lieu, et où elle n'a pas eu lieu.
Vérifier l'indexation de votre nouveau site — essai gratuit de 10 jours, sans carte bancaire.