Sites web et SEO / 04
Refonte de site et SEO : préserver le parcours qui mène aux demandes
Le nouveau site est réussi. Pourtant, un ancien lien ne fonctionne plus, le changement de langue ramène à l’accueil et les demandes deviennent difficiles à suivre. Voici ce qu’il faut conserver et vérifier pour que la refonte serve l’activité.
Un site plus élégant peut pourtant perdre des demandes
La nouvelle page d’accueil est rapide, les cartes sont soignées et le menu mobile plaît à toute l’équipe. Quelques semaines plus tard, les demandes issues de la recherche diminuent. La cause n’est pas nécessairement la couleur d’un bouton. Une prestation a changé d’adresse, un lien partenaire mène à une page absente ou le sélecteur de langue renvoie systématiquement à l’accueil.
Une refonte modifie un ensemble de contenus, de liens et de parcours qui fonctionne déjà. Avant les maquettes, identifiez ce que cet ensemble apporte. Quelle page présente l’entreprise ? Laquelle répond à une question précise avant un achat ? Laquelle permet de prendre contact ? Ces rôles doivent rester compréhensibles dans la nouvelle structure.
Ce guide utilise des exemples fictifs, pas des résultats clients. Aucune méthode de migration ne garantit des positions inchangées. En revanche, un inventaire et des vérifications reproductibles permettent de repérer des erreurs évitables avant que les visiteurs les rencontrent. Un site abouti doit fonctionner aussi bien dans son usage quotidien que sur une présentation.
Conserver une photographie du site existant
Rassemblez les URL à partir du sitemap, des liens internes, des données analytiques et des rapports Search Console disponibles. Pour chaque page importante, notez la langue, le sujet, l’action attendue et les indicateurs utiles. Ne vous limitez pas au menu actuel. Un ancien article peut encore attirer des prospects pertinents sans être connu de toute l’équipe.
Le nombre de visites ne suffit pas à décider. Une page consacrée à une intégration précise peut recevoir peu de visiteurs, mais répondre exactement à leur besoin. Un article général peut attirer davantage de monde sans contribuer aux demandes. Examinez les contacts et les étapes utiles du parcours lorsque votre mesure le permet, en signalant les informations manquantes.
Conservez aussi les titres, descriptions, intertitres, textes essentiels et principaux liens. Il ne s’agit pas de figer les anciennes formulations. Cette base permettra de distinguer un changement de présentation d’un changement de réponse. Sans elle, une baisse peut donner lieu à des suppositions alors qu’une page ou un passage important a simplement disparu.
Relever
URL, requêtes, demandes reçues et formulaires fonctionnels.
Associer
Prendre une décision pour chaque ancienne adresse.
Vérifier
Langues, redirections, indexation et parcours complet de contact.
Observer
Comparer des pages et des périodes équivalentes après le lancement.
Si un formulaire tombe en panne ou une page clé devient inaccessible, une personne désignée prend en charge la correction ou le retour arrière.
Attribuer une destination pertinente à chaque ancienne URL
Pour chaque adresse, choisissez de la conserver, de la déplacer vers un équivalent, de la regrouper avec un contenu proche ou de la supprimer. La décision doit respecter le besoin initial du visiteur. Rediriger toutes les anciennes prestations vers l’accueil simplifie parfois le développement, mais offre rarement une réponse équivalente.
Google recommande des redirections permanentes côté serveur pour les pages déplacées et un chemin direct vers la destination finale. Un ancien lien vers un audit doit donc ouvrir le nouvel audit correspondant. Évitez les étapes intermédiaires inutiles. La redirection guide une personne autant qu’elle informe un moteur de recherche.
Demandez une table de correspondance et vérifiez ses lignes sur le serveur réel. Contrôlez le statut HTTP, la destination et l’absence de boucle. Ajoutez quelques anciens chemins linguistiques et liens de campagne. Un tableau correct ne prouve pas que les règles publiées produisent effectivement le résultat prévu.
Faites défiler horizontalement pour voir toutes les colonnes.
| Situation de la page | Action | Vérification |
|---|---|---|
| Adresse et contenu conservés | Garder une réponse 200 | Canonical autoréférent et liens internes |
| Remplacement équivalent disponible | Redirection permanente 301 ou 308 | Un seul saut vers l’URL finale répondant en 200 |
| Contenus regroupés | Rediriger vers la page consolidée pertinente | La destination répond à l’intention de recherche initiale |
| Suppression sans remplacement | Réponse 404 ou 410 ; retrait du sitemap | Ne pas tout rediriger vers l’accueil |
Préserver la réponse derrière la requête
Une ancienne page sur l’automatisation expliquait les documents traités, les exceptions et les critères de réception. Sa remplaçante affiche seulement « Construisons demain » au-dessus d’un bouton. La composition paraît plus simple, mais le prospect ne comprend plus ce qui est livré. Supprimer des précisions utiles modifie la fonction de la page.
Identifiez l’intention de chaque contenu important. Le lecteur cherche-t-il un prestataire, une comparaison, une explication des coûts ou la solution à un problème précis ? Écrivez pour cette tâche. Les expressions pertinentes trouvent naturellement leur place dans les noms des prestations, les exemples et les explications. Leur répétition ne remplace pas une réponse.
Séparez les sujets qui méritent des développements différents. Agents IA, développement web sur mesure et création de MVP peuvent disposer de pages distinctes, reliées là où cela aide le lecteur. Le blog approfondit une décision. Cette organisation évite de réunir toutes les activités et tous les mots-clés dans un texte général sans relief.
Donner un rôle clair à l’accueil, aux prestations et au blog
L’accueil présente l’entreprise et aide à choisir une direction. Une page de prestation explique une mission précise. Un article accompagne une personne qui souhaite comprendre avant de commander. Lorsque ces rôles sont clairs, il devient plus facile de juger la navigation, les textes et les appels à l’action.
Pour une prestation, précisez à qui elle convient, ce qui est livré, les informations nécessaires et la manière de vérifier le résultat. Utilisez des preuves réelles que vous pouvez montrer. Un scénario illustratif doit être annoncé comme tel. Une présentation soignée ne transforme pas des chiffres inventés en étude de cas.
Placez les liens au moment où un complément est utile. Un article sur le coût de l’automatisation peut mener à la prestation correspondante, laquelle peut renvoyer vers le calcul détaillé. Le libellé doit expliquer ce que le lecteur trouvera. Des invitations identiques à « en savoir plus » rendent les destinations moins compréhensibles.
Vérifier les langues comme un parcours complet
Ouvrez une prestation précise et changez de langue. Si une traduction équivalente existe, le même sujet doit apparaître. Revenir à l’accueil oblige le visiteur à recommencer sa recherche. Pour un article long, le problème est particulièrement visible : la personne veut poursuivre le même contenu dans une langue plus confortable.
Les annotations hreflang relient des versions linguistiques ou régionales correspondantes. Ces relations doivent être cohérentes et pointer vers des pages disponibles. La balise ne traduit pas le texte et ne crée pas à elle seule une pertinence locale. Le vocabulaire, le contact et les informations commerciales doivent également convenir au public visé.
Une langue ne correspond pas automatiquement à un pays. Une édition anglaise peut servir plusieurs marchés. Une édition régionale se justifie lorsqu’elle explique une différence réelle d’offre, de conditions ou de contenu. Remplacer uniquement le nom du pays dans des dizaines de pages presque identiques apporte peu à une personne qui compare des prestataires.
Aligner les URL canoniques sur le site publié
L’URL canonique indique la version préférée parmi des pages identiques ou très proches. Après la refonte, elle doit correspondre à l’adresse publique prévue. Une erreur de modèle peut faire pointer toutes les prestations vers l’accueil ou conserver le domaine de prévisualisation. Le défaut se propage alors à de nombreuses pages.
Inspectez le HTML renvoyé par le serveur pour l’accueil, une prestation, un article et une traduction. Vérifiez ensuite l’ensemble des adresses importantes automatiquement. Comparez les canoniques avec les liens internes et le sitemap. Des signaux contradictoires ne deviennent pas plus clairs lorsqu’on ajoute une balise supplémentaire.
Évitez de regrouper indistinctement toutes les traductions sous une canonique anglaise. Une version linguistique a généralement besoin d’une canonique adaptée dans la même langue ; hreflang décrit les correspondances entre éditions. Examinez ces choix ensemble afin que les métadonnées, le menu linguistique et le sitemap racontent la même structure.
Rendre le contenu disponible avant la fin des effets visuels
Chargez un article avec une connexion lente et observez l’apparition du titre, du texte et des liens. Examinez aussi la réponse HTML du serveur. Un contenu éditorial se prête bien à une disponibilité immédiate. La lecture ne devrait pas dépendre d’une animation lourde ou de l’exécution réussie d’un script sans rapport avec le sujet.
JavaScript reste utile pour les formulaires, calculateurs et interactions pertinentes. La question est de savoir quelles dépendances sont indispensables à la tâche principale. Distinguez l’article de ses enrichissements. Cela facilite le diagnostic des erreurs et évite qu’une difficulté de réseau ordinaire bloque toute l’expérience.
Contrôlez les vrais liens entre les pages. Une personne peut ouvrir une prestation dans un autre onglet, copier une référence ou naviguer au clavier. Une destination appelle un lien avec une adresse valable ; une action appelle un bouton. Cette distinction simple contribue à la fiabilité du parcours.
Commencer la performance par la première action utile
Une grande vidéo ou une scène en trois dimensions peut être impressionnante sur l’ordinateur du designer. Testez la même page sur un téléphone courant avec une connexion mobile. Comprend-on rapidement l’offre ? L’action principale fonctionne-t-elle ? Le texte se déplace-t-il quand une image ou une police arrive plus tard ?
Les Core Web Vitals décrivent le chargement, la réactivité et la stabilité visuelle. Considérez les tests de laboratoire avec les données disponibles de véritables visites. Un excellent passage sur une machine rapide ne représente pas tout le public. Recherchez les éléments et interactions à l’origine d’un mauvais résultat plutôt que de poursuivre uniquement une note.
Réservez les dimensions des médias, examinez les polices et différez les ressources inutiles au départ. Regardez aussi la quantité de code exécutée pour une simple page de lecture. Le concept graphique peut souvent être conservé avec un meilleur ordre de chargement. La qualité perçue commence avant que tout soit affiché.
Tester le mobile avec les traductions définitives
Un titre court en anglais peut devenir sensiblement plus long en allemand, en polonais ou en ukrainien. Utilisez les véritables textes dans les cartes, les menus et les boutons. Les informations importantes ne doivent pas être masquées par une hauteur fixe ou un élément décoratif. Une maquette réussie avec du faux texte ne suffit pas.
Parcourez l’action principale sur un écran étroit. Le lanceur du chat recouvre-t-il le bouton d’envoi ? Le clavier cache-t-il les erreurs ? Peut-on fermer le menu des langues ? Vérifiez les zones tactiles et le focus visible au clavier. Ces détails influencent directement la capacité à terminer une demande.
Les articles longs nécessitent une largeur de lecture agréable, un contraste suffisant et des liens vers les sections. Un sommaire repliable peut garder un début compact sur téléphone. Le lecteur doit pouvoir retrouver un calcul ou une liste de vérification sans repartir du haut du texte.
Suivre une demande jusqu’à la personne responsable
Le trafic organique produit peu de valeur si le formulaire échoue silencieusement. Vérifiez toute la chaîne : saisie, enregistrement, confirmation et notification au bon interlocuteur. Utilisez un environnement convenu ou des données clairement marquées comme tests. Un message de succès dans le navigateur ne prouve pas la réception effective.
Essayez un champ manquant, un second clic et une erreur temporaire du serveur. Le visiteur doit comprendre si son message a été reçu et quoi faire ensuite. Conservez sa saisie jusqu’à confirmation. Perdre un brief détaillé à cause d’un incident passager abîme fortement l’expérience, même sur un site très soigné.
En analyse, distinguez le clic d’une demande réellement reçue. Vérifiez les événements en double et ceux perdus après navigation. Si la mesure change en même temps que le design, documentez-le. Sinon, la comparaison de conversion peut raconter une différence de suivi plutôt qu’une différence de comportement.
Faire correspondre les métadonnées au contenu visible
Chaque page mérite un titre précis et une description correspondant à son sujet et à sa langue. Le titre aide à reconnaître une réponse avant d’ouvrir le résultat. Énumérer tous les métiers de l’agence est généralement moins utile que nommer clairement cette ressource. Gardez un lien compréhensible entre présentation dans la recherche et titre visible.
Les données structurées d’un article peuvent décrire le titre, l’auteur ou l’organisation, les dates et l’image. Ces renseignements doivent correspondre au contenu publié. Ne changez pas une date de modification sans changement substantiel et n’inventez pas un expert pour créer de l’autorité. Une source de contenu commune facilite la cohérence.
Vérifiez également l’aperçu d’un lien partagé. Adresse, titre, description et image doivent représenter la page concernée. Un article qui ressemble à l’accueil est plus difficile à identifier. Ce contrôle peut accompagner les vérifications des canoniques et des langues, plutôt que devenir une tâche oubliée en fin de projet.
Distinguer la protection de la prévisualisation et l’indexation publique
Le sitemap doit contenir les adresses publiques que vous souhaitez faire découvrir. Écartez les variantes accidentelles de paramètres, les pages de test et les URL qui ne font que rediriger. Appelez les destinations pour vérifier leurs réponses. Un XML valide ne prouve pas que ses pages fonctionnent.
Une prévisualisation peut légitimement bloquer l’indexation. Avant le lancement, assurez-vous que ces réglages ne restent pas sur les contenus publics. Inspectez robots.txt, les métadonnées et les en-têtes HTTP. Leurs fonctions diffèrent ; une seule case dans l’administration ne décrit pas nécessairement toute la configuration.
Les espaces privés ont besoin d’un contrôle d’accès indépendant. Noindex n’est pas une authentification. Un inventaire clair des pages marketing permet de les distinguer des écrans d’administration et des comptes clients. Cela évite d’appliquer une modification générale à des routes dont les objectifs sont très différents.
Prévoir une vérification courte mais complète le jour du lancement
Choisissez un exemple de chaque modèle important : accueil, prestation, article, contact, traduction et ancienne URL redirigée. Ouvrez-les après publication sur le domaine réel. Vérifiez contenu, statut, langue, canonique et action principale. Une compilation réussie ne garantit pas la bonne configuration du domaine et de l’environnement.
Contrôlez formulaires et notifications dans le mode de test convenu. Les accès aux services et domaines autorisés peuvent différer de la prévisualisation. Nommez la personne capable de corriger une intégration. Le plan de lancement doit inclure cette responsabilité opérationnelle, pas seulement l’étape de publication.
Conservez un moyen praticable de revenir à la version précédente et définissez les situations qui le justifient. Une demande impossible à envoyer appelle une autre réaction qu’un léger défaut d’espacement. Cette distinction garde la discussion centrée sur l’impact pour les visiteurs plutôt que sur des captures isolées.
Comparer des situations comparables après la refonte
Commencez par les éléments techniques : pages absentes, mauvaises redirections, changements d’indexation et formulaires défaillants. Examinez ensuite les entrées, les requêtes et les demandes terminées. Le trafic global peut masquer une baisse sur une prestation ou une langue pendant qu’une autre progresse.
Tenez compte de la saison, des campagnes et de l’offre. Si les prix, les sources de visiteurs et le design changent ensemble, l’attribution restera limitée. La photographie initiale aide à distinguer les régressions évidentes des changements plus larges. Exposez cette limite au lieu d’attribuer tous les mouvements à la refonte.
Ne reconstruisez pas les pages à chaque fluctuation quotidienne. Réunissez des indices suffisants pour la décision concernée. En revanche, une URL importante en erreur ou un formulaire cassé n’exige pas d’attendre une tendance statistique. Corrigez le défaut observable, puis mesurez le résultat plus général.
Demander un site que l’équipe pourra continuer à faire vivre
Avec le design terminé, demandez l’inventaire des routes, les correspondances d’URL, les règles linguistiques, les résultats des tests et les consignes de publication. Ce sont des outils pour la prochaine personne qui modifiera le site. Ils doivent expliquer les choix et permettre une action concrète.
Créez un article non publié, puis modifiez son titre. Vérifiez ensemble la page, sa carte et ses métadonnées. Si la même information doit être recopiée à plusieurs endroits, les divergences deviennent plus probables. Une bonne organisation éditoriale rend le résultat cohérent lors des modifications ordinaires.
Attribuez enfin la responsabilité des relectures et des liens cassés. Une refonte n’est qu’une étape dans la vie du site. Sa qualité réapparaît lorsqu’une prestation est ajoutée, qu’une langue s’étend ou qu’un guide doit être corrigé. La transmission doit permettre à l’entreprise d’effectuer ces changements avec compréhension et méthode.
Avant de commencer
- Conserver les URL importantes, les contenus et les données de départ.
- Valider les correspondances d’URL, les parcours linguistiques et les critères de réception.
- Tester la configuration de recherche et le parcours complet d’une demande sur le domaine public.
Note de la rédaction. Les exemples illustrent une décision ou un test ; ce ne sont pas des résultats clients.