wp_robots dans WordPress 5.7 : contrôler noindex et l’indexation finement

Pendant des années, contrôler la balise meta robots d’une page WordPress relevait souvent du bricolage : une extension SEO ajoutait sa propre logique via wp_head, une autre extension de sécurité ajoutait la sienne de son côté, et parfois un développeur ajoutait encore une troisième couche pour un cas très spécifique. Résultat visible dans le code source : deux balises meta name="robots" concurrentes, dont l’une écrasait silencieusement l’autre selon l’ordre d’exécution des hooks.

WordPress 5.7, sorti en mars 2021, a mis fin à ce désordre en introduisant un point d’entrée unique : le filtre wp_robots. Comprendre son fonctionnement change la façon d’écrire tout code qui doit influencer l’indexation d’une page.

Un tableau associatif plutôt qu’une chaîne de caractères

Avant WordPress 5.7, gérer soi-même la balise meta robots impliquait de construire directement une chaîne de caractères du type noindex, nofollow, avec tous les risques de doublons ou de virgules mal placées que cela comportait quand plusieurs sources intervenaient. Le filtre wp_robots fonctionne différemment : il reçoit et retourne un tableau associatif, où chaque directive est une clé, et WordPress se charge lui-même d’assembler la chaîne finale et de gérer les doublons.

add_filter( 'wp_robots', function( $robots ) {
    if ( is_singular( 'brouillon_interne' ) ) {
        $robots['noindex']  = true;
        $robots['nofollow'] = true;
    }
    return $robots;
} );

Cette structure en tableau rend la composition de plusieurs sources triviale : une extension peut ajouter noindex pour une raison, une autre ajouter noarchive pour une autre raison, sans qu’aucune des deux n’écrase le travail de l’autre. C’est un changement d’architecture discret, mais qui règle un problème réel rencontré sur beaucoup de sites avant 2021.

Ce que WordPress ajoute déjà par défaut

Le filtre wp_robots n’est pas un filtre vide : WordPress y accroche déjà plusieurs fonctions natives. La plus connue est wp_robots_no_robots, qui ajoute noindex, nofollow dès lors que le réglage Réglages > Lecture > Visibilité par les moteurs de recherche est décoché. C’est cette même case, présente depuis les débuts de WordPress, qui pilote désormais ce filtre moderne en coulisses.

D’autres fonctions natives s’y accrochent aussi selon le contexte : wp_robots_noindex_search() ajoute un noindex sur les pages de résultats de recherche interne, tandis que wp_robots_max_image_preview_large() ajoute la directive max-image-preview:large par défaut, une directive qui autorise les moteurs de recherche à afficher des aperçus d’image en grand format dans leurs résultats, plutôt que la miniature réduite qu’ils utiliseraient sinon.

Écrire une règle conditionnelle propre

La bonne pratique consiste à toujours vérifier le contexte avant de modifier le tableau, plutôt que d’écraser des directives déjà présentes :

add_filter( 'wp_robots', function( $robots ) {
    if ( is_post_type_archive( 'evenement_passe' ) ) {
        $robots['noindex'] = true;
    }
    return $robots;
} );

Cette écriture ajoute une directive sans jamais retirer celles posées par d’autres fonctions, natives ou tierces. C’est exactement le comportement attendu d’un filtre WordPress bien conçu : chaque acteur ajoute sa contribution, sans supposer être le seul à intervenir sur le tableau.

Les directives les plus utiles au quotidien

• noindex : empêche l’indexation de la page, sans empêcher l’exploration des liens qu’elle contient.
• nofollow : demande de ne pas suivre les liens sortants de la page (rarement utile combiné à noindex, sauf cas très spécifiques).
• noarchive : empêche la mise en cache de la page par le moteur de recherche.
• max-snippet, max-image-preview, max-video-preview : contrôlent la taille des extraits affichés en résultat de recherche.

Un piège fréquent : le mélange ancien et nouveau code

Sur des sites migrés depuis longtemps, il n’est pas rare de retrouver encore un ancien code accroché directement à wp_head qui imprime sa propre balise meta name="robots", en parallèle du filtre wp_robots natif désormais actif. Le résultat visible dans le code source est alors deux balises meta robots distinctes, exactement le problème que WordPress 5.7 était censé résoudre. La correction consiste simplement à retirer l’ancien code accroché à wp_head et à migrer sa logique vers le filtre wp_robots.

Dès qu’un audit technique révèle deux balises meta robots sur une même page, la cause est presque toujours la même : un vieux bout de code jamais migré vers wp_robots depuis l’arrivée de WordPress 5.7.

En résumé

Le filtre wp_robots centralise proprement toute la logique d’indexation d’une page WordPress depuis la version 5.7. Son fonctionnement en tableau associatif, plutôt qu’en chaîne de caractères assemblée à la main, évite les conflits entre sources multiples et rend le code beaucoup plus lisible. Sur tout projet plus ancien, un rapide audit du code source suffit à repérer les balises meta robots injectées à l’ancienne, candidates naturelles à une migration vers ce filtre moderne.