Google cache-t-il vraiment les requêtes POST lors du rendu JavaScript ?

Pourquoi Google distingue-t-il GET et POST dans son mécanisme de cache ?

Le comportement de Googlebot lors du rendu JavaScript repose sur une logique de performance et de cohérence. Les requêtes GET, par nature idempotentes, peuvent être rejouées sans risque : récupérer deux fois la même ressource produit le même résultat. Google peut donc mettre en cache ces réponses et les réutiliser lors de rendus successifs, économisant du temps de traitement et des ressources serveur.

Les requêtes POST, en revanche, sont conçues pour modifier un état côté serveur — soumettre un formulaire, créer une ressource, déclencher une action. Les mettre en cache serait une aberration technique : chaque POST devrait théoriquement produire un résultat unique. Google ne peut pas présumer qu'une réponse POST sera identique lors d'un second rendu.

Quelle différence concrète entre le rendu initial et les rendus suivants ?

Lors du premier rendu d'une page, Googlebot exécute le JavaScript et effectue toutes les requêtes — GET comme POST. Le navigateur reçoit les réponses, le DOM se construit, le contenu s'affiche. Si une partie critique de la page (des blocs de texte, des produits, des avis) arrive via POST, elle sera visible lors de ce rendu initial.

Mais lors d'un rendu ultérieur — par exemple si Google réévalue la page quelques jours plus tard — les requêtes POST ne seront pas rejouées. Google réutilisera les ressources GET en cache, mais le contenu chargé via POST sera absent. Résultat : deux versions différentes de la même URL dans l'index, avec un risque d'incohérence entre le contenu indexé et le contenu réel.

Quel impact sur l'indexation et la performance perçue par Googlebot ?

Si votre architecture repose sur des appels POST pour charger du contenu critique, vous créez une dépendance à la fraîcheur du rendu. Googlebot peut indexer un état incomplet de la page si le dernier rendu n'a pas rejoué les POST. Pire encore : la performance du rendu peut varier selon que les POST sont exécutés ou non, faussant l'évaluation des Core Web Vitals et du temps de réponse.

Concrètement, un site e-commerce qui charge les prix ou les stocks via POST risque de voir Googlebot indexer des pages produit sans prix. Un blog qui charge les commentaires ou les articles connexes via POST peut se retrouver avec des pages jugées pauvres en contenu lors des rendus ultérieurs.

• Les requêtes GET sont mises en cache par Googlebot lors du rendu JavaScript, garantissant une cohérence entre rendus successifs.
• Les requêtes POST ne sont jamais cachées, ce qui peut créer des écarts d'indexation si du contenu critique en dépend.
• Un rendu initial peut afficher un contenu complet via POST, mais les rendus suivants ignoreront ces données.
• L'impact sur la performance du rendu varie selon la présence ou l'absence de réponses POST en cache.
• Les sites SPA ou headless qui abusent des POST pour récupérer du contenu s'exposent à une indexation partielle ou incohérente.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et elle clarifie un point souvent mal compris. Beaucoup de SEO pensent que toute requête HTTP effectuée lors du rendu sera rejouée systématiquement. C'est faux. Google optimise son processus en réutilisant ce qu'il peut réutiliser — c'est-à-dire les GET. Les POST, eux, sont traités comme des actions à usage unique.

Sur le terrain, on observe effectivement des cas où des pages rendues en JavaScript affichent du contenu variable selon le moment du rendu. Un site qui charge ses FAQ via POST peut voir Google indexer tantôt la version complète, tantôt une version sans réponses. [A vérifier] : Google communique rarement sur la fréquence de réexécution du JavaScript pour une URL donnée, ce qui rend difficile de prévoir quand un POST sera rejoué ou non.

Quelles nuances faut-il apporter à cette règle ?

Le cache de Googlebot n'est pas éternel. Les ressources GET restent en cache pendant une durée limitée — probablement liée aux en-têtes Cache-Control et à la fréquence de crawl de l'URL. Si une ressource GET expire, elle sera rejouée. Mais pour les POST, il n'y a aucun mécanisme de cache : chaque rendu initial les exécute, chaque rendu ultérieur les ignore.

Autre nuance : cette règle s'applique au rendu JavaScript, pas au crawl HTML statique. Si votre page sert du HTML complet côté serveur et que le JavaScript ajoute ensuite du contenu via POST, le contenu statique sera toujours indexé. Le problème concerne uniquement les sites qui dépendent du JavaScript pour afficher du contenu critique.

Dans quels cas cette règle devient-elle un vrai problème ?

Soyons honnêtes : la plupart des sites bien conçus n'utilisent pas POST pour charger du contenu indexable. Les API REST modernes privilégient GET pour la récupération de données. Mais certains frameworks ou architectures legacy, notamment des CMS headless ou des applications React/Vue mal configurées, peuvent envoyer des POST par défaut.

Le vrai risque concerne les sites qui chargent des éléments critiques pour le SEO via POST : titres, descriptions, corps de texte, données structurées. Si ces éléments ne sont visibles que lors du premier rendu, Google peut indexer une version appauvrie de la page lors des rendus suivants. Et c'est là que ça coince : l'incohérence d'indexation nuit au ranking.

Que faut-il faire concrètement pour éviter ce piège ?

Première étape : auditer les appels réseau effectués lors du rendu de vos pages critiques. Ouvrez la console développeur, chargez une page, et filtrez les requêtes par méthode POST. Si vous voyez des POST qui chargent du contenu indexable — des blocs de texte, des produits, des articles — c'est un signal d'alerte immédiat.

Deuxième étape : migrer ces appels vers GET. Si votre API ou votre framework envoie des POST par défaut, reconfigurez-les pour utiliser GET lors de la récupération de données. C'est une bonne pratique HTTP de toute façon : GET pour lire, POST pour écrire. La plupart des frameworks modernes permettent de spécifier la méthode HTTP dans la configuration des appels API.

Quelles erreurs éviter lors de la migration ?

Ne vous contentez pas de remplacer POST par GET sans vérifier les en-têtes Cache-Control. Si vos réponses GET sont marquées comme non-cachables (Cache-Control: no-store), Google ne les mettra pas en cache non plus, et vous perdez l'avantage de la migration. Assurez-vous que vos réponses GET incluent des directives de cache appropriées.

Autre erreur fréquente : envoyer des payloads complexes dans l'URL via GET. Techniquement possible, mais les URLs trop longues posent problème — limites serveur, troncature dans les logs, mauvaise UX. Si votre POST envoyait un JSON de 2ko, repenser l'architecture de l'API est probablement nécessaire plutôt que de tout passer en query string.

Comment vérifier que mon site est conforme après correction ?

Utilisez Google Search Console et l'outil d'inspection d'URL. Demandez un rendu en direct, puis comparez la version rendue avec ce que vous voyez en production. Si le contenu critique apparaît dans les deux cas, c'est bon signe. Sinon, creusez dans l'onglet réseau pour identifier les requêtes qui manquent.

Testez également avec des outils comme Screaming Frog en mode rendu JavaScript ou Oncrawl. Ces outils simulent le comportement de Googlebot et peuvent révéler des incohérences entre le HTML statique et le contenu rendu. Si vous constatez des écarts, c'est probablement lié à des POST non rejoués.

• Auditer tous les appels POST effectués lors du rendu JavaScript des pages critiques.
• Migrer vers GET les appels qui chargent du contenu indexable (textes, produits, données structurées).
• Vérifier que les réponses GET incluent des directives Cache-Control appropriées pour être mises en cache.
• Tester le rendu via Google Search Console et comparer avec la version en production.
• Surveiller les logs serveur pour détecter d'éventuels POST encore présents après migration.
• Documenter les appels API et leur méthode HTTP pour éviter les régressions lors des futures évolutions.