Crawl avec Screaming Frog
configurer une exploration propre

Un bon audit commence par un bon crawl. Screaming Frog explore ton site comme le ferait Googlebot, mais la qualité des données dépend entièrement de ta configuration : mode, rendu, limites et exclusions.

Mal configuré, un crawl rate des pages, en explore des inutiles ou sature ton serveur. Cette page te donne la configuration propre, étape par étape.

Ce que signifie crawler un site

Crawler un site, c’est l’explorer automatiquement en suivant ses liens, exactement comme le fait un moteur de recherche. Screaming Frog part d’une URL de départ, récupère la page, extrait tous ses liens, puis visite chacun d’eux à son tour. De proche en proche, l’outil reconstitue la carte complète de ton site : chaque page, chaque lien, chaque ressource. C’est cette exploration qui alimente ensuite toute l’analyse technique.

La qualité de cette exploration conditionne tout le reste. Un crawl mal configuré va rater des pages entières, en explorer des milliers d’inutiles, ou saturer ton serveur au point de fausser les temps de réponse. À l’inverse, un crawl bien réglé te donne une photographie fidèle et exploitable de ton site, sans angle mort ni bruit parasite. C’est le socle indispensable d’un audit SEO mené avec Screaming Frog.

Comprendre le crawl, c’est aussi comprendre comment Google voit ton site. Les paramètres que tu ajustes dans Screaming Frog (respect du robots.txt, rendu JavaScript, gestion des paramètres d’URL) sont exactement ceux qui déterminent ce que le moteur explore et indexe. Maîtriser la configuration de crawl, c’est donc maîtriser la façon dont ton site est perçu par les robots.

Mode Spider ou mode List : lequel choisir ?

Screaming Frog propose deux modes de crawl fondamentaux. Le mode Spider est le mode par défaut : tu saisis une URL de départ et l’outil explore le site en suivant les liens, page après page. C’est le mode à utiliser pour un audit complet, quand tu veux découvrir toute la structure d’un site et cartographier son maillage interne. Il révèle aussi les pages orphelines et la profondeur de clic de chaque URL.

Le mode List fonctionne différemment : tu fournis une liste d’URLs précises (colle-les ou importe un fichier) et Screaming Frog ne crawle que celles-là, sans suivre les liens. C’est le mode idéal pour vérifier un lot précis de pages, contrôler des URLs après corrections, ou auditer un sitemap en important directement son contenu. Il est rapide, ciblé et parfait pour les contrôles ponctuels.

Régler la vitesse et respecter ton serveur

Par défaut, Screaming Frog crawle vite, avec cinq threads simultanés. Sur un gros site ou un hébergement mutualisé, cette cadence peut surcharger le serveur, ralentir le site pour les vrais visiteurs, voire déclencher un blocage de ton adresse IP. La première règle d’un crawl propre est donc d’adapter la vitesse à la robustesse du site que tu explores.

Tu règles cela dans la configuration, section Speed. Tu peux limiter le nombre de threads et fixer un plafond d’URLs par seconde. Sur un site fragile, descendre à deux ou trois requêtes par seconde évite tout problème. Sur ton propre serveur robuste, tu peux au contraire monter la cadence pour gagner du temps. L’objectif est toujours le même : un crawl représentatif sans effet de bord sur la production.

Surveille pendant le crawl la colonne Response Time. Si les temps de réponse s’allongent au fur et à mesure, c’est le signe que tu satures le serveur et que tes mesures deviennent fausses. Réduis alors la vitesse et relance. Un crawl qui dégrade lui-même les performances du site fausse justement l’indicateur que tu cherches à mesurer, c’est un piège classique du débutant.

Activer le rendu JavaScript quand c’est nécessaire

Beaucoup de sites modernes construisent leur contenu avec du JavaScript, via des frameworks comme React, Vue ou Angular. Sur ces sites, le code HTML brut renvoyé par le serveur est presque vide : le vrai contenu n’apparaît qu’après exécution du JavaScript par le navigateur. Un crawl classique qui ne lit que le HTML brut passe alors complètement à côté du contenu et des liens réels.

Screaming Frog sait gérer ce cas grâce au rendu JavaScript. Dans la configuration, section Rendering, choisis le mode JavaScript. L’outil exécute alors le code exactement comme un navigateur et crawle le contenu final, celui que voit réellement l’utilisateur et que Google indexe après rendu. C’est indispensable pour auditer correctement une application web moderne, sous peine de conclusions totalement fausses.

Attention : le rendu JavaScript ralentit considérablement le crawl, car chaque page doit être exécutée dans un moteur de navigateur. Ne l’active que si ton site en a réellement besoin. Pour vérifier, compare le HTML brut et le HTML rendu d’une page test : si le contenu principal n’apparaît que dans le rendu, active le mode JavaScript. Sinon, reste en mode HTML classique, bien plus rapide.

Respecter ou ignorer le robots.txt

Le fichier robots.txt indique aux robots quelles zones du site ils peuvent ou ne peuvent pas explorer. Par défaut, Screaming Frog le respecte, exactement comme Googlebot. C’est le comportement recommandé pour un crawl représentatif : tu vois ton site comme le moteur le voit réellement, avec les mêmes zones bloquées. Cela te permet aussi de vérifier que ton robots.txt ne bloque pas par erreur des pages importantes.

Dans certains cas, tu veux au contraire ignorer le robots.txt pour explorer l’intégralité du site, y compris les zones bloquées. C’est utile pour auditer des pages en préproduction, ou pour vérifier ce qui se cache derrière une directive Disallow. Le réglage se trouve dans la configuration, section Robots.txt, où tu peux choisir de le respecter, de l’ignorer, ou d’utiliser une version personnalisée pour tester des modifications avant de les déployer.

La bonne gestion du robots.txt est un sujet à part entière, car une seule ligne mal placée peut bloquer tout un site aux moteurs. Je détaille comment l’auditer et le tester dans mon guide dédié au robots.txt avec Screaming Frog, où j’explique comment simuler des modifications sans risque avant de les mettre en production.

Exclure le bruit : paramètres, filtres et include

Sur beaucoup de sites, une grande partie des URLs crawlées sont du bruit : paramètres de tri, filtres de navigation à facettes, identifiants de session, pages de résultats de recherche interne. Ces URLs multiplient artificiellement le nombre de pages, gaspillent ton budget de crawl et polluent l’analyse. Un crawl propre commence par exclure ce bruit pour se concentrer sur les vraies pages du site.

Screaming Frog offre deux outils complémentaires pour cela. La fonction Exclude, dans la configuration, te permet de définir des motifs d’URL à ne jamais crawler, par exemple toutes les URLs contenant un point d’interrogation ou un paramètre précis. À l’inverse, la fonction Include restreint le crawl à un sous-ensemble précis, par exemple un seul répertoire. Combinées, elles te donnent un contrôle total sur le périmètre exploré.

• ✓Exclure les URLs à paramètres de tri et de filtre
• ✓Exclure les pages de résultats de recherche interne
• ✓Restreindre le crawl à un répertoire précis avec Include
• ✓Gérer les paramètres d’URL dans la section dédiée
• ✗Ne jamais crawler tout un site à facettes sans exclusions

Choisir le bon User-Agent

Le User-Agent est l’identité que Screaming Frog présente au serveur pendant le crawl. Par défaut, il s’annonce comme Screaming Frog SEO Spider. Mais tu peux le changer pour te faire passer pour Googlebot, Bingbot ou un navigateur mobile. C’est un réglage puissant, car certains sites renvoient un contenu différent selon le visiteur qui se présente.

Crawler en te faisant passer pour Googlebot mobile est particulièrement utile, car Google indexe désormais en priorité la version mobile des sites. En adoptant ce User-Agent, tu vois exactement ce que Google voit lors de son exploration, ce qui te permet de détecter les cas de contenu servi différemment aux robots et aux visiteurs, une pratique risquée appelée cloaking.

Le réglage se trouve dans la configuration, section User-Agent. Choisis dans la liste prédéfinie ou saisis une valeur personnalisée. Pour un audit standard, je crawle généralement en Googlebot mobile afin de coller au plus près de la réalité de l’indexation. C’est un réflexe simple qui évite bien des mauvaises surprises sur des sites au comportement variable.

Sauvegarder ta configuration pour la réutiliser

Une fois que tu as construit une configuration de crawl propre, adaptée à ta façon de travailler, ne repars pas de zéro à chaque audit. Screaming Frog te permet de sauvegarder l’ensemble de tes réglages dans un fichier de configuration réutilisable. Tu le recharges en un clic au début de chaque nouveau projet, et tu retrouves instantanément tes exclusions, ta vitesse, ton User-Agent et tes options de rendu.

Je conserve personnellement plusieurs configurations types selon le contexte : une pour les petits sites vitrines, une pour les gros sites e-commerce avec beaucoup d’exclusions de facettes, une pour les applications JavaScript avec rendu activé. Cette bibliothèque de configurations me fait gagner un temps considérable et garantit la cohérence de mes audits d’un projet à l’autre.

La sauvegarde se fait via le menu File, option Configuration, puis Save As. Le chargement suit le même chemin avec Load. Prends l’habitude de nommer clairement tes fichiers de configuration selon leur usage. C’est un petit investissement de départ qui transforme ta pratique du crawl en un processus rapide, reproductible et fiable, projet après projet.

Le crawl de sitemap XML pour comparer

Au-delà du crawl classique en mode Spider, Screaming Frog sait crawler directement un sitemap XML. Tu fournis l’URL de ton sitemap, et l’outil récupère toutes les URLs qu’il liste, puis les crawle une par une. C’est une opération très utile pour vérifier que ton sitemap est propre : que toutes les URLs qu’il déclare répondent bien en 200, sans 404, sans redirection ni page bloquée.

L’intérêt va plus loin quand tu compares le crawl du sitemap au crawl en mode Spider. D’un côté, tu as les pages que ton site déclare vouloir indexer via le sitemap. De l’autre, tu as les pages que ton maillage interne rend réellement accessibles. L’écart entre les deux révèle deux problèmes classiques : des pages dans le sitemap mais introuvables par le maillage, et des pages accessibles mais absentes du sitemap.

Cette double lecture est précieuse pour un audit d’indexation. Une page présente dans le sitemap mais orpheline dans le maillage envoie un signal contradictoire à Google. Une page importante accessible mais absente du sitemap perd une occasion d’être découverte plus vite. Réconcilier ces deux sources, c’est garantir la cohérence entre ce que ton site déclare et ce qu’il expose réellement, un point que Screaming Frog met en lumière en un instant.

Gérer l’authentification et les environnements protégés

Certains sites, notamment en préproduction ou en recette, sont protégés par une authentification. Un crawl classique se heurte alors à un mur : l’outil reçoit une demande d’identification et ne peut pas explorer le site. Screaming Frog gère ce cas grâce à la prise en charge de l’authentification, qu’elle soit de type formulaire ou de type serveur, ce qui te permet d’auditer un site avant même sa mise en ligne.

C’est une fonction essentielle pour valider un site avant son lancement. Tu peux auditer une refonte complète en préproduction, vérifier que toutes les balises sont en place, que les redirections sont prêtes, que le robots.txt est correctement configuré, et corriger les problèmes avant que le site ne soit visible du public et des moteurs. Auditer avant la mise en ligne évite les catastrophes découvertes trop tard, une fois le site indexable.

Le réglage se trouve dans la configuration, section Authentication. Tu y renseignes les identifiants nécessaires, et Screaming Frog les utilise pour accéder aux zones protégées. Attention toutefois à ne jamais crawler un environnement de préproduction avec un User-Agent Googlebot sans avoir bloqué l’indexation, au risque de voir ta recette apparaître dans les résultats de recherche. La prudence sur les environnements protégés reste de mise.

Surveiller la mémoire et crawler les très gros sites

Par défaut, Screaming Frog stocke les données de crawl dans la mémoire vive de ton ordinateur. Cette approche est rapide mais limitée : sur un très gros site de plusieurs centaines de milliers d’URLs, tu peux saturer la mémoire et voir l’outil ralentir ou planter. Il existe heureusement un mode de stockage sur disque, qui permet de crawler des sites bien plus volumineux au prix d’une vitesse légèrement réduite.

Le choix entre stockage en mémoire et stockage sur disque se fait dans la configuration, selon la taille du site à auditer. Pour un site de quelques milliers de pages, la mémoire suffit largement et offre la meilleure réactivité. Pour un gros e-commerce ou un site média de plusieurs centaines de milliers d’URLs, le stockage sur disque devient indispensable, et il est recommandé d’allouer davantage de mémoire à l’application dans ses paramètres.

Bien dimensionner ce réglage évite les crawls interrompus en cours de route, particulièrement frustrants sur les gros sites où une exploration complète peut prendre des heures. Un crawl qui plante à quatre-vingt pour cent te fait perdre tout le travail. Anticiper la volumétrie et choisir le bon mode de stockage dès le départ fait partie de la préparation d’un crawl propre sur les sites d’envergure, là où l’improvisation coûte cher en temps.

Filtrer et segmenter un crawl pour aller à l’essentiel

Un crawl brut de plusieurs milliers d’URLs est indigeste. Le vrai travail commence avec le filtrage et la segmentation, qui transforment cette masse de données en informations exploitables. Screaming Frog te permet de filtrer par répertoire, par type de contenu, par code de réponse ou par n’importe quel critère de la vue en colonnes. C’est cette capacité à isoler des sous-ensembles qui rend l’audit réellement actionnable.

J’utilise beaucoup l’inclusion et l’exclusion par expression régulière pour cadrer mes crawls. Sur un gros site, je crawle souvent une seule section à la fois, par exemple uniquement le blog ou uniquement le catalogue produit. Cela réduit le bruit, accélère l’analyse et me permet de livrer des recommandations ciblées par équipe. Un responsable e-commerce n’a que faire des problèmes du blog, et inversement.

La segmentation personnalisée, disponible dans les versions récentes, va encore plus loin. Tu définis des groupes d’URLs selon tes propres règles, et Screaming Frog affiche ensuite tes indicateurs par segment. Tu vois d’un coup d’œil quelle section du site concentre le plus d’erreurs, quelles pages profondes manquent de maillage, quel répertoire traîne des balises manquantes. C’est un gain de clarté énorme sur les architectures complexes.

Interpréter les données de crawl sans se noyer

Savoir lancer un crawl ne suffit pas : encore faut-il lire les résultats dans le bon ordre. Je commence toujours par les codes de réponse, car une 404 ou une 5xx est un problème immédiat. Je passe ensuite aux directives d’indexation, aux balises title et meta description, puis aux enjeux de structure comme la profondeur de clic et le maillage interne. Cette hiérarchie évite de se perdre dans les détails avant d’avoir traité l’essentiel.

L’onglet de vue d’ensemble, sur la droite de l’interface, est mon point de départ. Il résume en pourcentages l’état du site : part de pages indexables, taux de titles manquants, proportion de contenu dupliqué. Ces ratios donnent instantanément le niveau de santé général et orientent l’audit vers les postes les plus dégradés. Un site avec quarante pour cent de titles dupliqués n’a pas les mêmes priorités qu’un site propre à ce niveau.

Le piège, c’est de vouloir tout corriger d’un coup. Un crawl remonte toujours des dizaines de types de problèmes, et beaucoup sont mineurs. Mon rôle de consultant est de trier, de distinguer ce qui pèse vraiment sur le SEO de ce qui relève du confort. Un crawl bien interprété débouche sur une liste courte de chantiers prioritaires, pas sur un rapport de deux cents pages que personne ne lira jamais.

Sauvegarder et reprendre un crawl

Sur les gros projets, un crawl peut durer des heures. Perdre ce travail à cause d’une coupure ou d’une fermeture accidentelle serait frustrant. La version payante de Screaming Frog permet de sauvegarder un crawl en cours et de le reprendre plus tard, exactement là où il s’était arrêté. C’est une fonctionnalité que j’utilise systématiquement dès qu’un site dépasse quelques dizaines de milliers d’URLs.

Sauvegarder un crawl sert aussi à constituer un historique. En archivant le crawl de chaque audit, je peux revenir des mois plus tard sur l’état exact du site à une date donnée, comparer avec la situation actuelle et mesurer les progrès. Ces archives sont précieuses pour documenter l’impact d’un chantier technique auprès d’un client qui veut voir des résultats concrets.

Le passage en base de données plutôt qu’en mémoire vive, proposé dans la configuration, change tout sur ce point. Il permet de crawler des sites de plusieurs millions d’URLs sans saturer la RAM, et de conserver ces crawls sur disque de façon fiable. Pour un consultant qui enchaîne les audits de gros sites, activer ce mode de stockage est la première chose à configurer, avant même de lancer le moindre crawl.

Pense enfin à exporter régulièrement tes crawls dans un format ouvert comme le CSV. Un crawl sauvegardé au format natif de Screaming Frog ne se relit qu’avec le logiciel, alors qu’un export CSV se partage, s’intègre dans un tableur et se compare facilement d’un audit à l’autre. Cette double sauvegarde, native pour la reprise et CSV pour l’archivage, m’a déjà évité bien des mauvaises surprises sur des projets longs.

La qualité d’un audit dépend entièrement de la qualité du crawl qui l’alimente. Screaming Frog offre un contrôle total sur l’exploration : mode Spider ou List, vitesse adaptée au serveur, rendu JavaScript, gestion du robots.txt, exclusions et User-Agent. Bien réglé, il te donne une photographie fidèle et exploitable de ton site. Mal réglé, il rate des pages ou en explore des milliers d’inutiles.

Mon conseil pour démarrer : prends le temps de construire une configuration propre avant ton premier vrai audit, puis sauvegarde-la pour la réutiliser. Adapte la vitesse au serveur, active le rendu JavaScript seulement si le site en a besoin, et exclus le bruit des paramètres d’URL. Un quart d’heure de configuration t’évite des heures d’analyse faussée.