Un spécialiste SEO lance un audit technique d'un grand site — et après 10 minutes, Screaming Frog commence à afficher des 403 Forbidden ou 429 Too Many Requests. Le serveur de protection a pris le crawler pour un bot attaquant et a bloqué l'adresse IP. Le résultat — l'audit devra être redémarré, et il faudra expliquer au client pourquoi le rapport a été retardé. Le problème se résout par une configuration adéquate du proxy pour le crawler — voyons comment faire exactement.
Pourquoi les sites bloquent Screaming Frog lors de l'audit
Screaming Frog, Sitebulb, JetOctopus et Netpeak Spider fonctionnent techniquement de la même manière que les bots des moteurs de recherche : ils parcourent rapidement des milliers d'URL consécutivement, téléchargent HTML, CSS, JS et images, vérifient les redirections et les codes d'état. Du point de vue de la protection du site (Cloudflare, Qrator, DDoS-Guard, WAF intégré de l'hébergement), cela ressemble à une activité suspecte — trop de requêtes d'une seule IP en peu de temps.
Les blocages se produisent particulièrement souvent lors de l'audit :
- de grands magasins en ligne sur une infrastructure similaire à Wildberries avec leur propre protection contre le parsing ;
- de sites derrière Cloudflare avec le mode "Under Attack" activé ou un niveau de sécurité élevé ;
- de portails avec du contenu dynamique, où chaque requête génère une charge sur le serveur (recherche, filtres, listings de produits) ;
- de sites concurrents que vous analysez depuis un domaine qui n'est pas le vôtre — ils n'ont aucune raison de faire confiance à votre IP.
Une difficulté supplémentaire : si l'agence a une seule IP statique de bureau, et que l'audit des sites se fait régulièrement (plusieurs clients par jour), cette IP se retrouve rapidement sur les listes noires des systèmes de protection. Après cela, non seulement l'audit actuel est bloqué, mais aussi les futurs audits depuis la même adresse — même pour des sites qui s'ouvraient auparavant sans problème.
Comment reconnaître un blocage par les codes de réponse
Avant de changer les paramètres du proxy, il est important de comprendre ce qui se passe exactement. Screaming Frog affiche le code de réponse dans la colonne Code d'état — il est facile de déterminer la raison de l'arrêt du crawling.
| Code de réponse | Que signifie-t-il | Que faire |
|---|---|---|
| 403 Forbidden | IP bloquée par la protection du site | Changer d'IP, réduire la vitesse de crawling |
| 429 Too Many Requests | Limite de requêtes dépassée dans un intervalle de temps | Réduire le nombre de flux, ajouter un délai |
| 503 Service Unavailable | Serveur surchargé ou protection contre les bots activée | Changer d'User-Agent, utiliser une IP résidentielle |
| Pas de réponse / Timeout | IP sur liste noire, les requêtes n'atteignent pas le serveur | Remplacement complet du pool de proxies |
Si le même code apparaît massivement sur des milliers d'URL consécutives dans le rapport — c'est presque toujours un blocage par IP, et non un véritable problème du site. Vérifier l'hypothèse est simple : ouvrez l'URL problématique dans un navigateur normal depuis la même IP. Si la page s'ouvre normalement, mais que Screaming Frog reçoit un 403 — le problème vient du crawler, et non du site.
Quels proxies conviennent au SEO crawling
Le choix du type de proxy dépend de la tâche : audit ponctuel de son propre site, surveillance régulière des concurrents ou scan d'un marketplace protégé. Examinons trois types principaux et leur applicabilité pour les crawlers.
| Type de proxy | Vitesse | Risque de blocage | Quand utiliser |
|---|---|---|---|
| Proxies de centre de données | Élevée | Moyenne à élevée sur les sites protégés | Audit de son propre site sans protection stricte |
| Proxies résidentiels | Moyenne | Faible | Audit des concurrents, sites derrière Cloudflare, marketplaces |
| Proxies mobiles | Moyenne à faible | Minimale | Protections les plus agressives, audit ponctuel rare |
Pour la plupart des audits techniques réguliers, un bon équilibre est fourni par les proxies résidentiels — ils utilisent de vraies adresses IP de fournisseurs, donc la protection du site perçoit les requêtes du crawler comme du trafic d'utilisateur normal. Cela est particulièrement important si vous analysez non pas votre propre domaine, mais celui d'un concurrent ou un marketplace avec un système anti-bot strict.
Les proxies de centre de données restent une bonne option lorsque vous auditez votre propre site et pouvez préalablement ajouter la plage IP à la liste blanche au niveau du WAF ou de Cloudflare — alors la vitesse de scan sera maximale sans risque de blocages.
Configuration étape par étape du proxy dans Screaming Frog
Screaming Frog prend en charge les proxies "out of the box", la configuration prend quelques minutes :
- Ouvrez le programme et allez dans le menu Configuration → Système → Proxy.
- Cochez la case Utiliser le serveur proxy pour tout le trafic.
- Entrez l'adresse et le port du serveur proxy, obtenus auprès du fournisseur.
- Si le proxy nécessite une authentification par login et mot de passe — indiquez-les dans la fenêtre contextuelle lors de la première requête.
- Cliquez sur OK et redémarrez le crawling pour appliquer les paramètres.
Un point important : Screaming Frog, dans sa version gratuite et payante, ne peut travailler qu'avec un seul serveur proxy à la fois via l'interface intégrée. Si vous avez besoin d'une rotation IP à la volée (pertinent lors du scan de plus de 50 000 pages), utilisez un proxy avec changement automatique d'IP du côté du fournisseur — cela se configure non pas dans le crawler lui-même, mais dans le tableau de bord du service proxy, où l'intervalle de changement d'IP est défini (par exemple, toutes les 10 minutes ou à chaque nouvelle requête).
Ce schéma soulage la charge d'une seule adresse : le crawler continue de travailler avec un seul port, tandis que l'IP derrière lui change automatiquement, et le site ne voit pas une fréquence anormalement élevée de requêtes provenant d'une adresse spécifique.
Paramètres de vitesse et de flux pour les grands sites
Même avec un proxy fonctionnel, des paramètres de vitesse de crawling trop agressifs provoqueront un blocage. Dans Screaming Frog, cela est géré par la section Configuration → Vitesse. Les valeurs recommandées pour les sites de plus de 100 000 pages :
- Max Threads : 2–5 pour les sites protégés, 10–15 pour les sites sans protection stricte ;
- Max URI/s : limitez à 2–3 requêtes par seconde au départ, augmentez progressivement en surveillant les codes de réponse ;
- User-Agent personnalisé : dans la section Configuration → HTTP Header, utilisez un User-Agent d'un navigateur réel au lieu du standard "Screaming Frog SEO Spider", si le site bloque les crawlers par en-tête ;
- Respect robots.txt / crawl-delay : tenez compte de la directive Crawl-delay, si elle est spécifiée — l'ignorance conduit souvent à un ban au niveau du serveur.
Pour les sites avec une protection agressive contre les bots, il est également utile d'activer le mode JavaScript Rendering uniquement là où c'est réellement nécessaire (sites SPA sur React/Vue) — le rendu JS augmente considérablement la charge sur le serveur et augmente le risque de blocage lors du crawling via une seule IP.
Rotation IP lors du scan de plus de 100 000 pages
Plus le site est grand, plus il est important de répartir correctement la charge entre les adresses IP. Pour des audits de cette ampleur, deux schémas fonctionnent :
Rotation par temps. L'IP change automatiquement toutes les 5–15 minutes, indépendamment du nombre de requêtes. Convient pour un crawling long et uniforme, lorsque le scan s'étend sur plusieurs heures.
Rotation par requête. Chaque nouvelle requête HTTP part avec une nouvelle IP du pool. Ce mode offre une protection maximale contre les blocages, mais peut interférer avec le bon fonctionnement de l'autorisation basée sur les cookies ou des paramètres de session du site — pour un audit technique pur (collecte de codes d'état, redirections, méta-tags), ce n'est pas critique.
Pour les agences qui effectuent des audits parallèles de plusieurs sites clients, il est judicieux de diviser les pools d'IP par projet — cela empêche la situation où un blocage sur un domaine se propage "par erreur" à la réputation de l'IP lors du travail sur un autre site.
Conseil pratique : avant un grand audit, lancez un crawling test sur 500–1000 URL avec les paramètres de vitesse et de proxy actuels. Si aucune erreur 403/429 n'apparaît pendant ce temps, vous pouvez passer à l'échelle du scan sur l'ensemble du site.
Checklist avant le lancement de l'audit
- ✅ Proxy connecté et testé pour l'accessibilité (vérification via curl ou un navigateur séparé) ;
- ✅ Max Threads et Max URI/s réglés de manière conservatrice pour le premier passage ;
- ✅ User-Agent configuré correctement, ne suscitant pas de soupçons auprès du WAF ;
- ✅ Respect des robots.txt activé, si le site demande clairement de respecter le Crawl-delay ;
- ✅ JavaScript Rendering activé uniquement en cas de réelle nécessité ;
- ✅ Rotation IP configurée pour un volume de site de 20 000–30 000 pages ;
- ✅ Sauvegarde des progrès du crawling activée (Configuration → Sauvegarder le Crawl) en cas d'interruption de session ;
- ✅ Pour l'audit des marketplaces et des portails protégés, sélection de proxies résidentiels ou mobiles au lieu de ceux de centre de données.
Erreurs fréquentes lors du crawling via proxy
Vitesse trop élevée au départ. Les spécialistes mettent souvent le maximum de flux immédiatement, espérant accélérer l'audit. En conséquence, la protection du site réagit instantanément, et au bout de quelques minutes, tout le pool de proxies se retrouve sur liste noire.
Une seule IP statique pour tous les projets clients. Si l'agence utilise le même centre de données de proxy pour des dizaines d'audits par mois, la réputation de cette IP chute rapidement — les systèmes de protection de différents sites échangent des données sur les adresses suspectes via des bases de données communes (par exemple, Cloudflare IP Reputation).
Ignorer le geo-targeting. Si le site audité est configuré pour une région spécifique (par exemple, un magasin en ligne russe avec un blocage géographique du trafic étranger), l'utilisation de proxies avec des IP d'un autre pays provoquera elle-même une restriction d'accès — même sans crawling agressif.
Absence de surveillance pendant le processus. En lançant un crawling pendant plusieurs heures, les spécialistes ne vérifient souvent pas les codes de réponse intermédiaires. En conséquence, ils découvrent le problème seulement à la fin, lorsque la moitié du rapport est composée d'erreurs de blocage, et non de données réelles sur le site.
Conclusion
Les blocages lors d'un audit technique dans Screaming Frog se résolvent presque toujours par une combinaison de trois facteurs : le bon type de proxy, une vitesse de crawling raisonnable et une rotation IP adéquate. Pour les sites propres sans protection stricte, il suffit de proxies de centre de données avec ajout à la liste blanche. Pour l'audit des concurrents, des marketplaces et des sites derrière Cloudflare, des IP qui ressemblent à du trafic d'utilisateur normal sont nécessaires.
Si vous auditez régulièrement des domaines étrangers ou des plateformes protégées, nous vous recommandons de commencer par des proxies résidentiels — ils réduisent le risque de blocage sur les systèmes anti-bots les plus agressifs. Pour des tâches ponctuelles sur des ressources maximales protégées, envisagez des proxies mobiles, et pour des audits à grande échelle de votre propre infrastructure, les proxies de centre de données restent une bonne et rapide solution.