Sur un projet e-commerce headless avec un catalogue de 6 000 produits, la question de la recherche s’est posée assez tôt : l’endpoint natif /wp-json/wp/v2/search suffirait-il, ou fallait-il d’emblée prévoir un service tiers comme Algolia ? Ce n’est pas une question à trancher par principe : elle dépend du volume de contenu, des exigences de pertinence, et du budget disponible pour un service payant au-delà d’un certain seuil d’utilisation.
Cet article compare les deux approches sur trois critères concrets — pertinence des résultats, latence perçue, et coût — pour un usage headless. Il ne traite pas de la recherche sur un site WordPress classique avec thème PHP, où le moteur de recherche interne suffit dans la grande majorité des cas.
L’endpoint /search natif
WordPress expose une route de recherche transverse depuis plusieurs versions, qui interroge simultanément plusieurs types de contenu :
GET /wp-json/wp/v2/search?search=chaussures+running&type;=post&subtype;=productCette route s’appuie sur la même logique de recherche que WP_Query en coulisses : une correspondance SQL de type LIKE sur le titre et le contenu, pondérée légèrement par la pertinence du titre par rapport au contenu. C’est fonctionnel pour un besoin simple, mais avec des limites connues : pas de tolérance aux fautes de frappe, pas de recherche par synonymes, et une pertinence qui se dégrade vite sur un catalogue volumineux avec des termes proches.
Filtrer par type de contenu
Un point souvent sous-estimé : la route /search ne permet pas de filtrer par taxonomie ou par méta-donnée directement. Pour une recherche à facettes (filtrer par catégorie de produit en plus du texte libre), il faut généralement combiner plusieurs requêtes ou revenir à la route /wp-json/wp/v2/product?search=...&product;_cat=..., moins générique mais plus filtrable que /search.
// Recherche transverse (articles + pages + produits)
GET /wp-json/wp/v2/search?search=chaussures
// Recherche filtrée sur un seul type, avec taxonomie
GET /wp-json/wp/v2/product?search=chaussures&product;_cat=running
// Recherche filtrée sur les articles de blog uniquement
GET /wp-json/wp/v2/posts?search=chaussures&categories;=12Algolia : recherche instantanée et tolérante aux fautes
Algolia fonctionne différemment : au lieu d’interroger WordPress à chaque recherche, il maintient un index externe synchronisé (via l’extension WP Search with Algolia, par exemple), interrogé directement depuis le front avec une latence typiquement inférieure à 50 millisecondes. Sa tolérance aux fautes de frappe, sa pondération configurable par champ et sa recherche à facettes intégrée en font un choix nettement supérieur en pertinence perçue.
import algoliasearch from 'algoliasearch/lite';
const client = algoliasearch('APP_ID', 'CLE_PUBLIQUE_RECHERCHE');
const index = client.initIndex('produits_wordpress');
const { hits } = await index.search('chaussurs runing', {
filters: 'categorie:running',
hitsPerPage: 10,
});
// Trouve "chaussures running" malgré les deux fautes de frappeComparatif sur les trois critères
| Critère | /search natif | Algolia |
|---|---|---|
| Pertinence | Correcte pour un petit catalogue, limitée au-delà | Élevée, configurable finement par champ |
| Latence | 100 à 300 ms selon la charge du serveur WordPress | Généralement sous 50 ms |
| Coût | Aucun coût direct, inclus dans l’hébergement | Gratuit jusqu’à un certain volume, payant au-delà |
Le coût d’Algolia en pratique
Le plan gratuit d’Algolia (Community) reste limité en nombre de recherches et en taille d’index, suffisant pour un blog ou un petit catalogue. Au-delà, la facturation dépend du nombre de recherches mensuelles et du volume d’enregistrements indexés — un point à chiffrer avant de s’engager, en particulier pour un catalogue e-commerce dont le volume de recherches croît avec le trafic, contrairement à un coût d’infrastructure WordPress qui reste globalement fixe.
Indexation et synchronisation
Algolia introduit une dépendance supplémentaire à surveiller : l’index doit rester synchronisé avec le contenu WordPress. L’extension WP Search with Algolia s’appuie sur les hooks de sauvegarde pour réindexer automatiquement à chaque publication ou modification, mais un désalignement reste possible en cas d’import en masse ou de modification directe en base de données, sans passer par les hooks WordPress standards.
- Prévoir une réindexation complète planifiée (par exemple hebdomadaire) en complément de la synchronisation à la volée.
- Vérifier que les champs indexés correspondent bien à ceux affichés dans les résultats de recherche du front, notamment après l’ajout d’un nouveau champ personnalisé.
- Tester le comportement en cas d’indisponibilité temporaire d’Algolia, avec un repli possible vers
/searchnatif en dernier recours.
Sur un catalogue de moins de 500 contenus, je recommande presque toujours de commencer avec l’endpoint natif : le gain de pertinence d’Algolia ne justifie pas la complexité de synchronisation ajoutée tant que le volume reste modeste.
Notre verdict
L’endpoint /search natif convient à un site avec un catalogue restreint et des exigences de pertinence modérées, sans coût ni dépendance supplémentaire. Algolia devient pertinent dès que le volume de contenu grandit, que la tolérance aux fautes de frappe compte pour l’expérience utilisateur, ou que la recherche à facettes est un besoin explicite du projet — à condition d’accepter la dépendance à un service tiers et son modèle de coût variable.
