Screaming Frog : le guide

Mis à jour le 23 octobre 2026

Un site de quelques dizaines de pages se vérifie à la main. Au-delà, impossible de contrôler une à une toutes les balises, tous les liens et toutes les redirections. C’est le rôle d’un crawler comme Screaming Frog : il fait le tour du site en quelques minutes et vous rend un inventaire complet.

Cette page explique à quoi sert l’outil, comment lancer un premier crawl et quelles vérifications faire en priorité. C’est l’un des instruments de base du SEO technique.

Par Alexandre Montenon, consultant SEO et GEO depuis 2011

Screaming Frog : ce que fait l’outil

Screaming Frog SEO Spider est édité par une société britannique. On lui donne une URL de départ, il suit les liens qu’il trouve, page après page, et collecte pour chacune les éléments que regarde un moteur de recherche. Le résultat se présente sous forme de tableaux filtrables, exportables vers un tableur.

Le guide utilisateur de l’éditeur indique que la version gratuite permet d’analyser jusqu’à 500 URL à la fois, que la licence coûte 199 £ par an et supprime cette limite, que l’outil fonctionne sous Windows, macOS et Ubuntu, et qu’il propose deux modes principaux : le mode Spider, qui suit les liens à partir d’une URL, et le mode List, qui analyse une liste d’URL fournie.

Pour un site vitrine ou un petit blog, la version gratuite suffit souvent. La licence devient utile au-delà de 500 URL, ou pour suivre un site dans le temps.

Lancer un premier crawl

1. Choisir le mode

Le mode Spider convient à un audit complet : vous saisissez l’URL de l’accueil, l’outil suit les liens. Par défaut, il reste sur le sous-domaine saisi. Le mode List sert à vérifier une liste précise, par exemple les anciennes URL d’un site avant une refonte, pour contrôler qu’elles redirigent bien.

2. Régler la configuration

Quelques réglages changent beaucoup le résultat : respecter ou non le fichier robots.txt, suivre ou non les liens en nofollow, inclure les sous-domaines, activer le rendu JavaScript si le site en dépend. Sur un site en production, limitez la vitesse du crawl pour ne pas surcharger le serveur.

3. Lancer et attendre

La barre de progression indique le nombre d’URL trouvées. Sur un petit site, quelques minutes suffisent. Sur un site de plusieurs milliers de pages, comptez davantage, et lancez de préférence le crawl à un moment où le site reçoit peu de visites, pour ne pas ralentir la navigation des clients pendant l’analyse.

4. Lire les onglets

Chaque onglet correspond à un type d’information : codes de réponse, URL, titres de page, meta descriptions, balises H1 et H2, images, canonical, directives. Le panneau de droite résume les problèmes détectés, avec un filtre par type.

Les vérifications prioritaires

Les erreurs 404 et les liens cassés. Filtrez les codes 4xx, puis regardez quelles pages contiennent ces liens (onglet des liens entrants) pour les corriger à la source.

Les redirections internes. Un lien interne qui passe par une redirection 301 fonctionne, mais il ralentit le parcours du robot : remplacez-le par l’URL finale. Repérez aussi les chaînes de redirections.

Les titres et meta descriptions. Manquants, en double, trop longs ou trop courts. Les doublons signalent souvent deux pages qui se font concurrence.

Les balises H1. Absentes ou multiples, ou identiques au title partout sans réflexion.

L’indexabilité. Les pages marquées « non indexables » : balise noindex, canonical vers une autre URL, blocage par le robots.txt. Vérifiez que chaque exclusion est volontaire. La page sur le fichier robots.txt détaille ce qu’il bloque et ce qu’il ne bloque pas.

La profondeur. Le nombre de clics nécessaires pour atteindre une page depuis l’accueil. Les pages importantes doivent être proches.

Les images. Poids excessif, texte alternatif manquant. Commencez par les images des pages les plus visitées.

Le rendu JavaScript

De nombreux sites construisent une partie de leur contenu avec JavaScript. Google explique qu’il traite les applications JavaScript en trois phases : le crawl, le rendu et l’indexation. Si votre site affiche des menus, des textes ou des liens uniquement après exécution du JavaScript, lancez le crawl avec le rendu activé (fonction de la version sous licence) et comparez avec un crawl sans rendu. Les différences montrent ce qu’un robot qui n’exécute pas JavaScript ne voit pas, ce qui compte aussi pour certains robots d’assistants d’IA.

Trois usages courants

L’audit initial. Un crawl complet du site, croisé avec les données de la Search Console, pour établir la liste des corrections techniques et leur ordre de priorité.

La refonte ou la migration. Avant la mise en ligne du nouveau site, on crawle l’ancien pour conserver la liste complète de ses URL. Après la mise en ligne, on passe cette liste en mode List : chaque ancienne URL doit rediriger, en une seule étape, vers la nouvelle page équivalente. Les erreurs repérées le jour même coûtent beaucoup moins cher que celles découvertes trois mois plus tard dans la baisse du trafic.

Le contrôle régulier. Un crawl mensuel ou trimestriel, comparé au précédent, détecte les pages cassées par une mise à jour, les liens vers des contenus supprimés, les balises vidées par une extension. Sur un site qui publie souvent, c’est le moyen le plus simple de garder une base technique saine.

Dans tous les cas, exportez les résultats vers un tableur et ajoutez une colonne « action » et une colonne « responsable » : le rapport devient alors une liste de tâches, et non un énième document.

Lire les résultats sans s’affoler

Un premier crawl produit souvent des centaines d’alertes. Toutes ne se valent pas. Classez-les en trois groupes :

• Bloquant : pages importantes en erreur, non indexables par accident, inaccessibles.
• Gênant : liens cassés, redirections internes, doublons de titres sur des pages qui se concurrencent.
• Cosmétique : meta descriptions un peu longues, images légèrement lourdes sur des pages secondaires.

Traitez le premier groupe tout de suite, planifiez le deuxième, et ne passez pas des jours sur le troisième. Après corrections, relancez un crawl pour vérifier, puis vérifiez dans la Search Console que Google a bien pris en compte les changements, en suivant la démarche décrite sur la page consacrée à l’indexation Google.

Les alternatives

D’autres crawlers existent, en logiciel à installer ou en service en ligne, gratuits ou payants. Les critères de choix sont toujours les mêmes : nombre d’URL analysables, rendu JavaScript, possibilité de planifier les crawls et de comparer deux passages, connexion aux données de la Search Console, facilité d’export. La Search Console elle-même, gratuite, ne remplace pas un crawler : elle montre ce que Google a vu, pas l’état complet du site à un instant donné. Les deux se complètent.

Les erreurs fréquentes

Crawler sans configurer. Les résultats incluent des URL de filtres ou de paramètres qui faussent l’analyse.

Traiter toutes les alertes comme urgentes. Le temps passe sur des détails.

Oublier le JavaScript. Un crawl sans rendu peut sous-estimer, ou surestimer, ce que voient les robots.

Ne jamais relancer. Un audit ponctuel ne détecte pas les erreurs apparues depuis.

Surcharger le serveur. Un crawl trop rapide sur un hébergement modeste peut ralentir le site pour les visiteurs.

Exemple fictif : une boutique de vins en ligne

Pour illustrer, un cas inventé. Une boutique de vins de 1 200 pages lance un crawl après une mise à jour de son thème. Le rapport révèle 85 liens internes vers des fiches produits supprimées, 300 liens qui passent par des redirections, et une catégorie entière marquée noindex par erreur. Le noindex est retiré le jour même, les liens cassés sont corrigés depuis les pages qui les contiennent, et les redirections internes remplacées par les URL finales. Un nouveau crawl une semaine plus tard confirme les corrections. Les éléments de cet exemple sont inventés pour l’illustration.

Questions fréquentes sur Screaming Frog