Créer son connecteur MCP Google Search Console et Google Analytics pour Claude

Un connecteur MCP permet à Claude de lire vos données Google Search Console et Google Analytics 4 directement dans la conversation : requêtes, clics, pages, sessions, canaux d'acquisition. Plus besoin d'exporter des fichiers pour les analyser.

Ce guide vous accompagne de A à Z, quel que soit votre hébergement : hébergement mutualisé avec Node.js, serveur privé, plateforme cloud ou simple test depuis votre ordinateur. Comptez 1 à 2 heures la première fois. Si vous préférez être accompagné, n'hésitez pas à me contacter.

Ce que vous allez construire

On crée un petit serveur (Node.js) qui s'authentifie auprès de Google avec votre compte, puis on l'ajoute dans Claude comme « connecteur personnalisé ». Claude appelle ensuite ce serveur pour récupérer vos données.

1. Claude envoie une requête à l'adresse HTTPS de votre serveur (https://<votre-domaine>/mcp).
2. Le serveur vérifie que c'est bien vous (identifiant et mot de passe que vous choisissez).
3. Il interroge les API Google avec un jeton de lecture seule, obtenu une fois pour toutes.
4. Il renvoie les résultats à Claude, qui les analyse.

Le serveur expose 7 outils : 3 pour Search Console (gsc_list_sites, gsc_search_analytics, gsc_list_sitemaps) et 4 pour Analytics 4 (ga_list_properties, ga_run_report, ga_run_realtime_report, ga_get_metadata).

À savoir avant de commencer

• Il faut une adresse HTTPS publique avec un certificat valide. Claude refuse les certificats auto-signés. Un serveur sur votre ordinateur, sans adresse publique, ne fonctionne pas avec Claude en ligne.
• Un hébergement FTP classique ne suffit pas. Il faut pouvoir faire tourner un programme qui reste actif en continu (Node.js).
• Un plan Claude payant est généralement nécessaire pour les connecteurs personnalisés. Vérifiez l'offre en vigueur sur la page d'aide d'Anthropic.
• Le jeton est en lecture seule. Le connecteur ne peut ni modifier vos sites, ni changer vos réglages Google.
• Coût : de 0 € (offres gratuites de certaines plateformes) à environ 5 €/mois (petit serveur privé). Les API Google utilisées sont gratuites dans leurs quotas standard.

Choisir son cas d'hébergement

Si vous n'avez pas d'avis, prenez la plateforme cloud (cas C) : c'est le chemin le plus court. Si vous avez déjà un hébergement web qui propose Node.js (cas A) ou un serveur privé (cas B), utilisez-le.

Les cas A, B, C et E utilisent exactement le même code. Seules les étapes de déploiement changent.

Étape 1 : préparer Google Cloud

Cette étape crée l'identité de votre application auprès de Google. Elle est identique quel que soit l'hébergement. Les intitulés exacts des menus changent parfois : cherchez le mot-clé si un nom diffère.

1.1 Créer un projet

1. Ouvrez la console Google Cloud avec le compte Google qui a accès à vos données Search Console et Analytics.
2. Cliquez sur le sélecteur de projet en haut, puis sur Nouveau projet. Donnez-lui un nom (par exemple mcp-seo) et créez-le.

1.2 Activer les trois API

1. Menu API et services → Bibliothèque.
2. Cherchez et activez, une par une : Google Search Console API, Google Analytics Data API et Google Analytics Admin API.

1.3 Configurer l'écran de consentement OAuth

1. Menu API et services → Écran de consentement OAuth (parfois appelé Google Auth Platform).
2. Type d'utilisateur : Externe (choisissez Interne seulement si vous avez un Google Workspace et que vous êtes seul concerné).
3. Renseignez le nom de l'application, votre e-mail d'assistance et votre e-mail de contact.
4. Ajoutez votre propre adresse Google dans la liste des utilisateurs test.

1.4 Publier l'application (important)

Une application laissée en mode Test voit ses jetons expirer au bout de 7 jours : le connecteur cesserait alors de fonctionner. Dans l'écran de consentement, passez l'état de Test à En production (bouton Publier l'application).

Pour un usage personnel, aucune validation par Google n'est nécessaire. Au moment de vous connecter, Google affichera un avertissement « application non vérifiée » : c'est normal, c'est votre propre application. Cliquez sur Avancé, puis sur Continuer.

1.5 Créer les identifiants OAuth

1. Menu API et services → Identifiants → Créer des identifiants → ID client OAuth.
2. Type d'application : Application de bureau. Le type « Application Web » ne fonctionne pas avec le script de l'étape 2 : il provoque l'erreur redirect_uri_mismatch.
3. Notez l'ID client et le Code secret du client. Ils vont dans vos variables d'environnement à l'étape 3.

Gardez ces deux valeurs secrètes : ne les envoyez jamais par e-mail ou messagerie, et ne les mettez pas dans un dépôt Git public.

Étape 2 : récupérer le jeton Google (une seule fois, sur votre ordinateur)

Cette étape produit un « refresh token » : une clé de lecture seule qui permet à votre serveur d'interroger Google sans que vous vous reconnectiez. Elle se fait sur votre ordinateur, pas sur le serveur.

1. Installez Node.js (version LTS, 18 ou plus récente). Vérifiez avec node -v dans un terminal.
2. Placez les fichiers du projet dans un dossier (liste en annexe), puis ouvrez un terminal dans ce dossier.
3. Installez les dépendances :

   npm install

4. Créez un fichier nommé exactement .env (copie de .env.example) contenant au minimum :

   GOOGLE_CLIENT_ID=<ID client de l'étape 1.5>
   GOOGLE_CLIENT_SECRET=<Code secret de l'étape 1.5>

   Sous Windows, vérifiez que le fichier ne s'appelle pas .env.txt (affichez les extensions de fichiers dans l'Explorateur).
5. Lancez le script :

   node get-refresh-token.js

6. Un lien s'affiche et le navigateur s'ouvre. Connectez-vous avec le compte Google qui a accès à Search Console et à Analytics.
7. Google affiche l'avertissement « application non vérifiée » : Avancé → Continuer.
8. Sur l'écran des autorisations, cochez les deux cases (Search Console et Analytics). Si vous n'en cochez qu'une, l'autre service échouera plus tard avec l'erreur « insufficient authentication scopes ».
9. Le terminal affiche une ligne GOOGLE_REFRESH_TOKEN=.... Copiez la valeur dans un gestionnaire de mots de passe.

Traitez ce jeton comme un mot de passe : quiconque le possède peut lire vos données Search Console et Analytics. S'il fuite, révoquez-le sur la page des autorisations de votre compte Google, puis recommencez cette étape.

Droits d'accès à vérifier. Le compte utilisé doit être ajouté comme utilisateur de chaque site dans Search Console (Paramètres → Utilisateurs et autorisations) et avoir au moins le rôle Lecteur sur chaque propriété Analytics (Admin → Gestion des accès). Le connecteur ne voit que ce que ce compte voit.

Étape 3 : préparer le code et les variables d'environnement

Le serveur se configure uniquement par des variables d'environnement : aucun secret n'est écrit dans le code. Vous les saisirez dans le panneau de votre hébergeur (cas A à C) ou dans un fichier .env (cas B et E).

Pour générer un mot de passe solide, dans un terminal :

node -e "console.log(require('crypto').randomBytes(24).toString('base64url'))"

Trois points qui causent la plupart des pannes :

• PUBLIC_BASE_URL doit correspondre exactement à l'adresse que vous mettrez dans Claude : même nom de domaine, https://, pas de / final. Sinon la connexion échoue.
• Si une variable obligatoire manque, le serveur s'arrête au démarrage (le message est dans le fichier gsc-mcp.log).
• Modifier MCP_USERNAME, MCP_PASSWORD ou GOOGLE_CLIENT_SECRET déconnecte toutes les sessions existantes. C'est voulu : reconnectez-vous ensuite dans Claude.

Le serveur écrit un journal dans gsc-mcp.log, à côté de server.js. Il ne contient ni mot de passe ni jeton, et il sert au dépannage.

Étape 4 : déployer, cas par cas

Suivez uniquement la partie qui correspond à votre cas. Dans tous les cas, le résultat attendu est le même : l'adresse https://<votre-domaine>/ affiche « Serveur MCP GSC en ligne » avec un cadenas valide dans le navigateur.

Cas A : hébergement mutualisé avec Node.js (cPanel)

1. Sous-domaine. Créez un sous-domaine dédié (par exemple mcp.<votre-domaine>). Attendez que le certificat HTTPS soit émis ; dans SSL/TLS Status, le sous-domaine doit avoir un cadenas valide. Un certificat provisoire (auto-signé) fait échouer la connexion de Claude.
2. Application Node.js. Ouvrez l'outil de type Setup Node.js App, cliquez sur Create Application, puis choisissez : version de Node la plus récente proposée, mode Production, racine de l'application = le dossier du sous-domaine, URL = le sous-domaine, fichier de démarrage = server.js.
3. Fichiers. Envoyez server.js, package.json et get-refresh-token.js dans ce dossier (gestionnaire de fichiers, SFTP ou Git). N'envoyez pas le fichier .env.
4. Dépendances. Dans la page de l'application, cliquez sur Run NPM Install. Sinon, en SSH, activez l'environnement avec la commande affichée en haut de la page de l'application (elle commence par source ...nodevenv.../bin/activate), puis lancez npm install. Sans cette activation, la commande npm est introuvable.
5. Variables. Dans la même page, ajoutez les variables de l'étape 3, une par une.
6. Cliquez sur Restart, puis ouvrez https://<votre-domaine>/.

Point d'attention : certains hébergeurs filtrent les requêtes POST vers des chemins qu'ils jugent suspects (réponse 406 avec une page /406.shtml). Si Claude n'arrive pas à s'inscrire, voir la section Dépannage.

Cas B : serveur privé virtuel (VPS sous Linux)

1. DNS. Créez un enregistrement A pointant mcp.<votre-domaine> vers l'adresse IP du serveur.
2. Node.js. Installez une version LTS (18 ou plus) avec le gestionnaire de paquets de votre distribution ou nvm. Vérifiez avec node -v.
3. Fichiers. Copiez le projet dans /opt/gsc-mcp, puis :

   cd /opt/gsc-mcp
   npm install --omit=dev
   nano .env          # collez les variables de l'étape 3
   chmod 600 .env     # seul le propriétaire peut lire le fichier

4. Démarrage automatique. Créez /etc/systemd/system/gsc-mcp.service :

   [Unit]
   Description=Serveur MCP Search Console + Analytics
   After=network.target
   
   [Service]
   WorkingDirectory=/opt/gsc-mcp
   EnvironmentFile=/opt/gsc-mcp/.env
   ExecStart=/usr/bin/node server.js
   Restart=always
   User=<utilisateur-sans-privileges>
   
   [Install]
   WantedBy=multi-user.target

   sudo systemctl daemon-reload
   sudo systemctl enable --now gsc-mcp
   sudo systemctl status gsc-mcp

   Si which node ne renvoie pas /usr/bin/node, adaptez le chemin dans ExecStart.
5. HTTPS. Le plus simple est Caddy, qui obtient et renouvelle le certificat tout seul. Fichier Caddyfile :

   mcp.<votre-domaine> {
       reverse_proxy localhost:3000
   }

6. Pare-feu. Ouvrez les ports 80 et 443 uniquement. Le port 3000 reste interne.

Cas C : plateforme cloud (Render, Railway, Fly.io et équivalents)

1. Placez le projet dans un dépôt Git privé. Le fichier .gitignore fourni exclut déjà .env.
2. Sur la plateforme, créez un service web à partir de ce dépôt, runtime Node.js. Commande d'installation : npm install. Commande de démarrage : npm start.
3. Ajoutez les variables de l'étape 3 dans l'interface de la plateforme (section secrets ou variables d'environnement). Laissez PORT à la plateforme si elle le définit.
4. Déployez une première fois. La plateforme vous donne une adresse HTTPS (par exemple https://mon-service.<plateforme>.app). Copiez-la dans PUBLIC_BASE_URL, sans / final, puis redéployez. Si vous reliez ensuite votre propre domaine, mettez PUBLIC_BASE_URL à jour.
5. Ouvrez https://<adresse>/ pour vérifier.

Les jetons de connexion sont signés et ne dépendent d'aucun stockage : un redéploiement ou une mise en veille ne vous déconnecte pas. Sur une offre gratuite qui met le service en veille, le premier appel de Claude peut être lent ou échouer ; relancez-le. Vérifiez les offres et tarifs en vigueur sur le site de la plateforme.

Cas E : votre ordinateur + tunnel HTTPS (tests uniquement)

1. Installez cloudflared (ou un outil équivalent comme ngrok).
2. Lancez le tunnel et notez l'adresse HTTPS affichée :

   cloudflared tunnel --url http://localhost:3000

3. Dans votre fichier .env, mettez cette adresse dans PUBLIC_BASE_URL, puis démarrez le serveur dans un second terminal : node server.js.

L'adresse d'un tunnel gratuit change à chaque lancement : il faudra supprimer puis rajouter le connecteur dans Claude à chaque fois. Pour un usage durable, choisissez les cas A, B ou C.

Cas D et F

Le code fourni est un serveur Express classique. Il ne s'exécute pas tel quel sur des fonctions serverless (cas D) ; il faudrait le réécrire pour la plateforme choisie. Un connecteur local pour Claude Desktop (cas F) utilise un autre mécanisme (sans adresse web) et ne fonctionne pas dans le navigateur : ce n'est pas l'objet de ce guide.

Étape 5 : connecter le serveur à Claude et tester

Avant de commencer, ouvrez https://<votre-domaine>/ dans le navigateur : la page doit s'afficher avec un cadenas sans avertissement.

1. Dans Claude, ouvrez Réglages → Connecteurs → Ajouter un connecteur personnalisé. Sur une offre Team ou Enterprise, c'est un propriétaire de l'organisation qui l'ajoute ; chaque membre se connecte ensuite lui-même.
2. Donnez-lui un nom (par exemple « Search Console + Analytics ») et saisissez l'adresse https://<votre-domaine>/mcp. Attention au /mcp final.
3. Claude vérifie le serveur. Si l'étape « Connexion au serveur » échoue, ne cliquez pas sur « Continuer quand même » : consultez le Dépannage.
4. Aux écrans suivants, laissez les réglages détectés : authentification Se connecter maintenant, client OAuth S'enregistrer automatiquement. Laissez vides l'identifiant client, le secret client et les en-têtes.
5. Validez. Une fenêtre de connexion s'ouvre : autorisez les fenêtres pop-up pour le site de Claude si rien ne s'affiche.
6. Saisissez MCP_USERNAME et MCP_PASSWORD (ceux que vous avez définis à l'étape 3, pas vos identifiants Google).
7. Le connecteur apparaît comme connecté, avec ses 7 outils. Activez-le dans les outils de la conversation.

Tester

• « Liste mes sites Google Search Console. »
• « Liste mes propriétés Google Analytics. »
• « Sur le site <votre-site>, donne-moi les 20 requêtes qui génèrent le plus de clics sur les 28 derniers jours. »
• « Sur la propriété <identifiant>, montre-moi les sessions par canal d'acquisition sur les 28 derniers jours. »

Dans Search Console, une propriété s'écrit soit https://<site>/ (préfixe d'URL), soit sc-domain:<site> (propriété de domaine). Demandez d'abord la liste des sites pour utiliser la forme exacte.

Après une modification du serveur. Si vous changez le code ou l'adresse, supprimez le connecteur dans Claude puis ajoutez-le à nouveau : cela renouvelle l'inscription et la liste des outils. Si seuls les outils Analytics manquent, vérifiez que le serveur est bien en version 1.2 ou plus récente (affichée sur la page d'accueil du serveur).

Sécurité et bonnes pratiques

Le serveur est public sur Internet : seul le mot de passe que vous avez choisi empêche un inconnu de l'utiliser. Traitez-le comme un accès à vos données.

• Mot de passe solide et unique (20 caractères ou plus), généré par un gestionnaire de mots de passe. Le serveur limite déjà les essais de connexion (10 échecs par adresse IP et par période de 15 minutes).
• Accès en lecture seule. Les deux autorisations demandées (webmasters.readonly et analytics.readonly) empêchent toute modification. Ne les remplacez pas par des autorisations plus larges.
• Compte Google dédié si possible. Le connecteur voit tout ce que le compte voit. Un compte qui n'a accès qu'aux sites et propriétés utiles limite l'exposition en cas de fuite.
• Secrets hors du code. Ne placez jamais .env, l'ID client, le code secret ou le jeton dans un dépôt Git, un e-mail, une capture d'écran ou une conversation. Le fichier .gitignore fourni exclut .env.
• Connexion Claude. Le serveur n'accepte de rediriger la connexion que vers Claude (ou localhost). Élargissez la liste ALLOWED_REDIRECT_HOSTS seulement si vous en comprenez la raison.
• Durée des sessions. Une session Claude dure 24 heures et se renouvelle automatiquement ; sans utilisation pendant 90 jours, il faut se reconnecter.
• En cas de doute (fuite, départ d'un collaborateur) : changez MCP_PASSWORD (cela déconnecte toutes les sessions), puis révoquez le jeton Google sur la page des autorisations de votre compte Google et répétez l'étape 2.
• Mises à jour. Sur un VPS, gardez le système et Node.js à jour. Lancez de temps en temps npm audit dans le dossier du projet.
• Données de tiers. Si vous consultez les données d'un client, vérifiez que vous y êtes autorisé : les résultats sont transmis à Claude dans la conversation.

Le serveur est prévu pour une seule personne (un identifiant, un mot de passe). Pour donner l'accès à une équipe, ne partagez pas ce mot de passe : créez un connecteur par personne, ou faites évoluer l'authentification.

Dépannage

Premier réflexe : lire le journal. Le serveur écrit gsc-mcp.log à côté de server.js (ouvrez-le dans le gestionnaire de fichiers ou en SSH). Faites une tentative de connexion dans Claude, puis regardez les dernières lignes :

• des lignes POST /mcp ou POST /oauth/client apparaissent : Claude atteint votre serveur, le problème est plus loin ;
• aucune ligne n'apparaît : la requête n'arrive pas jusqu'à votre programme (adresse, certificat, pare-feu de l'hébergeur) ;
• le fichier n'existe pas : le programme ne démarre pas (variable manquante, npm install oublié, mauvais fichier de démarrage).

Test de référence depuis un terminal (remplacez le domaine). Il doit répondre 401 Unauthorized avec un en-tête WWW-Authenticate : c'est la bonne réponse, elle prouve que le serveur est joignable et protégé.

curl -i -X POST https://<votre-domaine>/mcp -H "Content-Type: application/json" -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{}}"

Si un problème persiste, notez le message exact (sans mot de passe, jeton ni identifiant secret) et les dernières lignes de gsc-mcp.log. C'est ce qu'il faut fournir pour obtenir de l'aide.

Annexes

Fichiers du projet

Version 1.2.1, à télécharger : gsc-mcp-kit.zip.

Outils exposés à Claude

Mettre à jour le serveur

1. Remplacez server.js (et package.json si fourni) par la nouvelle version.
2. Si package.json a changé, relancez npm install.
3. Redémarrez l'application (bouton Restart, systemctl restart gsc-mcp, ou redéploiement).
4. Vérifiez le numéro de version sur la page d'accueil du serveur.
5. Si les outils ont changé, supprimez puis rajoutez le connecteur dans Claude.

Limites connues. Le serveur lit les données ; il n'envoie ni ne modifie rien (pas de soumission de sitemap ni d'inspection d'URL). Il est mono-utilisateur. Les noms exacts des menus Google Cloud, de Claude et des plateformes d'hébergement évoluent : en cas de différence, cherchez le mot-clé plutôt que l'intitulé exact.