Comment récupérer ses logs serveurs pour le SEO (Apache, Nginx, cPanel, CDN)

En bref, récupérer ses logs serveur dépend de l'hébergement : Raw Access Logs en mutualisé (cPanel/Plesk), accès SSH/FTP direct sur un VPS ou un dédié, activation d'un export sur le cloud (AWS S3, Google Cloud), et vigilance sur les CDN comme Cloudflare, où une partie du trafic des robots n'atteint jamais le serveur d'origine. Visez au moins 30 jours de logs et vérifiez le format (Combined Log Format) avant l'analyse. Comme les logs contiennent des adresses IP, données personnelles au sens du RGPD et de la Loi 25 : privilégiez un traitement local plutôt qu'un envoi vers un tiers.

Avant de pouvoir analyser vos logs serveurs pour en tirer des enseignements SEO, encore faut-il mettre la main dessus. C'est une étape que beaucoup de guides SEO passent sous silence, comme si les logs tombaient du ciel dans un joli fichier CSV. En réalité, la façon de récupérer ses logs change complètement selon le type d'hébergement, et c'est souvent là que les projets d'analyse de logs s'arrêtent avant même d'avoir commencé. Ce guide fait le tour de toutes les situations courantes : hébergement mutualisé, VPS, cloud, CDN, et les pièges à éviter en cours de route.

Pourquoi récupérer ses logs serveurs est essentiel en SEO

Un fichier de logs serveur, c'est la trace brute de chaque requête HTTP reçue par votre serveur : humains, robots, API, tout y passe. C'est cette exhaustivité qui en fait une source si précieuse pour le SEO, largement supérieure aux estimations et à l'échantillonnage de la Search Console. Mais un fichier de logs mal récupéré, tronqué, incomplet sur la période, ou amputé du champ user-agent fausse toute l'analyse qui suit. Autant partir sur de bonnes bases.

Trois questions à se poser avant de foncer :

• Où sont physiquement stockés mes logs ? Sur le serveur web, sur un CDN, ou dispersés sur plusieurs load balancers ?
• Sur quelle période dois-je les récupérer ? Un minimum de 30 jours est recommandé pour capter les cycles de crawl normaux.
• Ai-je le droit d'y accéder tel quel ? Les logs contiennent des adresses IP, donc des données personnelles au sens du RGPD / Loi 25, un point sur lequel on revient plus bas.

Hébergement mutualisé : cPanel, Plesk et autre

C'est le cas le plus fréquent pour les petits sites, et paradoxalement souvent le plus mal loti côté logs. Sur un hébergement mutualisé (OVH, o2switch, Hostinger, PlanetHoster...), les logs bruts ne sont généralement pas activés par défaut, pour des raisons d'espace disque partagé entre des centaines de clients sur la même machine.

Dans cPanel, la marche à suivre est en général : Metrics > Raw Access Logs (ou Historique des accès bruts). Deux options s'offrent à vous : télécharger l'archive du jour même, ou activer l'option « Archiver les logs » pour conserver un historique glissant plutôt qu'un simple fichier écrasé chaque nuit. Sans cette activation, vous ne récupérez souvent que les dernières 24 heures, ce qui est nettement insuffisant pour une analyse fiable. (Détail dans la documentation cPanel « Raw Access ».)

Dans Plesk, on trouve l'équivalent sous Sites web et domaines > Journaux, avec un système de rotation configurable directement dans l'interface (nombre de fichiers conservés, fréquence de rotation).

Chez certains hébergeurs mutualisés bas de gamme, les logs bruts ne sont tout simplement pas accessibles à l'utilisateur, seulement des statistiques agrégées type AWStats ou Webalizer : inutilisables pour une vraie analyse SEO, car elles ne descendent pas au niveau de la ligne de log individuelle. Dans ce cas, le seul recours est de contacter le support, ou d'envisager une migration vers un VPS.

VPS et serveurs dédiés : l'accès direct par SSH/FTP

Sur un VPS ou un serveur dédié, vous avez un accès total au système de fichiers, donc aux logs bruts. C'est la configuration la plus confortable pour l'analyse SEO.

Les emplacements standards :

• Apache : /var/log/apache2/access.log (Debian/Ubuntu) ou /var/log/httpd/access_log (CentOS/RHEL)
• Nginx : /var/log/nginx/access.log

Pour les récupérer, deux méthodes principales :

1. SFTP/FTP avec un client comme FileZilla ou Cyberduck, en se connectant directement au dossier de logs.
2. SSH avec scp ou rsync, plus adapté si vous voulez automatiser la récupération régulière :

rsync -avz user@monserveur.com:/var/log/nginx/access.log* ./logs-locaux/

Attention au système de rotation : la plupart des serveurs utilisent logrotate, qui archive et compresse les anciens logs sous forme access.log.1, access.log.2.gz, etc. Si vous ne récupérez que le fichier access.log courant, vous perdez tout l'historique déjà tourné. Pensez à inclure les archives .gz dans votre récupération , elles se décompressent facilement avec gunzip.

Environnements cloud et hébergement managé

Sur AWS, Google Cloud, Azure ou des plateformes managées comme WP Engine, Kinsta ou Vercel, la logique change encore : les logs ne sont souvent pas de simples fichiers sur disque, mais des flux à activer et à exporter via des services dédiés.

• AWS : les logs d'un ELB/ALB s'activent via l'option Access Logs dans la console, avec écriture directe dans un bucket S3. Pour CloudFront (souvent utilisé en frontal), même principe : activation des logs standards ou en temps réel vers S3 ou Kinesis. (documentation AWS)
• Google Cloud : Cloud Logging centralise les logs, exportables vers BigQuery ou Cloud Storage pour un traitement en masse.
• Hébergement managé WordPress (WP Engine, Kinsta) : les logs bruts sont rarement accessibles directement ; il faut généralement passer par leur tableau de bord dédié aux logs, ou faire une demande au support pour une extraction sur une période donnée.

Ces environnements cloud et managés demandent donc une étape d'activation en amont, les logs ne sont pas toujours conservés par défaut, faute d'avoir configuré l'export.

Le cas des CDN : vos logs ne sont peut-être pas où vous pensez

C'est le piège le plus fréquent en 2026 : si votre site passe par un CDN comme Cloudflare, Fastly ou Akamai, une bonne partie du trafic (notamment celui des robots) touche d'abord les serveurs du CDN, pas votre serveur d'origine. Analyser uniquement les logs de votre serveur revient alors à ignorer une partie du crawl.

Sur Cloudflare, il faut activer Logpush (plans payants) pour exporter les logs Edge en continu vers un stockage externe (S3, GCS...), ou utiliser Logs Explorer pour une consultation ponctuelle. Sur le plan gratuit, l'accès aux logs bruts est très limité : un point à vérifier avant de se lancer dans une analyse ambitieuse. (Détail dans la documentation Logpush de Cloudflare.)

Dans l'idéal, on combine les deux sources : les logs du CDN pour la vision complète du crawl en périphérie, et les logs du serveur d'origine pour ce qui n'a pas été mis en cache. C'est un sujet qu'on approfondit dans l'article sur l'identification de Googlebot dans vos logs, où la distinction entre trafic CDN et trafic origine devient cruciale pour ne pas se faire piéger par de faux positifs.

Format, volume et rétention : ce qu'il faut vérifier avant d'analyser

Une fois les fichiers en main, quelques vérifications s'imposent avant de passer à l'analyse proprement dite :

• Le format du log : Apache et Nginx utilisent par défaut le Combined Log Format, mais il peut avoir été personnalisé. Vérifiez que les champs essentiels sont présents : IP, timestamp, méthode, URL, code de statut, user-agent, referer. (Format défini dans la documentation des logs Apache.)
• La période couverte : idéalement 30 jours pleins pour lisser les variations de crawl. Un export d'une semaine seulement peut donner une image trompeuse, notamment pour les sites avec un crawl irrégulier.
• Le volume : un site avec plusieurs millions de pages peut générer des fichiers de plusieurs gigaoctets. C'est justement pour éviter d'avoir à uploader ce genre de volume sur un service tiers qu'un traitement en local dans le navigateur devient pertinent, un point détaillé dans l'article sur l'analyse de logs sans upload.

Une fois vos logs récupérés, inutile de les uploader sur un serveur tiers pour les exploiter.L'analyseur de logs de Crawl Lab traite vos fichiers .log ou .gz directement dans le navigateur, même sur plusieurs gigaoctets : vos IP et vos données de crawl ne quittent jamais votre machine. C'est le point d'entrée le plus rapide pour transformer ces fichiers bruts en KPI exploitables, sans configuration ni ligne de commande.

RGPD : les logs contiennent des données personnelles

Un fichier de logs brut contient des adresses IP, qui sont juridiquement des données à caractère personnel en Europe. Deux bonnes pratiques à connaître :

• Anonymiser les IP dès l'extraction si vous devez partager les fichiers ou les stocker durablement (en tronquant le dernier octet en IPv4, par exemple).
• Limiter la durée de conservation des logs bruts non anonymisés, en cohérence avec votre politique de rétention des données.

C'est aussi pour cette raison que les outils qui traitent les logs directement dans le navigateur, sans upload sur un serveur tiers, présentent un avantage concret : les IP ne quittent jamais votre machine. Cadre juridique : le règlement (UE) 2016/679 (considérant 30) côté européen, la Loi 25 (P-39.1) au Québec.

En résumé

Récupérer ses logs serveurs pour le SEO n'a rien d'universel : mutualisé, VPS, cloud ou CDN imposent chacun leur propre méthode, avec des pièges spécifiques, rotation non incluse, logs CDN oubliés, rétention trop courte. Une fois cette étape maîtrisée, direction le guide de lecture d'un fichier access.log pour comprendre ce que chaque ligne raconte, puis les KPI à suivre pour transformer ces données brutes en plan d'action SEO.

À lire aussi

• Analyse de log serveur pour le SEO : le guide complet (2026)
• Analyse de logs SEO : quels KPI suivre et comment les interpréter
• Erreurs 404 et 5xx vues par les crawlers : les repérer dans les logs SEO