Un site refait, plus beau, plus rapide, et deux mois plus tard, le téléphone ne sonne plus. C'est une situation dont des entreprises viennent nous parler après coup, pour comprendre ce qui s'est passé, et c'est un cas d'école assez connu pour que Google publie sa propre documentation sur le sujet : le guide des migrations de site des développeurs Google.
Dans la quasi-totalité des cas, l'explication ne relève ni du hasard ni d'une mise à jour de Google. Elle tient à cinq erreurs, toujours les mêmes, toutes évitables.
Erreur 1 : que se passe-t-il quand les URLs changent sans redirection ?
C'est de très loin la première cause de chute, et le mécanisme est simple.
Votre ancien site avait une page à l'adresse monsite.fr/nos-services/plomberie. Le nouveau site l'a renommée monsite.fr/prestations/plomberie. Pour un visiteur, c'est indifférent. Pour Google, l'ancienne page a disparu, et avec elle, toutes les positions qu'elle avait mises deux ans à acquérir.
Ce qu'il faut faire. Avant toute modification, exportez la liste complète des URLs indexées. La Search Console et un outil d'exploration comme Screaming Frog donnent cette liste en quelques minutes.
Pour chaque ancienne adresse, définissez son équivalent sur le nouveau site, et mettez en place une redirection 301, permanente. Une redirection 302, temporaire, dit à Google que l'ancienne adresse reste la bonne : ce n'est pas ce que vous voulez signaler après une refonte. Google décrit le comportement attendu de chaque type de redirection dans sa documentation : Redirections et recherche Google.
Deux pièges fréquents : rediriger toutes les anciennes pages vers la page d'accueil, ce que Google traite comme une erreur 404 déguisée ; et enchaîner les redirections en cascade, qui diluent le signal à chaque étape.
Erreur 2 : peut-on supprimer une page sans regarder ses statistiques ?
« Cette page ne sert à rien, on la supprime. » C'est souvent faux, et c'est la deuxième cause d'effondrement.
Une rubrique de conseils jugée vieillotte est un cas typique : elle n'a pas l'air commerciale, elle date, personne dans l'entreprise n'y tient, et elle attire pourtant davantage de visiteurs que les pages de vente, parce qu'elle répond à des questions que les gens tapent réellement. La supprimer coûte le trafic qu'elle apportait, et les clients qui en venaient.
Ce qu'il faut faire. Avant de trancher, sortez le trafic organique de chaque page sur les douze derniers mois, ainsi que les liens entrants qu'elle a pu accumuler.
Ensuite, appliquez une règle simple : les pages performantes sont conservées et améliorées, les pages redondantes sont fusionnées entre elles, et seules les pages réellement mortes sont supprimées, puis redirigées vers la page thématiquement la plus proche.
Erreur 3 : que deviennent vos balises title et description après une refonte ?
Elles disparaissent, le plus souvent sans que personne s'en aperçoive. Les titres et descriptions ont souvent été peaufinés pendant des années sur l'ancien site. Une refonte les remplace fréquemment par des valeurs par défaut, générées automatiquement, identiques d'une page à l'autre.
Le résultat se voit vite : le taux de clic dans les résultats de recherche s'effondre, même à position égale.
Ce qu'il faut faire. Exportez les balises title et meta description de l'ancien site avant la refonte, et reportez-les (ou améliorez-les) sur le nouveau. Vérifiez aussi que les balises canoniques pointent vers les bonnes adresses, et qu'aucune balise noindex de préproduction n'a survécu à la mise en ligne.
Cette dernière erreur est plus fréquente qu'on ne l'imagine : un site entier passé en noindex parce qu'un réglage de préproduction n'a pas été retiré disparaît de Google en quelques jours. Google documente précisément la façon dont il traite ces directives : Bloquer l'indexation. À lire avant de toucher au réglage, pas après.
Erreur 4 : pourquoi une refonte se développe-t-elle en préproduction ?
Parce que développer directement sur le site en production expose à deux risques : des visiteurs qui tombent sur un site à moitié cassé, et une préproduction indexée par Google, qui crée un doublon complet de votre site.
Ce qu'il faut faire. Travaillez sur une adresse distincte, protégée par mot de passe et bloquée dans le fichier robots.txt. Le site actuel reste en ligne et opérationnel jusqu'à la bascule finale.
Au moment de la mise en ligne, la vérification la plus importante consiste à confirmer que le blocage d'indexation a bien été retiré de la version de production, et uniquement d'elle.
Erreur 5 : que faut-il surveiller dans le mois qui suit la mise en ligne ?
Une refonte ne se termine pas le jour de la bascule. Les effets sur le référencement mettent deux à six semaines à se manifester, et c'est précisément la période pendant laquelle une correction reste peu coûteuse.
Ce qu'il faut faire. Pendant trente jours, surveillez chaque semaine quatre indicateurs : les erreurs d'exploration dans la Search Console, le nombre de pages indexées, l'évolution des positions sur vos requêtes principales, et le trafic organique comparé à la même période de l'année précédente.
Une baisse de dix à quinze pour cent pendant deux à trois semaines est normale : Google réévalue le site. Une chute de moitié qui dure au-delà d'un mois indique un problème technique, pas une simple réévaluation.
À quoi ressemble un calendrier de refonte qui protège le trafic ?
- Semaine 1. Audit complet : URLs, positions, trafic par page, liens entrants, état technique.
- Semaine 2. Arbitrages de contenu et construction du plan de redirections.
- Semaines 3 à 5. Design et développement en préproduction, site actuel toujours en ligne.
- Semaine 6. Recette, vérification des balises, test des redirections une par une.
- Bascule. Mise en ligne aux heures creuses, activation des redirections, envoi du nouveau sitemap.
- Semaines 7 à 10. Surveillance hebdomadaire et corrections.
Ce calendrier n'a rien d'exotique. Le surcoût tient à trois choses : l'audit de la semaine 1, la construction du plan de redirections en semaine 2, et la surveillance des semaines 7 à 10. C'est du temps ajouté au projet, et c'est le seul temps qui protège les positions acquises par l'ancien site. Nous ne chiffrerons pas ici le risque évité : personne ne peut le faire honnêtement, puisqu'il dépend entièrement de ce que valait votre trafic organique avant.
Faut-il refondre ou améliorer l'existant ?
C'est la question qu'il faut se poser avant tout le reste, et la réponse dépend de l'état technique du socle.
| Critère | Remise à niveau ciblée | Refonte complète |
|---|---|---|
| Quand c'est le bon choix | La base technique est saine, le problème tient au design ou au contenu | La technologie n'est plus maintenue, le site est lent par construction, ou il a été piraté |
| Coût relatif | Deux à trois fois moins cher | Le budget d'un projet neuf |
| URLs | Conservées, donc aucune redirection à prévoir | Modifiées, donc plan de redirections obligatoire |
| Risque sur les positions | Faible : le socle indexé ne bouge pas | Réel, et c'est le sujet de cet article |
| Contenus | Repris tels quels, améliorés page par page | Arbitrés un par un, chiffres à l'appui |
| Durée typique | Quelques jours à quelques semaines | Plusieurs semaines, surveillance comprise |
Si la base est saine et que le problème tient au design ou au contenu, une remise à niveau ciblée coûte deux à trois fois moins cher. Si la technologie n'est plus maintenue, si le site est lent par construction ou s'il a été piraté, reconstruire revient souvent moins cher que rustiner indéfiniment.
Un audit de deux à cinq jours suffit à trancher cette question de façon factuelle, chiffres à l'appui. C'est un investissement modeste comparé au coût d'une refonte engagée pour de mauvaises raisons.
