« Le widget Posts ne trouve rien quand on tape une faute de frappe. » Ce retour, remonté par l’équipe éditoriale d’un site de ressources documentaires comptant plusieurs milliers d’articles, a motivé le remplacement du widget natif Posts d’Elementor par un widget personnalisé branché sur Algolia InstantSearch pour la page de recherche du site.
Ce chantier ne couvre pas l’indexation de contenu WooCommerce, absent de ce site, ni la facturation Algolia (qui dépend du volume de recherches et de la taille de l’index, à évaluer séparément selon chaque projet).
Pourquoi le widget Posts natif ne suffisait pas
Le widget Posts d’Elementor est un widget de requête : il exécute une WP_Query filtrée par taxonomie, auteur ou date, mais ne propose aucune tolérance aux fautes de frappe, aucun classement par pertinence textuelle, et aucune mise à jour des résultats sans rechargement de page. Pour une simple grille d’articles filtrable, c’est amplement suffisant. Pour une véritable recherche en texte libre sur plusieurs milliers de documents, ce n’est pas son rôle.
Principe d’Algolia InstantSearch
Algolia indexe le contenu séparément de WordPress (via une synchronisation déclenchée à chaque publication ou modification d’article) et expose une API de recherche optimisée pour la vitesse et la tolérance aux fautes. La bibliothèque JavaScript InstantSearch.js se charge de l’interface : elle envoie une requête à chaque frappe du visiteur et met à jour les résultats sans rechargement, avec un temps de réponse mesuré autour de 180 millisecondes sur ce projet.
Étapes de mise en place
- Créer un index Algolia et y synchroniser le contenu WordPress via le plugin officiel WP Search with Algolia, qui gère l’indexation initiale et les mises à jour incrémentales
- Créer un widget Elementor personnalisé (classe PHP étendant
\Elementor\Widget_Base) qui se contente de générer le conteneur HTML attendu par InstantSearch.js, sans logique de requête côté PHP - Charger la bibliothèque InstantSearch.js et initialiser la recherche côté client, avec la clé API publique (search-only, jamais la clé d’administration) et l’identifiant de l’index
- Personnaliser le gabarit d’affichage des résultats (« hit template ») pour respecter la charte graphique du site, en HTML/JavaScript côté client
Extrait du widget côté PHP
class Widget_Recherche_Algolia extends \Elementor\Widget_Base {
public function get_name() { return 'recherche-algolia'; }
public function get_title() { return 'Recherche Algolia'; }
protected function render() {
echo '<div id="algolia-searchbox"></div>';
echo '<div id="algolia-hits"></div>';
}
}
Le widget PHP reste volontairement minimaliste : sa seule responsabilité est de fournir les points d’ancrage HTML attendus par InstantSearch.js, chargé et initialisé séparément via un script enregistré avec wp_enqueue_script, dépendant du widget uniquement sur les pages où il est présent.
Conseil maison : garder le rendu PHP du widget aussi léger que possible et déporter toute la logique de recherche côté client évite de coupler le widget Elementor à la disponibilité de l’API Algolia au moment du rendu de la page.
Ce qu’il faut surveiller après mise en production
- La synchronisation de l’index après suppression d’un article (un article dépublié doit disparaître de l’index, pas seulement du site)
- Le volume de requêtes de recherche consommé, qui détermine le palier tarifaire Algolia
- La pertinence du classement des résultats, ajustable via les réglages de « ranking » côté configuration de l’index Algolia
Notre verdict
Le widget Posts natif d’Elementor reste pertinent pour des grilles de contenu filtrées de façon prévisible. Dès que le besoin devient une recherche en texte libre, tolérante aux fautes, sur un volume important de contenu, un widget personnalisé branché sur un moteur de recherche dédié comme Algolia répond à un besoin que le widget natif n’a jamais eu vocation à couvrir.
