Lire les logs au bon endroit dans l’architecture
Une ligne de log d’accès correspond à une requête traitée par le composant qui l’enregistre. Elle ne prouve ni une indexation ni un classement. Le statut donne la réponse renvoyée ; le user agent, l’identité que le client déclare.
Le format combined d’Apache ou de Nginx comprend notamment adresse IP, horodatage, ligne de requête, statut, volume de réponse, referrer et user agent. Pour enregistrer le temps de réponse, il faut ajouter un champ. Les documentations des logs Apache et du module de journalisation Nginx décrivent les options de configuration.
Prévoir dans le schéma analytique timestamp, client_ip, host, method, path, query_string, status, bytes, user_agent, referrer, response_time_ms et request_id. Ajouter cache_status, origin_status et edge_location lorsque ces champs existent. Vérifier ce que chaque mesure représente : secondes ou millisecondes pour le temps, taille du corps ou taille totale pour le volume, début ou fin de requête pour l’horodatage.
| Source | Ce qu’elle permet d’observer | Limite principale |
|---|---|---|
| Logs CDN | Requêtes externes, cache et réponses en périphérie | Champs et exhaustivité dépendants du service |
| Logs WAF | Blocages et challenges de sécurité | Ne décrivent pas seuls les pages servies |
| Logs d’origine | Travail réellement transmis à la plateforme | Absence des réponses servies depuis le cache |
| Logs applicatifs | Règles métier et erreurs internes | Ne couvrent pas forcément chaque requête HTTP |
Lorsqu’un CDN répond depuis son cache, l’origine ne voit pas la requête. Pour analyser le crawl réel, privilégier les logs du point d’entrée public et conserver ceux de l’origine pour expliquer les lenteurs et les erreurs.
Une même requête peut figurer dans les deux sources. Les additionner la compterait deux fois ; un identifiant propagé aide à rapprocher les enregistrements.
Collecter à grande échelle et authentifier les robots
Construire une collecte contrôlable
Le log shipping envoie les événements ou fichiers vers un stockage central avec Fluent Bit, Vector ou les mécanismes natifs du fournisseur. Conserver les données brutes et parsées, puis les agrégats. Pour chaque lot, enregistrer la source, la fenêtre temporelle, le nombre de lignes et l’état de traitement.
Partitionner les données par date et hôte, puis les convertir en Parquet facilite les lectures sélectives. Dédupliquer avec les identifiants disponibles et une règle documentée. Surveiller les retards, fichiers vides, erreurs de parsing et changements de schéma. Une baisse de crawl pendant une panne de collecte est d’abord une anomalie de données.
Choisir la durée de rétention selon les questions de l’audit et les périodes à comparer. Conserver trois mois de logs détaillés et un historique plus long d’agrégats est une politique possible. Garder les adresses IP nécessaires à la vérification des robots dans un périmètre d’accès limité. Avant de transmettre les données aux analystes, supprimer les paramètres contenant des informations privées.
L’échantillonnage convient mal à la mesure des URL rarement explorées : il gonfle le nombre de pages « jamais vues ». Un redressement peut estimer certains volumes. Il ne reconstitue toutefois pas la liste exacte des URL absentes. Documenter tout échantillonnage natif du CDN et rechercher une collecte exhaustive des requêtes utiles.
Vérifier Googlebot au-delà du user agent
Le filtre sur Googlebot ne suffit pas : un client HTTP peut déclarer ce nom. Utiliser l’adresse IP d’origine fournie par une chaîne de proxies de confiance. Un en-tête transmis librement par le visiteur n’est pas une source fiable.
Pour vérifier l’identité par DNS :
- Résoudre l’IP en nom d’hôte par DNS inverse.
- Vérifier le domaine autorisé et sa frontière de suffixe.
- Résoudre ce nom en adresses IP par DNS direct.
- Confirmer la présence de l’adresse initiale parmi les résultats.
- Enregistrer verdict, catégorie de robot et date de vérification.
Un nom contenant « googlebot » n’est pas une preuve. La procédure officielle de vérification Google distingue les catégories de robots et propose aussi les plages IP publiées pour une vérification automatisée. Mettre en cache les résultats DNS et isoler les échecs temporaires des usurpations confirmées.
Distinguer Googlebot de recherche, AdsBot et les fetchers déclenchés par un utilisateur. Pour les autres moteurs inclus dans le périmètre, appliquer leurs propres procédures. Stocker les verdicts dans une table bot_identity pour les réutiliser sans relancer les vérifications à chaque ligne.
Mesurer le crawl sans confondre activité et efficacité
Compter les requêtes quotidiennes du robot vérifié en distinguant documents HTML, ressources, robots.txt et sitemaps. Compter aussi les URL distinctes : un grand volume de requêtes peut venir de visites répétées sur un petit ensemble de pages. Ventiler les résultats par hôte, répertoire, type de page et famille de paramètres.
La répartition des statuts fait apparaître les redirections, absences, limitations et erreurs serveur. Pour les interpréter, suivre la sémantique HTTP de la RFC 9110. Un statut 304 indique une validation conditionnelle, pas une redirection. Le code HTTP seul ne révèle pas une soft 404 : il faut examiner le contenu ou un diagnostic du moteur.
Définir les indicateurs opérationnels
crawl_hits: nombre de requêtes dans la fenêtre et le périmètre retenus.distinct_crawled_urls: nombre de clés URL distinctes explorées.crawl_days: nombre de jours avec au moins une visite par URL.last_crawl_at: dernier horodatage observé, sans extrapolation hors historique.crawl_coverage: URL éligibles explorées divisées par URL éligibles du segment.first_crawl_delay: premier crawl observé moins date de publication connue.waste_share: requêtes vers les classes jugées inutiles divisées par requêtes du périmètre.
Pour décrire la fréquence de crawl d’une URL, calculer la médiane et les quantiles des intervalles entre visites.
Sur une nouvelle page, la première apparition dans les logs n’est pas forcément le premier crawl absolu. Les pages jamais observées à la fin de la fenêtre sont censurées : les exclure du délai moyen rend le résultat artificiellement favorable.
Définir quelles catégories comptent comme du gaspillage : paramètres sans valeur, chaînes de redirection, erreurs répétées, pages non indexables et combinaisons vides. Calculer le pourcentage sur des classes exclusives ou préciser leurs chevauchements. Une page en noindex peut être nécessaire au parcours marchand ; sa visite n’est donc pas automatiquement une anomalie prioritaire.
Rapprocher ces métriques de la valeur métier des pages : marge potentielle, disponibilité, demande et importance stratégique. Tenir compte de la saisonnalité (seasonality). Une catégorie dormante ne demande pas la même fréquence de crawl qu’un listing dont l’offre change rapidement : il faut chercher les déséquilibres observables entre segments, sans fixer de fréquence universelle.
Réaliser un crawl complet et qualifié
Screaming Frog, Oncrawl, Botify ou un crawler spécifique explorent les liens et extraient les attributs techniques. Un crawl « complet » suppose de borner son périmètre : hôtes autorisés, règles de paramètres, pagination, langues, limites de profondeur et comportement JavaScript. Prolonger le crawl d’un espace de facettes (faceted navigation) infini ne suffit pas à en tirer un inventaire utile.
Commencer par un crawl de découverte depuis les points d’entrée publics. Importer ensuite séparément sitemaps, exports catalogue et URL présentes dans les logs. Une URL injectée en mode liste ne prouve pas qu’elle est accessible par le maillage interne (internal linking). Conserver discovery_source et reachable_from_seed pour distinguer les deux.
Le crawl collecte status, content_type, canonical, meta_robots, x_robots_tag, robots_allowed, depth, inlinks, outlinks, title, h1, template et page_type. Stocker les liens dans une table dédiée avec source, destination et attributs. La profondeur correspond au parcours choisi par le crawler, pas à une mesure absolue de Google.
Vérifier le rendu (rendering) et l’indexabilité
Comparer le HTML initial au rendu JavaScript sur les gabarits qui en dépendent. Le rendu peut ajouter un lien absent du HTML, et un script peut modifier le canonical. Archiver la configuration du crawler, ses cookies et son user agent : le résultat dépend aussi de ces réglages.
Pour évaluer l’indexabilité technique, examiner l’accessibilité, le statut, les directives et le canonical. Ces éléments ne prouvent pas la présence dans l’index. Distinguer une page dont le canonical pointe vers une autre URL d’une page en noindex. Vérifier aussi la cible du canonical : une erreur, une redirection, un blocage ou une incohérence de langue peuvent remettre en cause l’interprétation.
Segmenter par métier et gabarit, sans se limiter au répertoire : fiches produits, catégories, facettes et pages éditoriales peuvent partager une structure d’URL. Attribuer les types avec des règles ordonnées et versionnées. Surveiller la classe « inconnu », dont la hausse signale souvent une évolution du site que le modèle analytique ne prend pas encore en compte.
Normaliser les URL et joindre les observations
Construire une clé sans effacer les anomalies
Conserver raw_url, normalized_url, url_key et normalization_version. Fonder la normalisation sur les équivalences vérifiées du site. L’hôte et le chemin ne se traitent pas de la même façon : mettre l’hôte en minuscules ne justifie pas de le faire pour le chemin, dont certains serveurs distinguent la casse.
Ne pas retirer systématiquement le slash final, fusionner HTTP et HTTPS ou supprimer tous les paramètres. Ces variantes peuvent produire des réponses différentes, que l’audit doit mesurer. Avant de trier les paramètres, vérifier que leur ordre ne change pas le comportement, notamment lorsque des valeurs se répètent.
Traiter l’encodage avec un parseur d’URL : ne pas transformer aveuglément %2F en séparateur de chemin et ne pas décoder plusieurs fois. Retirer le fragment, absent de la requête HTTP standard. Les paramètres de suivi reconnus peuvent être regroupés dans une clé analytique secondaire, tout en conservant la variante effectivement demandée.
Utiliser comme clé la chaîne normalisée ou son empreinte. Avec une empreinte, conserver aussi la chaîne pour l’audit. Garder séparément canonical_url_key et les destinations de redirection : joindre les logs directement sur les canonicals masquerait les requêtes vers les doublons à corriger.
Interpréter la jointure et ses limites
Une jointure externe complète réunit les URL des logs et du crawl. Chercher les pages orphelines (orphan pages) parmi les URL présentes uniquement dans les logs. Elles peuvent aussi être anciennes, hors périmètre, bloquées au crawler ou accessibles par un rendu qui n’a pas été exécuté. Avant de conclure, confirmer leur statut dans l’inventaire et leur absence de liens.
Qualifier les URL présentes seulement dans le crawl de « non observées dans les logs sur la période ». Elles ne sont pas nécessairement inconnues du moteur. Comparer leur publication et leur disponibilité à la couverture temporelle de la collecte. Pour les pages en noindex présentes dans les deux sources, vérifier si l’activité observée correspond à la politique attendue.
Examiner aussi les pages profondes très explorées : elles peuvent recevoir des liens externes, appartenir à un ancien maillage ou être prioritaires pour le moteur. Pour distinguer une anomalie structurelle d’un comportement justifié, croiser la profondeur, les liens entrants internes, la fréquence et la valeur commerciale.
Industrialiser les requêtes et convertir les résultats en actions
DuckDB convient à l’analyse locale de fichiers Parquet ou à un traitement embarqué. BigQuery facilite le travail sur des volumes partagés, les requêtes planifiées et les accès d’équipe.
Dans les deux cas, partitionner les logs par date et limiter les colonnes lues pour éviter des coûts inutiles. Agréger avant de joindre évite les multiplications de lignes.
Cet exemple SQL suppose que la table de logs ne contient que les requêtes HTML de Googlebot vérifié sur une période complète. La table de crawl contient une ligne par URL pour l’instantané choisi :
sql
WITH visits AS (
SELECT url_key, COUNT(*) AS hits, MAX(timestamp) AS last_seen
FROM verified_html_logs
GROUP BY url_key
)
SELECT c.url_key, c.page_type, c.depth,
COALESCE(v.hits, 0) AS hits, v.last_seen
FROM crawl_snapshot AS c
LEFT JOIN visits AS v USING (url_key)
WHERE c.is_indexable = TRUE;
Cette requête décrit la couverture des pages indexables du crawl. Pour identifier les candidates orphelines, faire une seconde extraction par anti-jointure des logs vers l’ensemble de découverte. Vérifier l’unicité des clés et comparer les totaux avant et après la jointure. Sans condition temporelle, ne pas joindre toutes les visites à toutes les versions historiques d’une page.
Organiser les corrections par mécanisme
| Constat confirmé | Action | Indicateur de suivi |
|---|---|---|
| Facettes sans demande très explorées | Revoir génération de liens et politique de crawl | Part des requêtes vers ces combinaisons |
| Pages utiles sans accès structurel | Ajouter des liens depuis les parents les plus proches | Couverture et délai de découverte |
| Pagination rompue | Rétablir des liens accessibles et cohérents | Découverte des produits profonds |
| Chaînes de redirection fréquentes | Pointer les liens vers la destination finale | Requêtes sur les étapes intermédiaires |
| Absences définitives encore fortement liées | Corriger les liens et les sitemaps | Visites répétées vers les erreurs |
Une page supprimée sans équivalent doit conserver un statut d’absence adapté. La rediriger vers l’accueil pour retirer les 404 du tableau de bord dégrade le diagnostic. Adresser chaque correction au responsable concerné : l’exploitation pour une erreur serveur, l’architecture pour une page utile peu liée.
Afficher dans les tableaux de bord les volumes, la couverture, les statuts, la latence et le délai de découverte par segment. Avant de déclencher une alerte, contrôler la fraîcheur des données et comparer des jours équivalents. Par exemple, une chute sur plusieurs jours accompagnée d’une hausse des erreurs serveur appelle une investigation technique, avec la liste des URL et la fenêtre concernée.
Attribuer chaque action à un responsable et consigner sa date de déploiement. Prévoir un groupe témoin (control group) lorsque c’est possible. Les règles de facettes ou de statuts peuvent être appliquées via une couche Edge SEO, puis vérifiées dans les logs. Intégrer ce suivi au pilotage SEO et à une chaîne reproductible de traitement des données.
Questions fréquentes
Les logs d’origine suffisent-ils derrière un CDN ?
Non si le CDN sert des réponses depuis son cache. Les logs publics décrivent les requêtes externes ; ceux de l’origine servent à comprendre la charge et les traitements transmis à la plateforme.
Une URL absente du crawl est-elle forcément orpheline ?
Non. Elle peut relever d’un autre périmètre, d’un rendu JavaScript ou d’une ancienne version. Confirmer l’absence de liens entrants à l’aide d’un inventaire et d’un crawl correctement configurés.
Peut-on détecter les soft 404 dans les logs seuls ?
Un statut de succès ne révèle pas le sens du contenu. Il faut examiner la page ou un diagnostic du moteur pour identifier une page vide ou un message d’absence servi avec un statut inadapté.
Faut-il bloquer toutes les pages noindex dans robots.txt ?
Non. Le moteur doit pouvoir explorer la page pour lire son noindex. Prévoir la désindexation avant de réduire l’exploration.
À retenir
- Collecter au point d’entrée public et contrôler l’exhaustivité des fichiers.
- Authentifier les robots avant de calculer leurs métriques d’exploration.
- Séparer découverte par liens, imports d’URL et indexabilité technique.
- Normaliser les adresses sans fusionner les variantes à diagnostiquer.
- Interpréter toute absence dans les limites de la période observée.
- Prioriser les corrections selon la valeur des pages et leur mécanisme technique.
- Vérifier les effets après déploiement avec des données comparables.