Logs, crawl et API de visibilité : prioriser les actions SEO utiles

Pourquoi le comportement des robots ne suffit pas

Une page peut recevoir régulièrement Googlebot sans obtenir d’impressions. Une autre peut garder ses positions malgré une baisse de sa fréquence de crawl. Chaque source décrit une partie de la situation : l’exploration dans les logs, une représentation technique du site dans le crawl et l’exposition dans les résultats de recherche dans les outils de visibilité. Ces sources ne sont pas interchangeables.

Croiser ces sources aide à choisir l’action SEO. Une catégorie indexable, peu profonde et souvent explorée, mais invisible sur ses requêtes cibles, demande un diagnostic différent d’une catégorie pertinente que les liens internes ne permettent pas de découvrir. Augmenter indistinctement le crawl ne résout pas ces deux situations.

Travailler par URL, pour un marché et une période définis, puis agréger les constats par segment métier : catégories, produits, facettes (faceted navigation), marques ou contenus. Pour passer des erreurs techniques aux actions à prioriser, tenir compte de la demande, de la disponibilité et de la marge.

Avant toute extraction, préciser ce que l’analyse doit établir : les pages qui méritent davantage de maillage interne (internal linking), les facettes qui répondent à une demande non servie ou les endroits où un problème de fraîcheur menace la visibilité acquise. Ce cadrage relève de la stratégie SEO et précède le choix des connecteurs.

Connaître les API et leurs angles morts

Search Console pour la performance observée

La Search Console API expose, via Search Analytics, des données de clics, impressions, CTR et position, avec des dimensions telles que page, requête, pays, appareil et date. Les regroupements et filtres changent le périmètre retourné. La méthode ne garantit pas de restituer toutes les lignes. Prévoir cette limite dans le modèle de données. Voir la référence Search Analytics.

Extraire séparément les totaux par page et le détail par requête. Les sommes du détail peuvent différer des totaux, notamment à cause des limites de restitution et des requêtes anonymisées. Une absence de ligne n’est donc pas automatiquement un zéro. Conserver extraction_complete, data_state et la fenêtre demandée avec chaque lot.

L’API URL Inspection apporte un diagnostic de la version connue de Google, avec les informations d’indexation disponibles. Elle ne lance pas un test en direct ni une demande générale d’indexation. La référence URL Inspection décrit ses possibilités. Réserver les inspections à des échantillons ciblés et aux anomalies prioritaires.

Sistrix et SEMrush pour le marché de recherche

La Sistrix API donne accès à l’indice de visibilité (visibility index), aux mots-clés et aux informations concurrentielles selon les méthodes disponibles. domain.visibilityindex et les méthodes de mots-clés servent à replacer les pages dans leur marché. L’indice mesure une visibilité selon la méthodologie du fournisseur, pas les visites observées sur le site. Les fonctions et crédits sont documentés dans la référence Sistrix API.

La SEMrush API fournit des rapports de positions, mots-clés, volumes et concurrence, ainsi que des données de backlinks selon le produit et l’accès souscrit. Distinguer les bases de recherche, les projets de suivi et les autres familles d’API. Les unités et périmètres dépendent du rapport ; la documentation officielle de l’API décrit cette organisation.

Chaque fournisseur observe son propre ensemble de requêtes à ses propres dates de mesure. Leurs volumes et indices ne sont donc pas directement comparables. Les utiliser pour élargir l’analyse aux concurrents et à la demande non encore captée, tout en conservant provider, database, country, device et snapshot_date.

Bing Webmaster peut compléter l’analyse lorsque ce moteur pèse dans le trafic visé. Garder ses données dans un périmètre distinct : calculer une moyenne commune entre moteurs brouillerait le diagnostic, car leurs systèmes de classement et leurs populations de recherche diffèrent.

Organiser extraction, coûts et stockage

Attribuer à chaque connecteur une identité de service ou une authentification adaptée, des droits minimaux et un responsable. Conserver les secrets dans un gestionnaire dédié et les exclure des journaux. Archiver les réponses brutes avec les paramètres d’appel, la date de collecte, l’état de pagination et la version du connecteur.

Planifier les extractions selon les quotas par méthode, projet, site ou compte. Search Console distingue notamment les limites de Search Analytics et celles d’URL Inspection. Consulter les valeurs dans les quotas officiels lors de la mise en service, puis fixer le budget de consommation : le plafond technique publié n’est pas une cible à atteindre.

Prévoir une file de tâches, limiter le débit et reprendre les appels avec un délai progressif en distinguant les erreurs temporaires des requêtes invalides. Les appels repris doivent être idempotents au niveau du stockage. Une extraction partiellement échouée ne doit pas remplacer un lot complet par des données incomplètes.

Pour les API payantes, estimer coût = somme(volume_facturable * tarif_unitaire_du_rapport), selon la convention du fournisseur. Compter les unités déjà consommées, fixer des plafonds et mettre en cache les résultats réutilisables. Interroger les mêmes historiques à chaque actualisation gaspille des crédits sans améliorer la décision.

BigQuery convient à une chaîne partagée et planifiée. DuckDB traite rapidement les fichiers Parquet pour un audit ou une chaîne plus légère. Séparer données brutes, tables nettoyées et tables métier. Chaque niveau doit pouvoir être reconstruit sans dépendre d’un fichier manuel dont les transformations sont inconnues.

Construire une table commune à l’URL et à la semaine

Fixer le grain avant les jointures

La table finale peut avoir pour clé url_key, week_start, market et device_scope. Le périmètre d’appareil doit être constant : si les logs ne permettent pas une ventilation comparable, garder une table principale tous appareils et des vues Search Console spécifiques. Ne pas déduire du user agent d’un robot une ventilation par appareil que les logs ne fournissent pas.

Agréger chaque source au grain cible avant de la joindre. Joindre directement plusieurs mots-clés, plusieurs visites et plusieurs liens entrants multiplie les lignes et gonfle les métriques. Conserver une table détaillée url_keyword_week séparée pour la cannibalisation de mots-clés (keyword cannibalization) et les analyses de requêtes.

Le CTR se recalcule par clics / impressions. Une position agrégée nécessite des observations compatibles et une pondération par les impressions, pas une moyenne simple des moyennes. Les positions d’un fournisseur externe sont des instantanés sur son échantillon ; elles restent distinctes des positions moyennes Search Console.

Aligner les dates et les identités

Adopter une semaine de référence et documenter les fuseaux. Les logs UTC peuvent être convertis avant agrégation pour correspondre aux frontières calendaires de la source de performance. Respecter aussi les délais de finalisation et réextraire une fenêtre récente pour intégrer les révisions.

Le crawl décrit le site au moment de son passage. Pour chaque semaine, retenir la dernière observation disponible avant la fin de semaine et stocker son âge. Si une page a changé depuis, ses attributs peuvent être périmés. Conserver l’historique des déploiements aide à expliquer ce décalage.

Lors de la normalisation, conserver les variantes brutes et ne supprimer que les différences dont l’équivalence a été vérifiée. Appliquer les mêmes règles dans tous les connecteurs pour l’hôte, le slash final, la casse du chemin, les paramètres et l’encodage. Maintenir une version du normaliseur et examiner les collisions avant toute fusion.

Search Console peut consolider la performance sur l’URL canonique, tandis que les logs montrent l’URL effectivement demandée. Garder une vue technique par URL demandée et une vue consolidée par entité canonique. Copier les impressions de la canonique sur tous ses doublons ferait apparaître une performance fictive sur chaque variante.

Analyser les écarts sans transformer une corrélation en diagnostic

Pages explorées sans impressions, et pages visibles peu explorées

Pour les pages souvent explorées sans impressions, vérifier la complétude des données, l’âge de publication, l’indexabilité, le canonical, la demande et le contenu. Une page récente ou saisonnière ne doit pas être fermée parce qu’elle manque de performance dans une fenêtre trop courte.

Une page qui reçoit des impressions mais peu de visites du robot peut poser un problème de fraîcheur si son offre change souvent. Pour le confirmer, comparer la date du dernier changement substantiel aux visites suivantes et effectuer quelques inspections ciblées. Une page stable et bien classée n’a pas besoin d’être explorée chaque jour pour rester utile.

Profondeur, maillage et cannibalisation

Comparer les positions par profondeur et nombre de liens entrants à type de page, marché et demande comparables. Contrôler ancienneté, contenu et liens externes lorsque les données le permettent. Les pages importantes reçoivent souvent davantage de liens : une association positive ne prouve pas l’effet causal du seul maillage.

Rechercher la cannibalisation à partir de query, url_key, week_start, country et device. Repérer plusieurs URL exposées sur une même intention, les alternances de page dominante et la dispersion des clics. Puis vérifier les résultats de recherche et la différence des contenus. Plusieurs pages classées sur une requête ne sont pas automatiquement en conflit.

Visibilité des segments et écarts concurrentiels

Pour un segment fortement visible mais peu exploré, examiner sa stabilité et sa fraîcheur. Utiliser un indice disponible au bon périmètre, ou construire un indicateur interne documenté sur un panel fixe de mots-clés. Ne pas additionner arbitrairement des indices de domaine pour inventer une visibilité de segment.

Pour analyser le gap concurrentiel, rapprocher les requêtes des concurrents de la taxonomie et de l’assortiment du site. Déterminer si l’écart vient d’une page adaptée manquante, d’une position insuffisante ou de l’absence d’une offre légitime. Les backlinks peuvent éclairer une différence d’autorité, sans réduire tout écart de classement à ce facteur.

Prioriser, agir dans la couche Edge et vérifier les effets

Un score opérationnel peut prendre la forme priorité = valeur_métier * opportunité * faisabilité, avec des dimensions normalisées. Évaluer la valeur métier à partir de la marge, de la disponibilité et du rôle stratégique. Pour l’opportunité, croiser une demande accessible avec un écart documenté. La faisabilité tient compte de l’effort, des dépendances et du délai : plus l’action est simple, plus sa valeur est élevée.

Définir chaque échelle et ses bornes. Une notation de un à cinq, par exemple, sert à classer les actions et ne fournit aucune estimation de revenus. Ajouter un indicateur de confiance séparé. Si un score élevé repose sur une extraction incomplète, vérifier les données avant de publier.

Exemple illustratif de décision

Dans cet exemple, une famille de listings reçoit des impressions sur des requêtes précises. L’assortiment est disponible, mais les liens entrants sont peu nombreux. Des concurrents possèdent des pages dédiées aux mêmes intentions. Les logs confirment une découverte lente après mise à jour, et le crawl montre que les filtres correspondants ne sont accessibles qu’au terme d’un parcours profond.

Sélectionner les facettes utiles, leur attribuer des URL stables et des titles précis, puis ajouter des liens depuis leurs catégories parentes. Une couche Edge SEO peut appliquer les règles d’ouverture et de maillage, puis actualiser les sitemaps. Pour les facettes sans intention distincte, vérifier leur visibilité existante avant d’appliquer une politique de fermeture spécifique.

Cet exemple ne rapporte aucun gain observé. Pour mesurer les effets, définir un groupe traité, un groupe témoin (control group) comparable et une date d’intervention. Contrôler immédiatement les réponses HTTP, les canonicals, les directives et les liens. Suivre ensuite la découverte, les impressions, les clics et la valeur commerciale en tenant compte des promotions et des changements d’offre.

Une baisse des requêtes vers des pages inutiles ne suffit pas à conclure. Le résultat attendu doit aussi apparaître sur les pages prioritaires ou sur la fiabilité technique. Relier chaque règle déployée à change_id, rule_version et affected_segment rend l’analyse après intervention reproductible.

Détecter les dérives (drift) et organiser la propriété des données

Distinguer dans les alertes hebdomadaires les problèmes de collecte des changements de comportement du site. Adapter la réponse à la cause de l’alerte : retard d’API, rupture de mapping ou baisse réelle des impressions. Avant de déclencher une alerte de performance, comparer des fenêtres équivalentes en tenant compte de la saisonnalité (seasonality) et imposer un volume minimal.

Par exemple, une alerte de dérive peut exiger une variation inhabituelle persistante sur deux semaines complètes. Son seuil doit être calibré sur la variabilité du segment. Pour éviter les notifications sans éléments vérifiables qui ajoutent du bruit, indiquer les URL concernées, les sources à jour, les changements récents et le responsable de l’investigation.

Définir qui est responsable des accès, des exports, des transformations et des définitions métier. Vérifier les droits de conservation et de réutilisation des données fournisseurs. Le référent SEO maintient la segmentation et l’équipe data les pipelines. Les responsables métier valident la valeur et les contraintes.

Une cadence possible consiste à collecter les logs chaque jour et à consolider les performances chaque semaine, avec des crawls dont la fréquence dépend de la vitesse de changement des gabarits. Documenter les quotas, la fraîcheur, la normalisation et les règles de score dans un dictionnaire partagé. Pour tirer parti de ce dispositif de data marketing, garder une trace des décisions afin que l’équipe puisse les revoir avec un accompagnement ciblé.

Questions fréquentes

Une absence de ligne Search Console signifie-t-elle zéro impression ?

Non. Elle peut provenir du périmètre, des limites de restitution ou d’une extraction incomplète. Conserver un état de couverture et vérifier les totaux par page avant de qualifier la performance.

Faut-il souscrire à Sistrix et SEMrush simultanément ?

Le besoin dépend des marchés, des rapports et de la couverture recherchée. Une seule source externe bien exploitée peut suffire. N’ajouter une seconde source que si elle apporte une information utile au diagnostic.

Peut-on fusionner directement les URL sur leur canonical ?

Une vue consolidée est utile, mais elle doit compléter la vue des URL réellement demandées. La fusion immédiate masque les doublons explorés et peut attribuer à tort la performance d’une canonique à ses variantes.

Le score de priorité mesure-t-il le gain attendu ?

Non. Il organise les actions selon des conventions documentées. Une prévision (forecasting) de gain exige un modèle et des hypothèses supplémentaires ; le score ne remplace ni l’expertise ni la mesure après déploiement.

À retenir

• Relier exploration, structure, visibilité et valeur métier au même périmètre.
• Distinguer absence de données, zéro observé et manque de couverture.
• Agréger chaque source avant les jointures pour éviter les doubles comptes.
• Conserver les URL demandées et les entités canoniques dans des vues distinctes.
• Qualifier les écarts avant de fermer une facette ou de modifier le maillage.
• Utiliser un score explicable avec un indicateur séparé de confiance.
• Mesurer les effets des règles déployées sur des semaines comparables.