On met souvent l’analyse des logs à l’avant-garde du SEO, considérée comme un truc de barbu où il faut mettre les mains dans le cambouis, installer des programmes tiers, etc. Bon ok y’a un p’tit côté geek indéniable dans l’ensemble du processus, mais je suis de plus en plus persuadé que cela reste accessible au plus grand nombre… à condition d’avoir accès aux logs du serveur web bien entendu, et un minimum d’envie !
Ce billet n’est pas un tutoriel pas à pas sur le traitement des access log d’Apache. Ceux qui sont à l’aise avec l’outil informatique sauront traduire les différents concepts abordés. L’intention est plutôt de partager mon approche et mes réflexions sur le sujet.
S’il existe une multitude de moyens et d’outils pour analyser les logs, j’ai tendance à penser qu’il n’y a pas 36 façons de le faire dans une logique « SEO analytics ».
Enfin, si vous êtes friand de visualisation de données, j’ai écrit il y a quelques temps déjà un billet sur la visualisation dynamique du crawl du Googlebot avec Gephi. Vous y trouverez également quelques techniques complémentaires à cet article.
D’autres ressources sont également proposées à la fin de cet article.
Deux approches différentes et complémentaires
Généralement on trouve deux grandes tendances dans la manière d’aborder les logs :
- Le monitoring au jour le jour et en temps réel qui consiste à installer un script sur le serveur et faire du « Googlebot Analytics » (Watussi, ou la fameuse « stack ELK » (Elasticsearch, Logstash & Kibana) par exemple). Il existe également des outils déportés en Saas comme Botify, Spiderlog ou encore Splunk. Hélas, beaucoup d’éditeurs et SEO s’obstinent à ne considérer que cette approche.
- L’analyse typée « audit », généralement attribuée aux consultants SEO, qui nécessite la récupération (rapide) de 2 ou 3 mois d’écritures (logs) déjà écoulés, sans avoir à installer de script sur le serveur, et attendre plusieurs semaines pour avoir de la data fiable. C’est cette approche que je vais partager avec vous.
Attention, je ne suis pas en train de dire que la 1ère option est moins bonne. C’est une approche différente, plus orientée monitoring qu’analyse, et qui peut être complémentaire. C’est le fait de balayer d’un revers de la main la 2ème approche plus artisanale qui me fait un peu grincer des dents. D’autant que tuner ELK peut demander beaucoup plus de temps et de compétences qu’un cat/grep en ligne de commande et un peu de nettoyage dans Excel. Et puis les jolis dashboards c’est bien, ça flatte la rétine, mais c’est rarement suffisant.
C’est quoi l’intérêt d’analyser les logs ?
Pas grand-chose si on ne considère que ça, et si on ne procède pas à du recoupement de données ! Je préfère dire « Utiliser les données des logs », ou encore « faire parler les logs ». C’est de la donnée brute, un indicateur qui servira à une analyse plus globale, et là ça peut devenir très intéressant. En fait, c’est comme pour tout en SEO : si vous ne faites que de l’analyse au travers de Google analytics ou search console, vous aurez toujours une vision biaisée. Si l’objectif est de repérer les pages faiblement crawlées et que vous n’associez pas les données avec un crawl « classique » avec Screaming Frog par exemple, vous n’allez jamais repérer les URLs qui ne sont jamais fréquentées par le Googlebot, et il peut y en avoir un paquet !
Petit rappel de ce qu’est un fichier log, et de l’utilité d’en récupérer les données : chaque serveur web doit légalement disposer d’un fichier journal (log) qui enregistre tous les accès appelés « hits » pour chaque ressource (page, fichier image, javascript etc), et pour tous les sites qu’il héberge. On y retrouve donc les hits générés par les internautes, mais également ceux des robots dont le fameux Googlebot, le robot d’indexation de Google. C’est bien évidemment ce dernier qui retiendra toute notre attention. Au passage, il y a plusieurs Googlebots : un spécifique aux images, un autre pour le mobile, le normal, et le mediapartners si vous avez des annonces Adsense. Ce qui nous intéresse ici, c’est le robot régulier généralement identifié sous l’appellation « Googlebot 2.1 ».
En fait absolument tous les accès sont consignés dans les logs contrairement à un service comme Google Analytics. C’est pour ça qu’on dit souvent « les logs ne mentent pas ».
L’objectif en SEO est donc de mesurer l’appétence du Googlebot, et son impact sur le référencement. Connaître avec une grande précision les URLs boudées par Google, et celles qu’il aime par-dessus tout, quitte à la revisiter des dizaines de fois par jour. Alors comment ils font les « référenceurs à l’ancienne » pour juger si Google apprécie ou pas une page ? Via des données indirectes et très peu fiables : ranking, nombre de visites organiques, performance SEO globales. Combien de fois vous êtes-vous acharné à optimiser une page, à enrichir son contenu sans retour sur investissement ? Si vous aviez regardé dans vos logs, vous auriez sans doute vu que le Googlebot ne fréquente cette page que très rarement, moins d’une fois par mois. Bref, il ne l’aime pas, et les stratégies pour booster cette page sont surement ailleurs.
Avec un peu de méthode, vous verrez que les données provenant des logs sont une aide formidable au décisionnel. En segmentant le site par thématiques ou typologies d’URLs, on arrive beaucoup plus facilement à discerner ce qui ne marche pas et à adopter des stratégies adéquates : qui n’a jamais hésité face à un groupe de pages aux stats faméliques entre suppression, redirection, optimisation, ou encore désindexation ?
A qui profite le plus l’analyse des logs ?
J’aimerai dire à n’importe quel site, mais c’est surtout un véritable levier sur les sites à forte volumétrie d’URLs. Vous pouvez toujours vous faire la main sur un blog de 30 pages, mais vous n’aurez pas beaucoup de latitudes pour influencer le comportement du Googlebot… et votre ranking.
C’est aussi un bon moyen d’apporter des POC aux clients
Ca on n’en parle jamais ;-) Pour un prestataire SEO, c’est toujours important d’appuyer ses recos avec des POC (Proof Of Concept). Demander à un éditeur de supprimer une rubrique intégralement sera certainement mal perçue si vous ne lui apportez pas de preuves du bien-fondé de votre stratégie. En lui montrant un tableau clair avec le volume important de pages inactives (pages n’ayant reçu aucune visite sur 30j par exemple), et un crawl rate 3 fois moindre que le reste du site qui prouve que Google n’aime pas cette partie du site, la pilule passera certainement mieux, car on s’appuie sur de la data fiable et difficilement contestable. Ca rend le SEO beaucoup moins conceptuel pour l’ensemble des parties !
L’optimisation du crawl est étroitement liée à l’optimisation de la distribution du « jus »
Si vous faites du SEO, sans doute avez-vous déjà entendu parler du PageRank sculpting, technique qui permet(ait) de canaliser la distribution du PageRank via le linking interne à l’aide de l’attribut nofollow. Cette technique ne marche plus pour le PageRank, mais reste toujours valable pour la distribution du crawl budget, et donc du jus. Si vous faite plus de liens vers une page qui en a besoin, ça profitera aux visiteurs, aux bots, et à la transmission de popularité (jus/PageRank).
L’étude des logs permet donc de repérer les ressources qui peuvent causer des déperditions de jus. Si dans vos logs (filtrés avec Googlebot) 30% des hits tombent sur des erreurs 404 ou 500, c’est 30% de crawl en moins sur les pages stratégiques ! Même chose avec les redirections à gogo, et autres « spider trap ». Aussi, même si Google crawl de plus en plus les fichiers JS/CSS pour faire des rendus graphiques, certains fichiers JS n’ont pas vraiment d’intérêt à être crawlés, et quand il y en a beaucoup et que le Googlebot s’obstine à les revisiter sans cesse, autant lui barrer la route.
Pourquoi se faire chier à faire le travail à la mano alors que des outils existent ?
Une notion importante à prendre en compte, c’est qu’un outil pour analyser les logs, n’est pas forcément un outil pensé pour le SEO à la base, et encore moins au recoupement de données.
Je vous donne un exemple bien concret : le passage du Googlebot est identifié par sa signature (user agent), mais ce user agent peut très bien être utilisé par d’autres outils/robots qui n’ont strictement rien à voir avec Google et qui de facto parasitent la data. Et ça arrive sur tous les sites que j’analyse ! Il est donc indispensable de faire du reverse DNS sur chaque IP attribuée au Googlebot, et les outils qui ne sont pas capables de le faire, autant dire que c’est de la m… enfin, vous ne pourrez jamais leur faire confiance.
Un autre exemple ciblé SEO : quand le Googlebot fait un hit sur une page B qui a pour URL canonique une page A, à qui attribuer le hit ? Haha ^^ personnellement, je préfère considérer les URLs canoniques. Mais ce choix implique un travail de recoupement qui peut s’avérer important sur certains projets. Et là aussi, si l’outil de traitement de logs n’est pas apte à prendre en charge les URLs canoniques, il peut (à mon sens) perdre énormément en précision.
Enfin, pour moi l’élément le plus lourd dans la balance, c’est l’agilité. En SEO, un outil spécialisé dans l’analyse des logs, si bon soit-il, ne procédera pas à du recoupement avec d’autres data (Google analytics, crawler SEO, votes sociaux, search console, SEMrush, Copyscape, etc), ou s’ils le font ça coûte un bras, et on n’a pas toujours ce que l’on veut.
Ça me défrise toujours un peu de voir des confrères SEO qui font ça complètement à la légère, ou pire, qui dépensent des sommes délirantes pour un service qui n’apporte aucune aide fiable à la décision. Faire le travail à la mano (comprendre avec un tableur et un peu de bon sens) permet de tirer des stats ultras pointues qu’aucun service ne vous donnera jamais !
Tenez, voici un exemple tiré d’un de mes audits :
Le tableau croisé dynamique ci-dessus montre la performance des différentes parties d’un site client. Les données tirées des logs (hits du Googlebot) arrivent en complément des autres indicateurs et permettent d’avoir une perception beaucoup plus fine des performances et des carences du site. Pour le coup, on voit que les pages appartenant à la branche « fiches techniques » sont à la peine, et la moyenne d’inlinks (liens entrants) montre un problème de linking interne évident. Au-delà des liens de cause à effet, on voit également les conséquences (corrélations) sur le référencement : plus le crawl rate baisse, plus le nombre de pages non indexées augmente. Le SEO Score (nombre de visites organiques / nombre d’URLs) a également une tendance baissière quand le crawl rate chute.
Le travail à la mano, s’il prend un peu plus de temps apporte beaucoup plus d’éclairage. Cela dit, rien n’empêche d’ajouter une couche d’automatisation à tout ça, ou mieux encore, développer ses propres outils !
« Crawl budget » : Votre site n’est pas Wikipedia. Google ne le traitera pas pareil.
L’énergie (et donc l’argent), c’est le talon d’Achille de Google. Ce n’est pas simple de s’en rendre compte, mais sachant que l’index Google contient plus de 47 billions de pages, imaginez s’il devait envoyer son Googlebot sur chaque page avec la même fréquence pour détecter les éventuels changements sur ces dernières, les ressources et la bande passante seraient colossales !
L’introduction de la mise à jour « Caffeine » en 2010, a apporté des changements structurels au moteur de recherche, permettant notamment de réaliser des économies d’énergie.
Et c’est à partir de là que l’on commence à parler de « crawl budget » ou encore de « crawl rank ». Pour faire simple, votre site se voit attribué un quota par Google, vraisemblablement indexé sur le PageRank, le volume, la thématique, la notoriété du site… bref vous avez compris, un lemonde.fr aura un crawl budget bien plus important qu’un Htitipi.com, logique. Concrètement, le nombre de pages crawlées à chaque visite du Googlebot est plafonné, autant ne pas faire de gaspillage !
Cette notion de crawl budget est hyper importante à capter pour le SEO !
Prenons un exemple ultra simple :
Votre site de 100 pages se voit affublé d’un crawl budget hypothétique de 100 (soit un bon ratio de 1). Supposons pour simplifier que cette valeur « 100 » corresponde à 100 passages du Googlebot en 24h. N’imaginez pas un seul instant que vos 100 pages seront crawlées dans la journée, non ! La fréquence du crawl (étroitement liée au PageRank) sera beaucoup plus importante sur la home, que sur les pages profondes, surtout si elles sont mal linkées et « froides ». Il y a donc une répartition du crawl, et c’est précisément ce qu’il faut optimiser !
Maintenant, imaginez un crawl budget de 100 sur un site de 1000 pages, soit un ratio dérisoire de 0,1. La conséquence se devine facilement : après analyse des logs sur une période de 30 jours environ, on décèlera des pages non fréquentées par le Googlebot… Et une page qui ne reçoit pas ou peu de visites du Googlebot n’a, en général, quasiment aucune chance de se positionner. Dans ce cas, il faudra des optimisations drastiques pour retrouver un ratio proche de 1. Et c’est dans ce genre de contexte que j’augmente considérablement le trafic de certains sites clients en éliminant purement et simplement la moitié (voir plus) des URLs de l’indexation.
« Less is more »
Le poison du SEO : les pages inutiles à l’indexation
Sachant que la fréquence du crawl dépend de tout ce que l’on a abordé jusqu’ici, et qu’il est très important de diriger au mieux les robots sur les bonnes pages, il y a tout intérêt à ne pas le nourrir avec des pages qui n’auraient aucun intérêt à être indexées ! La chasse aux pages inutiles devient donc une nécessité. Par exemple, cela peut être une page d’archive avec des news datant de 2008, les exemples ne manquent pas.
Chaque fois que vous barrez l’accès au Googlebot vers des pages inutiles, c’est du crawl en plus (et potentiellement des positions) pour les vraies pages destinées à ranker.
Latence et temps de chargement
Très sensible en matière de crawl rate, le temp de chargement des pages est un élément à ne surtout pas négliger, particulièrement sur les sites à forte volumétrie ou l’optimisation du crawl budget est une stratégie primordiale. Google va même jusqu’à dire qu’en divisant le temp de chargement des pages par deux, on augmente d’autant le crawl rate ! Pour y arriver, les leviers sont multiples (liste non exhaustive) :
- Épuration du code HTML, JS et CSS,
- Utilisation de CDN (Content Delivery Network),
- Mise en place de systems de cache : inutile de recalculer une page déjà affichée antérieurement (avec toutes les requêtes MySQL qui ralentissent l’affichage),
- Passer à une offre d’hébergement plus qualitative…
Des outils comme Dareboost (payant) ou PageSpeed de Google peuvent être d’une bonne utilité pour diagnostiquer les éléments ralentissants.
Gare à la pagination, la navigation à facettes, et les paramètres d’URLs !
C’est souvent un vrai cauchemar pour le SEO, et particulièrement quand il s’agit d’optimiser le crawl du Googlebot.
La pagination : il est impératif de laisser les bots naviguer dans la pagination si les pages contiennent des liens vers d’autres pages destinées à se positionner (les pages de catégorie par exemple). Mais au-delà de la première page, le crawl rate chute sévèrement. Je suis partisan de la solution hybride qui consiste à mettre une page monolithique « voir tout » accessible à la fois par les visiteurs et les robots d’indexation, et de préférence en version pré-calculée et statique ! Quand il y a 256000 produits à afficher, ce n’est pas la même histoire !
NB : une page « voir tout » accessible à tous, ne fait pas forcément doublon avec un sitemap XML. Ce dernier favorise la découverte des pages, mais n’influence pas vraiment le crawl rate.
La navigation à facette : autant cela peut représenter de véritables opportunités en SEO, autant ça devient vite une plaie si c’est mal réalisé. Cela explose littéralement le volume d’URLs, et si l’on ne fait pas gaffe, on créer rapidement un « index blow » avec tout ce qu’il y a de plus mauvais en SEO : DUST (Duplicate URL Same Text), duplication de contenu, pages vides, pages inutiles à l’indexation et j’en passe. Il faut méticuleusement désigner les URLs qui doivent être indexables et celles à désindexer, quitte à mettre en noindex toutes les URLs générées par la navigation à facettes dès le départ et ouvrir à l’indexation au cas par cas. Ensuite on rajoute une couche de directives disallow dans le robots.txt pour optimiser le crawl. Il y a de quoi faire un gros pavé sur le sujet !
La confusion ultra répandue en SEO : disallow, nofollow et noindex
Honnêtement, à part quelques SEO patentés, tout le monde se vautre sur l’arbitrage entre ces 3 notions. Ce sont 3 directives différentes, parfois cumulables, et aux conséquences différentes. Alors pour clarifier :
- Disallow : on retrouve cette directive dans le robots.txt. Elle suggère aux robots d’indexation (dont le Googlebot) de ne pas crawler telle ou telle ressource. Par exemple Disallow: /page-inutile.html suggère au Googlebot de ne pas fureter sur cette URL. Ce n’est en aucun cas une directive qui demande explicitement la désindexation de cette dernière !
- Noindex : là par contre on indique explicitement aux moteurs de ne pas indexer (ou désindexer) la page. On retrouve cette directive dans les balises d’entête HTML , ou HTTP avec X-Robots-Tag. A contrario, noindex n’indique aucunement aux moteurs de ne pas crawler la page !
- Nofollow : cet attribut puise sa source dans la lutte contre le spam. Il provoque un double effet quand il est associé à un lien : Google(bot) ne le suit pas (sauf cas exceptionnel), et aucune valeur SEO (PageRank) n’est transmise à la page cible. Personnellement, je ne l’utilise pas trop dans l’optimisation du crawl du Googlebot car peu adapté pour ça.
Et je vois très souvent des cumuls totalement foireux ! Exemple récurent : pour désindexer une page, on ajoute une balise <meta robots="noindex, nofollow"> dans la page, et pour enfoncer le clou, on ajoute un disallow: /page.html dans le robots.txt. Pas bien !
Le disallow va empêcher le robot d’accéder à la page (à désindexer)… Comment voulez-vous qu’il découvre la directive noindex qu’elle contient ? Je ne dis pas qu’elle ne sera pas désindexée à un moment ou à un autre, mais ça prendra plus de temps. Vient ensuite l’association ultra répandue (la faute aux CMS) du noindex et nofollow. Si on ne souhaite pas voir une page de catégorie dans l’index de Google c’est tout à fait normal de la mettre en noindex. Par contre un nofollow peut avoir des effets dévastateurs, car les pages liées à cette catégorie ne seront probablement pas découvertes par les robots, provoquant de sérieux problèmes d’indexation. Bref, faites preuve de discernement !
Appliquer les bonnes stratégies
Rechercher avec obsession un crawl rate satisfaisant et constant sur chaque page serait une hérésie, particulièrement sur les projets de grande envergure. Il est beaucoup plus judicieux de concentrer ses efforts sur les pages stratégiques (pour le positionnement), que pour les pages de moindre importance. L’étude de l’appétence du Googlebot doit donc s’accompagner d’un repérage des pages les plus importantes pour prioriser les actions à mettre en place. Personnellement, je vais même jusqu’à attribuer une note d’importance à chaque URL pour mieux prioriser les taches, et mettre en place des KPI.
L’appétence du Googlebot n’est pas uniquement liée au linking. Je remarque souvent que le Googlebot peut diminuer son crawl sur les pages d’une catégorie si cette dernière est un peu distante du cœur de cible du site. Autrement dit, si un groupe de pages ne génère pas beaucoup d’affichages (tous segments confondus), il est probable que le crawl rate soit plus bas que d’autres groupes de pages plus visités. Sans aller chercher quels pourraient être les liens de cause à effet, soyez bien conscient qu’il n’y a pas que les facteurs techniques (niveaux de profondeur et linking) qui peuvent influencer le Googlebot. Le contenu, le comportement utilisateur, la thématique et même le marketing sont des éléments influents à prendre en considération. D’ailleurs dans mes audits, comme vous pouvez le voir dans le tableau plus haut, je compare toujours la fréquence du Googlebot avec le nombre d’entrées organiques ET celles générées par les autres segments.
Les stratégies à appliquer sont donc multiples et tout doit être étudié au cas par cas. Voici quelques exemples :
- Une URL a un crawl rate élevé, mais génère peu d’entrées organiques : on peut penser à un problème de contenu, surtout sur les éléments importants comme la balise title, ou alors la page n’est pas du tout destinée à se positionner. Dans ce cas, il serait plus judicieux de mettre un nofollow sur l’ensemble des liens pointant vers elle histoire de ne pas gaspiller son crawl budget inutilement.
- Un groupe de pages (thématique) performe moins que les autres : cela peut arriver si cette rubrique/thématique est complémentaire. C’est donc normal que le crawl rate soit moins élevé. Dans le cas contraire, il faut augmenter les signaux pour booster les passages du Googlebot (plus de liens, mise en avant des articles, partages sociaux, etc).
- Autre exemple avec un groupe de page qui performe moins que les autres : le DUST, l’absence de canonicals, et un socle technique défaillant. Ca arrive souvent, et c’est une véritable plaie pour l’optimisation du crawl, et le SEO en général.
- Une landing page en niveau 2 est crawlée moins d’une fois par mois : si tous les éléments fondamentaux sont bons (title, contenu, liens) alors on peut envisager le changement d’URL avec pourquoi pas quelques retouches au contenu histoire de faire un « reset » de la page.
Période de temps optimale à analyser / récupérer
2 à 3 mois d’écritures, ça offre pas mal de recul et une bonne appréciation des URLs aimées ou mal-aimées de Google. Cela peut être casse-gueule de prendre une plage plus longue, particulièrement si le site change beaucoup (mise à jour techniques, contenu, migrations etc).
Sur ce point, je rencontre 2 difficultés avec mes clients :
- les sites de grande envergure avec une fréquence de crawl élevée génèrent après filtrage des fichiers toujours très lourds. (voir par ailleurs au chapitre « Les limites techniques »)
- Autre problème rencontré, toujours avec les « gros » sites, c’est la suppression automatique et incrémentale des archives de logrotate, empêchant de remonter sur une période de temps suffisante. Là, il n’y a pas d’autres solutions que de modifier les paramètres, et d’attendre.
Je vous recommande de calquer votre période d’analyse avec celle de Google analytics. Par exemple, si vous récoltez 2 mois de logs correspondant à octobre et novembre 2015, il faudra également récupérer la même période correspondant aux entrées organiques sur GA. Tout ça pour effectuer des recoupements précis, et faire du SEO « chirurgical ».
Seuil critique : à partir de quelle fréquence doit-on considérer qu’une page est « pagina non grata » ?
Il n’y a aucune règle, ou plutôt, il y a une règle pour chaque site. Un site avec beaucoup de pages très techniques dans une thématique faiblement concurrentielle aura sans doute des crawl rates sur des landing pages bien inférieurs à 1/30 jours, pour autant, la page se positionne très bien sûr le mot clé ciblé.
Dans un secteur plus concurrentiel avec un site de petite/moyenne envergure (comprendre moins de 100 000 pages), si une landing page possède un crawl rate inférieure à 1/20 jours et que le mot clé visé est mal positionné, alors un travail d’optimisation sera nécessaire, voir changer d’URL. La clairvoyance du prestataire SEO consiste justement à trancher entre optimisation, suppression, ou changement d’URL en fonction des situations.
Les limites techniques
Je vous mentirais si je vous disais que l’épluchage des logs est un jeu d’enfant sur 100% des projets. On se retrouve parfois avec des trous dans les logs à cause de migrations foireuses, des fichiers logs morcelés a cause de load balancing (il faut alors concaténer), les formats exotiques, les sys admin qui ne répondent pas…
Une des limites techniques majeures que l’on peut rencontrer avec ce process, c’est le volume de données brassé. On a vite fait de jongler avec plusieurs millions de lignes pour peu que l’analyse soit basée sur une période de plusieurs mois d’écritures. Là, les services Saas comme Botify ou le très jeune kelo.gs vous éviteront de mettre à genoux votre poste de travail. Personnellement, je me répète, ça m’ennuie un peu de m’orienter vers ces solutions, car je sors de ma zone de confort : si je gagne en performance machine d’un côté, je perds en agilité de l’autre… sans parler des coûts.
D’autres alternatives existes, pour gérer des logs « big data ». Il y a par exemple des outils orientés « business intelligence » comme Qlikview et Qlik Sense (merci @jeanbenoit) qui peuvent remplacer Excel et avaler plus de data, mais également le concurrent Tableau qui est un formidable outil de statistiques. Mais là aussi il ne faut pas avoir d’oursins dans les poches.
Cela dit, ne paniquez pas, 95% du temps un Excel fera largement l’affaire (n’en déplaise aux trolls), à condition de ne pas brasser des données inutiles (robots autres que Googlebot par exemple).
Pour finir… mais il y aurait encore beaucoup à dire !
Les logs permettent d’avoir une vision la plus proche de celle des moteurs, et en SEO ce n’est pas rien ! Ça me semble tellement indispensable que ce n’est plus une option dans mes prestations. Le PageRank, indicateur souverain hier, peut aujourd’hui être remplacé par l’appétence du Googlebot (à défaut de connaître un hypothétique crawl rank).
– Si vous n’avez pas de problème avec la langue de Shakespeare, Builtvisible a publié un très bon guide sur l’analyse des logs il y a quelques mois. Lisez également « Crawl optimization » de blindfiveyearold.com. Avec ces articles, vous aurez un bon complément pour analyser votre site aux petits oignons.
– Je vous recommande également de suivre Jean Benoit Moingt qui est devenu une référence dans ce domaine, avec sa solution Watussi déjà évoquée plus haut.
– A suivre également l’évolution du crawler Screaming Frog, qui prépare une version croisant logs et web crawl.
Hello Aurélien,
Je suis en grande partie de ton point de vue. A quelques petits détails près :-)
Pour moi, mettre les mains dans le cambouis à coups de grep ou de awk est très utile, notamment pour comprendre les concepts derrière l’analyse de logs, et à quoi peuvent correspondre tels ou tels indicateurs.
Cela dit, automatiser des traitements répétitifs permet quand même de gagner pas mal de temps, notamment sur de gros volumes. Les outils du marché permettent d’aller vite sur pas mal d’analyses, mais ça n’est pas toujours suffisant. Pour ma part j’utilise ELK en phase d’audit, un outil qui convient aussi pour du monitoring d’ailleurs. Ca me permet de déployer rapidement mes analyses « standard », mais aussi d’aller dans le détail et de croiser toutes sortes de données si besoin. Une souplesse que ne proposent pas les outils du marché pour l’instant.
Pour finir, petit conseil pour ceux qui opteraient pour un outil comme Kelo.gs ou OnCrawl : faites attention à bien comprendre à quoi correspondent les KPI, car chacun a son vocabulaire.
Botify agit en 2 parties :
– le monitoring
– le crawl
et les dashboard qui mixent les 2 infos sont vraiment intéressants.
Si on ajoute la possibilité de faire la catégorisation des pages, ca donne vraiment de bons indicateurs.
Pour extraire des informations, Botify Log Analyzer n’est pas très souple. Il n’y a pas les Explorer qu’on peut avoir dans Botify Analytics…mais ca va peut être évoluer.
Très bon article, comme d’habitude. Je suis justement en train de préparer un article aussi sur le sujet. L’objectif chez nous est de créer bientôt un analyseur sur mesure qui s’adapte facilement à toutes les situations. J’ai bien pris note du reverse DNS que je ne voulais pas faire, mais je crois qu’on va être obligé du coup. ;)
@Diije : les « petits détails près » abondent aussi dans mon sens :p
@Alexandre Santoni : a défaut de faire du reverse DNS qui est gourmand en temps, tu peux également filtrer les IP qui correspondent au bloc 66.249.*.* et qui représentent 95% (ça peut varier) des IP réelles du Googlebot. Mais c’est un quick fix foireux qui peut changer dans le temps, on perd 5% des hits, et il ne faut surtout pas appliquer cette technique pour faire du cloaking !
Bonjour et merci pour le pavé. Tu ne parles pas des documents autres que les pages web, je pense aux fichiers pdf notamment. J’aurais aimé avoir ton avis là dessus, est-ce que tu empêches Googlebot de les crawler sachant qu’ils peuvent contenir des liens ?
Big up pour l’approche à l’ancienne, dans le style maitre artisan du data. C’est très précis pour des petits sites car monitorer en temps réel permet une analyse et une optimisation rapide des performances. Pour des gros sites e-commerce (avec méga-menu et navigation à facettes), il est nécessaire d’adopter une autre façon de procéder, plus industrielle.
PS : good job sur la refonte du logo et du site, c’est plus pro et ergonomique.
@Julien Darribau : Les PDF, c’est comme les pages HTML : tout dépend si tu veux les indexer ou pas, si ils font du duplicate, si ils ont un intérêt à être indexés… Bref, c’est la même chose.
ps : lien supprimé ;)
Salut Aurélien
Ah content de te lire à nouveau !! Cet excellent billet me rapelle une discussion ;o)
A bientôt
Toujours aussi pertinent et précis. Ce que j’aime dans ton article, outre l’aspect mise en place technique c’est le partage des solutions par rapport à des problèmes précis.
On analyse les données mais il faut ensuite savoir quoi faire avec et là les cas de figure sont si différent les uns des autres que c’est souvent l’expérience qui fait la différence. C’est pour cela que c’est intéressant d’avoir des retours d’expériences ou d’échanger sur telles ou telles stratégies à mettre en place en fonction du problème rencontré.
Pour ma part, je suis un peu comme toi, j’aime bien analyser moi même les logs car je préfère avant tout connaitre les datas, savoir à quoi elles correspondent pour mieux en tiré partie.
Mais par contre je trouve que ces solutions SAAS sont très pratique pour faire le premier tri dans les logs et ressortir uniquement les hit des bots Google surtout pour les personnes ne souhaitant pas le faire eux-même.
Tu donne tes logs brut à ces outils qui te ressortent uniquement les données dont tu as besoin : la date, l’url, le bot, le statut http, le nbre de hit… Tu n’a plus qu’à les récupérer pour faire tes analyses toi même dans excel.
D’ailleurs je ne sais pas si un outil comme ça existe. Un outil qui permettrait via un fichier de logs de faire ressortir uniquement les datas brut qu’on veux (via regex par exemple) pour ensuite les analyser nous même.
PS : toujours pas de possibilité de s’abonner aux commentaires. Dommage ;)
@Dadoo : ;-) Je n’oublis pas non plus ce que je t’avais proposésur les logs, et je reviendrai vers toi rapidement pour quelque chose de plus « concret » ;) Stay tuned !
@Michael : Merci pour ton commentaire !
>Pour ma part, je suis un peu comme toi, j’aime bien analyser moi même les logs car je préfère avant tout connaitre les datas, savoir à quoi elles correspondent pour mieux en tiré partie.
Oui exactement ! Faire la tembouille sois-même aide énormément à mieux comprendre les data ! Et pas besoin d’être un dev pour ça.
> Mais par contre je trouve que ces solutions SAAS sont très pratique pour faire le premier tri dans les logs et ressortir uniquement les hit des bots Google surtout pour les personnes ne souhaitant pas le faire eux-même.
Pas d’accord du tout !
$ cat domaine-access_log | grep -i googlebot > domaine-access_log.googlebot
Et bim, tout est filtré en une ligne ! Moi je ne lâche pas des centaines d’euros pour si peu !
Plus d’infos ici : https://goo.gl/29RVTe
> Tu donne tes logs brut à ces outils qui te ressortent uniquement les données dont tu as besoin : la date, l’url, le bot, le statut http, le nbre de hit… Tu n’a plus qu’à les récupérer pour faire tes analyses toi même dans excel.
http://www.apacheviewer.com/ ;-)
> PS : toujours pas de possibilité de s’abonner aux commentaires. Dommage ;)
J’ai mis le plugin il y a de ça quelques temps, puis je l’ai retiré suis à des soucis…
Un truc qui me turlupine avec la directive NoIndex. Comme tu l’indique le NoIndex implique que la page ne sera pas indexée (ou sera désindexée) mais GoogleBot analyse (crawl) cette page afin de trouver les liens. Pour les liens trouvés (qui ne sont pas NoFollow) le « jus » du PR de la page NoIndex sera t’il propagé sur les pages cibles ? Quelle est la finalité d’avoir une page NoIndex et d’avoir des liens (pages cibles) à partir de cette page ? N’avons nous pas pour Google un signal « bizarre » indiquant de ne pas indexer une page mais cependant d’indexer des pages cibles à partir de celle-ci ?
Autre point, retour d’expérience, que je note lors de mes crawls. Je retrouve un nombre impressionnant de pages cibles à partir de pages qui sont « Disallow ». En effet je note que bien souvent on a un « Disallow » sur une sous arborescence. Les impacts ne sont pas négligeables, on les remarque lors de la génération du graphe (Sylvain D. en parlera au TekNSeo 2016 (buz) :) )
A ne pas oublier aussi dans la confusion l’utilisation de la directive « Canonical ». Impressionnant les erreurs que l’on peut noter sur son utilisation.
@LeMoussel :
> le « jus » du PR de la page NoIndex sera t’il propagé sur les pages cibles ?
Pour moi oui.
> Quelle est la finalité d’avoir une page NoIndex et d’avoir des liens (pages cibles) à partir de cette page ? N’avons nous pas pour Google un signal « bizarre » indiquant de ne pas indexer une page mais cependant d’indexer des pages cibles à partir de celle-ci ?
Non je ne trouve pas le signal bizzare… Le noindex n’est pas là pour le crawl, mais juste pour l’indexation. Si la page contient du DC, ou un contenu trop maigre, on choisira logiquement noindex, alors que le noindex, nofollow, n’aurait pas de sens.
> A ne pas oublier aussi dans la confusion l’utilisation de la directive « Canonical ». Impressionnant les erreurs que l’on peut noter sur son utilisation.
Oui certains ont un peu de mal à capter le concept ;)
@Aurélien : Merci pour les informations sur les IP. Effectivement, ça peut le faire. Je me pose aussi la question au niveau des sites qui passent par des services DNS comme Cloudflare, j’ai un gros doute sur l’IP qui est renvoyé du coup. Il faut que je vérifie.
@Aurelien :
« Pas d’accord du tout !
$ cat domaine-access_log | grep -i googlebot > domaine-access_log.googlebot
Et bim, tout est filtré en une ligne ! Moi je ne lâche pas des centaines d’euros pour si peu ! »
Qui a dit qu’il fallait lâcher des sous, ces outils ont un essai gratuit ;) et puis le montant de leur abo ne correspond pas qu’au filtrage des logs heureusement.
Merci pour l’outil je vais checker ça ;)
J’ai une question en terme de Near Duplicate sur des fiches produits e-commerce. La plupart de mes clients choisissent de créer des fiches produits unique plutôt que des déclinaisons. Du coup, ils ont régulièrement des fiches produits dont le contenu est à 80% le même car c’est le même produit mais avec des formats ou taille différentes. Généralement je préconise de fusionner ces fiches en une seule en mettant des déclinaisons et rediriger en 301 les fiches produits supprimées vers la nouvelle.
Mais je m’aperçois que le crawl sur ces nouvelles fiches n’est pas mieux que quand les produits étaient séparées.
Le crawl n’augmente pas pour les autres partie du site donc je pense que le budget de crawl n’augmente pas.
J’ai fait cela pour des centaines de fiches produits dont il y a eu potentiellement au moins 3 fois plus de page produits produits supprimés. Les redirections ont bien été prises en compte donc normalement le crawl sur ces fiches produits fusionnées devrait augmenter, non ?
@Alexandre Santoni : Je ne peux pas trop t’aider avec Cloudflare, je manque de recul.
@Michael : La 301 est déjà pas optimale en terme de transmission de jus, et pour le crawl des bots, je pense que ce n’est pas mieux. Essaye donc (à petite échelle) avec une autre rustine : le rel canonical. Dans ton cas ça me semble plus approprié.
Quel bel article ! merci ! pour m’être pencher un peu sur l’analyse de logs, je tiens à préciser, que ça ne sert clairement pas beaucoup sur des sites sur lesquels il y a peu de contenu ( < 1000 pages) ou du nouveau de façon quotidienne. A moins que vous aillez des retours d'expériences positives et constructives sur des "petits" sites ?
@Luc : on peut faire de l’analyse de logs avec des petits sites. C’est moins probant certes, mais c’est faisable, en particulier si les sites sont segmentés avec des thématiques/sections distinctes (cf siloing).
@aurélien : oui bien sur que c’est faisable :) je suis par contre septique/interrogatif sur ce que ça apporte réellement. (ouh la belle faute que j’ai fait plus haut :) )
@Luc : tu mets le doigt sur un point intéressant en fait ^^ L’analyse des logs n’est pas QUE dans un but d’optimisation. Ca peut être juste pour évaluer comment Google apprécie nos pages, et donc les différentes thématiques. Sur un site de 500 pages par exemple, rien n’empêche d’avoir 4 ou 5 thématiques différentes, et de tirer des stats. Si une thématique performe moins qu’une autre au niveau du trafic, et que l’on se rend compte qu’elle est également moins crawlée, on sait à quoi s’en tenir ! Et je te rejoint sur le fait que les latitudes d’optimisation sont faibles sur les petits sites.
@Aurélien : Je suis d’accord avec toi pour les effets de la 301 sur la transmission de jus et le crawl Google mais si je supprime des fiches produits pour les regrouper je suis bien obliger de faire une redirection je vais pas les laisser en 404.
Si je met une canonical cela veux dire que je ne regroupe plus les produits et dans ce cas cela sera difficile de choisir le produit qui sera inclut dans la canonical : les tendances de visites des produits déclinés sont à peu près les mêmes, idem pour le CA généré. Là je ne parle pas de de quelque dizaines de produit mais des centaines.
Du coup je ne vois pas trop de solution à ce problème à part optimiser encore plus le maillage interne vers ces fiches produits regroupant toutes leurs déclinaisons.
Merci pour cet article comme toujours très interessant. J’avais deja étudié les ressources que tu donnes a la fin mais certains aspects que tu donnes n’y etaient pas et vont completer a merveille ma base de connaissance. Super aussi ton arbre de decision. J’attends du coup avec impatience l’evolution de screaming frog.
@Bruno : Fanx amigo :) Comme je le disais à @Dadoo (David) plus haut, je tiens vraiment a ce qu’on se fasse une session log ensemble sous forme de webinar plus technique et concret. Je dois préparer ça un minimum, et je vous contacterai le moment voulu. Après peut-être que je diffuserai ce webinar, tout est possible ^^
Salut,
Bon article :)
Par contre tu ne fais pas mention d’un point qui est essentiel sur la fréquence des crawls : le temps de chargement de page.
C’est le genre de truc qu’on ne peut voir qu’avec un monitoring serré des logs et une approche un peu holistique. Perso j’ai la chance d’étudier très régulièrement le avant/après avec des sites lents qui réduisent leur temps de chargement par 2 voire 4 ou plus, ce qui m’a permis de constater l’impact du temps d’affichage de manière concrète pour le SEO.
Il y a de nombreuses hypothèses, mais je ne te livrerai que 2 certitudes :
– L’augmentation de fréquence des crawls de googlebot est proportionnelle à la diminution du « temps de téléchargement d’une page » (je reprends ici la terminologie de webmastertools dans les statistiques d’exploration). En gros un site qui s’affiche deux fois plus vite voit son crawl boosté par 2.
Et c’est échelle basse ! J’ai pu constater par exemple pour un site qui est passé de 7sec à 1 sec, une augmentation de la fréquence de crawls journaliers d’une petite centaine à plus de 2000/j puis 4000/j (ce qui correspond à la taille du site).
– Un site au delà des 5sec d’affichage n’a aucune chance d’être positionné en top 3, au délà de 7 secondes c’est la 1ere page de résultats qui lui est interdite (sauf recherche sur ndd).
Je précise que ces datas ne concernent que des sites qui ont un trafic relativement important, et qui jouent dans des cours concurrentielles.
– Pour le 1er cas de figure (boost de l’indexation provoqué par le boost de rapidité du site), je pense que c’est justement parce que gg voit que le site est à la peine qu’il « l’épargne » afin de ne pas le saturer. Par contre quand il voit que ca dépote derrière, il envoie la sauce.
– Pour le second cas de figure, il est possible qu’un bon temps d’affichage joue sur le ranking, mais ça doit être vraiment léger. Par contre il est certain qu’un mauvais temps d’affichage est pénalisant…
En conclusion, trustrank, PR sculpting ou rafraîchissement régulier du contenu sont de bons indicateurs, mais dans la compréhesion des crawls de l’ami google, le facteur de performance d’affichage n’est pas à négliger ;)
A te lire !
Jeffer
@Jeffer : Merci pour ta contribution ;) Tu as 200% raison sur le temps de chargement ! J’ai complètement fais l’impasse là dessus, sans doute trop focalisé sur le « comment », et moins le « pourquoi », mais je ne cherche pas d’excuse :p Je rajouterai un paragraphe là dessus à l’occasion (edit : ajouté !), car c’est vraiment un élément déterminant dans l’analyse des logs. Fanx ;)
Salut Aurélien,
Question de l’autre coté du miroir ^^ Cela arrive t’il souvent que tes clients ne puissent pas accéder à leur logs ? Dans le cas de CMS pro, solutions SAAS, serveur vérouillé etc…
Du reste, je trouve qu’une analyse de logs est particulièrement pertinente dans le cadre d’une migration de site, qu’en penses tu ?
@SylvainV : J’ai eu des cas ou les clients n’arrivaient pas à accéder à leurs logs… mais a vrai dire, ils ne cherchaient pas trop à mon avis ;) Normalement tout le monde doit y avoir accès. J’en profite pour preciser qu’un hébergement mutualisé ne doit pas empêcher d’avoir accès aux logs !
Pour les migrations c’est bien évidement très intéressant, ne serait-ce que pour évaluer à quel moment on arrive à un crawl budget équivalent. Encore faut il avoir les éléments nécessaires pour faire la dif, souvent on arrive après la bataille, et les anciens fichiers logs ont été dégagés !
Bon article et très bien expliqué comme d’habitude.
Quelques questions dans le traitement de la data :
* comment catégorises tu en masse tes urls ?
* comment gères-tu l’extraction des différents champs dans les logs (user agent, timestamp, etc..)
Pour grep je conseillerais plutôt :
* grep -F « Googlebot » my_file
que :
* cat my_file | grep -i « googlebot »
Le « vrai » googlebot a une majuscule dans sa chaîne, donc pas la peine de faire une recherche case insensitive. Le cat est inutile puisque tu peux greper directement dans un fichier et le -F chercher en pattern fixe.. Beauuuuucoup plus rapide :)
Merci encore en tout cas!
Aurélien ton article est pertinent et détaillé ! Merci et bravo ! :D
A bientôt,
Pierre
Top article! Je dois avouer que je suis encore un noob dans le domaine des logs et ton article m’a bien introduit à la chose :) J’ai téléchargé Watussi report à l’instant. Jean-Benoît MOINGT parle dans son explication du tool de linkexaminer, quelqu’un a déjà essayé son tool avec un rapport complet de screming frog?
Merci
Bonne journée
Teddy
Bonjour Aurélien,
Merci pour ton super article sur l’analyse des logs. Je ne sais pas quel service utiliser pour l’analyse de mes logs. Que penses-tu de https://www.screamingfrog.co.uk/log-file-analyser/ ou il vaut mieux un http://kelo.gs/ ou watussi ?
D’ailleurs ton arbre de décision est super utile. Ca serait intéressant d’en faire un pour le cocon sémantique après une analyse sur cocon.se par exemple.
Bonne journée
@Guillaume : Normalement mon article devrait répondre en partie à tes questions ;)
Salut Aurélien,
article au top ! Bravo.
Une question concernant un exemple précis que tu donnes : « La chasse aux pages inutiles devient donc une nécessité. Par exemple, cela peut être une page d’archive avec des news datant de 2008, les exemples ne manquent pas. »
Sur ce genre de contenu (qui n’est plus d’actualité donc, potentiellement n’est plus lu et n’est plus crawlé par Google) que fais-tu ? tu supprimes et rediriges (301), tu laisses en ligne mais empêche le crawl ? désindexe ? …
merci
@Vincent : c’est du cas par cas. Mais en général dans ce cas de figure, je place un disallow dans robots.txt couplé à du noindex.