Une refonte de site se rate rarement sur le design. Elle se rate sur ce que personne ne regarde : une adresse oubliée, un formulaire qui n’envoie plus rien, un site resté fermé à Google le lendemain de sa mise en ligne. Cette checklist de refonte de site réunit les 20 contrôles que nous appliquons avant, pendant et après la bascule, pour un site vitrine comme pour une boutique.
Nous l’avons passée au banc d’essai sur notre propre site en octobre 2026, lors d’une refonte menée avec un assistant IA et racontée dans notre bilan technique. Chaque point vient donc avec ce qu’il nous a appris et avec la façon de le vérifier vous-même. Aucun ne demande d’être développeur ; la plupart demandent un tableur et un peu d’obstination.
Avant de lancer une refonte : six décisions
Ces six points se règlent avant le premier devis. Ils en changent le contenu, et deux d’entre eux, la mesure et l’inventaire, ne se rattrapent pas : une fois l’ancien site débranché, il est trop tard.
- Écrire l’objectif en une phrase. « Recevoir plus de demandes », « rendre l’équipe autonome sur les pages », « diviser le temps de chargement par deux ». Une seule phrase, affichée. Le jour où il faudra choisir entre une animation et une seconde de chargement, c’est elle qui tranchera, et non le dernier qui a parlé.
- Mesurer l’existant, tant qu’il existe. Poids des pages, scores Lighthouse, positions, pages les plus vues, nombre de demandes par mois. Faites des captures et datez-les. Sans ce relevé, personne ne pourra dire ce que la refonte a changé, vous compris.
- Dresser l’inventaire des adresses. Pas celles du menu : celles que Google connaît. Exportez les plans de site et la liste des pages de la Search Console, fusionnez, dédoublonnez. Notre site, de taille modeste, en comptait 171, bien plus que ce que nous aurions cité de mémoire. Cette liste est le fil rouge de tout ce qui suit.
- Décider ce qui change d’adresse, et pourquoi. Une adresse qui change est une page que Google doit redécouvrir. « La nouvelle arborescence est plus jolie » n’est pas une raison. Gardez tout ce qui peut l’être, et notez chaque exception avec son motif.
- Fixer un budget de performance. Un poids maximal de code par page et un score minimal, écrits avant la première maquette. Le nôtre : 40 Ko de CSS, 5 Ko de JavaScript, 95 sur Lighthouse. Il a servi tout de suite : le bloc de navigation standard de WordPress pèse 18,5 Ko de JavaScript avec son menu mobile, soit plus de trois fois le budget à lui seul. Nous avons écrit le nôtre. Sans budget, nous l’aurions gardé sans le savoir.
- Lister tout ce qui est branché sur le site. Mesure d’audience, formulaires, lettre d’information, publicité, paiement, prise de rendez-vous. Pour chacun : qui a les accès, et comment saura-t-on qu’il fonctionne encore ? C’est la liste que l’on cherche partout le jour de la mise en ligne.
Pendant la construction : huit contrôles
Les adresses et le référencement
- Travailler sur une copie fermée aux moteurs. Une préproduction indexée par erreur concurrence votre propre site, avec vos propres textes. Fermez-la par un mot de passe ou un mode maintenance, pas par une simple case « ne pas indexer » que tout le monde oubliera.
- Écrire le plan de redirections. Un tableau à deux colonnes : l’ancienne adresse, la nouvelle. Chaque ligne pointe vers la page qui remplace vraiment l’ancienne. Tout renvoyer vers l’accueil revient à dire à Google que la page a disparu.
- Chercher les redirections que vous n’avez pas écrites. Un site qui a dix ans en a accumulé partout : dans une extension, dans une autre, dans la configuration du serveur. Chez nous, deux articles tournaient en boucle à cause de deux lignes d’un fichier du serveur, que ni WordPress ni ses extensions ne montraient. Cela ne se trouve qu’en testant les adresses une par une, par script.
- Corriger les liens internes, puis relire les titres. Un lien qui passe par une redirection fonctionne, mais il ralentit la page et vieillit mal : 22 de nos articles pointaient encore vers d’anciennes adresses. Reprenez au passage les titres et les descriptions à partir des recherches réelles relevées dans la Search Console, pas à partir de la maquette.
Ce que le visiteur reçoit vraiment
- Tester chaque formulaire jusqu’au bout. Jusqu’à la boîte de réception, pas jusqu’au message « merci ». Posez ensuite la question qui fâche : si le service d’envoi d’e-mails tombe, la demande est-elle perdue ? La nôtre est enregistrée d’abord, transmise ensuite. Et refaites l’essai le lendemain : un formulaire peut fonctionner sur une page fraîche et refuser l’envoi sur la même page sortie du cache.
- Charger les pages comme un vrai navigateur. Entre votre code et l’écran du visiteur, d’autres ajoutent des choses : le réseau de diffusion, l’hébergeur, une extension. Sur notre préproduction, une page affichait 55 de performance au lieu des 99 attendus. Le code n’avait pas bougé ; des scripts étaient ajoutés en route, et un contrôle simplifié ne les voyait pas. Mesurez la page servie, pas la page écrite.
- Ne pas se contenter d’un code 200. « La page répond » ne veut pas dire « la page affiche son contenu ». Pendant la construction, notre page du journal répondait parfaitement, et elle était vide. Un contrôle sérieux vérifie qu’un élément attendu est bien là : un titre, un nombre d’articles, un prix.
- Vérifier l’accessibilité et le consentement. Contrastes, navigation au clavier, textes alternatifs : c’est une obligation pour de nombreux sites depuis la loi européenne sur l’accessibilité. Pour le consentement, ouvrez la page en navigation privée et regardez ce qui se charge avant le moindre clic : rien ne doit partir vers un outil de mesure ou de publicité.
Le jour de la mise en ligne
Trois gestes, dans cet ordre.
- Sauvegarder l’ancien site, et vérifier que la sauvegarde se relit. Fichiers et base de données. Une sauvegarde que personne n’a jamais restaurée est un espoir, pas un retour arrière.
- Geler les publications. Tout ce qui est publié sur l’ancien site entre la dernière copie et la bascule disparaît. Prévenez l’équipe par écrit, avec l’heure de début et l’heure de fin.
- Rouvrir l’indexation. La préproduction était fermée aux moteurs ; le nouveau site ne doit pas l’être. Le piège : rien ne le signale à l’écran. Un site resté fermé s’affiche tout à fait normalement, et son trafic baisse sans bruit pendant des semaines. Ouvrez le fichier robots.txt et le code source de l’accueil, et cherchez « noindex ».
Après la bascule : vérifier, puis suivre
- Rejouer l’inventaire complet. Chaque adresse du point 3 doit aboutir à une page. Chez nous, les 171 aboutissent : 110 directement, 61 par une redirection. C’est le contrôle le plus rassurant de la liste, et il prend quelques minutes quand l’inventaire existe.
- Vider les caches, puis relire le plan de site. Un site a souvent plusieurs caches empilés (nous en comptons trois devant une même page), et chacun peut resservir l’ancienne version à son tour. Relisez ensuite le plan de site ligne à ligne avant de l’envoyer dans la Search Console : le nôtre contenait encore un type de contenu de l’ancien thème, retiré le jour même.
- Suivre pendant plusieurs semaines, et garder les redirections. Surveillez l’indexation et les erreurs d’exploration, sans conclure au bout de trois jours. Google recommande de conserver les redirections aussi longtemps que possible, en général au moins un an.
Une refonte fait-elle perdre son référencement ?
Pas si elle est préparée, mais attendez-vous à des variations, et ne paniquez pas à la première. Google l’écrit lui-même : pendant une migration, le classement d’un site peut fluctuer, et il peut s’écouler quelques semaines ou plus avant que les nouvelles adresses s’affichent dans les résultats.
Le risque ne s’annule donc pas, il se réduit. C’est tout l’objet des points 3, 8, 18 et 20 : savoir ce que l’on avait, dire à Google où chaque page est partie, vérifier que rien ne manque, puis laisser le temps faire. C’est l’approche que nous avions suivie pour Le China, dont le site a changé sans perdre son référencement.
Par où commencer
Par les points 2 et 3, dès cette semaine. Mesurer l’existant et relever vos adresses ne demande ni budget ni prestataire, seulement un accès à la Search Console et une heure tranquille. Vous n’aurez plus l’occasion de le faire une fois le nouveau site en ligne. Le reste se déroule ensuite avec la personne ou l’agence qui construira le site.
Vingt points ne font pas une refonte : ils évitent les pertes, ils ne disent ni quoi construire ni pour qui. Pour cette partie-là, parlons-en. Appelez-nous au 01 83 64 66 39, écrivez à [email protected], ou passez nous voir au 21 rue Greneta, à Paris : le café est pour nous. Nous répondons sous 24 heures, et une demi-heure suffit pour voir lesquels de ces vingt points sont déjà couverts chez vous. Notre façon de travailler est décrite sur la page Développement web.

