Utiliser les status HTTP 304 pour alléger sa bande passante sans diminuer son SEO

Comme je l’ai dis il y a quelques jours, j’ai amélioré ma configuration Apache pour prévoir les attaques potentielles. Cependant, j’ai rapidement constaté un changement dans les logs d’Apache, en voyant une montée en flèche du nombre d’erreurs de codes de retour HTTP 304 pour les requêtes faites par le GoogleBot. Comme c’est lui qui parcours les pages pour le moteur de recherche de Google (qui m’amène 99% du trafic en provenance de moteurs), il était donc assez important que je m’en préoccupe. Or il semble que c’est en fait plutôt une très bonne chose.

Comme je l’ai dit dans les commentaires du billet précédemment cité, j’ai fait des recherches sur la documentation de Google, et j’y ai trouvé un passage plutôt explicite sur les erreurs codes de retour HTTP 304, que voici :

304 (Not modified)

The requested page hasn’t been modified since the last request. When the server returns this response, it doesn’t return the contents of the page.

You should configure your server to return this response (called the If-Modified-Since HTTP header) when a page hasn’t changed since the last time the requestor asked for it. This saves you bandwidth and overhead because your server can tell Googlebot that a page hasn’t changed since the last time it was crawled

C’est écrit là.

Donc a priori, Google ne considère pas mal ces erreurs de codes de retour, et il semble même que ce soit lui-même qui les demande, dans la mesure où le code d’erreur 304 répond à une demande par rapport à une modification éventuelle. En d’autres terme, la requête du moteur de Google contient un argument If-Modified-Since, c’est à dire « si la page a été modifié depuis telle date » ; ce qui signifie que Google ne souhaite pas re-télécharger la page si elle n’a pas été modifiée depuis la date qu’il donne. A mon avis, il est donc bon de gérer les erreurs 304 : cela n’affecte pas le SEO mais sauvegarde des ressources CPU et de la bande passante (surtout quand on connait la fréquence de passage du Bot Google, mieux vaut lui envoyer des 304 quand il n’y a pas eu de changement que de lui ré-envoyer la page à chaque nouvelle demande). J’ajoute en plus que suivant certaines configurations de WordPress (et surtout du plugin WP-Super-Cache), les requêtes venant du Bot Google donnent des pages générées et non des pages en cache, donc chaque requète du Bot implique beaucoup plus de ressources qu’une requête « classique » d’un utilisateur pour une page en cache.

Une potentielle preuve de mes propos

Pour bien montrer l’effet de ce que j’ai écris ci-dessus, voilà un screenshot de la page « Crawl Stats » du compte Google Webmaster Tools associé à AbriCoCotier.fr.

Si vous regardez ce qui a été encadré en rouge sur les trois graphiques, vous verrez à chaque fois une chute.

Trois chutes donc.

  • Sur le premier graphique, ce sont les « Pages crawled per day« , soient donc les pages parcourues par jour. On voit une chute ; je l’attribue au fait que je n’ai pas publié de billet sur les trois ou quatre derniers jours.
  • Sur le deuxième graphique, ce sont les « Kilobytes downloaded per day« , soit les ko téléchargés par jour par le GoogleBot. Ils ont beaucoup chuté. Je pense que c’est dû au fait que le GoogleBot a arrêté de télécharger les pages qui n’ont pas été modifié et ont été signalé par l’erreur 304 (celles dont on parlait ci-dessus). Cette chute est une bonne chose, elle indique que le serveur a consommé moins de bande passante pour envoyer des infos au GoogleBot, pour un résultat équivalent à ce que j’avais auparavant. En d’autres terme, j’ai fait des économies.
  • Le troisième graphique est celui du « Time spent downloading a page (in milliseconds)« , qui indique le temps moyen passé à télécharger une page. Je pense que la chute est due en partie au fait que le temps requis pour télécharger une page non-modifiée est équivalent à 0 seconde, donc cela diminue rapidement la moyenne, ce qui est bon également.

Enfin, je rappelle que pour l’instant, je n’ai vu aucun impact sur mon trafic venant de Google, donc je pense qu’il est très peu probable que j’aie été pénalisé d’une quelconque manière. Au final, il est donc possible que ces erreurs de codes de retour HTTP 304 m’aient permis de sauvegarder des ressources (bande passante et CPU) sans gêner mon référencement, ce qui est une bonne chose.

13 réflexions sur « Utiliser les status HTTP 304 pour alléger sa bande passante sans diminuer son SEO »

  1. Bonjour, super article.
    N’avez vous pas peur que cet article n’attise les tentatives de piratage sur votre site ?
    Merci

    RépondreRépondre
  2. @asicfr: Heu non, vu que je l’ai protégé d’abord (cet article suit la protection, en fait).

    En gros, je ne le publie que maintenant que je n’ai plus trop peur de me le faire pirater. Heureusement, je fais des sauvegardes régulières de ma BDD et des fichiers associés à mon sites, ce qui fait que je peux repartir de zéro en peu de temps.

    RépondreRépondre
  3. Je comprends, perso j’aurais peur de lancer un challenge à celui qui trouverait une autre faille.
    Bon, j’arrête là, conscient de participer aussi à « l’attisation »

    RépondreRépondre
  4. @asicfr: Boarf, y’a pas grand chose à gagner. Pour deux raisons. Déjà parce que la majorité des WordPress sont moins sécurisés que celui-là, et surtout parce que il y a pleins de WordPress qui sont sur des serveurs bien plus puissant que le mien (et donc c’est beaucoup plus intéressant de les attaquer).

    Ensuite, j’avais repéré les attaques juste après avoir installé un nouveau WordPress. Je pense donc que les attaques proviennent de bots qui relèvent sur les sites publiant les nouveaux WordPress (ceux qui sont « tout neufs », et donc très probablement pas encore correctement sécurisés). Maintenant, ça fait pas mal de temps que celui-là a été « renouvelé », et donc il y a moins de chances que l’on vienne chez moi avons une batterie de failles à tester.

    RépondreRépondre
  5. L’article est intéressant, je lirai l’article sur la configuration d’apache pour en savoir plus.

    (Petite erreur dans le titre : 403 à la place de 304)

    RépondreRépondre
  6. J’en profite pour dire que 403 est une erreur mais pas 304. Les erreurs sont 400+ (403,404,500 etc.)

    C’est juste un code de retour 🙂

    RépondreRépondre
  7. @Bastien: Oui, effectivement. Je vais mettre « Status », ce sera plus juste que Erreur et plus court que « Code de retour » (pour le titre au moins, je mettrai « code de retour » dans le reste du texte) 🙂

    Merci de me l’avoir fait remarquer, d’ailleurs.

    RépondreRépondre
  8. @Louis: En revanche, pour en revenir au sujet de l’article, je pense que cela peut avoir un impact au niveau référencement:

    Tu ne donnes que très peu de détails sur quelles pages sont en 304.

    304 = not modified, ce qui veut dire que le bot ne chargera pas la page, et se contentera de ce qu’il connait déjà. La home, par exemple, doit être en 200 si un article a changé. Enfin, si apache le gère tout seul, tant mieux, mais sinon, il faut y faire attention. Idem quand un commentaire est posté sur une page!

    RépondreRépondre
  9. @Bastien: Oui,c ‘est vrai, et c’est ce qui m’a fait peur au début. Mais sur ce que j’ai constaté, il n’y avait qu’une partie des pages (les 2/3 à vue d’oeil) qui passaient en 304 pour le bot Google. Je pense que le reste constitue celles pour lesquelles la page de cache avait été régénérée, ou tout simplement mis à jour.

    Cela dit, comme je n’ai pas une foule de commentaires sur le blog, ni une foule de nouveaux articles, je peux comprendre que pas mal de pages passent fréquemment en 304.

    RépondreRépondre
  10. Super intéressant ! comment paramètres tu ce statut ? C’est un entête http ?

    bertrand masselot
    volumium.fr, SEO et communication de marque

    RépondreRépondre
  11. C’est assez extrême comme solution je trouve, il faut être attentif à caler ce code au bon moment. La majorité des sites actifs font des liens vers les articles récents depuis toutes les pages, et c’est justifié pour leur donner du jus. Après une publication, chaque page doit donc être marquée en 403 après la visite de Google bot…

    Un système de cache performant me parait bien plus simple et moins risqué… Je considère qu’un crawl rate qui augmente en continu est un bon signe, à le réduire comme ça, rien ne prédit qu’il reviendra à la normale en un claquement de doigts.

    RépondreRépondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.