Les APIs GET sont-elles vraiment mises en cache par Google comme les autres ressources ?

Pourquoi cette distinction entre GET et POST est-elle cruciale pour le crawl ?

Googlebot traite les requêtes GET comme des demandes de récupération de contenu stable. C'est le principe même du web sémantique : GET = lecture, POST = écriture ou action. Quand un bot crawle une URL, il s'attend à ce qu'une requête GET renvoie toujours le même contenu pour les mêmes paramètres.

La mise en cache repose sur ce postulat. Si une API répond via GET, Google applique les mêmes règles qu'à une image ou un script : il stocke la réponse en fonction des headers HTTP (Cache-Control, Expires, ETag). Une requête POST, par nature, modifie un état côté serveur — impossible de la cacher sans risquer d'incohérence.

Concrètement, qu'est-ce qui change pour un site qui charge du contenu via API ?

Un site e-commerce qui affiche des prix ou des stocks via une API GET peut voir Googlebot servir des données périmées si les headers de cache sont trop généreux. Le bot lit ce qu'il a en mémoire, pas l'état réel du catalogue.

À l'inverse, un site qui utilise POST pour récupérer du contenu critique — une pratique absurde mais vue sur le terrain — garantit que Google ne mettra jamais cette ressource en cache. Résultat : le contenu peut tout simplement ne pas être indexé si le bot ne peut pas le récupérer de manière fiable.

Les headers HTTP deviennent-ils un enjeu stratégique ?

Absolument. Google respecte scrupuleusement Cache-Control: no-cache, must-revalidate, et les directives d'expiration. Si une API renvoie un max-age=86400 (24h), le bot ne repassera pas avant ce délai, même si le contenu a changé entre-temps.

La différence entre un cache serveur et un cache bot est ténue mais critique. Le premier optimise la charge, le second conditionne ce que Google indexe. Un header mal configuré peut figer une version obsolète dans l'index pendant des jours.

• GET = mise en cache automatique si les headers HTTP l'autorisent
• POST = jamais mis en cache, même avec des headers favorables
• Les headers Cache-Control définissent la durée de vie d'une réponse GET dans le cache de Google
• Un contenu critique chargé via GET avec un max-age trop long peut devenir obsolète dans l'index
• Utiliser POST pour du contenu public destiné à l'indexation est une erreur technique majeure

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

Oui, et c'est confirmé depuis des années par les logs serveur. Quand on analyse les requêtes Googlebot, on constate qu'il ne redemande pas une ressource GET tant que son cache est valide. Les audits de crawl budget montrent que le bot saute systématiquement les ressources encore fraîches.

Le piège ? Beaucoup de devs configurent des APIs publiques avec des max-age par défaut hérités de frameworks (souvent 3600s ou plus). Résultat : Googlebot lit des données périmées sans que personne ne s'en aperçoive. C'est invisible en navigation humaine, mais critique en indexation.

Quelles zones d'ombre subsistent dans cette déclaration ?

Martin Splitt ne précise pas comment Google gère les paramètres dynamiques dans les URLs GET. Une API appelée avec ?timestamp=xxx génère techniquement une URL unique à chaque requête — donc pas de cache. Mais qu'en est-il des paramètres de tri, pagination, ou filtres ? [À vérifier]

Autre point flou : le comportement avec les réponses vides ou 204 No Content. Si une API GET renvoie un 204, Google met-il en cache cette absence de contenu ? Sur les sites headless, c'est un pattern courant pour signaler qu'une donnée n'existe plus. Silence radio de Google sur ce cas.

Dans quels scénarios cette règle pose-t-elle problème ?

Sur les sites à contenu ultra-volatile : médias en temps réel, plateformes de trading, inventaires dynamiques. Un article de breaking news chargé via API GET avec un cache de 5 minutes peut être obsolète dans l'index pendant cette fenêtre.

Pire encore : les sites qui font du A/B testing côté API. Si l'API GET renvoie une variante A puis une variante B selon un cookie, mais que Google cache la première réponse, il ne verra jamais les autres versions. Le cloaking involontaire guette.

Que faut-il auditer en priorité sur un site qui utilise des APIs ?

Premièrement, cartographier toutes les APIs GET qui servent du contenu visible par l'utilisateur. Pas seulement les endpoints évidents — aussi les micro-services internes, les CDN de données, les APIs tierces (avis clients, stocks, tarifs).

Deuxièmement, vérifier les headers HTTP réels renvoyés par chaque endpoint. Pas ceux de la doc, ceux qu'on observe dans un curl ou les DevTools. Un Cache-Control absent équivaut souvent à un cache implicite de plusieurs heures selon le serveur.

Comment configurer les headers de cache pour l'indexation ?

Pour du contenu destiné à être indexé, le sweet spot se situe entre no-cache (trop agressif, tue le crawl budget) et max-age=3600 (trop long, risque d'obsolescence). Un max-age=60 à 300 secondes est un bon compromis pour la plupart des sites.

Ajouter systématiquement must-revalidate ou stale-while-revalidate pour forcer Googlebot à revérifier la fraîcheur. Et si le contenu change rarement, mieux vaut utiliser un ETag — le bot fait une requête conditionnelle et économise de la bande passante si rien n'a bougé.

Quelles erreurs techniques guettent les implémentations headless ?

L'erreur classique : charger du contenu critique en POST "pour des raisons de sécurité". C'est une incompréhension du rôle de POST. Si la donnée est publique et doit être indexée, elle doit transiter en GET, point.

Autre faute fréquente : ne pas tester le rendu Googlebot avec les mêmes paramètres de cache que la prod. L'outil de test d'URL de Search Console ne simule pas toujours fidèlement le comportement du cache réel. Il faut croiser avec des logs serveur pour voir ce que le bot récupère vraiment.

• Lister toutes les APIs GET servant du contenu indexable
• Vérifier les headers Cache-Control, Expires, ETag sur chaque endpoint
• Configurer un max-age entre 60 et 300 secondes pour le contenu dynamique
• Ajouter must-revalidate ou stale-while-revalidate pour forcer la revérification
• Ne JAMAIS utiliser POST pour récupérer du contenu destiné à l'indexation
• Tester le rendu réel avec Google Search Console + analyse des logs serveur