Un client m'appelle l'été dernier, paniqué. Son trafic a chuté de 40 % en trois semaines. Il a vérifié son contenu, ses backlinks, ses balises title. Rien. Je lui demande la seule chose qui compte dans ce cas : "Tu as regardé ce que Google essaie réellement de crawler en ce moment ?" Silence au bout du fil.
Deux heures plus tard, on avait la réponse. Son fichier robots.txt avait été écrasé par un déploiement et bloquait 12 000 URLs. Aucun outil de suivi de positions ne l'aurait vu. Un simple export de crawl, croisé avec la Search Console, l'a mis en évidence en dix minutes.
C'est tout le problème avec l'audit technique : on parle d'outils, de prix, de fonctionnalités, mais rarement de ce qu'on fait vraiment des données une fois qu'on les a. Utiliser les données de crawl pour auditer son site, ce n'est pas lancer un scan et lire un rapport en rouge. C'est une méthode de lecture.
Points clés à retenir
- Un crawl seul ne sert à rien : c'est le croisement des colonnes (statut, profondeur, inlinks, indexabilité) qui produit l'audit
- Priorisez par template, jamais URL par URL — un site de 8 000 pages se traite en 6 ou 7 groupes, pas en 8 000 décisions
- Comparez toujours trois sources : données de crawl, logs serveur, rapport de couverture Search Console
- Une page orpheline ou trop profonde coûte plus cher qu'une 404 visible
- Ne corrigez jamais avant d'avoir segmenté : c'est la segmentation qui révèle le problème structurel
Pourquoi le crawl moteur et le crawl outil racontent deux histoires différentes
Il y a une confusion qui coûte cher, et je la rencontre à chaque mission. Quand on dit "crawl", on parle de deux choses :
- Le crawl moteur — Googlebot qui explore votre site selon ses propres règles, son budget, ses priorités
- Le crawl outil — un logiciel lancé depuis votre machine qui parcourt vos URLs selon vos paramètres
Ces deux-là ne voient pas le même site. Un agent qui se bloque sur un WAF, une limite de requêtes par seconde, un rendu JavaScript partiel : votre outil peut tout crawler, Google peut en ignorer la moitié. L'inverse est vrai aussi.
Comment comparer les trois sources correctement
La méthode que j'applique depuis des années tient en trois colonnes côte à côte :
- Les URLs crawlées par votre outil (toutes celles que vous connaissez)
- Les URLs réellement visitées par Google, visibles dans les logs serveur (filtrez sur le user-agent Googlebot légitime, pas les faux)
- Les URLs indexées, dans le rapport de couverture de la Search Console
Le delta entre ces trois ensembles, c'est votre audit. Une URL crawlé par l'outil mais jamais visitée par Google ? Problème de maillage ou de priorité. Une URL visitée par Google mais jamais indexée ? Problème de qualité ou de duplication. Une URL indexée mais absente de votre crawl ? Vous avez un contenu que vous ne contrôlez pas.
Franchement, cette triple lecture m'a fait gagner plus de temps que n'importe quel plugin SEO.
La segmentation : l'étape que tout le monde saute
Vous avez exporté 14 000 lignes. Bravo. Maintenant, qu'est-ce que vous en faites ?
La réponse n'est pas "trier par code réponse". C'est segmenter par template. Un site e-commerce, c'est typiquement :
- Les pages catégories (souvent 50 à 200, très liées)
- Les fiches produit (le gros du volume)
- Les pages de filtres et de pagination (le piège classique)
- Les pages éditoriales / blog
- Les pages légales et le compte client
Pourquoi ça change tout ? Parce qu'un problème sur les fiches produit n'a pas le même traitement qu'un problème sur les filtres. Si vos 4 000 fiches produit ont un temps de réponse de 2,3 secondes, c'est un problème d'hébergement ou de code. Si vos 900 pages de filtres ont le même souci, c'est un problème d'architecture à régler par un noindex ciblé ou une règle robots.txt.
Le ratio profondeur / inlinks, le vrai signal
Dans tout export de crawl, il y a deux colonnes qu'on regarde trop tard : la profondeur (nombre de clics depuis la home) et le nombre d'inlinks internes. Croisez-les.
Une page à plus de 4 clics de profondeur et moins de 3 liens internes pointant vers elle, c'est une page que Google va visiter une fois tous les trois mois — au mieux. La corriger en ajoutant deux liens depuis des pages fortes fait souvent plus d'effet que réécrire son contenu.
| Indicateur croisé | Signal faible | Action prioritaire |
|---|---|---|
| Profondeur 5+ / inlinks < 2 | Page quasi invisible | Ajouter 2-3 liens internes depuis pages fortes |
| Statut 200 / non indexable | Meta robots ou canonical incohérent | Corriger la directive, pas le contenu |
| Statut 301 en chaîne (2+ sauts) | Perte de jus + ralentissement | Réécrire la règle de redirection cible |
| 200 / 0 inlink / 0 visite log | Orpheline pure | Décider : mailler ou supprimer |
Ce tableau, c'est ma grille de lecture par défaut. Sur un site à 6 000 URLs, il sort en général entre 15 et 25 actions concrètes. Pas 600.
Les erreurs qui ne se voient qu'en croisant les données
Une 404 visible, c'est un problème bruyant. Un audit qui ne regarde que les erreurs 404 passe à côté de tout ce qui compte.
Les canonicals contradictoires
J'ai vu un site où 40 % des fiches produit déclaraient un canonical vers la page catégorie parente. Erreur d'un développeur qui avait fait une regex un peu trop large. Résultat : Google indexait la catégorie, ignorait les produits, et le site perdait les requêtes longue traîne qui représentaient son seul vrai avantage. Quatre mois de baisse sans qu'aucun outil ne remonte l'alerte, parce que toutes les pages répondaient 200.
Les redirections qui bouclent ou qui chaînent
Un export de crawl bien lu affiche la chaîne de redirection complète. Trois sauts 301 avant d'atteindre la cible ? Vous perdez du signal, vous ralentissez le crawl, et Google peut abandonner en route. Ce cas arrive plus souvent qu'on ne le pense après deux ou trois refontes successives.
Le contenu rendu en JavaScript
Là, il faut être honnête : un crawl HTML classique ne voit rien. Il faut activer le rendu JS de votre outil, ou crawler une version pré-rendue. J'ai mis six mois à comprendre pourquoi un client voyait ses pages indexées vides dans la Search Console alors que son crawl local affichait fièrement 100 % de contenu. Le coupable : un chargement d'avis clients en JS bloqué par une règle CSP trop stricte en production, invisible en staging.
Comment détecter ce problème rapidement ?
Ouvrez une URL dans votre navigateur avec JavaScript désactivé. Si le contenu principal disparaît, votre crawl HTML classique ne le verra pas non plus. Activez le rendu JavaScript dans l'outil, ou utilisez un service de pré-rendu pour tester. Comparez ensuite le HTML brut servi à Googlebot (via l'inspection d'URL dans la Search Console) avec ce que vous voyez dans votre navigateur.
Prioriser sans se noyer : la règle des 20 %
Sur un crawl de 10 000 URLs, vous aurez toujours 800 à 1 500 lignes "en rouge". C'est normal. C'est aussi inutile à traiter tel quel.
Ma règle : 20 % des URLs portent 80 % du trafic organique — vous le savez, c'est un constat statistique classique. Ces 20 %, vous les identifiez dans la Search Console (tri par clics décroissants sur 3 mois). Vous les croisez avec votre export de crawl. Toutes les anomalies sur ces pages passent en priorité absolue. Le reste attend.
Un exemple concret : sur un site média, 320 articles sur 9 400 généraient 76 % du trafic. Cinq d'entre eux avaient un canonical cassé depuis une migration. On a corrigé ça en une matinée. Résultat trois semaines plus tard : +18 % de clics organiques rien qu'en remettant ces pages en pleine possession de leurs moyens. Aucun contenu réécrit.
Ce que les outils ne feront jamais à votre place
Il existe une trentaine d'outils de crawl, du gratuit au très cher. Ils feront tous la même chose : lister, compter, colorier. Ce qu'aucun ne fera, c'est décider pour vous.
Le vrai travail d'audit commence à la sortie du rapport. C'est là qu'il faut répondre à trois questions :
- Quelle est la cause structurelle derrière ces 400 alertes similaires ?
- Quelle correction règle le plus de cas d'un seul coup ?
- Qu'est-ce que je peux laisser tel quel sans risque ?
La troisième est la plus importante et la plus négligée. J'ai vu des équipes passer des semaines à corriger des 404 sur des URLs jamais liées et jamais visitées. Zéro impact. Pendant ce temps, une redirection cassée sur une page à 4 000 visites par mois continuait de saigner.
Un crawl, c'est un révélateur. Pas un diagnostic. La différence tient dans la lecture que vous en faites — et dans ce que vous acceptez de ne pas corriger.
La prochaine fois que vous lancez un scan et que le rapport vous noie sous 2 000 alertes, posez-vous une seule question : laquelle, si je la corrige ce soir, change quelque chose de mesurable dans trente jours ? Commencez par celle-là. Les 1 999 autres vous attendront.
