Vérifiez si la protection contre les bots bloque le trafic de recherche IA que vous souhaitez
Vérifiez le fournisseur prévu, la réponse en direct et la politique qui le contrôle. Séparez la récupération de recherche, l’entraînement du modèle et l’accès dirigé par l’utilisateur avant de modifier les règles des bots.
Un propriétaire de site peut autoriser la découverte de recherche et recevoir quand même un rapport indiquant qu’une requête a été bloquée. Résoudre cette contradiction apparente commence par la requête exacte : quel fournisseur essayait d’atteindre quelle page, à quel but, et quelle réponse a-t-il reçue?
Une analyse SEOReport peut fournir des preuves d’un problème d’accès à enquêter. Traitez cette observation comme le début d’un diagnostic. La politique pour un fournisseur particulier et le comportement d’une requête particulière comptent tous deux.
Décidez quel but vous avez l’intention d’autoriser
Les services IA utilisent différents agents pour différentes tâches. OpenAI documente OAI-SearchBot pour la recherche, GPTBot pour la collecte potentielle d’entraînement de modèle et ChatGPT-User pour les requêtes dirigées par l’utilisateur. Sa documentation du crawler explique que les paramètres de recherche et d’entraînement sont indépendants.
La documentation du crawler d’Anthropic distingue également Claude-SearchBot, ClaudeBot et Claude-User. Enregistrez le choix prévu pour le fournisseur et le but qui vous intéressent. Refuser l’entraînement n’est pas une raison de qualifier la politique de recherche du site comme défectueuse.
Pour Google, vérifiez le Contrôle de l’IA générative de recherche sur la propriété Search Console correcte. C’est un choix de participation au niveau du compte en plus de l’état technique du site. Vérifiez les paramètres hérités ainsi que les choix explicites.
Comparez la politique avec la réponse livrée
Examinez le robots.txt public, les règles d’hébergement ou CDN et la réponse réelle de la page. Ils répondent à des questions différentes. Le robots.txt déclare la politique du crawler ; une règle d’accès peut empêcher une requête autorisée de recevoir la page.
Inspectez un URL représentatif important et enregistrez la destination finale observée, le statut et le contenu. Une page de défi servie avec un statut réussi reste une page de défi. En revanche, un widget CAPTCHA sur un formulaire de contact fonctionnel ne prouve pas que toute la page a été bloquée.
Notre guide d'accès aux crawls aide à organiser l'examen de la politique prévue et des URL affectées.
| Un fournisseur de recherche identifié reçoit un défi | Que la requête observée n'a pas pu récupérer la page prévue | Quelle règle l'a causée et si le comportement se répète |
| Une requête de test locale reçoit un 403 | La requête de test a été refusée | Si un fournisseur vérifié reçoit la même réponse |
| Une page contient un widget CAPTCHA | La page inclut un contrôle de vérification humaine | Si le contenu demandé a réellement été retenu |
| Robots.txt permet le crawler prévu | La politique de crawl déclarée autorise l'accès | Si les règles d'hébergement livrent la page |
Ce sont des interprétations illustratives. Conservez la véritable observation à côté de l'enquête sur la règle réelle.
Vérifiez l'identité du fournisseur avant de modifier une exception
Un libellé d'user-agent est facile à copier. Utilisez les directives d'identification documentées du fournisseur et les outils de vérification pris en charge par votre hébergeur lors de la décision d'admettre le trafic. Un test avec un libellé copié peut révéler comment cette requête est traitée, mais il ne peut pas prouver que la requête provenait du fournisseur.
Privilégiez le moindre changement qui met en œuvre la politique prévue. Un problème d'accès de recherche légitime ne nécessite pas de retirer toute protection d'un site. Conservez les frontières d’authentification et de données client, puis vérifiez que le contenu public prévu est délivré au lecteur prévu.
Revérifiez après un changement d’hébergement ou de politique
Enregistrez l’observation originale, notez le paramètre modifié et répétez la requête pertinente. Incluez le corps de la page dans la vérification afin qu’un code d’état modifié ne puisse pas masquer un défi ou une réponse vide.
Les paramètres par défaut du fournisseur et les options de compte peuvent changer. Lisez le paramètre actuel sur le site réel plutôt que de l’inférer à partir d’une annonce du fournisseur ou d’un fichier de configuration dans le dépôt. Sur une plateforme gérée, confirmez également quel niveau sert le robots.txt public.
Le plus large test d'acceptation de l'agent étend cette revue de la lecture d'une page à l'accomplissement d'une tâche autorisée. L’accès à la recherche, le contenu utilisable et une action réussie nécessitent chacun leur propre observation.
Observez la découverte après avoir confirmé l’accès
Une fois que le lecteur prévu peut récupérer la page, tenez compte des retards de traitement et de reporting du fournisseur. Examinez les impressions IA dédiées ou les citations lorsque disponibles, les visites de référence identifiables et les actions produit utiles séparément.
Le rétablissement d’accès établit une réparation technique. Une citation ou une visite client ultérieure établit un résultat différent. Conserver les deux dossiers donne à l’équipe un compte défendable de ce qui s’est amélioré et où un travail supplémentaire pourrait être précieux.
Obtenez le diagnostic complet de votre site
Un rapport fondé sur des preuves et un plan d’action priorisé, avec une offre à crédits mensuels.