Tech & Performance

MCP Search Console : analyser son SEO avec Claude

MCP Search Console : Google n’en documente pas, mais l’API Search Analytics et Claude Code permettent d’analyser son SEO. Méthode, quotas, limites et garde-fous.

Publié le 12/10/2026Par Maxence Vanderswalmen

Google Ads, Google Analytics et Merchant API ont chacun un serveur MCP documenté par Google. Search Console, non : dans les pages que nous avons consultées le 6 octobre 2026 (la présentation de l'API, le blog et les mises à jour de Search Central, la documentation de la Search Console API), aucune mention de MCP n'apparaît. Cela ne ferme pas la porte à Claude. L'API Search Analytics est documentée, ses limites aussi, et Claude Code sait écrire le script qui l'appelle. Ce guide décrit ce que l'API permet, ses quotas, la méthode que Google recommande pour tout récupérer, une série d'analyses à demander à Claude et les garde-fous à poser.

Les faits cités viennent de la documentation de Google et de celle d'Anthropic, consultées le 6 octobre 2026. La page des limites d'usage indique une dernière mise à jour au 28 août 2025 : relisez-la avant de vous appuyer sur un quota.

Si vous rencontrez un serveur MCP tiers pour Search Console, aucune des sources officielles citées ici ne le couvre. Il recevrait une autorisation OAuth sur vos données de recherche : lisez son code et son périmètre de portée avant de le connecter, comme pour tout serveur, puisque la documentation de Claude Code demande de vérifier la confiance accordée à chaque serveur.

Trois voies pour que Claude lise Search Console

Voie	Ce qu'elle apporte	Limite documentée
Script appelant l'API Search Analytics	Les données du rapport de performances, filtrables, sur la période voulue, écrites en fichiers que Claude analyse ensuite	50 000 lignes par jour et par type de recherche, quotas de charge et de requêtes
Export groupé vers BigQuery	Toutes les données de performance de la propriété, hors requêtes anonymisées, exportées chaque jour	Projet Google Cloud avec facturation, coûts de stockage et de requêtes au-delà du quota gratuit
Serveur MCP tiers	Non couvert par les sources officielles de cet article	À auditer vous-même avant tout branchement

Ce que la méthode searchAnalytics.query permet

D'après la page d'interrogation des données de recherche, la méthode expose toutes les données du rapport de performances de Search Console. La référence de la méthode en détaille les paramètres.

Paramètre	Ce que Google documente
`startDate`, `endDate`	Obligatoires, au format AAAA-MM-JJ, dans le fuseau du Pacifique (UTC moins 7 ou 8 heures), bornes incluses
`dimensions`	Zéro ou plusieurs dimensions de regroupement, par exemple `query`, `page`, `country`, `device`, `searchAppearance`, ainsi que `date` et `hour`
`type`	`web` (par défaut), `image`, `video`, `news`, `googleNews` ou `discover`
`dimensionFilterGroups`	Filtres sur une dimension, avec des exemples comme « query contains » ou « country equals », la valeur des pays suivant le code à trois lettres ISO 3166-1 alpha-3
`aggregationType`	`auto` par défaut, `byPage` ou `byProperty` : si vous regroupez ou filtrez par page, l'agrégation par propriété n'est pas possible
`rowLimit`, `startRow`	De 1 à 25 000 lignes, 1 000 par défaut ; `startRow` sert à paginer
`dataState`	`final` par défaut (données finalisées), `all` pour inclure les données récentes, `hourly_all` pour le détail horaire

La réponse contient des lignes avec les clés de regroupement, les clics, les impressions, le taux de clic et la position. Elles sont triées par clics décroissants, sauf quand on regroupe par date : l'ordre est alors chronologique.

Les limites qui changent la méthode

Selon la page sur la récupération de toutes les données, la méthode expose au plus 50 000 lignes par jour et par type de recherche, triées par clics. La référence ajoute que l'API ne garantit pas de renvoyer toutes les lignes mais les premières.
Regrouper par page et par requête peut faire perdre des données. Pour des comptes exacts, Google conseille d'omettre ces deux dimensions et de lancer une requête séparée pour le détail.
Les données sont généralement disponibles après deux à trois jours. Google conseille de lancer d'abord une requête groupée par date sur les dix derniers jours pour connaître la dernière date disponible.
D'après la page des limites d'usage, Search Analytics a un quota de charge, sur des fenêtres de 10 minutes et d'un jour, et des quotas de requêtes : 1 200 par minute et par site, 1 200 par minute et par utilisateur, 40 000 par minute et 30 millions par jour et par projet. Pour un dépassement du quota de charge sur dix minutes, Google conseille d'attendre 15 minutes avant de réessayer. Les requêtes groupées ou filtrées par page et par requête sont les plus coûteuses, et la charge augmente avec la période interrogée.

La méthode recommandée par Google : un jour par requête

Google recommande de lancer chaque jour une requête sur une seule journée, et de paginer par pas de 25 000 lignes jusqu'à une réponse vide. Sa boucle de référence, simplifiée :

maxRows = 25000
i = 0
faire
  réponse = requête(startDate = jour, endDate = jour,
                    dimensions = [page, query, country, device],
                    type = web,
                    rowLimit = maxRows, startRow = i * maxRows)
  i = i + 1
tant que réponse contient des lignes

Le corps de requête correspondant, tel que Google le donne pour le détail page et requête (au prix d'une perte possible de données) :

{
  "startDate": "2018-06-01",
  "endDate": "2018-06-01",
  "dimensions": ["page", "query", "country", "device"],
  "type": "web"
}

Pour des totaux exacts, Google donne une requête sans les dimensions page et requête, avec "aggregationType": "byPage" et, au choix, les dimensions pays et appareil. Google indique de lancer une telle requête chaque jour, une fois par valeur de type que vous suivez, et se conservent en fichiers : l'historique reste chez vous, consultable sans relancer l'API.

Faire écrire le script par Claude Code

L'API impose OAuth 2.0 pour toute requête sur des données utilisateur, sans autre protocole possible. Le guide d'autorisation donne deux portées : https://www.googleapis.com/auth/webmasters.readonly pour la lecture seule, https://www.googleapis.com/auth/webmasters pour la lecture et l'écriture. L'analyse ne demande que la première. Il faut un projet créé dans la console Google API et un droit de lecture sur la propriété. Google fournit des bibliothèques clientes pour plusieurs langages, qui gèrent une partie de l'autorisation.

Depuis un dossier de projet, une demande type à Claude Code :

Écris scripts/gsc_pull.py qui interroge l'API Search Console avec la portée webmasters.readonly.
Une requête par jour et par type web, dimensions page, query, country, device, pagination par 25000 avec startRow
jusqu'à une réponse vide. Écris un fichier CSV par jour dans data/gsc/. Lis les identifiants dans secrets/, ne les affiche jamais.
Commence par une requête groupée par date sur les 10 derniers jours pour trouver la dernière date disponible.

Relisez le script avant de l'exécuter : la portée demandée, le dossier d'écriture et la gestion du quota (attente après une erreur « quota exceeded ») se vérifient en quelques lignes.

Les analyses à demander une fois les fichiers en place

Les données sont dans des fichiers locaux que Claude agrège avec des scripts. Quelques demandes qui exploitent les colonnes de l'API :

« Quelles requêtes totalisent au moins 20 impressions sur 90 jours avec zéro clic ? »
« Parmi elles, lesquelles n'ont aucune page dédiée dans le dossier app/blog ? »
« Quelles pages ont une position moyenne au-delà de 12 sur des requêtes à fort volume d'impressions ? »
« Compare les 28 derniers jours aux 28 jours précédents, page par page, et liste les plus fortes baisses de clics. »
« Sépare mobile et ordinateur pour les dix pages les plus visibles et signale les écarts de position. »
« Regroupe les requêtes par intention et donne le nombre de clics de chaque groupe. »

La règle des deux premières demandes est celle que nous appliquons pour alimenter la file de sujets de ce blog : au moins 20 impressions sur 90 jours, et zéro clic ou une position moyenne au-delà de 12, sans page qui traite déjà la requête. Sur notre relevé du 15 juin au 14 septembre 2026, le cluster Claude et MCP totalisait 467 des 920 clics du site. Search Console ne montre toutefois que les requêtes sur lesquelles une page s'est déjà affichée : il ne dit rien de la demande qui existe sans que votre site y apparaisse. Il faut un autre outil pour la mesurer.

Un dernier point de méthode : une position moyenne autour de 9 ou 10 ne se convertit pas en clics par un taux de clic théorique. Une page peut cumuler des dizaines de milliers d'impressions à cette position sans recevoir de clic. Lisez les clics réels du fichier avant d'estimer un potentiel. Le guide sur l'attribution SEO et SEA dans GA4 complète cette lecture côté conversions.

Pour dépasser le plafond : l'export vers BigQuery

Quand 50 000 lignes par jour et par type ne suffisent pas, Google propose l'export groupé : un export quotidien des données de performance vers BigQuery, qui contient toutes les données de performance de la propriété à l'exception des requêtes anonymisées, selon l'aide Search Console. Le jeu de données se nomme searchconsole par défaut, avec les tables searchdata_site_impression (agrégée par propriété), searchdata_url_impression (agrégée par URL) et ExportLog, d'après la page de référence des tables. Il faut un projet Google Cloud avec facturation (voir la page sur le démarrage d'un export) ; Google signale un niveau d'usage gratuit, des coûts au-delà, et une accumulation des données sans limite de durée tant qu'on ne fixe pas d'expiration. Interroger ces tables avec Claude suppose un accès à BigQuery, que cet article ne détaille pas.

Les garde-fous

Portée webmasters.readonly uniquement : l'écriture donne accès aux propriétés et aux sitemaps.
Identifiants hors du dépôt et hors de la portée de Claude. Une règle deny sur le dossier les masque aux outils de lecture de fichiers (voir ci-dessous).
Un script relu avant exécution, et lancé par une commande précise, plutôt qu'un shell ouvert.
Les données de recherche d'un client ne sortent du poste que vers Claude : vérifiez que votre contrat l'autorise.

La documentation des permissions prévoit des règles Read en refus pour un chemin (par exemple Read(./secrets/**)) et des règles Bash avec une commande suivie d'un astérisque. Une configuration pour ce poste :

{
  "permissions": {
    "allow": ["Bash(python3 scripts/gsc_pull.py *)"],
    "deny": ["Read(./secrets/**)"]
  }
}

La documentation signale une limite : les règles de refus s'appliquent aux outils de lecture de Claude et aux commandes de fichiers qu'elle reconnaît dans Bash, mais pas à une commande qui lit des fichiers sans les nommer, comme un grep -r lancé depuis le dossier concerné. Votre propre script de collecte lit le dossier des identifiants par construction ; la règle protège contre une lecture directe par Claude, pas contre ce que fait le code que vous avez relu et lancé.

Par où commencer

Créer un projet dans la console Google API, activer l'API Search Console et générer des identifiants OAuth.
Faire écrire le script de collecte par Claude Code avec la portée en lecture seule, et le relire.
Lancer la requête de contrôle groupée par date, puis la collecte jour par jour.
Poser les deux règles de permission, puis dérouler les six analyses sur les fichiers.
Envisager l'export BigQuery si le plafond de 50 000 lignes par jour vous fait perdre des requêtes utiles.

Questions fréquentes sur le MCP Search Console

Google propose-t-il un serveur MCP pour Search Console ?

Dans les pages que nous avons consultées le 6 octobre 2026 (présentation de l’API Search Console, blog et pages de mises à jour de Search Central, documentation de la Search Console API), aucune mention d’un serveur MCP n’apparaît. Google en documente pour Google Ads, Google Analytics et Merchant API, mais pas, à cette date, pour Search Console. Cette absence se vérifie : relisez ces pages avant de vous fier à cet article.

Quel accès faut-il pour interroger l’API Search Console ?

Un compte Google avec au moins un droit de lecture sur la propriété (pour la méthode searchAnalytics.query), un projet créé dans la console Google API et des identifiants OAuth 2.0. L’API n’accepte aucun autre protocole d’autorisation. La portée webmasters.readonly donne un accès en lecture seule, la portée webmasters un accès en lecture et en écriture.

Combien de lignes l’API Search Analytics renvoie-t-elle ?

Une requête renvoie entre 1 et 25 000 lignes (1 000 par défaut), paginées avec startRow. Au-delà de la pagination, Google indique que la méthode expose au maximum 50 000 lignes de données par jour et par type de recherche (web, image et ainsi de suite), triées par clics, et qu’elle ne garantit pas de renvoyer toutes les lignes mais les premières.

Les données de l’API sont-elles identiques à celles du rapport de performances ?

La méthode expose toutes les données disponibles dans le rapport de performances, mais avec des limites propres : plafond de lignes par jour, perte possible de données quand on regroupe par page et par requête, données généralement disponibles après deux à trois jours. Pour dépasser le plafond de lignes, Google propose l’export groupé vers BigQuery, qui contient toutes les données de performance à l’exception des requêtes anonymisées, à partir de sa mise en place : pour l’historique antérieur, Google renvoie vers l’API ou les rapports.

Claude peut-il modifier mes sitemaps ou mes propriétés ?

Seulement avec la portée webmasters (lecture et écriture) : l’API comprend des méthodes pour ajouter ou supprimer des propriétés et des sitemaps. Avec la portée webmasters.readonly, aucun script de ce type ne peut écrire dans le compte. Pour de l’analyse, choisissez toujours la lecture seule.

Sources consultées le 6 octobre 2026

Pour aller plus loin sur Claude et les données marketing : MCP GA4, MCP Google Ads, MCP Merchant Center, MCP Klaviyo, skills Claude pour le marketing. Pour un audit de votre référencement, voir notre grille de priorisation d'audit SEO e-commerce.