EditoRelayOuvrir EditoRelay

Blog

Recherche interne : aider les lecteurs à retrouver un article

Un lecteur se souvient d’un article sur la fermeture d’une ligne de bus, mais pas de son titre. Il ouvre le site du média et saisit le nom du quartier. Dans ce parcours fictif, la diffusion a déjà fait son travail : le lecteur connaît le sujet et veut revenir au texte. Reste à le retrouver. La recherche interne prend le relais du lien perdu, avec une difficulté que la rédaction connaît mal lorsqu’elle teste seulement les titres exacts de ses articles. Quelques essais préparés à partir de destinations connues permettent de voir où ce retour se complique.

Préparer des recherches avec de vraies destinations attendues

Avant de changer le moteur, la rédaction peut réunir quelques articles qu’elle souhaite pouvoir retrouver. Pour chacun, elle note des formulations plausibles : le nom du lieu, celui de l’organisme concerné, un sujet décrit avec des mots courants. Le titre exact constitue un cas utile, mais trop facile s’il est le seul testé. Le lecteur n’a généralement pas sous les yeux les mots choisis par la rédaction.

Dans notre exemple de transport, « bus quartier nord », le nom de la ligne et celui de l’arrêt peuvent correspondre à des recherches différentes. L’équipe doit d’abord vérifier ce que l’article contient réellement. Si le quartier n’est jamais nommé, l’absence du résultat n’a pas le même sens que si le titre exact ne renvoie rien. Le relevé doit conserver cette distinction.

Un petit tableau de travail suffit : expression saisie, page attendue, résultat observé, difficulté rencontrée. Les cas peuvent mêler un article récent et plusieurs archives. L’objectif est de rendre les essais reproductibles. Un collègue qui reprend le dossier doit pouvoir lancer la même recherche et constater si le problème subsiste.

Les messages reçus par la rédaction peuvent fournir des formulations utiles, à condition de ne pas les transformer en statistiques d’audience. Une demande isolée révèle une difficulté possible ; elle ne mesure pas sa fréquence. Les exemples préparés par l’équipe restent eux aussi des hypothèses de test, explicitement distinguées des usages réellement observés.

Le relevé sert surtout à localiser l’échec. La personne ne trouve parfois même pas le champ. Ailleurs, elle lance la recherche mais ne reconnaît pas le bon article parmi les réponses. Entre ces deux moments, le moteur peut aussi avoir écarté la page attendue. Modifier son classement ne résoudrait que certains de ces problèmes.

Rendre le champ identifiable dans les parcours ordinaires

WordPress propose un bloc Recherche que l’on peut insérer dans une page ou un article. Sa documentation décrit notamment le libellé, le texte indicatif et différentes présentations du bouton. Documentation du bloc Recherche. Le choix du bon emplacement dépend ensuite du thème et de la navigation du média.

Le test commence depuis une page ordinaire, pas depuis l’écran où l’éditeur vient de placer le bloc. Une personne arrivant directement sur un article doit pouvoir comprendre comment chercher autre chose sur le site. Sur mobile, il faut notamment vérifier ce qui se passe dans le menu et si le champ reste utilisable lorsque le clavier apparaît.

Un libellé comme « Rechercher sur le site » indique clairement le périmètre. Une formulation créative peut être moins précise, surtout si elle ressemble à une invitation à poser une question à la rédaction. Le texte du champ doit correspondre au service réellement rendu : une recherche dans les contenus du média, avec les possibilités effectivement disponibles.

Le W3C recommande d’associer un libellé aux champs de formulaire pour que leur fonction soit identifiable, notamment par les technologies d’assistance. Il décrit aussi les cas où ce libellé peut être masqué visuellement tout en restant disponible dans le code. Tutoriel W3C sur les libellés de formulaire. La présence d’une loupe à l’écran ne suffit donc pas à vérifier l’accessibilité du champ.

La rédaction peut effectuer un premier parcours au clavier : rejoindre le champ, saisir une expression, lancer la recherche et poursuivre vers un résultat. Si une étape devient difficile à comprendre, le signalement doit nommer l’endroit et l’action. Ce contrôle simple aide à trouver des défauts concrets, mais il ne remplace pas un audit complet d’accessibilité.

Comprendre ce qui apparaît dans les résultats

Un article présent dans le site n’est pas nécessairement présenté comme l’équipe l’imagine dans la recherche. Le thème, les extensions et les réglages peuvent modifier les types de contenus affichés ou leur ordre. Avant d’acheter un nouveau service, la personne qui maintient WordPress doit identifier le mécanisme utilisé et reproduire les cas relevés par la rédaction.

Le test du titre exact est précieux à ce stade. Si une page publique attendue n’apparaît pas, il faut examiner son statut, son inclusion dans le périmètre et le comportement du moteur. Si elle apparaît avec son titre mais pas avec un terme présent dans le texte, la recherche porte peut-être sur un ensemble de champs plus limité que prévu. Le diagnostic dépend des vérifications sur cette installation WordPress.

La documentation WordPress sur la création d’une page de recherche propose de tester la recherche depuis la partie publique du site et de contrôler le cas sans résultat. Cette vérification extérieure à l’administration compte : la vue du lecteur est celle qui doit être évaluée, avec ses accès et ses conditions de consultation.

Le dernier incident sur la ligne de bus et le guide des horaires peuvent tous deux être des résultats pertinents. Ils répondent simplement à des besoins différents. Si le site privilégie la date, l’incident remontera peut-être devant le guide que cherchait le lecteur. L’équipe doit examiner cette règle de classement avec ses cas d’essai, puis décider si elle correspond au service qu’elle veut rendre.

Des filtres peuvent aider lorsqu’ils correspondent à une distinction comprise par le public. Une période ou une rubrique stable peut être utile ; une longue liste de catégories internes risque de compliquer la recherche. Le guide sur les catégories et étiquettes WordPress traite le classement du catalogue. La recherche doit être examinée avec ce classement, sans supposer qu’ajouter des étiquettes résoudra tous ses défauts.

Aider le lecteur à reconnaître l’article recherché

Une liste de titres presque identiques peut masquer un bon résultat. Dans une série consacrée au même chantier, « Le projet avance » ne permet pas de distinguer la consultation initiale, le vote et le début des travaux. Il faut regarder les informations visibles dans la carte : titre, date, extrait et, selon le site, rubrique ou illustration.

Dans le cas fictif de la ligne de bus, un extrait mentionnant le quartier et la période concernée aiderait à identifier le bon article. Un texte qui répète seulement le nom du média n’apporte pas cette aide. La rédaction peut vérifier ce que son thème reprend effectivement : un extrait préparé dans le CMS, un passage du texte ou une autre donnée.

Le travail sur les extraits WordPress complète ici le diagnostic. La recherche ne demande pas forcément de réécrire tous les résumés. Quelques résultats représentatifs permettent d’abord de voir si l’information utile existe déjà et si le modèle de page l’affiche. Une correction du modèle peut parfois traiter plusieurs cas à la fois.

La date doit également être intelligible. Un article ancien encore utile et une annonce dépassée ne posent pas le même problème. Le résultat peut aider à situer le contenu, mais l’ouverture de l’article doit confirmer son état. Un moteur qui retrouve parfaitement une information périmée ne remplit qu’une partie du service attendu.

Le contrôle se poursuit donc après le clic. Le lecteur arrive-t-il sur le bon article ? Comprend-il si les horaires sont actuels ? Peut-il rejoindre un dossier qui tient le sujet à jour ? La recherche interne et le maillage d’un dossier éditorial se complètent à cet endroit, sans avoir besoin de multiplier les copies d’un même contenu.

Traiter les recherches sans résultat sans inventer de réponse

Une page vide doit d’abord dire ce qui s’est passé. Le lecteur a besoin de comprendre qu’aucun résultat n’a été trouvé pour l’expression soumise et de pouvoir la modifier. Lui proposer seulement les derniers articles donne une liste à parcourir, mais ne dit pas si sa recherche a été exécutée correctement.

Le média peut proposer des pistes proportionnées à ce qu’il sait faire : essayer un nom de lieu plus court, rejoindre une rubrique, consulter un dossier existant. Ces aides doivent rester utiles et limitées. Une page sans résultat n’a pas à devenir une seconde page d’accueil remplie de contenus sans rapport avec la demande.

Une faute de frappe constitue un cas d’essai distinct. Certains outils peuvent la traiter, d’autres non ; la rédaction ne doit pas annoncer une correction automatique sans l’avoir vérifiée. Les essais peuvent ensuite porter sur les accents, les variantes de noms et les expressions composées. Leurs résultats indiqueront ce que le moteur sait retrouver ; on ne peut pas présumer qu’il comprend les synonymes.

Si l’équipe envisage une réponse générée par IA à cet endroit, elle change la nature du service. Il faudra vérifier les sources retenues, les liens fournis et la façon dont l’outil indique qu’il n’a pas trouvé d’information suffisante. Une synthèse convaincante mais fondée sur un ancien article pourrait aggraver le problème de départ. Le besoin immédiat peut souvent être traité en améliorant les résultats existants.

Choisir une correction que l’on pourra vérifier

À la fin des essais, la rédaction peut confier un problème délimité à la personne qui maintient le site : le champ se perd dans le menu mobile, telle série d’articles manque, ou les cartes ne permettent pas de distinguer les réponses. Ce relevé change la discussion. On ne cherche plus un « meilleur moteur » en général, mais une correction dont on pourra constater l’effet.

Une fois la correction faite, les expressions de départ servent à la vérifier. L’équipe peut ajouter quelques cas voisins pour éviter qu’un réglage favorable à une rubrique ne dégrade les autres. Il n’est pas nécessaire de refaire tout le catalogue à chaque essai ; il faut surtout garder les cas qui ont révélé les difficultés et documenter le résultat attendu.

Si des statistiques de recherche interne sont déjà disponibles, elles peuvent compléter cette observation. Une absence de clic ne prouve pas, seule, que le lecteur a échoué ; un clic ne prouve pas qu’il a trouvé sa réponse. Les données doivent être rapprochées du parcours et interprétées dans le cadre de mesure prévu par le média, sans ajouter une collecte détaillée par simple réflexe.

Enfin, les requêtes saisies dans le site ne sont pas celles de Google Search Console. Elles renseignent un autre moment de lecture, auprès de personnes déjà présentes sur le média. Améliorer ce parcours peut faciliter l’accès aux archives, mais ne garantit aucun classement dans Google. Le premier résultat à rechercher est plus concret : une personne retrouve le bon article, reconnaît sa date et comprend ce qu’elle peut encore en utiliser.

Sources officielles

Documents utilisés pour vérifier les points techniques de cet article.

Tester EditoRelay avec votre média

Créez votre espace, ajoutez le site du média, puis choisissez les comptes et les règles de publication utiles à votre rédaction.

Ouvrir EditoRelay