Analyse de logs SEO : les journaux que votre hébergeur ne garde pas

Prenons un cas type. Depuis dix jours, le trafic organique d’une boutique en ligne décroche, sans mise à jour annoncée ni erreur visible. L’agence SEO demande trois semaines de journaux serveur pour voir ce que Googlebot a exploré avant la chute. L’hébergeur WordPress infogéré n’en garde que quatre jours.

Ce chiffre n’a rien d’une hypothèse : c’est la durée que Kinsta documente pour son offre. Une analyse de logs SEO suppose d’abord des logs. Ils existent presque partout, mais ni assez longtemps ni sous le contrôle du client. L’hébergeur les efface à son rythme, le compte qui y donne accès est souvent au nom de l’agence, et personne n’a écrit ce qu’il fallait garder.

D’où une règle, plus contractuelle que technique : les journaux serveur se spécifient au contrat, avant d’en avoir besoin. Ce qui n’a pas été écrit le jour de la signature a déjà disparu le jour de la crise.

Analyse de logs SEO : ce que la Search Console ne remplace pas

Un journal d’accès consigne une ligne par requête reçue : l’adresse IP, la date, l’URL demandée, le code de réponse, la taille, le référent et le user-agent, c’est-à-dire le nom que le visiteur déclare. Robot ou internaute, chaque passage y laisse la même trace brute.

Google propose un équivalent partiel, le rapport Statistiques d’exploration de la Search Console. Son aide en fixe elle-même les limites. Le rapport vise les sites de plus de mille pages, ne s’ouvre que sur les propriétés de niveau racine et ne décrit que les robots de Google. Google prévient que certaines requêtes peuvent ne pas être comptées, et les exemples d’URL affichés ne sont pas exhaustifs. L’état de l’hôte, lui, ne remonte que sur 90 jours.

L’écart joue aussi dans l’autre sens. Une requête arrêtée avant le serveur n’apparaît dans aucun journal, et quand le fichier robots.txt est indisponible, les totaux du rapport dépassent ceux des traces d’accès. Aucune des deux sources ne dit tout. Confrontées, elles se contrôlent.

Google renvoie lui-même aux journaux dans au moins quatre situations.

• Un serveur qui ralentit : dans son billet « Inside Googlebot », Google explique que ses robots lèvent le pied quand les réponses tardent.
• Des pics de visites vers des pages de spam que des tiers ont créées sur le site.
• Des paramètres suspects dans les URL demandées, avec des fichiers de journaux à protéger de toute altération, selon sa page sur les logiciels malveillants.
• Un robot qui surcharge le serveur, dont il faut établir l’identité avant de le freiner.

Ces traces ne concurrencent pas les données de performance. Pour les clics et les impressions, mieux vaut archiver les seize mois de données de la Search Console. Pour savoir ce que les robots ont réellement demandé, seuls les journaux gardent la requête elle-même. Ils servent aussi à confronter le passage réel de Googlebot sur vos pages avec les délais d’exploration présentés par Google.

Qui produit les journaux quand tout est externalisé

Sur un site externalisé, trois couches peuvent répondre à une même requête. Le réseau de diffusion de contenu, ou CDN, sert les pages depuis ses propres serveurs, au plus près du visiteur. Le serveur d’origine, chez l’hébergeur, fabrique celles que le CDN n’a pas en cache. Une plateforme SaaS, elle, cumule les deux rôles sans rien montrer.

WP Engine documente clairement cette séparation. Son espace client distingue un journal d’origine, limité aux 1 500 dernières requêtes, et un journal de périphérie, qui remonte jusqu’à 20 millions de requêtes sur 72 heures. Une page servie depuis le cache n’atteint jamais l’origine.

Le journal qui fait foi est donc celui de la couche qui a répondu. Un prestataire qui n’analyse que l’origine peut voir un site presque désert, alors que Googlebot le parcourt chaque jour en périphérie.

Reste la question du titulaire. Quand l’hébergement a été souscrit par l’agence sur un compte revendeur, le client ne peut rien demander directement à l’hébergeur, pas même un extrait de journal. Avant toute discussion technique, il faut donc vérifier qui est titulaire du compte d’hébergement.

Trois couches, trois interlocuteurs, trois durées de conservation. Aucune n’est fixée au nom du client, sauf s’il l’a exigé.

Journaux serveur disponibles selon le type d’hébergement

Le tableau suivant rassemble ce que décrivent les documentations officielles, offre par offre. Une règle de lecture d’abord : une durée documentée n’est pas une garantie contractuelle. L’hébergeur peut la modifier sans préavis ; seul le contrat engage.

Journaux serveur disponibles selon le type d’hébergement, septembre 2026

Documentations officielles consultées le 15 septembre 2026. Colonne « À prévoir » : interprétation ExternFlow. Les marques sont citées comme exemples documentés, pas comme une sélection.

Sur les trois offres WordPress infogérées documentées, la fenêtre va de 72 heures à 30 jours. Chez Cloudflare, un journal brut conservé suppose en pratique l’offre Enterprise. Sur une boutique Shopify standard, le rapport Statistiques d’exploration reste le seul substitut. ExternFlow ne recommande aucun hébergeur : ces durées valent pour une offre et une date, pas pour tout un marché.

Plateformes SaaS : le journal brut reste chez l’éditeur

La documentation de Shopify ne décrit aucun journal HTTP pour une boutique standard. Le journal d’activité de l’administration existe bien, mais il liste des actions effectuées par les utilisateurs du compte, dans la limite de 250 résultats et sans export possible.

Les drains de journaux ne concernent que les vitrines Hydrogen hébergées sur Oxygen, pour les marchands Shopify Plus. Ils envoient les événements vers Datadog, New Relic, Splunk ou une adresse HTTP, avec des champs de requête sans adresse IP. Si la destination échoue, le message est perdu. Sur ces traces, impossible de vérifier Googlebot par son adresse.

CDN : les requêtes que votre serveur ne voit jamais

Côté CDN, tout dépend de l’offre souscrite. Chez Cloudflare, pris ici comme exemple documenté, quatre dispositifs coexistent. Instant Logs affiche un flux en direct, pour les offres Business et Enterprise. Logpush expédie les journaux vers un stockage choisi, en Enterprise uniquement, dans la limite de quatre tâches par zone, et ne rattrape rien si l’envoi échoue.

Logpull, fonction plus ancienne réservée elle aussi à l’Enterprise, garde les requêtes de 3 à 7 jours, à condition d’avoir activé une rétention désactivée par défaut. Log Explorer stocke jusqu’à deux ans, à 0,10 dollar par gigaoctet et par mois, pour les clients sous contrat.

La décision suit la titularité : qui détient le compte CDN détient les journaux de périphérie. Le raisonnement est le même que pour la décision de bloquer les robots d’IA prise chez l’hébergeur ou le CDN, appliqué ici à la conservation.

Les champs à garder pour vérifier Googlebot et diagnostiquer

Une ligne de journal utile au référencement tient en sept champs, quelle que soit la couche qui la produit.

• Horodatage avec fuseau : en UTC de préférence, pour rapprocher les journaux du CDN et ceux de l’origine.
• Hôte, méthode et URL avec paramètres : c’est dans les paramètres que se logent les doublons et les requêtes suspectes.
• Code de réponse et taille : une réponse 200 de quelques octets signale souvent une page vide.
• Temps de réponse : absent du format par défaut, il se demande explicitement.
• User-agent et référent : le nom que le visiteur déclare et la page d’où il vient.
• Adresse IP : seule preuve de l’identité d’un robot, et donnée personnelle à encadrer.
• Statut de cache du CDN : il indique si la requête a atteint l’origine.

Le format combiné, utilisé par défaut par Apache et Nginx, contient l’adresse IP, l’horodatage, la requête, le code, la taille, le référent et le user-agent. Il ne consigne ni le temps de réponse ni, sur un serveur qui héberge plusieurs sites, le nom d’hôte.

Une limite est souvent oubliée : le user-agent se déclare, il ne se prouve pas. N’importe quel script peut se présenter comme Googlebot. Le nom d’agent suffit pour comprendre ce que les robots d’IA lisent réellement sur une page ; il ne suffit pas pour attribuer une visite.

Vérifier un robot avant d’effacer son adresse IP

Google décrit deux méthodes. La première passe par le DNS. Une recherche inverse sur l’adresse doit renvoyer un nom en googlebot.com, google.com ou googleusercontent.com ; une recherche directe sur ce nom doit ensuite retrouver la même adresse IP. La seconde rapproche l’adresse des plages que Google publie en fichiers JSON.

Ces fichiers ont changé d’adresse. La documentation renvoie vers /crawling/ipranges/ depuis le 11 février 2026, et le billet du 31 mars 2026 annonce l’abandon de l’ancien chemin, redirigé « within 6 months ». Aucune date exacte n’est donnée : d’ici fin septembre 2026 environ.

Le relevé ExternFlow du 15 septembre 2026 montre une transition en cours. googlebot.json redirige déjà vers common-crawlers.json, trois autres anciens fichiers sont redirigés à leur tour, et seul user-triggered-agents.json est encore servi à l’ancienne adresse. Un script qui interroge l’ancien chemin dépend d’une redirection que Google n’a pas promis de maintenir. Faites vérifier ceux de votre prestataire.

Google cite aussi Web Bot Auth, un protocole expérimental de signature des requêtes, qui ne remplace pas la vérification par adresse IP. OpenAI publie de son côté les plages de ses robots. L’ordre des opérations en découle : vérifier les robots à l’ingestion, avant toute pseudonymisation.

Le temps de réponse, absent du format par défaut

Google écrit que ses robots ralentissent l’exploration quand le serveur peine à répondre. Or le format combiné ne consigne pas la durée de traitement. Il faut l’ajouter : %D sous Apache, qui l’exprime en microsecondes, $request_time sous Nginx, en secondes.

Sans ce champ, le lien entre une lenteur et une baisse d’exploration reste une hypothèse. Avec lui, il se démontre, à condition de l’avoir demandé avant l’incident.

Adresse IP et pseudonymisation : conserver sans tout garder

Ce qui suit décrit un cadre général, pas un conseil adapté à votre situation. En droit français, l’adresse IP est une donnée personnelle. La CNIL le rappelle, et la première chambre civile de la Cour de cassation l’a jugé le 3 novembre 2016 (n° 15-22.595). Un journal serveur relève donc du RGPD.

Deux articles du règlement s’appliquent directement. L’article 5, paragraphe 1, point e, limite la durée pendant laquelle les données permettent d’identifier une personne à ce qu’exigent les finalités. L’article 4, point 5, définit la pseudonymisation : des données qu’on ne peut plus attribuer à une personne sans une information supplémentaire, conservée à part.

Les lignes directrices 01/2025 du CEPD, version soumise à consultation en janvier 2025, précisent le point décisif : une donnée pseudonymisée reste personnelle pour qui détient l’information supplémentaire. Tronquer ou hacher une adresse réduit le risque. Le journal ne sort pas du RGPD pour autant.

La méthode que propose ExternFlow tient en deux temps. À l’arrivée des journaux, chaque ligne qui se réclame d’un robot est vérifiée, puis marquée comme telle. Les adresses des visiteurs sont ensuite tronquées, ou hachées avec une clé secrète : une clé conservée par le client, jamais par le prestataire.

La clé n’a rien d’un détail. Une adresse IPv4 hachée sans clé se retrouve en testant ses quelque 4,3 milliards de valeurs possibles, ce qu’un ordinateur de bureau accomplit vite. Le choix entre troncature et hachage revient au délégué à la protection des données, le DPO, qui valide aussi les durées.

Combien de temps conserver les logs serveur

Aucun texte ne fixe de durée pour des journaux exploités à des fins de référencement. Le repère le plus proche vient de la CNIL. Sa recommandation du 14 octobre 2021 (délibération n° 2021-122) conseille de garder de six mois à un an les traces d’accès des utilisateurs habilités d’un système d’information. Elle vise la sécurité, pas le SEO : une analogie, jamais une règle.

Le décret n° 2021-1362 du 20 octobre 2021 ne change rien à l’affaire. Il impose aux hébergeurs de conserver les données d’identification des auteurs de contenus, sans créer ni durée ni accès au profit de l’éditeur du site.

Faute de norme, ExternFlow propose une grille, à faire valider par le DPO.

• Journaux bruts, adresses IP comprises : environ 30 jours, le temps de vérifier les robots et de traiter un incident récent.
• Lignes pseudonymisées : 13 mois glissants, pour comparer une même saison d’une année sur l’autre ou l’avant-après d’une migration.
• Agrégats par robot, par code ou par répertoire : la durée du besoin, puisqu’ils ne contiennent plus d’adresse.

Mesurée à ces paliers, la réalité documentée paraît courte : quatre jours chez Kinsta, 72 heures en périphérie chez WP Engine, 30 jours chez WordPress.com. Ce qui doit durer plus longtemps s’exporte vers un stockage du client, ou disparaît.

Donner accès aux logs sans ouvrir l’espace client

Trois modèles coexistent, et le premier est à proscrire. Le plus répandu consiste à transmettre au prestataire les identifiants de l’espace client. Ils ouvrent les journaux, mais aussi la facturation, la zone DNS et parfois la résiliation.

Le deuxième modèle délègue un accès limité aux seuls journaux. OVHcloud permet de créer un utilisateur de statistiques qui consulte les traces sans entrer dans l’espace client ; Cloudflare attribue la permission Logs Read à un compte nominatif. Le troisième exporte les journaux vers un stockage ouvert au nom du client, où le prestataire dispose d’une lecture seule sur un stockage du client. C’est le seul qui survit à un changement de prestataire.

Le cadre juridique suit. Le prestataire qui traite des adresses IP pour le compte du client agit en principe comme sous-traitant au sens de l’article 28 du RGPD. Un contrat doit donc encadrer ses traitements. S’il utilise un outil hébergé hors de l’Union européenne, la question des transferts se pose en plus.

Un arbitrage documenté montre la tension. Chez Cloudflare, Logpull devient indisponible quand le client limite ses métadonnées à l’Union européenne. Protéger la localisation des données peut donc fermer un accès aux journaux : mieux vaut le savoir avant de choisir.

La spécification de conservation à annexer au contrat

La spécification ci-dessous est une interprétation ExternFlow. Elle s’annexe au contrat de chaque couche concernée, hébergement, CDN ou prestation SEO, et ses durées restent à valider par le DPO.

Spécification de conservation des journaux serveur, à annexer au contrat

Interprétation ExternFlow. Durées à valider par le DPO ; références juridiques et techniques sourcées dans l’article.

Trois contrôles de recette la rendent vérifiable. À la signature, la couche concernée remet un extrait de 24 heures dans le format convenu. Sur cet extrait, le prestataire SEO démontre une vérification de Googlebot qui aboutit. Trente jours plus tard, le client constate la date de purge des adresses brutes.

La rubrique « Fin de contrat » ne règle pas à elle seule le départ d’un prestataire. Elle se lit avec la clause de réversibilité et le plan de sortie du prestataire, qui organisent le reste de la restitution.

Exiger ses journaux au contrat plutôt qu’au lendemain d’une crise

Des journaux spécifiés coûtent peu : quelques lignes de configuration, un espace de stockage, une annexe. Des journaux effacés ne se reconstituent jamais, et aucune agence n’explique une chute de trafic avec des données qui n’existent plus. Annexez la spécification de conservation au prochain renouvellement de votre contrat d’hébergement, de CDN ou de prestation SEO.

D’ici là, demandez par écrit, cette semaine, à votre hébergeur, à votre CDN et à votre prestataire SEO la liste des journaux qu’ils produisent, leur durée de conservation et le titulaire du compte qui y donne accès. Leurs réponses diront par où commencer. La newsletter d’ExternFlow suivra la fin de la transition des plages IP de Google.

Sources et références

Cet article s’appuie notamment sur le billet de Google New Location for the Google Crawlers’ IP Range Files, publié le 31 mars 2026, sur la page Verify requests from Google crawlers and fetchers et sur l’aide Search Console consacrée au rapport Statistiques d’exploration. Le cadre juridique repose sur la recommandation de la CNIL relative aux mesures de journalisation, l’arrêt de la première chambre civile de la Cour de cassation du 3 novembre 2016 et les lignes directrices 01/2025 du CEPD sur la pseudonymisation. Les offres décrites viennent de la documentation Cloudflare Logs, de la documentation Shopify sur les drains de journaux d’Hydrogen et du guide OVHcloud sur les statistiques et les journaux d’un hébergement web.

Les situations où Google renvoie aux journaux proviennent de son billet Inside Googlebot, de son aide sur le spam créé par des tiers et de sa page sur la prévention des logiciels malveillants. Les durées des hébergements infogérés et mutualisés sont tirées de la documentation de Kinsta sur les journaux serveur, de l’aide de WP Engine sur ses journaux d’accès et d’erreur, de l’aide de WordPress.com sur la surveillance du site et de la documentation cPanel sur Raw Access.