Un robots.txt permissif ne suffit pas si le CDN ou le pare-feu renvoie un défi, une erreur ou une page vide aux robots. Comparez la réponse réellement reçue avec celle attendue, puis corrigez la règle précise qui bloque l’accès aux ressources publiques.
Observer une URL représentative
Choisissez une page importante, son image et le fichier robots.txt. Relevez statut HTTP, redirections, type de contenu et corps renvoyé. Un statut 200 peut masquer une page de vérification au lieu de l’article. Consignez la date et l’identifiant de requête fourni par l’infrastructure, si disponible. Un navigateur connecté à l’administration ne constitue pas un test suffisant de l’accès public.
Lire la réponse complète, pas seulement son statut
Le diagnostic doit distinguer la demande, la réponse et son contenu. Un succès HTTP ne prouve pas que l’article a été servi. À l’inverse, une erreur constatée une seule fois ne suffit pas à caractériser un blocage permanent. Comparez les mêmes URL à des moments documentés, puis recherchez la règle correspondant aux requêtes concernées dans les journaux de l’infrastructure.
| Réponse observée | Hypothèse à vérifier | Contrôle suivant |
|---|---|---|
| 200 avec le texte attendu | Accès public disponible pour cette requête | Vérifier aussi images, liens et métadonnées |
| 200 avec un défi de navigation | Protection servie à la place du contenu | Consulter l’événement associé dans le CDN |
| 403 | Accès refusé selon une règle ou une autorisation | Identifier la couche qui a pris la décision |
| 429 | Limitation du débit ou autre règle de fréquence | Lire les en-têtes et la politique appliquée |
| Redirections successives | Parcours d’URL ou configuration à revoir | Examiner la destination finale et les variantes de domaine |
Depuis Windows avec curl.exe, les commandes ci-dessous permettent de conserver les en-têtes et le corps de la réponse, puis d’identifier la destination finale. Remplacez l’adresse par une page publique que vous êtes autorisé à contrôler. Le domaine est illustratif ; ces lignes ne prouvent aucun résultat sur votre hébergement. Avec un autre système, adaptez notamment le nom de l’exécutable et le fichier de sortie ignorée.
curl.exe -sS -D headers.txt -o page.html https://example.com/guide/
curl.exe -sS -L -o NUL -w "%{http_code} %{url_effective}\n" https://example.com/guide/Croiser les journaux
Une requête bloquée en amont peut ne jamais parvenir au serveur d’origine. Consultez les événements du CDN et du serveur sur la même fenêtre horaire. Recherchez règles de protection, limites de débit et restrictions géographiques. Ne recopiez pas publiquement de paramètres sensibles. Le but est d’isoler une règle qui explique l’écart entre la réponse attendue et la réponse observée.
Vérifier l’identité avant une exception
Un nom de robot dans le User-Agent peut être imité. Pour Google, utilisez les méthodes publiées par l’opérateur : vérification DNS ou plages d’adresses officielles, selon votre dispositif. Pour un autre robot, consultez sa documentation. Une simulation locale du User-Agent aide à tester une réponse ; elle ne prouve pas que le vrai robot rencontre exactement le même traitement.
Exemple fictif : une image inaccessible
Le HTML d’un guide est accessible, mais son illustration reçoit un défi parce qu’un chemin d’images a été placé sous une protection trop large. L’équipe corrige seulement la règle des ressources publiques concernées, puis contrôle réponses et charge. Le test couvre visites ordinaires et accès vérifiés, sans ouvrir les zones d’administration ni les fonctions sensibles.
Construire une exception limitée et vérifier son effet
Commencez par une règle de test portant sur la ressource publique concernée. Notez le comportement avant et après, l’identité vérifiée du robot si elle est pertinente et la durée de l’essai. Un changement global du pare-feu ferait disparaître cette capacité de comparaison. Vérifiez également les visiteurs ordinaires : une exception ne doit pas casser leur parcours ou faire apparaître une réponse différente sur le fond.
- Corrélez les événements avec un identifiant de requête ou une fenêtre horaire précise. Si le serveur d’origine n’a rien reçu, commencez par la couche amont.
- Distinguez la politique robots.txt, le contrôle d’accès et la protection de débit. Ces mécanismes répondent à des questions différentes ; en modifier un ne corrige pas automatiquement les autres.
- Rejouez les lectures sur la page, l’image principale et une URL voisine. Contrôlez aussi le résultat après expiration ou invalidation du cache selon la méthode de votre infrastructure.
- Conservez la procédure de retour en arrière et le responsable de suivi. La clôture du défaut correspond à une réponse correcte reproduite, pas à la disparition d’un avertissement isolé.
La vérification officielle des requêtes Google aide à identifier les accès authentiques. Une simulation d’en-tête ne suffit pas pour cette étape. Pour éviter de mélanger identité et accès, poursuivez avec le contrôle de l’identité des robots dans les journaux.
Documenter la correction
Conservez règle initiale, changement, ressources visées et méthode de retour en arrière. Surveillez ensuite les erreurs plutôt que d’abaisser toutes les protections. Dans les outils de recherche, inspectez des pages représentatives et laissez le temps au traitement. Ce contrôle complète la préparation technique du site : il ne garantit pas l’indexation ou une citation. Vérifiez aussi que les images restent disponibles après expiration du cache.