Mappage liens→requêtes dans Search Console avec le rapport API

Ce que vous essayez de mesurer (et ce que vous ne mesurez pas)

Le mappage lien-vers-requête dans Search Console rassemble trois éléments dans une même vue : une page spécifique, les requêtes pour lesquelles cette page apparaît, et les pages référentes qui ont commencé à y faire un lien.

L'objectif n'est pas de prouver qu'un lien a causé une hausse de classement. Google n'étiquette pas les impressions ou les clics par « ceci s'est produit à cause du lien X », et les classements bougent pour bien d'autres raisons (modifications de contenu, maillage interne, saisonnalité, changements chez les concurrents, et mises à jour de Google). Le timing est aussi imprécis : un lien peut être publié aujourd'hui et découvert plusieurs jours ou semaines plus tard.

Un objectif pratique est plus simple : relier les nouvelles pages référentes aux changements d'impressions et de position moyenne pour l'URL exacte, par requête. Cela vous donne une histoire exploitable du type : « Cette page a gagné de nouveaux liens, puis la visibilité s'est améliorée pour ces requêtes. » C'est de la corrélation avec des garde-fous, pas une preuve judiciaire.

Ce que ce rapport peut vous dire

Utilisé avec précaution, un rapport API Google Search Console comme celui-ci peut répondre à quelques questions à forte valeur :

• Quelles requêtes pour une URL ont gagné ou perdu des impressions après l'apparition de nouvelles pages référentes.
• Si la tendance de la position moyenne de cette URL s'est améliorée, est restée stable, ou a baissé dans la même période.
• Quelles pages nouvellement liées coïncident avec les plus grands changements, pour savoir par où commencer l'examen.

Ce que ce rapport ne peut pas vous dire

Ce rapport ne peut pas de manière fiable :

• Attribuer le crédit à un seul lien ou calculer une « valeur de lien » exacte par requête.
• Séparer l'impact d'un lien d'autres travaux SEO sans contrôles supplémentaires.
• Garantir que Google a compté ou fait confiance à un lien simplement parce qu'il existe.

Exemple : votre page de tarification reçoit deux nouveaux liens depuis des articles de la branche. Sur les 14 jours suivants, les impressions augmentent pour « product pricing » et « enterprise pricing », tandis que « free trial pricing » reste stable. Cela ne prouve pas que les liens ont causé la hausse, mais montre que la page a commencé à apparaître plus souvent pour certaines recherches après l'arrivée de nouvelles pages référentes.

Si vous utilisez un service de placements comme SEOBoosty (seoboosty.com) pour diriger des backlinks premium vers une page spécifique, ce mappage sert aussi de contrôle de sensibilité. Il vous maintient concentré sur le fait que la visibilité des requêtes de cette URL a bougé, au lieu de vous fier aux moyennes du site qui peuvent masquer ce qui s'est passé.

Les données que vous allez combiner depuis Search Console

Vous aurez besoin de deux vues différentes depuis Search Console. L'une montre ce qui s'est passé dans la recherche (impressions, clics, position). L'autre montre quelles pages sur le web pointent vers vous.

1) Données de performance (ce qui a changé dans la recherche)

Cela provient du rapport Performance dans Search Console (via l'endpoint Search Analytics de l'API). C'est la façon la plus claire de mesurer des résultats comme les impressions et la position moyenne.

Récupérez des métriques comme clics, impressions, CTR et position moyenne, et regroupez-les par dimensions qui expliquent ce qui a bougé. Pour ce rapport, les dimensions les plus utiles sont page, requête et date. Le pays et l'appareil peuvent aider si vous avez des marchés mélangés ou de fortes différences mobile vs desktop.

Une règle pratique : incluez toujours page. Ajoutez requête lorsque vous voulez savoir quelles recherches ont changé, pas seulement si la page a changé.

2) Données de liens (ce qui a changé hors site)

Cela provient du rapport Links dans Search Console (via les endpoints links). C'est là que vous trouvez les pages référentes qui pointent vers votre site.

Pour le mappage lien-vers-requête, les champs qui vous intéressent sont :

• page cible (quelle URL de vos pages est pointée)
• page référente (la page externe spécifique qui fait le lien)
• site référent (le domaine, utile pour les regroupements)

Les données de liens ne vous disent pas quelle requête un lien a impactée. Elles disent seulement que le lien existe vers une page cible donnée. Toute « attribution » dans votre rapport se base sur le timing et l'URL affectée, pas sur une cause prouvée.

Pourquoi vous avez besoin de fenêtres « avant » et « après »

Les liens et les classements ne changent pas le même jour, et les données Search Console ne sont pas parfaitement en temps réel. Regarder une seule date crée du bruit.

Utilisez deux fenêtres temporelles égales pour les données de performance :

• une fenêtre « avant » pour établir une base
• une fenêtre « après » pour mesurer le changement

Puis alignez les nouvelles pages référentes sur la première date où vous les avez vues (ou la date la plus proche que vous pouvez assigner), et comparez la performance avant vs après.

Si vous ne retenez qu'un seul modèle mental : la Performance explique le mouvement ; les Liens suggèrent ce qui pourrait l'avoir déclenché. Les combiner par URL est tout l'intérêt.

Définir la portée, les fenêtres et les règles pour les « nouveaux liens »

Ce rapport ne fonctionne que si vous bloquez la portée avant de commencer. Si vous changez l'ensemble d'URLs ou les fenêtres temporelles en cours de route, les résultats fluctueront pour des raisons sans rapport avec les liens.

Commencez par l'ensemble d'URL ciblées et tenez-vous-y : une page importante, un dossier, ou un petit ensemble de gabarits (comme des pages produit). Plus l'ensemble est restreint, plus il est facile de relier les nouvelles pages référentes aux changements d'impressions et de position moyenne.

Ensuite, choisissez deux fenêtres temporelles égales. Pour beaucoup de sites, 28 jours contre les 28 jours suivants est une valeur par défaut qui lisse les variations quotidiennes.

Maintenant, définissez « nouveau ». Une règle simple : une page référente est « nouvelle » si elle n'avait aucun lien enregistré vers l'ensemble d'URLs cibles avant la fenêtre de comparaison, et au moins un lien enregistré pendant la fenêtre de comparaison. Si votre source de liens se met à jour lentement, ajoutez un petit tampon, par exemple en excluant les premiers jours de la fenêtre après pour la détection de « nouveau lien ».

Pour réduire le bruit, fixez des seuils minimaux avant de calculer les changements. Sinon, une impression aléatoire peut ressembler à un « saut de classement ». Par exemple :

• Inclure seulement les URLs cibles avec au moins X impressions dans les deux fenêtres (exemple : 100)
• Inclure seulement les requêtes avec au moins Y impressions dans les deux fenêtres (exemple : 10)
• Exiger au moins Z jours actifs avec des impressions par fenêtre (exemple : 10 jours)
• Ignorer les changements de position quand les impressions sont trop faibles pour être stables

Exemple : dans les 28 jours de base, votre page tarifaire obtient 1 200 impressions à une position moyenne de 11,2. Dans les 28 jours suivants, elle obtient 1 650 impressions à 9,8. Vos règles vous aident à considérer cela comme significatif, tout en ignorant les pages dont les impressions sont passées de 3 à 9.

Si vous suivez des placements d'un fournisseur (y compris des placements payants), traitez chaque page référente comme son propre événement « nouvelle page référente ». Cela vous permet de comparer les résultats entre sources sans regrouper plusieurs changements.

Concevoir un modèle de données simple pour le rapport

Gardez le modèle de données banal. Trois tables plus des règles partagées pour les URLs et les dates suffisent. Si les clés sont cohérentes, le rapport devient des jointures et comparaisons simples.

1) Table des URLs cibles (les pages qui vous intéressent)

C'est votre catalogue de pages. Elle évite les doublons quand la même page apparaît avec des paramètres, des majuscules mélangées ou des barres obliques finales.

Stockez :

• target_url_canonical : l'URL canonique sur laquelle vous reportez
• target_url_normalized : clé de jointure normalisée (voir règles ci-dessous)
• page_type : catégorie, produit, blog, docs, etc.
• notes : optionnel, par exemple « page à forte valeur » ou « récemment mise à jour »

2) Table des pages référentes (les nouveaux liens)

C'est l'entrée « ce qui a changé ». Chaque ligne est une page référente pointant vers une de vos URLs cibles.

Stockez :

• referring_url : page exacte qui vous lie
• referring_url_normalized : normalisée pour déduplication
• referring_domain : domaine extrait (pour regroupements)
• target_url_normalized : pour joindre à l'URL cible
• first_seen_date : première date où vous avez observé le lien (ou la date fournie par votre fournisseur)

Si une page référente pointe vers deux URLs cibles, conservez deux lignes. Le mapping doit rester explicite.

3) Table de performance (export Search Console)

Conservez les données de performance au niveau le plus bas utile pour pouvoir les agréger ensuite.

Stockez :

• date
• target_url_normalized
• query
• impressions
• clicks (optionnel mais utile)
• position (position moyenne depuis Search Console)

Évitez d'agréger trop tôt. Vous pouvez toujours sommer les impressions plus tard, mais vous ne pouvez pas récupérer le détail par requête une fois qu'il est écrasé.

Stratégie de clé de jointure (les règles qui maintiennent tout cohérent)

Choisissez des règles une fois et appliquez-les partout :

• URL normalisée : mettez en minuscules l'hôte, enlevez les fragments, et standardisez les barres obliques finales. Décidez comment gérer les paramètres (souvent : supprimer les paramètres de suivi, garder les paramètres significatifs).
• Extraction de domaine : stockez le domaine enregistrable ou au moins l'hôte pour pouvoir grouper proprement par domaine.
• Périodes de date : créez un champ date_bucket comme semaine (YYYY-WW) ou mois (YYYY-MM) pour rendre les comparaisons plus stables que des graphiques journaliers.

Avec ces trois tables et des clés cohérentes, votre rapport final est : nouvelles pages référentes (par date de première observation) jointes aux changements de performance (par URL, requête et bucket de date).

Étape par étape : récupérer les données via l'API Search Console

Commencez par les données de performance en lesquelles vous avez confiance, puis ajoutez les nouvelles pages référentes depuis une source séparée. L'API Search Console standard est conçue pour le reporting de performance, pas pour un export complet du rapport Links.

1) Accédez à la bonne propriété

Récupérez les données depuis la même propriété que celle utilisée par votre équipe dans Search Console (propriété Domaine vs propriété préfixe URL). Utiliser la mauvaise rendra les liens ou les classements comme « disparus » alors que vous regardez un jeu de données différent.

Avant d'exécuter quoi que ce soit, confirmez :

• que votre compte Google a la permission sur la propriété (Owner ou Full user)
• que l'API Search Console est activée dans le projet Google Cloud
• que vous pouvez lister le site via l'API (vérification rapide)

2) Récupérez la performance par page + requête (journalière si possible)

Utilisez la méthode query de Search Analytics. Choisissez une plage de dates, puis demandez des dimensions qui permettent de rattacher les changements à une URL et un terme de recherche.

Un point de départ pratique :

• Dimensions : date, page, query
• Métriques : clicks, impressions, position
• Filtres optionnels : pays/appareil si votre site varie beaucoup

L'ajout de dimensions augmente le nombre de lignes. Prévoyez la pagination avec startRow jusqu'à la fin.

Voici un corps de requête minimal (forme seulement) que vous pouvez réutiliser dans votre script :

{
  "startDate": "2026-01-01",
  "endDate": "2026-01-31",
  "dimensions": ["date", "page", "query"],
  "rowLimit": 25000,
  "startRow": 0
}

3) Obtenez les données des « nouvelles pages référentes » (ce qui est possible)

Le rapport Links de Search Console est utile dans l'interface, mais Google n'expose pas le même jeu de données « top linking pages -> target page » via l'API Search Console standard.

Si vous avez besoin des URLs des pages référentes, vous avez généralement deux options :

• Exporter le rapport Links depuis l'UI Search Console sur un calendrier et ingérer ce fichier.
• Utiliser une source de backlinks séparée et faire correspondre les pages référentes aux URLs cibles.

Dans les deux cas, conservez l'URL brute de la page référente, l'URL cible et une date de première observation (ou date d'export) afin de pouvoir classer plus tard ce qui est « nouveau ».

4) Stockez les réponses brutes avant transformation

Sauvegardez chaque réponse d'API (et les paramètres de requête qui l'ont produite) en fichiers JSON bruts ou en lignes dans une table raw. Les réexécutions deviennent plus simples lorsque vous ajustez les règles de correspondance, les fenêtres de date ou les filtres. Cela aide aussi quand quelqu'un demande pourquoi la position moyenne d'une URL a changé et que vous devez montrer ce que l'API a renvoyé.

Étape par étape : nettoyer, faire correspondre et calculer les changements

Ce rapport vit ou meurt selon la qualité des correspondances d'URL entre jeux de données. Si les URLs ne se joignent pas proprement, « l'impact » devient aléatoire.

1) Normalisez les URLs pour que les lignes se joignent réellement

Choisissez une forme canonique pour chaque URL cible, puis appliquez les mêmes règles partout (pages Search Console, liste de backlinks, et sortie). Les corrections communes :

• Utiliser un seul protocole et style d'hôte (par exemple, toujours https et votre hôte préféré).
• Standardiser les barres obliques finales pour que /page et /page/ ne se divisent pas.
• Supprimer les paramètres de suivi (utm_*, gclid, fbclid) et garder seulement les paramètres qui changent le contenu.
• Gérer les duplicatas évidents comme index.html.

Après normalisation, créez une clé stable (normalized_url) et joignez votre table de pages référentes aux données de performance Search Console sur cette clé.

2) Faire correspondre les requêtes sans en faire un projet de taxonomie

Le regroupement des requêtes devrait répondre à une question : la visibilité a-t-elle surtout augmenté pour la demande de marque, la découverte non-marque, ou les deux ?

Restez léger. Deux étiquettes par requête suffisent généralement : marque vs non-marque, plus un simple seau d'intention (informationnelle, commerciale, navigationnelle). Utilisez des règles courtes et éditables. Par exemple, marque = « la requête contient le nom de la marque ou du produit », navigationnel inclut « login » ou « pricing », et tout le reste est informationnel ou commercial selon une petite liste de mots-clés.

3) Calculer les deltas et aligner sur la « première observation »

Pour chaque page référente, stockez link_first_seen comme la date la plus ancienne où vous l'avez observée pointant vers l'URL cible. Puis alignez cette date sur vos fenêtres.

Une règle simple :

• before_window = 28 jours se terminant la veille de link_first_seen
• after_window = 28 jours commençant le jour de link_first_seen

Calculez les changements au niveau (target URL, groupe de requête), puis agrégez au niveau URL. Gardez des métriques lisibles :

• Delta impressions = impressions_after - impressions_before
• Delta position = avg_position_after - avg_position_before (négatif = mieux)
• Score de visibilité = impressions * (1 / avg_position) ou un autre poids simple que vous utilisez de façon cohérente
• Part de contribution = delta URL divisé par delta sitewide pour la même période

Exemple : un article de blog obtient un nouveau referrer observé le 10 mai. Dans les 28 jours avant, il a eu 1 000 impressions à la position 14. Dans les 28 jours après, il a 1 450 impressions à la position 11. Votre rapport affiche +450 impressions et -3 positions, et vous pouvez voir si le gain provient de requêtes informationnelles non-marques ou d'une hausse de marque.

Si vous suivez des placements d'un fournisseur comme SEOBoosty, stockez aussi le même champ link_first_seen pour ces placements afin que vos fenêtres restent comparables entre sources.

Construire les vues de rapport que les gens lisent réellement

Un bon rapport lien-vers-requête n'est pas un tableur avec des dizaines d'onglets. C'est un petit ensemble de vues qui répondent rapidement à une question : « Qu'est-ce qui a changé après que cette page a obtenu de nouveaux liens, et pouvons-nous faire confiance au signal ? »

Vue 1 : synthèse d'impact par URL (la vue d'ouverture)

Commencez par une ligne par URL cible. Restez lisible, et rendez les « nouvelles pages référentes » concrètes.

Incluez :

• URL cible
• Nombre de nouvelles pages référentes (dans la fenêtre de liens)
• Date de première observation (première date de réf. nouvelle)
• Delta d'impressions (avant vs après)
• Delta de position moyenne (avant vs après)

Ajoutez une cellule compacte « Nouvelles pages référentes » avec 2–3 exemples (domaine + date de première observation), la liste complète étant accessible via un drilldown ou un filtre. C'est là que les lecteurs vérifient rapidement si les liens semblent réels ou bruyants.

Vue 2 : impact par requête pour une URL (la vue « pourquoi »)

Quand quelqu'un clique sur une URL, montrez les requêtes qui ont bougé. Limitez aux principaux mouvements.

Un agencement pratique :

Triez par les plus fortes gains d'impressions d'abord, puis ajoutez un filtre pour les déclins. Gardez une colonne « Note » pour un contexte rapide comme « requête de marque » ou « fonctionnalité SERP apparue ».

Colonnes de contexte qui évitent de mauvaises décisions

Si vous ventilez par appareil, pays ou type de recherche, rendez-le évident dans l'UI pour que les lecteurs ne confondent pas pommes et poires. Un simple en-tête comme « Appareil : Mobile » suffit.

Ajoutez un champ de confiance manuel par URL : « Élevée » (hausse claire sur plusieurs requêtes), « Moyenne » (hausse mais surtout sur une requête), « Faible » (le timing chevauche une modification du site).

Un scénario réaliste (sans maths compliquées)

Concentrez-vous sur une URL pendant une semaine, puis comparez-la à une semaine similaire avant l'arrivée des liens.

Scénario

Vous publiez un article : /blog/on-page-checklist. La semaine du 6 au 12 mai, votre journal de source de liens montre trois nouvelles pages référentes pointant vers cette URL. Deux sont des articles pertinents et une est une liste de ressources générale.

Définissez deux fenêtres :

• Fenêtre avant : 29 avr. au 5 mai
• Fenêtre après : 6 mai au 12 mai

Récupérez les métriques au niveau requête pour cette URL dans Search Console pour les deux fenêtres et calculez les deltas.

À quoi peuvent ressembler les chiffres

Pour la requête « on page checklist », les impressions passent de 1 200 à 2 100 (+900), mais la position moyenne reste à peu près la même (8,4 à 8,3). Cela signifie généralement que vous êtes affiché plus souvent, mais que le classement n'a pas encore augmenté. Raisons communes : élargissement de l'éligibilité (plus de variantes longue traîne) ou hausse de la demande.

Pour la requête « on page seo steps », les impressions restent stables (300 à 310), mais la position s'améliore (14,2 à 10,8). Cela peut arriver quand la confiance s'améliore pour un ensemble restreint de recherches même si la demande n'a pas beaucoup changé.

L'essentiel est que votre rapport relie la date de première observation de chaque nouvelle page référente à la fenêtre de comparaison et garde les résultats séparés par URL (pas agrégés sur tout le site).

Comment résumer cela dans une mise à jour hebdomadaire

Restez bref et orienté décision :

• Ce qui a changé : 3 nouvelles pages référentes vers /blog/on-page-checklist (6 mai–12 mai)
• Ce qui a bougé : +900 impressions sur la requête principale ; amélioration de position sur une requête secondaire
• Ce que cela signifie probablement : la visibilité a d'abord augmenté ; les classements peuvent commencer à bouger pour des termes spécifiques
• À surveiller : refaire la même comparaison la semaine suivante pour voir si la position suit

Si vous utilisez des placements SEOBoosty, ce même format hebdo est un moyen propre de rapporter ce qui s'est passé après chaque lot sans prétendre que les liens ont causé chaque changement.

Pièges courants qui rendent le rapport trompeur

Ce rapport est utile, mais il est facile de se tromper. Le plus grand risque est de transformer une corrélation en histoire parce que le graphique est joli.

Piège 1 : « Le lien est apparu, les classements ont bougé, donc le lien en est la cause »

La concordance des dates n'est pas une preuve. Les données Search Console peuvent arriver en retard, les liens sont découverts lentement, et Google peut retraiter les signaux plus tard. Un lien peut être trouvé lundi, rapporté jeudi, et avoir un effet (s'il en a un) après cela.

Traitez le lien comme une explication candidate. Votre rapport doit montrer ce qui a changé, pas ce qui l'a causé.

Piège 2 : Fragmenter une page en plusieurs « URLs »

Si vous mélangez des variantes d'URL, vous fractionnez le signal et vos changements avant/après deviennent bruyants. Coupables courants : http vs https, www vs non-www, barre oblique finale, majuscules, paramètres, et pages canonisées.

Choisissez une règle de normalisation et tenez-vous-y. Sinon vous risquez d'attribuer une chute de position à des « nouvelles pages référentes » alors que la moitié de vos impressions se trouvent sur une URL avec paramètres.

Piège 3 : Fenêtres de comparaison inégales

Comparer 7 jours avant à 28 jours après (ou mélanger jours de semaine et week-ends) crée des faux gains et chutes. Beaucoup de sites ont de forts motifs jour-de-semaine.

Si vous devez utiliser des fenêtres courtes, gardez-les symétriques et alignées par jour de la semaine. Pour les sujets saisonniers, ajoutez des notes contextuelles (lancements, vacances, mentions RP) à côté des chiffres.

Piège 4 : Traiter la position moyenne comme une vérité absolue

La position moyenne peut changer simplement parce que le mix d'impressions a bougé. Si une page commence à apparaître pour une nouvelle requête en position 35 avec beaucoup d'impressions, la position moyenne se détériore même si votre requête principale s'est améliorée.

Vérifiez la distribution : les impressions ont-elles basculé vers des positions plus élevées ou plus faibles ? Une nouvelle requête a-t-elle dominé la période après ?

Piège 5 : Ignorer l'indexation et les changements on-page

Un rapport « impact lien » tombe à l'eau quand la page elle-même a changé. Réécritures de titre, maillage interne, mises à jour de gabarit, modifications de contenu et problèmes d'indexation peuvent tous faire bouger les impressions et la position.

Avant de créditer un backlink, confirmez que la page était stable et indexable.

Garde-fous qui rendent le rapport honnête :

• Utiliser des fenêtres de longueur égale (et aligner les jours de semaine) pour chaque comparaison.
• Normaliser les URLs et regrouper les variantes de requête quand c'est pertinent.
• Signaler les périodes avec mises à jour de contenu, redirections, ou avertissements d'indexation.
• Examiner les mouvements au niveau requête, pas seulement les moyennes de page.
• Traiter les « nouvelles pages référentes » comme un point de départ, puis vérifier avec d'autres signaux.

Vérifications rapides et étapes suivantes

Avant de faire confiance à un graphique, vérifiez rapidement les entrées. Le mappage lien-vers-requête peut sembler convaincant même quand les données d'URL, de lien ou de requête sont mal appariées.

Vérifications rapides (5 minutes)

• Confirmez que l'URL cible est cohérente : canonisée comme attendu, indexable, et pas bloquée par noindex, robots ou une mauvaise canonical.
• Validez que les « nouvelles pages référentes » sont réelles : la page existe, n'est pas derrière une connexion, et fait bien un lien vers votre page (pas seulement vers votre domaine).
• Assurez-vous que le lien pointe vers la bonne version d'URL : http vs https, www vs non-www, barre oblique finale, paramètres et redirections peuvent fragmenter le signal.
• Vérifiez la taille d'échantillon avant de faire confiance aux variations de position. Les faibles impressions rendent la position moyenne très instable.
• Balayez la même fenêtre pour d'autres changements : modifications de titre, mises à jour de gabarit, redirections, changements de maillage interne, lancements RP ou variations saisonnières.

Exemple : vous voyez une nouvelle page référente et la position moyenne d'une requête passe de 14 à 9. Si la page n'avait que 30 impressions avant et 40 après, ce bond peut être du bruit. Si elle avait 5 000 et 6 000 impressions, c'est plus vraisemblable.

Étapes suivantes qui gardent le rapport utile

La cohérence compte plus que des formules sophistiquées.

• Surveillez hebdomadairement en utilisant les mêmes fenêtres et règles.
• Ajoutez des annotations pour les pertes de liens et les changements majeurs du site.
• Identifiez les pages « haute confiance » : URL stable, fort volume d'impressions, et une nouvelle page référente claire qui pointe directement.
• Revérifiez après 2 à 4 semaines. Les liens et les classements ne bougent rarement de pair, et les données Search Console peuvent être retardées.

Si vous voulez des tests avant-après plus propres pour des URLs spécifiques, les placements contrôlés aident car vous pouvez enregistrer les cibles et les dates exactes. Par exemple, SEOBoosty (seoboosty.com) propose un accès par abonnement à des placements de backlinks sélectionnés, ce qui peut faciliter la comparaison des résultats entre événements de lien similaires.

Gardez les vérifications légères et régulières. Le rapport reste lisible et vous passez moins de temps à discuter des cas limites.