# SearchWP contre la recherche native pour un catalogue WooCommerce de 5 000 références

> La recherche native de WordPress peine dès que le catalogue dépasse quelques centaines de produits. SearchWP règle une partie du problème, mais pas gratuitement.

- Auteur : WordPress Développement
- Publié le : 2022-01-15
- Mis à jour le : 2022-01-15
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/searchwp-recherche-native-catalogue-woocommerce-5000-references/

## L’essentiel

- La recherche native ignore la pertinence par pondération de champ
- SearchWP indexe attributs, méta et variations séparément
- Le coût de licence doit être comparé au coût de maintenance interne

« recherche_produit ne trouve rien, mais le produit existe » : ce ticket revient presque tel quel dans le support d'à peu près toutes les boutiques WooCommerce dont le catalogue dépasse deux ou trois mille références. La cause est presque toujours la même : la recherche native de WordPress compare des chaînes de caractères sans notion de pertinence.

Sur un catalogue de 5 000 références réparties en quarante catégories, avec des variations de couleur et de taille sur la moitié des produits, j'ai comparé deux approches concrètes : garder la recherche native optimisée à la main, ou basculer sur SearchWP.

## Pourquoi la recherche native décroche

La recherche par défaut de WordPress s'appuie sur des clauses `LIKE '%terme%'` contre les colonnes `post_title` et `post_content` de la table `wp_posts`. Cette approche ne connaît ni la pondération par champ, ni la notion de pertinence : un produit dont le terme apparaît une seule fois dans une longue description remonte au même rang qu'un produit dont le titre correspond exactement.

Pire, les attributs de variation, les références SKU stockées en méta, ou les termes de taxonomie ne sont pas couverts par cette recherche par défaut. Sur le catalogue étudié, environ un tiers des recherches portaient justement sur une référence SKU tapée par un client ayant reçu un devis papier au préalable.

## Ce que change une indexation dédiée

> L'essentiel à retenir : La recherche native ignore la pertinence par pondération de champ ; SearchWP indexe attributs, méta et variations séparément ; Le coût de licence doit être comparé au coût de maintenance interne

SearchWP construit ses propres tables d'index, séparées de `wp_posts`, et permet de définir des sources de données pondérées : titre, contenu, attributs de variation, méta SKU, taxonomies de catégorie. Chaque source reçoit un poids configurable, ce qui permet de faire remonter un produit dont le titre correspond avant un produit qui ne matche que dans une note interne.

Concrètement, sur le catalogue testé, la configuration a consisté à :

- Ajouter la méta `_sku` comme source de recherche avec un poids élevé.
- Intégrer les attributs de variation (couleur, taille) comme source secondaire.
- Réduire le poids du contenu long pour éviter que des mentions légales ou des tableaux de tailles ne polluent les résultats.

## Le coût réel de SearchWP

Ce gain n'est pas gratuit à deux niveaux. D'abord financièrement : la licence est annuelle et son tarif dépend du nombre de sites couverts, ce qui pèse sur une agence qui gère plusieurs boutiques. Ensuite en maintenance : chaque modification structurelle du catalogue (nouvel attribut, nouvelle taxonomie) demande de revoir la configuration des sources et des poids, sous peine de voir la pertinence se dégrader silencieusement.

### Et la piste de la recherche native optimisée ?

Avant de basculer sur une extension payante, il existe une marge d'amélioration côté natif, notamment en filtrant la requête de recherche via `pre_get_posts` pour cibler explicitement le SKU et les attributs, ou en excluant les types de contenu qui ne devraient jamais apparaître dans les résultats produits.

```
add_action( 'pre_get_posts', function ( $query ) {
    if ( ! is_admin() && $query->is_search() && $query->is_main_query() ) {
        $query->set( 'post_type', array( 'product' ) );
    }
} );
```

Cette optimisation reste utile dans tous les cas, y compris avec SearchWP, mais elle ne règle pas le problème de pertinence par pondération de champ, qui reste la vraie limite structurelle de la recherche native.

## Comparatif synthétique

| Critère | Recherche native optimisée | SearchWP |
| --- | --- | --- |
| Pertinence par pondération | Absente | Configurable finement |
| Recherche sur SKU et attributs | Possible via développement sur mesure | Intégrée nativement |
| Coût récurrent | Aucun | Licence annuelle |
| Maintenance lors d'évolution du catalogue | Faible | Configuration à revoir |

> Je recommande SearchWP surtout quand la recherche fait partie du parcours d'achat principal, par exemple sur un catalogue technique où le client connaît déjà une référence précise. Sur une boutique où la recherche reste un usage secondaire, l'optimisation native suffit souvent.

## Notre verdict

Sur le catalogue de 5 000 références étudié, avec plus de deux cents recherches quotidiennes et un tiers portant sur des références SKU, SearchWP a justifié son coût : le taux de rebond après une recherche sans résultat a nettement diminué. Sur une boutique plus petite, ou dont le trafic de recherche reste marginal, l'optimisation native de la requête via `pre_get_posts` reste la solution la plus raisonnable.

La bonne question à se poser avant de choisir n'est donc pas « la recherche native est-elle mauvaise ? », mais « combien de clients tapent-ils une référence exacte plutôt qu'un mot-clé descriptif ? ». La réponse détermine presque à elle seule le bon investissement.