Refonte de site web : ne pas perdre son référencement (SEO)

Refondre son site est l'occasion de moderniser le design, la vitesse et les fonctions. C'est aussi l'un des moments les plus risqués pour votre visibilité : des URL qui changent, des pages supprimées, des redirections oubliées, et des mois de travail de référencement peuvent disparaître en quelques jours. Une refonte de site web réussie sur le plan du SEO n'a rien de magique : elle demande de l'inventaire, de la rigueur et des tests avant et après la mise en ligne.

Cet article suit la documentation officielle de Google (Search Central) et présente une méthode en étapes pour migrer un site sans perdre son référencement : audit de l'existant, redirections 301, hreflang pour les sites multilingues, sitemaps, Core Web Vitals, changement d'adresse dans la Search Console et suivi après lancement.

Ce qui est en jeu lors d'une refonte

Un moteur de recherche ne connaît votre site qu'à travers ses URL. Si une page bien classée change d'adresse sans redirection, Google doit réapprendre qu'elle existe, et les liens externes qui pointaient vers elle (les « backlinks ») ne servent plus. Les causes de baisse de trafic les plus courantes après une refonte :

• URL modifiées sans redirections ou avec des redirections incorrectes ;
• contenu supprimé ou fortement réduit ;
• balises de titre, descriptions, structure des titres (H1, H2) perdues ;
• site laissé en « noindex » après la mise en ligne, ou fichier robots.txt bloquant ;
• pages plus lentes, navigation moins claire ;
• liens internes cassés ou pointant vers l'ancien site.

Bonne nouvelle : tout cela se prévient. Mauvaise nouvelle : cela doit être planifié dès le début du projet, pas la veille du lancement.

Étape 1 : faire l'inventaire de l'existant

Avant de toucher à quoi que ce soit, documentez ce qui fonctionne.

• La liste complète des URL : export du CMS, exploration du site avec un outil de crawl, sitemap actuel.
• Les pages qui génèrent du trafic et des conversions : rapport Performances de la Search Console et votre outil d'analyse.
• Les pages avec des liens entrants : indispensables à conserver ou rediriger.
• Les éléments SEO de chaque page : titre, description, H1, URL canonique, hreflang, données structurées.
• Les performances techniques de départ : mesures Core Web Vitals, pour comparer avant et après.

Gardez ce fichier : c'est votre base de comparaison et votre plan de redirections.

Étape 2 : décider quoi conserver, fusionner ou supprimer

Une refonte permet de faire le ménage, mais pas à l'aveugle. Pour chaque page :

• Conserver : elle se classe, convertit ou reçoit des liens. Gardez son contenu, ou améliorez-le sans le réduire.
• Fusionner : plusieurs pages faibles sur le même sujet deviennent une page solide, avec redirection des anciennes vers la nouvelle.
• Supprimer : une page sans valeur peut être retirée. Google conseille de renvoyer une erreur 404 ou 410 pour le contenu que vous ne déplacez pas.

Pour savoir comment structurer vos contenus et votre budget en amont, vous pouvez aussi consulter notre guide sur le prix de la création d'un site web professionnel.

Étape 3 : la carte des redirections 301

C'est le cœur de la migration. Chaque ancienne URL doit pointer vers son équivalent le plus proche sur le nouveau site.

Les règles de Google, détaillées dans son guide de migration de site, sont claires. Source : Google Search Central, déplacer un site avec changement d'URL :

• utilisez des redirections permanentes côté serveur (301 ou 308), de chaque ancienne URL vers son équivalent ;
• redirigez directement vers la destination finale pour éviter les chaînes ; si ce n'est pas possible, Google recommande de limiter les chaînes à trois sauts idéalement, et à moins de cinq ;
• ne redirigez pas en masse toutes les anciennes URL vers la page d'accueil ; chaque page doit pointer vers un contenu équivalent ;
• gardez les redirections au moins un an pour que les signaux soient transférés.

Pourquoi côté serveur ? La documentation de Google sur les redirections explique que les redirections côté serveur sont interprétées de manière la plus fiable, que les redirections en JavaScript sont un dernier recours car le rendu peut échouer, et que les redirections temporaires (302, 307) n'indiquent pas à Google que la nouvelle URL doit remplacer l'ancienne. Source : Google Search Central, redirections et Google Search.

Exemple de tableau de redirection

Testez la carte avec un script sur la liste complète des URL avant la mise en ligne, puis contrôlez à nouveau après. Chaque ancienne URL doit répondre par une 301 vers une page qui répond elle-même 200.

Étape 4 : les éléments techniques de la nouvelle version

Avant d'ouvrir le site aux robots, vérifiez :

• Robots.txt et noindex : retirez les blocages de la préproduction. Un « noindex » oublié est une cause classique de désastre.
• URL canoniques : chaque page doit avoir une balise canonique pointant vers elle-même (ou vers la bonne version). Google recommande une canonique auto-référente sur les nouvelles URL.
• Titres, descriptions, H1 : conservez ou améliorez ceux des pages qui se classent.
• Liens internes : mettez à jour pour pointer directement vers les nouvelles URL, sans passer par les redirections.
• Données structurées : reportez-les (produits, articles, organisation, FAQ).
• Images et médias : conservez des noms de fichiers et des textes alternatifs cohérents.

Étape 5 : hreflang pour un site multilingue

Si votre site existe en plusieurs langues, la migration est le moment où les erreurs de hreflang se glissent. D'après la documentation de Google, les règles essentielles sont les suivantes. Source : Google Search Central, versions localisées :

• chaque version doit pointer vers toutes les autres, et ces pages doivent pointer en retour ; sans réciprocité, Google peut ignorer les balises ;
• chaque page doit se référencer elle-même dans son ensemble d'annotations ;
• une version x-default désigne la page de repli pour les utilisateurs dont la langue ne correspond à aucune version, par exemple une page de sélection de langue ;
• les trois méthodes (balises HTML, en-têtes HTTP, sitemap XML) se valent : choisissez-en une et tenez-vous-y ;
• les codes de langue suivent la norme ISO 639-1, avec un code pays optionnel ISO 3166-1 Alpha 2, et les URL doivent être complètes, avec le protocole.

Si vous changez la structure d'URL, mettez à jour les annotations hreflang pour les nouvelles adresses, comme le recommande aussi le guide de migration.

Étape 6 : les sitemaps

Le sitemap aide Google à découvrir vos nouvelles URL. Source : Google Search Central, créer et soumettre un sitemap :

• limitez chaque fichier à 50 000 URL ou 50 Mo non compressés, et utilisez un index de sitemaps au-delà ;
• n'y listez que les URL canoniques que vous voulez voir apparaître dans les résultats ;
• n'indiquez lastmod que s'il est exact ; Google ignore priority et changefreq ;
• soumettez-le dans la Search Console ou déclarez-le dans le fichier robots.txt ; un sitemap n'est qu'une indication.

Lors d'une migration, soumettez le sitemap du nouveau site et retirez l'ancien. Le guide de migration précise que des avertissements sur des URL de l'ancien sitemap qui redirigent sont normaux et peuvent être ignorés.

Étape 7 : performances et Core Web Vitals

La refonte est l'occasion d'améliorer la vitesse, ou de la dégrader par mégarde. Google recommande d'obtenir de bons Core Web Vitals : LCP (chargement) à 2,5 secondes ou moins, INP (réactivité) à 200 millisecondes ou moins, CLS (stabilité visuelle) à 0,1 ou moins, évalués au 75e centile et séparément sur mobile et ordinateur. Sources : web.dev, Core Web Vitals et Google Search Central.

Google ne présente pas ces métriques comme un facteur de classement unique, mais comme alignées sur ce que ses systèmes cherchent à valoriser. En clair : un site rapide et stable aide, sans remplacer un contenu pertinent.

Deux exemples chez nous. Pour la boutique allemande Kachouri Getränke-Service, migrée de Shopware 5 vers WooCommerce (812 produits), le décalage de mise en page mobile (CLS) est passé de 0,44 à 0. Sur la web app PDF Nova, les mesures de laboratoire Lighthouse mobile donnent 95 en performance et 100 en accessibilité, bonnes pratiques et SEO. Ce sont des mesures de laboratoire, à compléter par des données de terrain sur votre propre site.

Mesurez avant (Étape 1) et après, page par page, sur les modèles principaux : accueil, page de service, article, fiche produit.

Étape 8 : le changement d'adresse dans la Search Console

Si votre domaine change (ancien-site.fr vers nouveau-site.fr), utilisez l'outil de changement d'adresse. Si vous restez sur le même domaine (changement de structure d'URL, passage de HTTP à HTTPS, www vers non-www), l'outil n'est pas nécessaire.

Les règles, d'après l'aide officielle. Source : Aide Search Console, changement d'adresse :

• utilisez-le après avoir déplacé le site et mis en place les redirections ;
• vous devez être propriétaire de l'ancienne et de la nouvelle propriété dans la Search Console, avec le même compte Google ;
• il fonctionne sur des propriétés de domaine ; vérifiez et migrez chaque variante de l'ancien domaine (sous-domaines, www et non-www) ;
• configurez les redirections 301 de l'ancienne page d'accueil vers la nouvelle, et idéalement des autres pages canoniques ;
• la période de transfert dure 180 jours ; gardez les redirections au moins ce temps, et plus longtemps si vous recevez encore du trafic via Google. Le guide de migration recommande généralement un an minimum ;
• gardez l'ancien nom de domaine enregistré au moins un an.

Le guide de migration précise aussi que, pour un site de taille moyenne, il peut falloir quelques semaines ou plus pour que Google affiche les nouvelles URL, et que Googlebot doit visiter chaque URL de l'ancien et du nouveau site au moins une fois avant que le déplacement soit complet. Ne paniquez donc pas si les fluctuations durent plusieurs semaines.

Étape 9 : le jour du lancement et les semaines suivantes

Checklist de lancement

• Redirections 301 actives et testées sur l'ensemble de la liste d'URL
• Noindex et blocage robots.txt retirés
• Canoniques et hreflang corrects
• Sitemap du nouveau site soumis, ancien sitemap retiré
• Liens internes mis à jour
• Données structurées présentes
• Suivi des analyses et événements de conversion fonctionnel
• Changement d'adresse déposé si le domaine change
• Sauvegarde complète de l'ancien site conservée

Suivi après lancement

Surveillez chaque semaine pendant au moins deux à trois mois : le rapport de couverture/indexation de la Search Console, les erreurs « introuvable », les impressions et clics des pages principales, les mots-clés stratégiques, les Core Web Vitals sur données de terrain et les conversions. Le guide de Google recommande de contrôler les erreurs 404 inhabituelles. Corrigez les redirections manquantes dès qu'elles apparaissent.

Quand migrer une plateforme : WordPress, Shopify, sur mesure

Un changement de plateforme (par exemple de Shopware à WooCommerce, ou de WordPress à une application sur mesure) cumule les risques : URL, templates, données, performances. La logique reste la même : inventaire, carte de redirections, tests. Pour le choix de plateforme, lisez nos comparatifs WordPress ou développement sur mesure et Shopify, WooCommerce ou sur mesure. Pour une refonte complète du site vitrine, notre service de création de site web intègre la planification SEO dès le cadrage. Nous avons notamment redessiné le site du Club Photo Tunis (activités, événements, photothèque, réservation d'adhésion).

FAQ

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

Cela dépend de la taille du site et de la qualité de la migration. Google indique qu'un site de taille moyenne peut demander quelques semaines ou plus pour que la plupart des pages soient traitées. Des fluctuations temporaires sont normales ; une baisse durable signale un problème à investiguer.

Faut-il utiliser l'outil de changement d'adresse pour passer en HTTPS ?

Non. D'après l'aide Google, il ne sert pas pour un passage HTTP vers HTTPS, un changement www ou non-www, ni un changement d'hébergeur sans modification d'URL. Il concerne les changements de domaine ou de sous-domaine.

Combien de temps garder les redirections 301 ?

Au moins un an selon le guide de migration de Google, et plus si des liens externes ou des utilisateurs continuent d'utiliser les anciennes URL. Elles coûtent peu à conserver.

Peut-on refondre le design sans changer les URL ?

Oui, et c'est souvent la solution la plus sûre : si vos URL, contenus et balises restent les mêmes, le risque diminue fortement. Changez les URL seulement s'il y a une raison claire.

Que faire si le trafic chute après le lancement ?

Vérifiez d'abord les basiques : noindex, robots.txt, redirections cassées, canoniques, sitemap. Comparez avec votre inventaire de départ, puis corrigez page par page. Une cause technique est plus fréquente qu'une sanction.

Faut-il refaire le contenu en même temps que la forme ?

Pas forcément. Limiter les changements simultanés rend les causes plus faciles à identifier. Si vous améliorez le contenu, faites-le sans réduire ce qui fonctionne.

Conclusion

Une migration sans perte de SEO tient en quelques principes : inventorier, cartographier les redirections 301 une à une, soigner les éléments techniques (canoniques, hreflang, sitemaps, Core Web Vitals), déclarer le changement d'adresse quand le domaine change, et surveiller après le lancement. Si vous préparez une refonte et voulez la sécuriser, contactez-nous : nous construisons le plan de redirection et les tests avec vous, avant la mise en ligne.