Refonte de site web : comment ne pas perdre son SEO ?

Une refonte de site web peut modifier des URL, des contenus, le maillage interne, les balises, le rendu technique et parfois le domaine lui-même. Pour Google, cela signifie qu’une partie des pages doit être recrawlée, réévaluée ou associée à de nouvelles adresses.

Une migration bien préparée réduit les erreurs évitables, mais elle ne garantit pas l’absence de fluctuation. Google indique qu’un changement d’URL peut provoquer des variations de classement pendant le recrawl et la réindexation du site.

Le bon objectif n’est donc pas de promettre « zéro perte », mais de préserver ce qui mérite de l’être : URL utiles, contenus, liens internes, signaux de canonicalisation, données structurées et mesure des performances. Les changements nécessaires peuvent ensuite être suivis dans Search Console après la mise en ligne.

Avant la refonte : inventorier ce que Google connaît déjà

Une migration SEO commence avant la nouvelle maquette. Il faut d’abord connaître les pages actuellement accessibles, celles qui reçoivent des impressions ou des clics, les URL qui possèdent des liens externes et les contenus qui jouent un rôle important dans le parcours du site.

Un crawl de l’ancien site permet de récupérer les URL, les codes HTTP, les balises principales, les canonicals et les liens internes. Search Console complète cette vue avec les pages et requêtes qui génèrent réellement de la visibilité.

Cet inventaire sert ensuite de référence. Une page peu visitée n’est pas automatiquement inutile, et une ancienne URL ne doit pas être supprimée simplement parce qu’elle ne correspond plus à la future navigation.

Conserver une URL lorsqu’il n’existe pas de bonne raison de la changer

Une refonte graphique ou technique n’oblige pas à modifier les adresses des pages. Lorsque l’URL reste compréhensible, cohérente avec le contenu et déjà connue par Google, la conserver évite une migration inutile.

Changer /services/creation-site pour /expertises/site-web uniquement parce que la nouvelle arborescence paraît plus élégante ajoute du travail sans garantir aucun bénéfice SEO.

Une URL peut en revanche évoluer lorsque la structure précédente est devenue incohérente, lorsqu’un contenu est réellement déplacé ou lorsque plusieurs pages sont restructurées. Dans ce cas, le changement doit être prévu dans le plan de migration.

Redirections 301 : relier chaque ancienne URL à la bonne destination

Lorsqu’une page change définitivement d’adresse, une redirection permanente permet d’envoyer les utilisateurs et les moteurs vers sa nouvelle destination. Google recommande les redirections permanentes pour les changements durables d’URL.

La destination doit rester cohérente avec le contenu de l’ancienne page. Une ancienne page service doit idéalement pointer vers la page qui reprend ce service, et non vers la page d’accueil simplement parce qu’aucune correspondance n’a été prévue.

Google indique également que les redirections permanentes ne provoquent pas de perte de PageRank. Il n’est donc pas nécessaire d’utiliser d’anciens pourcentages supposés de « jus SEO transféré » pour évaluer une migration.

Le plan de redirection doit être préparé avant la mise en ligne puis testé. Les chaînes inutiles et les boucles doivent être corrigées afin que chaque ancienne adresse atteigne proprement sa destination finale.

Toutes les anciennes URL n’ont pas besoin d’être redirigées

Une URL supprimée ne doit pas être redirigée artificiellement vers une page sans rapport uniquement pour éviter une 404. Si le contenu n’existe plus et qu’aucune destination équivalente n’est pertinente, un véritable code 404 ou 410 peut être cohérent.

La priorité est de préserver les pages qui ont une vraie continuité : service déplacé, article renommé, catégorie réorganisée ou contenu fusionné dans une nouvelle page qui répond encore à la même intention.

Le guide sur les erreurs 404 explique pourquoi toutes les pages introuvables ne représentent pas le même problème SEO.

Préparer le nouveau site sans l’indexer trop tôt

Le nouvel environnement doit pouvoir être testé avant la bascule sans créer une seconde version indexable du site. Une préproduction peut être protégée par authentification ou configurée de manière à ne pas apparaître dans les résultats de recherche.

Il faut toutefois vérifier que les protections temporaires seront retirées au moment de la mise en ligne. Une balise noindex, une restriction d’accès ou une règle robots conservée par erreur peut empêcher Google d’explorer correctement le nouveau site.

Avant le lancement, les pages importantes doivent également être testées comme le ferait un visiteur : navigation, formulaires, liens, médias et autres fonctions réellement nécessaires au site.

Conserver les contenus et les intentions qui fonctionnent déjà

Une redirection ne compense pas une page devenue moins pertinente. Si une ancienne page répondait précisément à une recherche et que la nouvelle version supprime l’essentiel de son contenu, son URL peut être correctement redirigée tout en perdant sa capacité à répondre à la même intention.

La refonte doit donc distinguer ce qui relève du design de ce qui relève du contenu. Simplifier une interface n’oblige pas à supprimer les informations qui permettent aux visiteurs et aux moteurs de comprendre une offre.

Les pages peuvent être réécrites ou fusionnées lorsque cela améliore réellement leur utilité, mais ces décisions doivent être prises à partir de leur rôle actuel plutôt que d’une volonté générale de réduire le nombre de pages.

Titles, canonicals, données structurées et métadonnées : contrôler le transfert

Une migration ne concerne pas uniquement les URL visibles dans le navigateur. Les balises title, descriptions, canonicals, données structurées et directives d’indexation doivent également être vérifiées sur le nouveau site.

Une canonical qui pointe encore vers la préproduction, une ancienne URL ou une autre page peut envoyer un signal contradictoire. À l’inverse, une URL déplacée doit être cohérente avec les redirections, les liens internes et le sitemap.

Le guide consacré au sitemap, robots.txt et canonical détaille ces mécanismes et leurs rôles respectifs.

Mettre à jour le maillage interne

Les redirections servent surtout à gérer la transition depuis les anciennes adresses. À l’intérieur du nouveau site, les liens devraient pointer directement vers les URL finales plutôt que continuer à passer par les anciennes redirections.

Cela concerne la navigation, les liens éditoriaux, les breadcrumbs, les CTA et les autres composants capables de créer des liens internes.

Une refonte peut également modifier la profondeur des pages. Une page importante auparavant accessible depuis la navigation ne devrait pas devenir difficile à atteindre simplement parce que le nouveau design privilégie une structure plus minimaliste.

Sitemap et robots.txt : vérifier les fichiers réellement publiés

Le sitemap du nouveau site doit contenir les URL canoniques que l’on souhaite faire découvrir et suivre. Les anciennes URL redirigées n’ont pas vocation à rester durablement dans le sitemap principal.

Le fichier robots.txt doit lui aussi correspondre à la production réelle. Une règle utilisée pendant le développement ne doit pas empêcher par erreur l’exploration de ressources ou de sections nécessaires après la mise en ligne.

Ces fichiers ne remplacent ni les redirections ni les canonicals. Ils participent à des fonctions différentes et doivent rester cohérents avec l’architecture finale.

Le jour de la bascule : contrôler les points critiques

Une migration doit être vérifiée dès que la nouvelle version devient accessible publiquement. Il ne s’agit pas d’attendre que Google signale tous les problèmes plusieurs jours plus tard.

• Les anciennes URL importantes redirigent vers la destination prévue
• Les pages finales répondent correctement en HTTP
• Les balises noindex de préproduction ont disparu
• Les canonicals correspondent aux URL finales
• Le sitemap contient les nouvelles URL
• Les liens internes pointent vers les destinations finales
• Les principaux formulaires et parcours fonctionnent
• Analytics et les outils de mesure reçoivent les données attendues
• Search Console peut toujours être utilisée pour suivre le site

Le niveau de contrôle doit être adapté à la taille et à la criticité du site. Il n’existe pas de durée universelle de test ou de fenêtre de lancement valable pour tous les projets.

Après la refonte : surveiller Search Console sans paniquer au premier mouvement

Une migration avec changement d’URL peut provoquer des fluctuations pendant que Google recrawle les anciennes et les nouvelles pages. Google précise que le déplacement se fait URL par URL et qu’il n’existe pas de fréquence fixe à laquelle Googlebot doit revenir sur chaque page.

Les premiers contrôles doivent porter sur les erreurs d’exploration, l’indexation des nouvelles pages, les redirections, les impressions, les clics et les requêtes réellement touchées.

Une petite variation globale ne doit pas déclencher automatiquement un rollback. À l’inverse, une disparition massive de pages importantes, une hausse des erreurs serveur ou des redirections cassées demande une investigation immédiate.

Le suivi doit continuer tant que les principales URL n’ont pas retrouvé une situation compréhensible. La durée dépend de la taille du site, de la fréquence de crawl et de l’ampleur des changements.

Changer de domaine demande des contrôles supplémentaires

Une refonte conservant le même domaine n’est pas identique à une migration vers un nouveau domaine. Dans ce second cas, l’ensemble des URL change et Google doit également comprendre que le site se déplace vers une nouvelle propriété.

Search Console propose un outil de changement d’adresse pour certains déplacements de domaine, en complément des redirections et des autres contrôles de migration.

Le guide dédié au changement de domaine détaille ce cas particulier. Il ne faut pas appliquer automatiquement toutes ses étapes à une simple refonte qui conserve le même domaine.

WordPress vers Next.js, changement de CMS ou nouvelle stack : le framework n’est pas le sujet principal

Passer de WordPress à Next.js, de Drupal à un autre CMS ou d’un site statique à une nouvelle architecture ne constitue pas automatiquement un gain ou une perte SEO.

Les risques apparaissent surtout lorsque la migration modifie les URL, le contenu rendu, les métadonnées, les canonicals, les liens internes, les données structurées ou l’accessibilité des pages aux moteurs.

La nouvelle technologie peut apporter des bénéfices de maintenance, de performance ou d’expérience utilisateur, mais elle ne dispense pas de préparer la continuité SEO.

Si la refonte concerne également la conception du nouveau site, le guide pour préparer une refonte permet de cadrer les objectifs avant de modifier l’existant.

Que faire si le trafic chute malgré les précautions ?

Une baisse après migration doit être analysée à partir des données plutôt qu’attribuée automatiquement à une pénalité Google.

Commencez par comparer les pages et requêtes avant et après la bascule, puis vérifiez les codes HTTP, redirections, canonicals, indexation, maillage et différences de contenu sur les URL réellement touchées.

Le guide sur la reprise SEO après une refonte ratée détaille la méthode lorsque le nouveau site est déjà en production et que la visibilité a effectivement chuté.

À retenir : préserver le SEO consiste surtout à préserver la continuité

Une refonte ne doit pas chercher à figer le site uniquement pour éviter tout mouvement dans Google. Elle peut modifier ce qui doit réellement évoluer, à condition de comprendre les conséquences de ces changements.

Conserver une URL pertinente reste le choix le plus simple. Lorsqu’elle change, une redirection permanente vers une destination cohérente, des liens internes mis à jour et des signaux techniques alignés facilitent la transition.

Après la mise en ligne, Search Console permet de vérifier ce que Google découvre réellement. Les fluctuations doivent être analysées page par page et requête par requête plutôt qu’avec un seuil universel de perte de trafic.

Si la refonte doit encore être cadrée, Websual peut accompagner la création ou la refonte du site en intégrant le référencement naturel dès la préparation du projet.