Looker Studio et Search Console : tableau de bord SEO

Le connecteur Search Console de Looker Studio est gratuit, natif et se branche en quelques clics. C'est aussi un outil dont les choix de départ faussent facilement les chiffres : le choix entre la table « site » et la table « URL », les lignes qui disparaissent quand on ajoute une dimension, une formule marque / hors marque qui ne filtre rien à cause d'une expression régulière mal écrite. Ce guide porte sur l'outil et ses pièges, pas sur ce qu'il faut mesurer.

Si vous cherchez la liste des indicateurs à suivre, elle est ailleurs. Ici, on regarde comment le connecteur fabrique ses données, pourquoi un total ne correspond pas à celui de Search Console, et comment construire une source fiable sur laquelle un rapport peut reposer sans que personne ne se demande chaque mois d'où vient l'écart.

Ce que le connecteur récupère vraiment

Le connecteur officiel interroge les données de performance de Search Console pour une propriété que vous avez le droit de consulter. Ce n'est pas une copie de l'interface : c'est une requête envoyée à la même source que le rapport de performances, avec les mêmes limites de fond. Vous retrouvez donc les clics, les impressions, le CTR et la position moyenne, ventilés par date, requête, page, pays, appareil et apparence dans les résultats.

Trois conséquences pratiques découlent de ce fonctionnement. D'abord, la rétention : Search Console conserve seize mois de données de performance, et Looker Studio ne peut pas remonter plus loin. Un tableau de bord qui démarre aujourd'hui ne vous donne pas un historique que Google n'a plus. Ensuite, la fraîcheur : les données récentes arrivent avec un décalage d'un à deux jours, et les derniers jours sont parfois révisés. Enfin, le compte utilisé pour autoriser la source compte : si la personne qui l'a créée perd l'accès à la propriété, les graphiques affichent une erreur pour tous les lecteurs du rapport.

Au moment de créer la source, on vous demande de choisir la propriété, puis une table, puis un type de recherche. Ces trois choix sont figés tant qu'on ne recrée pas la source, et ce sont eux qui expliquent la plupart des écarts observés plus tard. Mieux vaut les comprendre avant de bâtir la moindre page du rapport.

Une remarque sur les propriétés : une propriété de domaine regroupe tous les protocoles et tous les sous-domaines, alors qu'une propriété de préfixe d'URL ne couvre qu'un périmètre précis. Si vous comparez un rapport Looker Studio à l'interface, vérifiez d'abord que les deux pointent la même propriété. C'est l'écart le plus banal, et celui qu'on oublie le plus souvent de contrôler.

Table site ou table URL : le choix qui change les chiffres

Le connecteur propose deux tables. La table d'impressions par site agrège les données au niveau de la propriété : une impression est comptée une seule fois pour le site, même si plusieurs de vos pages apparaissent sur la même page de résultats. La table d'impressions par URL compte chaque page séparément : si deux de vos pages s'affichent pour la même recherche, deux impressions sont enregistrées, une pour chaque URL.

Cette différence a un effet direct sur les totaux. Pour un même site et la même période, le nombre d'impressions peut être plus élevé dans la table URL. Le CTR et la position moyenne, calculés à partir de ces impressions, divergent eux aussi. Aucune des deux tables n'est fausse : elles répondent à des questions différentes.

La position moyenne mérite un mot à part. Dans la table site, elle reflète la meilleure position obtenue par votre site pour une requête donnée, alors que dans la table URL elle se rapporte à la page concernée. Un même mot-clé peut donc afficher une position de 3 d'un côté et de 7 de l'autre sans que rien ne soit cassé.

Le principe de décision tient en quelques règles simples.

• Utilisez la table site pour les tendances globales, pour tout total que vous voulez rapprocher de l'interface de Search Console et pour les analyses par requête, par pays ou par appareil.
• Utilisez la table URL dès que la page est l'unité d'analyse : performances par gabarit, par dossier ou par auteur, et toute jointure avec des données par URL venues d'un autre outil.
• Ne mélangez jamais les deux tables dans un même graphique ou dans une même rangée de chiffres clés, sous peine de comparer des impressions qui ne se comptent pas de la même manière.
• Si le rapport a besoin des deux vues, créez deux sources distinctes et nommez-les explicitement, par exemple « GSC – site » et « GSC – URL », pour que personne ne les confonde en modifiant un graphique.

Limites de lignes, anonymisation et faux échantillonnage

Le mot « échantillonnage » est à manier avec précaution pour ce connecteur. Il n'y a pas d'échantillonnage au sens de certains outils d'analyse : les clics et les impressions ne sont pas extrapolés à partir d'un sous-ensemble. Ce qui se produit est différent, et plus discret : des lignes manquent, et les totaux changent selon les dimensions que vous ajoutez.

Première source d'écart, les requêtes anonymisées. Google retire des données les requêtes saisies par très peu d'utilisateurs, pour protéger leur vie privée. Quand vous affichez un total sans dimension, ces clics sont comptés. Dès que vous ajoutez la requête comme dimension, les lignes anonymisées disparaissent du tableau, et la somme des lignes devient inférieure au total. Plus un site a de longue traîne, plus l'écart est visible.

Deuxième source, le plafond de lignes côté Search Console. L'API limite le nombre de lignes renvoyées pour chaque combinaison de site, de jour et de type de recherche. Sur un petit site, ce plafond ne se voit jamais. Sur un gros catalogue, croiser requête, page, pays et appareil sur une année fait exploser le nombre de combinaisons, et les plus rares sont écartées. Le tableau reste plausible, mais il n'est plus exhaustif. Plus vous empilez de dimensions, plus vous augmentez le risque de troncature.

Troisième source, plus banale : les limites d'affichage de Looker Studio lui-même. Un tableau ne montre que la page de lignes affichée, et un graphique limite le nombre de valeurs tracées. Un tableau paginé à cent lignes n'est pas une extraction complète, même si personne ne le dit.

Une façon simple de détecter le problème consiste à placer deux chiffres clés côte à côte : le total des clics sans dimension, et la somme des clics d'un tableau par requête sur la même période. L'écart entre les deux, rapporté au total, vous donne la part de trafic invisible au niveau requête. Il est normal qu'il soit non nul ; ce qui compte est de le connaître et de le noter dans le rapport.

• Gardez les totaux dans des cartes sans dimension, alimentées directement par la source, et n'additionnez jamais les lignes d'un tableau pour les reconstituer.
• Réservez les dimensions fines (requête, page) aux tableaux d'exploration, et utilisez pour les tendances des graphiques à dimension unique, la date.
• Filtrez plutôt que d'empiler : un tableau par pays ou par dossier est plus fiable qu'un tableau unique croisant tout.
• Indiquez dans une note du rapport que les requêtes anonymisées n'apparaissent pas dans les tableaux par requête.

Marque et hors marque : un champ calculé qui filtre vraiment

Séparer le trafic de marque du trafic hors marque est l'usage le plus courant des champs calculés avec ce connecteur. L'idée est de créer un champ qui classe chaque requête dans l'une des deux catégories, puis de l'utiliser comme dimension ou comme filtre. La formule de base s'écrit avec une instruction CASE et une fonction de correspondance par expression régulière.

Un exemple pour une marque fictive appelée « Dupont Jardins » serait : CASE WHEN REGEXP_MATCH(Query, "(?i).*(dupont|dupon|dupond|dupont jardin).*") THEN "Marque" ELSE "Hors marque" END. Plusieurs détails font la différence entre une formule qui fonctionne et une formule qui ne classe rien.

Le premier piège est la correspondance totale. Dans Looker Studio, REGEXP_MATCH exige que l'expression corresponde à la chaîne entière, pas seulement à une partie. Écrire simplement dupont ne reconnaît que la requête « dupont » exacte. Il faut entourer le motif de .* de chaque côté, comme dans l'exemple ci-dessus, pour reconnaître « avis dupont jardins ».

Le deuxième piège est la casse. Le préfixe (?i) rend la comparaison insensible aux majuscules. Sans lui, « Dupont » et « dupont » sont traités différemment. Dans Search Console les requêtes sont en général en minuscules, mais mieux vaut ne pas en dépendre.

Le troisième piège est l'orthographe. Les internautes écrivent le nom d'une marque avec des fautes, sans espace, avec ou sans trait d'union, ou avec une extension comme « avis » ou « login ». Listez les variantes réellement observées dans votre rapport de requêtes, pas celles que vous imaginez. Une relecture de la liste tous les trimestres est raisonnable, car de nouvelles variantes apparaissent avec le temps.

Le quatrième piège est l'équivalent d'un faux positif : une marque dont le nom est aussi un mot courant classe en « marque » des requêtes qui n'en sont pas. Dans ce cas, préférez des motifs plus longs, par exemple le nom accolé au domaine d'activité, plutôt qu'un mot unique très générique. Si le nom de marque est ambigu, acceptez qu'une partie des requêtes soit mal classée et documentez la règle plutôt que de la compliquer sans fin.

• Testez le champ sur un tableau par requête trié par clics, et vérifiez à l'œil les vingt premières lignes de chaque catégorie.
• Stockez le motif dans un seul champ calculé, réutilisé partout, plutôt que de recopier la formule dans chaque graphique.
• Les expressions régulières de Looker Studio suivent la syntaxe RE2 : pas de lookahead ni de référence arrière, ce qui limite les motifs d'exclusion complexes.

Calculer correctement le CTR et la position dans vos champs

Une fois la séparation marque / hors marque en place, il est tentant de calculer un CTR par catégorie. C'est là qu'apparaît l'erreur de moyenne la plus courante. Si vous faites la moyenne des CTR de chaque ligne, une requête à deux impressions pèse autant qu'une requête à dix mille. Le CTR correct d'un groupe est toujours la somme des clics divisée par la somme des impressions, soit SUM(Clicks) / SUM(Impressions).

Le connecteur fournit déjà un champ CTR qui s'agrège correctement dans les cartes et les graphiques. Le risque survient quand vous créez votre propre champ calculé ou que vous exportez un tableau vers une feuille de calcul pour le retraiter : à ce moment-là, la moyenne des pourcentages réintroduit le biais.

La position moyenne obéit à la même logique, avec une nuance supplémentaire. Elle est pondérée par les impressions dans Search Console. Additionner ou moyenner des positions de lignes sans pondération donne un chiffre qui ne correspond à aucun de ceux de l'interface. Utilisez le champ fourni par le connecteur pour les cartes, et traitez les moyennes calculées à la main comme des approximations à ne pas publier.

Attention aussi à la comparaison entre périodes. Looker Studio sait afficher la variation avec la période précédente, mais si le nombre de jours, ou la part de jours jugés incomplets, diffère, la variation est trompeuse. Évitez de finir une plage de dates sur les deux derniers jours, qui sont les plus susceptibles d'être révisés.

Stabiliser la source quand le rapport grossit

Un rapport qui interroge Search Console en direct à chaque affichage devient lent quand il empile les graphiques, et il expose plus souvent aux erreurs de quota. Looker Studio propose une extraction de données : vous figez un sous-ensemble de dimensions et de métriques, actualisé à intervalle régulier, qui alimente ensuite le rapport sans nouvelle requête à chaque chargement. C'est un bon compromis pour un rapport consulté par beaucoup de monde.

Pour un site volumineux ou quand il faut conserver plus de seize mois d'historique, le connecteur direct atteint ses limites. Search Console permet d'exporter ses données en continu vers BigQuery, ce qui contourne le plafond de lignes de l'API pour les gros volumes et permet de garder l'historique au-delà de la fenêtre de rétention, à partir du jour où l'export est activé. Looker Studio se connecte ensuite à BigQuery comme à n'importe quelle autre source. C'est plus de travail à la mise en place, et il faut surveiller les coûts de requêtes, mais c'est la seule voie propre pour un catalogue de centaines de milliers de pages.

Quelle que soit l'option retenue, quelques règles d'hygiène évitent les mauvaises surprises :

• Faites autoriser la source par un compte d'équipe stable plutôt que par le compte personnel d'un salarié qui peut quitter l'entreprise.
• Dupliquez le rapport avant toute modification de la source : changer de table dans un rapport existant casse les champs qui en dépendent.
• Datez et documentez dans le rapport la table utilisée, le type de recherche et la règle marque / hors marque, pour que le lecteur comprenne d'où viennent les chiffres.
• Comparez une fois par trimestre un total du rapport avec l'interface de Search Console, sur une même période et une même propriété, et notez l'écart acceptable.