Stocker les données GSC : un enjeu de performance
Ecrit par Adama Tandia
le
Le plus important lors de la mise en place d’une stratégie SEO, c’est de s’assurer que vous avez la capacité de jauger l’impact de vos actions.
Pour cela, nous utilisons entre autres la Google Search Console qui est devenu un outil indispensable pour le SEO car elle permet d’avoir des données sur :
- Les performances de recherches d’un site web
- L’indexation des pages
- Les problèmes techniques
- L’expérience utilisateur
- Les backlinks (liens externes)
- Les données structurées
Les données qui vont nous intéresser ici, ce sont les performances de recherches, car les KPI fournit se confrontent à 2 problématiques majeures.
- La search console remonte des données à 16 mois maximum. Vous ne pouvez donc pas comparer 2 années entre elles et perdez énormément d’information au fil des années sur les performances de recherches de votre site.
- Les données de la search console sont échantillonnées
Exemple : Je veux savoir combien de trafic a été généré à la suite de requêtes marques et des requêtes hors marques :
- Mon trafic global est égal à 100
- Mon trafic hors marque sera égal à 20
- Mon trafic marque sera égale à 60
J’ai donc 20 de trafic qui a disparu et ce sera encore le cas si j’affine encore plus ma recherche en voulant savoir par exemple le trafic généré en hors marque sur un type de produit.
Pour faire face à ces 2 problématiques, nous pouvons mettre en place une historisation des données de la search console. Pour cela , il existe 2 solutions et chacune d’entre elles a ses avantages et ces inconvénients.
L’historisation des données GSC : un enjeu pour mesurer la performance
L’historisation des données GSC consiste à collecter, stocker et conserver les données de performances de la search console d’un site web. L’objectif est de pallier la limitation de 16 mois maximum de la GSC en créant votre propre base de données dans laquelle vous pouvez aller piocher pour la connecter à un dashboard de monitoring.
La méthode de stockage via la connexion native
La méthode de connexion native consiste à extraire chaque jour des données de la search console pour les stocker.
C’est assez simple à réaliser, la seule chose dont vous avez besoin, c’est de connaître la personne qui à la propriété de votre search console, d’avoir un accès GCP (Google Cloud Platform) ce qui peut être compliqué lorsque vous êtes dans une structure qui n’autorise pas l’accès à la suite Google.
Si ces conditions sont remplies, voici la marche à suivre :
- Aller sur la Google Search Console
- Cliquer sur « Paramètres »
- Cliquer sur « Exportation groupée de données »
Suivre le tutoriel : https://support.google.com/webmasters/answer/12917675?hl=fr
La méthode de stockage via l’api
La méthode de stockage via l’API consiste à piocher dans la search console pour y extraire 16 mois de données.
C’est une solution plus complexe à mettre en place pour laquelle Peak Ace peut vous accompagner soit en le réalisant pour vous, soit en vous apprenant à le faire pour que vous soyez indépendant dans la gestion de vos données.
Les avantages et inconvénients de chaque solution
Pour identifier les avantages et inconvénients, nous allons prendre en compte les 2 problématiques majeures que nous cherchons à palier :
- La search console remonte des données à 16 mois maximum. Vous ne pouvez donc pas comparer 2 années entre elles et perdez énormément d’information au fil des années sur les performances de recherches de votre site.
- Les données de la search console sont échantillonnées
La connexion native
Avantage :
- Echantillonnage : la connexion native offre la donnée la plus fiable, car elle est très peu échantillonnée. Cela permet de réaliser des analyses poussées en gardant assez de données pour que ce soit assez parlant là ou l’échantillonnage avec la connexion de base à la search console pouvait amener à des situations où on se retrouvait avec des KPI très bas à la fin.
Inconvénients :
- Limite de 16 mois : C’est un défaut qui reste vrai dans 16 mois qui suivent la mise en place de la connexion, car elle commence à partir du moment où la connexion est réalisé et n’est pas rétroactive. C’est-à-dire que si vous faites la connexion le 19 février 2025 à 10h48, vous allez stocker les données à partir de ce moment uniquement. Vous pourrez donc palier la limite de 16 à partir d’aout 2026. Cependant, à partir du moment où vous faites la connexion, il n’y a plus d’actions à réaliser, c’est automatique.
La connexion à l’API
Avantage :
- Limite de 16 mois : Ici, vu que nous allons piocher dans les 16 derniers mois, nous réglons le problème dès le lendemain de la connexion car on obtient 16 mois et 1 jour. En revanche, à la différence de la connexion native, l’extraction de données ne se met pas à a jour. C’est-à-dire que si vous faites la connexion en février 2025, vous allez stocker les 16 derniers mois, mais si vous voulez les données de mars, vous devez refaire une extraction de données.
Inconvénients :
Echantillonnage : Si vous possédez un petit site qui capitalise sur peu de mots-clés, il n’y a pas de problème ici. En revanche, si vous avez un assez gros site, c’est une solution qui n’est pas pour vous.
Vous allez perdre énormément de données, car l’extraction de données est limitée à 50 000 mots-clés par jour ce qui pour un gros e-commerce est très problématique.
Nombre de MC analysés par jour
Vous pouvez voir ici la différence entre la connexion native et la connexion à l’api. Comme l’API se limite à 50K de mots-clés par jour, vous vous privez de toutes les données qui ont été générés au-delà des 50K donc des mots-clés longues traines qui vont être très stratégiques pour un e-commerce par exemple.
Donc, comment répondre aux problématiques d’échantillonnage et d’historisation des données ?
Voici un tableau récapitulatif de la manière qu’a chaque solution de répondre aux problématiques d’échantillonnage et d’historisation des données.
De notre côté nous vous conseillons si vous en avez la possibilité de faire la connexion native le plus rapidement possible. Cela permettra de palier son principal défaut qui est de ne pas aller piocher dans le passé. Plus tôt vous ferez la connexion, plus tôt vous pourrez vous débarrasser de cette contrainte.
La solution de l’API est adaptée pour les petits sites qui ne seront pas impactés par la limite de 50K de mots-clés par jour. Car indépendamment de ça elle permet d’aller piocher dans les 16 derniers mois.
Elle peut aussi servir de solution de repli pour les sites qui n’ont pas d’accès GCP, mais dans ce cas, nous vous recommandons de passer par la solution de base si vous êtes impactez par limite des 50k car elle peut vous priver de beaucoup de données en fonction de votre couverture sémantique.
Adama Tandia