Refaire son site sans perdre son référencement : la méthode, adresse par adresse

Quand on déménage, on peut repeindre, changer les meubles, abattre une cloison. Personne ne s'en plaindra. Ce qui fait perdre des clients, c'est d'oublier de faire suivre le courrier.

Un site, c'est pareil. Google se moque de ta nouvelle palette de couleurs. Il connaît ton site par ses adresses : chaque URL qui a gagné un peu de confiance au fil des années est une boîte aux lettres. Une refonte qui casse ces adresses repart de zéro, même avec un meilleur contenu.

J'ai récemment refait le site d'un cabinet d'expertise comptable : nouveau code, nouveau CMS, nouvel hébergement, même domaine. Le site est passé de l'ancien hébergement au nouveau sans qu'une seule ancienne adresse ne tombe en erreur. Voici la méthode, dans l'ordre où je l'ai appliquée.

Ce qui fait réellement chuter le trafic

Avant la méthode, il faut savoir ce qu'on protège. Quand une refonte fait perdre du trafic, la cause est presque toujours l'une de celles-ci :

• des URLs qui disparaissent : l'ancien article /blog/creation-sas n'existe plus, et personne n'a pensé à le rediriger ;
• des contenus réécrits sans raison : un texte qui se positionnait bien est « rafraîchi », et perd ce qui le faisait remonter ;
• une indexation bloquée par accident : le noindex de la version de démonstration part en production ;
• une bascule technique ratée : le site est inaccessible quelques heures, ou les e-mails du domaine cessent d'arriver.

Aucune de ces causes ne tient au design. Toutes tiennent à l'inventaire et à la procédure. C'est une bonne nouvelle : ça se prévient.

Étape 1 : l'inventaire, avant la première ligne de code

On ne protège pas ce qu'on n'a pas listé. Sur ce projet, l'ancien site comptait 36 pages publiques. Je les ai toutes relevées, avec trois informations par adresse :

1. l'URL exacte, telle qu'elle est indexée ;
2. son titre et sa description actuels ;
3. sa destination dans le nouveau site.

Cette troisième colonne est celle qui compte. Chaque ancienne adresse doit avoir une réponse : soit elle existe à l'identique, soit elle redirige en 301 vers la page qui la remplace. « On verra » n'est pas une réponse.

J'ai aussi archivé les 36 pages telles qu'elles étaient, avec une empreinte de chaque fichier. Pas pour la nostalgie : quand quelqu'un demande trois semaines plus tard « il n'y avait pas un paragraphe sur les holdings, avant ? », la réponse doit être vérifiable, pas une impression.

Étape 2 : garder les mêmes adresses chaque fois que c'est possible

La meilleure redirection est celle qu'on n'a pas besoin de faire.

Les 11 anciens articles du blog et 9 pages complémentaires ont été repris aux mêmes adresses, dans le nouveau CMS. Une redirection 301 transmet l'essentiel de la valeur d'une page, mais pas tout, et elle ajoute un saut à chaque visite. Une URL identique ne perd rien.

Deuxième règle, plus difficile à tenir : les anciens textes ont été conservés tels quels. Pas réécrits, pas « optimisés ». La tentation est forte, surtout quand on refait tout le reste. Mais un article qui ramène des visites depuis deux ans le fait pour des raisons qu'on ne connaît pas toujours. On l'améliore plus tard, une page à la fois, en mesurant l'effet. Jamais pendant la migration.

Étape 3 : construire à côté, jamais à la place

Le nouveau site a été construit et testé sans toucher à l'ancien. Il tournait sur le nouveau serveur, dans son conteneur, sans être exposé sur le domaine public. L'ancien site restait en ligne, intact.

Ce point paraît évident. Il ne l'est pas : beaucoup de refontes se font « en direct », en remplaçant les pages une à une sur le serveur de production. Le jour où quelque chose casse, il n'y a plus d'état antérieur où revenir.

Avec deux sites côte à côte, le retour arrière tient en une ligne : on ne bascule pas.

Étape 4 : une recette qui vérifie des faits, pas des impressions

« J'ai cliqué un peu partout, ça a l'air bon » n'est pas une recette. Sur la version candidate, avant toute bascule, j'ai vérifié pour chacune des 36 anciennes adresses :

• qu'elle répond normalement (ou redirige là où prévu) ;
• que le titre H1 est présent et unique ;
• que l'URL canonique pointe vers elle-même, sur le bon domaine ;
• que les données structurées sont valides ;
• qu'aucun lien interne rencontré n'aboutit à une erreur.

Puis des contrôles transverses : un sitemap de 42 URLs, cohérent avec ce qui existe réellement ; pas de noindex global en production, mais bien sur la démonstration ; aucune page qui déborde horizontalement sur un écran de téléphone de 390 pixels.

Et un contrôle qu'on oublie souvent : j'ai parcouru les 68 fichiers construits pour vérifier qu'aucune clé privée (formulaire, CRM, CMS) ne s'y trouvait. Un site statique publie tout ce qu'on lui donne. Une clé d'écriture du CMS dans un fichier JavaScript public, c'est un site que n'importe qui peut modifier.

Étape 5 : la bascule DNS, la partie qui fait peur

Le domaine reste le même, on change seulement le serveur vers lequel il pointe. C'est l'étape la plus courte, et celle où les erreurs coûtent le plus cher, parce qu'elles ne se voient pas tout de suite.

Baisser les TTL, puis attendre

Chaque enregistrement DNS porte une durée de vie (TTL) : le temps pendant lequel les résolveurs du monde entier gardent l'ancienne réponse en cache. Ici, elle était de 24 heures.

Si tu changes l'adresse du serveur avec un TTL de 24 heures, une partie de tes visiteurs verra l'ancien site pendant une journée. Si ça se passe mal, ton retour arrière mettra aussi une journée à se propager.

Donc : on baisse le TTL à 5 minutes d'abord, et on attend au moins l'ancien TTL, soit 24 heures. Pas les 5 minutes du nouveau : les caches qui ont lu l'ancienne valeur la garderont jusqu'au bout.

Ne toucher qu'à ce qu'on bascule

Un domaine ne sert pas qu'au site. Ce cabinet y faisait aussi passer sa messagerie : enregistrements MX, SPF, DKIM, DMARC, plus deux validations de services Google. Un fichier de zone modifié à la hâte, et les e-mails du cabinet cessent d'arriver. On s'en aperçoit le lundi, quand un client demande pourquoi personne ne répond.

J'ai relevé les 23 enregistrements de la zone avant de toucher à quoi que ce soit, et contrôlé après chaque import que les valeurs de messagerie étaient inchangées.

Le relevé a fait apparaître un piège : trois sous-domaines anciens étaient des alias du domaine principal. Ils l'auraient suivi vers le nouveau serveur, qui ne les connaissait pas. Ils ont été traités à part, au lieu de basculer par accident.

Le certificat avant la bascule, pas après

Le certificat HTTPS du nouveau serveur a été obtenu avant que le domaine n'y pointe, par validation DNS. Sinon, les premières minutes après la bascule, les visiteurs tombent sur un avertissement de sécurité : le pire accueil possible pour un cabinet comptable.

Garder l'ancien hébergement en vie

Après la bascule, l'ancien hébergement est resté actif. Certains réseaux gardent l'ancienne adresse en cache plus longtemps que prévu : sur ma propre machine, le résolveur local affichait encore l'ancien site lors du premier contrôle. On ne résilie l'ancien que lorsque la période de surveillance est terminée.

Étape 6 : après la bascule, surveiller ce qui ne se voit pas

Le site s'affiche ? Bien. Ce n'est pas la fin.

• Search Console : soumettre le nouveau sitemap. Pas de demande de changement d'adresse, puisque le domaine n'a pas changé.
• Les 404 : les surveiller pendant plusieurs semaines. Une adresse oubliée dans l'inventaire finit toujours par apparaître là.
• Les formulaires : un envoi réel, de bout en bout, jusqu'à la boîte de réception. Un formulaire qui s'affiche correctement peut ne rien envoyer.
• La messagerie : un test d'envoi et de réception sur le domaine, pas seulement la lecture des enregistrements DNS.

Bonus : publier sans casser

Une dernière chose, qui protège le référencement dans la durée. Le cabinet publie ses articles dans le CMS. Chaque publication déclenche la construction d'une nouvelle version candidate, qui passe les contrôles (pages, titres, SEO) avant de remplacer la version en ligne.

Lors de la recette, j'ai volontairement fait échouer une candidate : le site en ligne n'a pas bougé. Un article mal saisi ne doit jamais pouvoir faire tomber le site entier.

Ce qu'il faut retenir

Une refonte ne fait pas perdre le référencement. Ce qui le fait perdre, c'est l'improvisation :

1. Liste toutes les anciennes adresses et donne à chacune une destination.
2. Garde les URLs identiques chaque fois que possible, redirige en 301 sinon.
3. Ne réécris pas les contenus qui fonctionnent pendant la migration.
4. Construis à côté, jamais à la place.
5. Vérifie des faits : titres, canoniques, données structurées, liens, sitemap.
6. Baisse les TTL et attends l'ancien, garde la messagerie intacte, obtiens le certificat avant.
7. Garde l'ancien hébergement jusqu'à la fin de la surveillance.

Rien de tout ça n'est spectaculaire. C'est justement pour ça qu'on le saute, et qu'on le paie trois mois plus tard dans les statistiques.

Si le sujet t'intéresse plus largement, j'ai écrit sur ce que les moteurs et les IA lisent vraiment d'un site, et sur ce qui arrive quand un site perd ses données sans le dire.

Le site du cabinet est en ligne, et le projet est décrit ici. Tu prépares une refonte et tu as peur de perdre ce que ton site a gagné ? Écris-moi : je commence toujours par l'inventaire.