Un client m'appelle un mardi matin, paniqué. Son trafic a chuté de 38 % en trois semaines. Il a vérifié ses mots-clés, relu ses articles, rien. Je lance un crawl sur son site : 1 247 URLs explorées, 412 réponses en 404, et — le vrai problème — 89 pages stratégiques passées en noindex par un plugin mal configuré après une mise à jour. Deux heures de diagnostic. Trois jours pour tout remettre d'aplomb. Sans crawler, on y passait la semaine à cliquer à la main.
C'est exactement à ça que sert Screaming Frog SEO Spider. Pas à faire joli dans un rapport d'audit. À trouver, vite, ce qui casse votre référencement. Et si vous vous contentez de lire le tableau de bord sans prioriser, vous passerez à côté de l'essentiel.
Points clés à retenir
- Le crawler simule le passage d'un robot : il suit les liens, enregistre les codes de réponse et lit les balises de chaque page.
- La version gratuite plafonne à 500 URLs. Au-delà, il faut la licence (environ 245 €/an).
- Un crawl brut remonte facilement plusieurs centaines d'alertes. 95 % d'entre elles ne valent pas votre temps.
- Priorisez toujours par impact business, jamais par ordre alphabétique des onglets.
- Un crawl sans filtre personnalisé est un crawl inutile. La configuration avant lancement fait 70 % du travail.
- Le crawler détecte les symptômes. La cause, elle, est presque toujours ailleurs (plugin, redirection serveur, balisage).
Comment Screaming Frog détecte concrètement les erreurs SEO
Screaming Frog fonctionne comme un robot d'indexation. Il part d'une URL de départ, récupère le HTML, extrait tous les liens, puis recommence sur chaque lien trouvé. Page après page, il constitue une carte de votre site avec, pour chaque URL, une série d'informations : code HTTP, balise title, meta description, canonique, directives robots, hreflang, données structurées, temps de réponse, taille de page.
Ce que la plupart des guides oublient de dire : ce n'est pas l'outil qui trouve les erreurs. C'est vous, à travers les filtres et les vues qu'il expose. L'outil remplit une base de données. Vous décidez quoi regarder dedans.
Les onglets qui comptent vraiment
Sur les 30+ onglets disponibles, une poignée suffit pour 90 % des audits techniques :
- Response Codes : les 404, les 500, les redirections en chaîne. Le point de départ de tout.
- Page Titles : manquants, dupliqués, trop longs, trop courts. Un classique sous-estimé.
- Meta Description : absence, duplications, longueur hors norme.
- Canonicals : canoniques cassées, contradictoires, auto-référentes mal formées.
- Directives : pages en noindex ou nofollow qu'on voudrait indexables, et inversement.
- Internal Links : pages orphelines, liens vers des redirections, hiérarchie de maillage.
- Et un mien préféré, souvent oublié — Security, qui signale les URLs en HTTPS pointant vers du HTTP.
Un audit que j'ai mené l'an dernier sur un site e-commerce : 6 200 URLs, trois heures de crawl. Les deux alertes qui ont réellement changé la donne — 1 100 pages en noindex involontaire et 340 liens internes pointant vers une chaîne de 301 — se trouvaient dans deux onglets qu'on ouvre rarement : Directives et Internal Links. Le reste était du bruit.
Préparer le crawl pour éviter le bruit
Par défaut, Screaming Frog crawle tout, en respectant les règles robots.txt. C'est rarement ce qu'on veut. Avant d'appuyer sur Start, il y a trois décisions à prendre.
Paramétrer avant de lancer
Dans le menu Configuration → Spider, cochez « Crawl subdomains » uniquement si votre site en utilise (blog sur blog.exemple.com, etc.). Dans Robots.txt, désactivez « Respect robots.txt » uniquement pour un audit interne — jamais pour crawler un site tiers sans autorisation, cela va sans dire.
Pour le rendu JavaScript : activez l'option « JavaScript Rendering » si votre site utilise du contenu injecté côté client (React, Vue, Next.js). Une page vide pour le crawler est souvent une page vide pour Googlebot. J'ai vu un client perdre la moitié de son contenu indexé à cause de ça après une refonte en Next.js — le crawl avec rendu JS a immédiatement révélé le problème.
Exclusions et inclusions : votre meilleur filtre
Vous ne voulez pas crawler vos URLs de recherche interne, vos filtres à facettes, vos sessions, vos paramètres UTM. Ces pages génèrent des milliers d'URLs dupliquées qui polluent vos rapports. Dans Configuration → Exclude, ajoutez les motifs : ?s=, ?utm_, ?filter=. C'est cinq minutes à passer. Cela vous économise deux heures de lecture inutile.
À l'inverse, pour vérifier un point précis — un lot de pages produit, une section blog — utilisez l'onglet Mode → List et collez vos URLs. Le crawl passe de 6 000 à 200 pages. Beaucoup plus digeste.
Prioriser les erreurs : quelles alertes traiter en premier
Le vrai savoir-faire, celui sur lequel aucun tutoriel ne s'attarde, se joue après le crawl. Devant 300 alertes, dans quel ordre agir ?
Ma grille tient en quatre niveaux. Je l'applique depuis deux ans, elle ne m'a jamais trompé.
| Niveau | Type d'erreur | Impact typique | Délai de traitement |
|---|---|---|---|
| 1 — critique | Pages stratégiques en 404, noindex accidentel, redirections cassées | Perte immédiate de trafic et de positions | Sous 48 h |
| 2 — fort | Canoniques contradictoires, chaînes de redirection 301, hreflang mal formés | Dilution du signal, désindexation progressive | Dans la semaine |
| 3 — moyen | Titles dupliqués, meta descriptions absentes, liens internes vers redirections | Click-through et maillage interne dégradés | Dans le mois |
| 4 — cosmétique | Meta trop longues, images sans alt mineures, URLs longues | Effet marginal | Quand vous avez le temps |
Une règle simple pour arbitrer
Avant chaque correction, posez-vous la question : cette page rapporte-t-elle du trafic ou des conversions aujourd'hui ? Si oui, elle passe en priorité 1. Si non, elle peut attendre. Un 404 sur une ancienne page tag qui reçoit douze visites par an ne mérite pas votre après-midi.
Sur un audit récent, cette règle a réduit une liste de 280 alertes à 23 corrections réellement utiles. Les 257 restantes, après vérification, n'avaient aucun effet mesurable. On les a documentées, archivées, oubliées.
Lire les rapports sans se perdre
Chaque ligne du crawler contient une trentaine de colonnes. Vous n'avez pas besoin de tout afficher. Clic droit sur l'en-tête → décochez tout → réactivez les cinq ou six champs utiles à votre question du moment.
Pour un audit 404, gardez : Address, Status Code, Inlinks, Content Type. Pour un audit de titres : Address, Title 1, Title 1 Length, Title 1 Pixel Width. La largeur en pixels est plus fiable que la longueur en caractères, car elle tient compte de la typographie.
Un réflexe à prendre : ouvrez la vue Save Report et filtrez côté Excel ou Google Sheets. Le tri par nombre de liens entrants (Inlinks) situe immédiatement l'importance relative d'une page. Un 404 avec 47 liens entrants, ce n'est pas la même histoire qu'un 404 avec zéro.
Faut-il vraiment payer la licence ?
La version gratuite suffit pour un site vitrine de moins de 500 pages. Au-delà, ou pour accéder aux fonctions comme la comparaison de crawls, l'intégration Google Analytics, la Search Console ou le rendu JavaScript, la licence devient nécessaire. À environ 245 €/an, elle s'amortit dès le premier audit un peu sérieux. Pour un consultant, c'est un non-sujet.
Combien de temps prend un crawl complet ?
Sur un site de 1 000 pages sans rendu JS, comptez quinze à trente minutes. Avec rendu JavaScript activé, multipliez par trois à cinq. Sur 100 000 URLs, prévoyez plusieurs heures et surveillez la mémoire de votre machine. Le crawler est gourmand.
Trois pièges qui font perdre du temps
Crawler sans avoir exclu les paramètres. Vous vous retrouvez avec 40 000 URLs dont 38 000 sont des doublons de filtres. Le rapport est illisible, vous jetez l'outil en vous disant qu'il ne sert à rien.
Traiter les alertes par ordre d'apparition. Vous corrigez trois 404 sans importance pendant qu'un noindex accidentel sur votre page produit phare attend sagement depuis deux semaines.
Confondre symptôme et cause. Le crawler signale une 404. La cause, c'est un lien interne cassé dans votre template, ou une règle de réécriture Apache mal écrite. Corriger la 404 sans corriger le lien qui la génère garantit que le problème reviendra au prochain déploiement.
Un dernier point, franchement, sur lequel je me suis planté au début : je crawlais sans jamais comparer deux passages. Aujourd'hui, je lance systématiquement un crawl de référence, puis un crawl un mois plus tard, et je compare. La fonction Compare vous montre ce qui a changé : nouvelles erreurs, erreurs corrigées, pages apparues ou disparues. C'est là que vous voyez si votre travail paie. Sans ce différentiel, vous corrigez à l'aveugle, dans le vide.
Screaming Frog n'est pas un outil qui trouve les erreurs à votre place. C'est un microscope. Ce qu'on y voit dépend entièrement de ce qu'on cherche — et de ce qu'on accepte de ne pas regarder.
