Refaire son site sans perdre son référencement : la checklist

Un client type arrive avec un site refait, un nouveau design, un back-office plus confortable — et une chute de trafic organique de 30 à 60% dans les six semaines qui suivent la mise en ligne. Le scénario est classique : l’agence ou le prestataire a soigné l’interface et oublié que Google indexait des centaines d’URLs, des balises et des maillages qui n’existent plus une fois le nouveau site en ligne. Une refonte de site web mal préparée peut détruire en quelques jours un positionnement construit sur plusieurs années. Cette checklist couvre ce qu’il faut vérifier avant, pendant et après la bascule pour ne pas perdre ce capital.

Faire l’inventaire complet de l’existant avant de coder quoi que ce soit

La première erreur est de commencer la refonte par le design. Avant d’ouvrir un éditeur de code, il faut savoir précisément ce que Google connaît du site actuel. Trois exports sont indispensables :

• La liste de toutes les URLs indexées, récupérée dans Google Search Console (rapport Couverture, ou export via l’API) et croisée avec un crawl complet du site (Screaming Frog en mode liste ou spider, jusqu’à épuisement des 500 URLs gratuites ou en version payante pour les sites plus gros).
• Les pages qui génèrent réellement du trafic organique, via Search Console (Performances, filtré sur les 16 derniers mois) ou Google Analytics — ce sont celles qu’il ne faut surtout pas perdre en route.
• Le profil de backlinks, via un outil comme Ahrefs ou Search Console (liens externes) : une page qui reçoit des liens externes a une valeur de référencement qui ne se reconstruit pas en changeant simplement l’URL.

Sans cet inventaire, impossible de savoir ensuite quelles pages ont disparu ou changé d’adresse sans redirection.

Construire un mapping des redirections avant la bascule, pas après

Le mapping consiste à faire correspondre chaque ancienne URL à sa nouvelle destination, une par une. Ce travail se fait dans un tableur, en confrontant l’export de crawl à la nouvelle arborescence prévue. Les règles à respecter :

• Une redirection 301 (permanente), jamais une 302 : le 302 indique à Google que le changement est temporaire et ne transmet pas correctement le jus de lien.
• Une redirection vers une page réellement équivalente sur le fond, pas systématiquement vers la page d’accueil. Rediriger en masse tout un site vers l’accueil est traité par Google comme une absence de redirection.
• Pas de chaînes de redirections (URL A vers B vers C) : chaque saut ajoute de la latence et dilue une partie du signal. Un redirect checker permet de vérifier qu’on arrive en une seule étape.
• Le mapping doit être finalisé et testé en environnement de préproduction avant le jour J, pas improvisé une fois le nouveau site en ligne.

Sur un site vitrine de quelques dizaines de pages, ce travail prend une demi-journée. Sur un catalogue e-commerce de plusieurs milliers de fiches produits, c’est un chantier à part entière qui doit être budgété dès le devis.

Ne pas casser ce qui fonctionne déjà : structure d’URLs, titres, contenu

Une refonte est souvent l’occasion de repenser l’arborescence. C’est légitime, mais chaque changement de structure d’URL a un coût en SEO qu’il faut mesurer face au bénéfice attendu. Trois principes simples :

• Si une page se positionne bien sur une requête précise, conserver son contenu textuel principal (ou l’améliorer, jamais le réduire) et son titre <title>, même si le design change entièrement autour.
• Éviter de changer les slugs d’URL sans raison SEO valable. Passer de /services/creation-site-internet à /nos-prestations/creation-web n’apporte rien si l’ancienne URL était déjà courte et descriptive — et impose une redirection supplémentaire à maintenir.
• Conserver le maillage interne entre pages proches thématiquement : c’est souvent ce maillage, plus que le contenu isolé d’une page, qui explique un bon positionnement.

C’est aussi le moment de vérifier que la nouvelle version ne repose pas sur un page builder qui génère du HTML surchargé (Elementor et Divi sont connus pour multiplier les balises inutiles et alourdir le DOM) : un thème PHP natif, plus léger, limite ce risque dès la conception plutôt que de devoir le corriger après coup.

Protéger l’environnement de préproduction de l’indexation

Erreur fréquente et coûteuse : la préproduction (le sous-domaine ou l’espace de test où le nouveau site est construit) se retrouve indexée par Google avant même le lancement, créant du contenu dupliqué avec le site en production. Trois vérifications avant toute mise en ligne de préproduction :

• Un fichier robots.txt qui bloque totalement l’indexation (Disallow: /), ou mieux, une balise meta name="robots" content="noindex" sur toutes les pages.
• Une protection par mot de passe (HTTP Auth) si le CMS ou l’hébergeur le permet, pour éviter tout accès non désiré.
• Une vérification, juste avant la bascule finale, que ces protections seront bien retirées sur l’environnement de production — l’erreur inverse (un noindex oublié sur le site final) est tout aussi fréquente et catastrophique.

Le jour de la bascule : la séquence à respecter

La mise en ligne elle-même se joue en quelques heures et l’ordre des opérations compte :

1. Basculer le DNS ou le déploiement vers le nouveau site avec toutes les redirections 301 déjà actives.
2. Vérifier immédiatement un échantillon représentatif d’anciennes URLs (pages à fort trafic en priorité) pour confirmer que les redirections répondent bien en 301 et pointent vers la bonne destination.
3. Soumettre le nouveau sitemap XML dans Google Search Console et demander une nouvelle exploration des pages principales.
4. Vérifier que la Search Console et Google Analytics sont bien rattachés au nouveau site (le code de suivi analytics est un oubli classique lors des refontes).
5. Contrôler les balises canoniques : chaque page doit pointer vers elle-même, pas vers une ancienne URL ou une URL de préproduction restée en cache.

Surveiller les 30 jours qui suivent, pas seulement le jour J

Google ne réévalue pas un site instantanément. La réindexation complète prend généralement entre deux et six semaines selon la taille du site et sa fréquence de crawl habituelle. Pendant cette période :

• Surveiller le rapport Couverture de Search Console pour repérer les erreurs 404 sur des URLs qui auraient dû être redirigées.
• Comparer semaine après semaine les positions des requêtes principales (via Search Console ou un outil de suivi de position) plutôt que d’attendre un mois pour regarder les chiffres.
• Vérifier les temps de chargement mobile avec PageSpeed Insights : une refonte est aussi l’occasion de corriger les Core Web Vitals, mais un nouveau site plus lourd en JavaScript peut aussi les dégrader si le développement n’a pas été pensé pour la performance dès le départ.
• Garder les redirections actives au minimum un an, idéalement de façon permanente : supprimer une redirection 301 six mois après la refonte peut réactiver la perte qu’on avait évitée.

Budgéter ce travail dans le projet de refonte

Le mapping de redirections, l’audit préalable et le suivi post-lancement ne sont pas un service accessoire ajouté après coup : c’est une partie du travail de refonte elle-même, qui doit être chiffrée dans le devis initial au même titre que le développement du thème ou l’intégration du back-office. Les tarifs varient fortement selon la taille du site et le nombre d’URLs à mapper ; la page tarif freelance wordpress détaille les fourchettes de prix habituelles selon le type de projet. Pour un site vitrine d’une trentaine de pages, ce travail reste limité ; pour un site avec blog actif ou catalogue produits, il peut représenter plusieurs jours à lui seul.

FAQ

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

Si les redirections 301 sont correctement en place dès le lancement, la majorité des positions se stabilisent en deux à six semaines. Un site sans historique de refonte préalable, avec un mapping propre et un contenu conservé, peut même ne montrer aucune baisse visible. À l’inverse, un site où les redirections ont été oubliées ou mal faites peut mettre plusieurs mois à récupérer, et certaines pages perdues ne remontent jamais à leur niveau initial.

Faut-il garder les mêmes URLs lors d’une refonte ?

Ce n’est pas obligatoire, mais c’est la solution la plus sûre. Si les URLs actuelles sont propres, courtes et cohérentes avec le contenu, il n’y a aucune raison SEO de les changer : chaque URL modifiée impose une redirection permanente à maintenir et un risque d’erreur. Ne changer les URLs que si l’ancienne structure pose un vrai problème (URLs générées automatiquement illisibles, doublons, absence de hiérarchie logique).

Une refonte complète du design fait-elle automatiquement baisser le référencement ?

Non, le design n’a pas d’impact direct sur le classement. Ce qui compte pour Google, c’est le contenu textuel, la structure HTML sémantique, les temps de chargement et la présence de redirections propres. Un nouveau design construit sur un thème natif propre, sans page builder alourdissant le code, peut même améliorer les Core Web Vitals et donc indirectement le référencement, à condition que la migration technique respecte les points de cette checklist.

Si votre projet de refonte implique une migration de plusieurs dizaines ou centaines de pages, mieux vaut cadrer le mapping de redirections avant de lancer le développement : la page site vitrine présente la méthode de travail appliquée à ce type de projet, et un devis détaillé sous 48h permet de chiffrer précisément ce volet SEO en amont.