Pourquoi la recherche WooCommerce ne trouve pas vos références produit (SKU)

Un client vous demande une référence au téléphone, la tape dans votre boutique, et lit « Aucun produit ne correspond à votre sélection ». La fiche est publiée, le produit est en stock, et la référence est bien renseignée dans le champ UGS. Ce n'est pas un réglage manqué : la recherche WooCommerce ne lit pas ce champ.

Trois requêtes sur une boutique WooCommerce, sans extension de recherche

Mesuré le 28 septembre 2026 sur une boutique montée pour ça : WordPress 7.1.2, WooCommerce 11.1.2, PHP 8.5.10, thème Twenty Twenty-Five, 300 fiches de visserie publiées, aucune extension de recherche active. Le chemin mesuré est celui du formulaire de recherche produit d'un thème classique — /?s=…&post_type=product — celui que vos clients utilisent.

Ce que le client tape	Ce que la boutique rend
`REF-000134` l'UGS exacte d'une fiche publiée	0 résultat. « Aucun produit ne correspond à votre sélection. »
`M8-30` la dimension écrite avec un tiret	1 produit sur les 5 que cette boutique porte en M8×30. Et comme il n'y en a qu'un, WordPress y redirige le client directement.
`rondele inox` une lettre en moins	0 résultat, là où `rondelle inox` en rend 15.

Le pire des trois n'est pas un zéro

Les deux zéros se voient. Le client lit « aucun produit », il sait qu'il n'a pas trouvé, et il vous appelle ou il s'en va — c'est un coût, il est mesurable, et au moins personne ne se trompe.

M8-30 est autre chose. Une recherche qui ne rend qu'un seul produit ne montre pas de liste : WordPress répond par une redirection (un 302 vers la fiche), et le client atterrit directement sur l'article. Il n'a jamais vu qu'il y avait une liste. Il croit avoir trouvé.

Sur cette boutique, l'unique produit atteint est une vis en acier brut. Les quatre autres M8×30 — dont trois en inox — ne se sont affichées nulle part, parce qu'elles sont écrites M8X30, M8x30 ou M8 x 30. Ce n'est pas un résultat manquant, c'est un résultat qui ment par omission : le client repart avec de l'acier là où il voulait de l'inox, et rien, nulle part, ne lui a dit que le choix existait.

Les trois échecs ont la même cause

Pour chercher un produit, WordPress écrit des LIKE sur trois colonnes, et trois seulement : le titre, l'extrait et la description (post_title, post_excerpt, post_content). C'est la requête relevée sur cette boutique, et il n'y a rien d'autre dedans.

Aucune jointure sur l'UGS. Ni sur le champ, ni sur la table de correspondance produit de WooCommerce. Une référence qui ne figure pas aussi dans le titre ou la description est hors de portée de ce chemin. Si vos UGS sont des codes fournisseur — et en visserie, en pièces détachées, en composants électroniques, ils le sont — c'est toute votre nomenclature qui est invisible à votre propre recherche. C'est le problème que décrit notre article sur la recherche par référence en B2B ; ici, il est mesuré sur WooCommerce.

Un LIKE cherche une suite de caractères, pas une référence. M8-30 devient LIKE '%M8-30%'. Une fiche intitulée « Vis M8x30 » ne contient pas cette suite de caractères : elle ne sort pas. Sur cette boutique, les cinq M8×30 sont écrits de quatre façons — M8X30, M8x30, M8 x 30, M8-30 — parce qu'un catalogue réel agrège des imports successifs. Chaque écriture tapée n'atteint que les fiches écrites pareil.

Et quand le client met des espaces, le bruit arrive. M8 x 30 est découpé en mots, et WordPress jette les mots d'une seule lettre : il reste M8 et 30. Les cinq M8×30 sortent enfin, accompagnés de quatre produits qui n'en sont pas, parce que %30% attrape « inox 304 ». Neuf résultats, cinq bons.

Ce seuil n'est pas propre à WooCommerce, et c'est ce qui le rend intéressant. PrestaShop a le même genre de règle, placée plus haut : PS_SEARCH_MINWORDLEN vaut 3 à la livraison, et « M8 », « A2 », « 20 » n'y sont ni cherchés ni indexés — mesuré sur PrestaShop 9.1.4. WordPress, lui, ne jette que les mots d'une seule lettre, donc « M8 » survit. Deux plateformes, deux seuils, la même décision au départ : un moteur écrit pour des articles de blog, où un mot court ne veut rien dire. Dans un catalogue technique, les mots courts sont la référence.

La faute de frappe, elle, n'a aucune issue sur ce chemin : %rondele% ne figure dans aucun titre. Il n'y a pas de tolérance mal réglée à corriger, parce qu'il n'y en a pas du tout. Ce que nous avons mesuré, ce sont WordPress et WooCommerce seuls : nous n'avons pas vérifié qu'aucun thème ni aucune extension tierce n'en ajoute une.

Une précision sur le chemin, parce qu'elle change la réponse. Si votre boutique utilise le bloc « Recherche de produits » de WooCommerce, la recherche passe par l'API Store, et celle-là lit bien l'UGS : sur la même boutique, REF-000134 y rend la bonne fiche. Mais elle cherche la chaîne entière telle quelle : rondelle inox y rend 0, parce qu'aucun titre ne porte ces deux mots dans cet ordre. Les deux chemins échouent, pour deux raisons différentes.

Ce que ça coûte, et pourquoi vous ne le voyez pas

Une recherche à zéro résultat est une visite qui s'arrête. Le client ne vous écrit pas pour signaler qu'il n'a pas trouvé : il va voir ailleurs, ou il vous appelle — et un appel pour une référence que votre site porte déjà est un coût, pas une vente de plus.

Et rien de tout ça n'est enregistré quelque part : WooCommerce ne conserve pas les recherches restées sans résultat, et une redirection vers la mauvaise fiche ressemble, dans vos statistiques, à une recherche réussie. La vérification tient en une minute, et elle se fait sur votre boutique, pas sur la nôtre : prenez une fiche au hasard, copiez son UGS, tapez-la dans votre barre de recherche.

Les trois mêmes requêtes, module Heurix actif

Même boutique, mêmes 300 fiches, même thème. Le module Heurix Search for WooCommerce 0.2.1 est activé, le catalogue est indexé depuis l'écran de réglages (300 fiches, 0 échec), et le moteur tourne en local. Aucune des trois recherches n'est retombée sur la recherche native : les compteurs de repli du module sont vides.

Requête	Recherche native	Module actif
`REF-000134`	0 résultat	1 résultat, le bon. La référence est lue comme un terme. Le client est redirigé vers sa fiche — et cette fois, la redirection dit vrai.
`M8-30`	1 produit, celui écrit avec un tiret	Les 5 M8×30 aux 5 premières places, quelle que soit leur écriture. Plus de redirection : il y a une liste, et le client voit l'inox à côté de l'acier.
`rondele inox`	0 résultat	Les 15 rondelles inox aux 15 premières places. Ce sont exactement celles que la recherche native rend quand on écrit « rondelle » sans faute.

Ce que le module ne fait pas mieux

Le nombre annoncé. Sur M8-30, le module rend 45 résultats : les 5 bons, puis 40 produits qui ne partagent avec la requête que le diamètre ou la longueur — un M18-30, un M8×70, un insert M8. Sur rondele inox, il en rend 195. Les bons sont devant, c'est ce qui compte pour un client qui regarde la première page ; mais le total affiché à côté de la barre de recherche est celui-là, et les pages suivantes sont du bruit. Le module classe, il ne coupe pas.

Et une famille de fiches qu'il trouve sans la montrer. Cette boutique porte 18 rondelles inox, pas 15 : trois d'entre elles sont intitulées « Rondelle M18 A4 », « Rondelle M20 A2 », « Rondelle M3 A4 » — la nuance sans le mot « inox ». La recherche native ne les trouve jamais, ni avec la faute ni sans. Le moteur, lui, sait que A2 et A4 sont de l'inox : il les annote, et il les rend. Aux positions 117, 118 et 119 — la huitième page. Un client qui cherche une rondelle inox ne les verra pas davantage.

Ces trois requêtes sont trois requêtes que nous avons choisies, sur un catalogue que nous avons généré. Ce sont des cas, pas un taux.

Installer le module

Le module remplace les résultats de la recherche produit de WooCommerce par ceux du moteur Heurix. Il ne touche ni vos gabarits, ni vos filtres à facettes, ni vos fiches : ce qui change, c'est quels produits sortent, et dans quel ordre.

L'installation. Dans l'administration WordPress, Extensions > Ajouter, cherchez « Heurix Search » : Installer, puis Activer. La fiche publique est wordpress.org/plugins/heurix-search-for-woocommerce, en version 0.2.1. Le module est gratuit et aucune de ses fonctions n'est réservée à une formule payante : ce qui se paie est le service, et les tarifs le disent.

Ce qu'il faut. Deux choses, sur l'écran WooCommerce > Heurix Search : une clé d'API et le nom de votre catalogue. Vous testez la connexion, vous lancez une indexation complète, vous cherchez. Ensuite, chaque fiche que vous enregistrez se resynchronise seule. La page WooCommerce détaille le reste.

Ce qu'il ne fait pas, en 0.2.1. Il n'indexe pas les variations séparément : c'est le produit parent qui entre dans l'index, pas chaque couleur ni chaque taille. Si votre catalogue discrimine par variation, la recherche ne descendra pas à ce niveau.

Et si Heurix ne répond pas, la recherche native de WooCommerce reprend la main, recherche par recherche : vos visiteurs ne voient pas de panne — ils revoient la recherche décrite dans la première moitié de cet article. L'écran de réglages vous dit combien de recherches ont été servies comme ça, pour quelle cause, et depuis quand.

Les mesures

Les versions supportées par ce module ont été mesurées, pas déclarées. Sous WooCommerce 6.0 et plus ancien, la deuxième page de résultats revient vide — nous le savons parce que nous l'avons joué, quinze versions une par une. Le protocole est public : docs/mesures/woocommerce-bornes-2026-09.

Un chiffre de cette boutique n'est pas publié, et il est spectaculaire : « ecrou » y rend 20 fiches, « écrou » en rend 0. C'est le greffon SQLite du banc, pas WooCommerce — une base MySQL ne se comporterait pas ainsi. Tout ce qui est chiffré plus haut, en revanche, ne dépend ni de la base ni du catalogue.