Refonte de site : la checklist pour ne pas perdre son référencement

Une refonte de site fait perdre du référencement pour trois raisons, presque toujours les mêmes : des adresses qui changent sans redirection, des contenus qui se positionnaient et qui disparaissent, et des réglages de préproduction qui partent en ligne. Les trois s’évitent avec une méthode simple : tout inventorier avant, rediriger chaque ancienne adresse vers son équivalent au moment de la bascule, et surveiller la Search Console après.

Cette checklist suit les recommandations de Google pour migrer un site en changeant ses URL, et ce que j’ai appliqué sur la refonte de ce site : un ancien site Next.js remplacé par un site statique, avec de nouvelles adresses.

Pourquoi une refonte fait perdre du trafic

Google classe des adresses précises, pas « votre site » dans son ensemble. Si /services/plomberie/ devient /prestations/plomberie-nimes/ sans redirection, l’ancienne adresse renvoie une erreur, et Google retire de son index les URL déjà indexées qui renvoient une erreur 4xx. Les liens que d’autres sites faisaient vers cette page tombent dans le vide.

Deuxième cause : le contenu. Une page redirigée vers une nouvelle version plus courte, ou qui ne répond plus à la même question, peut perdre ses positions même si la redirection est parfaite. Troisième cause : les réglages. Une balise noindex ou un blocage dans le robots.txt posés pendant le développement, et oubliés le jour de la mise en ligne, suffisent à faire sortir un site des résultats, ou à empêcher Google de l’explorer.

Une baisse temporaire est normale : Google indique que la visibilité peut fluctuer pendant une migration, et que le déplacement de la plupart des pages d’un site petit ou moyen prend quelques semaines. Une baisse qui dure au-delà doit vous faire vérifier les redirections et l’indexation.

Avant : inventorier toutes les adresses et ce qu’elles rapportent

L’inventaire est l’étape la plus importante, et la plus souvent bâclée. Google conseille de partir des sitemaps, des journaux du serveur et de l’outil de mesure d’audience pour repérer les URL les plus importantes. Croisez ces sources, car aucune n’est complète seule :

• la Search Console : exportez le rapport Performances par page et par requête. Il ne garde qu’un historique limité (16 mois de données) : cet export sera votre point de comparaison ;
• une exploration de l’ancien site avec un outil dédié : Screaming Frog, par exemple, explore jusqu’à 500 URL dans sa version gratuite, ce qui couvre un petit site ;
• le sitemap actuel et les journaux du serveur : ils révèlent des adresses que plus aucun lien interne ne cite, mais que des visiteurs ou des robots demandent encore ;
• l’outil de mesure d’audience : les pages d’entrée des douze derniers mois ;
• les liens externes : le rapport Liens de la Search Console montre les pages de votre site les plus citées par d’autres sites.

Le résultat est un tableau : une ligne par ancienne adresse, avec ses clics, ses impressions, ses liens entrants et une colonne « décision ». Les pages qui apportent du trafic gardent leur contenu, ou l’améliorent, mais ne doivent jamais être raccourcies au point de ne plus répondre à la même question.

Sur ce site, j’ai aussi inventorié des adresses qui n’avaient jamais existé sur le domaine : des brouillons de la refonte, publiés sur une adresse de prévisualisation et parfois partagés. Ils sont redirigés eux aussi, sur le domaine comme sur les prévisualisations : une adresse qui a circulé peut encore être demandée.

Le plan de redirections : une ancienne adresse, une seule destination

Extrait du plan de redirections de ce site

Ancien siteNouveau site

• /about/  : redirection 301 vers /parcours/
• /portfolio/  : redirection 301 vers /realisations/
• /blog/  : redirection 301 vers /ressources/
• /pour-qui/startups/(brouillon)  : redirection 301 vers /services/saas-applications/
• /maintenance/  : 410, Contenu retiré, sans équivalent
• /blog/reparer-pc-lent/et six autres articles  : 410, Hors sujet avec le site actuel

À éviter

• Tout vers l’accueil Google peut y voir une erreur soft 404. À faire : Vers son équivalent, sinon 404 ou 410
• Les chaînes Idéalement 3 sauts au plus, en tout cas moins de 5. À faire : Directement vers la destination finale
• 302307 Le temporaire (302 ou 307) La nouvelle adresse n’est pas retenue comme référence. À faire : 301 ou 308, côté serveur

Redirections gardées au moins un an, le temps que Google transfère tous les signaux.

Pour chaque ligne de l’inventaire, trois réponses possibles : l’adresse est conservée (le meilleur cas, rien à faire), elle est redirigée en 301 vers la page qui répond à la même intention, ou elle répond 404 ou 410 parce que le contenu est retiré sans remplaçant. Les règles de Google sont nettes :

• des redirections permanentes côté serveur (301 ou 308), plutôt que des redirections en JavaScript. Google se sert d’une redirection permanente pour retenir la nouvelle adresse comme adresse de référence (canonique), ce qu’il ne fait pas avec une redirection temporaire (302 ou 307) ;
• pas de chaînes : Googlebot suit jusqu’à 10 redirections, mais Google conseille de viser directement la destination finale, ou à défaut de s’en tenir idéalement à 3 sauts, et en tout cas à moins de 5 ;
• pas de redirection en masse vers l’accueil : elle déroute le visiteur et peut être traitée comme une erreur soft 404 ;
• des redirections conservées le plus longtemps possible, en général au moins un an, le temps que Google transfère tous les signaux vers les nouvelles adresses.

301, 404 ou 410 : que faire des contenus que vous retirez

Rediriger un contenu retiré vers une page sans rapport est tentant : on espère « garder la valeur » de l’ancienne adresse. C’est une erreur. Le visiteur atterrit sur une page qui ne répond pas à sa question, et Google peut traiter la redirection comme une soft 404. Pour un contenu sans équivalent, Google demande simplement que l’ancienne adresse renvoie un code 404 ou 410.

404 ou 410 ? Pour Google, la différence est nulle : toutes les erreurs 4xx, à l’exception de 429, sont traitées de la même manière. Le 410, « supprimé définitivement », dit seulement l’intention plus clairement, aux robots comme à la personne qui relira la configuration dans deux ans.

C’est le choix que j’ai fait ici. L’ancien site contenait une page /maintenance/ et sept courts articles de dépannage informatique (PC lent, Wi-Fi, sauvegardes, hameçonnage…). Ils n’avaient plus rien à voir avec mon activité : les rediriger vers une page de service aurait fait passer du hors-sujet pour une réponse. Ils renvoient un 410, avec la page d’erreur du site pour orienter le visiteur.

Le jour de la bascule : les réglages qui ne pardonnent pas

Pour un site petit ou moyen, Google recommande de basculer toutes les adresses en même temps ; le découpage par sections est une option pour les grands sites. Le jour J, vérifiez dans l’ordre :

• plus aucun noindex ni blocage robots.txt hérité de la préproduction, comme Google le rappelle explicitement ;
• une balise canonical sur chaque nouvelle page, qui pointe vers elle-même ;
• les liens internes réécrits vers les nouvelles adresses : aucun ne doit passer par une redirection ;
• les sitemaps : le nouveau, soumis dans la Search Console. Google indique que l’ancien peut alors être supprimé ; le garder quelques semaines permet de voir ses URL sortir de l’index, mais ses avertissements de redirection sont normaux ;
• les balises hreflang mises à jour si le site existe en plusieurs langues ;
• une seule version du site : HTTPS, avec ou sans www, imposée par une redirection directe ;
• les fichiers de l’ancien site supprimés du serveur, sinon les anciennes pages restent accessibles en parallèle des nouvelles.

Si vous changez aussi de nom de domaine, ajoutez la déclaration de changement d’adresse dans la Search Console : Google précise que cet outil ne sert que pour un changement de domaine ou de sous-domaine.

Sur ce site, l’avant-dernier point s’applique ainsi : http://www et http mènent vers https:// sans www en une seule redirection. Une ancienne adresse demandée en http://www fait donc deux sauts (version du site, puis nouvelle page), sous le seuil conseillé. Et le dernier point n’est pas théorique : l’ancien site Next.js avait laissé ses fichiers (le dossier _next/ et les anciennes pages) chez l’hébergeur, et la procédure de mise en ligne prévoit de vider le dossier racine avant d’envoyer le nouveau site.

Pour éviter les oublis, les redirections sont écrites dans un seul fichier de données, qui génère le .htaccess du serveur Apache ; la configuration des prévisualisations en reprend la liste. Un script de contrôle vérifie après chaque génération que les deux correspondent, qu’aucun lien interne n’est cassé ou redirigé, et que chaque page a une canonical égale à sa propre adresse. Il reste un test manuel, adresse par adresse : curl -sI sur une ancienne URL doit afficher 301 et la bonne destination, ou 410.

Après : 4 à 8 semaines de suivi dans la Search Console

1. Le jour même : soumettez le sitemap, puis testez les pages prioritaires avec l’outil d’inspection d’URL (« Tester l’URL active ») et demandez leur indexation. Google précise que la demande ne garantit pas l’indexation et que leur nombre par jour est limité : réservez-la aux pages clés.
2. Chaque semaine, le rapport Pages : les anciennes adresses en « Page avec redirection » sont normales, tout comme les adresses retirées qui sortent de l’index. Une page du nouveau sitemap en « Détectée, actuellement non indexée » ou « Explorée, actuellement non indexée » demande du travail : contenu à enrichir, liens internes à ajouter. Une 404 sur une adresse qui avait du trafic signale une redirection oubliée.
3. Le rapport Performances : comparez clics et impressions par page avec l’export d’avant, sur des périodes comparables.
4. Les rapports d’amélioration : ils signalent les erreurs de données structurées. Début octobre 2026, la Search Console m’a signalé sur ce site « Il faut indiquer offers, review ou aggregateRating » (Extraits de produits) : une étude de cas avait été déclarée comme Product. Une étude de cas ne vend rien ; j’ai retiré ce type. Le détail est dans le guide sur les données structurées.

Pour savoir quoi regarder dans chaque rapport, et à quelle fréquence une fois la refonte digérée, voyez les rapports essentiels de la Search Console.

La checklist complète, à reprendre

1. 1

   Avant la refonte : Inventorier

   • Export Search Console (pages et requêtes) sauvegardé
   • Toutes les anciennes URL listées : exploration, sitemap, journaux, mesure d’audience, liens externes
   • Pages qui apportent du trafic repérées, contenu conservé ou amélioré
   • Une décision par URL : conservée, 301 vers une destination précise, ou 404/410
   • Aucune redirection en masse vers l’accueil, aucune chaîne
2. 2

   Le jour J : Basculer

   • noindex et blocages robots.txt de préproduction retirés
   • Canonical auto-référente sur chaque page, hreflang à jour
   • Liens internes vers les nouvelles adresses
   • Version unique du site (HTTPS, avec ou sans www)
   • Fichiers de l’ancien site supprimés
   • Chaque redirection et chaque 410 testés
   • Nouveau sitemap soumis
3. 3

   4 à 8 semaines après : Surveiller

   • Pages prioritaires inspectées et soumises
   • Rapport Pages suivi chaque semaine
   • Performances comparées à l’export d’avant
   • Erreurs de données structurées corrigées
   • Redirections conservées au moins un an

En résumé

Une refonte ne fait pas perdre de référencement par fatalité, mais par oubli : une adresse non redirigée, un contenu raccourci, un noindex resté en place. Inventoriez tout, donnez une seule destination pertinente à chaque ancienne adresse, assumez le 410 pour ce qui disparaît, testez avant d’ouvrir, puis suivez la Search Console pendant plusieurs semaines. Si vous préparez la refonte de votre site, c’est une étape que j’intègre à chaque projet de création de site internet.