Recherche interne sur votre site : configurer SearchWP ou Elasticsearch pour convertir
1. Pourquoi les équipes e-commerce ignorent systématiquement la recherche interne
La plupart des sites B2B traitent la barre de recherche comme un élément décoratif, placé en haut à droite, que personne ne configure et dont personne ne consulte les données. Or le parcours d’un acheteur B2B diffère de celui d’un acheteur B2C : il ne flâne pas au hasard, il cherche des spécifications précises — “304 stainless flange”, “1000W inverter”, “IP65 enclosure 200×150”. Une navigation par catégories ne permet presque jamais de trouver ce type de besoin précis : seule la barre de recherche le peut.
Le constat contre-intuitif, c’est que :un site où l’on utilise peu la recherche n’a pas moins besoin d’elle : c’est parce qu’elle est mauvaise que personne n’ose s’en servir. Le visiteur qui obtient zéro résultat ou une page de liens hors sujet ferme l’onglet et part. Donc “personne n’utilise la recherche” est en soi un signal d’alerte, pas une preuve qu’il ne faut pas l’optimiser. Pour installer le suivi, voir Déployer GA4 et ses événements.
| Idée reçue | Signal réel | Bonne action |
|---|---|---|
| Personne n’utilise la recherche, inutile de s’en occuper | Un taux de résultats vides élevé = une recherche mauvaise | Mesurer deux semaines avant de juger |
| Une barre de recherche en haut à droite suffit | L’accès à la recherche est difficile à trouver sur mobile | Barre de recherche fixe en haut sur mobile |
| La page de résultats n’a pas d’importance | Le taux de conversion après recherche est 2 à 3 fois plus élevé qu’après navigation | Ajouter filtres et tri sur la page de résultats |
| La recherche WP par défaut suffit | WP par défaut ne cherche que dans les titres et le contenu | Les attributs produits doivent être indexés séparément |
| Il suffit de passer à Elasticsearch | Sans structure d’index bien conçue, le résultat reste mauvais | Régler d’abord la pondération, changer de moteur ensuite |
2. Décider : comment choisir parmi les trois niveaux de recherche
L’erreur la plus fréquente chez les équipes e-commerce est de débattre d’emblée “Elasticsearch ou Algolia ?” : elles choisissent l’outil avant d’avoir diagnostiqué le problème. Le bon ordre est le suivant : mesurer d’abord pendant deux semaines le taux d’utilisation de la recherche, le taux de résultats vides et le taux de clic sur le premier résultat, puis décider à quel niveau de solution recourir.
Le seuil de décision est simple : si le taux d’utilisation de la recherche est inférieur à 2 %, commencez par optimiser la navigation et le contenu, sans changer de moteur ; entre 2 % et 5 %, installez SearchWP pour gérer les synonymes et ajuster les poids ; au-delà de 5 % avec plus de 500 SKU, envisagez Elasticsearch ou un service de recherche SaaS. Pour la conception globale de la recherche sur un catalogue produits, voir l’expérience de recherche du catalogue produit.
| Niveau | Taille adaptée | Délai de réponse | Coût annuel | Coût de maintenance |
|---|---|---|---|---|
| WP_Query par défaut | <200 pages, site de contenu pur | 1 à 3 secondes | 0 dollar | Quasiment nul |
| Extension SearchWP | 200 à 5000 pages avec produits | 200 à 400 millisecondes | environ 199 $ | renouvellement annuel + reconstruction de l’index |
| Elasticsearch local | >5000 pages, SKU >1000 | 80 à 150 millisecondes | serveur auto-hébergé 30 à 80 $/mois | nécessite des compétences en exploitation |
| Algolia/Meilisearch cloud | équipe sans ressources d’exploitation | 50 à 120 millisecondes | 99 à 399 $ par mois | facturation au nombre de documents |
| Recherche produits WooCommerce | petit site e-commerce pur | 300 à 600 millisecondes | environ 99 $/an | intégration poussée avec Woo |
III. Comment configurer SearchWP : poids, synonymes et page sans résultat
SearchWP est la solution la plus rentable pour améliorer la recherche dans l’écosystème WordPress. Sa valeur principale n’est pas d’être « plus rapide », mais d’offrir une « pertinence configurable ». La recherche WP par défaut trie par post_date décroissant ; SearchWP permet d’attribuer des poids distincts au titre, au corps, aux étiquettes, aux champs personnalisés, aux catégories et à la description courte, ce qui est crucial pour un site produit : l’acheteur recherche une référence, pas un titre d’article.
Exemple concret de configuration : sur un site produit, réglez le poids du champ « référence produit » à 10, la « description courte » à 5, le « corps » à 2 et les « étiquettes » à 3. Ainsi, quand l’acheteur saisit « WF-200 », il tombe directement sur le champ référence, au lieu de tomber sur un paragraphe de blog qui mentionne WF-200. Prévoyez au moins 50 groupes de synonymes couvrant les abréviations du secteur, les variantes orthographiques et les différences entre orthographe américaine et britannique (par exemple « aluminum » vs « aluminium »). Pour savoir comment monter une stack WordPress, voir la pile technique WordPress.
| Paramètre | valeur recommandée pour un site produit | valeur recommandée pour un site de contenu | signal d’ajustement |
|---|---|---|---|
| poids du titre | 8 | 10 | à augmenter si le taux de clic sur le premier résultat est <30 % |
| poids du corps | 2 | 5 | à diminuer si le taux de zéro résultat est élevé |
| poids des champs personnalisés | 10 (référence/spécifications) | 1 (quasiment inutilisé) | à augmenter si les résultats pour une référence sont mauvais |
| poids des étiquettes | 3 | 4 | à compléter si la couverture des synonymes est incomplète |
| poids des catégories | 5 | 2 | à diminuer si les résultats sont trop larges |
| longueur minimale des mots | 2 caractères | 3 caractères | à passer à 2 si les références courtes ne sont pas trouvées |
| Correspondance floue | activé (distance d’édition 1) | Fermer | à activer sur les marchés où les fautes de frappe sont fréquentes |
IV. Quand Elasticsearch est vraiment nécessaire et comment le configurer
Elasticsearch n’est pas synonyme de « recherche avancée » : il est conçu pour la recherche plein texte à grande échelle et les agrégations complexes. Un site indépendant ne devrait l’adopter que s’il remplit l’une de ces deux conditions : premièrement, plus de 1000 SKU avec filtrage à facettes en temps réel (filtrer simultanément par tranche de prix, matériau et certification) ; deuxièmement, plus de 5000 pages et un temps de réponse de recherche déjà supérieur à 500 millisecondes. Si ces deux conditions ne sont pas remplies, passer à Elasticsearch revient à écraser une mouche avec un canon.
Le piège le plus courant en matière de configuration, c’est la segmentation du chinois et du multilingue. Pour l’anglais, l’analyzer standard suffit ; pour le chinois, il faut impérativement installer l’analyseur IK et configurer un dictionnaire personnalisé (ajoutez-y vos références produit et vos abréviations métier), sinon « 304 acier inoxydable bride » sera découpé caractère par caractère et le rappel sera totalement faussé. Pour un site multilingue, créez aussi un index distinct par langue et reliez-les avec hreflang. Pour cette partie, voir Mise en place du hreflang multilingue. Pour la configuration du CDN et du cache, voir Accélération mondiale par CDN.
| Situation | Solution recommandée | Configuration essentielle | Résultat attendu |
|---|---|---|---|
| Site blog de 500 pages | SearchWP version gratuite | Poids du titre 10, corps 5 | Taux de zéro résultat passé de 25 % à 8 % |
| Site produit de 3000 pages | SearchWP Pro | Poids 10 sur le champ référence + table de synonymes | Taux de conversion après recherche +15 % |
| Site e-commerce de 2000 SKU | Elasticsearch local + plugin WP | Segmentation IK + agrégations à facettes | Réponse <150 ms |
| Site B2B multilingue | Elasticsearch multi-index | Index par langue + synonymes | Taux de zéro résultat <10 % par langue |
| Équipe sans exploitation | Algolia/Meilisearch cloud | Utiliser le plugin WordPress officiel | Sans exploitation, paiement au volume de documents |
V. Le taux de zéro résultat est un indicateur plus important que le classement
Beaucoup d’équipes surveillent « la position du résultat de recherche », mais le véritable indicateur tueur en B2B, c’est le taux de zéro résultat. Quand une requête ne renvoie rien, l’internaute ne tourne pas la page : il ferme son navigateur. L’expérience du secteur montre que : un taux de zéro résultat supérieur à 20 % signale un décalage entre les requêtes et la structure du contenu, et au-delà de 35 %, la recherche est pratiquement hors service.
Traiter un taux de zéro résultat élevé se fait en deux étapes : premièrement, exportez les requêtes sans résultat dans un tableau, triez-les par fréquence, et traitez impérativement les 20 premières ; deuxièmement, pour chaque requête, déterminez s’il s’agit de « contenu inexistant pour cette requête » ou de « contenu existant mais introuvable ». Dans le premier cas, il faut ajouter du contenu ; dans le second, ajuster le poids de l’index ou ajouter des synonymes. Pour savoir comment exploiter les requêtes de recherche interne afin de combler les lacunes de contenu, voir l’exploration des requêtes internes au site. Dans les Core Web Vitals, la page de résultats de recherche influence aussi le LCP, voir Optimiser les Core Web Vitals.
| Indicateur | Fourchette saine | Seuil d’alerte | Action à mener |
|---|---|---|---|
| Taux d’utilisation de la recherche (part des sessions avec recherche) | 5 % à 15 % | Inférieur à 2 % pendant 4 semaines consécutives | Optimiser la navigation et la visibilité de l’accès à la recherche |
| Taux de zéro résultat | Moins de 10 % | Supérieur à 20 % | Exporter les requêtes sans résultat fréquentes, ajouter du contenu ou ajuster le poids |
| Taux de clic sur le premier résultat | Supérieur à 40 % | Inférieur à 25 % | Problème de pertinence du classement des résultats, ajuster le poids |
| Taux de conversion après recherche | 2 à 3 fois supérieur à la navigation normale | Équivalent à la navigation | La page de résultats manque de filtres et de CTA |
| Temps de réponse de la recherche | Inférieur à 300 millisecondes | Supérieur à 800 millisecondes | Ajouter du cache ou changer de moteur |
FAQ — Questions fréquentes
Faut-il absolument passer à Elasticsearch pour un site indépendant ?
Comment savoir si la recherche interne doit être optimisée ?
Quelle différence entre SearchWP et la recherche par défaut de WP ?
Pourquoi la recherche en chinois donne-t-elle de mauvais résultats dans Elasticsearch ?
Que faire face à un taux de zéro résultat élevé, et comment traiter en masse ?
Algolia ou un Elasticsearch auto-hébergé : que choisir ?
Pour conclure
La recherche interne est le module le plus sous-estimé d’un site e-commerce en termes de retour sur investissement. Pas besoin de grands travaux : commencez par deux semaines d’instrumentation, puis laissez le taux de zéro résultat et le taux d’utilisation de la recherche décider du niveau à passer. La plupart des sites s’en tiennent à SearchWP, et c’est suffisant. Elasticsearch n’est pas obligatoire : c’est un choix naturel une fois la taille atteinte, pas le point de départ de l’expérience de recherche.
Trois étapes pour passer à l’action. Premièrement, installez cette semaine le suivi d’événements GA4 sur le champ de recherche pour enregistrer les requêtes, les clics et le nombre de résultats. Deuxièmement, deux semaines plus tard, exportez la liste des requêtes sans résultat et traitez les 20 plus fréquentes. Troisièmement, décidez d’installer ou non SearchWP selon le taux d’utilisation de la recherche ; si vous l’installez, ajustez une fois les pondérations, puis laissez tourner un mois pour voir si le taux de clic sur le premier résultat passe de 25 % à plus de 40 %.
Une phrase à retenir : si peu de gens utilisent la recherche, ce n’est pas qu’ils n’en ont pas besoin, c’est qu’elle est trop mauvaise pour qu’on ose s’en servir. Commencez par instrumenter et diagnostiquer, la question du moteur viendra ensuite.