Export Search Console vers BigQuery : le guide complet SEO + GEO

L'interface de Search Console t'affiche 1 000 lignes par rapport et garde 16 mois d'historique. Pour un site de 80 articles, ça suffit. Pour un site de 5 000 pages, ou dès que tu veux croiser tes requêtes avec autre chose que Search Console, tu te retrouves à exporter des CSV à la main. L'export en masse vers BigQuery (le « bulk data export ») règle ça : Google pousse chaque jour tes données de performance dans une base que tu interroges en SQL, et que tu gardes aussi longtemps que tu veux.

Voici comment le brancher sans casser l'export, lire correctement le schéma (le piège de la position moyenne surprend tout le monde), écrire trois requêtes utiles, et surtout ne pas laisser la facture ou les données anonymisées te tromper.

Pourquoi passer par BigQuery plutôt que l'interface

Trois limites de Search Console poussent à exporter :

• 1 000 lignes par vue : sur un gros site, la longue traîne des requêtes te reste invisible.
• 16 mois d'historique maximum : impossible de comparer trois ans de saisonnalité si tu n'as rien archivé.
• Aucune jointure : tu ne peux pas croiser une requête avec ton chiffre d'affaires, ton CRM ou tes logs serveur.

L'export en masse, présenté par Google en février 2023, lève ces trois points. Il contient l'ensemble des données de performance disponibles pour ta propriété, avec une exception importante : les requêtes anonymisées sont exclues (on y revient plus bas). Et il ne remplace pas l'API : si ton besoin, c'est un dashboard léger de 500 lignes, l'API suffit. L'export vaut le coup quand le volume ou la durée de conservation deviennent le problème.

Mise en place en 10 étapes courtes

Côté Google Cloud

1. Ouvre ton projet Google Cloud (ou crée-en un, avec facturation activée).
2. Dans APIs et services, active l'API BigQuery et la BigQuery Storage API.
3. Dans IAM et administration, ajoute le compte de service search-console-data-export@system.gserviceaccount.com avec deux rôles : BigQuery Job User (bigquery.jobUser) et BigQuery Data Editor (bigquery.dataEditor).

Il faut être propriétaire du projet pour accorder ces droits. N'ajoute que ces deux rôles, au niveau du projet prévu, rien de plus.

Côté Search Console

4. Va dans Paramètres > Export de données en masse de ta propriété.
5. Saisis l'identifiant du projet (le project ID, pas le numéro de projet).
6. Choisis le nom du dataset (il commence par searchconsole).
7. Choisis la localisation du dataset. Réfléchis-y : une fois l'export lancé, tu ne peux pas la changer facilement.
8. Valide. L'export est planifié.

Ensuite

9. Attends jusqu'à 48 heures avant de voir la première table. C'est normal, ne reconfigure pas dans l'intervalle.
10. Vérifie que les tables apparaissent, puis règle tout de suite l'expiration des partitions (voir la section coûts).

Ce que contient le dataset

Trois objets à connaître :

Colonnes clés des deux tables de données : data_date (le jour, en heure du Pacifique, donc un décalage possible avec tes rapports en heure de Paris), query, is_anonymized_query, country, search_type (web, image, video, news, discover, googleNews), device, impressions et clicks. La table par URL ajoute url et des booléens pour les apparences enrichies.

Le piège de la position moyenne

Il n'y a pas de colonne « position ». Il y a sum_top_position (table par propriété) et sum_position (table par URL), des sommes à diviser par les impressions, avec un +1 car la valeur est indexée à partir de zéro. La formule est documentée dans la référence des tables Search Console :

SUM(sum_top_position) / SUM(impressions) + 1

Si tu fais un AVG(sum_top_position), ton résultat est faux, et personne ne s'en apercevra avant que tu compares avec l'interface. Vérifie toujours sur une requête connue.

Trois requêtes qui rapportent

1. Requêtes en « striking distance »

Les requêtes entre la position 8 et 20 avec assez d'impressions : ce sont les pages à pousser en priorité.

SELECT
  query,
  SUM(impressions) AS impressions,
  SUM(clicks) AS clicks,
  SUM(sum_top_position) / SUM(impressions) + 1 AS avg_position
FROM `mon-projet.searchconsole.searchdata_site_impression`
WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY)
  AND is_anonymized_query = FALSE
GROUP BY query
HAVING avg_position BETWEEN 8 AND 20
  AND impressions >= 50
ORDER BY impressions * (21 - avg_position) DESC
LIMIT 50;

Le tri par impressions * (21 - position) met en tête les requêtes à la fois visibles et proches de la première page. Pense à filtrer sur search_type si tu veux isoler le web des images ou de Discover.

2. Pages qui se marchent dessus (cannibalisation)

SELECT
  query,
  COUNT(DISTINCT url) AS nb_urls,
  SUM(impressions) AS impressions
FROM `mon-projet.searchconsole.searchdata_url_impression`
WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY)
  AND is_anonymized_query = FALSE
GROUP BY query
HAVING nb_urls > 1 AND impressions >= 100
ORDER BY impressions DESC
LIMIT 50;

Une même requête servie par plusieurs URL n'est pas toujours un problème (une home et un article peuvent coexister), mais c'est la liste de départ pour l'audit décrit dans notre guide sur la cannibalisation de mots-clés.

3. Mesurer la part cachée : les requêtes anonymisées

SELECT
  is_anonymized_query,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions
FROM `mon-projet.searchconsole.searchdata_site_impression`
WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY)
GROUP BY is_anonymized_query;

Cette requête te dit quelle part de tes clics vient de requêtes que Google refuse de te montrer. C'est l'angle mort le plus mal compris de l'export : tes analyses par requête ne portent jamais sur 100 % du trafic.

Mini cas illustratif : retrouver du trafic oublié

Prenons un cas fictif, pour les ordres de grandeur. Un site e-commerce de 3 000 pages affiche, dans l'interface, une longue traîne de requêtes tronquée à 1 000 lignes. Une fois l'export en place depuis un trimestre, la requête « striking distance » ressort 120 requêtes en positions 8 à 20 avec au moins 50 impressions, dont 40 qui n'apparaissaient dans aucun rapport de l'interface. Trois pages regroupent la moitié des impressions concernées : c'est là qu'on réécrit d'abord le titre, l'introduction et le maillage interne. Le gain n'est pas garanti, mais la liste de priorités, elle, est enfin complète.

Coûts et garde-fous

Le stockage et les requêtes BigQuery sont facturés au-delà du quota gratuit Google Cloud. Trois réflexes :

• Règle l'expiration des partitions : sans réglage, les données s'accumulent indéfiniment. Google recommande de garder au minimum 14 jours ; garde-en bien plus si l'objectif est d'archiver, mais décide-le, ne le subis pas.
• Ne modifie pas le schéma des tables générées : crée des vues ou des tables dérivées à la place.
• Requête toujours avec un filtre sur data_date : la table est partitionnée par date, un SELECT * sans filtre lit tout l'historique et coûte en conséquence.

Surveille aussi la table ExportLog : elle t'indique ce qui a bien été enregistré. Une erreur non persistante est retentée le lendemain, mais un problème d'accès durable doit être corrigé chez toi (rôles, facturation).

Et pour le GEO ?

Search Console ne te dit pas si ChatGPT ou Perplexity te cite. Mais l'export t'aide de deux façons : tu isoles les requêtes conversationnelles longues (huit mots et plus) qui ressemblent à des prompts, et tu conserves des années d'historique pour repérer l'effet des AI Overviews sur tes clics. Pour la partie rapports IA de Google, regarde aussi notre article sur le rapport IA de Search Console.

Checklist avant de fermer l'onglet

1. API BigQuery et BigQuery Storage API activées.
2. Compte de service ajouté avec exactement deux rôles.
3. Project ID (pas le numéro) saisi, localisation choisie en connaissance de cause.
4. Expiration des partitions définie.
5. Première table présente après 48 h, ExportLog consultée.
6. Position recalculée avec SUM(sum_top_position) / SUM(impressions) + 1, vérifiée contre l'interface.
7. Part de requêtes anonymisées mesurée.

Si tu veux savoir avant tout ça où en est ton site, obtiens ton score /100 gratuitement : l'audit signale les pages à corriger côté SEO technique et GEO, et le rapport complet PDF détaille les actions. Pour la mesure business derrière tes données, lis aussi comment mesurer le ROI du SEO avec GA4.

FAQ

L'export vers BigQuery est-il gratuit ?

Le stockage et les requêtes dans BigQuery sont facturés au-delà du quota gratuit de Google Cloud, et un compte de facturation est requis. Règle l'expiration des partitions et filtre toujours par date.

Combien de temps avant de voir des données ?

Jusqu'à 48 heures après la configuration réussie pour la première exportation. Ensuite l'export est quotidien. Les données ne sont pas rétroactives : tu ne récupères que l'historique généré à partir de l'activation, d'où l'intérêt de l'activer tôt.

Pourquoi mes chiffres ne collent-ils pas avec l'interface ?

Trois causes fréquentes : les requêtes anonymisées sont exclues de l'export, la date data_date est en heure du Pacifique, et la position moyenne doit être recalculée avec la formule de somme divisée par les impressions plus un.

Puis-je changer la localisation du dataset plus tard ?

Pas facilement une fois l'export lancé. Choisis-la avant de valider, en fonction de là où vivent tes autres données à joindre.

À retenir

• L'export en masse pousse chaque jour tes données Search Console dans BigQuery, sans limite de 1 000 lignes ni plafond de 16 mois.
• Mise en place : deux API, un compte de service avec deux rôles, project ID, dataset, localisation, puis 48 h d'attente.
• Deux tables de données : par propriété et par URL ; la position se recalcule avec SUM(sum_top_position) / SUM(impressions) + 1.
• Les requêtes anonymisées sont exclues : mesure leur part avant de conclure quoi que ce soit.
• Règle l'expiration des partitions, ne touche pas au schéma, filtre toujours sur data_date.