Le cache CDN peut-il présenter d’anciennes pages aux robots d’exploration des moteurs de recherche ?

Oui. Tant que le nœud CDN auquel accède le robot d’exploration conserve une ancienne version du HTML et que les règles de cache autorisent la réutilisation de cette copie, le robot reçoit l’ancienne page. La mise à jour réussie du serveur d’origine ne signifie pas que les nœuds périphériques ont été mis à jour. Toutefois, le fait que les résultats de recherche affichent encore un ancien titre ou un ancien extrait ne prouve pas à lui seul un dysfonctionnement du cache CDN : l’exploration, le traitement de l’index et l’affichage des résultats de recherche sont des étapes distinctes.

Pour diagnostiquer un problème de mise en cache CDN pour les robots d’exploration, il faut d’abord confirmer le contenu réellement reçu par le robot, puis déterminer pourquoi le cache n’a pas été mis à jour. Le fait de voir la nouvelle version dans un navigateur, ou de voir encore l’ancienne version dans les résultats de recherche, ne suffit pas à en déterminer la cause.

À quel niveau l’ancienne page continue-t-elle d’être utilisée ?

Une requête peut passer par un nœud périphérique, un cache intermédiaire et le cache de l’application sur le serveur d’origine. Si seul le nœud périphérique le plus externe est purgé alors qu’un cache intermédiaire conserve toujours une ancienne copie, le nœud périphérique récupérera à nouveau l’ancien contenu. Il faut donc interpréter la réussite d’une « purge » en fonction de sa portée : une URL précise, un répertoire entier, des étiquettes de cache et différents noms d’hôte ne couvrent pas les mêmes objets.

La clé de cache peut également modifier le diagnostic. L’adresse d’un même article avec ou sans paramètres, les chemins correspondant à différentes langues ou les noms d’hôte peuvent renvoyer à des copies distinctes. Si les règles de cache intègrent l’appareil, la région ou les en-têtes de requête à la clé de cache, le navigateur et le robot d’exploration peuvent aussi recevoir des versions différentes. À l’inverse, si le contenu multilingue varie selon les en-têtes de requête sans être correctement distingué dans le cache, une langue peut être servie à la place d’une autre.

Certaines configurations autorisent le renvoi d’un ancien contenu pendant la mise à jour en arrière-plan, ou l’utilisation d’une copie périmée en cas de défaillance du serveur d’origine. Ainsi, même après expiration de la durée de validité du cache, l’ancienne page peut encore être envoyée : « expiré » ne signifie pas « ne sera jamais renvoyé ».

Quels en-têtes de réponse influencent réellement le diagnostic ?

Commencez par examiner la requête du document HTML, et pas seulement celles des images, des scripts ou des feuilles de style. Le fait que les ressources statiques soient mises en cache longtemps ne signifie pas que le corps de l’article bénéficie de la même durée de validité. Les champs suivants doivent être interprétés en tenant compte des règles effectives du CDN :

• Cache-Control: max-age indique la durée de fraîcheur de la réponse ; pour un cache partagé, si s-maxage est présent, il faut examiner en priorité cette directive. La console du CDN peut également définir des règles de cache périphérique qui remplacent les en-têtes de réponse du serveur d’origine.
• no-cache autorise le stockage de la réponse, mais exige une validation avant toute nouvelle utilisation ; no-store demande de ne pas stocker la réponse. Confondre les deux peut créer un écart entre la configuration et le comportement attendu.
• Age peut aider à estimer l’âge d’une réponse mise en cache, mais ne prouve pas à lui seul que le corps est ancien ou récent. Un indicateur de cache indique également uniquement si le cache a été utilisé ; il doit être examiné avec les informations de version présentes dans le corps.
• ETag et Last-Modified servent aux requêtes conditionnelles. Si le corps a changé mais que le validateur n’a pas été correctement mis à jour, une réponse 304 peut être renvoyée à tort, incitant le demandeur à continuer d’utiliser une copie existante.

stale-while-revalidate autorise le renvoi d’un contenu périmé pendant une période définie, suivi d’une validation en arrière-plan ; stale-if-error autorise l’utilisation d’une ancienne copie dans certaines conditions d’erreur. Pour les pages dont la fraîcheur doit être strictement maîtrisée, il faut déterminer si ces périodes sont acceptables, plutôt que de se contenter de modifier une durée de cache.

Transformer la réception d’une ancienne page en preuve vérifiable

Choisissez une URL complète concernée par le problème et notez le nouveau titre, une phrase du corps ou un marqueur de version qui devrait y figurer. Enregistrez les en-têtes et le corps de la réponse avec une requête GET standard, par exemple en exécutant curl -sS -D headers.txt -o page.html 'https://example.com/article'. Une requête HEAD ne permet pas de vérifier le corps, et certains services traitent HEAD et GET différemment.

Comparez ensuite les contenus renvoyés par le serveur d’origine et par le CDN, en conservant le même nom d’hôte, le même chemin, les mêmes paramètres et les mêmes conditions de langue. L’accès direct à l’adresse IP du serveur d’origine peut conduire au site par défaut et fausser le diagnostic ; la comparaison avec le serveur d’origine doit utiliser une méthode d’accès qui conserve le nom d’hôte et la configuration TLS appropriés. Si le serveur d’origine renvoie lui-même l’ancienne version, vérifiez d’abord l’état du déploiement, le cache de l’application ou la synchronisation des nœuds backend.

N’utilisez pas l’ajout arbitraire d’un paramètre aléatoire comme unique méthode de vérification. Ce paramètre peut contourner le cache ou être ignoré par la clé de cache ; de plus, l’URL testée peut différer de celle réellement consultée par le robot d’exploration. L’ajout de Cache-Control: no-cache à la requête ne remplace pas la vérification de la purge côté serveur ; le traitement dépend toujours de la configuration du CDN.

Remplacer le User-Agent de la requête par le nom d’un robot d’exploration permet uniquement de tester si les règles répartissent le trafic selon ce champ ; cela ne prouve pas que le véritable robot reçoit la même réponse. Les preuves les plus utiles sont les journaux d’accès du nœud périphérique, qui indiquent l’heure, l’URL complète, le nœud, l’état du cache et la version du contenu, ainsi que la vérification de l’origine de la requête selon les méthodes publiées par le moteur de recherche. L’absence de requête dans les journaux du serveur d’origine peut simplement signifier que la réponse a été servie depuis le cache périphérique.

Après la purge, quelle version faut-il vérifier ?

Lors d’un déploiement, confirmez d’abord que le serveur d’origine diffuse la nouvelle version, puis purgez le cache correspondant. Si l’ordre est inversé, le nœud peut recharger l’ancien contenu avant la mise à jour du serveur d’origine. En présence d’un cache intermédiaire, d’alias de page ou de chemins multilingues, procédez en fonction des relations réelles entre les caches et vérifiez que l’opération de purge est terminée ; le fait qu’une API confirme la prise en charge de la demande ne signifie pas que tous les nœuds ont été mis à jour.

Après la purge, récupérez à nouveau le contenu depuis l’URL d’origine et vérifiez le nouveau contenu, puis observez si la nouvelle version est toujours renvoyée lorsque le cache est de nouveau sollicité. Si les utilisateurs accèdent depuis plusieurs régions à l’étranger, effectuez aussi des vérifications dans différentes régions, car le résultat d’un seul nœud ne représente pas l’ensemble des nœuds. Si l’ancienne formulation apparaît toujours après la purge du HTML, vérifiez également si le corps de la page est chargé par une autre API, qui peut avoir son propre cache.

Conserver dans l’historique de déploiement la version du contenu, les éléments purgés et les résultats de vérification aide à distinguer un échec de déploiement d’un retard de mise à jour du cache en cas d’anomalie. Ce processus peut également constituer un enjeu technique concret dans l’analyse de l’impact de la transformation numérique sur la résilience des entreprises : le processus de rétablissement doit permettre de vérifier le contenu renvoyé à chaque niveau.

Si l’exploration réelle a déjà récupéré la nouvelle version alors que les résultats de recherche restent inchangés, vérifiez l’heure de l’exploration, l’URL canonique et l’état du traitement de l’index. Dans ce cas, purger le cache à répétition ne fera pas apparaître immédiatement les changements dans les résultats de recherche, et il n’est pas non plus recommandé de laisser les robots contourner tous les caches à long terme. Pour faciliter un diagnostic continu, le contenu des pages doit rester cohérent, les règles de cache doivent être explicables et les résultats des mises à jour doivent pouvoir être vérifiés.