SEO via MCP dans WordPress : plus rapide et bien sécurisé

Via MCP, un assistant IA comme Claude dialogue directement avec votre site WordPress. C’est ainsi que nous mettons en ligne des recommandations SEO sur des sites gérés par un autre prestataire, bien plus vite qu’à la main dans WordPress. Depuis WordPress 6.9, cela passe par l’Abilities API et le MCP Adapter. La sécurité repose sur des droits limités, une validation par modification et un journal.

Il s’agit de clients qui nous confient, en tant qu’agence SEO, un accompagnement mensuel, alors que le développement du site est entre les mains d’un tiers. D’après notre expérience, leur site tourne toujours sur un CMS, dans environ neuf cas sur dix sur WordPress.

Cet article s’adresse à eux, et à leur développeur web. Comment l’IA change le reste du travail SEO : lisez comment l’IA change le SEO.

Quelle voie pour votre version de WordPress ?

MCP, le Model Context Protocol, est une norme ouverte qui permet à des applications d’IA de se connecter à des systèmes externes ^[1]. La façon de connecter WordPress dépend de votre version et de votre plateforme.

Avant la 6.9, le plugin d’Automattic était la voie habituelle. Automattic renvoie désormais vers le MCP Adapter et déconseille son propre plugin pour les nouvelles installations ^[2]. Si un site tourne encore sur une version plus ancienne, mettez d’abord WordPress à jour.

À partir de la 6.9, l’Abilities API fait partie de WordPress : les plugins, les thèmes et WordPress lui-même y décrivent ce qu’ils savent faire, avec un schéma d’entrée et de sortie et un contrôle des droits ^[3]. Le MCP Adapter, que vous installez comme plugin ou via Composer, transforme ces abilities en outils pour un client MCP ^[4], ^[5]. C’est la voie que nous utilisons.

Depuis la 7.1, chaque ability a un indicateur public, désactivé par défaut. Le MCP Adapter respecte cet indicateur, mais rendre une ability visible ne revient pas à l’autoriser : les droits de l’utilisateur continuent de s’appliquer ^[7].

Deux choses à savoir sur l’adapter. Il n’ajoute lui-même aucune ability ; elles viennent de WordPress ou de plugins ^[4]. Et tant qu’il est en version 0.x, une mise à jour peut casser quelque chose, comme l’a fait la version 0.6.0 en août 2026 ^[4].

Qu’est-ce qui va plus vite ?

Le gain se situe sur le chemin qui mène de la recommandation à la page en ligne. Avant, une recommandation SEO partait sous forme de document ou de ticket chez le développeur, ou quelqu’un la saisissait à la main dans l’interface d’administration. Aujourd’hui, Claude applique lui-même la modification dans le site, après validation.

Les modifications possibles dépendent des abilities ouvertes. Il s’agit typiquement :

• des titres et des méta-descriptions, souvent des champs d’un plugin SEO ;
• des intertitres, des paragraphes et des blocs FAQ dans des pages existantes ;
• des liens internes et des textes d’ancrage ;
• des textes alternatifs des images ;
• des brouillons de nouvelles pages ou de nouveaux articles, prêts pour relecture.

S’il manque une ability, par exemple pour les champs de votre plugin SEO, quelqu’un doit d’abord l’enregistrer. Ensuite, le rythme ne dépend plus de l’agenda du développeur, mais de la rapidité de la validation.

Comment le configurer en toute sécurité ?

Traitez l’IA comme un nouveau collaborateur : son propre identifiant, des droits limités et quelqu’un qui garde un œil sur son travail. Un client MCP agit comme un utilisateur WordPress connecté, et fait donc partie de la surface d’attaque de votre site ^[5]. Nous recommandons ces six règles :

1. Mettez-vous d’accord avec le développeur. Laissez-le installer l’adapter et décidez ensemble quelles abilities sont ouvertes. Pour un endpoint accessible depuis internet, les développeurs de WordPress recommandent surtout des actions de lecture : diagnostic, rapports et lecture du contenu ^[5]. Chaque action d’écriture est donc un choix délibéré.
2. Un utilisateur séparé, avec un minimum de droits. Créez pour MCP un utilisateur ou un rôle distinct aux droits limités, surtout en production ^[5]. Le rôle Éditeur peut gérer les pages et les articles, y compris ceux des autres, mais pas les plugins, les thèmes ni les réglages ^[8]. Sur un site classique, un Éditeur peut toutefois publier du HTML non filtré (unfiltered_html) ^[8] ; pour tout verrouiller, créez un rôle sur mesure sans ce droit.
3. Un mot de passe d’application dédié. Vous le créez et le révoquez depuis le profil de l’utilisateur, et WordPress indique quand et depuis quelle adresse IP il a servi pour la dernière fois ^[9].
4. D’abord en staging. Testez les nouvelles abilities, les mises à jour de l’adapter et les gros lots sur une copie du site. Déclarez aussi réellement cette copie comme staging (WP_ENVIRONMENT_TYPE) ; sans ce réglage, WordPress considère chaque site comme un site de production ^[10].
5. Une validation par modification. Selon la spécification MCP, un humain doit toujours pouvoir refuser un appel d’outil ^[11]. Dans Claude, vous validez les appels d’outils ; ne choisissez « Toujours autoriser » que pour les outils auxquels vous faites confiance sans surveillance ^[12], donc pas pour une action d’écriture. Chez nous, en plus, aucune page et aucun article ne partent en ligne sans l’accord du client.
6. Un journal avec l’avant et l’après. Par défaut, les révisions de WordPress ne conservent que le titre, l’auteur, le contenu et l’extrait ^[13]. La méta-description d’un plugin SEO n’en fait pas partie par défaut : notez donc vous-même l’ancienne et la nouvelle valeur. La spécification MCP recommande de journaliser l’utilisation des outils ^[11], et vous branchez pour cela votre propre journalisation et votre monitoring sur l’adapter ^[4].

Une dernière règle : gardez le tracking en dehors des droits MCP. Les balises ont leur place dans Google Tag Manager, avec leurs propres droits et leurs propres versions. Mon collègue Cédric explique comment cela fonctionne dans Google Tag Manager expliqué.

Pourquoi le CMS reste-t-il le goulot d’étranglement ?

MCP vaut mieux que le travail manuel dans WordPress, mais pour un site de PME, le CMS est aujourd’hui surtout un frein. MCP rend le travail plus rapide, pas plus vaste : vous faites tout passer par le trou de serrure qu’est le CMS. L’IA ne peut faire que ce qu’une ability permet, et une ability ne peut faire que ce que le thème, le page builder et les plugins permettent.

Ce qui sort de ce cadre reste du travail pour le développeur. Pensez à un modèle qui impose la même structure à chaque page de service, au code lent d’un page builder ou à un plugin qui génère ses propres données structurées. Plus il y a de plugins, plus il y a de limites de ce genre ; pourquoi cela compte aussi pour la sécurité et la maintenance, vous le lisez dans WordPress ou site statique.

C’est pourquoi nous construisons les nouveaux sites de contenu sans CMS. Claude construit alors la page lui-même, en HTML et CSS, et cette limite disparaît. Pourquoi et quand cela convient : lisez site web sans CMS.

Que demander à votre partenaire SEO ?

Avant de commencer, demandez comment la connexion est configurée : quelle version de WordPress et quelle voie, quel utilisateur, quels droits, quelles abilities, qui valide et où se trouve le journal. Une bonne réponse tient sur une page. Pas de réponse, c’est une raison d’attendre.

Vous voulez d’abord savoir quelles modifications SEO rapporteraient le plus sur votre site ? Le scan SEO gratuit examine la technique, l’indexation, le contenu, les liens internes et votre visibilité dans les réponses de l’IA. Vous recevez les constats et un entretien, quelle que soit votre décision ensuite.