La question que tout le monde pose avant de signer
« Si on refait le site, est-ce qu'on perd notre référencement ? »
C'est la première question posée dans à peu près chaque rendez-vous de refonte, et la réponse honnête tient en deux temps. Non, pas si les redirections sont faites correctement. Oui, vous allez traverser plusieurs semaines pendant lesquelles Search Console affichera des chiffres inquiétants, et personne ne vous aura prévenu que c'est normal.
La plupart des articles sur le sujet donnent une checklist. Celui-ci donne autre chose : la courbe réelle, mesurée sur un cas précis. Le 31 août 2026, nous avons migré notre propre site, d'un WordPress sur hébergement mutualisé vers un site statique. Même nom de domaine, même entreprise, structure d'URL en grande partie nouvelle. Nous avons donc, dans notre propre Search Console, exactement la donnée que les clients nous demandent.
Les chiffres ci-dessous sont donnés en proportions plutôt qu'en volumes absolus : ce qui est transposable à votre site, c'est le rythme, pas le nombre d'impressions d'une agence de la Loire.
Ce qui ne bouge pas : les positions
Premier constat, et le plus rassurant : les positions moyennes n'ont pas décroché. Sur les requêtes où le site était visible avant la migration, il l'est resté après, dans la même zone de classement. Pas de chute brutale, pas de disparition, pas de « sandbox ».
C'est le résultat normal d'une migration où chaque ancienne URL part en 301 vers son équivalent. Si vous ne deviez retenir qu'une chose : le risque d'une refonte n'est pas dans le classement, il est dans le plan de redirection. Une redirection ratée ne fait pas baisser une page, elle la fait disparaître.
Ce qui bouge lentement : Google continue d'afficher les anciennes URL
Voilà le phénomène que personne n'annonce, et qui provoque la panique au bout de trois semaines.
Après la migration, Google continue pendant longtemps à afficher l'ancienne adresse dans ses résultats, alors même que la redirection fonctionne parfaitement et que l'internaute atterrit bien sur la nouvelle page. Dans Search Console, les impressions restent donc comptées sur l'ancienne URL. On a l'impression que la nouvelle version du site ne décolle pas, alors qu'elle reçoit déjà le trafic.
La part des impressions encore attribuées aux anciennes URL, dans notre cas :
| Relevé | Part des impressions sur les anciennes URL |
|---|---|
| Sur les 90 jours suivant la migration | 66 % |
| Sur les 28 jours arrêtés au 1er octobre | 54 % |
| Sur les 28 jours arrêtés au 5 octobre | 46 % |
Autrement dit : environ cinq semaines après la bascule, la moitié de la visibilité est encore comptée sur des adresses qui n'existent plus. La courbe descend régulièrement, d'à peu près un point par jour. Elle ne descend pas d'un coup, et aucune action de votre côté ne l'accélère : ni la purge du cache, ni la demande d'indexation, ni le renvoi du sitemap. C'est Google qui recalcule, à son rythme.
Si votre prestataire vous dit que le référencement sera « revenu » une semaine après la mise en ligne, il ne l'a pas mesuré.
Le cas d'école : l'ancienne page bat la nouvelle pendant six semaines
Le détail le plus instructif concerne une requête locale sur laquelle nous avions créé une page dédiée, précisément pour mieux répondre que l'ancienne page d'accueil générique.
Pendant six semaines, l'ancienne page d'accueil est restée mieux classée que la nouvelle page spécialisée. La page dédiée est apparue dans les résultats mi-septembre, loin derrière, puis a remonté semaine après semaine jusqu'à venir se placer au niveau de l'ancienne fin septembre.
Ce qui se joue là, c'est l'historique. Une URL qui existe depuis des années porte un capital que la meilleure page du monde ne reprend pas en quinze jours, même avec une redirection propre. Le contenu finit par gagner, mais il gagne lentement.
La conséquence pratique est importante au moment de l'arbitrage : ne jugez pas une nouvelle page sur son premier mois. Nous avons vu des entreprises supprimer une page neuve au bout de trois semaines en concluant « ça ne marche pas », alors que la courbe montait.
Les trois pièges qui cassent vraiment une refonte
Les checklists classiques parlent du plan de redirection, du sitemap et de la Search Console. Tout cela est vrai et tout cela est facile. Les trois problèmes ci-dessous sont ceux qui nous ont réellement coûté du temps, et aucun n'est visible sans aller vérifier.
1. Une redirection qui se transforme toute seule
Certaines anciennes pages doivent répondre 410 Gone et non 301 : les pages de démonstration d'un thème, les archives vides, les catégories générées automatiquement. Les rediriger vers l'accueil revient à dire à Google qu'elles ont déménagé, ce qui est faux, et à faire remonter du trafic parasite.
Nous avions donc écrit des règles 410. En testant sous un vrai serveur Apache, elles ressortaient en 301. La cause : la page d'erreur personnalisée est servie par une sous-requête interne qui repasse dans les règles de réécriture, et la règle de canonicalisation, qui teste la requête d'origine, se réappliquait par-dessus le 410.
La leçon est générale et vaut pour n'importe quel hébergement : les règles de redirection se testent avec un outil qui lit le code de réponse HTTP, jamais à la lecture du fichier de configuration. Ce qui est écrit et ce qui est servi sont deux choses différentes.
2. Le cache serveur qui ne distingue pas les domaines
Une semaine après la bascule, Search Console a commencé à signaler plusieurs
pages comme « Exclue par la balise noindex ». L'inspection d'URL confirmait un
noindex dans l'en-tête HTTP. La configuration, elle, était correcte : une
requête fraîche renvoyait bien index, follow.
L'explication : le cache du serveur mutualisé stockait ses entrées par chemin
d'URL, sans distinguer le domaine. La préproduction, qui sert légitimement un
noindex pour ne pas être indexée, alimentait le même cache. Sa réponse était
ensuite resservie sur le site public.
Un site statique n'a aucun besoin d'un cache serveur : nous l'avons simplement
désactivé. Mais le symptôme est traître, parce que tout ce que vous vérifiez à
la main semble correct. Si Search Console vous annonce un noindex que vous ne
trouvez nulle part, cherchez du côté du cache et de la préproduction.
3. Les pages supprimées envoyées vers l'accueil
C'est l'erreur la plus répandue, parce que c'est la plus simple à mettre en place : une règle unique qui renvoie tout ce qui n'existe plus vers la page d'accueil. Google traite ces redirections non pertinentes comme des erreurs douces et finit par les ignorer, en ayant au passage perdu du temps de crawl.
Une page supprimée volontairement part en 410. Une page déplacée part en 301 vers son équivalent réel, pas vers l'accueil. S'il n'y a pas d'équivalent, c'est un 410.
Le calendrier auquel s'attendre
Sur la base de ce que nous avons mesuré, et en supposant un plan de redirection correct :
| Période | Ce qui se passe |
|---|---|
| Jours 1 à 7 | Les positions tiennent. Les anciennes URL restent affichées. Rien à faire. |
| Semaines 2 à 3 | Search Console signale des anomalies d'indexation. C'est le moment où il faut vérifier les codes de réponse et le cache, pas paniquer. |
| Semaines 3 à 6 | Les nouvelles pages apparaissent, mal classées, puis remontent. Les anciennes URL pèsent encore la moitié des impressions. |
| Mois 2 à 3 | La consolidation s'achève. C'est à partir de là que les chiffres deviennent lisibles et comparables. |
Ne jugez pas une refonte avant le deuxième mois. Avant, vous ne mesurez pas le nouveau site, vous mesurez la transition.
Ce qu'on referait pareil
- Un tableau de correspondance ancienne URL vers nouvelle URL, ligne à ligne, écrit avant de toucher au site.
- Un relevé Search Console complet avant la bascule, pour avoir une référence. Sans point de départ, aucune des courbes ci-dessus n'aurait été lisible.
- Des 410 assumés sur ce qui disparaît, plutôt que des 301 de confort.
- Le test des règles sous un vrai serveur, avec lecture des codes HTTP.
Et ce qu'on ferait différemment : prévenir le client, par écrit et dès le devis, que les six premières semaines ne veulent rien dire. Nous le savions, nous ne l'avions pas formalisé, et c'est le genre de détail qui transforme une migration réussie en inquiétude inutile.
En résumé
Une refonte ne fait pas perdre le référencement. Elle le met en suspens le temps que Google recalcule, et ce délai se compte en semaines, pas en jours. Le vrai risque est technique et se concentre sur trois points : des redirections qui ne font pas ce que le fichier dit, un cache qui ressert une mauvaise réponse, et des pages supprimées traitées à la va-vite.
Si vous envisagez une refonte, c'est l'occasion de poser la question autrement : plutôt que « est-ce qu'on va perdre des positions », demandez à voir le plan de redirection et la méthode de vérification. C'est là que se joue le résultat.
Nous faisons ces migrations pour nos clients et nous venons de la faire pour nous. Si vous voulez en parler sur votre cas, prenons rendez-vous, ou regardez d'abord comment nous construisons les sites et nos réalisations.