Screaming Frog : le crawl lit le code, pas la page rendue

Screaming Frog est un robot de parcours qui tourne sur mon ordinateur. Il part d'une adresse, suit les liens qu'il rencontre, et range dans un tableau ce qu'il a lu de chaque page : le titre, la description, le code de réponse, les images, les liens entrants et sortants. La machine qui parcourt le site, c'est la mienne, et c'est toute la différence avec une donnée d'éditeur.

Sur le site d'un atelier d'usinage de précision, le premier parcours n'a rien ramené. Le code source était vide : tout le contenu arrivait ensuite, par JavaScript.

1. Le problème que ça règle chez moi

Un client veut faire corriger les attributs alternatifs de ses images, ces textes qui décrivent une image à qui ne la voit pas. La demande est claire. La question qui suit ne l'est pas : lesquelles, et dans quel ordre.

Cette liste ne se relève pas à la main. Un parcours automatique la fabrique en une passe, une ligne par fichier, avec la page qui le porte. C'est le motif pour lequel j'ouvre encore ce crawler-là.

2. Ce que j'en sors, concrètement

Sur le pré-audit d'un distributeur qui ne vend qu'à des professionnels, le parcours a compté 276 images et 247 sans attribut alternatif. Près de neuf sur dix. Ce chiffre a servi à ouvrir la conversation, il n'a rien décidé.

Ce qui décide, c'est la même liste triée par page. Sur un dossier de distribution d'équipements, je l'ai rendue en trois niveaux : les catégories et sous-catégories d'abord, puis les 30 produits les plus consultés, puis le reste. La médiathèque entière n'a pas été touchée, et elle n'avait pas à l'être : un attribut alternatif posé sur une page que personne n'ouvre ne rapporte rien.

Ce que je demande à ce crawler tient donc en une phrase : une colonne précise, sur toutes les adresses d'un site, dans un seul fichier. Pas un diagnostic.

3. Ce que je ne lui demande pas

De me dire ce que voit un moteur. Le parcours lit le code source tel que le serveur l'a envoyé, avant que le navigateur le traite. L'exécution du JavaScript existe, mais elle n'est pas le réglage de départ : elle se choisit, et elle ne tient d'un parcours au suivant que si on l'enregistre. L'éditeur le pose ainsi dans son mode d'emploi du parcours des sites en JavaScript. Sur le site de cet atelier d'usinage, la conséquence était brutale : corps de page vide, aucun lien à suivre, un rapport qui donnait l'image d'un site inexistant. Le site se portait très bien. C'est le parcours qui regardait au mauvais endroit.

De hiérarchiser à ma place. Il rend un tableau, et un tableau ne dit pas ce qui coûte des ventes. Mon crawler d'audit est devenu Sitebulb, qui rend un rapport hiérarchisé ; Screaming Frog est resté pour l'extraction. Le partage n'était pas prévu, il tient.

De tourner pendant que je fais autre chose. L'éditeur annonce dans son guide général un minimum de 4 Go de mémoire vive, 8 Go pour un parcours en dessous de 200 000 adresses, et un disque rapide avec 16 Go au-delà du million. Ce sont ses chiffres, et ils décrivent bien ce qui se passe : sur un gros catalogue, le poste est pris pour la durée du parcours.

4. Ce que je branche autour

Un parcours trouve une page. Il ne dit pas si le moteur l'a gardée. Les deux listes ne se recouvrent jamais tout à fait, et l'écart entre elles est précisément ce qui se travaille : j'ai écrit ce que la source venue du moteur montre, et ses trous, dans ce que je demande à Search Console.

Le reste se répartit sur le même principe. DataForSEO dit ce que les gens cherchent, Ahrefs dit qui cite qui. Aucun des deux ne lit le code d'une page ; le crawler ne lit que ça.

Sur une mission SEO, ce parcours est le premier geste, avant la moindre recommandation. Sur un site WordPress, il sert aussi à mesurer ce qu'un constructeur de pages a laissé derrière lui : j'ai raconté ce que ça donne dans la dette technique d'un site sous constructeur et dans reprendre un site laissé par une agence.

5. Ce que ça coûte à mon échelle

Le coût d'un crawler de bureau ne se lit pas sur la facture. Il se lit sur deux choses.

La machine d'abord. Les chiffres de l'éditeur ne sont pas décoratifs : un catalogue de plusieurs centaines de milliers d'adresses occupe le poste tant que le parcours tourne. Ces parcours-là, je les lance en fin de journée.

La péremption ensuite. Le fichier décrit le site tel qu'il était le jour du parcours. Deux mises en ligne plus tard, il décrit un site qui n'existe plus. C'est ce qui condamne l'idée de parcourir un site une fois pour toutes en début de mission : le parcours se refait, sinon il ment.

Le réglage fait le résultat

Un rapport de parcours ne décrit pas un site. Il décrit ce qu'une machine a demandé, avec les réglages qu'on lui a donnés, le jour où on l'a lancée. Devant un tableau vide, le premier réflexe n'est donc pas de conclure que le site est vide. C'est de regarder ce qu'on a demandé.

Votre site ressort-il vide d'un parcours automatique ?

Je lance le parcours, je compare ce qu'il trouve à ce que le moteur a gardé, et je rends la liste des écarts, triée par ce qu'ils coûtent. C'est le premier geste de mes missions SEO et de mes chantiers WordPress.

Demander un audit gratuit

À lire ensuite