Pourquoi exporter vos données Search Console vers BigQuery

La Search Console ne garde que 16 mois de données. Pour comparer une saison à la précédente, il faut un historique plus long.

Voici comment exporter les données de la Search Console vers BigQuery, et ce que cet export change pour vous.

Exporter les données de Search Console vers BigQuery : guide pour une analyse SEO élargie

L’export dépasse les rapports natifs de la Search Console

Les rapports de performances de la Search Console donnent une lecture immédiate des clics, impressions, taux de clics et positions. BigQuery transforme ces données en tables interrogeables en SQL. Ce langage permet de filtrer, agréger et croiser de grands volumes.

La différence opérationnelle est nette :

• Search Console : consultation rapide, filtres prêts à l’emploi et visualisation des indicateurs principaux, avec un volume de lignes restreint dans les interfaces d’export.
• BigQuery : stockage continu, requêtes SQL, agrégation personnalisée et rapprochement avec d’autres tables, sans plafond quotidien de lignes exportées.

L’export porte sur le rapport de performances de la propriété. Il couvre les recherches Web, Images, Vidéos, Actualités, Discover et Google Actualités, avec les dimensions disponibles pour chacune. Les requêtes anonymisées sont traitées à part : leur texte n’est pas transmis.

L’interface présente des limites d’affichage. L’API Search Analytics plafonne les résultats à 50 000 lignes par jour et par type de recherche. L’export BigQuery échappe à cette limite quotidienne.

BigQuery range les lignes dans des tables partitionnées par date. Chaque partition regroupe une journée de données. Vous pouvez ainsi interroger une période précise sans relire tout l’historique.

Les données deviennent interrogeables et réutilisables

Vous regroupez les requêtes par pays, appareil, type de recherche, date ou propriété. Puis vous calculez clics, impressions, taux de clics et positions moyennes.

Une requête SQL isole par exemple les recherches mobiles en France. Elle compare deux périodes, regroupe les expressions de longue traîne ou mesure la visibilité d’un ensemble d’URL. Les fonctions SUM, GROUP BY, WHERE et ORDER BY structurent ces analyses.

Quatre fonctions SQL pour structurer vos analyses

• SUM

  Additionne les clics et les impressions d’un périmètre, avant de calculer le taux de clics.

• GROUP BY

  Regroupe les lignes par pays, appareil, type de recherche ou date avant tout calcul.

• WHERE

  Restreint l’analyse à un sous-ensemble, par exemple les recherches mobiles en France.

• ORDER BY

  Classe le résultat, par exemple par nombre de clics décroissant.

Les résultats alimentent ensuite un tableau de bord, une feuille de calcul ou un outil de visualisation. Ils peuvent aussi partir vers un service de stockage externe. Des tables intermédiaires évitent de recalculer sans cesse les mêmes agrégations.

BigQuery conserve les données Search Console à partir de l’activation

L’export quotidien démarre avec la journée courante

La Search Console exporte les données une fois par jour, mais l’heure de transfert peut varier d’une table à l’autre. L’heure de publication figure dans la table ExportLog, exprimée en heure du Pacifique.

Après une configuration réussie, le premier export arrive dans un délai maximal de 48 heures. Il contient les données du jour de l’export, pas l’historique déjà disponible dans la Search Console.

La première livraison peut donc créer les tables avec une seule journée exploitable. Les jours suivants ajoutent de nouvelles partitions. L’historique se construit ainsi à partir de l’activation.

La conservation dépend du paramétrage des partitions

Les tables et leurs partitions sont conservées indéfiniment par défaut. Une règle globale du projet ou de l’organisation peut fixer une autre durée. Cette conservation dépasse la fenêtre d’analyse offerte par l’interface de la Search Console :

• Conservation indéfinie par défaut, sauf règle contraire du projet ou de l’organisation.
• Fenêtre d’analyse de l’interface Search Console, plus courte que cette conservation.

L’export ne reconstitue pas les données antérieures à son activation. Pour récupérer une période passée, il faut recourir aux rapports de la Search Console ou à l’API, avec leurs limites de lignes.

La table ExportLog permet de contrôler les journées effectivement enregistrées. Une ligne confirme la réussite d’un export. Une tentative échouée n’y apparaît pas.

Contrôler les journées exportées

• Ouvrir la table ExportLog et repérer les journées enregistrées.
• Vérifier qu’une ligne existe pour chaque jour attendu depuis l’activation.
• Repérer les journées absentes avant la fenêtre de rattrapage d’une semaine environ.

Une erreur temporaire déclenche une nouvelle tentative immédiate. Une erreur persistante, comme un problème d’autorisation, reporte l’export au passage quotidien suivant. La Search Console tente alors de récupérer les journées manquées sur une semaine environ.

Pour maîtriser le stockage, il est possible de définir une expiration sur les partitions :

• 14 jours ou plus : durée minimale à respecter pour ne pas perturber l’export automatique.
• Un à six mois : conservation adaptée aux contrôles opérationnels et aux audits rapprochés.
• Douze mois ou davantage : choix cohérent pour les comparaisons saisonnières et les analyses annuelles.

Trois tables BigQuery distinguent propriété, URL et suivi des exports

Chaque table répond à un niveau d’analyse

La table searchdata_site_impression agrège les performances au niveau de la propriété. Elle contient la date, la propriété, la requête, le pays, le type de recherche, l’appareil, les impressions, les clics et la position cumulée.

La table searchdata_url_impression ajoute l’URL de destination. Elle garde les dimensions requête, pays, appareil et type de recherche, ainsi que des indicateurs liés aux apparences dans les résultats.

La table ExportLog ne contient aucune performance SEO. Elle suit les données exportées, la table concernée, la date de données, la version de l’export et l’heure de publication.

Table	Niveau d’agrégation	Usage principal
searchdata_site_impression	Propriété, requête, pays, appareil et type de recherche	Mesurer la visibilité globale et analyser les requêtes sans distinguer les pages.
searchdata_url_impression	URL, requête, pays, appareil, type de recherche et apparence	Relier une requête à la page qui reçoit l’impression ou le clic.
ExportLog	Export, table et date de partition	Contrôler les journées et les tables effectivement publiées.

Les lignes ne sont pas nécessairement consolidées par date, URL, site ou combinaison de dimensions. Une même requête peut donc apparaître plusieurs fois. Agrégez-la avant toute interprétation.

Les mesures exigent des calculs contrôlés

Les colonnes clicks et impressions se totalisent avec SUM. Le taux de clics se calcule en divisant la somme des clics par la somme des impressions, et non en faisant la moyenne de taux individuels.

La position exportée repose sur une base zéro, où la première position vaut 0. Dans searchdata_site_impression, la position moyenne se calcule ainsi : SUM(sum_top_position) / SUM(impressions) + 1.

Dans searchdata_url_impression, le calcul repose sur sum_position selon la même logique : SUM(sum_position) / SUM(impressions) + 1. Cette correction restitue une position sur une base commençant à 1.

Une requête fiable sélectionne donc les colonnes utiles, filtre les partitions de date, agrège les métriques, puis regroupe les dimensions retenues. Une clause LIMIT seule ne réduit pas nécessairement le volume lu.

Exemple de structure SQL pour suivre les performances Web quotidiennes :

• SELECT
• data_date,
• SUM(impressions) AS impressions,
• SUM(clicks) AS clicks,
• SUM(clicks) / SUM(impressions) AS ctr,
• SUM(sum_top_position) / SUM(impressions) + 1 AS position_moyenne
• FROM projet.searchconsole.searchdata_site_impression
• WHERE search_type = ‘WEB’
• AND data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
• AND CURRENT_DATE()
• GROUP BY data_date
• ORDER BY data_date DESC ;

Les requêtes anonymisées restent exclues de l’export Search Console

L’anonymisation protège les recherches rares

La Search Console anonymise certaines requêtes rares. Ce seuil protège la confidentialité des utilisateurs. Il ne permet pas de retrouver le texte individuel de ces recherches.

Ces recherches peuvent peser peu ou beaucoup dans vos lignes visibles. Tout dépend de la propriété, du pays, du type de recherche et de la longue traîne. Leur texte reste inaccessible dans BigQuery.

Dans les tables exportées, is_anonymized_query signale une ligne anonymisée. La colonne query prend alors une chaîne vide. Vous distinguez ainsi une absence de texte d’une expression réellement saisie.

Les métriques associées restent utiles pour les totaux de performance. Elles ne permettent pas d’identifier les mots qui composent cette activité protégée.

Les filtres modifient la portée des totaux

Une analyse centrée sur les termes doit exclure les chaînes vides. Le filtre SQL recommandé est WHERE query != '', complété par les filtres de date, de pays, d’appareil ou de type de recherche nécessaires.

N’utilisez pas ce filtre pour le total général des clics ou des impressions. Les lignes anonymisées seraient retirées du résultat.

La comparaison avec un rapport natif impose donc de distinguer deux périmètres :

• Total Search Console : inclut les métriques liées aux requêtes anonymisées lorsqu’elles sont agrégées dans les données de performance.
• Requêtes nommées : inclut uniquement les lignes dont la colonne query contient un texte exploitable.

BigQuery relie les performances SEO aux pages et aux données métier

L’analyse par URL attribue le trafic aux pages

searchdata_url_impression associe les performances de recherche à l’URL vers laquelle l’utilisateur est dirigé. Il devient alors possible de comparer les pages d’une catégorie, d’un modèle produit, d’un répertoire ou d’un marché.

Le regroupement par URL révèle les pages qui génèrent le plus d’impressions, celles qui obtiennent le plus de clics et celles dont le taux de clics reste inférieur à leur visibilité.

Le regroupement par URL et par requête détaille les intentions couvertes par chaque page. On repère ainsi une page qui se positionne sur des requêtes éloignées de son sujet, ou plusieurs pages qui se concurrencent sur une même expression.

Les filtres par type de recherche distinguent les résultats Web, Images, Vidéos, Actualités et Discover. Cette séparation évite de comparer des environnements de visibilité dont les usages et les indicateurs diffèrent.

Les tables SEO rejoignent les données de l’entreprise

BigQuery permet de rapprocher les données de la Search Console de plusieurs sources :

• Tables GA4 : comportement des visiteurs après l’arrivée sur le site.
• Inventaire de contenus : pages et types de contenus publiés.
• Catalogue produit : références rattachées aux pages commerciales.
• CRM : relations clients et opportunités commerciales.
• Système de commandes : ventes enregistrées par page ou par produit.
• Référentiel de campagnes : campagnes et parcours associés aux URL.

La clé de jointure la plus directe avec GA4 est l’URL de destination, complétée par la date lorsque les tables partagent la même granularité quotidienne. Les paramètres d’URL, les redirections et les écarts de normalisation doivent être traités avant la jointure.

Un rapprochement fiable peut combiner plusieurs clés :

• Date : compare les performances de recherche avec les sessions, conversions ou ventes du même jour.
• URL de destination : relie les clics de la Search Console aux pages consultées dans GA4 ou aux contenus du référentiel interne.
• Identifiant produit : rattache une page produit à ses commandes, marges, stocks ou ruptures de disponibilité.

La Search Console mesure l’exposition et les clics issus des résultats Google. GA4 mesure les interactions après l’arrivée sur le site.

La configuration de l’export exige un projet Google Cloud prêt

Les autorisations se préparent avant la Search Console

Avant de commencer, vérifiez que vous disposez :

• D’une propriété Search Console.
• D’un compte autorisé à la gérer en tant que propriétaire.
• D’un projet Google Cloud associé à la facturation.

Ajoutez ensuite le compte de service suivant au projet : search-console-data-export@system.gserviceaccount.com

Attribuez-lui les rôles Utilisateur de tâche BigQuery et Éditeur de données BigQuery. Le premier autorise l’exécution des opérations. Le second permet l’écriture des données exportées.

La destination se définit dans les paramètres de la Search Console

Dans la Search Console, ouvrez les paramètres de la propriété, puis la fonction d’exportation groupée de données. Saisissez l’ID du projet Cloud. Ni son numéro, ni son nom d’affichage.

Le nom d’ensemble de données par défaut est searchconsole. Si plusieurs propriétés alimentent le même projet, choisissez un nom distinct pour chacune. Il doit toujours commencer par searchconsole.

Sélectionnez l’emplacement de l’ensemble de données avant le premier export. BigQuery associe les tables à cet emplacement. Le modifier devient difficile une fois les exports démarrés.

En cas d’erreur durable, contrôlez successivement :

1. Projet Cloud : vérifiez l’ID utilisé et la présence de la facturation.
2. API : confirmez l’activation de BigQuery et de BigQuery Storage.
3. Compte de service : contrôlez les deux rôles IAM attribués au compte Search Console.
4. Emplacement : vérifiez que le jeu de données existe à la destination attendue.
5. Schéma et partitions : retirez toute modification incompatible et maintenez une expiration de partition d’au moins 14 jours.

L’export est gratuit, mais le stockage et les requêtes BigQuery coûtent

La facturation concerne l’usage de BigQuery

La Search Console ne facture pas l’export quotidien de ses données vers BigQuery. Les coûts proviennent du stockage des tables, du traitement des requêtes et, le cas échéant, des services utilisés pour visualiser ou transférer les résultats.

BigQuery propose une utilisation gratuite mensuelle comprenant les 10 premiers Gio de stockage et le premier Tio de données traité par les requêtes. Ces seuils s’appliquent au compte concerné, sous réserve des conditions Google Cloud.

Au-delà du quota gratuit, la tarification des requêtes à la demande se calcule selon le volume de données traité. Le tarif de référence indiqué par Google est de 6,25 dollars par Tio traité.

Le stockage actif au-delà des 10 Gio gratuits est facturé selon le volume conservé et la durée. Le stockage longue durée applique un tarif différent lorsque les données restent inchangées pendant la période prévue par BigQuery.

Le volume lu détermine le coût des analyses

Une requête qui lit toute la table URL peut traiter bien plus de données qu’une requête limitée à une semaine et à quelques colonnes. Le coût dépend du volume lu, et non seulement du nombre de lignes renvoyées.

Pour réduire le traitement :

• Partition de date : utilisez une clause WHERE data_date pour limiter les journées parcourues.
• Colonnes ciblées : sélectionnez les champs nécessaires plutôt que SELECT *, surtout dans la table URL.
• Agrégation réutilisable : matérialisez les résultats courants dans une table dédiée pour éviter de relire les données brutes.
• Limite de facturation : imposez un plafond de données traitées pour bloquer une requête qui dépasserait votre budget.

Configurez aussi un budget Google Cloud avec des alertes de seuil.

Le choix de BigQuery dépend de l’historique et des analyses attendues

L’export répond à cinq besoins SEO précis

BigQuery devient utile lorsque vous devez conserver les données au-delà de la fenêtre des rapports de la Search Console. L’activation crée un historique durable à partir du jour de démarrage.

Besoin	Solution la plus adaptée	Point de vigilance
Contrôle rapide d’une baisse de clics	Rapport de la Search Console	Lecture ponctuelle et volume affiché limité.
Extraction automatisée avec filtres	API Search Analytics	Plafond de 50 000 lignes par jour et par type de recherche.
Historique continu et analyses SQL	Export BigQuery	Historique créé seulement après l’activation.
Analyse par page et par requête	searchdata_url_impression	Agrégation SQL obligatoire avant interprétation.
Rapprochement avec le chiffre d’affaires	BigQuery et tables métier	URL, dates et règles d’attribution à normaliser.

Les limites doivent peser dans la décision

BigQuery ne récupère pas les 16 mois de données des rapports. Lancez l’export avant de perdre les données utiles.

Les requêtes anonymisées restent sans texte. L’export améliore la couverture des lignes et la conservation des métriques. Il ne contourne pas la protection des recherches rares.

La table exportée demande une compétence SQL minimale. Sans agrégation, une même clé peut apparaître plusieurs fois. Les totaux et les positions moyennes deviennent alors faux.

Avant d’activer l’export

• Vérifier la date à partir de laquelle l’historique doit commencer
• Préparer une requête SQL d’agrégation par clé
• Définir les règles de normalisation des URL et des dates
• Prévoir le rapprochement avec les données métier

Reste à fixer la durée de conservation de vos partitions, selon les contrôles opérationnels, les comparaisons saisonnières ou les analyses annuelles que vous prévoyez. Ce choix conditionne aussi bien le coût du stockage que la profondeur de votre historique.