Refonte de site à Saint-Étienne : les 8 erreurs qui font perdre son trafic SEO

Pourquoi une refonte fait chuter le trafic SEO

Il y a une phrase qu'on entend au moins une fois par trimestre, souvent au téléphone, souvent avec une voix un peu tendue au bout du fil : « Le site est magnifique, mais on ne reçoit plus rien. » Et à chaque fois, le même enchaînement. Mise en ligne un jeudi. Satisfaction générale. Trois semaines plus tard, le formulaire de contact fait le mort.

Une refonte n'est pas un changement de décor. C'est un déménagement. Et comme dans tout déménagement, ce qui n'a pas été étiqueté avant le départ finit au fond d'un carton qu'on ne rouvrira jamais.

Ce que Google perd quand vous changez de site

L'ancien site, aussi daté soit-il visuellement, est un capital. Un vrai. Des URLs indexées depuis des années, un historique de confiance construit page par page, des liens externes qui pointent vers des adresses très précises, des signaux comportementaux accumulés au fil de milliers de visites.

Ce capital n'est pas attaché au domaine dans son ensemble. Il est attaché aux adresses. À chaque URL, individuellement.

Modifier une page, c'est remettre en jeu ce qu'elle avait gagné. La supprimer sans plan, c'est le jeter. Rien de dramatique quand ça concerne trois pages secondaires ; c'est une autre histoire quand la refonte touche l'intégralité de l'arborescence, ce qui est le cas neuf fois sur dix.

Le délai trompeur entre la mise en ligne et la chute

Voilà ce qui rend le sujet si vicieux. Google ne réagit pas le jour même. Le crawl du nouveau site prend du temps, la réindexation davantage encore, et la réévaluation des positions s'étale sur plusieurs semaines.

Résultat : pendant dix à quinze jours, tout va bien. Les chiffres tiennent. On se félicite. Puis la courbe se met à descendre, doucement d'abord, franchement ensuite. Et à ce moment-là, l'agence web a déjà été payée, l'équipe est passée à autre chose, et le lien de cause à effet n'est plus évident pour personne.

C'est bien le problème : la cause est en semaine 0, le symptôme en semaine 4. Entre les deux, la mémoire s'efface.

Le contexte stéphanois : un marché local où chaque position compte

Sur un bassin comme Saint-Étienne et le département de la Loire, les volumes de recherche sont ce qu'ils sont. Corrects, mais pas extensibles. Une requête comme « plombier Saint-Étienne » ou « expert-comptable Loire » génère un nombre fini de recherches mensuelles, et l'essentiel des clics se joue sur les trois ou quatre premiers résultats.

Perdre trois positions, dans ce contexte, ce n'est pas perdre quelques visites. C'est couper une source de prospects.

Un site national qui recule sur une requête compense ailleurs, sur le volume, sur la longue traîne, sur d'autres marchés. Une entreprise stéphanoise n'a pas ce matelas. Le champ est étroit, les concurrents locaux sont identifiés, et la place laissée vacante est reprise en quelques semaines. On l'a vu sur un artisan du secteur de Firminy : deux positions perdues sur sa requête principale, et le téléphone qui sonne deux fois moins. Pas de zone grise, pas de nuance. Juste moins d'appels.

Erreur n°1 : négliger le plan de redirections 301

Ce qui se passe concrètement

Les anciennes adresses ne répondent plus. Elles renvoient un 404, cette fameuse page « introuvable » que personne ne lit jamais.

Google passe, constate, repasse, constate encore, puis désindexe. Les liens externes accumulés au fil des années pointent désormais dans le vide : leur valeur ne se transmet plus nulle part. Et les visiteurs qui arrivaient par un ancien lien de blog ou un partage sur les réseaux tombent sur un mur.

Tout ça pour une ligne de configuration manquante.

Les cas oubliés systématiquement

Le plan de redirections existe presque toujours. C'est son périmètre qui pose problème. On redirige les huit pages du menu principal, on coche la case, on passe à la suite.

Ce qui reste sur le carreau, invariablement :

• Les anciens articles de blog, parfois publiés cinq ans plus tôt, souvent ceux qui captent le plus de trafic de longue traîne
• Les URLs contenant des paramètres, typiques des filtres et des recherches internes
• Les versions avec et sans www, ainsi que les vestiges en http qui traînent encore dans les liens entrants
• Les adresses terminant en .html, héritage des CMS de la génération précédente
• Les fiches produits retirées du catalogue
• Les catégories fusionnées ou renommées lors de la réorganisation
• Les URLs des images, qui génèrent parfois un trafic non négligeable via Google Images

Chacune de ces familles peut représenter des dizaines, voire des centaines d'adresses. Sur un site marchand un peu ancien, on dépasse facilement le millier.

La méthode : crawler AVANT de couper

Il n'existe pas de raccourci. Avant de toucher à quoi que ce soit, il faut sortir l'inventaire complet des URLs connues de Google, et le sortir de plusieurs sources parce qu'aucune n'est exhaustive à elle seule.

La Search Console donne les pages indexées et celles qui reçoivent des impressions. Un crawl complet du site révèle la structure réelle, y compris les pages qu'on avait oubliées. Les logs serveur, quand on y a accès, montrent ce que Googlebot visite vraiment — et il visite souvent des choses surprenantes. Le sitemap de l'ancien site complète le tableau.

On croise le tout, on dédoublonne, et on obtient une table de correspondance. Une ligne par ancienne URL, une destination décidée en face. Pas une case vide.

Ce document est fastidieux à produire. Sur un site de deux cents pages, comptez une bonne journée. C'est le meilleur investissement de tout le projet.

Les redirections en chaîne et les redirections « vers l'accueil »

Deux raccourcis tentants, deux mauvaises idées.

Le premier consiste à tout renvoyer vers la page d'accueil. C'est rapide, ça élimine les 404, et l'agence peut annoncer que « tout est redirigé ». Sauf que Google traite ces redirections massives vers l'accueil comme des soft 404 : il comprend parfaitement que la page demandée n'a rien à voir avec la destination, et il n'accorde aucun crédit au transfert. Le visiteur, lui, atterrit sur une page d'accueil sans rapport avec ce qu'il cherchait, et repart.

La redirection doit viser la page équivalente la plus proche. Une fiche produit supprimée renvoie vers sa catégorie. Un article de blog fusionné renvoie vers l'article qui l'a absorbé. Une page service renommée renvoie vers son remplaçant direct. Quand aucun équivalent n'existe vraiment, mieux vaut assumer un 410 propre qu'une redirection mensongère.

Le second raccourci, plus discret, c'est la chaîne. Une ancienne URL redirige vers une deuxième, qui redirige vers une troisième. Ça arrive tout seul quand le site a déjà connu une refonte par le passé et qu'on empile les règles sans nettoyer. Chaque saut dilue un peu le signal et ralentit le crawl. Deux sauts, ça passe. Quatre, ça devient un problème.

Erreur n°2 : réécrire les contenus « pour faire plus moderne »

Le texte raccourci au nom du design

Les maquettes actuelles sont aérées, épurées, respirantes. Beaucoup de blanc, de grandes images, des blocs courts. C'est joli. Et c'est un piège.

Parce que pour tenir dans la maquette, il faut couper. On demande alors au client de « résumer » sa page service. Le texte de 1 200 mots, construit au fil des années, enrichi à chaque question de prospect, tombe à 250 mots bien sentis.

Or ce texte, c'est exactement ce qui positionnait la page.

Ce n'est pas une question de quantité pour la quantité. C'est que ces 1 200 mots contenaient des dizaines de formulations différentes, des questions traitées, des précisions techniques, des variantes de vocabulaire. Autant de portes d'entrée qui viennent de se refermer d'un coup.

Les champs sémantiques abandonnés sans le savoir

Le plus frustrant ? Personne ne l'a fait exprès. En reformulant pour « moderniser le ton », on supprime des expressions qui généraient du trafic sans que quiconque les ait jamais identifiées comme stratégiques.

Un exemple typique : une page de dépannage mentionnait « fuite sous évier » dans un paragraphe technique. Personne n'y prêtait attention. Elle générait pourtant une trentaine de visites qualifiées par mois. La reformulation a transformé ça en « interventions de plomberie sanitaire ». Techniquement plus élégant. Commercialement, un désastre.

La parade est simple et coûte une heure. Avant la refonte, on ouvre la Search Console, on exporte les requêtes qui génèrent des impressions et des clics, page par page. On obtient une liste des expressions réellement porteuses. On la remet au rédacteur avec une consigne claire : ces formulations restent, quelle que soit la réécriture.

Les mentions locales effacées

Cas de figure archi-fréquent, et particulièrement pénalisant sur notre territoire.

L'ancien site disait : « Nous intervenons à Saint-Étienne, Firminy, Saint-Chamond, Roanne, Montbrison et dans toute la Loire. » Le nouveau dit : « Une expertise de proximité au service de votre projet. »

C'est mieux écrit, sans doute. Sauf que « expertise de proximité », personne ne le tape dans Google. Alors que « serrurier Saint-Chamond », si.

Les noms de communes disparaissent au profit de formulations génériques, et le site sort mécaniquement des requêtes géolocalisées. Sur un marché local, c'est presque toujours l'erreur la plus coûteuse des deux ou trois premiers mois.

Erreur n°3 : casser la structure des titres et des balises

Les title et meta descriptions régénérés automatiquement

Les balises title, celles qui s'affichent en bleu dans les résultats de recherche, sont probablement l'élément SEO au meilleur rapport effort/résultat. Elles sont aussi les plus faciles à perdre.

Lors d'une migration de CMS, le thème reconstruit les titles par défaut. Le plus souvent à partir du nom de la page, avec le nom du site accolé derrière. Un title patiemment travaillé du type « Plombier chauffagiste à Saint-Étienne | Dépannage 7j/7 » devient « Services - Mon Entreprise ».

Et ça se produit pour l'ensemble des pages, en une seule mise en ligne. Le travail de plusieurs années, écrasé en une commande.

Le H1 remplacé par une image ou un slogan

Le nouveau design place en haut de page une grande bannière avec une accroche marketing en surimpression. Parfois même une image contenant du texte, ce qui est encore pire.

Le H1, qui portait le mot-clé principal, se retrouve remplacé par « Votre partenaire de confiance depuis 1998 ». Charmant. Mais qui cherche « partenaire de confiance depuis 1998 » ?

Le H1 n'est pas un slogan. C'est l'annonce du sujet de la page, à destination du moteur autant que du lecteur. On peut parfaitement avoir un beau visuel et un H1 pertinent : ce sont deux choses qui coexistent sans difficulté, à condition d'en avoir parlé avant.

La hiérarchie Hn désorganisée par le thème

Les thèmes et les constructeurs de pages ont une fâcheuse habitude : ils choisissent les balises de titre pour des raisons de taille de police, pas de sens.

On se retrouve alors avec des H3 dans le pied de page pour les coordonnées, des H2 sur des éléments de navigation, trois H1 sur une même page parce que le carrousel en génère un par diapositive. La hiérarchie sémantique, qui devrait raconter le plan de la page, devient illisible.

Un audit rapide des Hn après mise en ligne prend vingt minutes. Il révèle presque toujours quelque chose.

Erreur n°4 : perdre le maillage interne dans la nouvelle arborescence

Les liens contextuels qui disparaissent avec les anciens contenus

Le maillage interne, c'est la circulation sanguine du site. Il distribue la popularité entre les pages, indique les priorités, et guide le visiteur d'un contenu vers le suivant.

Les liens les plus utiles sont ceux intégrés dans le texte, au fil de la lecture. Un article qui renvoie vers une page service. Une page service qui renvoie vers une réalisation. Ces liens-là ont un contexte, une ancre pertinente, une valeur réelle.

Quand on raccourcit les contenus (voir l'erreur n°2), on les emporte au passage. Sans même s'en rendre compte, puisqu'ils étaient dans les paragraphes supprimés. Les pages profondes se retrouvent alors isolées, alimentées par le seul menu, et perdent progressivement leur position.

Le méga-menu qui remplace la structure en silos

Réflexe fréquent : « On va mettre toutes les pages dans un grand menu déroulant, comme ça tout est accessible en un clic. »

L'intention est bonne. Le résultat, discutable.

Un menu qui affiche soixante liens sur toutes les pages du site envoie un signal très plat : tout se vaut, rien n'est prioritaire. Alors qu'un lien contextuel placé dans un paragraphe, avec une ancre qui décrit précisément la destination, porte une information autrement plus riche.

Sans compter la dilution mécanique. Chaque page dispose d'une popularité qu'elle redistribue à travers ses liens sortants. Soixante liens dans le menu, c'est soixante parts. Le méga-menu ne remplace pas une architecture en silos : il la remplace mal.

Les pages orphelines créées par la refonte

Une page orpheline, c'est une page qui existe, qui est parfois même dans le sitemap, mais vers laquelle aucun lien interne ne pointe. Personne ne peut y accéder en naviguant. Googlebot non plus, sauf à passer par le sitemap.

Ces pages apparaissent naturellement lors d'une refonte : la page existait, elle a été migrée, mais le lien qui y menait était dans un bloc supprimé ou une rubrique fusionnée.

La détection est mécanique : un crawl complet avant, un crawl complet après, et on compare. Les pages présentes au sitemap mais absentes du crawl sont vos orphelines. Il ne reste qu'à décider, pour chacune, si on la relie ou si on l'assume comme supprimée.

Erreur n°5 : oublier de retirer le blocage d'indexation de la préproduction

Le noindex et le robots.txt du site de recette

Celle-ci, c'est la plus bête. Et pourtant elle arrive tous les mois, chez des prestataires sérieux, sur des projets bien menés.

Pendant le développement, le site de recette est protégé de l'indexation. Logique : on ne veut pas que Google découvre une version en chantier. On pose donc une balise meta robots en noindex, ou un Disallow: / dans le fichier robots.txt.

Et le jour de la mise en ligne, dans le rush, personne ne la retire.

Le résultat est brutal. Google repasse, lit l'instruction, et commence à désindexer. En quinze jours, un site qui recevait deux mille visites mensuelles peut se retrouver à zéro. Littéralement absent des résultats sur son propre nom.

Le pire, c'est la remontée. Elle n'est ni immédiate ni automatique. Il faut redemander l'indexation page par page, et Google prend son temps avant de rendre à un site la confiance qu'il lui avait accordée.

Le mot de passe HTTP resté actif

Variante moins spectaculaire, tout aussi efficace. Une protection par mot de passe configurée au niveau du serveur, souvent via un fichier .htaccess, laissée en place sur une portion du site : un répertoire, une rubrique, le blog.

Le visiteur ne s'en aperçoit pas forcément s'il n'y va jamais. Googlebot, lui, reçoit un code 401 et s'en va.

Le contrôle à faire dans l'heure qui suit la mise en ligne

Une refonte se contrôle immédiatement, pas le lendemain. Voici ce qui se vérifie dans l'heure :

• Le fichier robots.txt, en le chargeant directement dans le navigateur, et en lisant chaque ligne
• La balise meta robots, dans le code source, sur la page d'accueil et sur au moins trois types de pages différents
• Les en-têtes HTTP, à la recherche d'un X-Robots-Tag oublié — il est invisible dans le code source, ce qui le rend redoutable
• L'inspection d'URL dans la Search Console, qui donne le verdict de Google lui-même
• Un test sur plusieurs gabarits : accueil, page service, article de blog, page de contact. Les blocages sont parfois partiels

Quinze minutes de vérification contre plusieurs mois de reconstruction. Le calcul est vite fait.

Erreur n°6 : dégrader les performances techniques et l'expérience mobile

Le poids des pages qui explose

L'ancien site était moche mais léger. Le nouveau est superbe et pèse huit mégaoctets.

Les coupables sont toujours les mêmes : vidéo en arrière-plan de la bannière, animations au défilement, quatre familles de polices chargées depuis un service externe, carrousel d'images en pleine résolution parce que « ça sera plus net », bibliothèques JavaScript empilées par le constructeur de pages.

Google mesure ces éléments à travers les Core Web Vitals, et ils entrent dans son évaluation. Mais l'impact le plus direct est ailleurs, et il n'a rien d'algorithmique : un visiteur sur mobile, en 4G, dans une rue de Saint-Étienne, attend six secondes et repart. La page ne s'est jamais affichée. Aucun classement n'y résistera.

Le mobile traité après le desktop

Le processus classique : on conçoit la maquette sur grand écran, on la valide sur grand écran, puis on « adapte » pour mobile en fin de projet. Souvent en masquant des blocs pour que ça tienne.

Or Google fonctionne en indexation mobile-first depuis des années. C'est la version mobile qu'il explore, qu'il analyse et qu'il classe.

Un site dont le contenu mobile est amputé de moitié n'est pas évalué sur sa belle version desktop. Il est évalué sur la version tronquée. Les textes cachés derrière des accordéons, les blocs supprimés en responsive, les tableaux illisibles : tout cela compte, et pas dans le bon sens.

Les données structurées perdues dans la migration

Le balisage structuré est le grand oublié des refontes. Il ne se voit pas, il n'est dans aucune maquette, personne ne le réclame en réunion.

Et pourtant : le balisage LocalBusiness avec l'adresse et les horaires, les avis clients affichés en étoiles, les blocs FAQ dépliables directement dans les résultats, les fils d'Ariane qui remplacent l'URL sous le titre. Autant d'éléments qui prennent de la place dans la page de résultats et attirent le clic.

Ils disparaissent, l'affichage redevient une ligne bleue banale, et le taux de clic baisse à position identique. Pour une entreprise locale, la perte du balisage LocalBusiness est particulièrement dommageable : c'est un des signaux qui relient le site à son territoire.

Erreur n°7 : laisser tomber le référencement local pendant la refonte

Le NAP modifié sans mise à jour des citations

NAP, pour Name, Address, Phone. Le trio d'identité de l'entreprise.

Google recoupe ces informations entre le site, la fiche Google Business Profile et les annuaires professionnels. Quand tout concorde exactement, la confiance monte. Quand ça diverge, elle baisse.

Et une refonte crée des divergences sans le vouloir. L'adresse passe de « 12 rue de la République, 42000 Saint-Étienne » à « 12 r. de la République - St-Étienne ». Le téléphone perd ses espaces, ou les gagne. Le nom commercial est « simplifié » dans le pied de page.

Chaque écart affaiblit un peu le signal. Le nouveau site doit reprendre la formulation exacte de la fiche Google, au caractère près. Et si l'on souhaite modifier la présentation, alors on la modifie partout en même temps : fiche, annuaires, réseaux sociaux, signatures de mail.

Les pages « zones d'intervention » supprimées

Ces pages ont mauvaise réputation. Elles sont souvent courtes, parfois répétitives, et un regard extérieur les qualifie volontiers de « pages pauvres » à supprimer.

Erreur de jugement dans la majorité des cas. Ces pages captent des requêtes à très forte intention commerciale : quelqu'un qui cherche « électricien Montbrison » a un besoin, une localisation, et souvent une urgence. Il ne fait pas de la veille documentaire.

Le bon réflexe n'est pas de les supprimer, c'est de les enrichir : contenu propre à chaque commune, réalisations locales, spécificités du secteur, témoignages du coin. Une page ville qui parle vraiment de la ville n'a rien de pauvre.

Et si la décision de supprimer est prise malgré tout, elle se prend en connaissance de cause, chiffres de trafic à l'appui. Pas par principe esthétique.

La fiche établissement qui pointe vers une URL morte

Détail à trente secondes, conséquences à plusieurs semaines.

La fiche Google Business Profile contient un lien vers le site. Idem pour les annuaires locaux, les pages Pages Jaunes, les fédérations professionnelles, les partenaires. Si l'arborescence a changé, ces liens pointent dans le vide.

Un utilisateur qui clique depuis la fiche Google et tombe sur une erreur, c'est un prospect perdu — et un signal négatif envoyé au passage. La mise à jour se fait le jour même, dans la foulée de la mise en ligne. Pas « quand on aura le temps ».

Erreur n°8 : ne rien mesurer avant, et découvrir la chute trop tard

L'absence de point zéro

Comment savoir ce qu'on a perdu si l'on ne sait pas ce qu'on avait ?

C'est la question qui met fin à beaucoup de réunions de crise. Le trafic a baissé, d'accord. Sur quelles pages ? Sur quelles requêtes ? Depuis quelle date exactement ? Silence.

Sans photographie de l'état initial, le diagnostic devient de la spéculation. On répare au hasard, on teste des hypothèses, on perd des semaines.

Le point zéro se constitue en une demi-journée, quelques jours avant la bascule : positions sur les requêtes stratégiques, trafic organique par page sur douze mois, principales pages d'entrée, requêtes générant des impressions, taux de conversion par source. Un dossier, une date, et c'est archivé.

Ce dossier ne servira peut-être jamais. Le jour où il sert, il vaut de l'or.

Le suivi analytics cassé à la mise en ligne

Autre grand classique, et il fonctionne dans les deux sens.

Le code de mesure n'a pas été reporté sur le nouveau site, ou seulement sur certains gabarits. Une nouvelle propriété a été créée, vierge, sans historique de comparaison. Les objectifs de conversion n'ont pas été reconfigurés, et le formulaire de contact ne déclenche plus rien.

On croit alors à un effondrement du trafic, alors que c'est le compteur qui est muet. Panique injustifiée, quelques nuits blanches.

Ou l'inverse, plus pervers : le suivi fonctionne mais compte mal, les chiffres semblent corrects, et la vraie baisse passe inaperçue pendant deux mois.

La fenêtre de correction de quatre à six semaines

Il existe un délai, et il est assez net.

Une perte détectée dans le mois qui suit se rattrape généralement bien. Les redirections sont posées, l'indexation se rétablit, les contenus sont restaurés, et les positions reviennent en quelques semaines. Google n'a pas eu le temps d'entériner la nouvelle situation.

Passé quatre à six mois, la logique change. Les concurrents ont pris la place. Les liens externes pointant vers les anciennes URLs ont été traités comme morts. La confiance accumulée s'est dissipée. On ne répare plus : on reconstruit, et ça prend beaucoup plus de temps qu'un plan de redirections fait à temps.

La méthode : sécuriser une refonte de site en trois temps

Avant : l'audit de l'existant

Tout se joue ici. Une refonte sécurisée coûte quelques jours de travail préalable ; une refonte ratée coûte un semestre de visibilité.

Le travail préparatoire comprend un crawl complet du site en place, l'export des positions sur l'ensemble des requêtes suivies, et l'identification des vingt pages qui produisent l'essentiel du trafic. Cette dernière étape est déterminante : dans la plupart des cas, une poignée d'URLs concentre l'écrasante majorité des visites organiques. Ce sont celles-là qu'on protège en priorité, quitte à faire des concessions ailleurs.

S'y ajoutent la cartographie des liens externes entrants avec leurs pages cibles, et le relevé complet des balises title, meta descriptions, Hn et données structurées existantes.

Pendant : les arbitrages à ne pas déléguer au graphiste

Le graphiste fait un travail de graphiste, et il le fait souvent très bien. Mais certaines décisions n'entrent pas dans son périmètre, et les lui laisser par défaut, c'est prendre un risque.

Quatre sujets doivent être arbitrés conjointement, avec quelqu'un qui connaît le référencement du site :

• Le plan de redirections, validé ligne par ligne avant la bascule
• La conservation des contenus performants, sur la base des chiffres et non des impressions esthétiques
• La structure des titres, définie gabarit par gabarit
• L'arborescence, et notamment la profondeur des pages stratégiques

Le mot important est conjointement. Ces décisions se prennent en amont, autour d'une table, pas à la livraison quand tout est développé et que revenir en arrière coûte un budget supplémentaire.

Après : les 30 premiers jours de surveillance

La mise en ligne n'est pas la fin du projet. C'est le début de la période sensible.

Semaine 1. Contrôle quotidien. Indexation via la Search Console, erreurs 404 dans les logs, fonctionnement effectif des redirections sur un échantillon d'anciennes URLs, présence du code analytics, absence de blocage. C'est la semaine où les erreurs grossières se corrigent avant qu'elles ne coûtent quoi que ce soit.

Semaine 2. Le crawl de Google monte en puissance et révèle des choses qu'on n'avait pas vues. On surveille les nouvelles 404 remontées, la courbe des pages indexées, et les premiers mouvements de position. Une baisse légère à ce stade est normale : le site est en cours de réévaluation.

Semaines 3 et 4. Les tendances se dessinent. On compare les positions au point zéro, requête par requête. On regarde le trafic organique page par page pour repérer les pertes localisées, que la moyenne globale a tendance à masquer. Et on contrôle les Core Web Vitals sur données réelles, qui commencent à être disponibles.

À un mois, on sait. Soit la migration est propre et le trafic est revenu à son niveau, voire au-dessus. Soit il reste des points à corriger, et on est encore largement dans la fenêtre où ça se rattrape.

Faire auditer sa refonte avant qu'il ne soit trop tard

Une refonte n'est pas un projet de design auquel on ajoute une couche SEO en fin de parcours. C'est un projet de migration, avec sa logique propre, ses points de contrôle et ses irréversibilités.

Le design compte, évidemment. Un site daté nuit à la crédibilité, et personne ne défendra le contraire. Mais un site magnifique que personne ne trouve reste un site que personne ne trouve. Les deux objectifs ne s'opposent pas : ils se traitent en parallèle, dès la première réunion de cadrage.

Chez FDSEO, nous accompagnons les entreprises de Saint-Étienne et de la Loire sur ces migrations, en amont avec les équipes techniques ou en réparation quand la chute est déjà là. Les deux situations se traitent, mais la première coûte nettement moins cher que la seconde.

Votre refonte est encore à l'état de maquette ? C'est le moment idéal pour un audit préalable : on identifie ce qui doit être protégé, on construit le plan de redirections, et on sécurise la bascule.

Elle est déjà en ligne et les chiffres ont décroché ? Alors il y a urgence, mais pas fatalité. Contactez-nous pour un audit de refonte : diagnostic de ce qui a été perdu, plan de correction hiérarchisé, et suivi jusqu'au retour à la normale.