Connecter Google Search Console à Looker Studio, et que faire quand ça coince
Search Console fait partie des rares sources que Looker Studio (renommé Data Studio par Google en avril 2026) connecte nativement, gratuitement, en 90 secondes environ. Ce guide fait cette partie proprement : les étapes exactes, plus le seul choix de configuration qui décide en silence des questions auxquelles votre tableau de bord pourra répondre pendant toute sa vie. Il passe ensuite en revue les quatre murs contre lesquels tout tableau de bord Search Console finit par buter, parce que « gratuit et natif » ne veut pas dire « suffisant ».
La connexion, étape par étape
Il vous faut une propriété Search Console validée et un compte Google disposant au moins d’un accès restreint à cette propriété. Ensuite, dans l’ordre (avec les libellés de l’interface française, tels que les donne la documentation Google du connecteur) :
- Dans Looker Studio, choisissez Créer → Source de données (Create → Data source) et cherchez Search Console. C’est un connecteur conçu par Google : il figure en haut de la liste, sans badge partenaire et sans prix.
- Autorisez le connecteur (bouton AUTORISER, Authorize) avec le compte Google qui a accès à la propriété.
- Choisissez la propriété dans le panneau Sites. La liste affiche à la fois les propriétés de domaine (
sc-domain:example.com) et les propriétés de préfixe d’URL (https://example.com/). - Choisissez le type de table dans le panneau Tableaux : Impression associée au site (Site Impression) ou Impression associée à l’URL (URL Impression). C’est le choix qui compte, et toute la section suivante lui est consacrée.
- Choisissez le type de recherche dans le panneau Type de recherche : Web, Image, Vidéo ou News. Il est fixé pour chaque source de données : un rapport qui a besoin de Web et d’Image a besoin de deux sources de données.
- Cliquez sur ASSOCIER (Connect), puis sur CRÉER UN RAPPORT (Create report). Ajoutez une série temporelle des clics : vous avez un tableau de bord qui fonctionne.
Le choix de la propriété est un piège qu’il vaut mieux nommer. Une propriété de domaine agrège tous les sous-domaines et les deux protocoles ; une propriété de préfixe d’URL ne compte que le préfixe exact sur lequel elle a été validée. Ce sont deux jeux de données différents, qui donnent des chiffres différents pour le même site, et un graphique construit sur le mauvais paraît parfaitement plausible. Choisissez celle sur laquelle votre équipe fait réellement son reporting, et notez ce choix là où la personne suivante le trouvera.
Le choix qui se paie plus tard : Impression associée au site ou à l’URL
Le connecteur vous fait choisir l’une des deux tables, et la différence n’a rien de cosmétique : les deux tables ne comptent pas de la même façon, et donnent donc des totaux différents pour les mêmes jours.
- Impression associée au site vous donne la Requête (Query), le pays, l’appareil et la date, mais pas de page de destination. Elle compte comme le graphique de la vue d’ensemble de Search Console, par propriété : quand deux de vos pages apparaissent pour une même recherche, cela fait une seule impression.
- Impression associée à l’URL vous donne la Page de destination (Landing Page) et la Requête, plus le pays, l’appareil et la date. Elle compte par page : la même recherche qui affiche deux de vos pages fait deux impressions, et les clics comme le CTR sont attribués à chaque URL.
La question SEO la plus naturelle, quelles requêtes amènent du trafic sur cette page ?, a donc une réponse dans Looker Studio, mais seulement depuis la table Impression associée à l’URL, et seulement selon sa façon de compter. Ses impressions ne correspondront ni aux totaux de la table Impression associée au site ni à la vue d’ensemble de Search Console pour les mêmes dates. Aucun des deux chiffres n’est faux : Google agrège par propriété les données par requête, pays, appareil et date, et par page les données par page (Aide Search Console, rapport sur les performances).
Le piège, c’est de mélanger les deux. Un graphique ou une combinaison qui réunit les deux tables additionne des chiffres comptés de deux façons différentes, et rien dans le canevas ne le signale. Choisissez une table par question : Impression associée à l’URL quand la question porte sur des pages, Impression associée au site quand il vous faut les totaux que vos parties prenantes voient dans Search Console.
Ce que le connecteur ne peut toujours pas vous donner
Même dans la table Impression associée à l’URL, les requêtes que Google anonymise pour protéger la confidentialité des internautes manquent dans toutes les lignes par requête : un tableau requête × page totalise donc toujours moins que les clics de la page elle-même. L’API Search Analytics de Search Console renvoie les deux agrégations, par propriété et par page, et tout outil qui la lit à intervalles réguliers peut les conserver côte à côte : le détail requête × page à côté des totaux du site, qui incluent encore le trafic anonymisé, et au-delà des seize mois que conserve Search Console.
La solution n’est donc pas un meilleur graphique, mais de lire la même API dans un outil qui conserve les deux vues.
Les quatre murs, dans l’ordre où vous allez les heurter
1. Seize mois, pas un de plus
Search Console conserve environ seize mois de données de performances. Looker Studio l’interroge en direct : l’historique de votre tableau de bord est donc celui de Search Console, sans aucune archive derrière. La première fois que quelqu’un demande une comparaison de saisonnalité sur deux ans, la réponse est que les données n’existent plus nulle part, à moins que vous ne les ayez stockées vous-même depuis le début.
2. Les requêtes anonymisées empêchent les chiffres de concorder
Search Console écarte les requêtes très peu fréquentes pour protéger la confidentialité des internautes (Google parle de requêtes anonymisées). La conséquence piège tout le monde, sans cesse : la somme d’une table au niveau des requêtes sera toujours inférieure à la carte des clics au niveau du site, sur la même page. Aucun des deux chiffres n’est faux : ce sont deux populations différentes. Mais une partie prenante face à deux totaux qui ne concordent pas posera la question tous les mois, et un graphique « top requêtes » omet discrètement toute la longue traîne tout en ayant l’air complet.
3. Les deux derniers jours ne sont pas définitifs
Search Console publie des données récentes en quelques heures, puis les révise à la hausse à mesure que le traitement se termine. Un tableau de bord consulté le lundi et qui inclut la veille affiche un chiffre provisoire que Google relèvera plus tard dans la semaine. Rien dans le canevas de Looker Studio n’indique quelles lignes sont encore en cours de consolidation : la courbe plonge sur le bord droit, et quelqu’un y voit une baisse.
4. Tout reste enfermé dans le canevas
Chaque nouvelle question est un nouveau graphique, construit à la main par la personne qui a les droits de modification. Une combinaison plafonne à cinq sources de données et vous donne une logique de jointure plutôt que du SQL. Alors, quand la question devient « comment les clics organiques ont-ils évolué face aux dépenses payantes le trimestre dernier ? », vous réconciliez deux tableaux de bord à l’œil nu, et c’est précisément le moment où l’on commence à se demander si le canevas est le bon contenant. Nous poussons cet argument plus loin dans les alternatives à Looker Studio (en anglais).
L’autre voie : lire la même API là où l’on peut faire des jointures
TableBI connecte Search Console par le même flux OAuth, puis conserve les données à deux altitudes : search_console_raw, la table brute, qui garde la requête et la page ensemble sur chaque ligne, et facts, où clics et impressions suivent les mêmes définitions multicanales que vos plateformes publicitaires. L’installation tient en trois commandes :
# installer la CLI et apprendre à votre agent à la piloter npm i -g @tablebi/cli tablebi login tablebi install # le navigateur s’ouvre pour l’OAuth, puis l’historique se synchronise tablebi connect gsc --site sc-domain:example.com # vérifier ce qui a été chargé, et sa fraîcheur tablebi sources
La question requête × page tient désormais en une seule instruction, exécutée sur une copie stockée plutôt que sur l’API en direct :
# quelles requêtes apportent des impressions à quelles pages ? tablebi ask "SELECT query, page, SUM(clicks) AS clicks, SUM(impressions) AS imp, AVG(position) AS pos FROM search_console_raw WHERE date >= (SELECT MAX(date) FROM search_console_raw) - 28 GROUP BY query, page ORDER BY imp DESC LIMIT 50"
Deux détails de cette requête SQL sont délibérés. Le filtre de date s’ancre sur MAX(date) et non sur la date du jour : comme les deux derniers jours ne sont pas définitifs, « aujourd’hui » n’est pas encore une ligne qui existe, et s’ancrer sur le calendrier donne une fenêtre vide chaque matin. Et chaque réponse revient avec un bloc de confiance (trust block) : la fraîcheur de chaque source et les mises en garde utiles ici, à savoir que les deux derniers jours sont provisoires et que les sommes par requête restent, par construction, inférieures aux totaux du site. Votre agent les lit, et cesse d’annoncer avec aplomb une révision comme une baisse.
Pour le workflow Search Console complet, et pas seulement la connexion, voir Claude Code pour le SEO (en anglais) ; si ce que vous vouliez vraiment, c’était l’API brute sans écrire de client OAuth, voir l’alternative à l’API Search Console (en anglais).
La question hors de portée du canevas
La raison de sortir Search Console de son propre tableau de bord est rarement Search Console elle-même. C’est que l’organique n’est qu’une ligne d’un tableau qui contient aussi le payant, et que le plafond des combinaisons est l’endroit où ce tableau cesse d’être constructible :
# clics organiques à côté des dépenses payantes, un seul résultat, mêmes définitions tablebi ask "SELECT platform, SUM(clicks) AS clicks, SUM(cost) AS spend FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY platform ORDER BY clicks DESC"
L’épingler sur une URL en direct
Quand une vue mérite d’être conservée, épinglez-la. Ce qui est enregistré, c’est la requête SQL et non une capture figée, si bien que l’URL se met à jour d’elle-même à chaque synchronisation de la source :
tablebi pin --title "Search Console — 28 days" \ --widget "Daily clicks::line=SELECT date, SUM(clicks) AS clicks FROM search_console_raw …" \ --widget "Top query × page=SELECT query, page, SUM(impressions) AS imp FROM search_console_raw …" ✓ published → https://dk.tablebi.com/d/dsh_… (public, read-only, self-refreshing)
En voici un vrai : des données Search Console en direct sur un portefeuille de sites, épinglées exactement de cette façon. Ce n’est pas une maquette ; il se met à jour à chaque synchronisation des sources :