Refonte de site sans perdre de trafic : la séquence

Une refonte de site ne préserve le trafic que si les URL, les contenus qui reçoivent des liens et les redirections sont traités comme des décisions, pas comme des conséquences du nouveau design. SiteBienfait construit la refonte à côté de l’ancien site, vérifie chaque adresse, puis bascule.

Pourquoi une refonte fait-elle perdre du trafic ?

Trois causes, presque toujours les mêmes. Des URL qui changent sans redirection : les anciennes adresses répondent 404, et les signaux qu’elles portaient disparaissent. Des contenus qui disparaissent parce qu’ils ne rentraient pas dans la nouvelle maquette. Un rendu qui dépend du JavaScript alors que l’ancien site servait du HTML complet, ce qui peut retarder ou empêcher la lecture par un crawler. Google documente les exigences techniques minimales pour qu’une page reste éligible (Google, documentation Search Central, consultée le 11 novembre 2026). Une refonte qui les ignore crée elle-même le problème qu’elle prétend résoudre.

Faut-il changer les URL pendant une refonte ?

Le moins possible. Une refonte réussie peut conserver l’intégralité des URL existantes : c’est la solution la plus sûre, et souvent la moins coûteuse à expliquer. Quand un changement de structure est réellement nécessaire, il se traite comme une migration : inventaire des anciennes URL, table de redirections, contrôle avant bascule. La table se vérifie avec le vérificateur de plan de redirections. Changer des URL pour des raisons esthétiques est un mauvais échange : le bénéfice est nul pour le visiteur, le risque est réel pour l’indexation.

Comment protéger les pages qui reçoivent des liens ?

On identifie les pages qui comptent avant de dessiner quoi que ce soit : celles qui reçoivent des liens externes, celles qui portent les impressions et les clics, celles qui répondent aux questions fréquentes. Ces pages gardent leur adresse et leur contenu, même si la maquette change. Une page qui n’a ni lien, ni impression, ni rôle de conversion peut être supprimée, mais la décision se prend sur des données, pas sur une impression visuelle. Les contenus qui ont du trafic se déplacent rarement sans coût : une page qui cible une requête depuis trois ans n’est pas interchangeable avec une page neuve.

Dans quel ordre livrer les changements ?

La séquence qui limite le risque est stable. D’abord le socle technique : URL, redirections, indexation, sitemap. Ensuite le contenu : titres, réponses, liens internes. Puis la performance : images, polices, scripts. Enfin le design et les composants, une fois que le trafic est stable sur la nouvelle structure. Cet ordre n’est pas une préférence esthétique : il permet de mesurer chaque étape séparément. Une refonte livrée en un seul bloc ne permet pas de savoir ce qui a causé une baisse, ni quoi rollbacker. Le parcours de refonte de site de SiteBienfait organise cette livraison avec une préproduction et une approbation avant chaque étape.

Que contrôler après la refonte ?

L’indexation des pages, les URL « Page avec redirection », les codes 404 anormaux, le sitemap traité et les performances de recherche comparées à la référence d’avant. On vérifie aussi que les pages qui recevaient des liens répondent toujours, et que les liens internes ne pointent plus vers des adresses mortes. Google recommande de traiter chaque URL modifiée comme un déplacement permanent et de surveiller l’indexation après la bascule (Google, documentation Search Central sur les déplacements de site, consultée le 11 novembre 2026). Un contrôle sérieux prend des semaines, pas une soirée.

Le design compte-t-il pour le référencement ?

Il compte pour le visiteur, et indirectement pour les signaux d’expérience, mais il ne remplace ni une adresse conservée ni un contenu utile. Un nouveau design peut dégrader les Core Web Vitals s’il ajoute des scripts, des polices ou des animations lourdes ; il peut aussi améliorer la lisibilité et réduire le rebond. Ces effets se mesurent avec des données réelles, pas avec une intuition. La priorité reste donc : conserver les adresses, conserver les contenus qui comptent, puis améliorer le rendu. Pour la suite logique, voir Core Web Vitals pour une petite entreprise.

Sources

• Google Search Central, « Move a site with URL changes », documentation consultée le 11 novembre 2026 : developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Google Search Central, « Search Essentials : technical requirements », documentation consultée le 11 novembre 2026 : developers.google.com/search/docs/essentials/technical
• web.dev, « Core Web Vitals », article consulté le 11 novembre 2026 : web.dev/articles/vitals