Recherche interne Webflow : choisir une solution et préparer la recette

Une recherche interne Webflow doit aider un visiteur à retrouver un contenu ou à poursuivre une tâche. Avant de choisir une solution, définissez ce qui doit être recherché : articles, ressources, réalisations, pages de services ou documentation. Un champ de saisie peut sembler fonctionner tout en cherchant dans une partie seulement de ce corpus.

Ce guide distingue recherche native, filtres et moteur tiers. Il propose un corpus fictif et douze situations de recette avec leurs résultats attendus. Ce sont des exigences à tester, pas les résultats d’un benchmark : aucun essai de moteur natif ou tiers n’est présenté comme exécuté.

Quel contenu vos visiteurs doivent-ils retrouver ?

Partez d’une tâche concrète : retrouver une procédure de migration, sélectionner les ressources d’une catégorie ou vérifier une réalisation comparable. Demandez ensuite où se trouve la réponse et comment le lecteur la nomme. La solution dépend de cette relation entre le besoin, les contenus et leur vocabulaire.

Définissez le corpus public dans un inventaire court : types de contenus, langues, champs utiles, destination de chaque résultat et contenus exclus. Distinguez une page accessible par son URL, un article stocké dans le CMS et un fichier externe. Leur présence dans une interface ne prouve pas qu’ils seront tous recherchés de la même manière.

Pour chaque type, choisissez le titre et le résumé qui aideront à reconnaître le bon résultat. Identifiez aussi les éléments qui ne doivent pas rendre toutes les pages pertinentes : navigation répétée, mentions de pied de page et listes de liens sans rapport avec le sujet principal.

Écrire les réponses attendues avant le test

Préparez quelques tâches à partir des questions des visiteurs et de vos contenus réels. Associez une requête à un document attendu, expliquez pourquoi il est pertinent et dites ce qui serait un échec. Pour une catégorie, la bonne réponse peut être une liste filtrée plutôt qu’un classement textuel.

Décidez aussi de ce qui est indispensable. Retrouver une page par son titre peut être nécessaire ; comprendre un synonyme métier peut l’être pour une autre audience. Une fonction confortable mais peu utile ne doit pas imposer seule une solution plus complexe. Les attentes ne doivent toutefois pas être abaissées après un échec pour déclarer le test réussi.

Recherche native, filtres ou moteur tiers : quelle fonction manque réellement ?

La recherche native pour retrouver des pages du site

La documentation Webflow Site search décrit une recherche disponible avec un plan Premium, ou certains anciens plans CMS et supérieurs. Un plan éligible et une publication créant l’index sont nécessaires aux vrais résultats ; les exemples d’aperçu ne les prouvent pas.

Webflow indique également un index commun au site, des résultats liés à la locale, au plus soixante résultats sans pagination et l’absence de fonctionnement sur un site exporté. Ces limites documentées sont à confronter au corpus.

Choisissez cette piste lorsque le besoin est de retrouver des pages publiques et que sa recette convient. Ne lui attribuez pas une tolérance aux fautes, des synonymes métier ou un classement personnalisé sans les avoir vérifiés pour vos exigences.

Les filtres pour explorer une liste définie

Un filtre répond à une sélection : « montrer les ressources CMS », « afficher les réalisations de ce type ». Il s’appuie sur des champs structurés et un ensemble d’items défini. Il ne remplace pas nécessairement une recherche dans les pages de services, les articles et les ressources de plusieurs sources.

Les filtres natifs des Collection lists servent à choisir les items affichés selon des règles configurées dans Webflow. Leur présence dans le Designer ne prouve pas qu’un visiteur dispose de filtres interactifs. Pour cette interaction, vérifiez le montage effectivement retenu, ses contrôles et les données qu’il charge.

Si un script filtre uniquement les items présents dans la page, sa portée dépend de ce chargement. Demandez comment il traite les pages suivantes et les contenus absents du navigateur. Testez un item au-delà de la première page de liste avant d’annoncer une couverture complète.

Un moteur tiers pour des exigences explicites

Une solution distincte mérite d’être étudiée lorsque vous devez régler le classement, gérer un vocabulaire métier ou réunir plusieurs sources. Il faut alors définir les données transmises, leur synchronisation, l’interface et le responsable de maintenance.

À titre d’exemple documentaire, Algolia décrit une tolérance aux fautes configurable et des synonymes à paramétrer. Cela ne démontre ni leur pertinence sur votre corpus, ni l’existence d’une intégration Webflow déjà prête dans votre projet. Les fonctions utiles et les conditions du compte doivent être vérifiées avant le choix.

Comparez les solutions sur les mêmes tâches. Évitez un classement général d’outils à partir de leur seule liste de fonctionnalités : le coût de reprise, les erreurs d’indexation et la capacité de votre équipe à maintenir le système font partie de la décision.

Les critères à documenter pour décider

Corpus et couverture. Quelles sources et quelles langues sont réellement parcourues ? Les contenus d’une liste paginée ou d’un fichier externe font-ils partie du périmètre ? Demandez une trace sur un document de chaque type.

Pertinence. Quels résultats doivent apparaître pour les requêtes prioritaires ? Accents, faute et synonyme sont-ils des exigences ou des limites acceptées ? Évaluez le classement sur ces cas, avec une raison de pertinence écrite.

Exclusions et confidentialité. À quel niveau peut-on exclure un contenu ? Qui contrôle les titres, extraits et URL exposés ? Un mécanisme d’authentification doit protéger les documents privés indépendamment du moteur.

Actualisation. Quel événement alimente l’index, avec quel délai documenté ou observé ? Qui vérifie un ajout, une modification et un retrait ? Distinguez la mise à jour du CMS de celle du moteur.

Interface. Le lecteur peut-il saisir une recherche, comprendre les résultats, corriger sa demande et sortir d’une impasse au clavier comme sur mobile ? Demandez le comportement en cas d’absence de résultat et en cas de panne.

Exploitation. Notez l’abonnement ou le plan requis, les volumes à confirmer, les dépendances, la transmission à l’équipe et la possibilité de changer de solution. Ne comparez les coûts qu’après avoir fixé le périmètre ; aucun tarif d’outil n’est présumé ici.

Préparer un corpus de démonstration et sa recette

Le corpus suivant est entièrement synthétique. Les neuf fiches sont des données pédagogiques, pas des réalisations client ou des pages Gemme à créer. Dans un environnement d’essai, chaque identifiant doit désigner une destination distincte. Le titre, le texte, la catégorie, la langue et le statut ci-dessous constituent les données de référence.

Le périmètre initial public comprend D01 à D05 en français et D08 en anglais. D06 est ajouté dans une seconde phase. D07 est une page statique publique exclue de la recherche ; D09 est une page protégée. Chaque page partage une navigation contenant le mot « Bibliothèque », absent du texte des fiches. L’environnement d’essai ne doit pas indexer cet article, qui contient lui-même tous les mots de contrôle.

D01 — Guide, français, catégorie Migration, public dès le départ.
Titre : « Migration WordPress : préparer les URL ».
Texte : « Une migration de site change son environnement technique. Préparer la correspondance des URL et contrôler les redirections avant de valider la livraison. »

D02 — Guide, français, catégorie CMS, public dès le départ.
Titre : « Recherche interne : définir le corpus ».
Texte : « Une recherche interne doit couvrir les ressources publiques choisies. Définir les documents attendus, leurs langues et leurs exclusions avant de retenir une solution. »

D03 — Checklist, français, catégorie Conversion, public dès le départ.
Titre : « Recette du formulaire B2B ».
Texte : « Vérifier un envoi, les champs reçus et la destination de la demande. Le message de succès ne suffit pas à confirmer la réception métier. »

D04 — Guide, français, catégorie CMS, public dès le départ.
Titre : « Créer une collection Réalisations ».
Texte : « Définir les champs et les références utiles pour présenter chaque réalisation. Vérifier un contenu complet dans son gabarit avant de généraliser le modèle. »

D05 — Cas pédagogique, français, catégorie Projet, public dès le départ.
Titre : « Cas fictif : navigation d’un site technique ».
Texte : « Séparer les besoins du décideur et du lecteur technique. Relier chaque entrée de navigation à une page qui explique le sujet attendu. »

D06 — Guide, français, catégorie Conversion, non publié au départ puis ajouté.
Titre : « Rendez-vous : confirmer une réservation ».
Texte : « Vérifier le créneau choisi et la présence du rendez-vous dans la destination convenue. Distinguer le clic, la confirmation affichée et la réservation créée. »

D07 — Page statique, français, hors catégorie, publique mais exclue de la recherche.
Titre : « Offre de démonstration ».
Texte : « Cette page pédagogique contient le marqueur coupon-orion-unique pour vérifier son exclusion du moteur interne. »

D08 — Guide, anglais, catégorie CMS, public dans la locale anglaise.
Titre : « Internal search: define the corpus ».
Texte : « Define the public resources, languages and exclusions. Check that each search task leads to the expected document. »

D09 — Page protégée, français, hors corpus public.
Titre : « Document confidentiel — accès réservé ».
Texte synthétique : « Le marqueur privetest-sirius-unique sert uniquement à contrôler une éventuelle exposition. Aucun document client n’est utilisé. »

Les douze cas à vérifier

Pour cet exercice, un document « retrouvé » doit apparaître parmi les trois premiers résultats, sauf si le cas demande une liste ou une absence. Ce seuil est un critère pédagogique à fixer avant l’essai, pas une performance observée. Les douze cas sont non exécutés dans ce guide.

Test 01 — Mot exact du titre.
Dans la locale française, saisir « WordPress » sur l’index initial.
Attendu : D01 parmi les trois premiers résultats, avec un titre et une destination cohérents. Raison : le mot identifie le guide de migration. Un résultat qui ne mène pas à cette fiche échoue au contrôle.

Test 02 — Expression de deux mots.
Saisir « recherche interne », sans imposer une syntaxe de recherche entre guillemets.
Attendu : D02 en première position, car son titre et son texte répondent directement au besoin. Documenter les autres résultats éventuels et leur pertinence, au lieu de supposer un fonctionnement exact par expression.

Test 03 — Accent et absence d’accent.
Comparer « réalisations » et « realisations ».
Attendu : D04 parmi les trois premiers résultats dans les deux cas. Si la solution ne le permet pas, noter la limite et décider si elle est acceptable pour les visiteurs ; ne pas déclarer les deux formes équivalentes sans essai.

Test 04 — Faute de frappe.
Saisir « migraton ».
Attendu pour le besoin pédagogique : retrouver D01 parmi les trois premiers résultats. Si aucun résultat ne convient, l’exigence de tolérance n’est pas satisfaite. Elle ne doit pas être attribuée d’avance au moteur natif ni déduite d’une documentation portant sur un autre produit.

Test 05 — Synonyme métier.
Saisir « transfert de site », expression absente des textes des fiches.
Attendu : D01 parmi les trois premiers résultats si cette correspondance métier fait partie du besoin retenu. Elle doit être préparée ou configurée dans la solution choisie, puis testée. Une tolérance orthographique ne prouve pas une compréhension des synonymes.

Test 06 — Sélection d’une catégorie.
Sans requête textuelle, choisir la catégorie CMS dans la navigation ou le dispositif de filtres prévu.
Attendu dans la vue française initiale : D02 et D04, sans D01, D03 ou D05. La tâche peut nécessiter une liste distincte du moteur. Écrire « CMS » dans un champ de recherche ne remplace pas ce contrôle de sélection structurée.

Test 07 — Aucun contenu correspondant.
Saisir « facturation lunaire », absent du corpus.
Attendu : aucun résultat présenté comme pertinent ; requête conservée, message compréhensible et accès à la liste des ressources. Si un filtre existe, proposer sa réinitialisation. L’interface ne doit pas inventer une réponse.

Test 08 — Terme présent seulement dans la navigation.
Saisir « Bibliothèque » après application des exclusions de navigation prévues.
Attendu : aucun document remonté uniquement à cause de ce libellé répété. Si toutes les fiches apparaissent, vérifier la portée de l’index et des exclusions. Une navigation utile ne doit pas polluer chaque résultat.

Test 09 — Nouveau contenu.
Vérifier l’absence de D06 dans l’état initial, puis l’ajouter selon le processus autorisé de l’environnement d’essai et rechercher « réservation ».
Attendu : D06 parmi les trois premiers résultats après la mise à jour effective de l’index. Conserver l’heure de publication, l’événement de réindexation et l’heure du contrôle. Une absence avant la fin du délai d’actualisation prévu ne suffit pas à diagnostiquer une panne.

Test 10 — Exclusion explicite.
Exclure D07 selon les possibilités du produit, actualiser l’index, puis saisir « coupon-orion-unique ».
Attendu : aucun titre, extrait ou lien vers D07. Vérifier aussi ses éventuelles reprises dans d’autres pages. La fiche utilise une page statique afin de ne pas supposer une exclusion individuelle d’item CMS que le produit ne permettrait pas.

Test 11 — Changement de langue.
Rechercher « internal search » en anglais, puis refaire la requête dans la vue française.
Attendu dans le scénario de corpus séparés : D08 retrouvé dans la locale anglaise et absent de la locale française. Si une recherche entre langues est nécessaire, il faut définir une autre exigence et vérifier une solution qui la prend réellement en charge.

Test 12 — Contenu protégé.
Sans être authentifié, rechercher « privetest-sirius-unique » et vérifier l’accès direct à la destination protégée.
Attendu : aucun titre, extrait ou URL de D09 dans la recherche publique et aucun contenu protégé accessible directement. Ce contrôle ciblé ne constitue pas un audit de sécurité complet. Utiliser seulement la fiche synthétique, jamais une donnée confidentielle réelle.

Exécuter et documenter les tests dans la solution retenue

Identifiez l’environnement, le produit, sa version lorsqu’elle est exposée, le plan, la langue, la date et les réglages utiles. Distinguez la liste des contenus publiés de ceux présents dans l’index. Exécutez ensuite les cas sur le même corpus et conservez la requête exacte, l’ordre des résultats, leurs destinations et une trace datée.

Pour chaque ligne de recette, séparez attendu, observé, écart et décision. Tant que l’essai n’a pas eu lieu, la colonne observée reste « non exécuté ». Une démonstration locale de filtrage peut illustrer les fiches ; elle ne valide pas le moteur natif Webflow.

Pour le natif, Webflow documente une actualisation d’index liée au plan et au mode de publication ; une publication d’item CMS seule ne déclenche pas la réindexation automatique. Les exclusions de recherche interne sont distinctes de l’indexation Google. L’exclusion d’une Collection ne retire pas forcément ses reprises sur d’autres pages ; l’exclusion individuelle d’un item n’est pas proposée. Vérifiez ces conditions dans la documentation actuelle et dans l’environnement retenu.

Que faire lorsqu’une exigence n’est pas satisfaite ?

Commencez par vérifier si l’échec vient du corpus, du chargement, de l’index ou du comportement de recherche. Un document absent de l’index et un document présent mais mal classé ne demandent pas la même correction.

Si une catégorie suffit, une navigation explicite peut résoudre le besoin. Si le terme métier doit retrouver un contenu formulé autrement, examinez la qualité de la rédaction et les réglages de correspondance. N’ajoutez pas des mots sans rapport aux pages pour fabriquer de faux résultats pertinents.

Lorsqu’une exigence indispensable reste hors de portée, comparez une autre solution ou un périmètre différent. Conservez la limite dans la transmission. Ne présentez pas comme validé un montage dont seuls l’apparence du champ et le résultat d’exemple ont été vérifiés.

Prévoir un parcours utile quand la recherche ne répond pas

Une absence de résultat n’est pas une erreur du visiteur. Conservez les mots saisis, donnez une explication courte et proposez un chemin adapté : corriger la requête, retirer un filtre ou parcourir les ressources. Réservez la prise de contact aux besoins qui le justifient ; elle ne doit pas être l’unique sortie d’un moteur peu utile.

Exemple de message : « Aucun résultat pour votre recherche. Essayez un autre terme ou consultez les ressources par thème. » Si des filtres sont actifs, ajoutez un contrôle nommé « Réinitialiser les filtres ». Les suggestions doivent mener à des contenus existants et ne pas être présentées comme des réponses exactes à une demande non couverte.

Distinguez cet état d’une indisponibilité technique : « La recherche est momentanément indisponible. Vous pouvez consulter les ressources par thème. » Le lecteur doit savoir s’il peut reformuler sa demande ou s’il rencontre un problème de service.

Contrôler le parcours au clavier et sur mobile

Le W3C recommande un libellé associé aux contrôles de formulaire. Donnez au champ un nom compréhensible, tel que « Rechercher une ressource », sans compter uniquement sur le texte indicatif à l’intérieur du champ.

Testez l’accès au champ, la saisie, le bouton de recherche, les éventuels filtres et les liens de résultats au clavier. Le focus doit rester visible et l’ordre de navigation compréhensible. Contrôlez aussi le retour après ouverture d’un résultat et la conservation utile de la requête.

Sur mobile, vérifiez la largeur des titres, les zones d’action, le clavier affiché et la lecture des extraits. Si les résultats changent sans rechargement, vérifiez que cette mise à jour est perceptible avec les technologies d’assistance. Ces contrôles s’ajoutent aux douze cas de pertinence ; ils ne constituent pas une certification d’accessibilité.

Maintenir les résultats et leur place dans le site

Désignez qui met à jour les contenus, qui surveille l’index et qui corrige l’interface. Après un changement de titre, d’URL, de langue ou de statut, reprenez les cas concernés. Pour une solution externe, ajoutez le contrôle de synchronisation et de retrait des données. Pour une liste filtrée, vérifiez les champs, les valeurs et le chargement des items.

Les recherches sans réponse peuvent révéler un vocabulaire différent, un problème de classement ou un véritable manque de contenu. Elles ne justifient pas automatiquement de nouveaux articles. Examinez d’abord la tâche et la réponse déjà disponible. Si des requêtes sont collectées, définissez une mesure adaptée et évitez la conservation inutile de données sensibles saisies par les visiteurs.

La recherche complète la navigation et le maillage. Elle ne doit pas devenir le seul moyen d’atteindre une ressource importante. Le guide du CMS Webflow avancé traite la structure des contenus ; le guide des plugins Webflow aide à raisonner sur les dépendances. Le présent guide garde un rôle précis : choisir la fonction de recherche et préparer sa réception.

Si vous préparez un site de ressources ou une nouvelle architecture éditoriale, notre offre de création de site Webflow permet de cadrer le corpus, les parcours et le CMS. La solution de recherche se choisit ensuite à partir des exigences réellement nécessaires et des contrôles qu’elle permet de réussir.