- Pourquoi tant de refontes font chuter le trafic
- Avant : l'audit de l'existant, ce qu'il faut sauver
- Le plan de redirections 301 : la pièce maîtresse
- Pendant : conserver ce qui fonctionne
- La recette SEO avant mise en ligne (checklist)
- Le jour J : la bascule
- Après : 90 jours de surveillance
- Les 7 erreurs qui coûtent le plus cher
- Cas particulier : quitter Wix, Jimdo ou un site codé en dur
- Combien coûte une refonte sans perte SEO ?
- Questions fréquentes
Une refonte réussie, c'est un site plus beau, plus rapide, plus efficace commercialement, et un référencement au moins égal à l'ancien. La plupart des prestataires s'arrêtent aux trois premiers points. Résultat : des sites magnifiques qui ont perdu 60 % de leur trafic parce que personne n'a pensé aux 400 URL qui existaient avant.
Ce guide est écrit pour les dirigeants de PME, artisans et responsables de collectivités qui préparent une refonte — pour savoir ce qu'il faut exiger du prestataire. Et pour les confrères qui voudraient une checklist.
Pourquoi tant de refontes font chuter le trafic
Google ne « connaît » pas votre entreprise. Il connaît des URL, le contenu qui s'y trouve, les liens qui pointent vers elles et l'historique de tout ça. Quand vous refaites votre site, vous touchez potentiellement aux quatre à la fois. Les mécanismes de chute, par ordre de fréquence :
- Les URL changent sans redirection. La page
/nos-prestations/plomberiequi rankait depuis 2017 devient/services/plomberie-chauffage. Pour Google, l'ancienne a disparu (404) et la nouvelle est une inconnue. Dix ans d'historique et tous les liens entrants : perdus. - Des pages sont supprimées parce qu'« elles ne servaient à rien » — alors qu'elles généraient 30 % du trafic sur des requêtes de longue traîne. Le blog est la victime classique.
- Les contenus sont raccourcis. Le nouveau design est épuré, donc on coupe les textes. Google avait classé la page sur 800 mots ; il en reste 120.
- Les balises changent. Titres, H1, méta-descriptions réécrits par le designer ou laissés par défaut (« Accueil – Mon site »).
- Le noindex de la préproduction part en production. Le site de développement était caché des moteurs, personne ne retire la case au moment de la mise en ligne. Le site entier disparaît de Google en deux semaines. Je le vois tous les ans.
- La performance se dégrade : nouveau thème lourd, constructeur de pages, images non optimisées. Un site plus lent, c'est un signal négatif en plus.
- Les données structurées et le maillage interne disparaissent avec l'ancien thème.
Avant : l'audit de l'existant, ce qu'il faut sauver
On ne refait pas un site sans savoir ce qu'il vaut. Avant la première maquette, je constitue un inventaire complet de l'existant :
- Crawl complet du site actuel (Screaming Frog) : toutes les URL, leurs titres, H1, méta-descriptions, canoniques, données structurées, images et leurs attributs alt.
- Export Search Console sur 16 mois : quelles pages reçoivent des impressions et des clics, sur quelles requêtes. C'est la liste des pages qu'on n'a pas le droit de perdre.
- Export Google Analytics : pages d'entrée, conversions, pages qui mènent au formulaire de contact.
- Liens entrants (rapport Liens de la Search Console, Ahrefs ou Semrush si disponible) : les pages qui reçoivent des liens externes ont une valeur que le reste du site n'a pas.
- Positions sur les mots-clés cibles, relevées avant travaux pour pouvoir comparer après.
- Accès : Search Console, Analytics, hébergeur, registrar. Étonnamment souvent, personne ne sait qui les détient.
Le livrable est un tableau, URL par URL, avec cinq colonnes : trafic, liens entrants, mots-clés, décision (conserver / fusionner / supprimer) et nouvelle URL. C'est ce tableau qui pilote toute la suite. Sans lui, on navigue à vue.
Une page qui reçoit du trafic ou des liens n'est jamais inutile, même si son contenu vous semble daté. On la conserve, on la met à jour, ou on la fusionne avec une page proche en redirigeant. On ne la supprime que si elle n'a ni trafic, ni liens, ni rôle dans le parcours — et dans ce cas on la redirige quand même vers la page thématiquement la plus proche.
Le plan de redirections 301 : la pièce maîtresse
La redirection 301 dit à Google : « cette page a déménagé définitivement ici, transférez-lui tout ce que vous saviez de l'ancienne ». C'est le mécanisme qui préserve l'historique. Les règles que j'applique :
- Une pour une. Chaque ancienne URL vers son équivalent exact. Jamais toutes vers la page d'accueil : Google traite ça comme une erreur 404 déguisée (soft 404) et le bénéfice est nul.
- Préparé avant, pas après. Le plan de redirections est écrit pendant la conception de l'arborescence, pas la veille de la mise en ligne.
- Sans chaînes. Si l'ancien site redirigeait déjà
/avers/b, le nouveau plan envoie/adirectement vers la destination finale. Chaque saut dilue un peu et ralentit. - Les images aussi, quand elles apportent du trafic via Google Images, et les PDF.
- Testé en liste : on fait crawler le fichier des anciennes URL sur le nouveau site, et chacune doit répondre 301 vers une page en 200. Pas une seule 404.
- Conservé au moins un an, et en pratique indéfiniment : des liens externes pointeront vers les anciennes URL pendant des années.
Techniquement, les redirections se posent dans le fichier .htaccess (Apache) ou la configuration Nginx, ou via le plugin Redirection sur WordPress pour que le client puisse les gérer ensuite. Sur quelques dizaines d'URL, c'est manuel ; au-delà, on génère les règles depuis le tableau d'audit.
Pendant : conserver ce qui fonctionne
Refonte ne veut pas dire table rase. Pendant la construction du nouveau site :
- L'arborescence reste proche de l'ancienne quand elle était logique. On améliore, on ne bouleverse pas.
- Titres et H1 des pages qui rankent sont repris, à l'identique ou en les améliorant avec précaution. Le designer n'a pas la main dessus.
- Les contenus sont conservés ou enrichis, jamais amputés. Un design épuré se construit en organisant le texte (onglets, accordéons, sections), pas en le supprimant.
- Le maillage interne est reconstruit au moins à l'équivalent : menus, pieds de page, liens contextuels.
- Les données structurées (LocalBusiness, FAQ, fil d'Ariane, Article) sont réimplémentées dans le nouveau thème.
- Les images gardent leurs attributs alt et, idéalement, leurs noms de fichiers.
- La performance est un objectif chiffré dès la conception : le nouveau site doit être plus rapide que l'ancien, pas l'inverse.
La recette SEO avant mise en ligne (checklist)
Le site est terminé sur l'environnement de préproduction. Avant de basculer, je passe cette liste point par point :
- ☐ Case « Demander aux moteurs de ne pas indexer » décochée dans Réglages → Lecture, et balise
noindexabsente du code. - ☐
robots.txtpropre, sansDisallow: /hérité de la préproduction. - ☐ Balises canoniques pointant vers le domaine définitif, pas vers l'adresse de préproduction.
- ☐ Plan de redirections testé : 100 % des anciennes URL en 301 vers une page en 200.
- ☐ Titres, méta-descriptions et H1 uniques sur toutes les pages, conformes au tableau d'audit.
- ☐ Sitemap XML généré, cohérent avec les URL finales.
- ☐ Page 404 personnalisée avec navigation vers les pages principales.
- ☐ Données structurées validées dans le test des résultats enrichis.
- ☐ Scores de performance mobile supérieurs ou égaux à ceux de l'ancien site.
- ☐ Crawl complet de la préproduction : aucun lien interne cassé, aucune image manquante.
- ☐ Analytics, Tag Manager et vérification Search Console réinstallés.
- ☐ Formulaires testés de bout en bout, avec réception de l'e-mail.
- ☐ HTTPS forcé, version avec et sans www unifiée.
- ☐ Sauvegarde complète de l'ancien site, conservée hors ligne.
Le jour J : la bascule
Jamais un vendredi soir, jamais à la veille d'un pic d'activité. Un mardi ou mercredi matin, pour avoir la semaine devant soi. Dans l'heure qui suit la mise en ligne :
- Vérification manuelle des dix pages les plus importantes, sur mobile et ordinateur.
- Crawl complet du site en production : codes de réponse, titres, noindex.
- Nouveau crawl de la liste des anciennes URL : toutes en 301.
- Soumission du sitemap dans la Search Console, et demande d'indexation des pages principales.
- Si le domaine change : outil de changement d'adresse de la Search Console.
- Mise en place d'une surveillance des erreurs 404 pour attraper ce qui aurait échappé au plan.
Après : 90 jours de surveillance
La refonte n'est pas terminée à la mise en ligne. Pendant trois mois :
- Semaine 1 : contrôle quotidien de la Search Console (couverture, erreurs 404, problèmes d'ergonomie mobile). Correction immédiate des 404 détectées.
- Semaines 2 à 6 : suivi hebdomadaire des positions et du trafic par rapport à la même période de l'année précédente. Des fluctuations de 10 à 15 % sont normales pendant que Google recalcule.
- Mois 2 et 3 : stabilisation. Si une page a décroché, on compare l'ancienne et la nouvelle version (contenu, balises, liens internes) et on corrige.
- Mois 3 : bilan chiffré, et on commence à récolter les bénéfices d'un site plus rapide et mieux structuré.
Les 7 erreurs qui coûtent le plus cher
- Le noindex oublié en production. La plus bête, la plus fréquente, la plus dévastatrice.
- Toutes les anciennes URL redirigées vers l'accueil. Autant ne rien faire.
- Tout changer en même temps : design, CMS, nom de domaine, hébergeur, arborescence. En cas de baisse, impossible de savoir d'où ça vient.
- Supprimer le blog ou les « vieilles » pages sans regarder leur trafic.
- Laisser le designer écrire les titres. « Bienvenue » n'est pas un titre de page.
- Ne pas demander les accès Search Console avant de commencer — et découvrir après coup qu'on ne peut rien mesurer.
- Livrer un site plus lent que l'ancien parce que personne n'avait posé la performance comme objectif.
Cas particulier : quitter Wix, Jimdo ou un site codé en dur
Beaucoup de refontes que je réalise sont des migrations depuis Wix, Jimdo, Squarespace ou un ancien site en HTML pur vers WordPress. La logique est identique, avec quelques spécificités :
- Sur Wix et consorts, vous n'avez pas accès au serveur. Si vous conservez votre nom de domaine, les redirections depuis les anciennes URL se posent… sur le nouveau site, puisque le domaine y pointe désormais. Il faut donc exporter la liste complète des URL Wix avant de résilier.
- Les URL Wix ont souvent des structures étranges (
/copie-de-services,/blank-1). C'est l'occasion de les normaliser, en redirigeant proprement. - Un site codé en dur depuis dix ans a souvent un référencement solide sur des URL en
.html. On les conserve ou on les redirige une à une ; on ne repart jamais de zéro. - Les contenus se récupèrent (export, copie structurée, ou extraction automatisée) : on ne réécrit pas 80 pages qui rankent.
Combien coûte une refonte sans perte SEO ?
La partie « sans perte SEO » représente en général 15 à 25 % du budget d'une refonte : audit de l'existant, plan de redirections, recette, suivi. C'est le meilleur investissement du projet, parce que c'est lui qui protège les autres 75 %. Mes repères :
| Prestation | Tarif indicatif HT |
|---|---|
| Refonte design d'un site WordPress existant, avec audit SEO préalable, plan de redirections et recette | À partir de 3 500 € |
| Refonte technique complète avec migration et restructuration | 5 500 à 12 000 € |
| Migration depuis Wix, Jimdo, Squarespace ou un site codé en dur vers WordPress | 5 000 à 10 000 € |
| Suivi post-migration 90 jours (Search Console, positions, corrections) | Inclus |
| Audit de récupération après une refonte ratée par un autre prestataire | À partir de 500 € |
Le détail de l'offre et la méthode sont sur la page refonte de site WordPress, et les fourchettes du marché dans mon article sur le prix d'un site WordPress en 2026.
Envoyez-moi l'adresse de votre site actuel et ce que vous attendez du nouveau. Je vous renvoie un premier audit de l'existant (ce qu'il faut absolument conserver) et un devis détaillé sous 48 h. Si votre trafic a déjà chuté après une refonte, même chose : on regarde ce qui est récupérable.
Questions fréquentes
Combien de temps Google met-il à prendre en compte une refonte ?
Les premières fluctuations apparaissent dans les jours qui suivent la bascule, le temps que Google recrawle le site. Si les redirections sont en place et le contenu conservé, la situation se stabilise en 4 à 8 semaines, et les gains liés à un site plus rapide et mieux structuré se voient à 2-3 mois. Une baisse de 10 à 15 % pendant quelques semaines est normale ; une baisse de 50 % qui dure est le signe d'un problème à corriger vite.
Faut-il absolument garder les anciennes URL ?
Non, mais chaque URL qui change doit être redirigée en 301 vers son équivalent exact sur le nouveau site. Garder les URL quand elles sont correctes évite tout risque ; les changer est légitime quand elles sont mal construites (identifiants numériques, paramètres, accents), à condition de le faire proprement et une seule fois.
Puis-je changer de nom de domaine en même temps que la refonte ?
C'est possible, mais c'est cumuler deux migrations risquées en une. Si vous le pouvez, décalez : refonte d'abord, changement de domaine six mois plus tard (ou l'inverse), pour pouvoir attribuer une éventuelle baisse à sa cause. Si vous devez tout faire en même temps, le plan de redirections doit être irréprochable et l'outil de changement d'adresse de la Search Console utilisé.
Mon trafic a chuté après une refonte faite par un autre prestataire. Est-ce rattrapable ?
Dans la plupart des cas, oui, et plus on agit vite, plus la récupération est rapide. Le diagnostic consiste à comparer l'ancien site (via la Wayback Machine et l'export Search Console) au nouveau : URL en 404, contenus supprimés, balises modifiées, noindex oublié, performance dégradée. Une fois les causes corrigées et les redirections mises en place, Google réattribue progressivement les positions. C'est une prestation que je réalise régulièrement.