Refonte de site et SEO : ne pas perdre son trafic, avant, le jour J et les quatre semaines après

Perdre son trafic après une refonte : d'où ça vient, comment l'éviter

Une refonte fait perdre du trafic quand Google ne retrouve plus ce qu'il classait : une URL changée sans redirection permanente, un blocage d'indexation oublié après les essais, des liens internes qui pointent encore vers les anciennes adresses. La liste de contrôle plus bas se suit dans l'ordre : avant, le jour J, puis les quatre semaines après.

L'étape qu'on néglige est l'après. Google écrit qu'un site de taille moyenne met « quelques semaines, voire davantage » à être pris en compte après une migration (documentation mise à jour le 20 août 2026). Pendant ce temps, on lit l'état d'indexation page par page, pas la position moyenne.

Je publie aussi nos propres chiffres : la refonte du site de Waimia, mise en ligne les 4 et 5 octobre 2026, suivie chaque semaine dans Search Console, du 4 octobre au 1er novembre 2026. Le site avait peu de trafic avant la refonte, donc ce cas mesure la reprise de l'indexation, pas la protection d'un trafic établi. Ce qui a marché, ce qui n'a pas marché, et ce que ces chiffres permettent de conclure.

Les étapes, le coût et le cas client d'une refonte sont dans le guide de la refonte de site internet. Ce qu'il faut écrire dans le cahier des charges (inventaire des URL, table de redirections, mesures de référence) est dans notre guide du cahier des charges d'un site internet et dans l'article sur le cahier des charges d'une refonte. Je ne les reprends pas ici.

Qu'est-ce qu'une refonte SEO ?

Une refonte SEO est la partie d'une refonte de site qui protège le référencement déjà acquis : relever les pages qui reçoivent des clics et des liens, rediriger chaque ancienne adresse vers sa nouvelle page, contrôler la mise en ligne, puis suivre l'indexation pendant plusieurs semaines. On parle de migration SEO quand les URL changent : nouveau domaine, nouvelle structure ou nouvelle plateforme.

Une redirection 301 est une réponse du serveur qui dit au navigateur et à Google qu'une page a déménagé définitivement à une autre adresse. D'après Google, une redirection permanente (301 ou 308) fait de la page de destination la page retenue dans l'index ; une redirection temporaire (302 ou 307) laisse l'ancienne page affichée dans les résultats.

La liste de contrôle : avant, jour J, quatre semaines après

Chaque ligne a une vérification. Une ligne impossible à vérifier n'est pas faite.

Quand	À faire	Comment le vérifier
Avant	Exporter de Search Console les pages qui reçoivent des clics et des impressions sur trois mois, et garder le fichier daté.	Le fichier existe avant le premier devis, avec la date de l'export.
Avant	Lister toutes les URL actuelles : sitemap, exploration du site, images et PDF.	Le nombre d'URL est connu, et chaque URL de l'export Search Console y figure.
Avant	Écrire la table ancienne URL, nouvelle URL. Une page sans équivalent répond 404 ou 410, pas la page d'accueil.	Chaque ligne a une destination ou un code de réponse.
Avant	Décider ce qui change : domaine, plateforme, structure ou graphisme. Une chose à la fois si possible.	La décision est écrite. Si les URL ne changent pas, la table est vide, et c'est le cas le plus sûr.
Jour J	Poser les redirections côté serveur, en 301 ou 308, en un seul saut, vers une page qui répond 200.	Un script teste toutes les anciennes URL : code 301 ou 308, une seule redirection, destination en 200. Si votre CMS ne sait pas poser de redirection côté serveur, l'hébergeur ou le CDN le peut ; évitez la redirection en JavaScript.
Jour J	Retirer le noindex et le blocage du robots.txt posés pendant les essais.	Lire la balise robots de cinq pages clés en production, et le fichier robots.txt.
Jour J	Faire pointer les liens internes vers les nouvelles URL, pas vers les anciennes redirigées.	Une exploration du nouveau site ne rencontre aucune redirection interne.
Jour J	Publier le sitemap des nouvelles URL avec une date de modification juste, et l'envoyer dans Search Console.	Le sitemap ne contient que des pages en 200, indexables, et chaque date correspond au contenu.
Semaines 1 à 4	Inspecter les pages qui comptaient : indexée ou non, et pour quel motif.	Un tableau par semaine, page par page (exemple plus bas).
Semaines 1 à 4	Comparer les clics page par page avec l'export d'avant.	Chaque page qui perd a une explication écrite.
Un an	Garder les redirections.	Personne ne les supprime au prochain changement de plateforme.

Un prestataire qui ne vous remet pas la table de redirections avant la mise en ligne ne protège pas votre référencement, quoi qu'il promette. Chez nous, une refonte se livre avec ses redirections : c'est le travail de notre service de création et de refonte de site web.

Ce que dit la documentation de Google

Trois pages de Google Search Central suffisent pour une refonte.

• Migrations de site (mise à jour le 20 août 2026) : correspondance URL par URL ; redirections permanentes côté serveur ; pas de renvoi en masse vers la page d'accueil, qui peut être traité comme une fausse page 404 ; liens internes à mettre à jour ; redirections gardées « aussi longtemps que possible », au moins un an en général. La page prévient d'une fluctuation temporaire du classement et de « quelques semaines » de prise en compte pour un site de taille moyenne. Elle conseille de soumettre le sitemap des nouvelles URL, et de garder un temps celui des anciennes pour suivre la bascule.
• Redirections et recherche Google (mise à jour le 14 avril 2026) : la redirection côté serveur est celle que Google interprète le mieux ; une redirection en JavaScript est à éviter, Google pouvant ne jamais la voir si le rendu échoue.
• Créer et envoyer un sitemap (mise à jour le 8 juillet 2026) : Google n'utilise la date de modification (lastmod) que si elle est exacte de façon constante et vérifiable, et elle doit refléter la dernière modification significative de la page. Changer la date du copyright n'en est pas une. Les balises priority et changefreq sont ignorées.

Notre refonte, mesurée semaine par semaine

Le site de Waimia a été refait et mis en ligne les 4 et 5 octobre 2026. Avant la refonte, Search Console comptait 16 clics et 322 impressions sur 92 jours (du 30 juin au 29 septembre 2026), et son rapport Pages, arrêté au 21 septembre, affichait 9 pages indexées. Depuis le 4 octobre, une collecte automatique inspecte chaque URL du sitemap par l'API de Search Console chaque dimanche. Elle a relevé ceci.

Collecte	URL inspectées	Indexées	Détectée, non indexée	Inconnue de Google	Clics sur 28 jours	Impressions sur 28 jours	Position moyenne
4 octobre 2026	73	38	14	15	4	193	23,3
11 octobre 2026	120	80	31	4	5	1 007	28,2
18 octobre 2026	217	143	50	10	9	1 932	31,9
25 octobre 2026	240	168	52	10	17	4 652	32,9
1er novembre 2026	255	173	45	27	39	7 690	30,8

Les colonnes d'indexation viennent de l'inspection d'URL de chaque collecte. Les clics, impressions et positions couvrent les 28 jours qui s'arrêtent trois jours avant la collecte (délai des données de Search Console). Les fenêtres des deux premières lignes s'arrêtent le 1er et le 8 octobre : elles décrivent surtout le site d'avant la refonte. Le rapport Pages de septembre et l'inspection d'URL d'octobre ne sont pas le même instrument, donc le passage de 9 à 38 pages indexées ne se lit pas d'un bloc. Le sitemap comptait 73 URL lors de la collecte du 4 octobre et 88 le 5, après la seconde mise en ligne. La hausse des URL inconnues de Google la dernière semaine, de 10 à 27, correspond aux pages publiées fin octobre, vues pour la première fois. Les autres états (explorée non indexée, noindex, redirection) ne sont pas repris : ils comptent de 5 à 14 URL selon la semaine.

Comment lire ces chiffres

1. Je n'attribuerais pas la hausse à la refonte seule. Le site est passé de 73 à 255 URL dans le mois, et les impressions viennent pour une grande part des pages publiées après la refonte. Ces données ne permettent pas de séparer les deux effets.
2. La position moyenne s'est dégradée, de 23,3 à 30,8, pendant que les impressions étaient multipliées par 40. La moyenne mélange les anciennes pages et des dizaines de pages nouvelles, qui apparaissent d'abord loin dans les résultats. Après une refonte qui ajoute des pages, la position moyenne du site ne sert à rien : on lit la position page par page et requête par requête.
3. Sous 30 impressions sur 28 jours, une position n'est pas un signal (c'est notre règle de lecture, pas une règle de Google). La requête « agence n8n » était en position 1 le 4 octobre sur 1 impression, et en position 41,9 le 1er novembre sur 136 impressions. Ce n'est pas une chute : la première mesure ne valait rien.
4. Le rapport Pages de Search Console était en retard : le 5 octobre, il datait encore du 21 septembre. L'inspection d'URL, dans l'interface ou par l'API, donne l'état du jour, et c'est elle qu'on lit les premières semaines.
5. La refonte a daté presque tout le sitemap du même jour. Le 5 octobre, 84 des 88 URL du sitemap portaient une date de modification de moins de huit jours, ce qui était juste ce jour-là. Ensuite, la date doit redevenir celle du contenu de chaque page, sinon Google cesse de s'y fier. Notre sitemap prend la date de mise à jour écrite dans le fichier de contenu, ou celle du dernier changement du fichier, jamais la date de construction du site.
6. Ce qui n'a pas marché : au 1er novembre, 18 pages restaient non indexées depuis la première collecte, dont la page automatisation des processus, pourtant liée depuis l'accueil et toujours « inconnue de Google » quatre collectes plus tard. J'ai demandé son indexation à la main dans Search Console le 2 novembre 2026. Si une page liée depuis l'accueil reste inconnue de Google après quatre semaines, faites de même, puis renforcez les liens internes qui y mènent.

Lire l'état d'indexation après la mise en ligne

L'inspection d'URL de Search Console donne pour chaque page un état et un motif. Nous les lisons ainsi chaque semaine.

État affiché	Ce que ça veut dire	Quoi faire
Envoyée et indexée	La page est dans l'index.	Rien, sauf si ses clics baissent par rapport à l'export d'avant.
Google ne reconnaît pas cette URL	Google n'a pas encore vu l'adresse.	Vérifier qu'elle est dans le sitemap et que d'autres pages du site la lient. Normal la première semaine pour une URL nouvelle.
Détectée, actuellement non indexée	Google connaît l'adresse et ne l'a pas encore explorée.	Renforcer les liens internes, vérifier qu'elle ne double pas une autre page.
Explorée, actuellement non indexée	Google a lu la page et ne l'a pas retenue.	Un problème de contenu : l'enrichir, ou la fusionner avec une page proche et la rediriger.
Page avec redirection	L'adresse redirige.	Normal pour une ancienne URL. Anormal pour une URL du nouveau sitemap : c'est un sitemap à corriger.
Exclue par la balise noindex	La page demande à ne pas être indexée.	Un bug si elle doit être trouvée : souvent un noindex de préproduction resté en place.

Une page qui reste dans le même état non indexé plus de trois collectes appelle une décision écrite : mailler, enrichir, fusionner ou rediriger. La laisser en l'état sans le dire n'est pas une option.

Si le trafic baisse après la refonte : l'ordre du diagnostic

1. Trouvez les pages qui perdent, en comparant l'export d'avant aux clics page par page de Search Console. Une baisse se lit page par page, jamais sur le total.
2. Testez l'ancienne URL de chacune : curl -sI https://votre-site.fr/ancienne-page doit répondre 301 ou 308, puis une seule redirection vers la page équivalente, qui répond 200.
3. Vérifiez que la nouvelle page est indexable (pas de noindex, canonique vers elle-même) et indexée, par l'inspection d'URL.
4. Comparez le contenu : la nouvelle page a-t-elle perdu le titre, les sections ou les liens qui la faisaient classer ? C'est le point à vérifier quand les redirections sont justes.
5. Seulement ensuite, attendez. Si les quatre points tiennent, la fluctuation annoncée par Google pendant quelques semaines est la seule explication restante.

Bing, IndexNow et les moteurs IA

IndexNow est un protocole ouvert qui permet de prévenir les moteurs participants qu'une URL a été ajoutée, modifiée ou supprimée. Une soumission reçue par un moteur est partagée avec les autres moteurs du protocole. Le site place à sa racine un fichier texte qui porte sa clé, et peut envoyer jusqu'à 10 000 URL par requête, selon la documentation d'IndexNow. Plusieurs CMS l'intègrent déjà, dont WordPress, Shopify et Wix d'après la même FAQ. La page de Google sur les migrations ne parle pas d'IndexNow : pour Google, ce sont le sitemap, les redirections et Search Console.

Pour les moteurs IA, ce qui dépend de vous, c'est qu'une page soit indexée et que son title et sa description disent ce qu'elle apporte. L'article apparaître dans ChatGPT détaille ce qu'une PME contrôle de ce côté.

Quand ne pas changer les URL

Si la refonte est graphique et que les pages qui reçoivent des clics et des liens gardent leur sujet, je garde leurs URL. Une table de redirections vide est la migration la plus sûre. Je ne change une URL que lorsque l'ancienne est fausse (sujet changé, mot inutile, ancienne plateforme dans le chemin), et une seule chose à la fois : le domaine, puis la plateforme, puis la structure, comme le conseille Google.

Si vous ne savez pas ce que Google voit aujourd'hui de votre site, commencez par là : c'est l'objet d'un audit SEO technique avant la refonte, ou de l'audit de site internet que vous pouvez faire vous-même.

PDF · 10 pages · envoyé par e-mail

Recevez la grille d'audit de site internet dans votre boîte mail

Vous la recevez par e-mail, en PDF.

• Huit axes à cocher, du formulaire de contact à la citabilité par les IA
• Pour chaque point, le geste ou l'outil gratuit pour le vérifier
• Les signaux d'alerte, et ce qui se corrige sans refonte
• Une règle de décision : corriger ou refaire

Ne pas remplir

Votre e-mail

Recevoir la grille

Recevoir aussi la lettre mensuelle de Waimia (un envoi par mois, désinscription en un clic).

Sans cette case : un seul e-mail, aucune liste. Responsable : Waimia (VirtuoseWeb). Confidentialité.

Grille PDF · A4

Grille d'audit de site internet

Huit axes · corriger ou refaire · 10 pages

waimia.com