Les requêtes POST plombent-elles vraiment votre crawl budget ?

Pourquoi Google ne cache-t-il pas les requêtes POST ?

La différence entre GET et POST n'est pas qu'une convention technique — elle porte en elle une intention sémantique. Les requêtes GET sont censées être idempotentes : même URL, même résultat, à chaque fois. Google peut donc tranquillement stocker la réponse en cache et la resservir lors du prochain crawl.

Les POST, elles, sont conçues pour modifier un état ou transmettre des données variables. Googlebot ne peut pas présumer que deux appels identiques retourneront le même contenu — d'où l'impossibilité de cacher quoi que ce soit.

En quoi cela impacte-t-il le crawl budget ?

Chaque requête POST doit être exécutée intégralement à chaque crawl. Pas de raccourci, pas de 304 Not Modified, pas de réutilisation d'une réponse précédente. Si votre page charge 10 endpoints POST pour assembler son DOM, le bot doit tous les interroger à chaque passage.

Le crawl budget, c'est une enveloppe limitée de requêtes que Google consent à effectuer sur votre site dans un laps de temps donné. Plus vous consommez de ressources par page, moins il en reste pour explorer d'autres URLs — ou pour recrawler plus souvent vos pages importantes.

Quelles architectures sont particulièrement concernées ?

Les Single Page Applications (SPA) qui assemblent leur contenu via des appels API sont les premières visées. Si ces appels passent en POST — souvent par habitude ou par mauvaise pratique —, le bot subit la latence complète à chaque visite.

Les sites headless ou JAMstack qui s'appuient sur des API externes pour hydrater les pages côté client risquent le même écueil. Le crawl devient coûteux, lent, et Google peut décider de revenir moins souvent.

• GET = cacheable : Google réutilise les réponses précédentes si rien n'a changé
• POST = toujours frais : chaque requête est exécutée intégralement, même si le contenu est identique
• Un site avec beaucoup d'appels POST consomme plus de crawl budget par page
• Les architectures JS modernes (SPA, headless) sont particulièrement exposées si mal configurées

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui — et c'est même documenté depuis des années dans les specs HTTP. Ce n'est pas une lubie de Google, c'est une propriété intrinsèque du protocole. Les POST ne sont pas idempotentes, donc non cachables par défaut (sauf si explicitement autorisé par des headers spécifiques, ce qui reste rare).

Côté crawl budget, les observations terrain confirment : les sites qui abusent des POST pour charger du contenu voient leur fréquence de crawl stagner, surtout si la latence des APIs est élevée. Google ne peut pas se permettre d'attendre 500 ms par endpoint POST sur des millions de pages.

Quelle nuance faut-il apporter à cette affirmation ?

Martin Splitt ne précise pas à quel point cette surconsommation est critique. Est-ce 10 % de crawl budget en plus ? 50 % ? Ça dépend du nombre d'appels POST, de leur latence, de la taille des réponses. [A vérifier] : Google n'a jamais publié de benchmark chiffré sur ce sujet.

Deuxième nuance : tous les POST ne se valent pas. Un POST qui retourne systématiquement le même JSON peut techniquement être caché côté serveur avec un CDN bien configuré. Googlebot verra alors une réponse instantanée, même si la requête initiale est un POST. Mais c'est à vous de mettre ça en place — Google ne le fera pas pour vous.

Dans quels cas cette règle ne pose-t-elle pas de problème ?

Si vos pages POST ne servent qu'à des actions utilisateur non indexables (formulaires de contact, panier, checkout), aucun impact SEO. Google ne crawle pas ces interactions — ou alors il ne devrait pas, si vous avez bien balisé vos noindex.

Autre cas : les sites avec un crawl budget largement excédentaire. Un blog de 50 pages peut se permettre quelques POST mal placés sans que ça change quoi que ce soit. Le problème se pose vraiment sur les gros catalogues e-commerce ou les portails de contenu avec des dizaines de milliers d'URLs.

Que faut-il auditer en priorité sur son site ?

Commencez par identifier tous les appels API qui participent au rendu du contenu indexable. Chrome DevTools, onglet Network, filtrez par "Fetch/XHR" et traquez les POST. Si un endpoint sert du contenu critique pour le SEO (titres, descriptions, prix, avis), il doit passer en GET.

Ensuite, vérifiez la latence de ces requêtes. Un POST qui répond en 50 ms pose moins de souci qu'un GET qui met 2 secondes. Mais à latence égale, GET gagne toujours — donc autant basculer tout ce qui peut l'être.

Comment convertir un POST en GET sans tout casser ?

La plupart du temps, c'est une question de convention. Si votre POST ne fait que récupérer des données sans modifier d'état côté serveur, il peut devenir un GET. Passez les paramètres dans l'URL ou en query string plutôt que dans le body.

Si vous avez besoin de transmettre beaucoup de données (par exemple, des filtres complexes), envisagez un système de hash : stockez la requête côté serveur, retournez un identifiant, et appelez cet identifiant via GET. Google pourra alors cacher la réponse.

Quelles erreurs éviter absolument ?

Ne basculez pas tous vos POST en GET sans réfléchir. Les actions qui modifient des données (ajout au panier, soumission de formulaire, vote) doivent rester en POST pour des raisons de sécurité et de sémantique HTTP.

Autre piège : convertir un POST en GET sans ajuster les headers de cache côté serveur. Si votre API retourne un Cache-Control: no-cache, Google ne mettra rien en cache même avec un GET. Configurez correctement vos ETag et Last-Modified.

• Auditez tous les appels API qui servent du contenu indexable
• Identifiez ceux qui sont en POST alors qu'ils pourraient être en GET
• Mesurez la latence de chaque endpoint pour prioriser les optimisations
• Basculez en GET les requêtes idempotentes (lecture seule)
• Configurez les headers de cache côté serveur (Cache-Control, ETag)
• Vérifiez que Googlebot peut bien exécuter vos APIs (pas de blocage CORS ou firewall)
• Surveillez l'évolution du crawl budget dans la Search Console après modification