Refonte de site web et SEO. Garder ce que l’ancien site avait gagné.

Pourquoi un site perd du trafic après une refonte

Une page bien placée sur Google l’est à une adresse précise. Le moteur l’a explorée, indexée, et d’autres sites ont fait des liens vers elle. Si la refonte change cette adresse et que l’ancienne répond par une erreur, Google la retire de son index : sa documentation sur les codes d’état HTTP le dit sans détour, une adresse en 404 ou en 410 qui était indexée en est supprimée. La nouvelle page, elle, part de zéro.

La perte ne vient presque jamais d’une seule cause. Voici celles qu’on retrouve, avec ce qu’elles produisent et la façon de les vérifier soi-même.

La dernière ligne du tableau est la plus coûteuse, et la plus évitable : elle a sa section plus bas.

Ce que Google recommande pour une migration de site

Google publie un guide de la migration d’un site avec modifications d’URL, mis à jour le 11 septembre 2026. Une refonte où les adresses changent en est une, même si le nom de domaine reste le même. Ce qu’il demande tient en peu de règles :

• Dresser la liste des anciennes adresses, en partant des plus importantes : celles du plan du site, celles qui reçoivent le plus de visites, celles qui reçoivent des liens d’autres sites. Images, vidéos et fichiers compris.
• Décider pour chacune où elle doit mener, et le consigner dans une table de correspondance.
• Rediriger de façon permanente, en 301 ou en 308, et directement vers la destination finale. Googlebot suit par défaut jusqu’à dix sauts, mais Google recommande d’aller droit au but et, à défaut, de s’en tenir idéalement à trois, en tout cas moins de cinq.
• Ne pas tout envoyer vers l’accueil. Rediriger en masse vers une seule page « risquerait de dérouter les internautes et pourrait être considéré comme une erreur de type soft 404 ». Seule exception : plusieurs anciennes pages réunies en une seule peuvent toutes mener à celle-ci.
• Répondre 404 ou 410 pour ce qui disparaît vraiment, plutôt qu’une redirection sans rapport.
• Mettre à jour le nouveau site : une balise canonical qui désigne sa propre adresse sur chaque page, des liens internes qui pointent vers les nouvelles adresses et non vers les anciennes, un nouveau plan du site envoyé dans Search Console.
• Conserver les redirections aussi longtemps que possible, généralement au moins un an, et, du point de vue des visiteurs, envisager de les garder indéfiniment.

Le même guide contient une recommandation qu’on cite rarement, parce qu’elle dérange : ne modifier qu’une seule chose à la fois. Google prend l’exemple d’un site qui change de nom de domaine, de système de gestion et de mise en page, et conseille de faire ces changements l’un après l’autre. Une refonte change presque toujours l’apparence et souvent l’outil. La traduction pratique est simple : si le nom de domaine doit changer, ne le faites pas le même jour que la refonte, et gardez les adresses des pages quand elles peuvent l’être. Une adresse conservée n’a besoin d’aucune redirection.

Le plan de redirection 301, adresse par adresse

Le plan de redirection est un tableau. Une ligne par ancienne adresse, et pour chacune une décision écrite. Il se prépare avant la construction, pas la veille de la mise en ligne : c’est lui qui dit quelles pages le nouveau site doit contenir pour que rien ne se perde.

Où trouver les anciennes adresses. Google en énumère les sources : le plan du site actuel, les statistiques de visite, le rapport « Liens » de Search Console pour les pages qui reçoivent des liens, l’export de votre outil de gestion, et les journaux du serveur sur une période qui tient compte de vos saisons. Ajoutez ce qu’on oublie toujours : les fichiers PDF (fiche technique, tarif, plan d’accès), qui ont souvent des liens vers eux depuis d’autres sites, et les adresses imprimées sur vos documents commerciaux.

Les trois décisions possibles.

Ce à quoi ressemble une table exploitable. L’exemple ci-dessous est une illustration, pas un projet réel : les adresses sont inventées. Il montre les colonnes qu’une table doit avoir pour se tester.

La colonne « Raison » n’est pas décorative. Dans six mois, quelqu’un se demandera pourquoi telle adresse mène là, et la réponse doit être écrite quelque part.

Redirection 301 ou 302 : laquelle pour une refonte ?

Pour une refonte, la réponse est permanente : 301, ou 308. Google l’explique dans sa page sur les redirections : avec une redirection permanente, la page cible devient l’adresse de référence dans ses résultats ; avec une redirection temporaire, l’ancienne adresse peut y rester. Google précise aussi de n’utiliser une redirection permanente que lorsqu’on est certain qu’elle ne sera pas annulée, ce qui est le cas d’une refonte livrée.

Si votre prestataire vous remet un relevé plein de 308, ce n’est pas une erreur. Le socle sur lequel nous construisons produit des 308 pour les redirections permanentes, comme le montre notre propre site plus bas, et Google les traite exactement comme des 301. Ce qui doit vous alerter, c’est un 302 ou un 307.

Comment nous testons les redirections

Écrire une table ne prouve rien. Ce qui compte, c’est ce que le site répond réellement, et une redirection qui fonctionne dans un navigateur peut être une chaîne de trois étapes ou un 302. Chez Trait Neuf, le travail se fait en trois temps.

La capture de l’existant. Avant d’écrire une ligne du nouveau site, l’ancien est parcouru comme le ferait un visiteur, en partant de son plan du site et de ses liens. Pour chaque page, nous gardons une capture d’écran pleine hauteur, son titre, sa description, son adresse canonique, ses intertitres, son texte, ses liens, et chaque image avec une empreinte qui garantit qu’on réutilise exactement le fichier d’origine. Ce parcours ne voit que ce qui est public et atteignable par un lien ou par le plan du site, dans une limite de pages fixée à l’avance : une page que rien ne relie, ou ce qui se trouve derrière une connexion, n’y apparaît pas. L’inventaire est donc croisé avec ce que votre outil de gestion permet d’exporter et avec vos pages les plus visitées.

Une décision par adresse. Chaque page de l’inventaire reçoit l’une des trois décisions du tableau plus haut, avec sa destination et sa raison. Une adresse sans décision bloque la suite : le projet ne passe pas à la mise en ligne tant qu’elle n’en a pas.

Le test, ligne par ligne. Chaque ancienne adresse est demandée au site servi, sans suivre la redirection. Le code obtenu doit être celui de la table. Pour une redirection, l’adresse de destination doit être exactement celle prévue, puis cette destination est demandée à son tour et doit s’afficher directement : si elle redirige encore, c’est une chaîne, et la ligne échoue. Le relevé donne, pour chaque ligne, le code attendu, le code obtenu et le verdict. Le test passe sur la préproduction avant la bascule, et les anciennes adresses sont testées de nouveau une par une après la mise en ligne.

Nous l’avons appliqué à notre propre site. Lors de sa refonte en septembre 2026, six anciennes adresses ont été relevées. Deux sont conservées : l’accueil et la page de confidentialité. Deux pages d’une étude de démonstration ont d’abord été conservées, puis retirées à notre décision quand de vrais clients ont pris leur place : elles répondent aujourd’hui 410, le code d’un contenu supprimé volontairement, que Google traite comme un 404 : la réponse qu’il demande pour un contenu qui disparaît sans remplaçant. Les deux dernières sont redirigées. Elles devaient mener à l’espace client, dont l’entrée renvoie elle-même vers la page de connexion quand on n’est pas connecté, ce qui est le cas de quiconque arrive par un vieux lien. Les faire pointer vers l’entrée aurait créé une chaîne de deux redirections : elles pointent directement vers la page de connexion. Vous pouvez le vérifier : trait-neuf.fr/paiement et trait-neuf.fr/studio répondent aujourd’hui par un 308 vers /espace/connexion, qui s’affiche sans autre étape (relevé du 18 septembre 2026, revérifié le 6 octobre 2026). C’est un petit site, et c’est précisément le point : la règle ne change pas avec la taille.

Le jour de la bascule : ce qui doit changer en même temps

La mise en ligne est le moment où les oublis coûtent le plus, parce que tout se décide en quelques minutes. Cette liste suit l’ordre dans lequel nous la vérifions.

• Le blocage de la préproduction est retiré. Une préproduction doit rester hors de Google, par une balise noindex ou un robots.txt fermé. Le jour J, ces deux verrous doivent sauter sur le site public, et seulement là.
• Chaque page déclare sa propre adresse comme canonique, sur le domaine définitif, et non celle de la préproduction.
• Les liens internes pointent vers les nouvelles adresses. Un lien interne qui passe par une redirection fonctionne, mais il ralentit le visiteur et fait travailler le moteur pour rien.
• Le nouveau plan du site est envoyé dans Search Console. Google indique qu’on peut alors retirer l’ancien.
• Les deux versions sont validées dans Search Console si le domaine change, avec toutes leurs variantes (avec et sans www).
• Les liens que vous contrôlez sont mis à jour : fiche d’établissement, réseaux sociaux, annuaires, signatures d’e-mail, campagnes publicitaires.
• Le courrier électronique continue d’arriver. Si la refonte s’accompagne d’un changement d’hébergement ou de serveurs de noms, les réglages de messagerie doivent suivre. L’Afnic prévient que, lorsqu’un transfert du nom de domaine s’accompagne d’un changement d’hébergement, plusieurs jours peuvent être nécessaires avant que tout soit pris en compte, une dizaine d’heures en moyenne pour les domaines qu’elle gère : une adresse e-mail qui ne reçoit plus rien pendant ce temps est une panne que personne ne voit.

Changer de nom de domaine pendant une refonte

Quand le domaine change, par exemple de ancien-nom.fr vers nouveau-nom.fr, Google met à disposition l’outil de changement d’adresse dans Search Console. Il ne sert qu’à cela, ou au passage d’un sous-domaine à un autre : pas au passage de http à https, ni au passage avec ou sans www, ni à un déplacement de pages à l’intérieur du même domaine.

Ses conditions sont précises. Les deux sites doivent être validés dans Search Console par le même compte, au niveau du domaine, sans chemin après le nom. L’ancienne page d’accueil doit rediriger en 301 vers la nouvelle, et Google recommande de faire de même pour les pages de l’ancien site. Une fois la demande acceptée, une notification de migration reste affichée pendant 180 jours. Google demande de conserver les redirections au moins 180 jours, et plus longtemps tant que des visiteurs arrivent encore par l’ancien domaine. Au terme de ces 180 jours, il ne reconnaît plus aucune relation entre l’ancien et le nouveau site.

Deux conseils de Google qu’on ne lit qu’en bas de page : continuer à payer l’ancien domaine pendant au moins un an, pour qu’un tiers ne l’achète pas et ne s’en serve pas à mauvais escient, et ne pas mener ce changement en même temps que la refonte elle-même.

Après la bascule : ce qu’on surveille, et quand

Une baisse passagère après une refonte est normale. Google l’écrit : la visibilité peut fluctuer pendant une migration, et pour un site de taille moyenne, il peut s’écouler quelques semaines ou plus avant que les nouvelles adresses remplacent les anciennes dans les résultats. Ce qui ne l’est pas, c’est une baisse qui s’installe sur des pages précises.

Trois endroits de Search Console suffisent à la distinguer :

• Le rapport d’indexation des pages. Les anciennes adresses doivent y apparaître en « Page avec redirection », ce qui est le statut attendu. Une ancienne adresse classée « Introuvable (404) » alors qu’elle avait un équivalent est une ligne oubliée dans la table. Google précise qu’il n’existe aucun moyen de lui faire oublier définitivement une adresse, et demande une redirection quand la page a été déplacée.
• Le rapport sur les performances, filtré par page. Comparez la période qui suit la mise en ligne à la même période avant, page par page. Une page dont les clics tombent à zéro pendant que sa remplaçante n’en reçoit aucun signale un problème de redirection ou de contenu.
• L’inspection d’URL, sur deux ou trois nouvelles adresses importantes, pour vérifier que Google les a vues, avec la bonne canonique.

Quand vous corrigez un problème signalé dans le rapport d’indexation, Google indique que la validation prend généralement deux semaines environ, parfois beaucoup plus. Ne modifiez donc pas tout à la fois pendant ce temps : vous ne sauriez plus ce qui a produit l’effet.

Perte de trafic après refonte : le diagnostic quand c’est déjà arrivé

La refonte est en ligne depuis un mois ou six, et les demandes ont baissé. Avant de tout refaire, il faut établir ce qui s’est passé, dans cet ordre.

1. Dater la chute. Dans le rapport sur les performances de Search Console, la baisse commence-t-elle le jour de la mise en ligne, ou plus tard ? Google rappelle qu’une baisse peut avoir d’autres causes : une mise à jour de ses algorithmes, un problème technique sans rapport, un problème de sécurité, une action pour spam, ou simplement la saison. Une chute qui commence trois semaines avant la mise en ligne n’est pas due à la refonte.
2. Retrouver les anciennes adresses. Si aucun inventaire n’a été fait, il se reconstitue : le rapport sur les performances, réglé sur une période antérieure à la refonte, liste les pages qui recevaient des clics ; le rapport « Introuvable (404) » liste celles que Google cherche encore ; les archives du web, comme la Wayback Machine d’Internet Archive, gardent souvent la trace des anciennes pages et de leurs adresses ; votre ancien plan du site, s’il a été sauvegardé, fait le reste.
3. Tester chacune. Pour chaque ancienne adresse retrouvée : que répond-elle aujourd’hui ? Une erreur, une redirection vers l’accueil, un 302, une chaîne ? C’est le même test que celui d’une bascule, appliqué après coup.
4. Comparer les contenus. Pour les pages qui sont bien redirigées mais qui ont perdu leurs positions, mettez côte à côte l’ancienne version (archive ou capture) et la nouvelle. Une page longue et détaillée devenue un paragraphe et une photo ne répond plus aux mêmes recherches, aussi parfaite soit sa redirection.
5. Corriger, puis attendre. Les redirections ajoutées tardivement servent encore : Google continue d’explorer les anciennes adresses pendant un certain temps, et une redirection ajoutée sera vue à son passage suivant. Rien ne garantit en revanche le retour aux positions d’avant, et personne ne peut vous promettre une date. Google lui-même prévient qu’un changement peut produire un effet en quelques jours ou en plusieurs mois.

Ce diagnostic est aussi le bon point de départ si votre site actuel est le résultat d’une refonte ratée et que vous envisagez d’en refaire une. Une nouvelle refonte qui ne commence pas par ce relevé reproduira la perte, en pire, puisqu’elle changera les adresses une deuxième fois.

Faire relire votre plan de redirection

Si vous préparez une refonte avec un autre prestataire, ce guide vous donne de quoi lui demander la table et son relevé de test. Si vous la préparez avec nous, l’inventaire, la table et le test font partie de chaque refonte. Et si la chute a déjà eu lieu, envoyez-nous l’adresse de votre site et la date de mise en ligne de la refonte : nous regardons d’abord ce que répondent vos anciennes adresses, avant de parler de quoi que ce soit d’autre. Nous écrire.