Quand on veut améliorer le référencement naturel d'un site, on commence souvent par auditer l'existant afin de comprendre quels problèmes existent sur le site et quelles opportunités de croissance peuvent être exploitées. L'analyse de logs en SEO fait partie du panel d'analyses que l'on peut justement réaliser dans ce but.
Elle s'attache à comprendre quel comportement les moteurs de recherche adoptent lorsqu'ils visitent vos pages Web.
Dans cet article, je vais vous expliquer ce que sont les logs, à quoi sert une analyse de logs en SEO, avec quels outils la réaliser et ce qu'elle peut vous apprendre.
Les logs serveur, qu'est-ce que c'est ?
Avant de comprendre pourquoi il est intéressant d'analyser les logs, encore faut-il savoir de quoi il s'agit !
Différents types de logs
Les logs sont des fichiers qui consignent des événements survenus dans un système, un peu comme si vous alliez dans un bâtiment et que l'on notait votre nom, vos coordonnées, votre heure d'arrivée et le motif de votre visite.
Il existe différents types de logs : on peut par exemple citer les "change logs", qui gardent la trace de toutes les modifications effectuées sur un fichier, un logiciel, une application... Ou encore les logs de sécurité, qui consignent tous les événements liés à la sécurité d'un système d'information et permettent de détecter certaines menaces informatiques.
Mais les logs qui vont nous intéresser dans le cadre d'une analyse de logs en SEO sont les logs serveur.
Ces fichiers, souvent segmentés par date, gardent en mémoire toutes les actions effectuées sur le serveur où se trouve votre site : quelles machines ont accédé au site (humains, robots, etc), quels fichiers ont été téléchargés et consultés, depuis quel navigateur et à quelle heure, quelles erreurs éventuelles ont été rencontrées...
A l'intérieur de ces logs, nous allons donc pouvoir isoler l'activité des moteurs de recherche pour l'étudier de plus près. En France, quand on réalise une analyse de logs, on se concentre souvent sur Google car c'est le moteur dominant à plus de 90%. Mais dans un autre pays, on pourrait tout à fait prendre en compte plusieurs moteurs, ou un autre moteur que Google (comme Baidu en Chine).
Comment récupérer les logs serveur ?
Si votre site est stocké sur un hébergement mutualisé, vous pouvez généralement accéder à ces fichiers sans avoir besoin de demander à votre hébergeur. À titre d'exemple, chez mon hébergeur o2switch, on peut retrouver les logs soit en se connectant via FTP à son espace d'hébergement et en allant dans le dossier /logs/ :
Soit via l'interface en ligne (Cpanel), en allant dans le menu "Accès brut" :
Sur un serveur dédié ou un VPS, les logs seront souvent stockés de la même manière. Vous pouvez ainsi télécharger les fichiers afin de les analyser ensuite sur des outils dédiés. Sachez aussi, si vous êtes à l'aise en développement web ou avez un développeur web à vos côtés pour vous aider, que l'on peut automatiser l'envoi des logs.
Si vous utilisez un CDN comme Cloudflare, Amazon CloudFront, vous pouvez y récupérer les logs. Il est d'ailleurs préférable de le faire plutôt que d'aller les chercher sur le serveur "source" où les données sont stockées : en effet, le CDN est le plus "proche" de votre visiteur final, celui qui va lui délivrer les pages web, c'est donc lui qui va enregistrer le gros du trafic.
Que contiennent les logs serveur ?
Si vous ouvrez un fichier de logs, voici à quoi il va ressembler :
Prenons une ligne et regardons ensemble ce qu'elle comporte :
66.249.66.19 - - [31/Dec/2021:01:00:38 +0100] "GET /perte-abonnes-instagram/amp/ HTTP/1.1" 200 95551 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Voici les principales informations dignes d'intérêt :
- Une adresse IP - Ici, 66.249.66.19. L'adresse IP permet d'identifier une machine sur un réseau, soit l'ordinateur ou le smartphone d'un particulier, soit un robot (comme le robot de Google par exemple).
- Une date et un horaire - Ici, [31/Dec/2021:01:00:38 +0100].
- Le type de requête effectué sur le site - Ici, "GET" pour récupérer une ressource. Il peut aussi y avoir des requêtes "POST" (soumission d'un formulaire par exemple).
- L'URL demandée - Ici, c'est l'article sur la perte d'abonnés Instagram qui a été consulté, dans sa version AMP (version conçue pour les mobiles).
- Le code de statut renvoyé par la page - Ici, c'est un code 200, qui signifie que la page est fonctionnelle (on aurait pu avoir aussi une erreur 404 par exemple).
- Le poids de la page - Ici, 95551 bytes.
- Le user-agent (agent utilisateur), qui fournit des informations complémentaires sur le navigateur utilisé, l'identité éventuelle du robot si c'est un robot, son mode mobile ou desktop... Ici, le "visiteur" se présente comme étant Googlebot, le robot de Google.
Il faut savoir que le user-agent peut parfois être modifié : certains robots de spam essaient ainsi de se faire passer pour Google quand ils arrivent sur un site. Pour cette raison, il est nécessaire de croiser l'information fournie par le user-agent avec l'adresse IP pour s'assurer qu'il s'agit bien du "vrai Google".
Google a en effet communiqué une liste des adresses IP "officielles" du Googlebot... et même sans cette liste, si on essaie de géolocaliser l'adresse IP "66.249.66.19", on identifie rapidement qu'elle appartient à Google et est localisée à "Mountain View", la municipalité californienne qui accueille le siège de Google.
Quels défis pose une analyse de logs ?
Quand on réalise une analyse de logs en SEO pour un tiers, c'est parfois la croix et la bannière de récupérer ces fichiers :) "On ne sait pas où c'est stocké", "on n'a stocké que 14 jours", "on ne peut pas les partager pour des raisons de sécurité/confidentialité", "il faudrait développer un script sur mesure pour les envoyer et on n'a pas les ressources", "on ne peut pas partager de gros fichiers à cause de notre politique d'entreprise, ça ne passe pas", "notre développeur nous facture très cher la récupération des logs".
Ensuite, un fichier de logs peut comporter des millions de lignes en fonction de la taille du site et du trafic qu'il reçoit. Cela signifie qu'il n'est pas envisageable de le traiter à la main, vous allez donc avoir besoin d'outils pour réaliser une analyse de logs.
Ca a un coût, mais ça implique aussi que les logs soient livrés avec le bon format, en étant suffisamment "complets" pour qu'un outil puisse les exploiter. Chaque outil communique en général sur le standard à utiliser.
Ensuite, il faut aussi penser à la représentativité statistique des logs : si vous n'avez qu'une semaine de logs à disposition, par exemple, c'est rarement suffisant pour généraliser vos conclusions. Dans un monde parfait, j'aime réaliser une analyse de logs initiale sur 90 jours de données, durée qui permet de prendre plus de recul sur ce qui se passe sur le site.
Mais justement, que peut-on tirer comme informations de ces fichiers somme toute assez indigestes à regarder ?
A quoi sert une analyse de logs en SEO ?
Le discours que l'on entend le plus souvent au sujet de l'analyse de logs en SEO est qu'elle permet de "mieux gérer le crawl budget". De quoi s'agit-il ?
La notion de crawl budget
En simplifiant, il y a aujourd'hui beaucoup de pages web en ligne, beaucoup de sites à explorer. Google, comme tout moteur de recherche, doit donc optimiser son temps et ses ressources pour en visiter un maximum. Il alloue donc à chaque site une quantité limitée de ressources, un nombre maximum de pages qu'il va pouvoir explorer sur une période donnée. On appelle cela le "crawl budget" (ou budget de crawl).
En réalité, beaucoup de sites n'ont pas à s'inquiéter de cette limite car Google accorde amplement assez de ressources pour explorer leur site. Le sujet devient plus stratégique quand vous avez un gros site de plusieurs dizaines de milliers de pages et plus ou que vous vous préoccupez de la rapidité d'indexation vos pages : imaginez un site e-commerce qui ouvre une nouvelle catégorie de produits, il a tout intérêt à ce que les pages soient explorées et indexées rapidement.
La notion de crawl budget est surtout intéressante parce qu'elle implique un arbitrage et une prise de conscience de votre part : sur votre site, toutes les pages ne se valent pas ; certaines ont plus de valeur commerciale que d'autres... et vous voulez que Google se concentre sur celles-là, et pas sur des pages peu intéressantes comme "Mot de passe oublié" ou "Politique de confidentialité".
Comprendre comment le moteur perçoit le site
L'analyse de logs vise justement à vous aider dans cet arbitrage, pour que Google se consacre en priorité aux pages que vous jugez les plus stratégiques.
Il va donc falloir comprendre comment le moteur perçoit votre site, comment il se comporte quand il est dessus. Vous allez ensuite pouvoir croiser ces informations issues des logs avec d'autres sources de données :
- Un crawl classique d'un site : vous allez par exemple pouvoir déterminer s'il existe un lien entre la profondeur d'une page dans la structure du site et la fréquence du crawl... ou entre le nombre de liens internes que reçoit un contenu et sa propension à être exploré par les moteurs ;
- Les données Search Console, pour établir un lien entre le comportement du moteur et les performances SEO d'une page ;
- Des données issues d'outils tiers, par exemple des outils de netlinking, pour voir s'il y a des caractéristiques communes aux pages que Google explore le plus en termes de profil de liens (ces pages reçoivent-elles beaucoup de backlinks ?).
A travers toutes ces données, vous allez pouvoir :
- Tirer des conclusions pour améliorer le site - Limiter la profondeur des contenus stratégiques, faciliter l'accès des moteurs aux ressources clés en ajoutant des liens internes ou en repensant l'arborescence du site, faire disparaître certaines erreurs ou redirections internes inutiles, enrichir des pages dont le contenu est pauvre et peu intéressant pour un moteur, revoir l'indexation de certains contenus (en interdisant par exemple aux moteurs d'aller dessus), etc.
- Suivre l'impact de changements majeurs - Vous allez pouvoir étudier le comportement de Google après une refonte de site, une refonte de l'arborescence, une migration.
- Détecter des problèmes de sécurité - Les logs permettent parfois de faire émerger des cas de piratage, où des milliers de pages ont été générées sur un site de manière automatisée : ce n'est pas forcément détectable de l'extérieur en visitant le site, mais ça va ressortir dans les logs.
Quels éléments regarder dans une analyse de logs ?
Quelles pages sont explorées par les moteurs et comment ?
Quelles sont les pages sur lesquelles les moteurs de recherche passent le plus souvent et à quelle fréquence les explorent-ils ? Est-ce cohérent avec les pages que vous estimez stratégiques ?
L'analyse des logs va vous montrer quelles pages sont les plus crawlées, combien de fois le moteur est passé dessus au cours de la fenêtre temporelle correspondant à votre échantillon de logs.
Il est souvent pertinent de segmenter le site en fonction de votre stratégie plutôt que de réaliser une analyse page par page. Cela vous permet, dans un premier temps, de voir s'il existe une hiérarchie entre vos différentes rubriques : certaines ont-elles davantage la faveur des moteurs ? D'autres sont-elles complètement délaissées ?
Ici par exemple, j'ai dû masquer la segmentation pour des raisons de confidentialité mais on voit que sur certaines rubriques du site, il n'y a que la moitié des pages qui sont explorées par Google alors que sur d'autres, 100% des pages sont explorées.
Si vous constatez que le moteur passe trop de temps sur des pages peu stratégiques ("mot de passe oublié", page de connexion, mentions légales, politique de confidentialité, etc), il peut être pertinent de modifier leur stratégie d'indexation : par exemple, si ce sont des pages non pertinentes en SEO, vous pouvez décider d'empêcher les moteurs de recherche de les consulter avec une instruction "disallow", en complément d'une instruction "noindex" qui interdira à Google de les répertorier.
Si les pages sont déjà indexées, il faudra d'abord les désindexer avant de les interdire aux moteurs.
On peut aussi aller plus loin en décidant en plus de rendre les liens qui pointent vers ces pages inutilisables par un moteur de recherche (tout en restant pleinement fonctionnels pour le visiteur). On parle alors d'obfuscation. Au lieu de construire le lien de façon "classique" dans le code, en utilisant la balise "a href", on a recours à du JavaScript + à un encodage du lien afin qu'il ne soit pas reconnu comme étant une URL.
Du côté du visiteur, le site fonctionne normalement mais le moteur de recherche n'est pas capable de détecter l'existence du lien, donc d'aller sur la page.
Le site comporte-t-il des "pièges à robots" ?
Sur certains sites, il existe ce que l'on a appelé des "spider traps", autrement dit, des "pièges à robots". Ce sont des éléments présents sur les pages Web qui font qu'un moteur de recherche va se retrouver pris dans une sorte de boucle infinie, prisonnier de votre site sans parvenir à en sortir.
Sur le papier, ça pourrait être sympathique de garder Google chez soi mais en réalité, dans ce type de situation, le moteur va rester coincé sur des pages à faible valeur ajoutée. Le fameux "budget de crawl" se retrouve donc bien mal dépensé.
Parmi les cas que je rencontre le plus souvent dans mon métier, il y a celui des filtres (navigation à facettes sur les sites e-commerce, filtres de contenu sur de gros sites médias) : quand on laisse le moteur accéder aux filtres, il va parfois se retrouver pris dans une spirale où il va tester de manière automatique toutes les combinaisons possibles de filtres... ce qui peut vite générer des centaines de milliers d'URL.
Autre situation : la pagination. Sur beaucoup de sites, le contenu des rubriques s'affiche sur plusieurs pages. Parfois, cette pagination est mal codée et le moteur peut l'incrémenter sans fin, sans jamais tomber sur une erreur. Même si la page 5927 ne comporte pas de contenu propre, l'URL peut quand même être générée, renvoie un code 200 (page fonctionnelle)... si bien que rien n'indique à Google qu'il doit arrêter d'explorer la rubrique. Si on le laisse faire, on le retrouve à la page 201899...
Le même principe peut se produire sur des calendriers (qui vous laissent avancer dans le futur sans limite et peuvent donc joyeusement emmener Google en l'an 10879 de notre ère).
Autre cas assez fréquent : des URL qui contiennent un identifiant de session. A chaque fois qu'un visiteur accède au site, ouvrant une session, cela génère une nouvelle URL avec un identifiant de session à l'intérieur, comme ci-dessous sur une boutique de robes de mariée.
Si ce type de situation n'est pas géré, le moteur de recherche se retrouve face à une infinité de pages à indexer ayant toutes le même contenu mais une URL qui change tout le temps.
L'analyse de logs permet justement de repérer ces "spider traps" pour les faire disparaître, à travers une meilleure gestion des filtres et une correction des erreurs de pagination par exemple.
Y a-t-il des pages délaissées par les moteurs ?
Nous venons de voir sur quelles pages le moteur de recherche passe du temps mais il est tout aussi intéressant d'étudier celles qu'il délaisse.
Pouvez-vous identifier des parties du site qui sont moins crawlées que les autres ? Quelles caractéristiques ont-elles en commun ? Par exemple...
- Des pages qui ont un niveau de profondeur important dans la structure du site ;
- Des pages qui sont pauvres en contenu ;
- Des pages qui présentent un niveau de duplication important ;
- Des pages avec des problèmes techniques signalés ;
- Des pages qui reçoivent peu de liens internes (depuis d'autres pages du site).
C'est là qu'il est intéressant de croiser les données issues de l'analyse de logs avec des informations issues d'un crawl classique du site, qui vous donnera justement ces notions de profondeur, de nombre de mots sur la page, etc.
Ici par exemple, on voit qu'à partir d'une profondeur de 4 par rapport à l'accueil, il n'y a plus qu'un tiers des pages qui sont explorées par Google sur la période étudiée.
Cela permet ensuite de corriger les problèmes en conséquence, par exemple :
- Ajouter davantage de liens internes vers les pages concernées ;
- Les enrichir en contenu et les remettre à jour si nécessaire ;
- Les supprimer si vous estimez que ces contenus n'ont plus leur place sur le site et sont devenus inutiles ;
- Les "fermer" aux moteurs (en les désindexant puis, une fois la désindexation effectuée, en mettant une instruction "disallow" pour interdire aux moteurs d'aller dessus) si vous considérez que les contenus méritent encore leur place sur le site mais n'ont pas besoin d'être référencés ;
- Corriger les problèmes techniques.
Par expérience, on constate en général que la fréquence de crawl d'une page par Google diminue à mesure que sa profondeur par rapport à la page d'accueil augmente, en particulier au-delà du niveau 3-4.
C'est assez logique dans le sens où si vous "cachez" un contenu dans les profondeurs du site, ça laisse entendre qu'il n'a pas beaucoup d'importance pour vous, il n'en a donc pas beaucoup non plus pour le moteur. A l'inverse, si un contenu est facile d'accès, présent dans le menu par exemple, cela laisse entendre qu'il est stratégique et il est logique que Google y consacre plus de temps. Gardez en tête ces notions de bon sens pour éventuellement revoir l'arborescence de votre site.
Y a-t-il des pages orphelines ?
Une page orpheline est une page Web qui n'est plus présente dans le maillage interne du site (on ne la détecte pas en crawlant le site ou en l'explorant "manuellement" car il n'y a plus aucun lien qui mène à la page)... mais qui reste malgré tout en ligne.
J'ai un client e-commerce qui était spécialiste de ce type d'erreur : il proposait régulièrement des promotions, pour lesquelles il créait une page dédiée qu'il mettait en avant sur l'accueil de son site. Une fois la promotion terminée, il retirait simplement le lien de l'accueil mais sans supprimer la page.
Or, souvent, le contenu concerné a reçu des liens depuis des sites tiers, il a pu être partagé sur les réseaux sociaux... et ces liens qui traînent, ailleurs que sur votre site, permettent encore d'accéder à la page, ce dont Google ne se prive pas !
Si la page a été retirée du maillage par erreur mais est encore pertinente, ajoutez des liens vers elle.
Si une page n'est plus pertinente, pensez à la supprimer et à créer si c'est pertinent une redirection depuis son adresse vers une page alternative sur la même thématique.
Y a-t-il des pages suspectes sur le site ?
C'est assez rare mais une analyse de logs permet parfois de détecter un piratage de site qui était invisible à l'œil nu. J'ai déjà croisé ce cas : le piratage avait généré des centaines de pages de contenu sur des sujets insolites (porno, films d'horreur) sans aucun rapport avec l'univers du client (sinon, c'est pas drôle !). Ce n'était pas visible quand on explorait le site... mais c'est très vite ressorti dans les logs !
A quelle fréquence Google tombe-t-il sur des erreurs ?
Lorsque l'on réalise un audit technique sur un site, l'une des analyses consiste à regarder le code de statut que renvoient les pages. Sont-elles fonctionnelles (code 200), y a-t-il des erreurs 404 (liens brisés, pages non trouvées), des erreurs 5xx (erreurs serveur), des chaînes de redirection (une page redirigée vers une page redirigée vers une page et ainsi de suite !) ou d'autres types d'erreurs ?
Ici par exemple, on voit la proportion de chaque code de statut rencontré par un moteur de recherche au fil du temps (on peut cliquer sur chaque barre du diagramme pour accéder à la liste des pages concernées) : ça permet de détecter des problèmes ponctuels sur le site (explosion des erreurs) mais aussi de suivre la prise en compte par Google des corrections effectuées.
L'analyse de logs permet d'aller encore plus loin car elle va aussi vous signaler ce type d'erreur même lorsqu'elles ne sont pas directement présentes sur les pages de votre site.
Imaginez la situation suivante : vous avez publié un article il y a 10 ans. À l'époque, il a connu son petit succès, il a été partagé sur d'autres sites, des gens en ont parlé sur leur blog... Mais par la suite, vous avez changé de ligne éditoriale et vous avez supprimé ce contenu sans le rediriger nulle part.
10 ans plus tard, donc, Google se promène sur le web, tombe sur un blog qui parle de votre article et suit naturellement le lien qui s'y trouve... en tombant sur une page d'erreur.
Vous êtes précisément dans une situation où sur votre site lui-même, il n'y a plus de lien qui pointe vers cette fameuse page, elle a disparu, l'erreur n'est donc pas signalée lors d'un crawl classique du site. Pourtant, grâce aux logs, vous allez pouvoir repérer que Google est tombé sur une erreur... et agir en conséquence (ex : rediriger l'URL, faire en sorte qu'elle renvoie un code 410 pour signaler que la page a disparu et ne reviendra pas).
Mon exemple est volontairement caricatural car en 10 ans, le moteur de recherche a eu le temps de comprendre qu'un article disparu ne reviendrait pas... mais au moins, vous voyez l'idée ;)
Il s'agit pour vous de :
- Corriger les erreurs ;
- Retirer les références à des URL qui n'existent plus (soit en supprimant le lien, soit en mettant directement le lien "final" si l'URL supprimée a été redirigée) ;
- Faire le point sur votre hébergement si vous constatez que les erreurs serveur sont récurrentes.
Gardez en tête que les références à des URL problématiques peuvent se trouver dans le contenu lui-même mais aussi dans des balises canoniques, des balises hreflang sur les sites multilingues, des sitemaps ou dans des chaînes de redirections...
Combien de temps mettent les nouveaux contenus à être explorés ?
En réalisant une analyse de logs sur une période de plusieurs mois ou en gardant un œil sur les logs en continu, vous allez pouvoir repérer au bout de combien de temps un nouveau contenu attire l'attention de Google. Cela correspond au moment où vous repérez les premiers passages du moteur sur l'URL de ce contenu.
Au-delà de la valeur elle-même, vous allez surtout pouvoir tirer des conclusions sur ce qui permet à un contenu d'être exploré rapidement : certaines rubriques sont-elles plus porteuses que d'autres, à quel point le fait de mettre en avant l'article en page d'accueil accélère-t-il sa découverte par Google ?
Quel lien entre performances SEO et analyse des logs ?
Lorsque je réalise une analyse de logs, j'aime créer une matrice de décision en fonction de la performance SEO d'une page (combien de clics SEO reçoit-elle) et de la fréquence à laquelle elle est crawlée par Google.
- Pages très crawlées, très visitées par les internautes => elles sont censées être les plus stratégiques du site, celles vers lesquelles on crée le plus de liens internes, que l'on retrouve à des emplacements stratégiques. Elles sont prioritaires à mes yeux, doivent être mises à jour régulièrement et "surveillées" comme le lait sur le feu pour rester compétitives face aux concurrents ;
- Pages très crawlées, peu visitées => elles intéressent le moteur mais pas l'internaute => sont-elles réellement pertinentes en SEO ou pourraient-elles être désindexées ? Prennent-elles trop de place dans l'arborescence ? Le contenu est-il en phase avec les intentions de recherche des internautes, peut-il être retravaillé ?
- Pages peu crawlées, très visitées => ce cas est moins fréquent mais si ça arrive, ça peut être intéressant de repositionner ces pages dans la structure du site pour qu'elles soient moins profondes et reçoivent davantage de liens ;
- Pages peu crawlées, peu visitées => y a-t-il un problème dessus (problème technique, contenu pauvre, dupliqué) ? Doivent-elles être supprimées, interdites aux moteurs ?
Quels outils pour réaliser une analyse de logs ?
Il existe sur le marché beaucoup d'outils pour réaliser une analyse de logs. En voici quelques-uns !
SEOlyzer, accessible aux indépendants
SEOlyzer est un outil d'analyse de logs gratuit pour les "petits sites" (jusqu'à 10000 URL crawlées ou logs/mois). Il propose ensuite différentes formules d'abonnement pour les sites plus importants et plus visités.
La bonne nouvelle aussi, c'est que le décompte des URL est "intelligent" : autrement dit, dans le quota, on ne vous compte que les visites SEO issues de Google et les pages téléchargées par Googlebot, en excluant aussi du décompte tout ce qui concerne les images, les scripts et les feuilles de style.
L'outil vous offre à la fois un analyseur de logs et un crawler, permettant de réaliser des analyses croisées. C'est français (cocorico à son fondateur, Olivier Papon !) et je lui trouve un grand avantage : l'interface est très facile à prendre en main pour quelqu'un qui n'est pas "du métier".
Il me fait penser à l'outil JetOctopus, qui dissocie crawler et analyseur de logs.
Screaming Frog Log File Analyser
Là aussi, il s'agit d'une solution très bon marché ! Screaming Frog est un éditeur de logiciels très réputé en SEO, qui propose notamment un excellent outil pour crawler des sites ("Screaming Frog" tout court). Ils offrent également un outil d'analyse de logs, Screaming Frog Log File Analyser.
Il est utilisable gratuitement jusqu'à 1000 lignes de logs (ce qui est très peu) mais l'abonnement annuel est vraiment très bon marché, à la portée d'un indépendant ou d'une petite entreprise.
C'est un outil très complet, la version gratuite vous donne l'avantage de pouvoir tester pour voir s'il vous convient avant d'investir. En revanche, il n'est pas à mes yeux adapté aux très gros sites : en effet, c'est un logiciel que l'on installe sur son ordinateur, autant dire que lors du traitement de gros volumes de logs ça fait un peu fumer la machine :)
Botify, pour des besoins importants
Botify vise clairement un autre public, avec un outil complet, dans le cloud (donc apte à gérer des sites à forte volumétrie de logs), permettant à la fois le crawl et l'analyse de logs. Il est extrêmement puissant, on peut segmenter les données de manière très fine, couvrir toutes les dimensions dont on a besoin quand on réalise un audit technique. Les possibilités de filtres sont infinies.
En revanche, ce n'est pas à la portée de toutes les bourses. Botify ne communique pas publiquement sur ses tarifs et se vante de construire une proposition sur mesure pour chaque client... mais évidemment, le sur-mesure a un prix ;)
OnCrawl, puissant et plus transparent sur les prix
Après avoir utilisé Botify pendant quelques années, j'ai fini par privilégier OnCrawl pour l'instant. C'est aussi un outil dans le cloud (donc idéal pour traiter de "gros volumes" sans être limité par la puissance de sa machine), qui combine crawler et analyseur de logs.
Ils sont plus transparents sur leurs tarifs et, de ma propre expérience, moins chers que Botify. OnCrawl s'adresse à mon sens à une cible d'entreprises de taille moyenne à grande... ou de petites entreprises misant énormément sur le SEO. Certains consultants SEO ont d'ailleurs recours au "group buy" pour pouvoir s'en servir sans payer une fortune (achat d'un accès "à plusieurs" et partage des ressources).
L'offre de base, autour de 50€/mois, présente pas mal de limites (par exemple, impossible à ce prix de faire un crawl JavaScript si le site le nécessite, ce qui est de plus en plus fréquent, l'analyse de logs n'est pas incluse, etc). Il faut donc négocier du sur-mesure et, une fois de plus, ce n'est pas gratuit.
Il y aurait bien d'autres outils à citer et chacun a ses petits préférés : certains sont pertinents en soi pour de l'analyse de gros fichiers (comme Splunk Log Observer) mais sont moins orientés analyse de logs et SEO.
Pour choisir, au-delà de vos besoins en termes de nombre de lignes de logs à traiter, de reporting (besoin d'un connecteur DataStudio ou pas, etc), il faut aussi raisonner en fonction de la valeur ajoutée que vous allez retirer d'une analyse de logs. Par exemple, si elle sert à régler un problème majeur d'indexation sur un site e-commerce, le bénéfice peut se compter en dizaines de milliers d'euros.
Dépenser 1000€ pour un outil est alors moins problématique que si on réalise ce type d'analyse "pour sa curiosité personnelle" ou "pour progresser en SEO".
Néanmoins, ça reste un complément très utile à un audit technique classique, pour débusquer des erreurs bien cachées que l'on n'aurait pas vues autrement... et pour se mettre (au moins vaguement) à la place de Google !
