Gary Illyes : les crawlers de Google envoient aussi HEAD, OPTIONS, PUT, PATCH et DELETE

L’essentiel

• Les crawlers de Google envoient aussi des requêtes HEAD, OPTIONS, PUT, PATCH et DELETE.
• D’après Gary Illyes, ces cinq méthodes pèsent moins de 1,5 % des requêtes de l’ensemble des crawlers de Google.
• Il les attribue au JavaScript des pages, exécuté pendant le rendu.
• Google ne donne aucune ventilation par méthode ni par robot.

Gary Illyes : les robots de Google ne s’en tiennent pas au GET et au POST

Gary Illyes, de l’équipe Search Relations de Google, a publié le 6 août 2026 un post LinkedIn sur une question qu’on lui a posée plusieurs fois ces dernières semaines : les crawlers de Google envoient-ils d’autres requêtes HTTP que GET et POST ? « Pour faire court, oui » (traduction), répond-il, avant de citer HEAD, OPTIONS, PUT, PATCH et DELETE.

Ces méthodes restent marginales. Elles représentent « moins de 1,5 % du total des requêtes envoyées par l’ensemble des crawlers de Google » (traduction). Le chiffre est global : il ne sépare pas Googlebot des autres robots et fetchers de Google, et aucune répartition méthode par méthode n’est fournie. Search Engine Roundtable a relayé l’information le 7 août 2026.

Le JavaScript exécuté au rendu déclenche ces requêtes

Ce n’est pas Google qui choisit d’envoyer un PUT ou un DELETE. Selon Gary Illyes, ces requêtes partent du JavaScript présent sur les pages, qu’il range sans ménagement parmi les « bêtises en JavaScript » (traduction), le rendu se contentant de faire son travail. Quand le service de rendu de Google exécute les scripts d’une page, leurs appels réseau partent donc avec, quelle que soit la méthode utilisée.

Gary Illyes n’explique pas la présence d’OPTIONS. Mon hypothèse : il s’agit de la requête de contrôle préalable (le « preflight » du mécanisme CORS) qu’un navigateur envoie avant un appel vers une autre origine, dès que le script utilise PUT, PATCH, DELETE ou des en-têtes personnalisés. Le service de rendu de Google repose sur Chromium. Qu’il se comporte comme Chrome sur ce point serait logique, mais Google ne l’a pas confirmé.

Côté site : des API trop ouvertes et des pare-feu trop stricts

Premier cas de figure : un script lancé au chargement d’une page appelle en PUT, PATCH ou DELETE un point d’accès qui ne demande aucune authentification. Le robot qui exécute la page peut alors déclencher cet appel, comme le ferait un visiteur anonyme, et si l’appel modifie ou supprime une donnée, la modification a bien lieu. Le diagnostic n’a rien d’évident. Dans les logs serveur, la requête apparaît sur l’URL du point d’accès, pas sur celle de la page qui contenait le script.

Le cas inverse pose un autre problème. Un pare-feu applicatif (WAF) ou une règle serveur qui rejette tout ce qui n’est ni GET ni POST peut dégrader le rendu. Si la requête OPTIONS est refusée, le navigateur n’envoie pas l’appel qui devait suivre, et le contenu chargé par ce script manque dans la page rendue par Google. Un problème voisin a déjà été traité ici avec les règles anti-bots IA de Cloudflare qui renvoyaient des 403 à Googlebot.

Ce que j’en retiens

Moins de 1,5 %, c’est peu. Le sujet mérite pourtant un contrôle, parce qu’il relève de la sécurité autant que du SEO : une page publique ne devrait jamais pouvoir modifier des données sans session ni jeton, que le visiteur soit un humain ou un robot. Je commencerais par filtrer les logs serveur sur les robots de Google vérifiés (DNS inverse ou plages d’IP publiées par Google), puis par isoler toutes les requêtes autres que GET. Un PUT, un PATCH ou un DELETE dans cette liste, c’est un script à retrouver.

Pour le pare-feu, je préfère une réponse 405 (méthode non autorisée) sur les méthodes que le serveur ne gère vraiment pas plutôt qu’un refus global, et je laisse passer OPTIONS sur les points d’accès appelés pendant le rendu. Il reste à contrôler le résultat avec le test en direct de l’outil d’inspection d’URL de la Search Console : le contenu chargé en JavaScript doit figurer dans le HTML rendu.