SEO et architecture web : le plan avant de construire

Un site ne devrait commencer ni par le design ni par une liste de mots-clés. Apprenez à relier votre entreprise, la demande et les besoins de vos clients pour définir les pages nécessaires, leur organisation et la fonction de chacune.

Imaginez que vous allez construire une maison.

Avant de choisir les matériaux, de répartir les meubles ou de décider des finitions, vous devez comprendre comment cet espace sera utilisé.

Combien de personnes y vivront, quels sont leurs besoins, comment les pièces s’articuleront et quelles conditions la construction doit remplir.

Vous aurez ensuite besoin d’un plan.

Il devrait en aller de même pour un site web.

Pourtant, de nombreux projets commencent directement par le design.

On choisit un modèle, on dessine la page d’accueil et on organise un menu avec les rubriques habituelles : Accueil, Services, À propos et Contact.

On répartit ensuite les contenus disponibles et, lorsque le site possède déjà une structure définie, vient le moment de travailler le référencement naturel.

Des difficultés peuvent alors apparaître.

Nous découvrons que différents services ont besoin de pages propres, que certaines recherches importantes ne trouvent pas de réponse adaptée ou que plusieurs pages expliquent pratiquement la même chose.

Nous devons parfois refaire une partie du travail. D’autres fois, nous finissons par accepter une structure peu adaptée parce que sa modification demanderait trop d’efforts.

Le problème ne réside pas nécessairement dans le design ni dans la qualité du développement.

Il réside dans le fait d’avoir commencé à construire avant de décider ce qu’il fallait construire.

L’architecture web permet de résoudre cette question.

C’est le travail qui relie la réalité de l’entreprise, son offre, les besoins des personnes et la demande de recherche à une structure cohérente de pages, de contenus et de parcours.

Il ne consiste pas uniquement à dessiner un menu.

Il consiste à créer le plan sur lequel pourront ensuite travailler le design, les contenus, le développement et le SEO.

Et plus ce plan sera clair, plus il sera facile de construire un site qui remplisse une fonction réelle pour l’entreprise.

1. Qu’est-ce que l’architecture web et pourquoi compte-t-elle ?

L’architecture web est l’organisation des informations, des pages et des fonctions d’un site, ainsi que des relations qui existent entre elles.

Elle permet de décider quels contenus ont besoin d’un espace propre, comment les regrouper, quelle importance accorder à chaque rubrique et comment les personnes peuvent trouver ce dont elles ont besoin.

Elle aide aussi les moteurs de recherche à découvrir les pages et à mieux comprendre leurs relations.

Mais sa valeur ne se limite pas au référencement.

Une bonne architecture permet à une personne de s’orienter dans le site, de comprendre une offre, de comparer les options et d’effectuer l’action dont elle a besoin.

Prenons un petit hôtel.

Une personne peut arriver en cherchant des informations sur ses chambres.

Une autre veut connaître les conditions d’un séjour avec des enfants.

Une troisième doit vérifier les disponibilités pour des dates précises.

Et quelqu’un qui ne connaît pas encore l’établissement peut rechercher les expériences offertes par la destination.

Tous ces besoins n’exigent pas nécessairement une page indépendante.

Mais tous méritent une réponse adaptée.

L’architecture doit nous aider à décider où fournir cette réponse et comment la relier au reste du site.

Une page a besoin d’une raison d’exister

Une page ne devrait pas être créée simplement pour ajouter une option au menu.

Elle devrait remplir une fonction identifiable.

Elle peut présenter un service, répondre à une question, faciliter un achat, montrer une expérience, expliquer des conditions ou aider à trouver des informations connexes.

Certaines pages remplissent des fonctions commerciales.

D’autres sont informatives, opérationnelles ou renforcent la confiance.

L’essentiel est de savoir à quel besoin chacune répond.

Une page de service peut, par exemple, avoir pour fonction d’expliquer une activité et de faciliter sa réservation.

Un article peut aider à comprendre comment choisir cette activité.

Et une page générale peut organiser différentes expériences pour que le visiteur trouve la plus adaptée.

Toutes trois remplissent des fonctions différentes, mais peuvent travailler ensemble.

Une bonne architecture ne cherche pas à accumuler les pages. Elle cherche à organiser les réponses.

L’architecture n’est pas le menu de navigation

Cette distinction compte.

L’architecture définit l’organisation de l’information du site.

La navigation est l’ensemble des mécanismes qui permettent d’y accéder : menus, liens, catégories, filtres et autres éléments.

Un site peut contenir des dizaines de pages sans devoir toutes les inclure dans son menu principal.

Il peut aussi avoir un menu visuellement simple derrière lequel se trouve une architecture complexe.

Nielsen Norman Group distingue précisément l’organisation des contenus et des fonctionnalités des éléments de navigation qui permettent de les trouver. [1]

Concevoir un menu ne revient donc pas à concevoir l’architecture.

Nous devons d’abord comprendre quelles informations doivent exister et comment elles s’articulent.

Nous pourrons ensuite décider comment en faciliter l’accès.

2. Pourquoi le SEO et l’architecture web doivent travailler ensemble

Le SEO, ou référencement dans les moteurs de recherche, cherche à améliorer la capacité d’un site à être découvert par les recherches pertinentes pour son contenu et ses objectifs.

Une partie fondamentale de ce travail consiste à étudier ce que les personnes cherchent et ce qu’elles espèrent trouver.

L’architecture utilise ces connaissances pour organiser les pages et leurs relations.

C’est pourquoi les deux disciplines devraient être développées de manière coordonnée.

Mais nous devons établir une différence importante :

Le SEO apporte des éléments sur la demande. Il ne doit pas remplacer la stratégie de l’entreprise.

Nous comprenons d’abord ce que l’entreprise propose

Imaginons une entreprise spécialisée dans les excursions guidées dans les Pyrénées.

Sa proposition repose sur de petits groupes, un accompagnement professionnel et des expériences adaptées à différents niveaux de préparation.

Pendant l’étude SEO, nous découvrons un intérêt pour la location de matériel de montagne.

Cela signifie-t-il que nous devrions immédiatement créer une page pour ce service ?

Pas nécessairement.

Nous devons d’abord vérifier si l’entreprise propose de la location, si elle souhaite la développer et si elle dispose des ressources nécessaires pour le faire correctement.

Une recherche peut représenter une opportunité.

Mais elle peut aussi sortir de notre modèle économique.

Créer des contenus pour attirer des personnes intéressées par des services que nous ne proposons pas peut augmenter les visites sans apporter de valeur commerciale.

C’est pourquoi la stratégie digitale doit définir un premier périmètre.

Nous devons comprendre ce que l’entreprise propose, qui elle veut servir, les territoires qu’elle couvre, ses capacités et ses objectifs.

Nous utilisons ensuite le SEO pour étudier comment cette demande s’exprime et confronter nos hypothèses aux faits.

Nous étudions ensuite la manière dont les personnes cherchent

Le langage du client ne coïncide pas toujours avec celui de l’entreprise.

Une entreprise peut décrire son produit comme des « expériences de cyclotourisme assisté ».

Ses clients pourraient en revanche chercher des « parcours en vélo électrique » ou des « excursions guidées en e-bike ».

Ces expressions peuvent renvoyer à des services liés, mais nous devons vérifier l’intention derrière chacune.

Une personne peut vouloir acheter une excursion.

Une autre cherche à louer un vélo.

Et une troisième veut simplement trouver un itinéraire à parcourir seule.

Les mots peuvent sembler proches.

Les besoins sont différents.

L’étude des recherches nous aide à reconnaître ces nuances et à décider quelles réponses le site mérite d’offrir.

Le volume de recherche ne décide pas à notre place

Un mot-clé très recherché ne constitue pas automatiquement une opportunité intéressante.

Nous devons évaluer son rapport avec notre offre, les attentes de l’utilisateur, la concurrence existante et notre capacité à fournir une réponse utile.

Nous devons aussi considérer les recherches moins fréquentes qui peuvent représenter un besoin beaucoup plus précis et pertinent.

Pour une activité spécialisée, attirer moins de personnes mais davantage en phase avec sa proposition peut être plus pertinent que de poursuivre un grand volume de trafic peu lié à ses services.

Il ne s’agit pas de choisir entre stratégie et SEO.

Il s’agit de les utiliser ensemble.

L’entreprise établit quelle valeur elle peut offrir. L’étude de la demande aide à comprendre où et comment cette valeur peut être pertinente.

Google recommande aussi d’organiser les sites de manière logique pour permettre aux utilisateurs comme aux moteurs de recherche de comprendre les relations entre les pages. [2]

3. Comment construire le plan d’un site

Chez PhiStudio, nous organisons le travail de SEO et d’architecture autour de cinq instruments connectés.

Chacun répond à une question différente et aide à passer de la connaissance de l’entreprise à une structure prête à être construite.

Cette séquence est notre manière d’organiser le travail professionnel.

Elle ne constitue pas une méthode universelle obligatoire. Dans la pratique, les résultats d’une phase peuvent nous amener à revoir des décisions antérieures.

1. Plan de site fonctionnel initial : la première hypothèse

La première étape consiste à proposer les pages dont l’entreprise pourrait avoir besoin à partir de sa stratégie et de son offre.

Nous ne décidons pas encore de la structure définitive.

Nous formulons une hypothèse.

Si une entreprise propose trois services réellement différenciés, nous pouvons, par exemple, envisager au départ une page pour chacun.

Si elle couvre différents territoires, nous devrons étudier si ces différences justifient des contenus spécifiques.

Et si elle dispose de ressources informatives, nous devons comprendre leur fonction dans l’ensemble.

Le résultat est une première carte de pages possibles.

Cette carte permet de commencer la recherche avec une référence issue de l’entreprise.

Mais elle peut encore changer.

Une page initialement prévue peut se révéler inutile.

Ou nous pouvons découvrir un besoin important auquel nous n’avions pas pensé.

Précisons que ce plan de site fonctionnel diffère du sitemap XML utilisé en SEO technique.

Le premier est un instrument de planification, mais un diagramme de pages ne couvre pas toutes les décisions d’architecture. [3]

Le second est un fichier qui fournit aux moteurs de recherche des informations sur les URL du site dont nous voulons faciliter la découverte. Son existence ne garantit pas que toutes ces pages seront explorées ou indexées. [4]

2. Étude de la demande : confronter les hypothèses au marché

Nous devons maintenant vérifier comment les personnes cherchent les services, les produits ou les connaissances liés à notre entreprise.

Nous pouvons utiliser des outils de recherche SEO, des informations issues de recherches réelles, les données du site existant et les connaissances apportées par le contact direct avec les clients.

La finalité n’est pas d’accumuler des milliers de mots-clés.

Elle est de comprendre les besoins qui apparaissent, leur expression et les opportunités qui peuvent être pertinentes.

La recherche peut aussi montrer des différences territoriales, des variations de langage ou des requêtes auxquelles nous n’avions pas pensé initialement.

Mais nous devons interpréter ces données avec prudence.

Une même expression peut avoir plusieurs sens et un volume élevé ne démontre pas à lui seul une intention d’achat.

Nous devons aussi observer le type de résultats affichés pour les requêtes étudiées.

Si une recherche renvoie principalement des guides et des cartes d’itinéraires, ses utilisateurs attendent peut-être des informations pour organiser une excursion seuls.

Si les pages d’entreprises proposant des expériences guidées dominent, l’intention commerciale peut être différente.

Ces observations ne remplacent pas une recherche complète, mais apportent du contexte.

3. Carte des intentions : comprendre la réponse nécessaire

Une fois les recherches pertinentes identifiées, nous devons comprendre ce que chaque personne tente d’obtenir.

Certaines veulent apprendre.

D’autres souhaitent comparer les options.

D’autres encore cherchent à localiser un service, connaître ses conditions ou effectuer un achat.

L’intention de recherche aide à décider quel type de réponse préparer.

Par exemple :

« Quelle est la difficulté d’un parcours en vélo électrique » peut représenter un besoin d’information.

« Excursion guidée en e-bike Val d’Aran » peut exprimer un intérêt pour un service précis.

« Réserver un parcours guidé en vélo électrique » indique une intention d’achat plus explicite.

Mais ces classifications sont des hypothèses initiales.

Nous devons les confronter aux résultats de recherche, à l’offre et au comportement réel des utilisateurs lorsque nous disposerons d’informations.

L’essentiel est de comprendre que toutes les requêtes n’exigent pas le même contenu.

Une bonne architecture doit offrir des réponses adaptées aux différentes situations du client.

4. SEOMap : décider quelle page répondra

Le SEOMap est l’instrument avec lequel nous organisons les groupes de recherches, leurs intentions et les pages qui devront y répondre.

Sa fonction principale est d’éviter de construire le site comme une accumulation de contenus déconnectés.

Nous pouvons trouver plusieurs expressions qui représentent pratiquement le même besoin.

Dans ce cas, une seule page bien développée peut peut-être y répondre correctement.

Nous pouvons aussi identifier des besoins différents qui méritent des pages indépendantes.

Le SEOMap permet d’attribuer une page principale responsable de chaque groupe d’intentions et d’établir quelles autres pages peuvent la soutenir ou la compléter.

Il est important de ne pas confondre cette responsabilité thématique avec la canonicalisation technique.

En SEO, une URL canonique est la version que Google sélectionne comme représentative lorsqu’il identifie des pages dupliquées ou très similaires. Nous pouvons communiquer une préférence par des mécanismes comme rel="canonical", mais Google prend sa propre décision. [5]

Attribuer une page principale à une intention de recherche est une décision d’architecture et de contenus, pas une instruction technique de canonicalisation.

Cette distinction permet d’utiliser chaque notion correctement.

5. Architecture finale : organiser le système complet

Avec la stratégie, la recherche et les décisions du SEOMap, nous pouvons consolider la structure.

Nous définissons maintenant les pages qui feront partie du site, leurs fonctions et leurs relations.

Nous pouvons aussi établir leurs adresses, leurs hiérarchies, la navigation principale, les regroupements de contenus et les liens internes pertinents.

À ce stade, nous distinguons différents niveaux :

L’architecture établit l’organisation conceptuelle de l’information.

La navigation permet aux personnes de trouver les pages.

Les URL identifient les adresses publiées.

Le maillage interne relie les contenus connexes et facilite les parcours entre eux.

Ces éléments doivent être cohérents, mais ne sont pas identiques.

Une page peut, par exemple, faire partie de l’espace des activités sans nécessiter obligatoirement une URL à plusieurs niveaux de dossiers.

L’essentiel est que la structure soit compréhensible et que les adresses soient claires et faciles à maintenir.

Nous pouvons désormais représenter l’ensemble par un plan qui servira de référence pour les phases suivantes.

Mais une question importante reste ouverte :

Comment tout ce travail se traduit-il en un site concret ?

Voyons-le à travers un exemple.

4. Exemple pratique : concevoir l’architecture d’une entreprise d’expériences de montagne

Imaginons une petite entreprise du Val d’Aran qui organise des excursions guidées et des activités de nature.

Son site actuel possède une structure simple :

Accueil · Activités · À propos · Contact

La page Activités présente tous les services à l’aide de photos, de textes courts et de plusieurs boutons de contact.

L’entreprise veut renouveler son site parce qu’elle estime que ses expériences ne sont pas suffisamment différenciées et qu’il est difficile de trouver des informations sur chacune.

Sa première idée consiste à moderniser le design.

Mais nous devons d’abord vérifier si la structure actuelle répond correctement aux besoins de l’entreprise et de ses clients.

Cet exemple est entièrement illustratif. Les recherches, l’offre et les décisions proposées ne proviennent pas d’une étude réelle et ne représentent pas les résultats d’un projet de PhiStudio.

Étape 1. Nous comprenons l’offre et les objectifs

Pendant l’analyse, nous identifions deux activités principales :

Randonnée guidée. Excursions accompagnées par des professionnels, avec différents parcours et niveaux de difficulté.

Parcours guidés en vélo électrique. Expériences organisées pour découvrir le territoire à vélo électrique.

L’entreprise organise aussi certaines sorties privées pour les groupes.

Mais nous ignorons encore si ces expériences privées justifient une activité commerciale indépendante ou représentent simplement une modalité de réservation des activités principales.

C’est une question à étudier.

Nous devons aussi connaître les objectifs de l’entreprise.

Supposons qu’elle souhaite augmenter les réservations directes et réduire le temps consacré à répondre sans cesse aux mêmes questions.

Cela signifie que l’architecture devra remplir deux fonctions.

D’une part, aider à découvrir et à comprendre les expériences.

D’autre part, permettre aux clients de trouver suffisamment d’informations pour décider et réserver.

Nous avons déjà un point de départ beaucoup plus précis que « nous avons besoin d’un site moderne ».

Étape 2. Nous construisons la première carte de pages

À partir de l’offre, nous pourrions proposer une structure initiale :

Cette première carte provient de l’entreprise.

Nous n’avons pas encore suffisamment étudié la demande.

Nous ne devrions donc pas la considérer comme définitive.

C’est une hypothèse que nous allons vérifier.

Étape 3. Nous étudions les recherches pertinentes

Nous analysons maintenant comment les personnes intéressées pourraient rechercher ces expériences.

Par exemple :

Ces expressions sont des exemples de recherche, pas des mots-clés validés.

Nous n’affirmons pas qu’elles font toutes l’objet d’une demande significative ni qu’elles doivent être intégrées au site.

Nous devons les confronter aux outils et aux résultats de recherche.

Certaines peuvent aussi exprimer des besoins différents.

Une personne qui cherche « parcours e-bike Val d’Aran » pourrait, par exemple, vouloir trouver des itinéraires à faire seule.

Mais notre entreprise propose des excursions guidées.

Nous devons donc vérifier si cette recherche correspond réellement à notre offre.

Promettre des parcours en accès libre ou de la location de vélos n’aurait pas de sens si ces services n’existent pas.

Étape 4. Nous regroupons les intentions

Après avoir étudié les requêtes et les avoir confrontées à l’offre, nous pouvons commencer à organiser les besoins.

Imaginons que nous trouvions quatre groupes pertinents.

Groupe A. Personnes qui cherchent des excursions de randonnée guidée.

Elles doivent comprendre les parcours proposés, leur durée, leur difficulté et la manière de les acheter.

Groupe B. Personnes intéressées par des expériences guidées en vélo électrique.

Elles cherchent à connaître les caractéristiques de l’activité, les prérequis et les disponibilités.

Groupe C. Familles qui doivent vérifier si une activité convient à leurs enfants.

Leurs questions peuvent apparaître aussi bien dans le contexte de la randonnée que dans celui du vélo.

Groupe D. Personnes souhaitant des informations sur les itinéraires et les activités avant de décider quoi faire à destination.

Elles peuvent avoir besoin de contenus informatifs sans intention d’achat immédiate.

Ces groupes ne doivent pas automatiquement devenir quatre pages.

Nous devons d’abord vérifier quelles réponses ils partagent et lesquelles nécessitent une explication propre.

Étape 5. Nous décidons quelles pages créer et lesquelles écarter

Imaginons que l’étude confirme que la randonnée guidée et les expériences en e-bike représentent deux offres différenciées, avec des demandes et des processus de choix suffisamment distincts.

Il serait alors pertinent de créer deux pages de service.

Chacune pourra expliquer son activité, montrer des preuves et faciliter la réservation.

Mais que faire des expériences familiales ?

Nous pourrions créer une page spécifique pour chaque combinaison :

Randonnée familiale.

Randonnée facile pour enfants.

Excursions de montagne pour les familles.

Parcours familiaux à vélo.

Activités faciles pour enfants.

Cela pourrait toutefois multiplier les pages aux contenus très proches.

Nous devons étudier l’offre réelle plutôt que décider selon les variations de mots-clés.

Si les expériences familiales ne constituent pas des services indépendants, il est peut-être plus utile d’intégrer des informations spécifiques dans les pages correspondantes.

La page de randonnée pourrait, par exemple, indiquer quels itinéraires conviennent à certains âges, à condition que l’entreprise puisse confirmer ces informations.

La page d’e-bike pourrait expliquer ses prérequis et ses limites pour les jeunes participants.

Et un contenu informatif pourrait aider les familles à comprendre les facteurs à considérer avant de choisir une activité.

Pensons maintenant aux expériences privées.

S’il existe une proposition différenciée, avec des caractéristiques, des conditions et une demande propres, développer une page spécifique peut être pertinent.

Mais s’il s’agit uniquement d’une option de réservation des excursions habituelles, l’expliquer dans chaque service peut suffire.

La décision dépend de la différence réelle entre les offres et les besoins des personnes qui les cherchent, au-delà des seuls mots utilisés.

Étape 6. Nous construisons une architecture provisoire

Après ces décisions, nous pourrions aboutir à la structure suivante :

ACCUEIL

ACTIVITÉS

• Randonnée guidée
• Parcours guidés en e-bike
• Expériences privées (si la recherche justifie une offre indépendante)

À PROPOS

• Équipe et expérience

RESSOURCES

• Comment choisir une excursion de montagne en famille
• Conseils pour effectuer un parcours guidé en e-bike

CONTACT

Cette représentation montre une organisation conceptuelle. Elle ne signifie pas que toutes les pages doivent apparaître dans le menu principal ni que les rubriques regroupées doivent être reproduites littéralement dans les URL.

Elle ne constitue pas non plus une recommandation définitive pour une entreprise réelle.

C’est le résultat illustratif de décisions d’architecture.

L’étape suivante serait de définir leurs relations.

Étape 7. Nous relions les pages au sein d’un parcours

Imaginons qu’une famille arrive depuis Google sur un article expliquant comment choisir une excursion de montagne adaptée aux enfants.

L’article répond à ses questions sur la difficulté, la durée, la préparation et les points à vérifier.

Lorsque c’est pertinent, il peut présenter les expériences guidées proposées par l’entreprise et renvoyer vers sa page de randonnée.

La famille y trouvera les activités disponibles, leurs caractéristiques, les conditions et un moyen de se renseigner ou de réserver.

Nous n’avons pas obligé l’utilisateur à commencer par l’accueil.

Nous n’avons pas non plus transformé l’article informatif en page publicitaire.

Chaque élément remplit une fonction.

La ressource informe.

La page de service explique une proposition concrète.

Le système de réservation facilite l’achat.

Et les liens permettent à la personne d’avancer lorsqu’elle trouve une option pertinente.

C’est une architecture au service du parcours client.

Étape 8. Nous définissons les pages avant de les dessiner

Enfin, chaque page importante a besoin d’une définition fonctionnelle.

Par exemple :

Cette fiche permet déjà d’orienter le travail ultérieur.

Le designer connaît la fonction de la page.

La personne qui rédige sait quelles informations expliquer.

Le développeur peut comprendre les fonctionnalités nécessaires.

Et le responsable de la mesure sait quelles actions pertinentes il devra observer.

Nous n’avons pas encore créé la page.

Mais nous avons déjà résolu une part considérable des décisions qui conditionnent son utilité.

5. Quand créer une nouvelle page et quand s’en passer

L’une des décisions les plus importantes en architecture web consiste à déterminer quels besoins méritent une page indépendante.

Il n’existe pas de règle universelle.

Une question peut trouver sa réponse dans une section, une page de service, un guide informatif ou une ressource existante.

Il se peut aussi qu’il ne soit pas pertinent de développer un contenu pour y répondre.

Quand une page propre apporte de la valeur

Créer une page indépendante peut être justifié lorsqu’il existe une offre clairement différenciée, un besoin précis ou une réponse qui nécessite suffisamment de profondeur.

Une entreprise qui propose de la randonnée guidée et du canyoning aura, par exemple, probablement besoin d’expliquer ces services séparément.

Les activités présentent des caractéristiques, des conditions, des risques et des décisions d’achat différents.

Les regrouper uniquement dans une page générique pourrait rendre les deux plus difficiles à comprendre.

Mais cette conclusion doit être confrontée à l’offre réelle et à la manière dont les utilisateurs cherchent l’information.

Quand une section suffit

Dans d’autres cas, une question peut trouver une réponse adaptée au sein d’une page existante.

Imaginons que les clients veuillent savoir si les excursions acceptent les animaux.

Si la réponse dépend de chaque activité, il sera peut-être plus utile d’inclure cette information dans les pages de service respectives.

Nous n’avons pas besoin de créer automatiquement une page indépendante intitulée « Excursions avec un chien ».

Cela ne serait pertinent que s’il existe une proposition différenciée ou un besoin d’information justifiant une réponse plus approfondie.

Quand créer un contenu d’appui

Certaines recherches n’expriment pas une intention d’achat immédiate.

Mais elles peuvent représenter des questions pertinentes dans le parcours de nos clients.

Un guide sur la préparation d’une excursion en montagne peut aider les personnes qui envisagent encore différentes activités.

Ce contenu peut remplir une fonction informative propre et être relié aux services correspondants.

Il n’a pas besoin de devenir une page commerciale déguisée.

Sa valeur réside dans la réponse correcte à un besoin.

Google recommande de privilégier des contenus utiles et fiables pour les personnes, plutôt que de produire des pages principalement destinées à manipuler la visibilité dans les résultats de recherche. [6]

Quand nous ne devrions rien créer

Nous devons aussi reconnaître les recherches qui sortent de notre proposition.

Il peut exister une demande pour un service que nous ne proposons pas, une question à laquelle nous ne pouvons pas répondre avec rigueur ou un contenu dont l’entretien serait disproportionné.

Dans ces situations, décider de ne pas créer de page peut être parfaitement raisonnable.

Une architecture bien conçue se reconnaît aussi aux pages qu’elle a décidé de ne pas construire.

Le problème des pages trop similaires

La notion de cannibalisation SEO intervient ici.

En pratique, nous craignons que plusieurs pages de notre site tentent de répondre de manière presque identique à un même besoin et finissent par se chevaucher sans apporter de différenciation utile.

Mais nous devons éviter une interprétation trop simplifiée.

Le fait que deux pages apparaissent pour une même recherche ne signifie pas automatiquement qu’il existe un problème.

Un guide informatif et une page commerciale peuvent partager des termes tout en répondant à des besoins différents.

Ils peuvent aussi se compléter par des liens internes.

L’essentiel est de rechercher s’il existe un chevauchement nuisible.

Si deux pages offrent pratiquement la même réponse, il est peut-être préférable de les fusionner.

Si elles répondent à des besoins différents, il peut être préférable de les spécialiser et de clarifier leurs fonctions.

Et si une page apporte des informations complémentaires, elle peut être conservée comme contenu d’appui.

L’objectif n’est pas d’empêcher différentes pages de partager des mots-clés. Il est d’éviter les doublons inutiles et de faire en sorte que chacune apporte une valeur identifiable.

6. Comment relier les pages : hiérarchie, navigation et liens internes

Une architecture ne s’achève pas lorsque nous décidons quelles pages le site comportera.

Nous devons aussi définir leurs relations.

Cette organisation permet aux personnes de trouver des informations, de comprendre où elles sont et de poursuivre vers des contenus pertinents.

La hiérarchie organise les connaissances

La hiérarchie établit les grands espaces qui existent et les contenus qui en font partie.

Une entreprise peut, par exemple, disposer d’un espace général d’activités qui organise différentes expériences.

Cette relation permet de comprendre comment son offre est structurée.

Mais toutes les pages connexes ne doivent pas dépendre visuellement ou techniquement d’une même chaîne de dossiers.

La hiérarchie est une décision conceptuelle.

La navigation facilite l’accès

Le menu principal doit permettre de s’orienter vers les espaces les plus importants.

Il n’a pas besoin de montrer toutes les pages existantes.

Nous pouvons utiliser des menus secondaires, des liens contextuels, des catégories ou des composants spécifiques pour faciliter d’autres parcours.

Le choix dépend de la complexité du site et des besoins de ses utilisateurs.

Un menu avec peu d’options ne démontre pas automatiquement l’existence d’une bonne architecture.

Un menu avec beaucoup d’options ne signifie pas non plus nécessairement qu’il est mal conçu.

L’essentiel est que les personnes puissent trouver ce dont elles ont besoin sans être confrontées à une organisation confuse.

Les liens internes relient des besoins connexes

Le maillage interne permet de relier les pages qui apportent des informations complémentaires.

Un guide sur les excursions familiales peut, par exemple, renvoyer vers les activités adaptées.

Une page de service peut renvoyer vers les conditions de réservation.

Et une rubrique générale peut présenter les différentes offres.

Ces liens aident les personnes à poursuivre leur parcours et permettent aux moteurs de recherche de découvrir les pages et de comprendre les relations au sein du site.

Google souligne l’importance de rendre les contenus pertinents accessibles par des liens explorables. [2]

Les liens doivent toutefois correspondre à des relations réelles.

Nous n’avons pas besoin de relier toutes les pages entre elles simplement pour augmenter le nombre de liens internes.

Le fil d’Ariane aide à s’orienter

Les breadcrumbs, ou fils d’Ariane, sont des éléments qui montrent un parcours de navigation ou une position dans le site.

Par exemple :

Accueil → Activités → Parcours guidés en e-bike

Ils peuvent être utiles lorsqu’il existe différentes catégories et différents niveaux.

Ils aident à comprendre le contexte d’une page et facilitent le retour vers des espaces plus généraux.

Mais ils ne remplacent pas une bonne structure et ne sont pas obligatoires sur toutes les pages.

Leur utilité dépend du site.

Vérifier si les personnes trouvent ce dont elles ont besoin

L’architecture ne devrait pas être validée uniquement parce qu’un diagramme paraît logique aux personnes qui y ont travaillé.

Il est utile de la confronter aux utilisateurs.

Nous pouvons demander à une personne de trouver les conditions d’une activité ou d’indiquer où elle se renseignerait sur une expérience pour les familles.

Si elle ne sait pas où chercher, il existe peut-être un problème dans les noms des rubriques, la classification des contenus ou la navigation.

Des techniques comme les tests d’arborescence (tree testing) permettent d’évaluer la capacité à trouver des informations dans une structure, sans que le design visuel influence le test.

D’autres tests peuvent aider à identifier les difficultés dans les éléments de navigation.

Nielsen Norman Group décrit différentes méthodes pour distinguer les problèmes d’organisation des contenus des problèmes d’interface. [7]

Tous les sites n’ont pas besoin d’une étude approfondie.

Mais même une vérification simple avec des personnes qui ne connaissent pas la structure peut révéler des difficultés importantes avant de développer toutes les pages.

L’architecture doit être compréhensible pour la personne qui utilise le site, au-delà de celle qui le construit.

7. Un nouveau site et un site existant ne partent pas du même point

Jusqu’ici, nous avons utilisé l’exemple d’une entreprise qui doit réorganiser sa présence digitale.

Mais il existe une différence importante entre construire un nouveau site et renouveler un site publié depuis des années.

Dans les deux cas, nous devons comprendre l’entreprise, étudier la demande et définir une architecture cohérente.

Ce qui change, ce sont les informations de départ.

Lorsque nous construisons un nouveau site

Nous partons principalement des connaissances sur l’entreprise, son offre, ses clients et de l’étude du marché.

Nous ne disposons pas encore d’un site propre dont nous pourrions analyser les résultats.

Une partie de nos décisions reposera donc sur des hypothèses fondées.

Nous devons étudier ce que les personnes cherchent, comment d’autres entreprises y répondent et quelle structure peut le mieux satisfaire ces besoins.

Nous construirons ensuite les actifs et commencerons à observer leur comportement réel.

L’architecture initiale doit être assez solide pour orienter le développement, tout en permettant des ajustements lorsque nous disposerons de nouvelles informations.

Lorsque nous renouvelons un site existant

Une responsabilité supplémentaire apparaît ici.

Le site peut avoir accumulé de la valeur pendant des années.

Il possède peut-être des pages recevant des visites pertinentes, des contenus vers lesquels d’autres sites font des liens ou des URL qui génèrent des demandes commerciales.

Il peut aussi contenir des informations utiles aux clients qui connaissent déjà ces adresses.

Même si le design est ancien, cela ne signifie pas que toute la structure précédente doit disparaître.

Un site existant n’est pas une page blanche. C’est un ensemble d’actifs dont nous devons comprendre l’histoire.

Exemple : renouveler un site sans détruire sa valeur

Imaginons qu’une entreprise possède quinze pages de services, d’activités et de destinations.

Le nouveau design propose de simplifier la navigation et de les réduire à six.

Visuellement, cela peut sembler une amélioration.

Mais nous devrions d’abord étudier ce qui arrive aux neuf pages qui disparaîtraient.

Certaines sont peut-être pratiquement identiques et méritent d’être fusionnées.

D’autres peuvent répondre à des recherches très précises et mériteraient d’être conservées.

Nous pourrions aussi découvrir des pages qui doivent être actualisées, mais dont la fonction reste importante.

C’est pourquoi un renouvellement doit intégrer un inventaire des actifs existants.

Nous devons connaître leurs contenus, leurs URL, leurs liens pertinents, leur comportement et leur contribution à l’entreprise, dans la mesure où nous disposons de données.

Nous pourrons ensuite décider ce qu’il faut conserver, améliorer, fusionner ou retirer.

Ce qui se passe lorsque les URL changent

Modifier une adresse peut avoir des conséquences.

Une page peut recevoir des liens depuis d’autres sites ou être enregistrée dans les favoris des utilisateurs.

Si elle disparaît sans alternative adaptée, ces personnes pourraient rencontrer une erreur.

Nous pouvons aussi rendre plus difficile pour les moteurs de recherche l’identification du nouvel emplacement du contenu.

C’est pourquoi les migrations nécessitent une planification.

Lorsqu’il existe une nouvelle page équivalente, il peut être approprié de mettre en place une redirection permanente depuis l’ancienne adresse.

Google recommande d’utiliser des redirections permanentes côté serveur, comme 301 ou 308, pour les déplacements définitifs d’URL, ainsi que de préparer les correspondances et de surveiller la migration. [8]

Mais nous ne devons pas rediriger sans discernement toutes les pages supprimées vers l’accueil.

Nous devons évaluer chaque cas et offrir une destination pertinente lorsqu’elle existe.

Il peut aussi être correct de retirer un contenu devenu inutile, sans forcer une équivalence artificielle.

L’objectif est de protéger l’expérience des personnes et de préserver, autant que possible, la valeur utile existante.

La modernisation ne devrait pas commencer par détruire

Ce principe rejoint directement la direction des actifs digitaux.

Lorsqu’une entreprise décide de renouveler son site, nous ne devrions pas considérer tout ce qui précède comme un problème à faire disparaître.

Nous devons d’abord reconnaître ce qui fonctionne.

Nous déciderons ensuite de ce qu’il faut améliorer.

Une nouvelle architecture peut nécessiter des changements profonds, mais devrait les justifier par des critères d’entreprise, d’expérience et de SEO.

Renouveler un site ne consiste pas nécessairement à repartir de zéro. Il s’agit de construire une meilleure version à partir des connaissances et des actifs dont nous disposons déjà.

8. Ce qui doit être prêt avant de concevoir et de construire

Une fois l’architecture définie, nous devons la transformer en une référence utilisable par les personnes chargées du design, des contenus et du développement.

Livrer un beau diagramme ne suffit pas.

Nous devons conserver les décisions qui justifient la structure.

Dans un projet professionnel, ce plan peut se composer de différents instruments de travail.

La carte des pages

Elle permet de visualiser les pages du site, leurs regroupements et leurs relations principales.

Elle n’a pas besoin de reproduire exactement le menu ni la structure technique des URL.

Son but est de représenter l’organisation du système.

L’étude de la demande et le SEOMap

Ils documentent les besoins identifiés, leur expression dans les recherches et les pages attribuées pour y répondre.

Ils permettent de comprendre pourquoi une page a été proposée et quelle fonction elle devra remplir.

Ils aident aussi à éviter que de nouveaux contenus reproduisent inutilement ceux qui existent déjà.

Les fiches fonctionnelles

Elles définissent les responsabilités de chaque page importante.

Elles peuvent inclure son public, son intention principale, les informations nécessaires, les preuves, les actions et les relations avec les autres rubriques.

Leur utilité consiste à orienter le travail sans décider prématurément de tous les aspects du design.

Les décisions de navigation et de maillage

Elles établissent comment les personnes pourront s’orienter et quelles relations doivent être rendues accessibles.

Elles permettent d’identifier les contenus principaux, les regroupements et les liens pertinents.

L’inventaire et les décisions de migration

Lorsqu’un site précédent existe, nous devons documenter les pages conservées, celles qui changent, les contenus fusionnés et les URL nécessitant une intervention technique.

Cela évite que l’équipe de développement ait à interpréter seule le sort des actifs existants.

Les exigences de construction

Enfin, il est utile d’identifier les conditions qui affecteront le design et le développement.

Par exemple, les fonctions de réservation, les informations requises, les comportements de navigation, les besoins d’indexation ou les actions à observer avec des outils de mesure.

Tous ces éléments n’auront pas la même profondeur dans chaque projet.

Un site simple peut nécessiter une documentation beaucoup plus compacte qu’une plateforme de plusieurs centaines de pages.

L’essentiel est que les décisions fondamentales soient explicites.

La valeur du plan ne se mesure pas à la quantité de documents produits. Elle se mesure aux décisions qu’il permet de prendre sans improviser.

Le design, les contenus et le développement ont besoin d’une référence partagée

Le design doit transformer la structure en une expérience visuelle compréhensible.

Les contenus doivent répondre aux intentions et aux besoins identifiés.

Le développement doit mettre en œuvre les pages, les relations et les fonctionnalités prévues.

Et le SEO technique doit vérifier que les moteurs de recherche peuvent accéder aux contenus destinés à être découverts et les interpréter correctement.

Chaque discipline apporte ses propres connaissances.

L’architecture ne prétend pas remplacer ce jugement professionnel.

Mais elle permet au travail de partir de décisions partagées.

Imaginons que, pendant la rédaction, nous découvrions que deux pages prévues expliquent pratiquement la même offre.

Nous devrons peut-être revoir leur différenciation.

Ou qu’un test de navigation montre que les personnes ne comprennent pas une catégorie.

Nous pouvons la changer.

L’architecture doit pouvoir évoluer lorsque de nouveaux éléments apparaissent.

La différence est que nous savons désormais quelle décision nous modifions et quelles conséquences cela peut avoir sur l’ensemble.

Le plan n’élimine pas la créativité. Il lui donne une direction et permet d’évaluer ses propositions avec davantage de discernement.

9. Une architecture préparée à évoluer

La manière dont les personnes trouvent et utilisent l’information digitale change.

Les moteurs de recherche intègrent de nouvelles expériences de consultation et les outils d’intelligence artificielle participent de plus en plus aux tâches de recherche, de comparaison et de travail.

Certains systèmes peuvent consulter les informations publiées sur un site et les utiliser pour répondre à des questions ou aider à réaliser certaines actions.

Cela ajoute de nouvelles possibilités, mais ne change pas un besoin fondamental.

Les entreprises doivent toujours présenter correctement leurs services, expliquer leurs conditions et maintenir des informations cohérentes et actualisées.

L’information doit être compréhensible et vérifiable

Reprenons notre entreprise d’expériences de montagne.

Une personne doit savoir quelles activités elle propose, où elles ont lieu, quelles sont leurs conditions et comment les acheter.

Ces mêmes caractéristiques peuvent aussi être pertinentes pour les systèmes digitaux capables d’accéder aux informations et de les interpréter.

Une architecture cohérente aide à les organiser.

Mais elle ne garantit pas qu’un moteur de recherche, un assistant ou un agent externe découvrira le site, utilisera ses contenus ou recommandera l’entreprise.

Ces résultats dépendent de multiples facteurs, dont les mécanismes d’accès et de fonctionnement de chaque plateforme.

Lorsque c’est approprié, nous pouvons compléter une bonne architecture par des données structurées, des informations lisibles par machine et des mécanismes techniques d’accès.

Mais ces outils ne remplacent ni la qualité ni la véracité du contenu.

Ils ne transforment pas non plus automatiquement un site en système capable de recevoir des réservations par des agents.

Ce sont des capacités différentes à étudier selon les besoins de l’entreprise.

Construire pour l’entreprise, au-delà de l’outil à la mode

Une entreprise peut changer de gestionnaire de contenus, renouveler son design ou intégrer de nouvelles formes d’interaction.

Mais ses services, ses clients et ses besoins fondamentaux ne devraient pas être entièrement redéfinis à chaque changement de technologie.

C’est pourquoi il est utile de séparer les décisions d’architecture des outils utilisés pour les mettre en œuvre.

Une structure cohérente peut servir de référence pour développer un site avec différentes technologies.

Elle peut aussi faciliter son entretien, son évolution et l’ajout de nouvelles fonctionnalités.

Cela ne signifie pas que tout changement technologique sera simple.

Cela signifie que nous conservons les connaissances nécessaires pour comprendre ce que nous avons construit et pourquoi.

Une bonne architecture ne devrait pas dépendre exclusivement de l’outil avec lequel le site a été développé. Elle doit représenter la logique de l’entreprise et les besoins des personnes.

10. Le plan avant de construire

Un site peut être visuellement séduisant, techniquement rapide et développé avec des outils modernes.

Mais si sa structure ne répond pas aux besoins de l’entreprise et de ses clients, il conservera des limites importantes.

Un meilleur design, davantage de trafic ou davantage de pages ne corrigent pas à eux seuls une structure qui répond mal aux besoins de l’entreprise.

L’architecture permet d’aborder ces questions avant d’engager une part importante de l’investissement.

Elle nous aide à comprendre les pages dont l’entreprise a réellement besoin, la demande à laquelle elles devraient répondre et leurs relations.

Elle permet aussi de protéger les actifs existants et d’éviter des constructions inutiles.

Mais sa principale valeur ne réside pas dans la production d’un plan de site ou d’une liste d’URL.

Elle réside dans la transformation des connaissances stratégiques et de l’étude de la demande en décisions utilisables pendant le design, la rédaction et le développement.

Un site ne devrait pas commencer par la question du nombre de pages à construire. Il devrait commencer par la compréhension de ce que l’entreprise doit résoudre et de la manière d’organiser les réponses attendues par ses clients.

Avec ce plan, le design, les contenus et le développement peuvent avancer à partir de décisions partagées, révisables lorsque de nouveaux éléments apparaissent. Cela ne garantit pas que tout fonctionnera dès le premier jour ; cela réduit l’improvisation et permet d’apprendre sans perdre la direction.