Refonte de site : la méthode pour ne pas perdre son référencement

Une refonte peut faire disparaître en quelques jours une visibilité construite pendant des années. Ce n'est pas la refonte elle-même qui fait perdre des positions, mais ce qu'elle casse au passage : des adresses qui changent sans redirection, des contenus supprimés, des pages devenues inaccessibles.

Bien préparée, une refonte peut au contraire améliorer le référencement. Voici la méthode, avec l'exemple concret de la refonte de ce site.

Pourquoi une refonte fait perdre du trafic

Google ne classe pas des « sites », mais des adresses (URL). Chaque page qui apparaît dans les résultats a accumulé des signaux : des liens venant d'autres sites, un contenu jugé pertinent pour certaines recherches, un historique. Si son adresse change sans redirection, Google trouve une erreur 404 à la place, et les liens qui pointaient vers elle mènent dans le vide.

Les causes de perte les plus fréquentes :

• des adresses modifiées sans redirection ;
• des contenus raccourcis ou supprimés, qui répondent moins bien aux recherches qu'avant ;
• des balises perdues : titres, descriptions, balises canoniques, données structurées ;
• une consigne noindex du site de préproduction mise en ligne avec le nouveau site ;
• des pages qui ne sont plus reliées entre elles par des liens internes.

Avant : inventorier ce qui vous rapporte déjà

Les pages qui reçoivent des visites et des liens

Avant la première maquette, dressez la liste de ce qu'il faut protéger :

• dans Search Console, rapport Performances, onglet Pages : les pages qui reçoivent des clics et des impressions, sur les douze derniers mois ;
• dans le rapport Liens de Search Console : les pages les plus liées depuis d'autres sites ;
• la liste complète des adresses du site actuel, obtenue avec un logiciel d'exploration (Screaming Frog, par exemple, explore gratuitement jusqu'à 500 adresses).

Les requêtes à protéger

Pour chaque page importante, notez les recherches qui y mènent (onglet Requêtes, filtré sur la page). La nouvelle version de la page devra toujours y répondre : si un paragraphe attirait des visiteurs, le supprimer au nom d'un design plus épuré revient à renoncer à ces visites.

Garder ou changer les URL : la décision qui compte le plus

La règle est simple : conserver chaque adresse qui peut l'être. Changer une adresse lisible n'apporte presque rien en référencement, alors que le risque, lui, est réel.

Un changement se justifie quand :

• l'ancienne adresse est illisible (/page.php?id=123) ;
• le contenu change réellement de nature ;
• plusieurs pages sont fusionnées en une seule ;
• le site devient multilingue, et chaque langue a besoin de ses propres adresses.

Ce site en offre un exemple. Ses premières pages s'appelaient /about et /projects, en anglais, alors que le site est en français. Tant qu'il n'existait qu'en français, les traduire n'aurait rien apporté en référencement : Google comprend ces mots, et il aurait fallu rediriger des adresses peut-être partagées depuis longtemps (LinkedIn, CV, e-mails). Elles ont donc d'abord été conservées.

La décision a changé quand une version anglaise du site a été prévue : /about devra alors désigner la page anglaise, et mélanger les langues dans les adresses rendrait la structure confuse, pour les visiteurs comme pour Google. Les adresses françaises sont devenues /a-propos et /projets, avec une redirection permanente depuis les anciennes. Un changement d'adresse justifié par une raison structurelle, pas par une question de goût.

Construire le plan de redirection 301

Une ancienne URL, une nouvelle URL

Le plan de redirection est un simple tableau :

Ancienne adresse	Nouvelle adresse	Raison	Testée
/nos-services.html	/services	Même contenu, nouvelle structure	Oui
/equipe	/a-propos	Pages fusionnées	Oui

Chaque ancienne adresse renvoie vers la page la plus équivalente du nouveau site. S'il n'existe vraiment aucun équivalent, la page parente la plus proche fait l'affaire pour le visiteur.

Les erreurs fréquentes

• Des redirections temporaires (302, 307) au lieu de permanentes. Google recommande des redirections permanentes, telles que 301 et 308 : une redirection temporaire annonce que l'ancienne adresse reviendra.
• Des chaînes (A redirige vers B, qui redirige vers C). Envoyez directement vers la destination finale.
• Tout rediriger vers l'accueil. Google déconseille de rediriger en masse les anciennes adresses vers une même page, comme l'accueil : il peut les traiter comme des pages supprimées (erreurs « soft 404 »).
• Oublier les variantes : avec et sans www, http et https, avec et sans barre oblique finale.
• Oublier les fichiers : PDF, images bien positionnées dans Google Images.

Le jour de la mise en ligne : la check-list

1. Retirez la consigne noindex et le blocage du fichier robots.txt hérités de la préproduction.
2. Testez chaque ligne du plan de redirection : code 301 ou 308, destination directe, sans chaîne.
3. Vérifiez sur les pages principales le titre, la description, la balise canonique et le titre principal (H1).
4. Déclarez le nouveau sitemap dans Search Console.
5. Demandez l'indexation des pages principales avec l'outil d'inspection d'URL.
6. Envoyez-vous une demande depuis le formulaire de contact, et vérifiez vos outils de mesure.

Après : ce qu'il faut surveiller

Les variations sont normales pendant quelques semaines, le temps que Google explore à nouveau le site. Surveillez :

• le rapport Pages de Search Console : nouvelles erreurs 404, pages exclues de l'index ;
• le rapport Performances : clics et impressions par page, comparés à la période précédant la refonte ;
• les redirections elles-mêmes : Google recommande de les conserver aussi longtemps que possible, généralement au moins un an.

Si une page importante perd durablement ses positions, comparez son ancienne et sa nouvelle version : un contenu qui a disparu en est souvent la cause.

Exemple : la refonte de ce site

En octobre 2026, j'ai resserré ce portfolio : dix pages de projets anciens et la page Expérience ont été retirées. Puis, en préparant la version anglaise, les adresses restées en anglais ont été traduites. Enfin, les projets ont perdu leur page individuelle : un clic sur un projet ouvre désormais directement le site réalisé. Chaque ancienne adresse a reçu une redirection permanente :

Ancienne adresse	Nouvelle adresse	Pourquoi
Les 10 pages /projects/… retirées	/projets	Pas d'équivalent : la liste des projets est la page la plus proche
/experience	/a-propos	Le parcours se lit désormais sur la page À propos
/about	/a-propos	Adresse traduite avant la version anglaise
/projects	/projets	Adresse traduite avant la version anglaise
Chaque page de projet (/projects/…, /projets/…)	/projets	Les projets s'ouvrent directement sur leur site : la liste est la page la plus proche

Quand /about est devenu /a-propos, la redirection de /experience, qui pointait vers /about, a été modifiée pour pointer directement vers /a-propos. Sans cette correction, un visiteur arrivé par l'ancienne adresse aurait traversé deux redirections successives : c'est la chaîne à éviter.

Le site est construit avec Next.js, qui utilise le code 308, l'équivalent moderne du 301. Pour les dix projets, la redirection vers la liste est un choix assumé : ces pages n'avaient pas d'équivalent, et l'objectif était d'orienter les visiteurs qui arrivent par un ancien lien, pas de transmettre leur référencement.

La même refonte a corrigé une incohérence entre la version avec www et la version sans www du site, détaillée dans le guide pour un site absent de Google.

Une refonte se prépare donc bien avant le design : c'est l'inventaire de l'existant qui décide de ce qui peut changer. C'est le point de départ de chaque refonte de site web que je mène. Et si vous hésitez entre corriger votre site et le refaire, un audit permet de trancher.