Résoudre les erreurs et les blocages de crawl
Erreurs HTTP, robots.txt, IP à autoriser, user-agents et échecs d’export.
Dans ce guide
Identifier ce qui a échoué
Une URL en 404 n’est pas forcément un échec du crawl : l’audit peut justement vous aider à la trouver. Distinguez l’arrêt du moteur, une réponse en erreur sur une page et un document Sheets ou Slides non généré. Le message, le nombre d’URL récupérées et les résultats déjà accessibles permettent de faire la différence.
Conservez l’identifiant du crawl et le message complet, avec son éventuel code entre crochets. Les libellés ci-dessous concernent la chaîne de crawl Cuik.
Le site refuse ou ralentit les requêtes
| Message ou code | Ce que cela signifie | Que faire ? |
|---|---|---|
site_blocked, HTTP 403, CAPTCHA |
Le site ou son pare-feu refuse la requête. | Vérifiez les journaux du pare-feu. Autorisez la source du crawl sur votre site ou essayez le proxy résidentiel proposé dans les paramètres réseau. |
HTTP 429, rate_limit_persistent |
Le site limite le rythme. Les refus sont conservés et signalés dans le résultat partiel. rate_limit_persistent concerne les anciens crawls arrêtés. |
Réduisez la vitesse, attendez la fin de la limitation et testez un petit périmètre. N’enchaînez pas les relances. |
robots_blocked |
Une règle de robots.txt interdit l’URL au user-agent choisi. | Vérifiez le groupe et le chemin concernés. Corrigez la règle sur votre site si elle est involontaire. |
robots_unavailable |
Le moteur n’a pas pu lire robots.txt correctement. | Ouvrez le fichier, contrôlez ses redirections, son statut HTTP et les règles du pare-feu. |
site_http_error |
L’URL de départ répond par une erreur HTTP. | Pour 401, vérifiez l’accès ; pour 404/410, l’adresse ; pour 5xx, le serveur du site. |
Le proxy résidentiel aide dans certains cas de filtrage d’IP datacenter. Il ne garantit pas l’accès, ne résout pas toutes les protections et ne remplace pas une autorisation du propriétaire du site. Ce choix doit être vérifié à chaque lancement : il n’est pas conservé comme une préférence ordinaire.
Quelle IP autoriser ?
Pour un crawl serveur en IPv4, sans proxy résidentiel, l’adresse de sortie vérifiée le 4 octobre 2026 est 46.4.101.91. Autorisez cette adresse uniquement pour le site à analyser et les requêtes nécessaires à l’audit. Demandez à votre hébergeur ou à la personne qui gère votre WAF d’examiner les requêtes bloquées à l’heure de l’essai. Une autorisation globale qui désactive toutes les protections du site n’est pas nécessaire.
Cette adresse ne s’applique pas à un crawl depuis votre application desktop, à une connexion IPv6 ou au proxy résidentiel : ces parcours ont une autre sortie réseau. Le sélecteur Connexion IP permet de choisir IPv4 pour un diagnostic reproductible. Pour un autre parcours, faites confirmer l’IP effectivement vue dans les logs du site ou demandez-la au support avec l’identifiant du crawl. Ne remplacez pas cette IP par l’adresse DNS de cuik.io ou api.cuik.io : l’adresse d’un service web n’est pas nécessairement celle de ses requêtes sortantes.
L’infrastructure peut évoluer. Si une ancienne règle ne fonctionne plus, faites vérifier l’adresse observée avant d’ajouter d’autres autorisations.
User-agent, robots.txt et JavaScript
Le user-agent est l’identité annoncée dans la requête. Cuikbot, Googlebot mobile, Chrome Desktop et la valeur personnalisée permettent de tester des comportements différents. Sélectionner Googlebot ne fait pas de Cuik un robot Google : un pare-feu peut vérifier aussi l’IP. Autoriser une simple chaîne « Googlebot » ou « Cuikbot » ne constitue pas une authentification.
Le réglage Respecter robots.txt contrôle les règles d’exploration. Respecter Crawl-delay est indépendant et applique le délai déclaré. Vérifiez ces réglages avant de conclure à une panne. Pour un diagnostic autorisé qui nécessite d’ignorer une règle, limitez le périmètre et revenez ensuite à une configuration normale.
Crawler les fichiers JS vérifie des fichiers ; cela ne rend pas la page dans un navigateur. Si le contenu est injecté par JavaScript, activez le rendu JavaScript et comparez sur quelques URL. Chrome Desktop, rendu JavaScript et empreinte réseau Chrome sont trois réglages distincts.
Connexion impossible ou aucune page exploitable
| Code | Vérification utile |
|---|---|
site_unreachable |
Vérifiez le domaine, le DNS, le certificat TLS, les redirections et l’accessibilité publique. Si le problème dépend d’IPv6, comparez avec IPv4. Ne désactivez pas la vérification des certificats pour masquer une erreur du site. |
timeout |
Réduisez le périmètre et la vitesse ; vérifiez si le site répond lentement ou si le traitement attend de la capacité. Un timeout ne prouve pas que le site est hors ligne. |
no_usable_html |
Vérifiez l’URL de départ, les réponses HTTP, le périmètre, robots.txt et les protections : aucune page HTML interne utilisable n’a été récupérée. |
database_invalid |
Les données du crawl sont absentes ou inutilisables. Transmettez l’identifiant au support ; changer le user-agent ne répare pas cette base. |
Un résultat partiel peut aussi venir d’une limite d’URL, de profondeur ou de variantes, d’un périmètre trop étroit, ou de liens absents du HTML exploré. La détection des sitemaps ne signifie pas que toutes leurs URL sont ajoutées à la file de crawl. Consultez le guide de configuration avancée.
Le crawl est terminé, mais un document manque
Les codes google_api ou report_backend_unavailable peuvent concerner la préparation des documents, même si la collecte a réussi. Ouvrez les résultats avant de relancer l’audit. Si les documents n’ont pas été demandés, utilisez Générer les documents, choisissez les modèles disponibles et vérifiez les sélections Sheet et Slides.
Un appel API ou MCP ne demande pas forcément ces documents. Une erreur sur un modèle ou un accès Google doit être traitée à cette étape, sans refaire toute l’exploration. Pour external_api, lisez quel enrichissement est concerné : un échec PageSpeed, Ads ou DataForSEO n’a pas la même cause qu’un refus de votre site.
Quand contacter le support
crawler_unavailable et renderer_unavailable signalent un service de crawl ou un navigateur indisponible ; interrupted indique une interruption du traitement. stopped_by_user correspond à un arrêt demandé. Une erreur unknown nécessite le message complet pour être comprise.
Depuis Aide et support, envoyez : l’identifiant du crawl, l’URL, l’heure approximative, le moteur, le message et les options réseau/rendu utilisées. Ajoutez une capture ou le code HTTP relevé côté site. N’envoyez pas votre clé API, vos mots de passe ou vos tokens Google. Une erreur dite réessayable ne signifie pas qu’une relance immédiate corrigera le problème ni qu’elle sera sans effet sur votre quota.
Pour comprendre les ralentissements, les pauses de 1, 5 et 10 minutes et les résultats partiels, consultez le guide HTTP 429 : crawl ralenti ou interrompu.