Refonte sans perdre son trafic : la checklist des redirections

Une refonte de site mal préparée peut faire chuter le trafic organique de 30 à 70 % en quelques jours. Ce n’est pas une hypothèse : c’est ce que j’observe régulièrement sur des sites qui changent de structure sans plan de redirections. Le pire, c’est que la plupart de ces pertes sont évitables avec une checklist rigoureuse appliquée avant, pendant et après la mise en ligne. Cet article détaille chaque étape, chaque vérification et chaque outil pour que votre refonte conserve le référencement durement acquis.

Pourquoi une refonte fait perdre du trafic

Google indexe des URL précises. Quand vous changez la structure de votre site, chaque page qui existait à une adresse donnée et qui se retrouve à une autre adresse devient, aux yeux du moteur, une page disparue. Le robot reçoit un code 404, retire la page de l’index, et le trafic associé tombe à zéro. En parallèle, la nouvelle URL doit être découverte, crawlée, indexée, puis positionnée : un processus qui prend plusieurs semaines.

Les causes les plus fréquentes de perte de trafic lors d’une refonte sont les suivantes :

• Changement de slugs : passer de /nos-services/creation-web à /services/web sans redirection
• Suppression de pages : retirer des pages jugées obsolètes qui généraient encore du trafic longue traîne
• Changement de domaine : migrer de monsite.com vers monsite.fr sans plan de redirection inter-domaines
• Modification du maillage interne : les liens internes pointent vers d’anciennes URL qui n’existent plus
• Perte du balisage : les données structurées, les balises title et meta description sont réinitialisées

Selon les recommandations officielles de Google sur les redirections, le transfert de signal SEO via une 301 prend un certain temps, mais il préserve la grande majorité de l’autorité de la page source. Ne pas poser de redirection revient à jeter cette autorité.

Si vous vous demandez si votre site a réellement besoin d’une refonte, j’ai détaillé les signaux qui montrent qu’il est temps de refondre dans un article dédié.

L’audit pré-refonte : inventorier tout ce qui compte

Avant de toucher à quoi que ce soit, il faut photographier l’existant. Cet audit constitue la base de votre plan de migration. Voici les éléments à collecter :

Crawler l’intégralité du site actuel

Utilisez Screaming Frog (gratuit jusqu’à 500 URL) ou Sitebulb pour crawler le site. Exportez la liste complète des URL avec leurs codes de statut, leurs balises title, meta description, H1, et le nombre de liens internes entrants. Ce fichier sera votre référence absolue.

Exporter les données Search Console

Dans la Google Search Console, exportez le rapport de performances sur les 12 derniers mois. Triez par pages et notez les URL qui génèrent le plus de clics et d’impressions. Ce sont vos pages prioritaires : elles doivent impérativement être redirigées correctement.

Lister les backlinks

Les liens entrants pointent vers des URL précises. Si ces URL disparaissent, vous perdez le bénéfice de ces liens. Exportez vos backlinks depuis la Search Console (section Liens) ou depuis un outil comme Ahrefs. Identifiez les pages qui reçoivent le plus de liens externes : elles sont critiques.

Capturer le sitemap existant

Téléchargez le fichier sitemap.xml actuel. Il contient la liste des URL que vous avez vous-même déclarées comme importantes. Comparez-le avec le crawl : s’il manque des pages dans le sitemap, c’est un problème à corriger dans la nouvelle version.

Pour structurer cet audit, un cahier des charges bien construit inclut toujours une section dédiée à la migration SEO. C’est le moment de l’exiger si votre prestataire ne l’a pas prévu.

Construire le fichier de mapping URL par URL

Le fichier de mapping est le document central de toute migration. Il s’agit d’un tableur avec au minimum trois colonnes : l’ancienne URL, la nouvelle URL correspondante, et le statut de la redirection. Voici comment le construire méthodiquement.

Partez de la liste des URL crawlées. Pour chaque URL de l’ancien site, déterminez :

1. La page existe-t-elle dans le nouveau site ? Si oui, notez la nouvelle URL en face
2. La page a-t-elle été fusionnée avec une autre ? Redirigez vers la page fusionnée
3. La page a-t-elle été supprimée ? Redirigez vers la page parente la plus pertinente, jamais vers la page d’accueil sauf s’il n’existe aucune alternative

Un site vitrine de 30 pages visibles peut facilement compter 200 URL indexées en réalité : pages de catégories, pages d’archives, pages de tags, pages de pagination, versions avec et sans slash final. Le mapping doit toutes les couvrir. Pour un site e-commerce ou un blog actif, ce chiffre monte rapidement à 1 000 ou 2 000 lignes.

Ce travail de mapping représente souvent 2 à 5 jours de travail selon la taille du site. C’est un poste de coût à intégrer dans le budget global de votre site. Les prestataires qui ne le mentionnent pas dans leur devis ne l’ont probablement pas prévu.

301, 302, canonical : quel type de redirection utiliser

Toutes les redirections ne se valent pas. Le choix du type a un impact direct sur le transfert d’autorité SEO.

La redirection 301 (permanente)

C’est le standard pour toute migration. Elle indique à Google que la page a définitivement changé d’adresse. Le moteur transfère progressivement l’autorité de l’ancienne URL vers la nouvelle. C’est celle que vous utiliserez dans 95 % des cas lors d’une refonte.

La redirection 302 (temporaire)

Elle signale un déplacement temporaire. Google conserve l’ancienne URL dans son index en attendant qu’elle redevienne active. Ne l’utilisez jamais pour une migration définitive : le transfert d’autorité n’a pas lieu, ou très partiellement.

La balise canonical

Ce n’est pas une redirection à proprement parler. Elle indique à Google quelle version d’une page est la version principale quand plusieurs URL affichent un contenu similaire. Utile pour les doublons internes, mais insuffisante pour remplacer une 301 lors d’une migration : l’utilisateur qui clique sur l’ancienne URL verra toujours l’ancien contenu ou une erreur.

Le meta refresh et le JavaScript redirect

À éviter absolument. Les redirections côté client (meta refresh, window.location) ne transmettent pas correctement le signal SEO. Google les tolère mais ne les recommande pas. Restez sur des redirections serveur (301/302) configurées au niveau du fichier .htaccess, du serveur Nginx, ou du CMS.

Implémenter les redirections selon votre CMS

La méthode technique dépend de votre infrastructure. Voici les approches les plus courantes.

Sur Apache (.htaccess)

La majorité des hébergements mutualisés français tournent sur Apache. Les redirections se configurent dans le fichier .htaccess à la racine du site :

RewriteEngine On
RewriteRule ^nos-services/creation-site$ /services/creation-site-web [R=301,L]
RewriteRule ^blog/ancien-article$ /blog/nouvel-article [R=301,L]

Pour les migrations avec changement de domaine, ajoutez une condition sur le nom d’hôte :

RewriteCond %{HTTP_HOST} ^ancien-domaine\.com$ [NC]
RewriteRule ^(.*)$ https://nouveau-domaine.fr/$1 [R=301,L]

Sur Nginx

Si votre serveur utilise Nginx (fréquent sur les hébergements VPS ou dédiés), les redirections se placent dans le bloc server :

location = /nos-services/creation-site {
    return 301 /services/creation-site-web;
}

Sur WordPress

Le plugin Redirection (gratuit) permet de gérer les 301 depuis l’interface d’administration. Il offre un suivi des erreurs 404 et un import CSV pour charger votre fichier de mapping en masse. Pour les sites à fort volume, le plugin Rank Math intègre aussi un gestionnaire de redirections performant.

En pratique, sur mes projets WordPress, je combine les deux approches : les redirections critiques (pages à fort trafic) vont dans le .htaccess pour la performance, et le reste passe par le plugin pour faciliter la maintenance par le client.

Sur Webflow

Webflow propose un gestionnaire de redirections 301 natif dans les paramètres du projet (section Hosting > 301 Redirects). L’import en masse est possible via un fichier CSV. Attention : Webflow limite à 500 redirections sur le plan de base.

La checklist du jour J : les 15 vérifications avant mise en ligne

Le moment de la bascule est critique. Voici la liste des vérifications à effectuer avant de pointer le DNS vers le nouveau site ou de remplacer les fichiers sur le serveur.

1. Tester chaque redirection du fichier de mapping sur l’environnement de recette (staging)
2. Vérifier les codes de réponse avec un outil comme HTTPstatus.io : chaque ancienne URL doit retourner un 301 pointant vers la bonne destination
3. Contrôler le sitemap.xml du nouveau site : il ne doit contenir que les nouvelles URL valides, aucune ancienne URL
4. Vérifier le fichier robots.txt : aucune directive Disallow ne doit bloquer le crawl des nouvelles pages
5. Tester le rendu mobile du nouveau site (Google indexe en mobile-first depuis 2021)
6. Vérifier les balises title et meta description de chaque page clé : elles ne doivent pas être vides ou dupliquées
7. Contrôler les balises canonical : chaque page doit pointer vers elle-même, pas vers l’ancienne URL
8. Vérifier les données structurées (schema.org) avec le test des résultats enrichis de Google
9. Tester la vitesse de chargement avec PageSpeed Insights : la refonte ne doit pas dégrader les Core Web Vitals
10. Contrôler le certificat SSL : toutes les pages doivent être servies en HTTPS sans mixed content
11. Vérifier le maillage interne : aucun lien interne ne doit pointer vers une ancienne URL
12. Tester les formulaires de contact et les pages de conversion
13. Vérifier le tracking Analytics : le code GA4 ou Matomo doit être présent sur toutes les pages
14. Contrôler les pages 404 : la page d’erreur personnalisée doit fonctionner
15. Préparer la soumission du nouveau sitemap dans la Search Console

Cette checklist peut sembler longue, mais chaque point négligé est une source potentielle de perte de trafic. En pratique, je bloque systématiquement une demi-journée uniquement pour ces vérifications avant chaque mise en production.

Suivi post-migration : surveiller et corriger pendant 8 semaines

La mise en ligne n’est pas la fin du processus. Les premières semaines après la migration sont décisives pour détecter et corriger les problèmes avant qu’ils n’impactent durablement le référencement.

Semaine 1 : surveillance intensive

Connectez-vous à la Search Console quotidiennement. Le rapport de couverture affiche les erreurs 404 détectées par Google sous 48 à 72 heures. Chaque 404 signalée correspond à une redirection manquante : ajoutez-la immédiatement à votre fichier de mapping et implémentez la 301.

Surveillez aussi les erreurs de redirection en chaîne (une 301 qui pointe vers une autre 301) et les boucles de redirection (A pointe vers B qui pointe vers A). Ces deux situations ralentissent le crawl et diluent le signal SEO.

Semaines 2 à 4 : analyser les tendances

Comparez le trafic organique semaine par semaine avec la même période de l’année précédente. Une baisse de 10 à 15 % est normale et temporaire. Au-delà de 20 %, cherchez les URL qui ont perdu leurs positions et vérifiez que leurs redirections fonctionnent.

Soumettez à nouveau le sitemap dans la Search Console si Google n’a pas encore indexé toutes les nouvelles URL. Utilisez l’outil d’inspection d’URL pour demander manuellement l’indexation des pages prioritaires.

Semaines 5 à 8 : consolidation

Le trafic doit progressivement revenir à son niveau d’avant la refonte. Si certaines pages restent en retrait, vérifiez :

• Que le contenu n’a pas été modifié de manière significative (un changement de contenu cumulé à un changement d’URL double le risque de perte de position)
• Que les backlinks externes pointent bien vers des URL redirigées et non vers des 404
• Que le temps de chargement du nouveau site n’est pas supérieur à celui de l’ancien

Pour gérer votre nom de domaine pendant cette phase, notamment si vous changez d’hébergeur, consultez mon guide sur le transfert de nom de domaine chez OVH ou celui sur la gestion de domaine OVHcloud.

Les erreurs qui ruinent une migration même bien préparée

Après avoir accompagné plusieurs dizaines de refontes depuis 2015, voici les erreurs que je vois revenir le plus souvent, y compris chez des prestataires expérimentés.

Rediriger tout vers la page d’accueil

C’est l’erreur la plus grave et la plus fréquente. Au lieu de créer des redirections unitaires URL par URL, certains mettent en place une règle globale qui redirige toutes les anciennes URL vers la page d’accueil. Google comprend rapidement que ces redirections ne sont pas pertinentes et les traite comme des soft 404. Résultat : aucun transfert d’autorité, perte totale du positionnement.

Oublier les URL avec des paramètres

Les URL avec des paramètres GET (?page=2, ?utm_source=newsletter, ?s=recherche) sont souvent indexées par Google. Si vous ne les redirigez pas, elles génèrent des 404 massives. Prévoyez des règles de redirection avec wildcards pour capturer ces variantes.

Supprimer les redirections trop tôt

Certains suppriment les redirections 301 après quelques mois en pensant que Google a « compris ». En réalité, Google recommande de maintenir les redirections indéfiniment, ou au minimum pendant un an. Les supprimer relance les erreurs 404 et la perte de trafic recommence.

Ne pas prévenir Google du changement

En cas de changement de domaine, la Search Console propose un outil spécifique : le changement d’adresse (dans les paramètres de la propriété). Ne pas l’utiliser ralentit significativement la prise en compte de la migration par Google. C’est un levier souvent oublié.

Modifier le contenu en même temps que les URL

Changer l’adresse d’une page et son contenu simultanément envoie un double signal négatif. Google doit réévaluer à la fois la pertinence de l’URL et la pertinence du contenu. Quand c’est possible, migrez d’abord la structure, puis modifiez le contenu quelques semaines plus tard.

Ignorer les images et les fichiers PDF

Les images apparaissent dans Google Images et génèrent parfois un trafic non négligeable. Les PDF indexés (plaquettes, catalogues, fiches techniques) aussi. Si vous changez le chemin de vos fichiers média, prévoyez des redirections pour ces ressources également.

Selon la CNIL et ses recommandations pour les sites web, une refonte est aussi le moment idéal pour mettre à jour votre politique de cookies et votre bandeau de consentement, deux éléments qui n’impactent pas le SEO mais qui sont obligatoires.

Si votre refonte inclut un changement d’hébergeur, comparez les offres de noms de domaine : j’ai analysé les options chez Ionos et chez Hostinger dans des articles dédiés.