Faut-il abandonner POST pour les APIs crawlables et basculer tout en GET ?

Pourquoi Google ne peut-il pas cacher les requêtes POST ?

Les requêtes POST ne sont pas idempotentes par nature. Autrement dit, envoyer deux fois la même requête POST peut théoriquement produire deux résultats différents ou déclencher deux actions distinctes côté serveur.

C'est pour cette raison que les navigateurs et les systèmes de cache — Googlebot y compris — ne peuvent pas stocker les réponses aux POST de la même manière qu'ils le font pour les GET. Un POST pourrait créer une ressource, modifier un état, ou déclencher un effet de bord. Le cacher reviendrait à ignorer l'intention du protocole HTTP.

Qu'est-ce que ça change pour le crawl budget ?

Le crawl budget désigne le nombre de requêtes que Googlebot peut allouer à votre site dans un laps de temps donné. Chaque fois qu'un bot visite une page nécessitant un rendu JavaScript, il exécute le code, déclenche les requêtes API, et attend les réponses.

Si ces APIs fonctionnent en POST, Googlebot doit refaire l'appel à chaque passage, même si le contenu n'a pas changé. Sur un site avec des milliers de pages dynamiques, ça représente une charge serveur considérable et un gaspillage de crawl budget. En GET, la réponse peut être mise en cache (avec les headers HTTP appropriés), ce qui évite de solliciter inutilement le serveur et accélère le rendu.

GraphQL peut-il fonctionner en mode GET ?

Oui, et c'est justement ce que Martin Splitt recommande. GraphQL est généralement utilisé avec POST parce que les queries peuvent être longues et complexes, ce qui pose problème avec la limite de taille des URLs en GET.

Mais techniquement, rien n'empêche de passer une query GraphQL en paramètre d'URL via GET, tant qu'elle reste en dessous de la limite des 2000 caractères environ. Pour les queries courantes et répétitives nécessaires au rendu, c'est tout à fait faisable. L'avantage est double : réduction du nombre de requêtes grâce à la flexibilité de GraphQL, et mise en cache possible grâce à GET.

• POST ne peut pas être caché par Googlebot, ce qui consomme du crawl budget inutilement à chaque visite
• GET permet la mise en cache via les headers HTTP standards (Cache-Control, ETag, etc.)
• GraphQL en GET combine les avantages de la flexibilité des queries et de la mise en cache
• Chaque endpoint POST sollicité lors du rendering génère une requête serveur systématique, même si le contenu est identique
• Sur un site à fort volume de pages dynamiques, le passage de POST à GET peut réduire drastiquement la charge serveur et libérer du crawl budget

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

Oui, et c'est même une des recommandations les plus claires de Martin Splitt. On constate régulièrement que les sites JavaScript-heavy avec des APIs POST ont des problèmes d'indexation lents, surtout quand le volume de pages augmente.

Les logs serveur montrent que Googlebot refait systématiquement les appels POST lors de chaque crawl, même sur des contenus stables. En revanche, quand on bascule ces mêmes endpoints en GET avec des headers de cache appropriés (max-age, ETag), on observe une baisse significative du nombre de hits serveur et une progression plus rapide de l'indexation. Rien de surprenant, c'est du HTTP de base, mais beaucoup de devs modernes l'ignorent.

Quelles sont les limites pratiques de cette recommandation ?

La limite principale, c'est la taille des URLs. Les requêtes GET passent leurs paramètres dans l'URL, et la plupart des serveurs acceptent jusqu'à 2000-8000 caractères selon la config. Pour GraphQL, ça peut vite devenir problématique si vos queries sont complexes avec beaucoup de champs imbriqués.

Autre point : les données sensibles ne devraient jamais transiter en GET, parce que l'URL complète apparaît dans les logs serveur, les referrer headers, l'historique du navigateur. Si votre API manipule des tokens, des IDs utilisateur, ou toute donnée qui ne devrait pas être loggée en clair, POST reste le bon choix — mais alors ce contenu ne devrait probablement pas être exposé à Googlebot de toute façon.

[A verifier] Martin Splitt ne précise pas si Googlebot respecte les directives de cache pour les GET lors du rendering. On suppose que oui, mais aucune doc officielle ne détaille le comportement exact du cache interne de Googlebot pendant le rendu JavaScript. Les tests terrain suggèrent qu'il respecte Cache-Control, mais il faudrait des validations plus poussées sur différents types de contenus.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si le contenu renvoyé par l'API n'est pas nécessaire à l'indexation (espaces membres, interfaces d'admin, contenus derrière login), alors peu importe que ce soit POST ou GET. Googlebot ne va pas se connecter ni tenter de crawler ces zones.

De même, si votre site fonctionne principalement en server-side rendering (SSR) et que les APIs ne sont appelées qu'en client-side pour des interactions post-chargement, ça n'impacte pas le crawl. Le bot récupère le HTML déjà rendu, sans avoir besoin d'exécuter les appels API. C'est d'ailleurs une des raisons pour lesquelles SSR reste la solution la plus robuste pour le SEO.

Que faut-il faire concrètement pour migrer de POST vers GET ?

D'abord, identifier quelles APIs sont sollicitées pendant le rendu des pages indexables. Utilisez les Chrome DevTools en mode "Disable cache" et inspectez l'onglet Network pendant le chargement. Filtrez par XHR/Fetch et notez toutes les requêtes POST qui interviennent avant que le contenu principal soit visible.

Ensuite, pour chaque endpoint POST identifié, évaluez s'il peut être converti en GET. La plupart des APIs REST classiques (lister des produits, récupérer un article, charger des métadonnées) peuvent facilement basculer en GET. Pour GraphQL, transformez vos queries POST en GET avec la query en paramètre d'URL, à condition qu'elle reste sous 2000 caractères.

Côté serveur, configurez les headers de cache HTTP appropriés : Cache-Control avec un max-age raisonnable (300-3600 secondes selon la fréquence de mise à jour), ETag pour permettre la validation conditionnelle, et Vary si le contenu change selon certains headers (Accept-Language, etc.). Sans ces headers, même en GET, le cache ne sera pas efficace.

Quelles erreurs éviter lors de la migration ?

Ne convertissez pas en GET des endpoints qui modifient des données (création, mise à jour, suppression). C'est une violation du standard HTTP et ça peut créer des problèmes de sécurité graves. GET doit rester idempotent et safe.

Évitez aussi de mettre en cache des contenus qui changent fréquemment avec un max-age trop long. Si vous cachez une API de stock produit pendant 1 heure alors que le stock change toutes les 5 minutes, Googlebot (et vos utilisateurs) verront des données périmées. Ajustez la durée de cache en fonction de la volatilité réelle de vos données.

Enfin, attention aux queries GraphQL trop longues. Si vous dépassez la limite d'URL du serveur, la requête échouera silencieusement ou renverra une 414 (URI Too Long). Testez systématiquement vos endpoints GET sur plusieurs environnements (dev, staging, prod) avant de déployer.

Comment vérifier que l'optimisation est effective ?

Comparez les logs serveur avant/après migration. Vous devriez observer une baisse du nombre de hits pour les endpoints convertis en GET, surtout pour les passages répétés de Googlebot. Utilisez aussi la Search Console pour surveiller l'évolution du crawl budget : si l'indexation s'accélère ou si le nombre de pages crawlées par jour augmente, c'est bon signe.

Testez avec l'outil URL Inspection de la Search Console et comparez le rendu avant/après. Le contenu doit apparaître identique, mais le temps de rendu peut diminuer si le cache fonctionne bien. Vous pouvez aussi utiliser des outils comme Screaming Frog en mode JavaScript rendering pour simuler le comportement de Googlebot.

• Auditer les appels API déclenchés pendant le rendu JavaScript des pages indexables
• Convertir les endpoints POST en GET pour toute API nécessaire à l'affichage du contenu crawlable
• Configurer Cache-Control, ETag et Vary côté serveur pour permettre la mise en cache
• Tester la longueur des URLs GraphQL en GET et s'assurer qu'elles restent sous 2000 caractères
• Valider que les endpoints GET ne modifient jamais de données (respect du standard HTTP)
• Comparer les logs serveur et les métriques de crawl avant/après migration pour mesurer l'impact