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.
Bonjour, super article.
N'avez vous pas peur que cet article n'attise les tentatives de piratage sur votre site ?
Merci
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"
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)
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 :)
Super intéressant ! comment paramètres tu ce statut ? C'est un entête http ?
bertrand masselot
volumium.fr, SEO et communication de marque
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.