Refonte site web SEO Suisse :
méthode

Décider ce que la refonte doit résoudre

Une refonte de site web doit résoudre des problèmes identifiés sans effacer les contenus et les parcours qui fonctionnent déjà. Pour une entreprise suisse, le premier livrable utile est une liste de décisions : ce qui reste, ce qui change, pourquoi cela change et comment vérifier le résultat. Cette préparation concerne les pages, les formulaires, les langues, les médias et les accès. Une nouvelle interface ne suffit pas à démontrer que le site répond mieux aux besoins commerciaux.

Commencez par décrire les difficultés observées avec leurs preuves. Un formulaire qui n’envoie pas de message, une page de prestation devenue inexacte et une navigation qui ne permet pas de trouver les zones desservies appellent des corrections différentes. Évitez de les réunir sous « site dépassé ». Le choix entre une amélioration ciblée et une refonte plus large dépend de leur étendue, des composants concernés et de la capacité à intervenir sans multiplier les régressions.

Le périmètre doit aussi préciser les changements exclus. Un projet d’amélioration de la prise de contact n’autorise pas automatiquement une nouvelle identité graphique, le remplacement des textes juridiques ou une modification du domaine. Listez les éléments protégés avec leur responsable. Les équipes pourront alors proposer une solution en connaissant les contraintes, au lieu de faire approuver tardivement des changements qui n’étaient pas compris dans la demande initiale.

Si le problème principal concerne les adresses des pages ou le passage vers un autre domaine, le guide de migration SEO traite cette opération plus précisément. Cette page porte sur la conduite d’une refonte : transformer un besoin métier en version testable, préserver les actifs utiles et décider d’une mise en ligne sur preuves. Elle ne promet pas l’absence de fluctuations dans Google ni une progression commerciale automatique après le lancement.

Inventorier les pages et les parcours existants

L’inventaire doit dépasser les pages visibles dans le menu. Croisez les adresses du sitemap, les pages découvertes par exploration, les données de Search Console et les entrées connues des équipes. Des ressources anciennes peuvent encore recevoir des visiteurs ou servir à un commercial. Les fichiers téléchargeables, pages de confirmation et versions linguistiques doivent aussi être examinés. Leur absence de navigation ne prouve pas qu’ils sont inutiles ou qu’ils peuvent disparaître sans conséquence.

Pour chaque adresse, relevez son rôle, son contenu principal, son état technique et les actions proposées. Associez les données disponibles à une période précise. Une page sans clic dans un petit export n’est pas nécessairement sans usage : le rapport peut être incomplet, la période trop courte ou la demande saisonnière. Lorsque l’information manque, conservez le statut « à examiner » dans le dossier de travail au lieu de transformer une absence de mesure en preuve d’inutilité.

L’inventaire fonctionnel recense les opérations que le site rend possibles. Un visiteur peut envoyer une demande, télécharger une fiche, choisir une langue ou accéder à un service tiers. Les collaborateurs peuvent publier des contenus ou récupérer les messages. Vérifiez qui possède les accès et où arrivent les données. Une refonte qui préserve toutes les pages mais coupe une destination de formulaire a perdu un actif commercial, même si l’apparence du nouveau site est réussie.

Conservez une référence datée de l’état initial : fichiers, export des adresses, captures des parcours critiques et résultats de tests. Ce dossier permet de comparer deux versions sans dépendre du souvenir d’une personne. Il sert également à expliquer une décision de conservation. Le diagnostic SEO du site existant peut alimenter cet inventaire, mais il doit rester relié aux pages et aux opérations que le projet de refonte modifie réellement.

Attribuer une décision à chaque contenu

Une page peut être conservée, améliorée, réunie avec une ressource proche ou retirée lorsque cela est justifié. La décision doit porter sur son utilité et son intention, pas uniquement sur sa longueur. Un contenu précis qui répond à une question importante peut mériter d’être maintenu. À l’inverse, plusieurs pages longues qui répètent une offre sans différence peuvent demander une consolidation. Examinez leur destination commerciale et leurs liens avant de choisir.

Si deux pages sont réunies, la nouvelle ressource doit conserver les informations nécessaires aux deux parcours compatibles. Une redirection vers une page générique ne compense pas la perte d’un guide spécialisé. La documentation de Google sur les changements d’URL recommande une correspondance pertinente entre anciennes et nouvelles pages et déconseille de rediriger de nombreuses adresses vers une destination sans rapport. Le tableau de migration doit rendre cette correspondance vérifiable.

Les contenus commerciaux sensibles demandent un contrôle dédié. Préservez les conditions, les limites de service et les liens de paiement existants tant qu’une modification n’a pas été autorisée. Ne simplifiez pas une phrase si cela retire une réserve nécessaire. Un texte réglementé doit être revu par la personne compétente lorsque la refonte en modifie le sens. La responsabilité éditoriale ne disparaît pas parce qu’un contenu a changé de composant ou de mise en page.

Pour les éléments réécrits, préparez une comparaison lisible : besoin du lecteur, ancien message, nouveau message et preuve utilisée. La validation devient alors une décision sur le fond plutôt qu’une approbation vague de maquette. Si une information n’a pas été vérifiée, ne la remplacez pas par une affirmation plus assurée. Mieux vaut garder une explication limitée et exacte que créer une promesse que l’entreprise ne pourra pas tenir après publication.

Construire la navigation autour des décisions

La navigation doit permettre au lecteur de trouver une prestation, de vérifier qu’elle lui convient et de comprendre la suite. Pour une PME active dans plusieurs domaines, l’organigramme interne n’est pas nécessairement le meilleur menu. Testez les intitulés avec des situations concrètes : un propriétaire qui prépare des travaux, un responsable achats qui compare une prestation ou un client qui recherche une information pratique. Le chemin retenu doit réduire les hésitations sans multiplier les rubriques.

Les catégories doivent avoir un rôle éditorial réel. Une page qui ne fait que répéter les liens du menu apporte peu à celui qui hésite entre deux services. Elle peut expliquer les critères de choix, les exclusions et les interlocuteurs. Les pages détaillées prennent ensuite en charge les besoins spécifiques. Cette articulation évite de demander au visiteur de comprendre votre organisation avant de pouvoir exprimer son projet.

En Suisse, les zones desservies et les langues de prise en charge doivent être distinguées. Un formulaire traduit ne prouve pas qu’une équipe commerciale répond dans cette langue. Un bureau situé dans une commune ne signifie pas que toutes les prestations couvrent le pays. La refonte doit exposer le périmètre opérationnel confirmé, sans fabriquer une présence locale avec des pages identiques où seul le nom de ville change.

Validez la structure avec les contenus réels et les destinations finales. Une maquette contenant des titres provisoires très courts peut sembler claire puis devenir difficile à lire une fois les appellations métier ajoutées. Vérifiez aussi les chemins de retour, les liens entre rubriques et la navigation sur mobile. Le travail sur l’architecture des contenus aide à relier les pages selon leurs sujets ; il ne remplace pas un test des décisions que les visiteurs doivent accomplir.

Définir les responsabilités avant la production

La refonte implique souvent plusieurs personnes : direction, marketing, rédacteur, développeur, responsable métier et prestataire externe. Désignez qui décide pour chaque catégorie de changement. Le responsable métier valide une description de service ; l’équipe technique confirme une contrainte de fonctionnement ; la direction arbitre les choix qui dépassent le périmètre convenu. Cette répartition évite que tout soit soumis à tout le monde ou qu’un intervenant décide seul d’un changement engageant l’entreprise.

Le dossier de travail doit distinguer une proposition, une validation et une mise en production. Un commentaire positif sur une capture ne constitue pas forcément une autorisation de publier l’ensemble du site. Les décisions importantes doivent préciser la version concernée et leurs limites. Une validation du texte français ne valide pas automatiquement sa traduction, son formulaire ou ses données structurées. Chaque élément doit être examiné au niveau où il peut introduire un défaut.

Gardez un responsable de cohérence transversale. Une modification de rubrique peut toucher le menu, les titres, les liens internes, le formulaire et le suivi des conversions. Si chaque intervenant vérifie seulement sa partie, les raccords risquent d’être oubliés. Le responsable de cohérence ne remplace pas les spécialistes ; il vérifie que leurs livrables se rencontrent dans un parcours complet et que les désaccords sont résolus avant la recette.

Prévoyez enfin le fonctionnement après livraison. Qui corrigera une information devenue fausse ? Qui pourra suspendre un formulaire ? Qui recevra une alerte de disponibilité ? La documentation utile décrit ces opérations et les personnes habilitées, sans exposer de secrets. Une refonte n’est pas terminée lorsqu’elle devient dépendante d’un intervenant indisponible pour chaque modification courante. Les accès, la réversibilité et la continuité doivent être discutés avant la bascule.

Préserver les URL et les versions linguistiques

Conserver une adresse utile simplifie la continuité du site. Un changement de titre ou de présentation n’exige pas nécessairement un nouveau chemin. Lorsque des URL doivent changer, préparez leur correspondance avant de développer les redirections. Vérifiez la destination, le contenu conservé et la réponse attendue. Les liens internes devront pointer directement vers la nouvelle adresse finale, afin d’éviter une navigation qui passe continuellement par des détours anciens.

Le contrôle concerne aussi les fichiers et les images qui reçoivent des liens. Une brochure commerciale peut être utilisée dans un message déjà envoyé ou dans un document externe. Son remplacement doit être organisé selon sa fonction. Si son contenu est devenu inexact, identifiez la ressource adaptée ou le comportement de retrait. Ne laissez pas un ancien fichier public contredire les nouvelles conditions simplement parce qu’il n’apparaît plus dans le menu.

Pour un site multilingue, la liste doit relier chaque version à son contenu réel. Google explique dans sa documentation sur les sites multirégionaux et multilingues l’intérêt d’URL distinctes pour les versions linguistiques et d’une navigation permettant de choisir la langue. La refonte doit vérifier que le changement de langue mène à la ressource correspondante, pas toujours à l’accueil, lorsque cette ressource existe.

Une version absente ne doit pas être simulée avec une redirection trompeuse. Si une prestation n’est présentée qu’en français, ne déclarez pas une page allemande identique qui affiche finalement le français. Les responsables du contenu doivent décider quelles versions sont maintenues et qui les actualise. La qualité d’une traduction comprend le produit, les acteurs et les démarches du marché visé ; remplacer les mots sans contrôler ces éléments peut rendre une page techniquement correcte mais commercialement fausse.

Recetter les formulaires de bout en bout

Le formulaire doit être testé depuis la page d’entrée jusqu’à la réception par la bonne équipe. Vérifiez les champs, les messages d’erreur, la confirmation et la destination réelle. Un bouton qui change de couleur ne démontre pas qu’une demande a été enregistrée. Un message reçu par un développeur ne prouve pas que le responsable commercial le recevra après publication. Le test doit reproduire le parcours prévu pour l’entreprise.

Les cas d’échec sont aussi importants que l’envoi normal. Préparez un champ manquant, un format incorrect, une indisponibilité du service de réception et un double clic. Le visiteur doit comprendre ce qu’il peut corriger et ne pas croire qu’une demande perdue a été transmise. L’équipe doit pouvoir retrouver un dossier sans créer plusieurs opportunités identiques lors d’une nouvelle tentative. Les confirmations ne doivent pas afficher des renseignements personnels inutilement dans une adresse publique.

Les informations de confidentialité doivent correspondre au traitement effectif. Le PFPDT distingue les usages publicitaires selon le canal. Une refonte de formulaire ne doit pas ajouter silencieusement une inscription commerciale à une demande de prestation. La finalité, les destinataires et les choix proposés doivent rester cohérents avec l’organisation réelle. Faites examiner les changements par le responsable compétent lorsque des partenaires ou de nouveaux usages sont introduits.

Testez également les contacts alternatifs : lien téléphonique, adresse de messagerie, prise de rendez-vous ou téléchargement. Ils peuvent constituer une part importante du parcours sans passer par le formulaire principal. Le compte rendu de recette doit préciser ce qui a été vérifié, depuis quelle page et dans quelle version. Les données de test doivent être reconnaissables et traitées selon une procédure convenue pour ne pas polluer le suivi commercial réel.

Contrôler la lisibilité et le chargement

Une nouvelle interface doit être évaluée avec les pages représentatives du futur site. Choisissez une page de service, un article long, une page comportant un formulaire et un contenu riche en médias. Leur comportement peut différer alors qu’ils partagent le même menu. Vérifiez les petits écrans, les textes longs, les tableaux, les liens et les zones interactives. Une capture de l’accueil sur ordinateur ne couvre pas l’ensemble de ces situations.

Le chargement des médias doit respecter l’usage réel. Une grande photographie peut être utile pour expliquer une prestation, mais son poids et ses dimensions doivent être adaptés. Les vidéos, polices et composants externes doivent être recensés pour comprendre leurs dépendances. Lorsque leur chargement échoue, le contenu principal et l’action attendue doivent rester accessibles. Cette vérification est particulièrement importante si le nouveau site remplace un contenu statique par des effets ou des interactions.

Examinez séparément le document reçu et ce que le navigateur affiche. Un titre visible peut être absent du contenu initial ou ajouté seulement après une action. Le contrôle technique SEO permet d’examiner le rendu, les réponses des pages et les ressources nécessaires. Le choix d’une technologie ne constitue pas en soi une preuve de qualité : la version réellement servie doit être testée avec ses contenus et ses paramètres.

Les tests de laboratoire donnent des repères, pas une description complète de tous les visiteurs. Notez les conditions de mesure et comparez des versions équivalentes. Une baisse liée à une image précise appelle une correction différente d’un ralentissement intermittent d’un service externe. Ne transformez pas un score unique en garantie de conversion ou de classement. La recette doit expliquer ce qui fonctionne, ce qui reste fragile et quelles limites ont été acceptées.

Organiser une recette vérifiable

La recette associe chaque exigence à un test et à une preuve. « Le SEO est conservé » est trop large pour être vérifié avant publication. On peut en revanche contrôler qu’une URL prévue répond correctement, que son titre correspond au contenu, que ses liens sont valides et que son formulaire aboutit. Décomposez ainsi les objectifs généraux en résultats observables, puis conservez les anomalies avec leur gravité et leur responsable.

Le plan doit distinguer les tests complets et les échantillons. Vérifier tous les liens critiques est possible sur un site modeste ; observer manuellement chaque combinaison de navigateur et de page l’est moins. Indiquez les pages choisies et les situations non examinées. Un résultat partiel doit rester présenté comme tel. Cette transparence aide à décider quels risques résiduels nécessitent un contrôle supplémentaire avant la mise en ligne.

Après une correction, refaites le test qui échouait et ceux que le changement peut affecter. Modifier un composant commun pour réparer un formulaire peut déplacer des éléments sur d’autres pages. La preuve finale doit donc porter sur la version corrigée, pas sur une capture produite auparavant. Une anomalie ne se ferme pas parce que le code a changé ; elle se ferme lorsque le comportement attendu est observé à nouveau.

Préparer la bascule et le retour arrière

La mise en ligne nécessite une décision explicite sur une version identifiée. Préparez la source à publier, les accès nécessaires, les personnes disponibles et les contrôles à réaliser immédiatement après. Un site de test validé ne doit pas être confondu avec une autre copie plus récente mais non vérifiée. Conservez un repère de version et la liste des changements inclus afin que l’équipe sache exactement ce qui sera servi.

Le retour arrière doit être pensé avant la bascule. Déterminez ce qui peut être restauré et ce qui nécessite une attention particulière, notamment les demandes reçues pendant la transition. Restaurer une ancienne interface ne doit pas faire disparaître des données collectées entre-temps. Le plan doit nommer la personne habilitée à décider et préciser les défauts qui déclenchent l’arrêt, comme l’indisponibilité de pages critiques ou l’échec généralisé des formulaires.

Après publication, contrôlez les adresses publiques réelles, les redirections, les balises, les médias et les parcours. Une configuration de production peut différer de la prévisualisation. Les caches, domaines et services externes doivent être examinés au bon endroit. Le statut « déploiement réussi » fourni par un hébergeur ne prouve pas que le domaine attendu affiche la version validée ni que les demandes parviennent au bon destinataire.

Organisez la communication interne autour de ces contrôles. Les commerciaux doivent savoir quand le nouveau parcours entre en service et comment signaler une anomalie. Les personnes qui publient des contenus doivent connaître les règles mises à jour. Conservez les décisions et les preuves techniques dans un dossier accessible aux responsables concernés. Il n’est pas nécessaire d’exposer ce dossier aux visiteurs pour leur fournir un site clair et fonctionnel.

Lire les résultats après la refonte

Les premières observations doivent séparer fonctionnement, exploration, visibilité et conversion. Le site peut être correctement publié sans que Google ait encore réexaminé toutes ses pages. Une adresse présente dans un sitemap n’est pas une confirmation d’indexation. Les résultats de recherche peuvent également évoluer pour d’autres raisons que la refonte. Le suivi doit conserver les périodes, les pages concernées et les changements intervenus afin de ne pas attribuer trop vite chaque variation au projet.

Les données commerciales permettent de vérifier si le parcours remplit son objectif. Examinez la destination des demandes, les prestations choisies et les motifs de refus. Une augmentation de formulaires peut cacher davantage de demandes hors zone ou des messages de support arrivés dans une boîte commerciale. Le succès ne se mesure pas seulement au total reçu. Il dépend de la correspondance entre les besoins exprimés et les services réellement proposés.

Pour comparer avant et après, documentez les modifications du plan de mesure. Si le nouveau site compte un événement supplémentaire, le total ne peut pas être interprété comme une progression à périmètre constant. Préservez les balises existantes sauf modification explicitement autorisée, puis testez les événements. Conservez les limites connues de la mesure et les changements de consentement ou de parcours qui peuvent affecter l’observation.

Un exemple hypothétique aide à lire ces données : une page de contact reçoit moins d’envois après l’ajout d’une indication claire sur les zones couvertes, mais les demandes restantes correspondent mieux aux possibilités de l’entreprise. Il faut examiner leur traitement avant de conclure à un échec. Le bilan peut alors distinguer baisse du volume brut et meilleure adéquation, sans transformer cet exemple en résultat annoncé pour votre propre refonte.

Cadrer votre refonte avec SEO Swiss

Pour préparer un échange, apportez l’adresse du site, les problèmes observés et les opérations que vous souhaitez améliorer. Indiquez les langues, les offres à préserver, les équipes concernées et les contraintes techniques connues. Les accès sensibles ne doivent pas être envoyés dans un message public. Un premier diagnostic peut se préparer avec les informations disponibles et un accès approprié aux données nécessaires, selon des droits limités au périmètre convenu.

Demandez un périmètre écrit plutôt qu’une promesse générale de modernisation. Il doit préciser les contenus concernés, les livrables, les validations et les tests. Les éventuelles modifications de design, de domaine ou de mesure doivent être distinguées de la correction éditoriale. Si un problème peut être résolu sans refaire toutes les pages, cette option mérite d’être examinée. La taille du chantier doit découler du besoin et des preuves, pas d’une préférence pour reconstruire.

La proposition de travail doit également prévoir les limites. Certains résultats dépendent d’un prestataire tiers, d’une validation métier ou du traitement ultérieur par Google. Les responsabilités doivent être explicites pour éviter qu’une attente non formulée devienne un désaccord à la livraison. La disponibilité d’une version locale, sa publication et son adoption dans les résultats de recherche correspondent à des états distincts, chacun demandant sa propre vérification.

Présentez votre projet de refonte à SEO Swiss en décrivant le problème prioritaire et les éléments que vous souhaitez conserver. L’échange servira à définir une intervention contrôlable, les preuves attendues et les conditions de mise en ligne. Vous pourrez ainsi décider sur un périmètre concret, avec un inventaire, une recette et un suivi, plutôt que sur la seule apparence d’une maquette ou une garantie de classement impossible à vérifier.