Comment segmenter un crawl par répertoire sur un gros site ?

Explorer un site de cinquante mille adresses avec un outil de crawl produit un tableau de cinquante mille lignes, et ce tableau ne se lit pas. On y trouve tout ce qu'il faut, on n'en tire rien, et l'audit se termine sur une liste de constats génériques valables pour n'importe quel site, dont le client ne fera rien. La segmentation d'un crawl par répertoire résout ce problème d'un coup : au lieu de regarder un site, on regarde une dizaine de familles homogènes que l'on peut comparer entre elles. Un taux de pages sans méta description de douze pour cent ne veut rien dire ; le même taux à quatre pour cent sur les articles et à quatre vingt pour cent sur une rubrique précise désigne immédiatement le chantier, son volume et le gabarit responsable. La segmentation ne produit aucune donnée nouvelle, elle rend simplement lisible celle que l'on avait déjà.

Préparer le crawl avant de le lancer

Un crawl mal configuré sur un gros site tourne pendant huit heures, sature la mémoire et produit des données inexploitables. La préparation prend vingt minutes, elle détermine toute la suite et elle évite d'avoir à relancer l'opération le lendemain, dans le prolongement de ce que nous décrivons dans la rubrique référencement naturel à propos des audits techniques.

Décider ce que l'on cherche

Un crawl exploratoire, destiné à découvrir la structure, et un crawl de contrôle, destiné à vérifier des points précis, ne se configurent pas de la même manière. Le premier doit rester large et peu profond, le second peut être restreint à quelques répertoires et collecter davantage d'informations par page. Lancer systématiquement un crawl complet avec toutes les options activées est le meilleur moyen d'attendre longtemps pour obtenir des données que l'on n'exploitera pas. La question à se poser avant de lancer tient en une phrase : quelle décision ce crawl va t il permettre de prendre ?

Choisir le mode de stockage

Les outils de crawl conservent par défaut leurs données en mémoire, ce qui est rapide et limité par la machine. Au delà de quelques dizaines de milliers d'adresses, le passage à un stockage sur disque devient nécessaire, au prix d'une vitesse moindre. Faire ce choix avant de lancer évite l'interruption au bout de trois heures pour saturation, qui oblige à tout recommencer depuis le début. Le stockage sur disque a un second avantage sur un gros site, il conserve le crawl après fermeture de l'outil, ce qui permet de revenir dessus plusieurs jours plus tard sans le relancer.

Régler la vitesse pour ne pas perturber le site

Un crawl lancé sans limitation peut envoyer plusieurs dizaines de requêtes par seconde et dégrader sérieusement un site en production, voire déclencher une protection qui bloquera l'outil. Une limite de deux à cinq requêtes par seconde est raisonnable sur un hébergement mutualisé, davantage sur une infrastructure solide, et l'opération se mène de préférence en dehors des heures de forte activité. Prévenir l'hébergeur ou l'équipe technique évite par ailleurs une alerte de sécurité inutile, et permet de faire lever temporairement une limitation qui fausserait les résultats.

Exclure ce qui n'apporte rien

Les adresses de recherche interne, les filtres combinés, les paramètres de suivi et les fichiers volumineux consomment la majeure partie du temps sans rien apprendre. Les exclure par des règles définies avant le lancement réduit souvent le volume de moitié et concentre le crawl sur ce qui compte. Il faut en revanche noter ces exclusions, car un audit qui ne les mentionne pas laisse croire à une couverture complète alors qu'une partie du site n'a jamais été regardée.

Se présenter honnêtement

L'outil doit s'identifier clairement plutôt que se faire passer pour un navigateur, ce qui permet à l'équipe technique de reconnaître le trafic dans les journaux et d'écarter une fausse alerte. Sur un site protégé, il est parfois nécessaire d'autoriser explicitement l'adresse d'origine, ce qui se prépare avant plutôt que de découvrir en cours de route que la moitié des pages répond une erreur d'accès.

Explorer autre chose que les liens

Un crawl classique suit les liens internes depuis un point de départ, ce qui laisse dans l'ombre tout ce qui n'est lié par rien. Sur un site volumineux, cette part est loin d'être négligeable, et c'est précisément là que se cachent les problèmes intéressants. Trois sources complémentaires méritent d'être injectées au démarrage : le plan de site, qui contient ce que le site revendique, la liste des adresses trouvées dans les journaux serveur, qui contient ce que le moteur visite, et un export des adresses connues des outils pour webmasters. Le rapprochement des quatre populations, liées, déclarées, visitées et connues, produit à lui seul plusieurs constats : contenus orphelins présents dans le plan de site, adresses explorées par le moteur mais absentes du site, pages liées mais jamais déclarées. Aucune de ces trois anomalies n'apparaît dans un crawl mené par les seuls liens.

Définir des segments qui ont du sens

La segmentation est l'étape qui transforme la donnée en information. Elle se construit à partir de la structure réelle des adresses, et elle rejoint la logique de familles employée dans notre article sur la manière de calculer son budget d'exploration à partir des journaux serveur.

Partir des répertoires existants

Sur un site bien structuré, le premier segment de chemin correspond déjà à une famille : le blog, la boutique, les pages institutionnelles, l'espace client. C'est le découpage le plus naturel, le plus rapide à mettre en place et le plus immédiatement lisible par le client, qui reconnaît son propre site dans le tableau. Quand la structure des adresses ne reflète pas l'organisation du site, ce qui arrive après plusieurs refontes, la segmentation doit s'appuyer sur des motifs plutôt que sur des dossiers, ce qui reste tout à fait possible mais demande un travail préalable de repérage un peu ingrat, généralement une extraction des motifs d'adresses les plus fréquents pour voir ce qui se dégage.

Séparer par gabarit autant que par thème

Deux répertoires très différents thématiquement mais construits avec le même gabarit se comportent techniquement de la même manière, et les regrouper facilite le diagnostic. À l'inverse, un même répertoire contenant deux gabarits distincts, articles et pages de liste par exemple, doit être scindé. Le critère de segmentation le plus utile est donc la combinaison du répertoire et du modèle d'affichage, ce qui donne en général entre huit et quinze segments sur un site volumineux. Ce croisement se prépare en amont, en repérant quel motif d'adresse correspond à quel gabarit, information que l'équipe technique fournit en quelques minutes.

Isoler explicitement le bruit

Un segment doit être réservé à tout ce qui n'entre dans aucune famille utile : archives par date, pages d'auteur, adresses de pagination profonde, contenus de test oubliés. Le regrouper plutôt que de l'ignorer présente un avantage, il devient mesurable : constater que ce segment représente trente pour cent des adresses explorées est en soi un résultat d'audit, et souvent le plus actionnable, puisqu'il désigne un volume que l'on peut réduire sans rien perdre.

Garder les segments stables

La valeur de la segmentation vient de la comparaison dans le temps. Les définitions doivent donc être écrites, versionnées avec le reste de l'audit, et réutilisées à l'identique au crawl suivant. Redéfinir les segments à chaque passage produit des chiffres qui ne se comparent pas, ce qui prive le suivi de tout intérêt, transforme chaque campagne en exercice isolé et rend impossible de démontrer l'effet d'une correction, qui est pourtant la seule chose qui intéresse le client au bout de six mois.

Se limiter à une dizaine

Au delà d'une quinzaine de segments, le tableau redevient illisible et les effectifs par segment deviennent trop faibles pour être significatifs. Mieux vaut une dizaine de familles bien définies, quitte à mener un second crawl restreint sur celle qui pose problème. Ce découpage en deux temps, une vue d'ensemble puis un examen ciblé, est nettement plus efficace qu'une segmentation très fine dès le départ, et il correspond mieux à la manière dont un audit se déroule réellement.

Décider s'il faut exécuter le JavaScript

Le mode de rendu conditionne ce que le crawl voit, et il double au minimum la durée de l'opération. Sur un site dont le contenu et les liens figurent dans le document servi par le serveur, l'exécution des scripts n'apporte rien et coûte cher ; sur un site dont la navigation dépend de scripts, un crawl sans rendu manquera l'essentiel des pages. La vérification préalable est simple : afficher le code source de deux ou trois gabarits représentatifs et y chercher les liens de navigation. La méthode qui donne les meilleurs résultats sur un gros site consiste à mener un crawl rapide sans rendu sur l'intégralité, puis un crawl avec rendu sur un échantillon de chaque segment, ce qui permet de mesurer précisément l'écart entre les deux sans payer le coût du rendu sur cinquante mille pages.

Lire les résultats par comparaison

Un chiffre isolé ne dit rien, un écart entre segments dit presque tout. C'est le principe de lecture, et il change complètement la nature des conclusions que l'on peut tirer d'un crawl. Il vaut aussi pour les autres contrôles techniques, comme la recherche des chaînes de redirections sur un site de plusieurs milliers d'URL.

Comparer chaque segment à la moyenne du site

La première lecture consiste à afficher, pour chaque indicateur, la valeur de chaque segment et celle de l'ensemble. Les segments qui s'écartent nettement de la moyenne désignent les gabarits défaillants, sans qu'il soit nécessaire de définir un seuil absolu. Cette lecture relative est robuste : elle ne dépend d'aucune norme extérieure et reste valable quels que soient le secteur et la taille du site. Elle produit aussi des conclusions faciles à présenter, un écart visible entre deux lignes d'un tableau se comprenant sans explication.

Croiser avec les journaux serveur

Le crawl dit ce que le site contient, les journaux disent ce que le moteur visite réellement. Croiser les deux par segment fait apparaître les familles ignorées malgré leur présence dans le plan de site, et celles qui absorbent une part disproportionnée de l'exploration. C'est le croisement qui produit les conclusions les plus fortes, parce qu'il relie une structure à un comportement observé plutôt qu'à une hypothèse. Il demande simplement que les deux jeux de données couvrent la même période, un crawl du jour comparé à des journaux d'il y a six mois n'ayant aucun sens.

Croiser avec les données de performance

Ajouter à chaque segment le nombre d'impressions et de clics issus des outils pour webmasters change l'ordre des priorités. Un segment techniquement médiocre mais générant l'essentiel du trafic mérite une intervention immédiate ; un segment impeccable et sans aucune visibilité pose une question différente, celle de son utilité. Cette question mérite d'être posée franchement : sur beaucoup de sites volumineux, un segment entier ne sert plus à rien et sa suppression pure et simple vaut mieux que sa correction. Cette lecture évite le travers classique de l'audit technique qui hiérarchise par gravité théorique plutôt que par enjeu réel.

Regarder la distribution, pas la moyenne

Une profondeur moyenne de trois clics peut recouvrir un site homogène ou un ensemble où la moitié des pages est à deux clics et l'autre à huit. La distribution, affichée par tranches, révèle ces situations que la moyenne masque. C'est particulièrement vrai sur les sites à forte pagination, où quelques milliers de pages se retrouvent très profondes sans que la moyenne ne bouge sensiblement. La même prudence vaut pour le poids des pages, où quelques gabarits très lourds pèsent lourd sur l'expérience réelle et disparaissent dans une moyenne calculée sur des dizaines de milliers de pages légères.

Transformer l'audit en suivi

Un crawl ponctuel produit une photographie et un rapport que l'on classe. Répété selon la même méthode, il devient un instrument de pilotage, et c'est là que l'investissement de segmentation se rentabilise.

Rejouer à intervalle régulier

Un crawl trimestriel sur un site volumineux, avec les mêmes segments et les mêmes exclusions, permet de suivre l'évolution de chaque indicateur par famille. Les corrections apportées se voient, les régressions apparaissent tôt, et la discussion avec le client cesse de porter sur des impressions pour porter sur des écarts chiffrés entre deux dates. Le fichier de configuration de l'outil doit être conservé avec les résultats, faute de quoi la reproductibilité n'est qu'une intention. Une note accompagnant chaque campagne, indiquant la date, la version de l'outil et les éventuelles particularités du jour, complète utilement ce dossier.

Conserver les exports, pas seulement les rapports

Le rapport de synthèse vieillit vite et ne permet aucune nouvelle question. Les exports bruts, eux, permettent des analyses qui n'avaient pas été prévues, et surtout des comparaisons ligne à ligne entre deux crawls. Ils pèsent quelques dizaines de mégaoctets et se conservent des années sans effort, ce qui est sans commune mesure avec ce qu'ils permettent de retrouver. Le format retenu doit rester ouvert, un export dans un format propriétaire dépendant de la disponibilité future de l'outil qui l'a produit.

Automatiser ce qui peut l'être

Sur un site où l'enjeu le justifie, une partie des contrôles peut tourner chaque semaine sur un échantillon plutôt que sur l'intégralité : quelques centaines d'adresses tirées de chaque segment, vérifiées automatiquement sur les points critiques. Cette surveillance légère détecte les régressions de gabarit en quelques jours, là où le crawl trimestriel les découvre après trois mois de dégradation. Les points qui méritent cette surveillance rapprochée sont peu nombreux : présence du titre, de la canonique et de la directive d'indexation, et code de réponse.

Rendre les résultats lisibles par le client

La dernière étape est de présentation. Un tableau de dix lignes, une par segment, avec quatre ou cinq colonnes et un code visuel simple, produit plus d'effet et plus de décisions qu'un rapport de quarante pages. Les détails restent disponibles en annexe pour ceux qui les demandent, et l'export complet reste joint au dossier, mais la synthèse doit tenir sur un écran et désigner sans ambiguïté les deux ou trois chantiers qui comptent. Chacun doit être formulé comme une action, avec un ordre de grandeur du travail nécessaire, faute de quoi la synthèse décrit un état sans permettre de décider. L'ordre de grandeur se donne en journées de travail plutôt qu'en heures, précision suffisante pour arbitrer et suffisamment prudente pour ne pas engager l'équipe sur une estimation que l'audit ne permet pas de tenir.