D'où viennent ces requêtes HTTP non-standard dans mes logs ?

Googlebot crawle les pages avec des requêtes GET, parfois des POST pour les formulaires : la plupart des professionnels SEO le savent. Mais les logs serveur racontent autre chose. On y trouve des HEAD, OPTIONS, PUT, PATCH ou DELETE émanant des plages IP de Google.

Gary Illyes apporte l'explication : ces requêtes pèsent moins de 1, 5% du total, et c'est le code JavaScript présent sur vos pages qui les déclenche. Googlebot exécute le JS embarqué quand il effectue le rendu d'une URL. Des appels fetch() ou XMLHttpRequest avec des méthodes non-standard dans ce code ? Google les exécute réellement.

Pourquoi Google exécute-t-il ce JavaScript au lieu de l'ignorer ?

Le processus de rendu de Googlebot cherche à comprendre le contenu tel qu'un navigateur moderne le restituerait. Ignorer le JavaScript reviendrait à passer à côté du contenu chargé dynamiquement, des liens générés côté client et des interactions qui font l'expérience utilisateur.

Exécuter le JS, c'est déclencher mécaniquement toutes les requêtes réseau que ce code génère. Votre application front-end s'appuie sur des API REST modernes, avec PUT pour mettre à jour et DELETE pour supprimer ? Googlebot les invoquera au moment du rendu. Le moteur ne filtre pas les méthodes HTTP.

Faut-il bloquer ces requêtes non-GET dans mes configurations serveur ?

Non. Bloquer HEAD, OPTIONS ou les autres méthodes risque de casser le rendu JavaScript de vos pages, et donc d'empêcher Google de voir le contenu généré dynamiquement. Les requêtes HEAD, par exemple, vérifient qu'une ressource existe sans télécharger le corps complet.

En volume, 1, 5% ne représente presque rien. Ces requêtes peuvent pourtant viser des endpoints critiques : si votre JS interroge une API pour afficher le contenu principal, bloquer la méthode utilisée rend cette zone invisible pour Google. Gardez vos configurations permissives pour ces méthodes, au moins pour les user-agents Google.

• Moins de 1, 5% du volume total de crawl Google utilise des méthodes autres que GET et POST
• Ces requêtes proviennent du JavaScript exécuté pendant le rendu des pages par Googlebot
• Les méthodes concernées sont HEAD, OPTIONS, PUT, PATCH et DELETE
• Bloquer ces requêtes peut empêcher le rendu correct de vos pages et masquer du contenu à Google
• Les logs serveur reflètent le comportement réel du JavaScript de vos pages, pas des anomalies

Cette révélation change-t-elle vraiment quelque chose pour les SEO praticiens ?

Soyons honnêtes. La plupart des sites n'ont jamais vu passer ces requêtes dans leurs logs, ou ne s'en sont pas souciés. Avec 1, 5%, elles restent marginales en volume, surtout face aux dizaines de milliers de GET qu'encaisse chaque jour un site moyen.

La vraie question porte sur les applications web modernes qui s'appuient massivement sur des frameworks JavaScript (React, Vue, Angular). Si votre front-end déclenche des PUT ou DELETE vers des API au chargement initial, vérifiez que ces endpoints répondent correctement à Googlebot. Un 403 Forbidden bloquerait le rendu. Une authentification obligatoire aussi.

Quels risques concrets pour les sites avec des API REST complexes ?

Tout se complique dès que votre JavaScript émet des requêtes avec effets de bord. Un DELETE déclenché par Google pendant le rendu pourrait, en théorie, effacer des données si votre API ne prévoit rien pour s'en prémunir. [A vérifier] : Gary Illyes ne dit pas si Google filtre les méthodes potentiellement destructrices ou les exécute aveuglément.

Un PUT ou PATCH modifie l'état d'une ressource. Votre front-end s'en sert pour des mises à jour temps réel sans token CSRF ni vérification d'origine ? Vos données sont potentiellement exposées. Mieux vaut poser des gardes côté serveur : authentification et validation d'origine, avec du rate limiting.

Les données fournies par Gary Illyes sont-elles suffisamment précises ?

Le seuil de 1, 5% reste vague. On ne connaît ni la distribution par type de méthode (HEAD vs DELETE par exemple), ni la répartition par catégorie de sites, et rien ne dit si certains secteurs sont davantage touchés. [A vérifier] : un site e-commerce bourré de JS déclenche-t-il proportionnellement plus de ces requêtes qu'un blog statique ?

Gary attribue ces requêtes au JavaScript, sans préciser le contexte d'exécution. Googlebot exécute-t-il les event listeners (click, scroll), ou seulement le code qui part au chargement ? Si Google simule des interactions utilisateur, le volume de 1, 5% pourrait grimper sur des sites très interactifs.

Que faut-il vérifier dans vos logs serveur maintenant ?

Première étape : analyser vos logs pour repérer les requêtes HEAD, OPTIONS, PUT, PATCH et DELETE émises par les user-agents Googlebot, puis croiser ces relevés avec vos plages horaires de pic de crawl. Des volumes suspects ? Des patterns inhabituels ? Votre JavaScript génère peut-être des appels non intentionnels.

Regardez aussi les codes de réponse HTTP renvoyés pour ces méthodes. Un taux élevé de 4xx ou 5xx signale que votre configuration serveur ou votre API bloque ces requêtes, et Google risque alors de ne pas rendre correctement vos pages. Corrigez les règles de pare-feu ou les configurations Nginx/Apache qui rejettent ces méthodes par défaut.

Comment protéger vos API des requêtes potentiellement destructrices ?

Tous vos endpoints sensibles doivent porter une authentification robuste, y compris ceux appelés par votre propre front-end. Tokens CSRF, vérification de l'en-tête Origin, rate limiting : autant de garde-fous contre les appels non autorisés, qu'ils proviennent de Googlebot ou d'acteurs malveillants.

Pour les méthodes avec effets de bord (PUT, PATCH, DELETE), exigez des permissions explicites. L'obscurité ne protège rien (security through obscurity). Si Googlebot peut déclencher un DELETE, un attaquant le peut aussi. Structurez vos API pour que ces opérations réclament une authentification valide.

Faut-il modifier votre JavaScript front-end pour limiter ces requêtes ?

Auditez votre code JS et traquez les appels inutiles au chargement initial. Si votre application envoie des PUT ou DELETE pendant le montage des composants, interrogez leur utilité réelle pour l'affichage du contenu. Les opérations non critiques peuvent attendre l'interaction utilisateur.

Quand cela se justifie, appuyez-vous sur des conditional requests : les en-têtes If-Modified-Since ou If-None-Match laissent votre front-end vérifier la fraîcheur d'une ressource sans télécharger tout le corps, ce qui allège le serveur et ménage votre crawl budget dans l'hypothèse où Google exécute ces requêtes.

Ces chantiers techniques se mènent mal en solo, surtout sur des architectures distribuées comptant plusieurs API et microservices. Une agence SEO spécialisée dans les audits techniques avancés peut vous accompagner pour sécuriser vos endpoints, optimiser votre JavaScript et vérifier que Googlebot rend bien vos contenus sans déclencher d'effets de bord indésirables.

• Analyser les logs serveur pour identifier les requêtes HEAD, OPTIONS, PUT, PATCH, DELETE depuis Google
• Vérifier les codes HTTP retournés pour ces méthodes et corriger les configurations bloquantes
• Implémenter authentification et CSRF sur tous les endpoints API sensibles
• Auditer le JavaScript front-end pour éliminer les appels inutiles au chargement
• Tester le rendu de vos pages avec Google Search Console et Mobile-Friendly Test
• Monitorer le crawl budget pour détecter toute anomalie liée à des requêtes JS excessives