# wp_robots dans WordPress 5.7, un an après : ce qui a vraiment changé pour le SEO

> Le filtre wp_robots a remplacé une décennie de fonctions maison bricolées. Bilan, presque un an après son arrivée, sur ce qu'il a réellement simplifié.

- Auteur : Clément Hadrot
- Publié le : 2021-12-16
- Mis à jour le : 2021-12-16
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/wp-robots-wordpress-57-un-an-apres/

## L’essentiel

- wp_robots unifie un mécanisme jusque-là dispersé entre plusieurs fonctions non filtrables
- Les extensions SEO majeures ont migré vers ce filtre en quelques mois
- Les anciennes fonctions maison sur wp_head continuent de fonctionner mais ne devraient plus être utilisées

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.

> L'essentiel à retenir : wp_robots unifie un mécanisme jusque-là dispersé entre plusieurs fonctions non filtrables ; Les extensions SEO majeures ont migré vers ce filtre en quelques mois ; Les anciennes fonctions maison sur wp_head continuent de fonctionner mais ne devraient plus être utilisées

## 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-snippet` et `max-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.