« Une Ability décrit une capacité que votre site expose de façon structurée, avec un contrat d’entrée et de sortie explicite, indépendamment de tout rendu visuel. » C’est en substance ce qu’indique la documentation technique publiée autour de l’intégration des Abilities API dans le cœur de WordPress 6.9, sortie en décembre 2025. Pour un développeur habitué à raisonner en pages, URL et balises meta, cette description peut sembler abstraite — et pourtant elle a des conséquences très concrètes sur la façon dont un site expose désormais son contenu à des systèmes tiers, dont les agents IA qui s’appuient sur le protocole MCP, disponible depuis novembre 2024 et de plus en plus relié à WordPress via des adaptateurs dédiés apparus courant 2025.
La question qui se pose naturellement à un développeur soucieux de SEO est simple : ce nouveau canal remplace-t-il, complète-t-il, ou risque-t-il de perturber l’indexation classique par les moteurs de recherche ? La réponse tient en une distinction structurelle qu’il vaut mieux comprendre avant de déployer quoi que ce soit en production.
Ce qu’une Ability expose réellement
Une Ability, dans le vocabulaire introduit par cette API, est une fonction enregistrée par un plugin ou un thème, avec un schéma d’entrée, un schéma de sortie, et des métadonnées décrivant son usage. Elle est déclarée côté serveur via une fonction dédiée, dans l’esprit de ce que fait déjà register_rest_route() pour l’API REST, mais avec un objectif différent : rendre une capacité découvrable et invocable par un agent externe, pas afficher une page à un visiteur humain.
wp_register_ability( 'monsite/rechercher-articles', array(
'label' => 'Rechercher des articles publiés',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'mot_cle' => array( 'type' => 'string' ),
),
),
'execute_callback' => 'monsite_ability_rechercher_articles',
) );Ce mécanisme ne génère ni URL publique, ni entrée de sitemap, ni balisage Schema.org : il fonctionne via un canal d’invocation distinct, généralement exposé par un serveur MCP adossé au site, que seul un client autorisé (un agent IA, un outil interne) peut solliciter. Autrement dit, une Ability n’est pas une page, et son existence n’a aucun effet automatique sur l’indexation Google.
La cohabitation avec l’indexation traditionnelle
C’est là que la distinction devient importante pour un développeur SEO. Les deux canaux — rendu HTML public destiné à Googlebot et aux navigateurs, et Abilities exposées via MCP à des agents autorisés — opèrent sur des couches complètement séparées de la même donnée. Une fiche produit reste indexable normalement par Google via son URL habituelle, son sitemap, son balisage Product en JSON-LD ; en parallèle, une Ability peut exposer une capacité de recherche structurée sur ce même catalogue, invocable uniquement par un client MCP authentifié, sans jamais transiter par une URL publique explorée par un robot classique.
Cette séparation évite un écueil qu’on aurait pu craindre : que l’exposition d’un contenu via les Abilities API dilue ou modifie la façon dont Google perçoit le site. Ce n’est pas le cas, à condition de ne pas mélanger les deux registres par erreur — par exemple en exposant, via une Ability mal conçue, un contenu qui devrait rester privé (données de commande, informations personnelles), ce qui relèverait davantage d’un problème de sécurisation des accès que d’un problème SEO à proprement parler, et qui sort du périmètre traité ici.
Un point de vigilance : la découvrabilité du manifeste
WordPress expose la liste des Abilities disponibles via un point d’entrée dédié, comparable dans l’esprit à ce que wp-json/ fait pour l’API REST. Il est recommandé de vérifier que ce point d’entrée ne se retrouve pas accidentellement référencé dans le sitemap XML ou dans le fichier robots.txt comme s’il s’agissait d’une ressource de contenu classique — ce serait une confusion de nature, puisqu’il s’agit d’un point de découverte technique pour des agents, pas d’une page destinée à un classement dans les résultats de recherche.
Ce que cela change concrètement dans une stratégie de contenu technique
Pour un développeur qui gère à la fois le SEO classique et l’exposition à des agents externes, trois habitudes se dessinent déjà sur les premiers projets ayant adopté cette API :
- Garder deux checklists distinctes : une pour le rendu public (balisage, sitemap, canonical), une pour les Abilities (schémas d’entrée/sortie, documentation du contrat, authentification du client appelant).
- Ne jamais dupliquer manuellement le contenu d’une fiche produit dans une Ability : faire lire l’Ability depuis la même source de données que le rendu public, pour éviter toute divergence entre ce que Google voit et ce qu’un agent MCP reçoit.
- Documenter clairement, dans le code, la différence entre une route REST publique (indexable, cachable, visible des robots classiques) et une Ability (invocable uniquement par un client autorisé, jamais explorée par un crawler web standard).
Une Ability n’est pas une page qui manque à votre sitemap : c’est un canal différent, avec des règles différentes, et il vaut mieux ne jamais les confondre dans la documentation d’un projet.
En résumé
Les Abilities API de WordPress 6.9 ajoutent un canal d’exposition du contenu pensé pour des agents externes via le protocole MCP, structurellement séparé du canal utilisé par l’indexation classique. Pour un développeur, l’enjeu n’est pas de choisir entre les deux, mais de les faire cohabiter proprement : un contenu exposé à un agent n’est pas un contenu indexé par Google, et inversement, un contenu bien référencé n’est pas automatiquement disponible pour un agent tant qu’aucune Ability adaptée n’a été déclarée. Cette distinction, encore peu documentée début 2026, deviendra probablement un réflexe aussi naturel que celui qui existe déjà entre une page HTML et un endpoint REST.
