Rappelons pour ceux qui débarqueraient dans le SEO, l’utilité d’un crawler : c’est un programme (service en ligne, ou encore « bot ») à qui l’on demande de parcourir un site de lien en lien pour en récolter toutes les données exploitables en SEO (title, meta, taille, nombre de liens sortants, profondeur etc). Il en existe pléthore, du gratuit au service « all inclusive » où il est préférable de ne pas avoir d’oursins dans les poches. Quoi qu’il en soit, un crawler est incontournable si l’on souhaite analyser un site.
Côté techno et pricing, on distingue 2 axes :
- Les solutions desktop, qui sont des applications traditionnelles que l’on installe sur son poste de travail (Screaming Frog en fait partie),
- les solutions en ligne, que l’on qualifie parfois de solutions en « cloud » ou « Saas » (Software as a service).
Screaming Frog SEO Spider est certainement la star des crawlers « desktop ». Fait par un SEO pour les SEO, il est très populaire dans la communauté grâce notamment à son rapport qualité/prix inégalé.
95% du temps (ce chiffre peut varier d’un prestataire/projet à l’autre), Screaming Frog « avalera » n’importe quel site… mais quand on lui donne un gros projet, comprendre plus de 100 000 URLs, le crawler se retrouve rapidement avec les dents du fond qui baignent : interruption du crawl, ralentissements, plantages, RAM saturée sont les effets les plus notoires. Contrairement aux crawlers Saas, Screaming Frog est tributaire des performances de votre machine. Il n’est pas « scalable ». Et le pire reste sans doute le traitement des données par la suite, sur Excel par exemple, où la moindre opération peut prendre des plombes. De fait, la première chose à vérifier sur Screaming Frog, c’est que l’option « Pause On High Memory Usage » soit bien cochée (c’est le cas par défaut), histoire de sauvegarder et reprendre le crawl après.
Mais vous verrez, les solutions pour repousser les limites ne manquent pas ! L’objectif de ce billet est double : limiter la consommation de ressources par Screaming Frog, et surtout alléger l’export des data pour les « faire parler » ensuite sur Excel (ou autre tableur).
La RAM : plus il y en a mieux c’est !
Plus l’envergure du site à crawler est grande, plus il faudra de RAM pour stocker les données. Si vous faites tourner Screaming Frog sur un ordinateur portable avec moins de 4Go de RAM, votre crawl s’interrompra probablement aux alentours des 40 000 URLs. Si votre machine a plus de 4Go de RAM, il sera nécessaire de faire un peu de tuning, mais rassurez-vous, c’est très simple.
64 bits sinon rien
Pour exploiter plus de 4Go de RAM, votre environnement doit être impérativement « full 64 bits ». Concrètement, votre système d’exploitation (Windows surtout) doit être en version 64 bits. Mais ce n’est pas tout, Screaming Frog devra également tourner avec une version des runtimes Java en 64 bits si vous voulez que votre crawler préféré ne reste pas anorexique ! N’ayez crainte, sur Windows, une installation 64 bits peut très bien cohabiter avec une version 32 bits. Mais pour exploiter au mieux votre mémoire vive, il reste une dernière bidouille à faire…
Configuration du fichier ScreamingFrogSEOSpider.l4j.ini
Il faut maintenant paramétrer Screaming Frog pour définir la mémoire allouée. Dans le répertoire d’installation, éditez le fichier ScreamingFrogSEOSpider.l4j.ini : si vous avez par exemple 16Go de RAM, mettez -Xmx12g histoire de ne pas asphyxier votre système d’exploitation. Attention, par défaut la valeur de base est fixée au raz des pâquerettes, soit 512mo de RAM !
Maintenant que vos slots de mémoire sont exploités à toc et la RAM paramétrée aux petits oignons, il reste encore plein de leviers pour décupler la capacité de Screaming Frog et en faire un goinfre à data. Vous pourrez même envisager des sites avoisinant le million d’URLs ! Il faut maintenant paramétrer finement SF.
Filtrer les URLs utiles et inutiles
Ressources inutiles
Une URL ne désigne pas forcément une page HTML ;-) Je veux dire par là que toute autre ressource telle que les fichiers javascript, image, css etc, n’ont pas un grand intérêt SEO. De fait, si on cherche à économiser de la RAM, autant éviter de charger le bouzin avec des URLs superflues ! Mais ne vous trompez pas : Il ne suffit pas de décocher tout ce qui n’est pas intéressant pour le SEO (img, js, css etc) dans Configuration > Spider > Basic, car Screaming Frog gardera tout de même les URLs de ces ressources. Pour bien faire, il faut crééer une règle d’exclusion comme suit :
Dans le menu Configuartion > Exlude, ajouter les lignes suivantes (à adapter au besoin) :
.*.jpg.*
.*.jpeg.*
.*.png.*
.*.gif.*
.*.css.*
.*.js.*
.*.zip.*
Si vous êtes habitués aux expressions régulières, vous remarquerez que je n’ai pas choisi le format .*jpg$ car parfois les URLs « image » se voient affublées de paramètres, comme on peut le voir avec WordPress par exemple.
Je vous recommande quand même de lancer un premier crawl partiel, genre 10 ou 20%, sans aucune exclusion, pour voir les ressources appelées. On trouve parfois des scripts pour afficher des images comme par exemple photo.php?id=xxx, qui n’ont pas d’intérêt pour une éventuelle analyse. Dans ce cas, il faut ajouter une règle d’exclusion dans Configuration > Exclude avec (par exemple) .*photo.php.*.
Ignorer les pages en noindex
On peut également sacrifier les pages en noindex, via le menu configuration > Spider > Advanced en cochant « Respect Noindex ». Si le volume est important, on soulage ainsi la RAM et surtout les exports en csv/xls.
Attention aux effets de bord avec cette option ! Une page de catégorie qui n’aurait aucune raison d’être indexée (contenu dupliqué etc) a plein de bonnes raisons d’avoir une directive noindex. Mais si on exclue ces pages du crawler, ce dernier aura beaucoup de mal à trouver les pages qui en découlent ! Aussi, noindex n’est pas nécessairement associé à nofollow.
Là encore je recommande de lancer un crawl partiel pour évaluer la typologie des pages noindex. Si des scripts du style form.php ou panier.php constituent une majeur partie des URLs en noindex, alors il sera préférable d’exclure ces dernières comme évoqué juste avant. Dans tous les cas, il faut veiller à entraver le moins possible la découverte des pages par le crawler (et les moteurs !).
Ne pas suivre les liens en nofollow
D’une manière générale, si un lien possède un attribut nofollow, c’est que l’on ne souhaite pas voir la page cible dans les moteurs de recherche. On peut donc sans trop d’hésitation décocher les options relatives au nofollow dans Configuration > Spider > Basic. Cela permet également de se rapprocher de la « vision moteur » (Googlebot). Après je dois avouer que bien souvent je rencontre des éditeurs associant sans aucune distinction noindex et nofollow avec les conséquences que l’on connaît. Il est donc parfois nécessaire de faire un crawl en forçant SF à suivre les nofollow histoire de voir s’il n’y a pas des URLs laissées pour compte.
Respect du robots.txt
A l’image du nofollow évoqué juste au dessus, on peut également demander à Screaming Frog de respecter les directives du robots.txt. Sur certains projets, le volume d’URLs soumises à disallow est parfois considérable. Prenez soins de décocher « Show internal URLs Blocked By Robots.txt » dans Configuration > Spider > Basic, de même pour « Ignore Robots.txt ». Je rappelle quand même que ce conseil vaut surtout pour alléger la RAM, mais que ce genre d’option peut apporter un plus indéniable en temps normal.
Limiter la profondeur des URLs
Sacrilège quelle idée ! Un crawl n’est valable que s’il est complet ! Me direz-vous…
Certes ! Surtout lors d’un audit si on veut montrer au client que ses pages en niveau 6 et + ne drainent aucun trafic organique, il faut bien les récolter. Sauf qu’il y a quand même des cas où l’on peut appliquer cette restriction : j’ai à mainte reprise bossé sur des projets « passoire » qui généraient des URLs en boucle infinie, Drupal étant mon winner dans ce registre. Alors soit on fixe (rapidement) le problème, soit on fixe une limite, menu Configuration > Spider > Limit. En plus on se rapproche d’une certaine « vision moteur » car au bout d’un moment, les robots d’indexation détectent les boucles infinies (spider trap) et s’arrêtent de crawler.
Cette logique peut également s’adapter à l’option « Limit number of query strings », autrement dit, les paramètres d’URLs qui s’empilent à n’en plus finir. Sur les sites ayant une architecture d’URLs mal structurée, il est préférable de fixer une limite, surtout quand ça part en boucle infinie.
Faire l’impasse sur l’intégration de Google Analytics et Search console
Depuis les versions 4 et 5 de Screaming Frog, il est possible de récupérer les données de GA et SC grâce aux API de ces derniers. Cette association de données est incontestablement excellente et manquait cruellement à SF vis-à-vis de ses concurrents « Saas ». Mais sur des sites à forte volumétrie, on augmente de facto la masse de data récoltées. Mon conseil est donc de faire l’impasse au niveau du crawl, mais de récupérer/associer ces data ultérieurement, sous Excel par exemple (voir mon tuto sur vlookup et le super combo du SEO).
Segmentation du site
Voilà une idée qui a du sens, mais qui n’est pas sans conséquence. On réalise donc plusieurs crawls en fonction des parties distinctes du site : sous-domaine, blog, répertoire etc. En fait c’est une solution de dernier recours, voir utopique. Si le site est si gros au point de devoir le segmenter, tous les exports, analyses, recoupements, associations etc seront également cloisonnés. Perso, je ne peux pas bosser comme ça. J’ai besoin d’une vision d’ensemble pour tirer des statistiques fiables. Cela ne m’empêche pas d’identifier les différentes thématiques/parties du site par la suite pour en sortir des stats segmentées.
Quand il y a plusieurs millions de pages, ça m’est déjà arrivé, alors je me dirige vers des solutions Saas comme Deepcrawl par exemple. Mais je trouve ça beaucoup moins souple (et plus cher) qu’avec le combo SF + Excel. Chacun son truc après tout.
Attention également aux ressources du serveur web !
Même si c’est un peu hors sujet, soyez indulgent avec le serveur du site que vous allez crawler, surtout si c’est un gouffre à URLs ! Si vous ne limitez pas un peu le nombre d’URLs crawlées à la seconde, vous risquez de le stresser, voir de le mettre à genoux. Préférez les crawls nocturnes, et réduisez la voilure dans Configuration > Speed.
Délocaliser Screaming Frog sur le cloud
La manœuvre peut paraître intéressante : utiliser la puissance du cloud pour faire tourner Screaming Frog. Amazon comme Google proposent à la location des machines virtuelles « scalables » permettant en théorie à SF d’avaler n’importe quel type de projet. A ce sujet, je vous conseille de lire cet article très détaillé (EN) qui explique en détail comment procéder à l’installation.
Si vous voulez mon point de vue, ce n’est pas une option pour moi. Le coût, et le temps de mise en place m’incite plutôt à me tourner vers des outils en Saas comme Botify ou Deepcrawl. Question d’habitude aussi !
J’espère que Screaming Frog arrive à crawler plus de 100 000 URLs quand même !
Avec un vieux crawler comme Xenu, je passe facilement les 500 000 URLs…
Au final ça te prend combien de temps pour faire un crawl de ce genre ?
Et tu fais un gain de temps de combien en paramétrant ainsi ?
@Francois : Compare pas SF à Xenu malheureux ! xD
Plus sérieusement, SF n’est pas limité en URLs, sauf dans sa version d’essai (500). Par contre SF va récolter beaucoup plus de data que Xenu dont la spécialité reste les 404.
@Patrick : Ca peut prendre longtemps, tout dépend de la vitesse du serveur en face. Si tu crawl à 30 URL/s, ce n’est pas la même chose que 5 URL/s. Mais paradoxalement, les outils Saas sont beaucoup moins véloces à volumétrie égale.
Un article super complet à bookmarker, comme souvent !
Un petit complément d’infos pour ceux qui comme moi pendant très longtemps galèrent pour augmenter la RAM. Il est possible de vérifier l’augmentation de la RAM allouée en se rendant sur Help puis Debug. Il faut regarder la valeur dans Memory après le terme Max (la valeur affichée est légèrement inférieure à celle indiquée dans la config, c’est normal).
@Cédric : Well spotted!
Salut
Ton article démontre surtout que screaming frog n’est pas du tout adapté au crawl de gros sites.
Mnogosearch (par exemple) dont parlait Jean-Baptiste demande de la config et de l’apprentissage, c’est plus brut, mais je e lui ai déjà fait encaisser 2 millions d’URL sans soucis, même si ça prend un temps considérable.
Il y en a pas mal d’autres. J’avais bien aimé deepcrawl il y a 3 ans, je ne sais pas ce que ça donne aujourd’hui.
Screaming c’est bien sur du petit site e mais ça reste un joli jouet :)
@françois-Olivier : Salut ! Oui je me souviens, on avait déjà échangé sur le sujet sur Twitter il y a quelques temps. Le problème est double : la capacité du crawler, mais aussi la gestion des data par la suite. Screaming Frog n’est pour moi qu’une étape, un truc qui crache de la data, point. Tu peux me mettre le meilleur crawler entre les main, ça ne règle le problème qu’à moitié. Bon y’a des trucs comme tableau ou qlic sense pour faire ses stats, mais ça coute parfois un bras, les repères/fonctions ne sont pas les mêmes…
95% du temps SF convient. Et quand tu dis « Screaming c’est bien sur du petit site », qu’entends-tu par « petit » ? Tu me diras que c’est subjectif, mais 200k URLs HTML c’est du petit site pour toi ? En tout cas, 200k URLs en réglant bien SF et sa RAM ça passe sans souci :)
Après je ne prèche pas que pour SF ^^ Oui il y en a d’autres hyper intéressants comme Scrapy, Nokigiri, Mnogosearch…
Salut,
Encore un article en marge, une vrai rareté dans le SEO, merci ;)
Je ne sais pas si ça a changé, mais mon SF est à 4GO de ram par défaut dans le .ini.
J’ai aussi appris un truc avec les conditions d’exclusions !
Concernant la question SAAS/Desktop, j’utilise et Botify et SF actuellement. Depuis l’intégration GA et GSC, je ne vois plus la plus value d’un outil comme Botify, peut être parce que je travaille sur du « petit » site.
Pour un futur article, tu pourrais peut être nous faire quelque chose autour des outils d’analyse de logs (enfin) accessibles financièrement comme Kelog’s et Spiderlog ? Dans la veine de ce que tu avais fait sur Botify :)
@Sylvain : Concernant la plus value de Botify (ou Deepcrawl) vis à vis de Screaming Frog, effectivement elle devient maigre. Objectivement, les 2 solutions ont leurs qualités et leurs défauts. Botify va plus dans l’analytics et le reporting, permet le recoupement avec les logs, est scalable… Mais si on commence à parler prix…
Pour l’analyse des logs, bingo, j’ai un truc dans les cartons !
Je pense qu’il faut vraiment arrêter de penser qu’on peut crawler de gros sites avec SF. Attention : c’est un outil très utile, pour des sites de moindre envergure ou pour des phases de recette sur une liste d’URLs par exemple. Puisque certains posent la question, de mon point de vue un site de moins de 1M pages (HTML), c’est « petit » :p
Mais malgré tout le « tunning » qu’on peut imaginer, et même en l’installant sur une machine dédiée, qu’elle soit physique ou dans le cloud, ce crawler a un problème énorme : en cas de crash, il faut tout recommencer. Ca n’est évidemment pas très grave quand on a affaire à de petits sites, mais quand il faut plusieurs jours pour parcourir un ensemble de pages ça n’est pas acceptable.
La logique d’outils comme Botify ou OnCrawl est différente : ici on stocke à la volée les données en base, donc même si le crawler plante, on les conservera. Mon problème avec Botify/OnCrawl est triple : limitations en volume, pas ou peu de customisation (au contraire de SF d’ailleurs, qui permet par exemple d’utiliser des Regex pour récupérer du contenu dans les pages) et impossibilité d’exporter les données. Avoir de jolis tableaux de bord n’est pas forcément la panacée :-)
Bref, Screaming Frog est un excellent outil, dont pour ma part je me sers très régulièrement. Mais crawler de gros sites avec ça reste utopique, ou stupide :D
PS pour François-Olivier : tu peux rajouter un ou deux 0 sans problème à ton nombre d’URLs sur Mnogosearch, ça devient juste très lent ;)
@Diije : ok sur tout. Je précise bien que pour certains projets de grande envergure, je me tourne vers des outils Saas. C’est plus scalable certes, mais ça m’emmerde car je perds en souplesse, en argent aussi… SF aura toujours une limite, c’est clair.
Concernant le plantage bah… j’en ai jamais eu :/ Considérant que les crawlers Saas ont une fréquence de crawl/analyse plus lente, et que tu te rends compte à la fin que tu as mal paramétré ton crawl et qu’il faut tout refaire, là vraiment ça pique !
Bien vu pour le filtrage des ressources inutiles, je décochais bien tout, mais ne filtrais pas en faisant confiance à ma RAM pour encaisser le tout sur les sites analysés, merci !
Pour les trolls sur la taille du site, on peut toujours partitionner les analyses ou utiliser divers outils selon les besoins, SF reste un très bon outil.
J’ai bien envie de copier coller le commentaire d’Aurélien car je comptais dire la même chose mais cela ferait du duplicate :)
Merci pour le partage.
@Aurélien : Lequel d’Aurélien ? #triplicate
Super Article…
comme tout le monde j’ai été confronté à ce problème de mémoire vive dans screaming frog et effectivement la réponse du support avait été de segmenter le crawl… ce qui ne répond pas vraiment à mes besoins.
Néanmoins, je trouve surtout que screaming frog n’est pas très bon pour recracher de la donnée facile à exploiter :
* les rapports csv sont difficilement exploitables directement dans excel car il y a une ligne d’en-tête
* le rapport de chaîne de redirections est juste vraiment mal formaté… avoir la dernière url de la chaine et son code demande un peu de maîtrise d’excel
* Il fait automatique du décodage d’url sans prévenir, ce qui laisse des surprises quand on teste des urls encodés
* il ne fait pas de hash pour les ressources type img, css, js (toujours utile de voir si un site tue le cache navigateur en appelant les ressources avec des urls différents
* Il faut exporter les rapports un à un si jamais tu veux un spectre d’analyse complet (alors que ca serait sympa d’avoir un zip avec tous les rapports pour tout importer d’un coup dans excel ou qlik par exemple)
* on ne peux pas catégoriser les urls
* il pourrait également faire un hash de l’url même car…. qui a déjà recherché un url de plus de 255 caractères avec un rechercheV? :)
Bon, après, ne crachons pas… l’outil est super pratique, et il est seul sur son segment… mais il lui manque pas mal d’éléments pour produire des rapports directement exploitables.
Merci en tout cas pour l’article!
haha, aurelienD
(je me rends compte, qu’indiquer AurelienB en pseudo n’est pas suffisant non plus :-)
@ZeNobral :
les rapports csv sont difficilement exploitables directement dans excel car il y a une ligne d’en-tête
Ho mais ce n’est rien ça ! ^^
Remarque pertinente concernant le hash des ressources autres que HTML. Pour les exports un à un, effectivement on pourrait imaginer que SF nous mache le travail pour faciliter sous Excel. Et si la solution se trouvait (en partie) dans un outil intermédiaire comme Knime ?
Pour la catégorisation des URLs, ce n’est pas un boulot que je confierai aveuglément à SF car subjectif, mais il peut y contribuer : depuis la v4 tu peux récupérer le répertoire courant du fil d’Ariane par exemple ce qui permet de trier/filtrer ensuite les URLs sous Excel.
Sinon, Screaming Frog a un concurrent frontal totalement méconnu, en France en tout cas, c’est A1 Website Analyzer que l’on peut également aux autres outils de microsystools.com
Merci Aurélien,
j’ai plusieurs sites, qui ont plusieurs centaines de milliers de pages, que j’avais du mal à crawler avec Screaming Frog et là en suivant tes conseils ça fonctionne parfaitement :-)
@Dimitri : cool :)
Bonsoir,
Quand je change le fichier .ini avec par exemple 8g, SF n’arrive plus à démarrer.
Sinon j’aimerais bien également que tu nous dise ce que tu pense de l’utilisation de SF pour les domaines expirés.
Merci
@SEO.ma : regarde ici : https://goo.gl/R44sek ;)
Merci pour cet article.
Je suis actuellement confronté à un site de prospect qui n’est pas crawlable, non pas à cause d’un manque de RAM (cas le plus fréquent) mais parce qu’il consomme toutes les ressources processeur ! Au bout de quelques milliers d’urls, le crawler s’essouffle et s’arrête. Processeur à 100% et plus une page de crawlée. Testé avec plusieurs installations de Screaming forg, java en 64 bits, etc.
Pour info si quelqu’un rencontre ce problème, cela semble venir du nombre de liens sortants (internes) par page qui est clairement excessif. Au minimum 800 par page et çà monte à quelques milliers. Oui c’est beaucoup ;-)