Pour préserver le référencement pendant une refonte, définissez d’abord ce que chaque URL doit continuer à accomplir : répondre à une recherche, recevoir des liens, orienter un visiteur ou produire une demande. Gardez les adresses utiles quand leur rôle ne change pas. Sinon, associez chaque ancienne URL à une destination équivalente et testez la redirection. La mise en ligne attendra si le rendu, l’indexation ou la mesure ne sont pas vérifiables.
Méthode vérifiée le 8 septembre 2026. Elle réduit les risques d’une migration, mais ne garantit ni le maintien de chaque position ni l’absence de fluctuation.
Une refonte préserve des fonctions, pas une copie de balises
Le référencement existant ne tient pas dans des titres et descriptions à recopier. Une URL peut répondre à une intention, recevoir des liens et mener vers une offre. Le plan SEO doit préciser ce que la nouvelle page garde, améliore ou abandonne avant les maquettes finales.
Une refonte ne justifie pas à elle seule de changer une URL. Si une page conserve son sujet et son rôle, garder son adresse retire une opération de migration. Si vous changez aussi le domaine, le CMS, l’hébergement et les contenus, séparez les changements quand le projet le permet. Google recommande de ne changer qu’un élément à la fois afin de limiter les causes possibles d’un incident (Google Search Central).
Comment construire l’inventaire avant la refonte ?
L’inventaire doit réunir plusieurs sources. Le sitemap montre des URL déclarées, le CMS les contenus administrés, les journaux et l’outil analytique les accès, Search Console les requêtes, impressions, clics et liens connus de Google.
Pour chaque URL, consignez au moins ces éléments :
| Champ | Preuve à rechercher | Décision que la preuve éclaire |
|---|---|---|
| Rôle de la page | contenu visible, offre, téléchargement ou étape du parcours | conserver le rôle, le déplacer ou l’arrêter |
| Visibilité organique | requêtes, impressions et clics sur une période comparable | préserver la réponse et suivre la nouvelle URL |
| Liens internes et externes | crawl, navigation, Search Console et sources de trafic | mettre à jour les liens et éviter une destination sans rapport |
| Action utile | demande reçue, appel, téléchargement ou étape réellement suivie | conserver le parcours et sa mesure |
| État technique | statut HTTP, canonical, indexabilité, langue et contenu rendu | corriger avant de prendre l’existant comme référence |
| Saisonnalité ou obligation | calendrier métier, archive nécessaire ou contrainte légale | éviter de supprimer une page seulement parce qu’elle est calme |
L’absence de clics dans un export ne suffit pas à supprimer une page. La période peut être trop courte, la mesure incomplète ou la page utile par un lien direct. Notez « preuve manquante » au lieu de transformer une absence de donnée en certitude.
Si l’état initial reste difficile à reconstituer, un audit SEO, GEO et UX exploitable peut séparer constat, preuve, impact, action et contrôle avant de poursuivre.
Quelle destination choisir pour chaque ancienne URL ?
Chaque URL doit recevoir une décision explicite. Trois destinations couvrent la plupart des cas.
| Décision | Quand la choisir | Résultat attendu |
|---|---|---|
| Conserver l’URL | le sujet et la fonction restent comparables | la nouvelle page répond à la même adresse avec un statut 200 |
| Regrouper et rediriger | une nouvelle page reprend réellement le besoin de l’ancienne | l’ancienne adresse redirige directement vers cette destination |
| Supprimer sans redirection | le contenu n’a plus d’équivalent utile et ne doit plus être disponible | l’ancienne adresse renvoie correctement un statut 404 ou 410 |
Une redirection doit conduire la personne et le moteur vers une réponse de remplacement. Envoyer toutes les suppressions vers l’accueil retire ce lien de sens ; Google avertit que ces destinations non pertinentes peuvent être traitées comme des erreurs de type soft 404 (Google Search Central).
Lorsque le changement est définitif, Google recommande une redirection permanente côté serveur, généralement 301 ou 308 (Google Search Central). Visez directement la destination finale. Une chaîne ancienne URL → URL intermédiaire → nouvelle URL ajoute de la latence et complique le diagnostic.
Le registre de migration transforme la liste en décisions
Ajoutez à l’inventaire la nouvelle URL, le contenu à conserver, le statut attendu, la règle de redirection, le contrôle à exécuter et son responsable. Ce registre devient la référence commune du contenu, du développement et de la validation.
Une ligne complète peut se lire ainsi :
/ancienne-offrereçoit des impressions sur une intention encore couverte. Son contenu de preuve rejoint/nouvelle-offre. L’ancienne URL doit répondre en301directement vers la nouvelle ; la nouvelle doit répondre en200, se déclarer canonique, apparaître dans le sitemap et recevoir les liens internes mis à jour. La personne chargée de la recette vérifie ces résultats avant la bascule.
La cohérence compte autant que chaque balise. Google présente les redirections et rel="canonical" comme des signaux forts, et le sitemap comme un signal plus faible. Si la redirection vise une URL, le canonical une autre et le sitemap une troisième, l’équipe ne donne pas une instruction claire (Google Search Central).
Exemple rempli : la refonte fictive d’un site de maintenance
Cet exemple est fictif. Il ne décrit ni une mission cliente ni un résultat Klaapp.
Une PME de maintenance industrielle change de CMS et simplifie ses offres sans changer de domaine. L’inventaire croise CMS, sitemap, Search Console, mesure des demandes et liens entrants.
| Ancienne URL | Observation fictive | Décision et contrôle |
|---|---|---|
/maintenance-preventive |
page d’offre visible et utilisée avant plusieurs demandes | conserver l’URL, la réponse principale et le parcours vers le contact |
/services/maintenance-industrielle |
sujet proche, contenu plus faible et aucun rôle distinct confirmé | regrouper dans la première page, puis rediriger directement vers elle |
/guides/checklist-arret-usine.pdf |
document encore téléchargé et lié depuis un site professionnel | conserver le fichier ou rediriger son URL exacte vers le document repris |
/actualites/salon-maintenance-2019 |
événement terminé, information périmée et aucune destination équivalente | retirer avec un statut 410, sans renvoi vers l’accueil |
/contact |
étape utilisée par toutes les offres | conserver l’URL, tester le formulaire, la réception et la mesure |
Le domaine et trois adresses utiles restent stables. Une seule fusion exige une redirection. Le PDF reçoit une décision propre au lieu de disparaître avec l’ancienne médiathèque. La PME pourra réécrire une page après la migration, sans confondre une erreur de bascule avec l’effet d’une nouvelle promesse.
Quels contrôles doivent bloquer la mise en ligne ?
La date de lancement ne doit pas transformer un échec connu en tâche pour plus tard. Utilisez quatre portes de décision et adaptez les échantillons au volume du site.
- Couverture. Toutes les URL trouvées ont une décision, et chaque page importante issue des données ou des liens est incluse.
- Destination. Chaque redirection mène en un seul parcours vers une page équivalente ; aucune boucle, chaîne évitable ou destination générique ne reste sur les URL prioritaires.
- Rendu et indexabilité. Les nouvelles pages répondent avec le statut prévu, rendent leur contenu, déclarent le bon canonical et ne conservent aucun
noindexou blocage de préproduction involontaire. - Mesure et exploitation. Les accès Search Console restent valides, le sitemap contient les URL canoniques, les formulaires arrivent réellement et une personne sait examiner journaux et erreurs après lancement.
Testez aussi images, téléchargements, données structurées et liens internes. La recette doit prévoir le retrait du noindex ou des autres protections temporaires. Google demande de tester pages, images, formulaires et téléchargements, puis de retirer les blocages au démarrage (Google Search Central).
Si une porte échoue sur une page qui porte une offre, un trafic ou un lien important, reportez la bascule ou retirez cette page du lot. Une refonte progressive de l’existant peut être moins risquée qu’une reconstruction simultanée.
Que faire pendant et après la bascule ?
Activez les pages, redirections et liens internes selon le même registre. Vérifiez immédiatement statuts, destinations, canonicals, règles robots et sitemap. En cas de changement de domaine, préparez aussi les propriétés Search Console et le changement d’adresse adapté.
Google recommande de conserver les redirections aussi longtemps que possible, généralement au moins un an. Gardez-les plus longtemps si d’anciens favoris ou liens sont encore utilisés, tout en corrigeant vos propres liens.
Le suivi doit séparer quatre familles de signaux :
- service rendu : réponses
200, redirections attendues, erreurs404ou5xx, disponibilité des médias et des formulaires ; - exploration et indexation : accès de Googlebot, URL envoyées dans le sitemap, pages indexées et motifs d’exclusion ;
- visibilité : impressions, clics et requêtes par groupes de pages comparables ;
- activité : demandes réellement reçues, appels, téléchargements ou actions utiles définies avant la refonte.
Une baisse globale ne donne pas la cause. Isolez les groupes stables, redirigés, fusionnés et supprimés. Pour un groupe redirigé, contrôlez d’abord destination, chaîne, canonical, contenu rendu et liens internes. Si la technique est conforme, comparez ensuite les requêtes et l’intention servie.
Google indique que la visibilité peut fluctuer pendant le retraitement des URL. Cela n’autorise pas à ignorer une erreur technique, ni à promettre « zéro perte » ou à déclarer l’échec après un seul jour.
Les erreurs qui font perdre la trace de la migration
- Concevoir avant l’inventaire, puis reconstruire l’ancien site depuis des souvenirs.
- Déduire qu’une page est inutile parce qu’un outil ne lui attribue aucun clic.
- Renommer toutes les URL sans bénéfice pour les utilisateurs ou les rediriger vers l’accueil.
- Laisser le nouveau site canonique vers la préproduction, bloqué par
noindexou absent du sitemap. - Modifier simultanément domaine, CMS, contenu et mesure sans pouvoir isoler leurs effets.
- Regarder seulement le trafic total ou retirer trop tôt l’ancien hébergement et les redirections.
Préparer la refonte avec Klaapp
Klaapp peut examiner l’inventaire, les décisions d’URL, les contrôles de mise en ligne et la continuité de mesure avant le développement. Le premier échange sert à repérer les preuves disponibles, les destinations encore ambiguës et les portes qui doivent conditionner la bascule. L’accompagnement de refonte d’un site ou d’un logiciel peut aussi conclure qu’il faut conserver davantage d’existant ou fractionner le projet.
Questions fréquentes
Faut-il conserver toutes les URL pendant une refonte ?
Non. Conservez l’URL si la page garde son rôle. Redirigez-la si une destination réellement équivalente reprend ce rôle. Si le contenu disparaît sans remplacement pertinent, un statut 404 ou 410 est plus honnête qu’une redirection vers l’accueil. Vérifiez auparavant les liens, usages et périodes qui pourraient manquer à vos mesures.
Quelle différence entre une redirection 301, 308 et 302 ?
Les statuts 301 et 308 signalent un déplacement permanent ; Google les utilise comme signal vers la nouvelle URL canonique. Le statut 302 décrit un déplacement temporaire et aide à conserver l’ancienne URL comme référence. Le choix dépend donc du caractère définitif de la décision, pas d’une préférence de l’outil.
Combien de temps faut-il garder les redirections après la refonte ?
Google recommande de garder les redirections aussi longtemps que possible, généralement au moins un an. Une durée supérieure reste utile si d’anciens liens ou favoris sont encore employés. Mettez à jour vos liens internes et les liens externes importants pour envoyer directement vers la nouvelle adresse.
Peut-on garantir qu’une refonte ne fera perdre aucune position ?
Non. Même une migration préparée peut produire des fluctuations pendant la nouvelle exploration et l’indexation. L’objectif raisonnable est de conserver les signaux utiles, détecter rapidement les erreurs et expliquer les écarts par groupe de pages. Une garantie de position ignorerait les changements du site, des concurrents et du moteur.
Sources
- Google Search Central — Déplacement de site avec modification d’URL
- Google Search Central — Redirections et recherche Google
- Google Search Central — Indiquer une URL canonique
- Google Search Central — Changer d’hébergement
Thomas R. est cofondateur de Klaapp. Il porte les choix techniques, l’IA appliquée et la formation, avec un regard entrepreneurial sur la fiabilité et les coûts d’exploitation. Découvrir le studio Klaapp.