// guide pilier · écosystème seo
Screaming Frog : crawler son site pas à pas.
Un crawler reproduit ce que fait Googlebot : il part de la page d'accueil et suit les liens. Le configurer correctement, comprendre ce qu'il ne peut structurellement pas voir, et lire les rapports dans l'ordre qui compte plutôt que de corriger 800 lignes sans les trier.
Ce qu'un crawler voit, et ne voit pas.
Un crawler part d'une URL de départ, télécharge la page, extrait les liens, et recommence. C'est exactement le comportement de Googlebot, ce qui en fait le meilleur simulateur disponible. C'est aussi la source de sa limite fondamentale.
// à retenir
Un crawler ne peut par définition pas trouver une page qu'aucun lien ne pointe. Si votre crawl remonte 400 URLs et que Search Console en connaît 600, les 200 manquantes ne sont pas un bug de l'outil : ce sont des pages orphelines, et cet écart est en soi le diagnostic le plus rentable de l'exercice.
Ce que le crawl seul ne dira jamais
- Ce que Google a réellement indexé. Le crawler dit ce qui est atteignable et indexable. Le verdict d'indexation appartient à Search Console, et lui seul.
- Ce que Googlebot crawle vraiment. Seuls les logs serveur le disent. Un crawler simule un passage ; il ne mesure pas la fréquence réelle. Voir crawl budget.
- Les pages orphelines. Sans croisement avec le sitemap ou les API, elles restent invisibles. C'est la limite la plus coûteuse à ignorer.
Configurer un crawl utile.
Les réglages par défaut conviennent à un premier crawl exploratoire. Quatre points méritent une décision consciente avant de lancer, surtout sur un site en production.
La vitesse de crawl
Le premier réglage à toucher, et le plus oublié. Un crawl à pleine vitesse sur un serveur mutualisé peut le faire tomber. Baisser le nombre de requêtes par seconde avant de lancer, surtout en journée sur un site marchand.
→ avant, jamais après
Le respect du robots.txt
Activé par défaut : c'est le bon réglage pour reproduire Googlebot. Le désactiver sert à mesurer le volume d'URLs cachées derrière un Disallow, mais expose à un crawl massif si les filtres sont bloqués.
→ garder activé par défaut
- Le user-agent. Crawler en se déclarant Googlebot révèle les serveurs qui traitent Googlebot différemment des visiteurs. C'est ainsi qu'on découvre un pare-feu qui renvoie un 403 au moteur tout en servant la page aux humains.
- Les API Search Console et Analytics. Le réglage qui change tout, et qui justifie à lui seul la licence. Il permet le rapport de pages orphelines et le croisement trafic/crawl.
- L'authentification. Le crawler gère l'authentification HTTP basique pour les préproductions protégées. Une recette est presque toujours en noindex global : toutes les pages remonteront non indexables, et c'est normal.
Le test des deux crawls.
La manipulation la plus instructive de l'outil, et celle que presque personne ne fait. Elle prend dix minutes et répond à une question que rien d'autre ne tranche aussi nettement.
HTML brut (par défaut)
Le crawler lit le HTML servi par le serveur, sans exécuter le JavaScript. C'est exactement ce que voit Googlebot en première vague de crawl, celle qui décide de la découverte des liens.
→ la première vague
Rendu JavaScript activé
Le crawler exécute le JavaScript avant d'analyser. Correspond à la seconde vague de Googlebot, qui arrive avec un délai variable et n'est jamais garantie dans un délai donné.
→ la seconde vague
// lire l'écart
C'est la différence entre les deux crawls qui constitue le diagnostic, pas le résultat de l'un ou de l'autre. Si le crawl avec rendu trouve 300 pages là où le crawl brut en trouve 12, la navigation dépend entièrement du JavaScript et la découverte de vos pages repose sur une vague de crawl différée. Ne crawler qu'avec le rendu activé rend ce problème parfaitement invisible.
Lire les rapports dans l'ordre.
L'outil présente ses onglets dans un ordre qui n'est pas celui des priorités. Suivre l'interface conduit à traiter les titles avant les erreurs serveur, ce qui est exactement l'inverse de ce qu'il faut faire.
- 01
- 02
Indexabilité
La colonne qui rapporte le plus. Filtrer sur "non indexable" et vérifier chaque motif : noindex, blocage robots.txt, canonical vers une autre URL. C'est ici qu'on trouve le noindex de recette laissé en production.
- 03
Canonical et duplication
Le rapport de titles dupliqués est le meilleur détecteur de pages dupliquées : deux URLs au même title servent presque toujours le même contenu. Repérer le motif d'URL commun plutôt que les URLs une à une. Voir contenu dupliqué.
- 04
Profondeur et liens internes
La colonne de profondeur classe les pages par distance à la home. Filtrer au-delà de 3 clics, croiser avec la valeur business. Le rapport de liens entrants dit si la hiérarchie du maillage reflète celle du chiffre d'affaires. Voir maillage interne.
Trouver les pages orphelines.
Le diagnostic le plus rentable, et celui qu'un crawl seul est structurellement incapable de produire. Il faut donner au crawler des sources d'URLs qu'il n'aurait jamais atteintes par les liens.
- 01
Connecter les sources externes
API Search Console (URLs qui reçoivent des impressions), API Analytics (URLs qui reçoivent des visites), et le sitemap XML. Trois inventaires d'URLs indépendants du maillage.
- 02
Lancer le rapport de pages orphelines
Il liste les URLs connues de ces sources mais jamais atteintes par le crawl. En version gratuite, exporter les URLs de GSC et du sitemap, puis comparer dans un tableur : le principe est identique, seul le confort change.
- 03
Trier avant de corriger
Toutes les orphelines ne méritent pas un lien. Une page qui reçoit encore du trafic doit être remaillée d'urgence. Une page obsolète depuis trois ans doit sortir du sitemap et passer en 410. Le rapport ne fait pas cette distinction à votre place.
Le mode liste.
Le second mode de l'outil, moins connu et pourtant décisif dans deux situations. Au lieu de suivre les liens, le crawler teste une liste d'URLs fournie telle quelle.
- Valider un plan de redirections. Passer la liste des anciennes URLs avant et après une bascule. Chaque ligne doit renvoyer un seul 301 vers une URL en 200. C'est le contrôle qui sauve une migration, et il coûte dix minutes.
- Contrôler des pages porteuses de backlinks. Vérifier en masse que les pages qui hébergent vos liens sont bien en 200 et indexables. Un lien sur une page morte ou en noindex ne transmet rien. Voir netlinking.
- Auditer un sitemap. Charger le sitemap en mode liste vérifie que chaque URL déclarée est canonique, indexable et en 200. Un sitemap qui liste des redirections envoie des signaux contradictoires. Voir sitemap XML.
Trier plutôt que tout corriger.
Le piège de l'outil tient en une phrase : il liste, il ne hiérarchise pas. Un crawl de 500 URLs remonte facilement 800 lignes signalées, dont la majorité n'a aucun impact réel.
// à retenir
Deux filtres avant toute décision. D'abord, ne garder que les pages indexables : une meta description manquante sur une page en noindex n'est pas un problème, et l'outil ne fait pas la différence. Ensuite, pondérer par la valeur business : un blocage sur 3 000 archives sans trafic pèse moins que le même sur 12 fiches produit. Trier par volume est le réflexe de l'outil ; trier par valeur est le travail de l'auditeur.
Les fausses erreurs classiques
- Meta descriptions manquantes. Sur des milliers de pages de longue traîne, ne pas en écrire est souvent le bon choix. Voir title et meta description.
- Liens sortants cassés. Vers des sites tiers morts depuis des années. Désagréable pour le lecteur, sans effet sur votre indexation.
- Pages "trop peu de mots". Le seuil est arbitraire et fixé par l'outil, pas par Google. Une page de contact de 80 mots est parfaite.
- Titles dupliqués sur des pages non indexables. Symptôme sans conséquence tant que les pages restent hors index.
Où va ce crawl ensuite
Le crawl est la matière première, pas la conclusion. Il alimente la méthode en 6 passes de l'audit SEO technique, qui donne l'ordre de traitement et la grille de priorisation. Sur un catalogue, il se croise avec les logs pour mesurer le gaspillage de crawl : voir SEO e-commerce et crawl budget.
Questions fréquentes.
La version gratuite de Screaming Frog suffit-elle ?
Pour la majorité des sites éditoriaux, oui. La limite est de 500 URLs par crawl, ce qui couvre un blog ou un site vitrine complet. Les restrictions réelles sont ailleurs : pas de connexion aux API Search Console et Analytics (donc pas de détection automatique des pages orphelines), pas de rendu JavaScript, pas de crawl planifié, pas de configuration personnalisée sauvegardée. Sur un site e-commerce ou un média, la licence devient vite indispensable, moins pour le volume que pour les croisements d'API.
Le crawler ne trouve que la page d'accueil, pourquoi ?
Trois causes, par ordre de fréquence. (1) La navigation est en JavaScript et le rendu est désactivé par défaut : le crawler ne voit aucun lien dans le HTML servi, exactement comme la première vague de Googlebot. (2) Le robots.txt bloque le crawl et le crawler le respecte par défaut. (3) Un pare-feu ou un anti-bot renvoie un 403 au user-agent du crawler. Tester dans cet ordre.
Faut-il activer le rendu JavaScript ?
Faire les deux crawls, et comparer. C'est l'écart entre le crawl HTML brut et le crawl avec rendu qui constitue le diagnostic : si le second trouve des pages, des liens ou du contenu que le premier manque, le site dépend du rendu client. Googlebot finit généralement par rendre le JavaScript, mais en seconde vague, avec un délai variable. Ne crawler qu'avec le rendu activé masque complètement ce problème. Voir JavaScript SEO.
Comment trouver les pages orphelines ?
Par croisement, jamais par le crawl seul, et c'est la limite conceptuelle de l'outil : un crawler part de la home et suit les liens, donc il ne peut par définition pas trouver une page qu'aucun lien ne pointe. La méthode : connecter les API Search Console et Analytics, puis lancer le rapport de pages orphelines, qui liste les URLs connues de ces sources mais absentes du crawl. En version gratuite, exporter les URLs de GSC et du sitemap, puis comparer manuellement. Voir maillage interne.
Le crawler respecte-t-il le robots.txt ?
Par défaut oui, et c'est le bon réglage pour reproduire le comportement de Googlebot. On peut l'ignorer pour auditer ce qui se cache derrière un Disallow, ce qui est parfois utile pour mesurer le volume d'URLs bloquées. Attention : ignorer le robots.txt sur un gros site peut déclencher un crawl massif et faire tomber le serveur. Limiter la vitesse de crawl avant, jamais après.
Quel rapport regarder en premier ?
Les codes de réponse, toujours. Trier par code : les 5xx sont une urgence, les 403 signalent un blocage de Googlebot, les chaînes de redirections gaspillent du crawl. Ensuite seulement, la colonne des directives d'indexabilité. Les rapports de titles et de meta descriptions arrivent en dernier : ce sont des sujets de taux de clic, pas d'indexation. Cet ordre est celui de l'audit SEO technique, et il n'est pas négociable.
Comment crawler un site en préproduction protégé ?
Le crawler gère l'authentification HTTP basique, ce qui couvre la plupart des recettes protégées par mot de passe. Pour une authentification par formulaire, la version payante permet de se connecter dans un navigateur intégré et de conserver la session. Point de vigilance : une préproduction est presque toujours en noindex global, ce qui fera remonter toutes les pages comme non indexables. C'est normal, et c'est précisément ce qu'il faudra vérifier à la mise en ligne.
Le crawler remonte 800 erreurs, faut-il tout corriger ?
Non, et c'est le piège principal de l'outil. Un crawler ne hiérarchise pas : il liste. Beaucoup de ces lignes n'ont aucun impact (meta descriptions manquantes sur des pages non indexables, liens sortants cassés vers des sites tiers morts, "erreurs" H1 sur des pages de service). Filtrer d'abord sur les pages indexables, puis pondérer par la valeur business des URLs concernées. Le tri est le travail ; la liste n'est que la matière première.
// passer à l'action
Tester une URL avant de crawler tout le site.
Le diagnostic applique les mêmes contrôles d'indexabilité qu'un crawler, sur une seule page et sans installation.