Comment fonctionne la recherche dans WordPress

La recherche inté­grée de Word­Press fait un tra­vail simple et le fait bien : retrou­ver un mot dans le titre, l’ex­trait et le conte­nu de vos pages et articles. Pour la plu­part des sites, cela suf­fit. Mais on ne la règle pas faci­le­ment : ce qu’elle explore et la façon dont elle classe sont fixes, sauf à pas­ser par du code ou une exten­sion. Cet article décrit com­ment affi­cher un champ de recherche, ce que le moteur com­pare, com­ment il classe, ce qui lui échappe, et par quels moyens élar­gir son péri­mètre le jour où cela ne suf­fit plus.

Ce qui se passe quand un internaute lance une recherche

Le par­cours est simple. L’in­ter­naute sai­sit un mot, le navi­ga­teur appelle une adresse de la forme votresite.fr/?s=randonnee, et Word­Press inter­prète le s comme une demande de recherche. Il com­pose alors une requête, l’en­voie à la base de don­nées, récu­père la liste des conte­nus cor­res­pon­dants et les affiche dans un gaba­rit dédié, dis­tinct de celui d’une page ordi­naire. Cette page de résul­tats n’est pas une page de votre site : elle est géné­rée à la volée à chaque recherche, et vous ne la trou­ve­rez pas dans l’on­glet « Pages » de votre inter­face d’ad­mi­nis­tra­tion. Nous y reve­nons plus bas.

Tout se joue donc dans la base de don­nées Word­Press, cet ensemble de tables où Word­Press range vos contenus.

Le même gaba­rit gère aus­si le cas où rien ne cor­res­pond : la liste de conte­nus est vide, mais la page s’af­fiche nor­ma­le­ment, avec en géné­ral un mes­sage invi­tant à refor­mu­ler la recherche. Ce n’est pas une erreur ni une page à part, seule­ment la même méca­nique sans résul­tat à afficher.

Soigner l’apparence de la page des résultats de la recherche

Cette page res­semble par­fois assez peu au reste du site : son appa­rence dépend d’un gaba­rit dédié de votre thème, dis­tinct de vos pages ordi­naires. Pen­sez à le tra­vailler comme le reste du site.

Dans un thème à blocs (FSE), il s’é­dite dans Appa­rence > Édi­teur > Modèles > Résul­tats de recherche ; dans un thème clas­sique, il cor­res­pond au fichier search.php ; sous Ele­men­tor Pro, c’est un modèle de résul­tats de recherche à créer dans le Construc­teur de thème ; dans la ver­sion gra­tuite d’E­le­men­tor, faute de Construc­teur de thème, cette page reste gérée par le thème actif, ce qui vous ramène à l’un des deux cas pré­cé­dents. Le nom exact et la marche à suivre peuvent varier selon le thème ou l’ou­til utilisé.

Comment afficher un champ de recherche sur son site

Word­Press four­nit le moteur de recherche, mais votre thème décide si un champ per­met­tant de l’u­ti­li­ser appa­raît sur le site. Cer­tains thèmes l’in­tègrent direc­te­ment dans leur en-tête, tan­dis que d’autres ne l’af­fichent pas par défaut.

Avec un thème basé sur les blocs, ouvrez Appa­rence > Édi­teur, puis modi­fiez l’en-tête ou la par­tie de modèle dans laquelle vous sou­hai­tez pla­cer la recherche. Ajou­tez ensuite le bloc Recherche. Celui-ci peut affi­cher un champ accom­pa­gné d’un bou­ton, un champ seul ou uni­que­ment une icône qui se déploie au clic.

Avec un thème clas­sique, ren­dez-vous géné­ra­le­ment dans Appa­rence > Wid­gets et ajou­tez le bloc Recherche dans une zone pré­vue par le thème, par exemple la barre laté­rale ou le pied de page. Cer­tains thèmes pro­posent éga­le­ment une option dédiée dans leurs réglages pour pla­cer une icône ou un wid­get de recherche dans l’en-tête.

Le bloc peut aus­si être insé­ré direc­te­ment dans une page ou un article, comme n’im­porte quel autre bloc. Ce choix convient à une page de res­sources ou à un cata­logue, mais il ne rend pas la recherche acces­sible depuis l’en­semble du site. Dans la plu­part des cas, l’en-tête reste l’emplacement le plus facile à trou­ver, par­ti­cu­liè­re­ment sur smartphone.

Si votre site uti­lise Ele­men­tor Pro, ouvrez le modèle d’en-tête dans le Construc­teur de thème et ajou­tez le wid­get Recherche à l’emplacement sou­hai­té. Ele­men­tor peut éga­le­ment affi­cher des résul­tats pen­dant la sai­sie et limi­ter la recherche à cer­tains types de conte­nus. Ces options dépassent alors le fonc­tion­ne­ment stric­te­ment natif décrit dans cet article. Avec la ver­sion gra­tuite d’E­le­men­tor, l’af­fi­chage d’un champ dans l’en-tête dépend géné­ra­le­ment des pos­si­bi­li­tés offertes par le thème.

Où WordPress va chercher

Le péri­mètre est net, et c’est le point le plus utile de tout cet article. Word­Press regarde trois choses, et uni­que­ment trois : le titre du conte­nu, son extrait, et le conte­nu lui-même. Rien d’autre n’entre dans la com­pa­rai­son. Une cor­res­pon­dance dans un seul de ces trois champs suf­fit : le mot cher­ché n’a pas besoin de figu­rer dans les trois à la fois.

S’a­joutent deux filtres de bon sens. Pour un inter­naute non connec­té, seuls les conte­nus publi­que­ment acces­sibles sont exa­mi­nés : un brouillon, un conte­nu pro­gram­mé ou un conte­nu pri­vé reste invi­sible. Et les conte­nus pro­té­gés par mot de passe sont écar­tés des résul­tats, ce qui évite de révé­ler par la recherche ce que le mot de passe protège.

Reste la ques­tion des types de conte­nu concer­nés. Par défaut, la recherche couvre les articles et les pages, ain­si que les types de conte­nu per­son­na­li­sés qui n’en ont pas été expli­ci­te­ment exclus. Sur une bou­tique, les fiches pro­duits entrent ain­si géné­ra­le­ment dans les résultats.

La média­thèque consti­tue un cas par­ti­cu­lier. Les fichiers télé­ver­sés sont bien enre­gis­trés comme des conte­nus par Word­Press, avec un titre, une légende et une des­crip­tion, mais ils ne remontent nor­ma­le­ment pas dans les résul­tats de recherche publics. Un thème ou une exten­sion peut néan­moins modi­fier ce com­por­te­ment. Notre article sur la média­thèque Word­Press détaille le rôle des dif­fé­rents champs asso­ciés aux fichiers.

Enfin, toute exten­sion qui crée son propre type de conte­nu peut le rendre cher­chable, et cer­taines le font sans le signa­ler clai­re­ment. Mais on trouve aus­si des types pure­ment tech­niques, créés par une exten­sion pour son usage interne, qui se retrouvent dans la recherche sans que per­sonne l’ait deman­dé. Si vos résul­tats contiennent des entrées incon­grues, l’ex­pli­ca­tion est sou­vent là. La notion de type de conte­nu per­son­na­li­sé est déve­lop­pée dans notre article sur les types de conte­nu dans Word­Press.

Comment les résultats sont classés

Contrai­re­ment à une idée répan­due, les résul­tats ne sortent pas dans l’ordre chro­no­lo­gique. Word­Press applique d’a­bord un clas­se­ment par per­ti­nence, et la date ne sert qu’à dépar­ta­ger les conte­nus à égalité.

Ce clas­se­ment est simple et repose entiè­re­ment sur la place du terme cher­ché. Quand la recherche porte sur un seul mot, les conte­nus qui le portent dans leur titre passent devant, les autres suivent, et chaque groupe est trié du plus récent au plus ancien. Quand elle porte sur plu­sieurs mots, Word­Press dis­tingue cinq niveaux : l’ex­pres­sion com­plète dans le titre, puis tous les mots dans le titre, puis un seul de ces mots dans le titre, puis l’ex­pres­sion com­plète dans l’ex­trait, puis l’ex­pres­sion com­plète dans le contenu.

La logique est cohé­rente : le titre pèse plus que le corps du texte. En contre­par­tie, un conte­nu qui traite par­fai­te­ment le sujet sans en reprendre les mots dans son titre se retrouve méca­ni­que­ment der­rière un conte­nu qui les affiche sans les trai­ter. Le clas­se­ment mesure la posi­tion des mots, pas la qua­li­té de la réponse.

Les règles de correspondance à connaître

Word­Press ne cherche pas un mot, mais une suite de carac­tères exacte, pré­sente n’im­porte où dans le texte. Il ignore qu’un mot a un sin­gu­lier et un plu­riel, ou qu’il peut s’é­crire autre­ment : il com­pare des lettres, rien de plus. Cette seule idée explique la plu­part des surprises.

Pre­mière consé­quence, la com­pa­rai­son fonc­tionne dans un sens mais pas dans l’autre. Cher­cher « chaus­sure » remonte un conte­nu qui écrit « chaus­sures », car la suite « chaus­sure » figure à l’in­té­rieur de « chaus­sures ». L’in­verse échoue : cher­cher « chaus­sures » ne remonte pas un conte­nu qui n’é­crit que « chaus­sure », cette suite plus longue ne s’y trou­vant nulle part. Un conte­nu qui emploie les deux formes est trou­vé dans les deux cas, mais par chance, parce qu’il contient déjà chaque ortho­graphe, non parce que Word­Press rap­proche le sin­gu­lier du pluriel.

Deuxième consé­quence, Word­Press ne cor­rige pas les fautes de frappe et ne connaît ni les syno­nymes ni les abré­via­tions. La com­pa­rai­son est tou­te­fois géné­ra­le­ment insen­sible aux majus­cules et, selon la confi­gu­ra­tion de la base de don­nées, elle peut éga­le­ment igno­rer les dif­fé­rences d’ac­cents. Ce com­por­te­ment vient de la base de don­nées, pas d’une com­pré­hen­sion du mot recherché.

Troi­sième point, et il sur­prend sou­vent : Word­Press écarte les mots très cou­rants. Sur un site en fran­çais, il retire de la recherche une longue liste de mots outils, dont « le », « la », « les », « de », « des », « un », « une », « et », « dans », « pour », « sur » ou « que », ain­si que les lettres iso­lées. Cher­cher « les tarifs de la sai­son » revient donc à cher­cher « tarifs » et « sai­son ». Le garde-fou existe : si votre recherche ne contient que des mots de cette liste, Word­Press la cherche telle quelle, comme une expres­sion entière. « de la » ren­voie donc bien des résultats.

Qua­trième point, la façon dont plu­sieurs mots sont com­bi­nés. Chaque mot doit être pré­sent, mais rien n’im­pose qu’ils soient proches, ni même dans le même champ. Un conte­nu dont le titre porte « tarifs » et dont le der­nier para­graphe men­tionne « sai­son » est un résul­tat valide pour « tarifs sai­son ». C’est la prin­ci­pale source de résul­tats qui semblent hors sujet : ils sont conformes à la règle, la règle ignore sim­ple­ment la notion de contexte.

Deux rac­cour­cis inté­grés, que vos inter­nautes ignorent presque toujours

➔ Les guille­mets cherchent l’ex­pres­sion exacte : "coupe du monde" ne remonte que les conte­nus où ces trois mots se suivent dans cet ordre.
➔ Un tiret pla­cé devant un mot l’ex­clut : maillot -enfant remonte les conte­nus qui parlent de maillot sans par­ler d’enfant.

Les deux fonc­tionnent nati­ve­ment, sans aucune exten­sion. Les men­tion­ner sous votre champ de recherche coûte une ligne et rend le moteur net­te­ment plus maniable.

Ce qui reste hors du périmètre

Puisque la com­pa­rai­son porte sur trois champs, tout ce qui vit ailleurs est invi­sible pour la recherche. Concrètement :

• les champs per­son­na­li­sés, c’est-à-dire les infor­ma­tions ran­gées à part du conte­nu prin­ci­pal : réfé­rence, prix, date d’un évé­ne­ment, coor­don­nées, et de manière géné­rale tout ce qu’un for­mu­laire d’ad­mi­nis­tra­tion ajoute sous l’éditeur ;
• les caté­go­ries et les éti­quettes : un conte­nu clas­sé dans « ran­don­née » ne remonte pas pour « ran­don­née » si le mot n’ap­pa­raît pas dans son texte ;
• les com­men­taires, y com­pris quand ils contiennent la réponse que l’in­ter­naute cherchait ;
• le conte­nu des fichiers : le texte d’un PDF dépo­sé dans la média­thèque n’est pas lu.

Sur une bou­tique Woo­Com­merce, cette liste pro­duit un effet très concret : la réfé­rence d’un pro­duit n’est pas trou­vée. Le titre du pro­duit remonte, sa réfé­rence non, parce qu’elle est ran­gée dans un champ sépa­ré. Le test prend dix secondes sur votre propre site, avec une réfé­rence que vous connaissez.

Cette limite n’est pas un oubli. Aller cher­cher dans tous ces empla­ce­ments sup­po­se­rait de construire et de tenir à jour un index dédié, c’est-à-dire un réper­toire de tous les mots du site avec leur empla­ce­ment. Word­Press ne construit pas cet index : il inter­roge direc­te­ment le texte au moment de la recherche. C’est un choix de concep­tion, avec ses avan­tages, à com­men­cer par le fait que rien ne peut se désynchroniser.

Le cas du constructeur de page Elementor

Le conte­nu d’une page Ele­men­tor est-il trou­vé par la recherche native ? La réponse dépend du wid­get et de la ver­sion. Sur une ver­sion récente, mes tests montrent qu’à l’en­re­gis­tre­ment l’ex­ten­sion reco­pie le texte de ses wid­gets dans le conte­nu de l’ar­ticle, là où la recherche va lire. Je l’ai véri­fié sur trois wid­gets cou­rants, l’é­di­teur de texte, le titre et le bou­ton, cha­cun pré­sent dans le conte­nu de la page et remon­té par la recherche. Le com­por­te­ment peut tou­te­fois varier selon le wid­get, la ver­sion d’E­le­men­tor et le recours à du conte­nu dyna­mique ou à des modèles, cas où le texte reste par­fois ran­gé à part, hors du conte­nu exa­mi­né. À véri­fier sur votre propre site plu­tôt qu’à généraliser.

Pourquoi la recherche WordPress pèse sur le serveur

Ce mode de fonc­tion­ne­ment a un coût.

Une base de don­nées va vite parce qu’elle s’ap­puie sur des index, l’é­qui­valent de l’in­dex d’un livre : au lieu de tout lire, elle saute direc­te­ment aux empla­ce­ments utiles. Mais, pour une recherche tex­tuelle, un index clas­sique est sur­tout effi­cace lorsque la valeur com­mence par la suite de carac­tères recher­chée. Or Word­Press cherche un frag­ment pou­vant se situer n’im­porte où à l’in­té­rieur du texte. L’in­dex ne peut alors plus être exploi­té effi­ca­ce­ment, et la base doit exa­mi­ner l’en­semble des conte­nus à chaque recherche.

Deux effets en découlent. Le coût aug­mente avec le volume de conte­nus, là où un index dédié le main­tien­drait à peu près stable. Et le cache de pages aide géné­ra­le­ment peu : les pages de recherche conte­nant un para­mètre dans leur adresse sont sou­vent exclues du cache, et la grande varié­té des termes sai­sis limite les pos­si­bi­li­tés de réuti­li­sa­tion. Sur un site de quelques dizaines de pages, cela ne se voit pas. Sur un cata­logue impor­tant, ou sur un site visi­té par de nom­breux robots qui déclenchent des recherches, cela devient visible. Si vous vou­lez mesu­rer plu­tôt qu’es­ti­mer, notre article sur l’a­na­lyse des len­teurs PHP avec PHP X‑Ray explique com­ment obser­ver le coût réel d’une page, recherche comprise.

À noter que MyS­QL (ou MariaDB), le ges­tion­naire de base de don­nées uti­li­sé par Word­Press, sait faire autre­ment, avec un mode de recherche en texte inté­gral conçu pour cet usage. Word­Press ne l’emploie pas par défaut.

Les pages de résultats et l’indexation par Google

Les pages de résul­tats de recherche (?s=...) sont acces­sibles par une adresse comme n’im­porte quelle autre page du site, donc visibles par les robots d’ex­plo­ra­tion de Google. Le risque théo­rique est réel : du conte­nu jugé pauvre ou dupli­qué, une page qui change à chaque requête, poten­tiel­le­ment de nom­breuses variantes indexées si des inter­nautes, ou des robots, génèrent des recherches variées.

Depuis Word­Press 5.7 (2021), le cœur de Word­Press traite ce cas nati­ve­ment : une balise noindex est ajou­tée auto­ma­ti­que­ment à l’en-tête de toute page de résul­tats de recherche, via son API de ges­tion des balises robots. Sur un site à jour, cette pro­tec­tion est donc déjà active, sans réglage à faire.

Com­ment véri­fier que c’est bien le cas sur votre site

➔ Ouvrez une page de résul­tats de recherche (votresite.fr/?s=test)
➔ Affi­chez le code source et cher­chez la balise <meta name="robots" ...> dans l’en-tête
➔ Elle doit conte­nir noindex

Deux cas font excep­tion à cette pro­tec­tion par défaut : un site res­té sur une ver­sion ancienne de Word­Press, et un thème per­son­na­li­sé dont l’en-tête ne charge pas cor­rec­te­ment les fonc­tions natives de Word­Press. Une exten­sion de réfé­ren­ce­ment peut aus­si modi­fier ou rem­pla­cer cette balise avec son propre réglage : là encore, mieux vaut véri­fier son conte­nu que le sup­po­ser correct.

Un point de vigi­lance sou­vent confon­du avec le pre­mier : blo­quer ces URL via le fichier robots.txt n’a pas le même effet qu’une balise noindex, et peut même être contre-pro­duc­tif. Le fichier robots.txt empêche l’ex­plo­ra­tion d’une page, pas son indexa­tion : une page déjà connue de Google peut res­ter indexée alors même qu’elle est blo­quée à l’ex­plo­ra­tion, puisque Google ne peut plus reve­nir véri­fier son conte­nu ni sa balise noindex.

Élargir le périmètre

Trois voies existent, d’ef­fort crois­sant, et le bon choix dépend sur­tout de la place que la recherche occupe réel­le­ment dans les par­cours de vos internautes.

La pre­mière ne touche pas au moteur : elle réduit le besoin de s’en ser­vir. Un menu clair, des caté­go­ries cohé­rentes, des titres qui reprennent les mots que vos inter­nautes emploient réel­le­ment, et une page lis­tant les conte­nus prin­ci­paux règlent une bonne part des recherches infruc­tueuses. Dans la même logique, il est sou­vent utile de res­treindre plu­tôt que d’é­lar­gir : reti­rer des résul­tats les types de conte­nu tech­niques ajou­tés par vos exten­sions rend la recherche immé­dia­te­ment plus lisible. Cette voie est gra­tuite et sans effet de bord, mais elle ne rend pas le moteur plus intel­li­gent : il conti­nue­ra d’i­gno­rer les fautes de frappe et les champs personnalisés.

La deuxième consiste à ins­tal­ler une exten­sion qui construit son propre index. Le prin­cipe change : au lieu d’in­ter­ro­ger le texte à chaque recherche, l’ex­ten­sion tient à jour un réper­toire des mots du site, ce qui lui per­met d’al­ler cher­cher dans les champs per­son­na­li­sés, les caté­go­ries, les com­men­taires, par­fois le conte­nu des docu­ments, et de tolé­rer les approxi­ma­tions. En contre­par­tie, cet index occupe de la place, doit être recons­truit après un import mas­sif, et ajoute une exten­sion de plus à main­te­nir. C’est la réponse habi­tuelle dès qu’un site a beau­coup de conte­nus et que la recherche est réel­le­ment utilisée.

La troi­sième déporte l’in­dex chez un pres­ta­taire spé­cia­li­sé. Le site lui envoie ses conte­nus, et l’in­ter­roge au moment d’une recherche. Les résul­tats sont rapides et fins, y com­pris sur de très gros volumes, et la charge quitte votre héber­ge­ment. Les contre­par­ties sont réelles : un abon­ne­ment, une dépen­dance à un ser­vice tiers, et vos conte­nus qui tran­sitent vers l’ex­té­rieur, ce qui demande d’être regar­dé de près si votre site traite des don­nées sen­sibles. Cette voie se jus­ti­fie sur­tout pour les cata­logues impor­tants ou les sites sur les­quels la recherche joue un rôle central.

Avant de choi­sir, une étape simple évite de se trom­per : regar­dez ce que vos inter­nautes cherchent réel­le­ment. Un site sur lequel la recherche est uti­li­sée dix fois par mois et un site sur lequel elle ouvre la moi­tié des par­cours n’ap­pellent pas la même réponse.

À retenir

• Word­Press com­pare le terme cher­ché à trois champs seule­ment : le titre, l’ex­trait et le conte­nu. Tout le reste lui est invisible.
• Les résul­tats sont clas­sés par per­ti­nence, pas par date, et cette per­ti­nence se résume à la posi­tion des mots, le titre pesant plus que le corps du texte.
• Le moteur cherche une suite de carac­tères : ni fautes de frappe, ni syno­nymes, ni plu­riels rat­tra­pés. La com­pa­rai­son ignore géné­ra­le­ment les majus­cules et peut aus­si igno­rer les accents selon la base de données.
• Deux fonc­tions natives méritent d’être connues de vos inter­nautes : les guille­mets pour une expres­sion exacte, le tiret pour exclure un mot.
• Les champs per­son­na­li­sés, les caté­go­ries, les com­men­taires et le conte­nu des fichiers res­tent hors péri­mètre. Sur une bou­tique Woo­Com­merce, cela se tra­duit par une réfé­rence pro­duit introu­vable.
• Pour aller plus loin, trois voies : struc­tu­rer le site, indexer avec une exten­sion, ou dépor­ter l’in­dex.

Le moteur natif fait exac­te­ment ce pour quoi il a été conçu : retrou­ver un texte dans un texte, sans dépen­dance et sans main­te­nance. Savoir où s’ar­rête ce péri­mètre est ce qui per­met de déci­der s’il vous suffit.