Refonte sans perte de trafic

La refonte est l’une des causes les plus courantes de chute soudaine du trafic organique. Le site est superbe, l’équipe est satisfaite, puis un mois plus tard la GSC affiche une baisse de 40 %. La cause est presque toujours la même : des URL ont changé sans redirections, ou le moteur de recherche n’a pas réindexé la nouvelle structure. Voici un guide pas à pas pour refondre un site sans perte.

Pourquoi les refontes font chuter le trafic

Les moteurs de recherche indexent des URL précises. Si /blog/seo-guide/ existe depuis des années, Google a accumulé pour elle de la popularité transmise par les liens, de l’autorité et un historique de clics. Une refonte qui modifie la structure des URL revient à détruire tout cela : du point de vue du crawler, la page a simplement disparu.

zoom_in

Cinq causes de perte de trafic reviennent le plus souvent après une refonte :

Audit avant mise en ligne : ce qu’il faut relever

Avant de toucher au design, prévoyez au moins deux semaines d’audit. Vous devez enregistrer l’état actuel pour disposer d’une référence de comparaison après le lancement. Quatre outils essentiels :

Repérez les pages qui ont un trafic, des liens ou une valeur commerciale notables, afin de les traiter une à une dans la correspondance des pages. La priorité de la carte des redirections doit reposer sur les données propres au site concerné, et non sur une part de trafic générique.

Ce qu’il faut relever avant la refonte

Architecture des URL et carte des redirections

La structure des URL est la partie la plus délicate d’une refonte. Si la structure change (par exemple /services/seo/ devient /seo-services/), chaque ancienne URL doit recevoir une redirection 301 explicite. La carte des redirections est un tableau « ancienne URL → nouvelle URL » : elle se prépare avant le lancement, se vérifie à la main et se transmet au développeur.

Si une page n’est plus nécessaire et que son contenu n’est repris nulle part ailleurs, utilisez un 410 et non une 404. Le 410 signale à Google que la suppression est intentionnelle : le budget de crawl est alors mieux utilisé, car le crawler cesse plus vite de revenir sur l’URL disparue.

# Nginx: redirect a specific page
location = /old-services/ {
    return 301 /services/;
}

# Nginx: redirect an entire section
location /old-blog/ {
    rewrite ^/old-blog/(.*)$ /blog/$1 permanent;
}

# Test redirect with curl
curl -I https://example.com/old-url/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-url/

Testez chaque redirection avant le lancement, en particulier pour les pages qui ont du trafic, des liens ou des conversions. Une URL pertinente oubliée peut créer des erreurs évitables, pour les visiteurs comme pour les crawlers.

Configuration technique après le lancement

Les 48 à 72 premières heures après la mise en ligne du nouveau design sont critiques. Assurez-vous que le crawler voit exactement ce que vous avez prévu, et non une version de préproduction avec l’indexation désactivée.

1. Vérifiez le robots.txt : confirmez que la production n’est pas bloquée par la directive Disallow: /
2. Recréez le sitemap XML avec les nouvelles URL et soumettez-le dans la GSC, à la section Sitemaps
3. Demandez l’indexation des pages clés via GSC → Inspection de l’URL → Demander une indexation
4. Vérifiez les balises meta : title, description et canonical sur chaque page prioritaire
5. Parcourez la carte des redirections et testez chaque 301 avec curl ou l’onglet Réseau des DevTools
6. Mesurez les Core Web Vitals avec PageSpeed Insights pour les 20 pages les plus visitées

Vérifiez aussi les balises canonical. Lors d’un changement de CMS ou de thème, elles reviennent parfois à des chemins relatifs, ou disparaissent complètement. Le canonical doit contenir l’URL absolue du domaine de production : https://example.com/page/, et non /page/.

<!-- Correct canonical in <head> -->
<link rel="canonical" href="https://example.com/services/seo/">

<!-- Wrong — relative path (common CMS migration error) -->
<link rel="canonical" href="/services/seo/">

Suivi après le lancement

Une refonte n’est pas un événement, c’est un processus. Les trois premiers mois après le lancement sont une période d’instabilité, pendant laquelle Google réévalue le site. Votre rôle : surveiller les signaux et réagir rapidement.

Tableau de diagnostic : si un problème survient après le lancement, commencez par ici :