Analyse de logs serveur :
Google Analytics ne voit que 43 % de mon trafic

Pourquoi Google Analytics ne peut pas voir tout votre trafic ?

Il faut comprendre une chose simple avant d’aller plus loin : Google Analytics ne mesure pas votre trafic, il mesure les visiteurs qui acceptent d’être mesurés. La nuance change tout. Le principe technique repose sur un script JavaScript déposé sur vos pages. Quand un internaute arrive, son navigateur télécharge ce script, l’exécute, puis envoie un signal aux serveurs de Google. Si l’une de ces trois étapes échoue, la visite n’existe pas.

Or elles échouent beaucoup plus souvent qu’on ne l’imagine. Un bloqueur de publicité empêche le script de se charger, purement et simplement. Un bandeau de consentement refusé coupe la mesure à la source, et c’est même le comportement légalement attendu en Europe. Un visiteur qui ferme l’onglet avant la fin du chargement disparaît lui aussi. Sur mon audience, composée en grande partie de professionnels du référencement et de profils techniques, le taux d’équipement en bloqueurs est particulièrement élevé.

Le serveur, à l’inverse, n’a pas ce problème. Chaque fois qu’un navigateur, un robot ou un script demande une ressource, le serveur web enregistre une ligne dans un fichier texte. Cette ligne contient l’adresse IP, la date, l’URL demandée, le code de réponse, la page d’où vient le visiteur, et l’identifiant du logiciel utilisé. Rien ne peut y échapper, puisque l’enregistrement se fait avant même que la page ne soit envoyée.

C’est cette différence de nature que j’ai voulu quantifier. Pas par curiosité théorique, mais parce que je pilote ma stratégie de contenu sur ces chiffres depuis des mois. Si je me trompe de moitié sur mon volume réel, je me trompe aussi sur ce qui fonctionne et sur ce qui ne fonctionne pas.

Comment j’ai récupéré mes logs sur un hébergement mutualisé ?

Je suis hébergé chez o2switch, sur une offre mutualisée classique avec cPanel. Beaucoup pensent que l’analyse de logs est réservée aux gros sites sur serveur dédié. C’est faux, et c’est même l’une des raisons pour lesquelles j’écris cet article : la donnée est déjà là, sur votre hébergement, et personne ne va la chercher.

Dans cPanel, l’outil s’appelle Accès brut. Il donne accès aux journaux Apache complets sous forme de fichiers compressés téléchargeables. Le format utilisé est le format combiné standard, qui contient tout ce dont j’ai besoin : adresse IP, horodatage, requête, code HTTP, référent et identifiant du navigateur.

Un piège majeur attend le débutant à cette étape, et je suis passé à deux doigts de perdre mon historique. Par défaut, l’hébergeur ne conserve que les journaux les plus récents et les supprime dès qu’ils ont été traités par les outils de statistiques internes. Il faut impérativement cocher la case d’archivage pour que les fichiers soient conservés dans votre répertoire personnel. Tant que ce n’est pas fait, vous perdez votre historique chaque nuit.

Deuxième piège, plus vicieux encore : le cache. Si vous utilisez un système de cache serveur avancé ou un réseau de diffusion de contenu placé devant votre site, une partie des pages est servie sans jamais atteindre Apache. Dans ce cas, vos journaux sous-comptent au lieu de sur-compter, et toute votre analyse part de travers. Vérifiez ce point avant de tirer la moindre conclusion.

Pourquoi il ne faut jamais confondre une ligne de log et un visiteur ?

C’est l’erreur numéro un, celle qui transforme une analyse rigoureuse en illusion flatteuse. Une ligne de journal n’est pas une personne, c’est une requête HTTP. Chaque page consultée génère une ligne pour le document, puis une ligne par feuille de style, par script, par image, par police de caractères. Une seule visite peut ainsi produire quarante lignes.

S’ajoute à cela tout ce qui n’est pas humain. Les robots des moteurs de recherche, les outils de surveillance, les agrégateurs de flux, les scanners de vulnérabilité, les robots d’entraînement des intelligences artificielles, et le trafic que votre propre site génère sur lui-même. Si vous comptez les lignes brutes et que vous les comparez à Google Analytics, vous allez voir un facteur cinq ou dix et croire au jackpot. Ce serait une erreur grossière.

Sur mes 493 863 lignes, la décomposition m’a franchement surpris. Les attaques et les processus système représentent 109 679 requêtes, soit 22,2 % du total, dominées par des tentatives répétées sur un point d’entrée classique de WordPress. Le trafic interne généré par mon propre site, notamment par le préchargement du cache, pèse 141 106 requêtes, soit 28,6 %. Les robots des outils de référencement ajoutent 18 727 requêtes et ceux des intelligences artificielles 6 516.

Autrement dit, plus de la moitié de l’activité de mon serveur n’a strictement rien à voir avec des visiteurs. C’est déjà un enseignement en soi, et cela m’a conduit à revoir ma configuration de cache dans la foulée.

Quel filtre sépare vraiment un humain d’un robot ?

C’est le cœur de la méthode, et c’est ce qui rend cette étude reproductible. La première approche, naïve, consiste à compter les adresses IP uniques ayant demandé une page, après avoir exclu les robots connus par leur identifiant. Cette méthode m’a donné 19 581 visiteurs. Extrapolé sur un mois, cela dépassait les 24 000 personnes. Je savais que c’était faux avant même de vérifier.

Deux raisons à cela. D’abord, les réseaux mobiles font tourner les adresses IP en permanence, ce qui gonfle artificiellement le compte. Ensuite et surtout, une grande partie des robots modernes se déclarent avec un identifiant de navigateur parfaitement crédible. Filtrer sur l’identifiant ne sert donc plus à grand-chose.

J’ai alors appliqué un critère beaucoup plus discriminant, basé sur le comportement plutôt que sur la déclaration. Un vrai navigateur, quand il affiche une page, télécharge automatiquement les feuilles de style et les scripts qui l’accompagnent. Un robot, lui, se contente presque toujours du document HTML. Je n’ai donc compté comme humaine qu’une session dont le couple adresse IP et identifiant de navigateur avait demandé au moins un fichier CSS ou JavaScript dans les deux minutes suivant la page.

Le résultat est sans appel. Les sessions retenues chargent en moyenne 7,32 fichiers annexes par page. Les sessions rejetées en chargent 0,08. Il n’y a aucun recouvrement entre les deux populations, ce sont deux mondes distincts. Et l’estimation humaine chute de 19 581 à 6 067, soit 72,4 % de disparitions.

Quels filtres appliquer avant de tirer la moindre conclusion ?

Voici la séquence exacte que j’applique désormais, dans cet ordre. Chaque étape retire une catégorie de bruit, et sauter l’une d’elles suffit à fausser complètement le résultat final.

Google Analytics contre les logs : le verdict chiffré

Passons aux résultats. Ma fenêtre de mesure côté serveur couvre 25 jours, du 30 juin au 24 juillet 2026. Ma fenêtre Google Analytics couvre 30 jours, du 24 juin au 23 juillet. Les deux périodes ne sont pas identiques, j’ai donc tout ramené au quotidien pour que la comparaison ait un sens.

Google Analytics 4 affiche 6 730 pages vues sur sa période, soit 224 par jour. Mon analyse de logs validée par le filtre des fichiers annexes donne 13 048 pages vues humaines, soit 522 par jour. L’écart est d’un facteur 2,3. Formulé autrement, Google Analytics voit environ 43 % de mon trafic réel.

Ce chiffre demande deux nuances d’honnêteté, et je préfère les poser moi-même plutôt que d’être corrigé en commentaire. D’un côté, mon filtre compte certaines adresses que Google Analytics ne compte pas, comme les pages d’erreur ou les flux de syndication. Le facteur 2,3 est donc un plafond. De l’autre, un visiteur qui revient sur le site avec les fichiers annexes déjà en cache ne les redemande pas et se retrouve éjecté de mon comptage. Le facteur est donc aussi un plancher. La vérité se situe dans cette fourchette, mais l’écart reste massif dans tous les cas.

Un élément vient valider l’ensemble de la démarche, et c’est celui qui m’a le plus rassuré. Google Analytics dispose désormais d’un canal dédié aux assistants IA, et il affiche 38 sessions sur la période. Mon analyse de logs, totalement indépendante, en trouve 42. Deux méthodes qui n’ont rien en commun aboutissent à 10 % près au même résultat. Quand deux instruments différents convergent, c’est généralement que l’on mesure quelque chose de réel.

Quelle méthode de mesure choisir selon votre besoin ?

Aucune de ces trois approches n’est meilleure dans l’absolu, elles ne répondent simplement pas à la même question. Voici comment je les positionne désormais dans mon travail quotidien.

Que font vraiment les intelligences artificielles sur votre site ?

Voilà la partie que je n’avais pas anticipée, et de loin la plus importante. Sur mes 25 jours de mesure, les robots liés aux intelligences artificielles ont effectué 6 516 requêtes sur mon site. Pendant la même période, les visiteurs arrivés depuis une interface d’IA se comptent au nombre de 42. Le ratio est de 155 lectures pour un seul visiteur envoyé.

Mais l’agrégat cache le plus intéressant. Il faut distinguer deux familles de robots que tout le monde mélange. D’un côté les robots d’entraînement, qui parcourent le web pour constituer des corpus. De l’autre les agents temps réel, déclenchés au moment précis où un utilisateur pose une question dans un chat.

Or chez moi, le premier robot en volume est un agent temps réel, avec 2 842 requêtes. Ce ne sont pas des passages d’entraînement anonymes, ce sont 2 842 fois où quelqu’un a posé une question et où le système est allé lire ma page pour construire sa réponse. Mon contenu a servi à répondre à des milliers de personnes en trois semaines. Presque aucune n’est jamais venue chez moi.

Chez le principal acteur du secteur, le ratio grimpe à 728 lectures pour un unique visiteur renvoyé. Je précise que ces 42 clics constituent un plancher, car de nombreuses interfaces d’IA, en particulier sur mobile, transmettent mal l’information de provenance. Le vrai ratio est donc meilleur que 155, mais l’ordre de grandeur reste écrasant.

Comment interpréter le comportement de chaque type de robot ?

Tous les passages de robots ne se valent pas, et les confondre mène à des décisions absurdes comme bloquer l’ensemble des accès. Voici les trois catégories que je surveille séparément désormais.

Pourquoi ma courbe de taux de clic est-elle devenue plate ?

En croisant mes données de logs avec celles de la Search Console, je suis tombé sur le chiffre le plus dérangeant de toute cette étude. Sur 30 jours, mon site affiche 148 589 impressions dans les résultats Google pour 1 805 clics, soit un taux de clic global de 1,21 %.

Ce chiffre seul ne dit pas grand chose, car un taux moyen mélange les bonnes et les mauvaises positions. J’ai donc découpé par tranche. En position 1 à 3, mon taux de clic est de 1,43 %. En position 3 à 10, il est de 1,38 %. En position 10 à 20, il tombe à 0,21 %.

Regardez bien les deux premiers chiffres. Ils sont quasiment identiques. Or dans un fonctionnement normal du référencement naturel, le taux de clic s’effondre avec la position : on parle classiquement de 25 à 35 % en première place contre quelques pourcents en bas de première page. Cette dégringolade est le mécanisme fondamental qui rend le référencement rentable.

Chez moi, cette courbe a disparu. Être premier ou septième ne change plus rien au nombre de visiteurs. C’est un constat brutal, mais il est infiniment plus utile de le savoir maintenant que dans six mois. Cela signifie que sur ces requêtes précises, continuer à investir pour gagner des positions ne rapportera plus rien.

À quoi ressemble la signature d’une requête à zéro clic ?

En descendant dans le détail requête par requête, un motif m’a sauté aux yeux. Cinq formulations quasiment identiques autour d’une même comparaison de plateformes, toutes positionnées entre la deuxième et la troisième place, cumulant 23 005 impressions. Et sur ces 23 005 affichages, zéro clic. Pas un seul.

Ce type de motif ne s’explique pas par une recherche classique tapée dans une barre. Personne ne saisit cinq variantes conversationnelles d’une même question dans un moteur traditionnel. En revanche, c’est exactement la forme que prennent les questions posées dans les interfaces de recherche générative. Le système affiche ma page comme source, comptabilise l’impression, construit sa réponse, et l’utilisateur repart satisfait sans jamais cliquer.

Deux autres requêtes viennent confirmer le diagnostic. Sur l’une, je suis positionné à 1,3 en moyenne avec 4 460 impressions et un taux de clic de 4,1 %. Sur l’autre, position 1,3 également, 4 055 impressions, et 2,5 % de taux de clic. En première position, je perds donc autour de 90 % des clics normalement attendus.

La raison est simple et elle tient au type de question. Ces requêtes portent sur des informations dont la réponse tient en une phrase. Quand la réponse complète est affichée au-dessus du lien, l’internaute n’a aucune raison de descendre. Ce n’est pas un défaut d’optimisation de ma part, mes pages sont premières. C’est un changement de nature du canal.

Faut-il bloquer les robots d’intelligence artificielle ?

C’est la première réaction de beaucoup de propriétaires de sites quand ils découvrent ces chiffres, et je la comprends parfaitement. Si une machine lit mon travail 155 fois pour me renvoyer une personne, pourquoi continuer à lui ouvrir la porte ?

Des solutions de facturation à la lecture existent désormais, portées par certains acteurs de l’infrastructure web, et des dispositifs de licence de contenu commencent à se structurer. Techniquement, faire payer l’accès est donc possible aujourd’hui. Mais soyons lucides sur les ordres de grandeur : ces dispositifs sont calibrés pour des éditeurs de presse qui pèsent des dizaines de millions de pages vues. Avec quelques milliers de lectures par mois, les montants en jeu sont dérisoires.

Quant au blocage pur et simple, je pense que c’est une erreur stratégique majeure pour la plupart des sites. Fermer la porte aux robots d’IA revient à disparaître des réponses générées. Vous ne récupérez pas les clics perdus, vous perdez en plus l’exposition et la reconnaissance comme source. Sur un positionnement construit autour de l’optimisation pour les moteurs génératifs, ce serait un suicide pur et simple.

Ma position est donc de laisser les accès ouverts, mais de changer complètement la façon dont je mesure le retour. Le clic n’est plus la bonne unité de compte sur ce canal. J’ai basculé sur une autre métrique, et elle est facile à suivre pour n’importe qui.

Quel indicateur suivre quand le clic disparaît ?

L’hypothèse de repli habituelle consiste à se dire que les citations construisent la notoriété, et que les gens vous chercheront par votre nom plus tard. C’est une hypothèse raisonnable, mais elle se vérifie ou elle ne se vérifie pas. Alors je l’ai testée sur mes propres données.

Sur 30 jours, les recherches contenant mon nom totalisent 25 impressions et 9 clics. Autant dire rien du tout. Les intelligences artificielles me lisent massivement, mais elles ne me nomment pas assez pour que les gens retiennent qui je suis. À ce stade, le mécanisme de compensation par la marque ne fonctionne pas chez moi.

C’est pourtant précisément l’indicateur que je vais suivre tous les mois désormais, et je vous invite à faire pareil. Si une stratégie d’optimisation pour les moteurs génératifs produit du résultat, cela doit se voir quelque part. Et si ce n’est plus dans les clics organiques, alors cela doit apparaître dans le volume de recherches sur votre nom ou celui de votre marque.

C’est un indicateur simple, gratuit, disponible dans la Search Console, et beaucoup plus honnête que les tableaux de bord qui comptent les mentions dans les réponses IA sans jamais démontrer le moindre retour. Si la courbe monte, votre travail paie. Si elle reste plate pendant six mois, il faut changer d’approche.

Que faut-il changer dans sa stratégie de contenu ?

Je tire trois conclusions opérationnelles de cette étude, et elles ont directement modifié mon plan éditorial pour la fin de l’année.

La première, c’est que le contenu purement informationnel sur des questions à réponse courte n’est plus un canal d’acquisition. J’avais construit des ensembles de pages parfaitement optimisés sur des questions factuelles, du type origine d’un outil ou pays d’un éditeur. Ces pages sont premières. Elles ne rapportent presque aucun visiteur, et elles n’en rapporteront plus jamais, parce que la réponse tient en une ligne et qu’elle est affichée avant mon lien.

La deuxième, c’est que ce contenu n’est pas inutile pour autant. Il change simplement de rôle. Il ne se compte plus en trafic, il se compte en autorité thématique et en présence dans les corpus. C’est un coût d’entrée pour exister comme source, pas une source de visiteurs. Faire cette distinction évite de se décourager, et évite surtout d’en produire trop.

La troisième, c’est qu’il faut réorienter la production vers ce qui résiste structurellement au résumé automatique. Un outil interactif ne peut pas être résumé, il faut l’utiliser. Une donnée originale que vous êtes seul à produire ne peut pas être inventée, elle peut seulement être citée avec votre nom. Une opinion argumentée fondée sur votre expérience ne se trouve nulle part ailleurs. Et une intention commerciale nécessite un humain au bout de la chaîne.

Quelles sont les limites honnêtes de cette méthode ?

Je préfère lister moi-même les faiblesses de mon protocole plutôt que de laisser croire à une précision qu’il n’a pas. Cette étude donne des ordres de grandeur solides, pas des mesures au visiteur près.

Première limite, l’unité de comptage. Le couple adresse IP et identifiant de navigateur n’est pas une personne. Un même téléphone en itinérance génère plusieurs couples, un réseau d’entreprise en fusionne plusieurs en un seul. Le chiffre est directionnel. C’est pour cela que je compare les pages vues plutôt que les visiteurs uniques, car les pages vues sont beaucoup plus robustes.

Deuxième limite, la fenêtre. Mon hébergement ne conserve que le mois en cours, je n’avais donc pas de mois calendaire complet à disposition. J’ai travaillé sur 25 jours et ramené au quotidien, ce qui reste comparable mais introduit une part de saisonnalité non contrôlée.

Troisième limite, les clics d’IA sont sous-estimés parce que plusieurs interfaces transmettent mal la provenance, en particulier depuis les applications mobiles. Quatrième limite enfin, mes catégories ne sont pas parfaitement étanches : un robot sophistiqué qui exécute le JavaScript peut franchir mon filtre et être compté comme humain. Ces réserves ne changent pas les conclusions, mais elles doivent accompagner les chiffres.