Un client demande, après avoir lu un article alarmiste, de « désactiver toutes les API pour sécuriser le site et éviter que Google gaspille du budget de crawl dessus ». La demande part d’une bonne intention mais mélange deux mécanismes très différents : XML-RPC, un protocole ancien largement ciblé par les attaques automatisées, et la REST API, un mécanisme central au fonctionnement moderne de WordPress, utilisé notamment par l’éditeur de blocs Gutenberg depuis la version 5.0.
Voici un comparatif de ces deux mécanismes, pour décider lequel traiter en priorité et comment, sans casser des fonctionnalités que le client utilise au quotidien sans le savoir.
Ce que chaque mécanisme expose réellement
| Critère | XML-RPC (xmlrpc.php) | REST API (wp-json) |
|---|---|---|
| Usage principal | Publication à distance, anciennes apps mobiles, Jetpack | Éditeur de blocs, thèmes headless, intégrations modernes |
| Cible d’attaques | Très ciblé : force brute par appels groupés system.multicall | Peu ciblé directement, mais expose des données si mal configuré |
| Désactivation totale possible | Oui, sans impact si Jetpack ou publication à distance non utilisés | Risqué : casse l’administration moderne |
| Impact sur le budget de crawl | Nul, Googlebot n’explore pas ce point de terminaison | Marginal, sauf si des routes exposent du contenu dupliqué indexable |
Pourquoi le budget de crawl n’est pas l’angle pertinent ici
Contrairement à l’intuition du client, ni XML-RPC ni la REST API ne posent en réalité de problème de budget de crawl direct : Googlebot n’explore pas spontanément xmlrpc.php, qui répond à des appels XML structurés et non à une navigation classique, et les routes REST par défaut renvoient du JSON, un format que Google indexe rarement comme contenu autonome sauf configuration explicite malencontreuse. La vraie motivation à traiter ces deux points est la sécurité et la charge serveur générée par des attaques automatisées, pas le référencement.
XML-RPC : le candidat à désactiver en premier
XML-RPC concentre l’essentiel des tentatives d’attaque automatisée observées sur les sites WordPress non protégés : des scripts tentent des connexions en masse via system.multicall, une méthode qui permet de tester des centaines de combinaisons d’identifiants en une seule requête HTTP, contournant les limitations de tentatives classiques. Sauf usage confirmé (certaines anciennes configurations Jetpack ou applications mobiles tierces), la désactivation complète est la recommandation la plus simple :
add_filter( 'xmlrpc_enabled', '__return_false' );
REST API : restreindre plutôt que désactiver
Désactiver entièrement la REST API casse l’éditeur de blocs, plusieurs widgets modernes et toute intégration headless éventuelle. La bonne pratique consiste à restreindre l’accès aux données sensibles pour les utilisateurs non authentifiés, plutôt qu’à couper le mécanisme dans son ensemble. La route qui expose la liste des utilisateurs, par exemple, révèle des noms d’utilisateur exploitables pour des tentatives de connexion ciblées :
add_filter( 'rest_endpoints', function ( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
return $endpoints;
} );
Verdict argumenté
XML-RPC doit être désactivé en priorité sur la majorité des sites, sauf dépendance confirmée : le rapport bénéfice-risque est net, la fonctionnalité perdue est marginale pour la plupart des configurations actuelles. La REST API, elle, ne doit jamais être désactivée en bloc sans audit préalable des routes réellement utilisées par le thème et les extensions actives : mieux vaut restreindre chirurgicalement les routes sensibles que risquer de casser l’administration du site pour un gain de sécurité largement inférieur.
En résumé
Ni l’un ni l’autre de ces deux mécanismes n’est un levier de budget de crawl à proprement parler : c’est un raccourci de langage trompeur qui circule souvent dans les guides de sécurité génériques. Le vrai enjeu est la réduction de la surface d’attaque, avec un traitement différencié : coupure nette pour XML-RPC, restriction ciblée pour la REST API.
