Refonte de site web : comment migrer sans perdre son référencement

Le paradoxe de la refonte : dépenser pour progresser, et voir le trafic s'effondrer

Un site vieillissant, un design daté, une navigation qui date d'une autre époque. La décision de refondre tombe, souvent pour de bonnes raisons. Puis, six semaines après la mise en ligne du nouveau site, le graphique Search Console pique du nez. Moins 40 %. Parfois moins 70 %.

Cette histoire, les agences SEO la voient passer plusieurs fois par an. Et à chaque fois, le même scénario : le nouveau site est plus beau, plus rapide, mieux pensé pour l'utilisateur. Mais quelque chose s'est cassé en chemin.

Une précision importante avant d'aller plus loin : cette chute n'a rien d'inévitable. Ce n'est pas une taxe technique que Google prélèverait sur les projets de refonte. Dans l'immense majorité des cas, la perte de trafic découle d'un audit qui n'a pas été fait, ou fait trop tard. Le SEO n'a pas été invité à la table au moment du cahier des charges, il a été consulté trois jours avant le lancement, quand toutes les décisions structurantes étaient déjà prises et budgétées.

La méthode qui suit se déroule en trois temps : avant, pendant, après. Rien de révolutionnaire. Juste de la rigueur, appliquée dans le bon ordre.

Pourquoi une refonte fait chuter le référencement

Commençons par écarter une croyance tenace : non, Google ne « punit » pas les sites refondus. Il n'existe aucun filtre anti-refonte. Ce qui se produit est beaucoup plus mécanique, et donc beaucoup plus évitable.

Les causes réelles se comptent sur les doigts de deux mains :

• La perte de l'historique d'URL. Les anciennes adresses disparaissent sans redirection, ou avec une redirection approximative. Tout le capital accumulé sur ces URL part avec elles.
• La suppression de pages qui généraient du trafic. Souvent des pages anciennes, oubliées, qui ne figuraient dans aucun tableau de bord mais captaient tranquillement des dizaines de requêtes longue traîne chaque mois.
• L'appauvrissement du contenu. Le fameux « on épure ». Une page de 1 800 mots devient une page de 350 mots parce que le nouveau design ne supporte pas les blocs de texte longs.
• Le bouleversement du maillage interne. Un menu qui rétrécit, des fils d'Ariane supprimés, des blocs « articles liés » passés à la trappe. La popularité interne ne circule plus de la même manière.
• La perte des balises et données structurées. Title réécrits automatiquement par le nouveau CMS, meta descriptions vidées, balisage schema.org non reporté.
• La dégradation des performances. Un framework JavaScript moderne mal optimisé peut faire exploser le LCP alors même que le site « paraît » plus rapide.
• Le blocage accidentel. Un Disallow: / ou une balise noindex oubliée en préproduction, mise en ligne telle quelle. Cause numéro un des effondrements brutaux et totaux.

Le mythe du « Google va comprendre tout seul »

Il faut le dire clairement. Google finit effectivement par comprendre. Mais « finir par » signifie parfois trois mois, parfois davantage sur un site de plusieurs milliers d'URL. Et pendant ce temps, le chiffre d'affaires organique, lui, ne patiente pas.

Le moteur doit recrawler l'intégralité des anciennes URL, suivre les redirections, réattribuer les signaux de popularité aux nouvelles adresses, puis réévaluer la pertinence du nouveau contenu. Sur un site à faible budget de crawl, ce cycle s'étale. Beaucoup.

La patience n'est pas une stratégie de migration. C'est ce qui reste quand on n'a pas eu de stratégie.

Refonte graphique, refonte technique, refonte de contenu : trois profils de risque

Toutes les refontes ne se valent pas en termes d'exposition. Avant de paniquer ou de sous-estimer le chantier, il vaut la peine de situer son propre projet.

Risque faible : refonte purement visuelle, même CMS, mêmes URL, même contenu, même arborescence. On change la peau, pas le squelette. Les points de vigilance se limitent aux performances et au maillage.

Risque modéré : changement de CMS ou de template avec conservation de l'arborescence. Les URL bougent peu, mais le rendu HTML change du tout au tout. Attention aux balises et au contenu réellement servi.

Risque élevé : nouvelle arborescence, nouvelles URL, contenu réécrit. Là, tout est à cartographier et à rediriger.

Risque maximal : changement de nom de domaine cumulé avec une nouvelle arborescence. Le combo le plus délicat, celui qui exige une préparation chirurgicale.

Phase 1 : l'audit préalable, socle de toute migration réussie

C'est l'étape que tout le monde veut raccourcir. C'est aussi celle qui détermine 80 % du résultat final.

Cartographier l'existant avec un crawl de référence

Première action, avant même que le prestataire web n'ouvre son éditeur : crawler l'intégralité du site actuel. Screaming Frog, Sitebulb, ou l'outil de votre choix. Peu importe. Ce qui compte, c'est d'exporter le résultat et de le dater.

Ce référentiel doit contenir, pour chaque URL :

• l'adresse complète et son code réponse HTTP
• le title et la meta description
• le H1 et la structure des Hn
• la balise canonique
• la directive robots (index/noindex, follow/nofollow)
• la profondeur de clic depuis la page d'accueil
• le nombre de liens internes entrants

Ce fichier deviendra la référence absolue pendant toute la durée du projet. Il servira à construire le plan de redirection, à vérifier le report des balises, à contrôler le maillage après lancement. Sans lui, on navigue à vue.

Identifier les pages à réelle valeur SEO

Toutes les pages n'ont pas la même importance. Encore faut-il savoir lesquelles comptent vraiment, et la réponse n'est pas toujours celle qu'on attend.

Le croisement se fait sur trois sources :

Search Console. Impressions, clics, position moyenne, requêtes positionnées. Exportez sur 16 mois pour capturer la saisonnalité complète.

Analytics. Sessions organiques, taux de conversion, valeur générée par page. Une page à faible trafic mais forte conversion vaut mieux qu'une page à fort trafic sans effet business.

Backlinks. Majestic, Ahrefs, Haloscan. Quelles pages reçoivent des liens externes, et de quelle qualité.

De ce croisement naît une matrice de priorisation. Et c'est ici que le piège se referme sur beaucoup de projets : la tentation de ne conserver que le top 50 des pages les plus performantes. Erreur classique. Sur un site éditorial mature, la longue traîne représente régulièrement 40 % du trafic organique, répartie sur des centaines d'URL qui font chacune vingt visites mensuelles. Sacrifiez-les toutes, et vous perdez presque la moitié de votre acquisition, sans qu'aucune page individuelle ne vous ait alerté.

Photographier le point zéro

Comment prouver qu'une migration s'est bien passée si l'on ne sait pas d'où l'on part ? Cette question paraît triviale. Elle est pourtant à l'origine d'innombrables débats stériles entre client et prestataire trois mois après un lancement.

Avant le jour J, il faut figer :

• un relevé de positionnement complet sur l'ensemble des mots-clés suivis
• un export Search Console sur 16 mois (requêtes, pages, pays, appareils)
• les Core Web Vitals de référence, terrain et laboratoire
• les volumes de trafic organique par typologie de page

Ces données ne servent pas à faire joli dans un rapport. Elles constituent le seul moyen de distinguer, plus tard, une baisse liée à la migration d'une baisse liée à la saisonnalité ou à une mise à jour d'algorithme.

Inventorier les backlinks et leurs pages réceptrices

Les liens externes représentent un actif qui a coûté du temps, parfois de l'argent, souvent des années. Chaque page recevant un backlink de valeur doit figurer sur une liste à part.

Ces URL sont non négociables. Elles seront redirigées une par une, vers l'équivalent le plus proche sur le nouveau site. Jamais vers la page d'accueil. On y revient juste après.

Phase 2 : construire le plan de redirection

Le cœur du réacteur. Un plan de redirection propre sauve une migration ; un plan bâclé la condamne.

Le tableau de correspondance

Un fichier, deux colonnes essentielles : ancienne URL, nouvelle URL. Éventuellement une troisième pour le commentaire ou l'arbitrage retenu.

La règle est simple à énoncer, exigeante à appliquer : une redirection 1 pour 1, vers l'équivalent sémantique le plus proche. Si l'ancienne page traitait de la rénovation de toiture à Lyon, la nouvelle URL doit traiter du même sujet. Pas la catégorie parente « travaux », pas la page d'accueil, pas une page de contact.

Toutes les URL indexées doivent figurer dans ce tableau. Pas seulement celles du menu principal. Pas seulement les 200 premières du crawl.

Les erreurs qui tuent une redirection

Elles reviennent avec une régularité déconcertante. Les voici, par ordre de dégâts causés :

La redirection massive vers la page d'accueil. Le raccourci fatal. Google traite ces redirections comme des soft 404 et ignore purement et simplement le signal transmis. Autant ne rien faire.

Les chaînes de redirections. URL A vers URL B vers URL C vers URL D. Chaque saut dilue et ralentit. Sur des migrations successives, il n'est pas rare de trouver des chaînes de cinq maillons héritées de trois refontes antérieures. Nettoyez : pointez directement vers la destination finale.

Les boucles. Rares mais catastrophiques. Une URL qui se redirige vers elle-même, directement ou via un détour. Le crawler abandonne.

La 302 au lieu de la 301. Une redirection temporaire ne transmet pas les signaux de la même manière qu'une permanente. Sur une refonte, c'est toujours du 301.

Les oublis systémiques. Les URL avec paramètres (tri, filtres, tracking), les versions www et non-www, les variantes http et https, les URL paginées, les fichiers PDF positionnés dans les résultats, les images qui génèrent du trafic via Google Images. Chacune de ces familles mérite sa propre règle de redirection.

Les pages supprimées sans équivalent

Que faire d'une page qui n'a tout simplement plus de correspondance ? Un service abandonné, un produit retiré du catalogue, un article obsolète.

Deux options, et l'arbitrage mérite réflexion.

Si une page parente traite d'un sujet réellement proche, la redirection 301 vers cette page a du sens. L'internaute qui arrive depuis un vieux lien trouve un contenu connexe, pas une impasse.

Si aucune page ne s'approche du sujet, mieux vaut assumer une suppression propre. Un code 410 (Gone) indique explicitement à Google que la ressource a disparu définitivement, ce qui accélère sa sortie de l'index et évite de gaspiller du budget de crawl. Une page d'erreur 404 personnalisée, avec des suggestions de navigation, fait le reste côté utilisateur.

Contre-intuitif mais vrai : une redirection non pertinente est souvent pire qu'une suppression assumée. Elle génère de la déception utilisateur, brouille les signaux sémantiques et finit de toute façon traitée comme un soft 404.

Cas particulier : le changement de nom de domaine

Ici, les précautions se cumulent.

L'outil de changement d'adresse dans Search Console doit être utilisé. Il ne fait pas tout, mais il accélère sensiblement la prise en compte du transfert par Google.

L'ancien domaine doit être conservé et maintenu actif. Douze mois au minimum, idéalement sans limite de durée. Le coût annuel d'un nom de domaine est ridicule comparé à la valeur des redirections qu'il porte. Trop de migrations réussies ont été ruinées deux ans plus tard par un renouvellement oublié.

Enfin, une démarche que peu d'entreprises entreprennent et qui fait pourtant une vraie différence : contacter les éditeurs des backlinks les plus puissants pour leur demander de mettre à jour le lien vers la nouvelle adresse. C'est fastidieux, ça prend des semaines, ça n'aboutit que dans un cas sur trois. Mais un lien direct vaut toujours mieux qu'un lien redirigé.

Phase 3 : préserver le contenu et la structure sémantique

Migrer les balises, pas seulement les textes

Les textes visibles sont rarement oubliés. Ce sont les éléments invisibles qui disparaissent en silence.

La checklist de report, champ par champ :

• balise title (attention aux templates de CMS qui la génèrent automatiquement et écrasent les optimisations manuelles)
• meta description
• structure Hn complète, avec un seul H1 par page
• attributs alt des images
• balises canoniques
• attributs hreflang sur les sites multilingues
• données structurées schema.org (produit, article, avis, FAQ, fil d'Ariane, organisation)
• balises Open Graph et Twitter Card

Un détail qui coûte cher : les données structurées. Elles ne sont visibles nulle part sur la page, personne ne les réclame pendant la recette, et pourtant leur disparition fait perdre du jour au lendemain les étoiles d'avis, les prix affichés dans les résultats, les FAQ déployées. Le trafic ne s'écroule pas forcément, mais le taux de clic, si.

Ne pas sacrifier le contenu sur l'autel du design

Voilà le sujet de friction par excellence entre référenceurs et directions artistiques.

Le nouveau design est aéré, respirant, épuré. Superbe, sincèrement. Sauf qu'il ne prévoit que 300 mots là où l'ancienne page en comptait 1 500, et que ces 1 200 mots supprimés portaient l'essentiel des expressions sur lesquelles la page se positionnait.

Comment défendre le volume rédactionnel sans passer pour le rabat-joie de service ? En sortant les chiffres. Prenez les cinq pages concernées, montrez leur trafic, leurs requêtes positionnées, leur contribution au chiffre d'affaires. La discussion change immédiatement de nature : on ne parle plus d'esthétique contre SEO, on parle d'un arbitrage économique documenté.

Les solutions de compromis existent, et elles fonctionnent. Accordéons, onglets, blocs « lire la suite ». Google indexe le contenu masqué par ces dispositifs à condition qu'il soit présent dans le HTML servi, et non chargé après un clic via JavaScript. La nuance est technique mais décisive : contenu replié visuellement, oui ; contenu absent du code source, non.

Reconstruire le maillage interne

Le maillage interne distribue la popularité à l'intérieur du site. Modifier la navigation, c'est redessiner cette distribution, souvent sans s'en rendre compte.

Le contrôle à effectuer est direct : pour chaque page stratégique, comparer le nombre de liens internes entrants avant et après. Le crawl de référence de la phase 1 sert précisément à cela.

Les régressions les plus fréquentes :

• un menu principal simplifié qui passe de 8 entrées à 4, coupant l'accès direct à des rubriques entières
• la disparition des blocs « articles liés » ou « produits similaires » en bas de page
• l'abandon des fils d'Ariane, qui portaient un maillage ascendant discret mais efficace
• un footer allégé qui ne pointe plus vers les pages secondaires
• des pages devenues orphelines, accessibles uniquement par l'URL directe

Une page sans lien interne entrant, c'est une page que Google finira par considérer comme secondaire. Puis par oublier.

Phase 4 : la recette technique en préproduction

Protéger la préproduction sans se piéger soi-même

La préproduction ne doit pas être indexée. Tout le monde est d'accord. Le problème vient de la méthode choisie pour l'empêcher.

Les deux mauvaises solutions : une balise noindex globale, ou un Disallow: / dans le robots.txt. Pourquoi mauvaises ? Parce qu'elles sont invisibles pour l'œil humain le jour de la mise en ligne. Le site part en production avec la protection encore active, et l'intégralité des pages sort de l'index en quelques jours.

Ce scénario reste, année après année, la première cause d'effondrement brutal post-refonte. Effondrement total, d'ailleurs : pas 40 % de perte, mais 95 %.

La bonne méthode : une authentification HTTP au niveau du serveur. Elle bloque les robots aussi efficacement, elle est impossible à oublier (personne ne peut accéder au site sans la retirer), et elle ne laisse aucune trace dans le code une fois désactivée.

Tester les redirections avant la mise en ligne

Le plan de redirection existe sur le papier. Fonctionne-t-il réellement ?

La vérification consiste à crawler la liste complète des anciennes URL contre l'environnement de préproduction, et à contrôler trois choses pour chacune : le code réponse est bien un 301, la destination est bien celle prévue au mapping, et il n'y a pas de saut intermédiaire.

L'objectif de couverture : 100 % des URL à valeur SEO. Pas 95 %. Les 5 % restants contiennent toujours, par une malice statistique dont le SEO a le secret, la page qui rapportait le plus.

Performances et Core Web Vitals

Un site refait est censé être plus rapide. Il l'est rarement d'emblée.

Les trois métriques à mesurer sur la préprod : LCP (affichage du contenu principal), INP (réactivité aux interactions), CLS (stabilité visuelle).

Les coupables habituels sur les refontes récentes :

• un framework JavaScript qui embarque plusieurs centaines de kilo-octets avant le premier pixel utile
• des images en pleine résolution servies sans compression ni format moderne
• des polices personnalisées bloquantes, chargées depuis un domaine tiers
• l'accumulation de scripts tiers (tag manager, chat, cookies, analytics, pixels publicitaires) qui s'empilent sans jamais être audités
• des animations au défilement qui provoquent des décalages de mise en page

Rendu JavaScript et indexabilité

Question simple, conséquences majeures : le contenu est-il présent dans le HTML servi, ou construit côté client après exécution du JavaScript ?

Google sait exécuter le JavaScript. Mais il le fait en deux temps, avec un délai variable et un budget contraint. Sur un site de taille moyenne, le rendu différé peut retarder l'indexation de plusieurs semaines. Sur un gros site, certaines pages ne passent jamais l'étape.

Le test tient en deux gestes : afficher le code source brut (Ctrl+U) et vérifier que les textes, titres et liens y figurent. Puis utiliser l'outil d'inspection d'URL de Search Console, qui montre exactement ce que Googlebot obtient après rendu. Si les deux versions divergent fortement, il y a un sujet à traiter avant la mise en ligne, pas après.

La checklist du jour J

À cocher, dans l'ordre, avant d'annoncer que le site est en ligne :

• authentification de préproduction retirée
• robots.txt de production en place, sans Disallow: /
• aucune balise noindex résiduelle sur les pages à indexer
• balises canoniques pointant vers les bonnes URL en https
• certificat SSL valide, redirection http vers https active
• redirections 301 effectives et testées en production
• sitemap.xml généré, à jour, soumis dans Search Console
• propriété Search Console configurée pour le nouveau site
• balises analytics et de suivi de conversion opérationnelles
• page 404 personnalisée fonctionnelle
• tests de formulaires et de tunnel de commande

Phase 5 : les 72 heures qui suivent la mise en ligne

Le site est en ligne. C'est maintenant que le travail de surveillance commence, et il se joue en heures, pas en semaines.

Le monitoring d'urgence

Ce que l'on regarde dès la première journée :

• les erreurs 404 remontées par Search Console et par les logs serveur
• le statut d'exploration : Googlebot accède-t-il normalement au site ?
• les premières indexations de nouvelles URL
• les erreurs serveur 5xx, signe d'une infrastructure sous-dimensionnée
• le temps de réponse réel sous charge

Une 404 détectée à H+6 se corrige en dix minutes. La même, découverte trois semaines plus tard, a déjà coûté son positionnement à la page.

Accélérer la découverte par Google

Trois actions concrètes, dans cet ordre.

Soumettre le nouveau sitemap dans Search Console, en s'assurant qu'il ne contient que des URL en 200, canoniques et indexables.

Conserver temporairement l'ancien sitemap, s'il est encore accessible. Cela semble paradoxal, mais c'est une technique éprouvée : il pousse Googlebot à recrawler les anciennes URL, donc à découvrir les redirections plus vite. On le retire au bout de quelques semaines.

Demander l'indexation manuelle des pages les plus stratégiques via l'outil d'inspection d'URL. Le quota est limité, alors on le réserve à la vingtaine de pages qui portent le chiffre d'affaires.

L'analyse de logs, l'outil que presque personne n'utilise

Voilà probablement le conseil le plus sous-exploité de cette liste.

Les logs serveur enregistrent chaque passage de Googlebot : quelle URL, quand, quel code réponse. Ils révèlent en 48 heures ce que Search Console mettra trois semaines à afficher.

Ce qu'on y trouve concrètement : le budget de crawl gaspillé sur des anciennes URL mal redirigées, les pages neuves que Googlebot n'a jamais visitées (souvent des orphelines du maillage), les zones du site totalement ignorées, les erreurs 500 intermittentes que personne n'avait remarquées.

Un simple export de logs sur 72 heures, passé dans un tableur ou un outil dédié, en apprend plus qu'un mois d'attente passive devant les rapports Google.

Phase 6 : stabilisation et mesure sur trois mois

À quoi ressemble une migration réussie

Même parfaitement exécutée, une refonte provoque des remous. Il faut le savoir pour ne pas déclencher la cellule de crise au premier frémissement.

La courbe normale : une baisse modérée de 10 à 20 % pendant deux à quatre semaines, le temps que Google recrawle et réattribue. Puis un retour progressif au niveau initial entre la quatrième et la huitième semaine. Puis, si la refonte a réellement amélioré le contenu, la structure et les performances, une progression au-delà du point de départ.

Les fluctuations quotidiennes de 5 à 10 % font partie du bruit habituel. Elles n'existaient pas moins avant la refonte, on les regardait simplement moins souvent.

Le signal d'alerte réel : une baisse supérieure à 30 % qui ne s'inverse pas après trois semaines. Là, il faut diagnostiquer.

Diagnostiquer une baisse persistante

Un arbre de décision, à dérouler dans l'ordre.

La baisse touche-t-elle tout le site ou un groupe de pages ? Une chute globale évoque un problème technique transversal (indexabilité, robots.txt, performances). Une chute localisée oriente vers un problème de contenu ou de maillage sur un cluster précis.

Les nouvelles URL sont-elles indexées ? Le rapport de couverture Search Console donne la réponse en trente secondes. Si le taux d'indexation plafonne, le sujet est technique.

Les redirections fonctionnent-elles vraiment ? Recrawler la liste des anciennes URL en production. Chercher les 404, les chaînes, les 302, les destinations erronées.

Le contenu a-t-il été appauvri ? Comparer le volume de texte et la couverture sémantique avant/après sur les pages en baisse. C'est souvent là que se cache la réponse.

Une mise à jour d'algorithme est-elle tombée au même moment ? Vérifier les dates. Un core update concomitant complique le diagnostic, mais il ne l'annule pas : les deux effets se cumulent et se distinguent par leur profil de baisse.

Les indicateurs de contrôle

Cinq KPI à suivre sur toute la période de stabilisation :

• taux d'indexation des nouvelles URL (objectif : plus de 90 % des pages à valeur SEO)
• évolution de la position moyenne par cluster de pages, pas en global
• trafic organique par typologie (accueil, catégories, produits, articles)
• volume d'erreurs 404 déclarées par Search Console
• Core Web Vitals mesurés sur données réelles utilisateurs

Le calendrier type d'une refonte respectueuse du SEO

Sur un projet de taille moyenne, comptez huit à douze semaines entre le cadrage et la mise en ligne. Voici la répartition qui fonctionne.

Semaines 1 et 2 : cadrage et audit. Crawl de référence, extraction des données de performance, inventaire des backlinks, définition des pages à valeur. Livrable : le référentiel complet de l'existant.

Semaines 3 et 4 : arborescence et arbitrages. Construction de la nouvelle structure en tenant compte des contraintes SEO. Décisions sur les pages conservées, fusionnées, supprimées. Livrable : arborescence validée.

Semaines 5 à 8 : production et plan de redirection. Développement en parallèle de la construction du mapping URL. Report des balises, contrôle du contenu. Livrable : tableau de redirection complet.

Semaines 9 et 10 : recette technique. Tests de redirection sur préproduction, contrôle des balises, mesure des performances, vérification du rendu. Livrable : rapport de recette validé.

Semaine 11 : mise en ligne et monitoring intensif.

Semaine 12 et suivantes : suivi, corrections, mesure.

Deux règles qui n'ont l'air de rien et qui évitent beaucoup de week-ends gâchés.

D'abord, le référenceur intervient dès le cahier des charges. Pas au moment de la recette, pas trois jours avant le lancement. Les décisions les plus lourdes de conséquences (arborescence, choix technologique, volume de contenu par gabarit) se prennent au début. Après, tout arbitrage devient un coûteux retour en arrière.

Ensuite, jamais de mise en ligne un vendredi. Ni la veille d'un pont, ni en pleine haute saison commerciale. Un site e-commerce ne migre pas en novembre. Un site touristique ne migre pas en juin. Le bon moment, c'est le creux d'activité, un mardi matin, avec toute l'équipe disponible pendant 72 heures.

Les erreurs les plus coûteuses observées sur le terrain

Le noindex oublié. Cinq caractères dans un template. Résultat : 95 % du trafic organique évaporé en dix jours. Détecté au bout de trois semaines. Six mois pour tout récupérer. Évitable avec une authentification HTTP en préprod et une checklist de mise en ligne.

La redirection globale vers la page d'accueil. Solution de facilité choisie faute de temps pour construire le mapping. Toutes les URL redirigées vers la racine. Google traite l'ensemble en soft 404, aucun signal transmis, capital SEO réduit à zéro. Évitable avec deux jours de travail sur un tableur.

Le blog supprimé « parce qu'il ne convertit pas ». Deux cents articles effacés sans redirection. Ils généraient 45 % du trafic organique et alimentaient l'ensemble du maillage interne. Découvert deux mois après, contenus perdus, aucune sauvegarde. Évitable avec une analyse de contribution avant décision.

Le changement de domaine sans conservation de l'ancien. Domaine non renouvelé quatorze mois après la migration. Toutes les redirections tombent d'un coup, les backlinks historiques pointent dans le vide. Évitable pour le prix d'un renouvellement annuel.

La refonte livrée sans référentiel de départ. Baisse constatée, mais impossible de mesurer son ampleur réelle ni d'identifier les pages touchées. Trois mois passés à reconstruire une base de comparaison approximative au lieu de corriger. Évitable avec un crawl et un export, soit deux heures de travail en amont.

Questions fréquentes

Combien de temps pour retrouver son trafic après une refonte ?

Sur une migration bien préparée, quatre à huit semaines pour revenir au niveau initial. Sur un site de plus de 10 000 URL, comptez jusqu'à trois mois, le temps que le recrawl complet s'effectue. Si rien n'a bougé au bout de quatre mois, ce n'est plus une question de patience : il y a un problème structurel à diagnostiquer.

Faut-il garder les anciennes URL à tout prix ?

Non, mais il faut les rediriger à tout prix. Changer une structure d'URL pour la rendre plus claire et plus logique est un choix parfaitement défendable, à condition que chaque ancienne adresse pointe en 301 vers son équivalent. Ce qui compte n'est pas de figer les URL, c'est de ne jamais rompre la chaîne.

Une refonte peut-elle améliorer le référencement ?

Absolument, et c'est même l'objectif. Une arborescence plus cohérente, des performances améliorées, un contenu enrichi, un maillage repensé : ces quatre leviers produisent des gains réels, généralement visibles à partir du deuxième ou troisième mois. Encore faut-il que la refonte ait été pensée comme un projet SEO et pas seulement comme un projet graphique.

Doit-on prévenir Google d'une refonte ?

Il n'existe pas de formulaire « je refais mon site ». En revanche, deux actions font office de signalement : l'outil de changement d'adresse dans Search Console en cas de nouveau domaine, et la soumission du nouveau sitemap. Pour le reste, ce sont les redirections et le crawl qui informent le moteur.

Que faire si le trafic ne revient pas au bout de trois mois ?

Reprendre le diagnostic à zéro, dans l'ordre : indexation, redirections, contenu, maillage, performances, algorithme. Dans la grande majorité des cas, la cause est identifiable et corrigeable. Un audit post-migration ciblé permet de localiser le point de rupture en quelques jours, plutôt que d'attendre une amélioration qui ne viendra pas d'elle-même.

Une refonte n'est pas un risque SEO, c'est un projet SEO

Toute la différence entre une migration réussie et une catastrophe tient dans une seule décision : à quel moment le référencement entre dans la conversation.

Intégré dès le cahier des charges, il oriente l'arborescence, sécurise le contenu, cadre les choix techniques. Consulté trois jours avant le lancement, il ne peut plus que constater les dégâts et rédiger le rapport d'autopsie.

Trois jalons ne se négocient pas. L'audit préalable, qui fige l'existant et identifie ce qui a de la valeur. Le plan de redirection, construit puis testé en préproduction. Le monitoring post-lancement, mené dans les heures qui suivent la mise en ligne et non le mois d'après.

Le reste relève de l'exécution, et l'exécution s'organise.

Un projet de refonte en préparation ? FDSEO accompagne les migrations de A à Z : cadrage SEO en amont du cahier des charges, audit complet de l'existant, construction et recette du plan de redirection, monitoring des 72 heures critiques et suivi de stabilisation sur trois mois. Parlons-en avant que les développeurs ne commencent, c'est là que tout se joue.