Automatiser un rapport SEO hebdomadaire avec n8n et l'API Google Search Console

Vérifier Search Console à la main chaque lundi — ouvrir l'interface, comparer les clics à la semaine précédente, repérer les pages qui ont chuté — prend dix minutes par site. Multiplié par plusieurs clients ou plusieurs projets, ce rituel devient vite le genre de tâche répétitive que l'automatisation est censée éliminer en premier. L'API Google Search Console expose exactement les mêmes données que l'interface, et n8n peut les interroger, les comparer d'une semaine sur l'autre, en tirer une synthèse lisible, puis la livrer directement dans Slack ou par email — sans ouvrir un navigateur.

Pourquoi sortir du reporting SEO manuel

Un rapport SEO manuel souffre de trois limites concrètes : il n'est produit que quand quelqu'un pense à le faire, il compare rarement plus de deux périodes à la fois, et il ne déclenche aucune alerte entre deux vérifications — une page qui sort du top 3 un mardi peut perdre l'essentiel de son trafic avant d'être remarquée le lundi suivant. Un workflow automatisé règle les trois points en même temps : exécution garantie sur un cron hebdomadaire, calcul systématique des variations, et possibilité d'ajouter des seuils d'alerte indépendants du rapport de synthèse.

Connecter n8n à l'API Google Search Console

L'API Search Console n'a pas de node dédié dans n8n : elle se pilote avec le node HTTP Request, authentifié par un credential Google OAuth2 API (le même type de credential que pour Sheets ou Drive). La configuration se fait en trois étapes :

1. Dans Google Cloud Console, activer l'API « Search Console API » sur le projet, puis créer des identifiants OAuth 2.0 (type « Application Web »), avec l'URL de redirection fournie par n8n dans l'écran de configuration du credential.
2. Dans n8n, créer un credential Google OAuth2 API, y coller Client ID et Client Secret, et ajouter le scope https://www.googleapis.com/auth/webmasters.readonly (lecture seule — suffisant pour un rapport).
3. Lancer l'autorisation OAuth une seule fois : n8n stocke le refresh token et renouvelle ensuite le token d'accès automatiquement à chaque exécution du cron.

Ce credential une fois posé est réutilisable par tous les nodes HTTP Request qui appellent l'API, y compris pour un éventuel workflow de suivi de l'indexation en complément du rapport de clics.

Interroger searchanalytics.query pour deux périodes

Le cœur du workflow est un appel POST vers https://www.googleapis.com/webmasters/v3/sites/{siteUrl encodé}/searchAnalytics/query, avec un corps JSON précisant les dimensions voulues :

{
  "startDate": "2026-07-13",
  "endDate": "2026-07-19",
  "dimensions": ["query", "page"],
  "rowLimit": 500
}

Pour calculer une variation, le workflow appelle cet endpoint deux fois : une fois sur les 7 derniers jours, une fois sur les 7 jours précédents (mêmes dimensions, dates décalées d'une semaine). Un node Set en amont, alimenté par $now.minus({days: 7}) et consorts, génère dynamiquement les quatre bornes de dates à chaque exécution du cron plutôt que de les coder en dur — le workflow reste ainsi utilisable indéfiniment sans retouche.

Search Console applique un plafond de 50 000 lignes par requête et une fenêtre de quota glissante de 10 minutes : largement suffisant pour un rapport hebdomadaire sur un site, y compris avec la dimension « page » activée en plus de « query ».

Calculer les variations avec un node Code

Les deux jeux de résultats (semaine courante, semaine précédente) arrivent sous forme de lignes { keys: [query, page], clicks, impressions, ctr, position }. Un node Code les fusionne sur la clé query + page, puis calcule pour chaque ligne la variation de clics et de position :

• Trier par plus forte baisse de clics en absolu — ce sont les pages qui méritent une vérification (contenu concurrent qui a progressé, changement d'intention de recherche, problème technique).
• Isoler les mots-clés qui ont gagné ou perdu le top 3 : c'est la zone qui capte l'essentiel des clics. Une étude de référence en eye-tracking, Granka, Joachims et Gay (2004), montre que l'attention visuelle des utilisateurs sur une page de résultats se concentre très fortement sur les tout premiers liens — ce qui explique pourquoi une chute de la position 2 à la position 5 pèse bien plus lourd sur le trafic qu'une chute de la position 15 à la position 20, à volume d'impressions comparable.
• Ne garder dans le rapport final que le top 10 des progressions et le top 10 des baisses, plutôt que les 500 lignes brutes — un rapport illisible n'est jamais lu.

Résumer les tendances en langage naturel avec l'IA

Un node IA (Anthropic ou OpenAI) transforme ensuite ce tableau de chiffres en deux ou trois paragraphes de synthèse : les pages en hausse, les pages en baisse à surveiller, une hypothèse plausible quand un motif se dégage (plusieurs pages d'une même catégorie qui chutent le même jour, par exemple). Le prompt reste volontairement contraint — demander explicitement de ne commenter que les chiffres fournis, sans extrapoler sur des causes externes non vérifiables — pour éviter les fausses certitudes dans un rapport qui sera lu tel quel. Cette étape reprend le même principe que le rapport de synthèse d'audit généré par IA du Pack Conformité & Audit : des données structurées en entrée, une synthèse contrainte en sortie, jamais l'inverse.

Distribuer et archiver le rapport

Le rapport part ensuite par le canal le plus adapté à l'équipe : un message Slack formaté (le même pattern que le digest quotidien d'emails du Pack Inbox IA, ici sur un cron hebdomadaire plutôt que quotidien) ou un email HTML pour un client externe. Dans les deux cas, il vaut la peine d'archiver chaque rapport — synthèse IA incluse — dans une table Supabase avant l'envoi : cela permet de reconstituer un historique de tendances sur plusieurs mois et de retrouver facilement quand une chute a réellement commencé, sur le même principe de journalisation que décrit notre article sur la piste d'audit avec Supabase.

Aller plus loin : des alertes indépendantes du rapport hebdomadaire

Le calcul de variation peut aussi alimenter un second déclencheur, plus réactif : si une page identifiée comme stratégique (une liste d'URLs à surveiller, stockée dans Supabase ou Google Sheets) sort du top 3 entre deux vérifications quotidiennes, un message Slack immédiat part sans attendre le rapport du lundi. C'est la même logique de seuil que pour un monitoring d'erreurs — voir notre guide sur la gestion des erreurs et l'Error Workflow — appliquée cette fois à une métrique métier plutôt qu'à une panne technique.

Pièges fréquents

• Confondre la propriété Search Console avec le domaine affiché dans le navigateur : une propriété de type « préfixe d'URL » (https://www.exemple.fr/) et une propriété de type « domaine » (sc-domain:exemple.fr) ne renvoient pas exactement les mêmes données ; vérifiez laquelle est configurée avant d'interpréter un écart.
• Oublier le décalage de fraîcheur des données : Search Console affiche les données avec 2 à 3 jours de retard. Fixer endDate sur la veille plutôt que sur le jour même évite de récupérer des lignes tronquées ou vides pour les jours les plus récents.
• Trop de dimensions à la fois : ajouter country ou device en plus de query et page multiplie rapidement le nombre de lignes et complique le calcul de variation ; commencez avec deux dimensions et affinez seulement si un besoin précis se présente.
• Rapport illisible faute de tri : envoyer les 500 lignes brutes plutôt qu'un top 10 trié transforme un rapport actionnable en fichier qu'on ouvre puis referme sans le lire.

Pour aller plus loin

Le principe — données structurées en entrée, calcul de variation en Code node, synthèse contrainte par IA, archivage et alerte — est directement celui des workflows de reporting du Pack Conformité & Audit (149 €), pensé pour transformer des données brutes en rapport lisible sans read-team humaine dédiée. Si vos rapports doivent croiser plusieurs sources (Search Console, ticketing, CRM), notre guide pour connecter Claude ou GPT à n8n couvre la configuration des credentials IA qui alimentent l'étape de synthèse décrite ici.