Créez votre site WordPress avec Elementor.Découvrir Elementor Lien partenaire

LANGUES DE BLOGPASCHER

Archives par langue

Choisissez une archive disponible ou retrouvez les langues prévues pour les traductions.

Archives disponibles

Traductions prévues (32)
  • Englishanglais
  • Españolespagnol
  • Deutschallemand
  • Portuguêsportugais
  • Italianoitalien
  • Nederlandsnéerlandais
  • Polskipolonais
  • Українськаukrainien
  • Češtinatchèque
  • Slovenčinaslovaque
  • Hrvatskicroate
  • Românăroumain
  • Magyarhongrois
  • Ελληνικάgrec
  • Türkçeturc
  • العربيةarabe
  • עבריתhébreu
  • हिन्दीhindi
  • বাংলাbengali
  • ไทยthaï
  • Tiếng Việtvietnamien
  • Bahasa Indonesiaindonésien
  • 简体中文chinois simplifié
  • 日本語japonais
  • 한국어coréen
  • Danskdanois
  • Svenskasuédois
  • Norsknorvégien
  • Suomifinnois
  • Eestiestonien
  • Latviešuletton
  • Lietuviųlituanien

Apparence du site

Éditeur et contenus · Intermédiaire

Rendre un type de fiche visible dans la recherche WordPress

Retrouvez pourquoi des fiches publiques manquent à la recherche WordPress en vérifiant le type de contenu, la requête et le modèle de résultats.

Chercher un titre connu pour isoler le problème

Une fiche de ressource est publiée et s’ouvre à son adresse, mais la recherche interne ne la propose jamais. Reproduisez d’abord l’écart avec un mot distinctif qui figure dans le titre de la fiche. Utilisez un mot assez rare pour reconnaître le résultat et vérifiez qu’il existe réellement dans le titre enregistré. Si la fiche ressort avec ce mot, puis disparaît quand vous cherchez une référence conservée dans un champ personnalisé, examinez l’indexation de ce champ. Si aucun titre de ce type de contenu ne ressort alors que les articles ordinaires ressortent, poursuivez ici.

Ouvrez la fiche et la recherche dans la même session de visite, sans connexion à l’administration. Notez le domaine, le sous-site si nécessaire, la langue de la fiche, son statut et la page qui répond à la recherche. Un brouillon, une fiche privée ou une fiche réservée à certains comptes demande une autre décision. Confirmez auprès du responsable que la fiche et les autres contenus du même type sont destinés à être trouvés par le public. Une fiche visible pour un administrateur peut répondre différemment pour un visiteur.

Comparez deux chemins. Utilisez le champ de recherche qui posait problème, puis la recherche générale du site avec le même terme si elle est disponible. Sur une installation qui utilise la recherche standard, une adresse telle que https://recette.example/?s=astere permet de comparer ce deuxième chemin. Adaptez-la à votre site et à votre langue. Certains formulaires envoient vers une page de répertoire ou transmettent un filtre de type. Si les résultats diffèrent, notez les deux adresses finales. Vous devez savoir quel formulaire a produit la liste que vous voulez corriger.

Relever la clé du type et ses paramètres effectifs

Identifiez la clé technique du type de contenu. Une interface peut afficher « Ressources » alors que la clé vaut ressource. Dans la liste d’administration du type, le paramètre post_type peut fournir un indice. Confirmez-le avec la personne qui maintient la déclaration, qu’elle se trouve dans une extension, le thème ou une interface de configuration. Le nom d’une catégorie ou d’un modèle de page ne désigne pas forcément un type de contenu.

Si WP-CLI est déjà disponible sur la copie, le mainteneur peut lire l’objet déclaré avec wp --path=/srv/recette/wordpress --url=https://recette.example post-type get ressource --fields=name,public,publicly_queryable,exclude_from_search,has_archive --format=json. Adaptez le chemin, l’adresse et la clé. En multisite, sélectionnez le sous-site auquel appartiennent les fiches. La commande montre la déclaration après chargement du site et de ses extensions. Comparez-la à la configuration prévue. Si la clé n’existe pas ou si les champs relevés diffèrent, contrôlez d’abord le site sélectionné et la version du composant qui déclare le type.

Notez séparément les paramètres. public fournit des valeurs par défaut à plusieurs options. publicly_queryable intervient dans l’accès aux requêtes publiques. exclude_from_search détermine notamment l’inclusion du type lorsque la requête demande les types recherchables avec post_type réglé sur any. has_archive concerne l’archive du type. Une archive ouverte et un lien direct fonctionnel n’établissent pas que la recherche inclut le type. De même, faire apparaître la fiche dans la recherche ne nécessite pas de créer une archive. Gardez le relevé des valeurs avant tout changement.

Approche 1. Corriger la déclaration du type

Si exclude_from_search est vrai et que tout le type est destiné à la recherche publique, ouvrez la configuration qui fait autorité pour ce type. Avec une interface de déclaration, repérez l’option qui exclut des résultats de recherche. Certains écrans présentent au contraire une case d’inclusion. Lisez l’intitulé et le texte d’aide avant de changer la valeur. Enregistrez sur la copie et confirmez, si possible avec la commande précédente, que exclude_from_search vaut maintenant faux pour ce seul type. Si la déclaration est maintenue en PHP dans votre projet, ajustez cet argument dans la définition versionnée.

Laissez les règles d’accès, l’archive et les autres valeurs au niveau prévu par le site. Un type peut être volontairement exclu parce qu’il contient des entrées techniques, des fiches internes ou des données publiées seulement dans un contexte particulier. Si seule une partie du type doit ressortir, demandez au mainteneur un filtre adapté à ce périmètre. Activer un réglage général pour retrouver une seule fiche peut élargir la liste à toutes les fiches de ce type. Sur la copie, choisissez aussi une fiche que le public ne doit pas retrouver et contrôlez ce contre-exemple.

Vérifiez le résultat avec le titre témoin et une recherche d’article ordinaire. Si l’objet déclaré montre la nouvelle valeur et que la fiche reste absente, gardez la preuve du réglage et passez à la requête ou au modèle. Selon le site, la recherche peut être limitée à certains types après la déclaration. Une extension d’indexation peut aussi utiliser ses propres types autorisés et demander une reconstruction selon ses options. Repérez d’abord le mécanisme réellement utilisé, puis suivez son parcours existant. La recherche native du cœur ne demande pas de réindexation manuelle pour ce changement.

Approche 2. Appliquer un filtre ciblé sur la déclaration

Ce fragment est destiné à un mainteneur sur une copie autorisée, lorsque le type est enregistré par un composant dont les fichiers ne doivent pas être modifiés et que le diagnostic a confirmé l’exclusion par la déclaration. Si votre extension de site possède déjà une règle à cet endroit, modifiez cette règle dans le fichier PHP existant. Si vous y intégrez le filtre, reprenez l’appel et sa fonction dans la partie PHP du fichier. L’en-tête du fragment sert à l’extension dédiée. Sinon, placez le fragment complet dans wp-content/plugins/bpc-ressources-recherche/bpc-ressources-recherche.php. Remplacez la clé d’exemple ressource par celle confirmée. Activez l’extension depuis l’écran Extensions du site de recette concerné. En réseau, utilisez l’administration de ce site pour limiter l’essai à ce sous-site.

Le filtre doit être enregistré avant que le type soit déclaré. Il convient notamment aux types déclarés plus tard pendant init. Si le type est enregistré plus tôt par un autre composant, faites vérifier l’ordre de chargement par son mainteneur et contrôlez la valeur effective après activation. Le fragment exige que le type soit déclaré public et consultable. Il tient compte de la valeur héritée de public lorsque publicly_queryable est absent ou nul. Si un filtre plus tardif ou le filtre propre au type redéfinit l’exclusion, la lecture de l’objet chargé doit révéler cet écart. Le changement porte uniquement sur exclude_from_search. Faites néanmoins un essai en visiteur et contrôlez les fiches que votre site réserve à certains comptes. L’accès effectif peut dépendre d’autres règles.

Après activation sur la copie, relisez le type et refaites la recherche témoin. Si la déclaration a changé mais qu’une autre recherche fondée sur any montre aussi les fiches, évaluez cette conséquence avant de retenir le filtre. Le changement porte sur le type dans le site et peut toucher d’autres listes qui s’appuient sur les mêmes types recherchables. Si vous souhaitez corriger seulement un répertoire précis, intervenez dans la requête de ce répertoire. Pour annuler l’essai, désactivez l’extension dédiée ou rétablissez la version précédente de la règle existante.

<?php
/**
 * Plugin Name: BPC Ressources dans la recherche
 */

defined('ABSPATH') || exit;

add_filter('register_post_type_args', static function (array $args, string $post_type): array {
    $public = $args['public'] ?? false;
    $queryable = $args['publicly_queryable'] ?? $public;

    if ('ressource' === $post_type && $public && $queryable) {
        $args['exclude_from_search'] = false;
    }

    return $args;
}, 10, 2);

Approche 3. Ajuster la requête ou le modèle de résultats

Si le type est inclus dans la déclaration, comparez les paramètres du formulaire et la requête qui produit la page. Une requête qui indique une liste explicite de types peut continuer à ne retenir que les articles, même si les Ressources sont recherchables dans une requête générale. Cherchez un filtre dans le formulaire, le code de recherche du thème ou l’extension qui gère le répertoire. Modifiez la liste existante sur la copie si elle doit désormais contenir les Ressources. Conservez les types qui étaient déjà prévus et vérifiez les autres filtres, notamment la langue et les termes.

Avec un thème à blocs, ouvrez Apparence > Éditeur > Modèles et recherchez le modèle de résultats, si vous disposez des droits correspondants. Sélectionnez la Boucle de requête qui affiche la liste principale. Dans les versions qui exposent le type de requête, le mode Par défaut permet de reprendre la requête du modèle. Une boucle personnalisée peut appliquer son propre type, ses propres filtres et un ordre sans rapport avec le terme recherché. Sur la copie, réglez seulement la boucle qui doit représenter les résultats de recherche. Gardez une boucle séparée pour les contenus suggérés si le modèle en prévoit une.

Avec un thème classique ou une extension de recherche, demandez au mainteneur de repérer si la requête principale est modifiée ou si le modèle lance une requête secondaire. Si une règle de pre_get_posts modifie le périmètre, examinez ses conditions. Dans un parcours classique, le mainteneur peut cibler la requête publique principale de recherche en vérifiant le contexte d’administration et les méthodes de l’instance reçue. Un formulaire de répertoire, une requête AJAX ou un moteur d’indexation peut suivre une autre voie. Corrigez la couche qui produit réellement la liste et gardez le reste du site hors de l’essai.

Suivre les variantes qui changent le diagnostic

Si un article et une fiche contiennent le même terme mais que seule la fiche disparaît, contrôlez d’abord que le formulaire inclut bien son type et que son statut est autorisé. Comparez une fiche du même type qui fonctionne si vous en avez une. Si une seule fiche manque, relevez la langue, l’état de publication, les filtres du répertoire et sa position éventuelle sur une autre page de résultats. Si aucun titre ne ressort pour le type, vérifiez à nouveau les paramètres de déclaration et la liste des types avant de modifier le texte des fiches.

Si les fiches ressortent dans la recherche standard mais manquent dans un formulaire spécialisé, concentrez-vous sur les options du répertoire. Relevez le type attendu et reproduisez l’essai sans filtre de catégorie ou de langue uniquement lorsque la copie le permet. Ajoutez les filtres un à un pour voir lequel écarte le témoin. Après avoir retrouvé le bon périmètre, remettez les filtres nécessaires. Conservez la définition WordPress si elle était déjà correcte. Si le répertoire est conçu pour une catégorie particulière, vérifiez aussi le témoin qui possède cette catégorie et celui qui ne la possède pas. Le formulaire doit continuer à séparer ces deux cas après la correction.

Si les résultats contiennent la fiche mais que la carte mène à une autre adresse ou n’affiche aucun titre, ouvrez le modèle de la carte et vérifiez la liaison avec la publication courante. Si la liste elle-même est vide, vérifiez aussi le modèle avant de conclure à une exclusion. Pour distinguer requête et rendu, conservez une recherche qui retourne au moins un article ordinaire. Un modèle qui échoue avec tous les types oriente vers la présentation. Un modèle qui rend les articles et pas les Ressources justifie de comparer les filtres de type et le comportement de la carte pour une Ressource.

Vérifier le résultat avec des témoins qui doivent rester distincts

Sur votre copie autorisée, préparez une Ressource publique « Astrolune – ressource témoin » et un article ordinaire « Astrolune – article témoin ». Ajoutez un brouillon et une fiche privée du type Ressource portant le même mot. Si votre site a un autre type volontairement exclu, préparez aussi une fiche publique « Astrolune – type exclu » dans ce type. Relevez les identifiants, les statuts et les liens. Depuis une session de visite, lancez la recherche « Astrolune » avant le changement et ouvrez directement la Ressource publique. Le lien direct et la présence dans les résultats sont deux observations distinctes.

Effectuez un seul changement et recherchez « Astrolune » depuis le formulaire initial. Comparez avec la recherche générale si les deux parcours diffèrent. Dans une recherche qui doit couvrir les Ressources et les articles, la Ressource publique doit rejoindre l’article ordinaire. Vérifiez que ni le brouillon, ni la fiche privée, ni le type exclu n’apparaissent dans cette liste. Ouvrez le résultat de la Ressource et contrôlez qu’il mène au bon identifiant. Vérifiez aussi la pagination, si elle existe, et le filtre de langue avec un témoin qui doit rester hors du périmètre.

Notez le rôle du visiteur de test, le formulaire utilisé et le nombre de résultats utiles. Comparez une recherche sans résultat pour vous assurer que le modèle garde son comportement habituel. Contrôlez également une liste ordinaire du site qui utilise les mêmes fiches. Un essai qui remet un type dans la recherche mais fait apparaître des contenus inattendus ailleurs demande de resserrer le périmètre avant la mise en service.

Revenir au réglage initial si le périmètre s’élargit trop

Si des fiches non prévues apparaissent ou que les résultats ordinaires disparaissent, rétablissez le changement réellement effectué. Remettez l’option d’exclusion dans la définition si vous avez modifié la déclaration, désactivez le filtre dédié si vous avez ajouté l’extension de recette, ou remettez la liste de types précédente si le formulaire était limité par sa requête. Si vous avez modifié un modèle, restaurez la configuration de la boucle ciblée. Contrôlez la recherche et les listes concernées après le retour. Si vous avez rétabli le filtre d’une extension, vérifiez avec la commande de lecture que la valeur chargée est bien celle du relevé initial. Le réglage affiché dans un écran peut encore être remplacé par une règle maintenue ailleurs.

Gardez le relevé de départ et celui de l’état retenu. Indiquez la clé du type, la couche qui décidait du périmètre, la langue et le formulaire testés. Précisez aussi quels types et quels statuts doivent rester absents des résultats de visite. Après un changement de thème, d’extension ou de formulaire, l’équipe pourra retrouver la bonne couche à partir du titre témoin et vérifier le lien direct, le résultat et les contre-exemples dans la même session.

Notre méthode éditoriale

Ces guides peuvent aussi vous aider