Refonte de site web : comment refaire son site sans perdre son référencement

Le vrai risque d’une refonte de site web n’est pas esthétique, il est invisible. On peut refaire entièrement le design d’un site sans perdre un seul visiteur, et on peut aussi faire disparaître trois ans de référencement en une nuit, simplement en changeant les adresses des pages sans les rediriger. La différence tient à quelques heures de préparation. Ce guide explique quand une refonte est justifiée, et surtout comment la mener sans rien perdre.

Faut-il vraiment tout refaire ?

Avant la méthode, une question honnête : la refonte est-elle la bonne réponse ? Dans un cas sur deux, ce que le client appelle « refonte » est en réalité un problème ciblé qui se corrige pour bien moins cher.

Les six signaux qui justifient une refonte

Le site n’est pas utilisable sur téléphone. Pas « moins joli » : inutilisable. Les boutons se chevauchent, il faut zoomer pour lire, le menu ne s’ouvre pas. C’est le seul signal qui, à lui seul, justifie une refonte complète, parce que la majorité de tes visiteurs sont sur mobile.

La technologie n’est plus maintenue. Un thème abandonné depuis des années, un constructeur de pages qui n’est plus mis à jour, une version de PHP obsolète que l’hébergeur va couper. Là, le sursis a une date de fin.

Tu ne peux rien modifier toi-même. Si changer un numéro de téléphone impose d’appeler quelqu’un et d’attendre une semaine, le site est un obstacle, pas un outil.

La structure ne correspond plus à ton activité. Tu vends trois services alors que le site en présente un, ou l’inverse. Réorganiser l’arborescence d’un site mal structuré coûte souvent plus cher que de repartir proprement.

Le site a été piraté plusieurs fois. Un site compromis à répétition contient souvent des portes dérobées qu’un nettoyage ne retire jamais complètement. La reconstruction sur une base saine devient la seule option raisonnable.

Il est structurellement lent. Attention, ce signal est le plus mal utilisé. Un site lent à cause d’images non optimisées ou d’un cache absent se corrige en une journée. Un site lent parce qu’il empile quarante extensions et trois constructeurs de pages, c’est autre chose.

Quand une simple mise à jour suffit

À l’inverse, voici ce qui ne justifie pas de tout refaire :

• Le site te paraît démodé, mais il fonctionne et convertit. Un rafraîchissement des couleurs, des polices et des photos change plus que tu ne crois, pour une fraction du prix.
• Il ne convertit pas assez. Ce sont les textes, les appels à l’action et les preuves de confiance qu’il faut travailler, pas le code.
• Il n’apparaît pas sur Google. Une refonte ne règle pas ça toute seule ; elle peut même aggraver la situation. C’est un travail de contenu et de structure.
• Une seule page te déplaît. Refais cette page.

Si tu hésites, un critère simple : une refonte se justifie quand le problème est dans les fondations, pas dans la décoration.

Ce qui se passe quand on ne prépare rien

Le cas typique que je reprends ressemble à ceci. Une entreprise refait son site. Le nouveau est plus beau, plus rapide, tout le monde est content. Trois semaines plus tard, le dirigeant remarque que le téléphone sonne moins. Deux mois plus tard, il constate que son site a disparu de Google sur les recherches qui lui amenaient des clients.

Ce qui s’est passé est mécanique. L’ancien site avait des adresses du type /services/depannage-informatique-casablanca/, que Google avait indexées et positionnées pendant des années. Le nouveau site a des adresses différentes : /nos-prestations/depannage/. Personne n’a fait le lien entre les deux. Google envoie donc ses visiteurs vers des pages qui renvoient une erreur 404, constate que ces pages n’existent plus, et finit par les retirer de son index. L’autorité accumulée par ces adresses ne se transfère nulle part : elle est simplement perdue.

Le pire est que rien ne prévient. Le site fonctionne, il est joli, aucun message d’erreur n’apparaît. La perte est silencieuse et se mesure des semaines plus tard, quand il est déjà difficile de revenir en arrière.

J’ai vécu cette contrainte de l’intérieur en refaisant mon propre site : je suis passé d’un WordPress à une technologie entièrement différente, en conservant chacune des adresses existantes, article par article. Ce n’est pas la partie glorieuse du projet, c’est celle qui a demandé le plus de rigueur, et c’est la seule qui garantissait de ne rien perdre.

La méthode en 7 étapes

Étape 1 : inventorier avant de toucher à quoi que ce soit

C’est l’étape que tout le monde saute, et sans elle rien n’est vérifiable ensuite.

Récupère la liste complète de tes adresses actuelles, en croisant trois sources :

• Ton sitemap : tonsite.ma/sitemap.xml ou sitemap_index.xml. Il liste ce que tu publies.
• Google Search Console, rapport « Indexation des pages » : il liste ce que Google connaît réellement, y compris des adresses que tu as oubliées ou que tu ne soupçonnes pas.
• Un outil de crawl gratuit, qui parcourt ton site comme un robot et suit tous les liens.

L’union de ces trois listes est ton inventaire de départ. Mets-la dans un tableur, une adresse par ligne.

Ajoute ensuite une colonne décisive : le trafic de chaque page. Dans Search Console, rapport Performances, onglet Pages, sur les douze derniers mois. Tu découvriras presque toujours que vingt pour cent des pages apportent quatre-vingts pour cent des visiteurs, et que certaines de ces pages ne sont pas celles que tu croyais. Ce sont elles qu’il faut protéger en priorité.

Si tu ne sais pas encore lire ces rapports, le guide Search Console couvre exactement cette manipulation.

Étape 2 : décider ce qu’on garde

Pour chaque adresse de la liste, une décision et une seule :

Décision	Quand	Conséquence
Conserver l’adresse	La page existe toujours sur le nouveau site	Rien à faire, cas idéal
Rediriger	L’adresse change, le contenu reste	Redirection 301 vers la nouvelle adresse
Fusionner	Plusieurs pages traitent le même sujet	301 des secondaires vers la principale
Supprimer	Contenu obsolète sans équivalent	404 assumée, pas de redirection vers l’accueil

Le principe le plus important de tout ce guide : garde les mêmes adresses chaque fois que c’est possible. Une refonte visuelle n’oblige jamais à changer les adresses. Si ton prestataire te dit le contraire, demande pourquoi, et exige une raison technique précise.

Étape 3 : conserver le contenu qui fonctionne

La tentation, en refaisant un site, est de tout réécrire « puisqu’on y est ». C’est un piège.

Les pages qui te rapportent des visiteurs sont positionnées grâce à leur contenu. Le raccourcir, le reformuler ou le remplacer par un texte plus court et plus joli fait perdre les positions, même si l’adresse ne change pas. Google a apprécié un texte précis, qui répondait à une question ; s’il disparaît, la raison de te classer disparaît avec lui.

Concrètement, sur les pages qui reçoivent du trafic : conserve la balise titre, la structure des sous-titres et l’essentiel du texte. Améliore la mise en page, ajoute, réorganise, mais ne supprime pas. Sur les pages sans trafic, tu es libre.

Étape 4 : préparer le plan de redirections

Ton tableur devient un plan de redirections : ancienne adresse dans une colonne, nouvelle adresse dans l’autre. Quelques règles apprises à la dure :

• Une redirection par page, vers son équivalent réel. Rediriger l’ensemble d’un ancien site vers la page d’accueil est l’erreur classique : Google traite ces redirections comme des pages introuvables déguisées, et le visiteur qui cherchait une information précise atterrit nulle part.
• Toujours du 301, jamais du 302. Le 301 est permanent et transfère l’autorité ; le 302 est temporaire et ne le fait pas de la même façon. Google documente précisément les types de redirections et leur effet.
• Pas de chaînes de redirections. Si A pointe vers B qui pointe vers C, fais pointer A directement vers C.
• Attention à la barre finale. /ma-page et /ma-page/ sont deux adresses différentes pour un serveur. Choisis une convention et applique-la partout.

Étape 5 : construire sur un environnement de test

Ne construis jamais le nouveau site à la place de l’ancien. Utilise un sous-domaine de préproduction ou un environnement local, et surtout : empêche son indexation le temps du développement.

Attention au piège inverse, celui qui fait le plus de dégâts. La protection contre l’indexation posée pendant le développement doit être retirée à la mise en ligne. Sur WordPress, il s’agit de la case « Demander aux moteurs de recherche de ne pas indexer ce site », dans Réglages puis Lecture. Je vois régulièrement des sites lancés avec cette case toujours cochée : le site est parfait, et totalement invisible, parfois pendant des mois.

Étape 6 : la mise en ligne, dans l’ordre

L’ordre compte. Voici celui que je suis :

1. Mettre le nouveau site en ligne.
2. Activer les redirections dans la foulée, pas le lendemain.
3. Retirer la protection contre l’indexation, et le vérifier.
4. Tester une dizaine d’anciennes adresses à la main, en commençant par tes pages les plus visitées.
5. Soumettre le nouveau sitemap dans Search Console.
6. Vérifier que le fichier robots.txt ne bloque rien d’essentiel.
7. Contrôler que le certificat HTTPS couvre bien toutes les variantes d’adresse.

Le point 4 n’est pas optionnel. Prends tes dix pages les plus visitées de l’année passée, colle leurs anciennes adresses dans le navigateur, et vérifie que chacune arrive au bon endroit. Dix minutes qui évitent des mois de dégâts.

Si tu arrives à cette étape et que le site en production reçoit déjà des visiteurs de Google, c’est le moment de ne pas improviser. Une migration se prépare, et l’essentiel du travail se fait avant la mise en ligne, pas après.

Étape 7 : surveiller pendant six semaines

La refonte ne s’arrête pas à la mise en ligne. Pendant six semaines, ouvre Search Console une fois par semaine et regarde trois choses :

• Indexation des pages : les erreurs 404 augmentent-elles ? Chaque nouvelle 404 correspond à une redirection oubliée. Corrige au fil de l’eau.
• Performances : la courbe des clics. Une baisse de dix à vingt pour cent pendant quelques semaines est normale, le temps que Google réexplore tout.
• Signaux Web essentiels : le nouveau site est-il réellement plus rapide, mesuré sur de vrais visiteurs ?

Un repère pour ne pas paniquer, et ne pas s’endormir non plus : une baisse de 10 à 20 % pendant deux à six semaines est une transition normale. Une chute de plus de la moitié, ou une baisse qui dure au-delà de deux mois, signale une erreur, le plus souvent des redirections manquantes ou une balise noindex partie en production.

Le cas particulier du changement de nom de domaine

Changer de nom de domaine en même temps que le site est le scénario le plus délicat. Trois précautions s’ajoutent :

• Rediriger le domaine entier, adresse par adresse, avec le même plan que ci-dessus.
• Utiliser l’outil de changement d’adresse de Search Console, prévu exactement pour ça, après avoir vérifié les deux domaines.
• Conserver l’ancien domaine plusieurs années. Les redirections doivent rester actives longtemps, et un domaine expiré peut être racheté par n’importe qui.

Si tu peux l’éviter, ne cumule pas refonte et changement de domaine. Fais l’un, laisse passer quelques mois, puis l’autre. En cas de problème, tu sauras lequel des deux en est la cause.

Combien de temps prévoir

Le développement d’un nouveau site vitrine prend quelques semaines. Mais la partie que personne n’anticipe, c’est le reste :

• L’inventaire et le plan de redirections : une demi-journée à deux jours selon le nombre de pages.
• La reprise du contenu : c’est presque toujours le poste le plus long, et c’est souvent le client qui bloque. Prévois-le explicitement dans le cahier des charges, avec des dates.
• Les tests avant mise en ligne : une journée complète, sérieusement.
• Le suivi après lancement : quelques heures étalées sur six semaines.

Autrement dit, sur une refonte, le développement représente rarement plus de la moitié du travail réel.

Par où commencer

Si tu envisages une refonte, fais d’abord une seule chose : exporte la liste de tes pages les plus visitées des douze derniers mois depuis Search Console. Cinq minutes. Cette liste te dira si tu as quelque chose à protéger, et donc si ta refonte est un projet simple ou un projet à risque.

Si ces pages représentent une part significative de tes contacts entrants, ne confie pas la refonte à quelqu’un qui ne t’a pas parlé de redirections avant de parler de design. C’est le test le plus fiable que je connaisse pour distinguer un prestataire qui a déjà migré des sites d’un prestataire qui va apprendre sur le tien.

Et si tu veux qu’on regarde ensemble ce que ta refonte risque de coûter en visibilité, écris-moi : l’inventaire et le plan de redirections se préparent avant que la moindre ligne de code ne soit écrite.