Résoudre les problèmes de crawl avant l’analyse de logs
Il y a quelques jours, j'ai eu un échange concernant l'analyse de logs avec un client qui m'a donné envie d'écrire ce billet.
Il se demandait pourquoi on réglait des problèmes de crawl avant d'analyser les logs et pourquoi on ne le faisait pas en même temps.
(Oui je fais dans l'humour aussi)
Je commence toujours par régler la majorité des problèmes de crawl avant d'envisager d'analyser les logs.
Voici les principales raisons :
- Cela permet d'épurer les fichiers de pas mal d'erreurs, facilitera et accélérera l'analyse
- C'est beaucoup plus simple
- Les crawlers gratuits (ou payants) sont nombreux
- Obtenir des logs peut prendre 12 mois sur certains projets
- De nombreux problèmes sont visibles à la fois via le crawl et les logs
- Il est facile de réaliser plusieurs crawls alors qu'obtenir plusieurs exports des logs...
- Il n'y a rien à demander au client
- Le client n'a pas à payer un autre prestataire (extraction de logs+parsing des bots+gestion de projet)
- Obtenir des logs exploitables peut demander parfois de nombreux échanges (coûts gestion de projet + optimisations déployées plus tardivement)
- Maintenance & Recette : Quand les dépôts de logs sont récurrents et automatisés, des bugs pourront arriver et arriveront... (#truestory)
En guise d'illustration, voici 3 exemples.
- Pages en 404 (hors page orpheline : - )
- Spidertrap ! (hum les facettes)
- Liens internes pointant vers des redirections (hors redirections serveur non maillées)
En SEO, comme dans d'autres domaines, il faut parfois savoir identifier, se concentrer et prioriser les actions ayant le plus de valeur à court terme.
Dans tous les cas, vous l'aurez compris, ces 2 taches sont aussi complémentaires.
