Comment bien utiliser le code 304 en SEO ?

Parmi les codes réponses qui peuvent être renvoyés dans les en-têtes HTTP par un serveur aux navigateurs ou aux crawlers sur la demande d’une URL, les statuts HTTP 200 sont en général les plus représentés (200 : Requête traitée avec succès). D’autres codes réponses peuvent être renvoyés comme les erreurs 404 (ressource non trouvée) ou 410 (la ressource n'est plus disponible), ainsi que des redirections 301 ou 302 en cas de déplacement d’une URL. Mais un code réponse particulier (et assez peu connu et utilisé) peut être renvoyé dans certains cas par les serveurs. Il s’agit du statut HTTP 304, qui signifie que le document n’a pas été modifié depuis la dernière requête. Nous allons aborder dans cet article son fonctionnement, ainsi que son intérêt d’un point de vue utilisateur, mais également des enjeux que ce code réponse peut avoir d’un point de vue SEO.

Visualiser le code réponse « 304 Not Modified »

Pour afficher les différents codes réponses pour chaque élément chargé lors de l’affichage d’une page Web, il est possible de passer par l’onglet « Réseau » ou « Network » de l’inspecteur d’éléments des principaux navigateurs Web :

Codes réponses reçus par le navigateur pour chaque élément d'une page

Le code de réponse 304 Not Modified indique au serveur qu'il n’est pas nécessaire de retransmettre les ressources demandées. C'est une redirection implicite vers une ressource mise en cache au préalable. Mais comment le serveur peut-il décider de ne pas renvoyer une ressource car cette dernière serait déjà en cache ?

En-tête de validation

Last-modified et HTTP/1.0

Avec le protocole HTTP 1.0, l’en-tête de validation « Last modified » est envoyé par le serveur lorsque le navigateur d’un internaute (ou un crawler comme Googlebot) demande une ressource. Il peut s’agir d’une page HTML, comme d’une image ou de fichiers statiques tels que des feuilles de styles (.css) ou des fichiers Javascript (.js). Cette information transmise par les en-têtes HTTP permet d’activer le processus de validation pour toute demande ultérieure.

Prenons l’exemple d’un fichier HTML de 269 Ko qui serait récupéré par un navigateur. Une fois récupéré, si ce fichier est appelé à nouveau (et qu’il n’a pas de date d’expiration précisée via la directive « Cache-Control »), le navigateur va lancer une requête vers le serveur avec l’en-tête « If-Modified-Since ». Cet en-tête contiendra la dernière date de modification connue, envoyée au préalable par le serveur via l’information « Last Modified ».

Validation d'une ressource via Last modified

Si la date est différente, alors cela signifie que le fichier a été modifié depuis son dernier chargement, le navigateur téléchargera donc à nouveau la ressource de 269Ko en intégralité.

Dans le cas où la date de modification connue du navigateur via « If-Modified-Since » serait identique à la date de modification (Last-Modified) de la ressource demandée sur le serveur, un code réponse 304 sera renvoyé dans une requête de type HEAD (légère donc puisqu’il ne s’agit que de données d’en-têtes et non du corps d’un fichier).

Ce code réponse 304 retourné par le serveur permet d’indiquer que la ressource n’a pas été modifiée, et que le navigateur de l’internaute peut utiliser la ressource déjà récupérée disponible dans son cache.

Etag et HTTP/1.1

Avec l’arrivée du protocole HTTP/1.1, un nouvel en-tête a vu le jour. En effet, le principal défaut de « Last-modified » réside dans le fait qu’un document peut ne pas avoir été modifié, et que les éléments qui entourent ce document l’aient été. Si nous prenons l’exemple d’un article qui renverrait un en-tête « Last-modified » avec une date liée à sa date de modification dans le CMS, cela ne signifie pas pour autant que les éléments autour de cet article qui habillent la page Web (blocs de liens, ressources connexes, footer) soient les mêmes.

Pour ce qui est du fonctionnement de l’Entity-Tag, il se base sur la génération d’une empreinte liée à l’ensemble du contenu d’un fichier. S’il s’agit d’un fichier HTML par exemple, il suffit qu’un élément d’une page HTML ait été modifié (ex : lien en bas de page) pour que l’empreinte soit différente. Et c’est ce comportement qui lui donne un avantage sur l’en-tête « Last-Modified » vue précédemment.

Prenons un fichier HTML : lors de la première récupération de la page par un navigateur, une empreinte du fichier est envoyée dans l’en-tête Etag par le serveur (sous la forme d’une suite de caractères). Ex : « Etag : UreJ2G ». Si le navigateur rappelle la même ressource par la suite, il va envoyer une requête au serveur contenant l’empreinte qu’il avait reçu au préalable, dans l’en-tête « If-None-Match », soit « If-None-Match : UreJ2G » dans notre exemple.

EntityTag pour la validation d'une ressource avec HTTP/1.1

Si le serveur constate que l’empreinte est différente de celle qu’il avait envoyé lors de la première demande, l’intégralité du fichier HTML sera récupérée par le serveur. Dans le cas où l’empreinte du fichier serait la même pour les demandes ultérieures, le serveur renverrait seulement une requête de type HEAD avec un code réponse « 304 Not Modified » indiquant que la ressource qui se trouve dans le cache du navigateur est toujours valable.

Intérêt du code réponse 304

Que cela se fasse via l’en-tête Last-Modified ou ETag, ce cache de validation semblable à une redirection implicite vers une ressource mise en cache, permet de limiter le transfert de données entre un serveur et un navigateur, et d’améliorer le temps de chargement d’une page. Au-delà de son intérêt pour les internautes, voyons la façon dont il peut impacter le crawl d’un site par les robots d’exploration de moteurs de recherche.

Budget de crawl – rappel

Le budget de crawl ne concerne que les sites de taille moyenne ou grande (plus de 10 000 pages uniques) dont le contenu change très rapidement (quotidiennement), ainsi que les sites très volumineux (plus d'un million de pages uniques) dont le contenu change assez souvent (une fois par semaine). Comme Google l’indique dans sa documentation, Google doit gérer son crawl entre deux indicateurs : le besoin d’exploration et la limite d’exploration. Et pour les sites de plus de 10 000 URL avec un contenu qui change quotidiennement, l’utilisation des 304 peut avoir un impact bénéfique sur le budget de crawl.

Besoin d’exploration et limite d’exploration

Le besoin d’exploration est évalué par Google en fonction de plusieurs facteurs dont :

L’inventaire perçu par Google, en fonction de plusieurs paramètres (restrictions de crawl par exemple) ;
La popularité des URL, avec un crawl plus important sur les URL les plus maillées ;
L’obsolescence, afin que les données de l’index qui sont proposées aux internautes soient à jour.

La limite de la capacité d'exploration peut varier en fonction de différents facteurs :

Etat de l’exploration, et temps de réponse du serveur pour permettre un crawl correct (sans pour autant surcharger le serveur d’un site) ;
Limite d’exploration définie dans la Search Console par le propriétaire d’un site ;
Limite d’exploration définie par Google, qui doit faire des choix par rapport aux ressources dont il dispose (Google dispose de ressources importantes, mais non infinies !).

Google doit donc adapter la façon dont il crawle un site, en trouvant le juste équilibre entre ses besoins d’exploration mais également ses limites de la capacité d'exploration.

Impact sur le budget de crawl

L’utilisation du code réponse 304 permet donc d’améliorer le temps machine que Google attribue à chaque site Web, afin d’améliorer le crawl de ce dernier. Cela permet aux robots d’exploration de ne pas re-télécharger des fichiers déjà récupérés, et donc d’économiser des ressources pour maximiser leur besoin d’exploration afin d’avoir un maximum d’URL à jour dans l’index des moteurs de recherche.

Il a déjà été constaté sur des sites à forte volumétrie une amélioration du taux de crawl, grâce à l’utilisation de codes réponses 304, gérés via les en-têtes de validation décrites précédemment. Ils peuvent être paramétrés afin de réduire le crawl sur des pages HTML (ou images) qui subiraient moins de modifications régulières que d’autres fichiers. Il est à noter qu’avec ses capacités d’apprentissage, il est possible que Google réduise sa fréquence de crawl sur des ressources qui seraient rarement modifiées.

Avec les besoins d’exploration de Google pour effectuer le rendu JS de nombreuses pages, l’utilisation d’en-têtes de validation sur des ressources JS et CSS est recommandée, ces ressources étant chargées sur une grande partie des pages d’un même site.

Vision dans la Search Console

Afin de mieux comprendre la façon dont ce code réponse 304 peut impacter le crawl, il est possible d’analyser les codes réponses reçus et leur impact sur le crawl directement dans la Search Console via l’entrée : « Paramètres » > « Statistiques sur l’exploration » > « Ouvrir le rapport » :

Statistiques sur l'exploration par code réponse dans la Search Console

En cliquant sur un code réponse, 304 dans notre cas, il est possible de voir l’évolution des demandes de validations effectuées par Googlebot. La corrélation entre la mise en place de 304 et le taux de crawl peut être constatés sur les sites ayant une forte volumétrie de pages.

Évolution de l'exploration du site par Google (Search Console)

Ce code réponse est donc un véritable atout pour améliorer son budget de crawl, tout en optimisant le temps de chargement d’une page via l’utilisation des ressources déjà en cache dans le navigateur des internautes.