Quand WordPress 5.7 est sorti en mars 2021 avec le nouveau filtre wp_robots, l’annonce est passée relativement inaperçue comparée à d’autres nouveautés de cette version. Pourtant, ce filtre unifie un mécanisme que chaque développeur bricolait jusque-là à sa façon : la génération de la balise meta robots, jusqu’alors éparpillée entre des fonctions non filtrables du cœur et des solutions maison accrochées directement sur wp_head.
Neuf mois après sa sortie, ce bilan revient sur ce que wp_robots a réellement changé dans la pratique quotidienne, classé par ordre d’impact décroissant.
Impact majeur : un point d’entrée unique et filtrable
Avant WordPress 5.7, la balise noindex posée automatiquement sur les pages de résultats de recherche ou les archives vides était générée par du code non filtrable dans le cœur, ce qui obligeait à retirer l’action existante puis à en ajouter une nouvelle pour la modifier, une manipulation fragile et peu documentée. Le filtre wp_robots change cela radicalement : n’importe quelle extension ou fonction peut désormais ajouter, retirer ou modifier une directive robots via un simple tableau associatif, sans toucher aux actions internes du cœur.
add_filter( 'wp_robots', function ( $robots ) {
if ( is_post_type_archive( 'evenement' ) ) {
$robots['noindex'] = true;
}
return $robots;
} );
Impact notable : l’adoption rapide par les extensions SEO majeures
En quelques mois, les principales extensions SEO du marché ont migré leur génération de balise meta robots vers ce nouveau filtre plutôt que de continuer à écrire directement dans wp_head par leurs propres moyens. Cette convergence a un effet concret : les conflits entre deux extensions qui tentaient chacune de poser leur propre balise robots, un problème réel avant 5.7, deviennent nettement plus rares, puisque toutes passent désormais par le même tableau filtrable, fusionné une seule fois avant l’affichage final.
Impact limité : les anciennes méthodes restent fonctionnelles
Un point moins souvent souligné dans les annonces de sortie : les anciennes fonctions accrochées manuellement sur wp_head pour afficher une balise meta robots continuent de fonctionner sans erreur après la mise à jour vers WordPress 5.7. Rien ne casse automatiquement. Le risque, purement pratique, est de se retrouver avec deux balises meta robots dans le même document si l’ancienne méthode n’est pas retirée après avoir adopté wp_robots, un doublon que les moteurs de recherche gèrent en général en appliquant la directive la plus restrictive, mais qui reste un signal de code mal nettoyé.
Impact anecdotique : la syntaxe du tableau elle-même
Le tableau associatif attendu par le filtre reste simple : chaque clé correspond à une directive (noindex, nofollow, noarchive, max-snippet avec une valeur numérique, etc.), et sa valeur booléenne ou numérique en détermine la présence dans la balise finale. La fonction wp_robots_noindex(), ajoutée en même temps, sert d’exemple de référence pour construire ses propres filtres personnalisés.
Les directives que le tableau accepte concrètement
noindex: empêche l’apparition de la page dans les résultats de recherche.nofollow: empêche la transmission de crédit vers les liens sortants de la page.noarchive: empêche Google de proposer une version en cache de la page.max-snippetetmax-image-preview: limitent la longueur de l’extrait ou la taille de l’aperçu d’image affichés dans les résultats.
Ce qui n’a pas changé
Le filtre wp_robots ne modifie en rien le fonctionnement du robots.txt, resté sur son propre mécanisme via le filtre robots_txt évoqué dans un précédent article. Les deux systèmes continuent de coexister sans lien direct entre eux, une distinction qui reste source de confusion chez les développeurs qui découvrent le sujet pour la première fois.
Bilan neuf mois après
Sur les projets suivis depuis la sortie de WordPress 5.7, la migration vers wp_robots a été systématique dès qu’une mise à jour de version était de toute façon prévue, sans jamais poser de problème de compatibilité. Le principal bénéfice observé n’est pas une nouvelle fonctionnalité spectaculaire, mais une réduction nette des conflits silencieux entre extensions qui se disputaient jusque-là la même balise meta, un problème de plomberie interne enfin traité à la racine par le cœur de WordPress.
