Faut-il abandonner les paramètres GET pour sécuriser son crawl budget ?

Pourquoi Googlebot ignore-t-il les requêtes PUT ?

Le protocole HTTP définit plusieurs méthodes de requêtes : GET pour récupérer des données, POST pour en soumettre, PUT pour créer ou modifier une ressource, DELETE pour la supprimer. Googlebot se concentre quasi exclusivement sur les requêtes GET, celles qui servent à afficher du contenu.

Les requêtes PUT, utilisées pour des actions de modification, ne font pas partie du périmètre classique d'exploration d'un moteur. Gary Illyes confirme ici ce que beaucoup soupçonnaient : Googlebot n'exécute pratiquement jamais de PUT requests lors de son crawl.

Quel est le problème avec les paramètres GET pour les actions utilisateur ?

Sur de nombreux sites e-commerce, les actions comme "ajouter au panier" passent par des URLs avec paramètres GET : ?add_to_cart=123, ?action=wishlist&product_id=456. Ces URLs sont techniquement crawlables.

Résultat : Googlebot peut les découvrir via des liens internes mal configurés, les explorer, générer des pages inutiles dans l'index et gaspiller du crawl budget. Sur un catalogue de plusieurs milliers de produits, ça devient vite ingérable.

Comment les PUT requests règlent-elles ce souci ?

En basculant ces actions vers des requêtes PUT (ou POST, d'ailleurs), vous sortez ces URLs du radar de Googlebot. Le bot ne suivra jamais un lien qui déclenche une requête PUT.

Concrètement, l'action d'ajout au panier se fait via JavaScript avec une requête AJAX PUT vers une API backend, sans générer d'URL crawlable. Vous gardez le contrôle sur ce qui est exploré.

• Googlebot se limite quasi exclusivement aux requêtes GET
• Les paramètres GET pour des actions (ajout panier, filtres temporaires) créent des URLs crawlables inutiles
• Utiliser PUT ou POST via AJAX évite que ces URLs polluent l'index
• Cette approche protège le crawl budget sur les gros catalogues

Cette recommandation est-elle cohérente avec les pratiques terrain ?

Oui, totalement. Les audits de sites e-commerce révèlent régulièrement des milliers d'URLs parasites générées par des paramètres GET mal maîtrisés. Filtres de tri, sessions utilisateur, actions de compte — tout ça finit dans les logs de crawl.

La solution classique consiste à combiner robots.txt, balises noindex ou paramètres dans Search Console. Mais c'est du traitement symptomatique. Passer par PUT/POST en AJAX, c'est traiter le problème à la racine.

Quelles nuances faut-il apporter à cette déclaration ?

Gary Illyes dit "très rare", pas "jamais". On manque de contexte : dans quels cas Googlebot utiliserait-il PUT ? Aucune donnée publique là-dessus. [À vérifier]

Autre point : cette approche suppose que votre site fonctionne en mode SPA ou avec du JavaScript moderne. Si vous tournez encore sur un CMS ancien avec des formulaires classiques, la migration vers PUT requests peut représenter un chantier technique conséquent.

Enfin — et c'est rarement dit — POST aurait le même effet que PUT ici. Google ne crawle pas non plus les POST. Pourquoi Illyes mentionne-t-il spécifiquement PUT ? Peut-être pour insister sur la sémantique REST, mais dans les faits, POST fait aussi bien l'affaire.

Cette technique remplace-t-elle les autres bonnes pratiques ?

Non. Passer aux PUT requests ne dispense pas de nettoyer vos paramètres GET existants. Si votre site a déjà indexé 50 000 URLs inutiles, elles ne vont pas disparaître magiquement.

Il faut combiner cette approche avec une revue des paramètres dans Search Console, un fichier robots.txt propre et une stratégie de canonicalisation claire. Les PUT requests, c'est un outil de prévention, pas de correction.

Que faut-il faire concrètement sur un site e-commerce ?

Première étape : auditer vos URLs crawlées. Regardez vos logs serveur ou Search Console pour identifier les paramètres GET liés à des actions (ajout panier, wishlist, filtres temporaires).

Ensuite, passez ces actions en requêtes AJAX avec méthode PUT ou POST. Cela suppose que votre front-end utilise du JavaScript moderne (Fetch API, Axios, etc.). Si vous êtes sur WordPress/WooCommerce, des plugins comme WP REST API permettent de gérer ça proprement.

Parallèlement, nettoyez les URLs déjà indexées via robots.txt ou balises noindex, et soumettez une demande de suppression dans Search Console si nécessaire.

Quelles erreurs éviter lors de la migration ?

Ne basculez pas tout d'un coup. Testez d'abord sur une sous-section du site (une catégorie produit, par exemple) et vérifiez que les conversions ne chutent pas.

Assurez-vous que vos requêtes PUT/POST renvoient des codes HTTP appropriés (200 pour succès, 201 pour création, 4xx/5xx pour erreurs). Un mauvais retour peut casser l'UX sans que vous le détectiez immédiatement.

Enfin, ne supprimez pas vos anciennes URLs GET tant que vous n'avez pas confirmé que le nouveau système fonctionne. Gardez un fallback pendant quelques semaines.

Comment vérifier que Googlebot ne crawle plus ces URLs ?

Surveillez vos logs serveur : si vous ne voyez plus Googlebot taper sur ?add_to_cart= ou équivalent, c'est bon signe. Search Console doit aussi montrer une baisse du nombre d'URLs explorées.

Utilisez l'outil d'inspection d'URL dans Search Console sur quelques URLs suspectes. Si elles ne sont plus découvertes, vous avez réussi.

• Auditer les paramètres GET actuellement crawlés (logs, Search Console)
• Identifier les actions utilisateur qui passent par GET (panier, wishlist, filtres)
• Migrer ces actions vers PUT ou POST en AJAX
• Tester en environnement de dev avant déploiement
• Bloquer les anciennes URLs GET via robots.txt ou noindex
• Surveiller les logs serveur pour valider la baisse de crawl
• Vérifier dans Search Console que les URLs parasites disparaissent de l'index