Nous avons déjà eu l’occasion d’expliquer pourquoi il était intéressant de s’assurer que votre plateforme web gère bien les requêtes conditionnelles, et en particulier celles qui servent à gérer le comportement de cache de Googlebot : les requêtes if-modified-since et if-none-match.
En clair, c’est une manière simple et efficace d’économiser du budget de crawl et donc de faire croître le nombre de pages crawlées par jour et/ou de diminuer les pages que Google « oublie » d’explorer et/ou d’accélérer la vitesse avec lesquelles vos contenus sont indexés.
Pour un petit site (moins de quelques milliers de pages) ce type d’optimisation ne change pas grand chose au comportement de Googlebot. Au dela, cela vaut le coup d’exploiter cette piste.
Voici les deux articles dans lesquels nous avions expliqué d’une part le fonctionnement et l’intérêt de ces requêtes conditionnelles, et d’autre part les derniers conseils donnés par Google à ce sujet :
Mais dans la pratique, comment fait-on pour tester le bon fonctionnement de la plateforme ? C’est ce que nous allons expliquer dans cet article.
Première vérification : quelle proportion de requêtes http renvoient 304 ?
Un coup d’oeil dans le rapport « statistiques sur l’exploration » dans la Google Search Console va vous donner la proportion de requêtes http(s) qui renvoient un code 304.
Ce code est renvoyé par votre plateforme web quand la réponse à une requête « if-modified-since » ou « if-none-match » est « Not Modified ». En clair : la page n’a pas été modifiée depuis la dernière interrogation.
Ici on voît que 10% des requêtes http(s) effectuées par Googlebot renvoient un code 304. C’est un chiffre suffisamment élevé pour dire que la plateforme supporte au moins partiellement ces requêtes conditionnelles. Après 10% c’est peu pour un site dont les pages ont une durée de vie de plusieurs semaines dans 90% des cas.
La GSC fournit un rapport plus détaillé qu’il est utile de consulter car la valeur « 10% » est un chiffre très arrondi.
Le rapport fournit des exemples d’urls qui renvoient 404. La consultation de ce tableau d’exemples permet déjà de détecter un comportement correct mais dans quelques cas particuliers seulement :
- par exemple, les 304 sont renvoyées uniquement pour des images, mais pas de trace de pages HTML. Dans ce cas, l’outil qui délivre vos images (un CDN ou un DAM) gère les requêtes conditionnelles, mais pas le reste de la plateforme… Oops
- autre cas : les pages html renvoyant des 304 correspondent à certains modèles de pages, mais pas à tous. Par exemple, vous ne voyez pas de pages produit dans ces exemples.
Est-ce que les stats fournies par la GSC sont fiables ?
En principe oui, mais il n’est pas rare que le nombre de 304 reporté par la GSC soit en décalage important avec d’autres sources d’informations, comme les cas de réponse 304 identifiés dans les logs serveurs. Identifier les causes de ces différences peut être plus ou moins simple suivant ce qui cause ces différences. Mais une fois ces causes identifiées, on retombe en général sur des chiffres proches de ceux donnés par Google dans la GSC.
Comment tester rigoureusement le bon fonctionnement des requêtes conditionnelles
Si vous voulez comprendre pourquoi vos stats d’urls répondant 304 sont en anomalie, la solution la plus simple est d’utiliser cet outil pour simuler des requêtes curl :
Cet outil s’appelle Reqbin et ce que l’on veut faire ce sont des requêtes de type « HEAD »
L’option -I permet de faire une requête de type « HEAD » qui ne renvoie que le header. Et l’option -H permet d’ajouter un champ d’en-tête, ici la requête « If-Modified-Since ».
Comme la valeur indiquée dans la requête « If-Modified-Since » (qui en situation réelle est la date de mise en cache du fichier du navigateur) est plus ancienne que la date de dernière modification, le serveur réagit en répondant par un code 200. Avec une requête de type GET, il renverra la nouvelle version de la page.
Si par contre je rentre une date postérieure à la date de dernière modification, alors le serveur web répond par un code 304.
La page n’a pas été modifiée depuis la dernière mise en cache, inutile de télécharger la page. Le code renvoyé est « 304 Not Modified »
Pour Wikipedia, ce test montre que la prise en compte de la requête conditionnelle IMS (If-Modified-Since) est parfaitement fonctionnelle.
Test de la prise en charge des eTags
Une autre solution pour bien gérer le rafraichissement des pages en cache est d’utiliser un eTag. L’eTag est une chaine de caractère alphanumérique qui identifie une version de la page, et une seule. Il est changé à chaque fois que le contenu de la page change (en tout cas c’est le fonctionnement attendu).
Tous les sites web ne génèrent pas forcément d’eTags, il faut :
- soit une extension spéciale
- soit un développement spécifique
- soit un simple paramétrage
Google préconise d’utiliser plutôt le test des eTags, nous expliquerons plus tard pourquoi.
Pour tester la prise en charge correcte de la comparaison des eTags pour invalider les pages en cache, le principe avec Reqbin est similaire.
On remplace la requête condtionnelle « If-Modified-Since » par « If-None-Match ». Et on rentre la valeur de l’e-Tag à tester.
Avec la même valeur que celle de la dernière version, la réponse doit être un code 304
Et 200 avec des valeurs différentes.
Attention dans vos tests à la syntaxe de la valeur de l’eTag : un espace en trop ou un guillemet manquant et le résultat sera différent de celui que vous attendez.
Le test est négatif ou je n’ai pas de champ Lastmodified ou eTag dans les entêtes
Il est possible que vous ne voyiez pas les champs eTag ou Lastmodified pour une bonne raison : on peut les rendre visibles ou non.
Par contre si le test avec Curl ci-dessus montre que votre plateforme ne gère ni les requêtes IMS ni le test de l’eTag, alors vous avez intérêt à corriger cela, surtout si vous avez un gros site.
En pratique, des tas de choses peuvent empêcher vos plateformes de bien gérer les champs IMS. Notamment des réglages différents entre l’applicatif, le serveur web, les reverse proxies et les DNS. Des instructions de gestion du cache contradictoires sont aussi souvent la cause de mauvais fonctionnement.
Le plus simple est souvent de se focaliser sur la génération d’eTags corrects, car il est plus facile d’obtenir le fonctionnement attendu avec cette aproche. C’est d’ailleurs probablement pour cela que Google, après avoir longtemps recommandé le support des requêtes IMS, s’est mis en décembre dernier à recommander les eTags.
Si, malgré tous ces conseils, vous n’arrivez pas à rendre votre plateforme ou votre CMS compatible avec le support des 304, n’hésitez pas à faire appel aux spécialistes de Neper