Refonte de site : garder vos adresses et votre référencement

Pour refondre un site sans perdre son référencement, gardez les adresses qui reçoivent des visites ou des liens. Quand une adresse change, redirigez-la en 301 directement vers la page équivalente. Une page retirée sans remplaçant répond 404 ou 410. Faites l’inventaire dans Search Console avant la refonte, puis vérifiez chaque ancienne adresse après la mise en ligne. Ces précautions indiquent à Google où se trouve chaque page ; elles ne garantissent ni une position ni un délai.

Quelles adresses garder avant une refonte ?

Avant de toucher à l’arborescence, listez les adresses de l’ancien site qui reçoivent des impressions, des visites ou des liens. Google conseille de commencer par les plus importantes et indique où les trouver dans son guide « Migrer un site » :

• Le sitemap actuel : il contient en principe les adresses déjà soumises à Google.
• Les liens vers votre site, dans Search Console : les pages qui reçoivent des liens internes ou externes.
• Les journaux du serveur ou l’outil de statistiques : les adresses les plus visitées et celles consultées au moins une fois récemment, sur une période qui tient compte des variations saisonnières.

J’y ajoute le rapport Performances de Search Console, onglet Pages, pour exporter les adresses qui ont reçu des impressions. La vue par défaut ne couvre que les trois derniers mois ; choisissez la période la plus longue disponible.

Rassemblez ces listes dans un tableur, une ligne par adresse, puis notez pour chacune la décision : l’adresse reste identique, elle change ou elle disparaît. Ce tableau devient votre plan de redirection.

Gardez aussi les variantes d’une même page. Dans les données de mon site, Search Console liste la même page avec et sans barre oblique finale sur deux lignes distinctes ; les deux formes doivent mener quelque part.

Si la refonte elle-même n’est pas encore décidée, l’article quand et comment décider d’une refonte traite cette étape en amont.

Comment construire un plan de redirection 301 en un seul saut ?

Le plan de redirection associe chaque ancienne adresse à sa destination finale, sans étape intermédiaire. Les codes HTTP utilisés sont définis par la RFC 9110 :

• 301 (Moved Permanently) : la ressource a reçu une nouvelle adresse permanente.
• 308 (Permanent Redirect) : même sens que la 301, sans possibilité de changer la méthode de la requête.
• 410 (Gone) : la ressource n’est plus disponible, et cette situation est probablement définitive.

Google recommande des redirections permanentes côté serveur, 301 ou 308, quand c’est techniquement possible. Pour ses robots, une 301 est un signal fort que la cible doit être traitée, et la 308 lui est équivalente. Une redirection permanente fait apparaître la nouvelle adresse dans les résultats de recherche.

Voici un extrait de la table d’eljadiworks.com :

Les deux dernières lignes n’ont pas de destination : ces articles ont été retirés sans page équivalente. Pour le contenu supprimé lors d’une migration, Google demande une réponse 404 ou 410.

Que faire de la barre finale et des variantes d’adresse ?

Une même page peut répondre à plusieurs adresses : avec ou sans barre oblique finale, avec ou sans www, en http ou en https. Choisissez une forme et faites rediriger les autres vers elle. Pour Google, les redirections sont un signal fort pour désigner l’adresse canonique, celle qu’il retient parmi les doublons.

Sur eljadiworks.com, la forme canonique se termine par une barre oblique. Une adresse sans barre finale répond 308 vers la forme avec barre. Une ancienne adresse redirigée part directement vers sa destination finale, déjà sous sa forme canonique : /articles/prix-site-internet-suisse mène en un saut à /prix-site-internet-suisse/, sans passer par /prix-site-internet-suisse.

Le sitemap et la balise rel="canonical" donnent la même forme. Google recommande de mettre dans le sitemap les adresses que vous voulez voir dans ses résultats, donc les adresses canoniques. Son guide de migration demande aussi de remplacer les anciennes adresses dans les liens internes.

Comment vérifier chaque redirection après la mise en ligne ?

Vérifiez chaque ancienne adresse par un contrôle automatique, relancé avant chaque mise en ligne : une vérification faite à la main le jour du lancement ne repère pas une règle ajoutée plus tard qui casserait une ancienne redirection. Sur mon site, la commande npm run qa:seo lit dans le code la table de redirections et la liste des adresses retirées, puis interroge le site, en local ou en production. Elle contrôle notamment :

• chaque ancienne adresse : une seule redirection, vers la destination attendue, qui répond 200 ;
• chaque adresse retirée : une réponse 410 ;
• les brouillons supprimés : une réponse 404 ;
• le sitemap : aucune adresse redirigée, retirée ou en brouillon ;
• les liens internes : aucun lien cassé ni dirigé vers une adresse retirée ;
• en production, les variantes http et www : une redirection vers l’adresse en https sans www.

Elle échoue dès qu’une ligne ne correspond plus et se relance en une commande.

Après la mise en ligne, Search Console complète ce contrôle. Le rapport Sitemaps indique combien d’adresses soumises sont indexées, et l’outil d’inspection d’URL montre le code réellement renvoyé par une adresse.

Si vous ne gérez pas la technique vous-même, demandez à votre prestataire la table complète et la vérification de chaque ligne après la mise en ligne.

Ce que montrent les adresses déplacées et retirées d’eljadiworks.com

Sur eljadiworks.com, deux articles déplacés redirigent en 301 vers la page prix, et quatre articles retirés sans page équivalente répondent 410 ; ces quatre articles totalisaient 723 impressions et 2 clics dans Search Console du 20 juin au 3 octobre 2026. Dans une refonte de site à Genève, je garde de la même façon les adresses utiles de l’ancien site ou je les redirige vers leur nouvelle page.

Les chiffres viennent de la Search Console d’eljadiworks.com, relevés le 5 octobre 2026. Les données de la propriété commencent le 20 juin 2026 : sauf mention contraire, ils couvrent la période du 20 juin au 3 octobre 2026. La position est la position moyenne de Search Console.

Quatre articles retirés, en 410

J’ai retiré quatre articles, deux en français et deux en anglais : un guide d’intégration de bexio à un site et un comparatif KLARA, Banana et bexio. Aucune page du site ne traite ces sujets ; leurs adresses répondent 410.

Les données s’arrêtent au 3 octobre 2026 : elles décrivent ces articles quand ils étaient encore en ligne. Ils étaient vus, avec une position moyenne autour de 6, et presque jamais cliqués. Sur les 90 jours du 6 juillet au 3 octobre 2026, ils totalisent 717 des 2 077 impressions comptées page par page, et la version anglaise du comparatif est la deuxième page la plus affichée, après l’article anglais sur le choix entre freelance et agence web. Le retrait coûte donc des impressions.

Rediriger ces adresses aurait envoyé le lecteur vers une page sans rapport, comme la page prix ou l’accueil. Google prévient que rediriger de nombreuses anciennes adresses vers une seule page sans rapport peut être traité comme une soft 404. Pour une page supprimée sans remplaçant au contenu similaire, il demande une réponse 404 ou 410.

Entre 404 et 410, Google ne fait pas de différence : toutes les erreurs 4xx, sauf 429, sont traitées de la même manière, et une adresse déjà indexée qui répond 4xx est retirée de l’index. Je n’attends donc du 410 aucun effet plus rapide dans Google. Je l’utilise pour le sens que lui donne la RFC 9110 : la ressource est volontairement indisponible, probablement de façon définitive. Les brouillons jamais publiés répondent 404.

La ligne sans barre finale illustre la section sur les variantes : Search Console a compté le guide bexio anglais sous deux adresses, 3 impressions sans barre du 7 au 12 juillet 2026, puis 29 avec barre à partir du 7 août 2026. Les données n’en donnent pas la cause ; elles montrent qu’un inventaire doit couvrir les deux formes.

Deux déplacements en 301

L’article sur les prix a quitté la rubrique Articles fin mai 2026 pour devenir la page prix. Ce déplacement précède le début des données : Search Console n’a rien enregistré pour l’ancienne adresse, et je ne peux montrer aucun avant-après.

L’article sur le coût d’un site à Genève a été fusionné dans la page prix en septembre 2026. Ses deux anciennes adresses avaient reçu peu d’impressions : 19 au total, aucun clic. La page prix française compte ensuite 27 impressions la semaine du 28 septembre 2026, contre 0 à 8 par semaine auparavant, et la page anglaise apparaît pour la première fois le 1er octobre 2026. Trois mois de données sur un petit site ne permettent pas d’attribuer cette hausse à la redirection.

Chaque ancienne adresse mène en un saut à sa destination canonique, qu’elle ait une barre finale ou non.

Quelles erreurs font perdre le référencement pendant une refonte ?

1. Les chaînes de redirections. L’adresse A redirige vers B, qui redirige vers C. Googlebot suit jusqu’à 10 sauts, mais Google conseille de rediriger directement vers la destination finale et, à défaut, de ne pas dépasser idéalement 3 sauts. Une chaîne se forme par exemple quand une deuxième refonte ajoute ses règles sans réécrire celles de la première : mettez alors à jour les anciennes lignes vers la nouvelle destination.
2. Tout rediriger vers l’accueil. Envoyer de nombreuses anciennes adresses vers une seule page sans rapport, comme l’accueil, peut dérouter les visiteurs et être traité comme une soft 404.
3. La soft 404. C’est une page qui annonce que le contenu n’existe pas, ou une page presque vide, renvoyée avec le code 200. Search Console la signale dans le rapport sur l’indexation des pages. Une page retirée répond 404 ou 410 ; une page déplacée ou remplacée par un contenu clair redirige en 301, selon le guide de Google sur les erreurs d’exploration.

Pour une adresse en erreur 4xx, Google indique seulement qu’il cesse de l’utiliser au fil du temps, sans durée précise. Le 410 ne convient pas quand une page équivalente existe : la 301 vers cette page reste alors la réponse recommandée.

Sources

• Google Search Central, « Migrer un site » (page « Site moves with URL changes »), mise à jour le 2026-09-11, consultée le 2026-10-05.
• Google Search Central, « Redirections et recherche Google », mise à jour le 2026-05-05, consultée le 2026-10-05.
• Google, « Effet des codes d’état HTTP sur les robots d’exploration Google », mise à jour le 2026-03-05, consultée le 2026-10-05.
• Google Search Central, « Résoudre les problèmes d’exploration de la recherche Google », mise à jour le 2025-12-21, consultée le 2026-10-05.
• Google Search Central, « Spécifier une URL canonique avec rel="canonical" et d’autres méthodes », mise à jour le 2026-07-13, consultée le 2026-10-05.
• Google Search Central, « Créer et envoyer un sitemap », mise à jour le 2026-07-15, consultée le 2026-10-05.
• Aide Search Console, « Rapport sur les performances (résultats de la Recherche) », sans date de mise à jour affichée, consultée le 2026-10-05.
• IETF, RFC 9110 « HTTP Semantics », juin 2022, sections 15.4.2 (301), 15.4.9 (308) et 15.5.11 (410), consultée le 2026-10-05.
• Search Console d’eljadiworks.com, propriété de domaine, données du 2026-06-20 au 2026-10-03, relevées le 2026-10-05.