Cariboo

Google n'a jamais communiqué sur ce qui était réellement compris dans le "download time", mais oui, c'est forcément le temps de téléchargement mesuré par un crawler, donc un time to last byte (le temps pour télécharger le code HTML) en excluant les temps de rendition dans le navigateur et probablement aussi certaines ressources comme les js/css externes.

Dans la pratique, les temps communiqués par Google sont souvent plus faibles que ce que l'on mesure avec Screaming Frog : leur infrastructure est optimisée pour le crawl, ça se voit

Il faut faire attention avec les canonical et les hreflang, car leurs objectifs sont diamétralement opposés.

Dans ce cas particulier, il faut pointer OBLIGATOIREMENT vers l'url de destination de la balise canonical, car sinon, Google risque de traiter bizarrement ce cas. Mais le plus important, c'est de s'assurer que les liens dans les balises HREFLANG sont bien symétriques entre les différentes versions. 

Et la balise canonical n'est à placer que si la "traduction" de la page existe. Si elle n'existe pas, cela génère une erreur, et comme d'habitude, s'il y'a trop d'erreurs, Google risque de mal interpréter les hreflangs.

Dans tous les cas, renvoyer autre chose que 503 dans un contexte d'indisponibilité est une mauvaise idée.

Pour les autres urls : un renvoi massif de 503 diminue le rythme de crawl et de recrawl de Google, c'est ce que j'observe parfois. Mais pendant ce temps les autres urls restent indexées donc les effets de bord sont minimes (ne pas renvoyer 503 par contre, cela va engendrer beaucoup plus de problèmes)

Attention, deux jours c'est déjà limite, il faut que tu réduises ton temps d'indispo au maximum. Au bout d'un certain temps (quelques jours, le délai précis est inconnu) Google va considérer que ta 503 doit être interprétée comme une 404.

Tu trouveras les conseils de Google ici :

https://googlewebmastercentral.blogspot.fr/2011/01/how-to-deal-with-planned-site-downtime.html

Pour t'assurer que les bots interprètent bien ta 503, et pour éviter les effets de bord, il faut que tu penses bien à ajouter le champ header http:// retry after.

Non ce n'est pas en coûteux en ressources.

L'info sur la date de dernière modification est renvoyée au navigateur (ou au bot) dans le header http://

Avec des pages dynamiques générées avec un langage orienté serveur, on met à jour le champ Last Modified avec un bout de script.

Ex de champs header pour gérer les champs de mise en cache en php :

$fp = fopen($_SERVER["SCRIPT_FILENAME"], "r"); 
$etag = md5(serialize(fstat($fp))); 
fclose($fp); 
header("Cache-Control: must-revalidate");
header("Last-Modified: ".gmdate("D, d M Y H:i:s", $SelectS['timestamp'])." GMT"); 
header('Etag: '.$etag);
header("Expires: -1");

A chaque fois que le script est appelé, le bon champ last modified est généré. Evidemment, si la page ne change pas vraiment à chaque fois, il faut utiliser un script adapté.

La fonction MD5 sert pour créer un etag unique pour une version de page, ce qui permet de piloter une autre fonction de cache ;-)

En fait, le code 304 n'est renvoyé que si le navigateur envoie une requête http:// dite "conditionnelle" au serveur web. Inutile de se préoccuper des robots vs utilisateurs, cela fonctionne tout seul.

Ce que fait Googlebot, c'est d'envoyer régulièrement des requêtes conditionnelles en appelant le champ "if modified since". Si le serveur répond que la page n'a pas changé, il passe son chemin et réessaie plus tard. Si la page a changé, Googlebot téléchargera la page complète. Supporter les requêtes conditionnelles pour un serveur web diminue beaucoup la charge du serveur causée par les bots, et favorise l'exploration du site.

La requête du bot ressemble à ça :

GET /index.html HTTP/1.0
User-Agent: Mozilla/5.0
From: something.somewhere.net
Accept: text/html,text/plain,application/*
Host: www.example.com
If-Modified-Since: Wed, 19 Oct 2005 10:50:00 GMT

Si la page répond 304, alors le bot sait que la page n'a pas été modifiée. Et s'il répond 200, elle  a été modifiée, et la nouvelle page est tout bonnement téléchargée.

Nota Bene : un reverse proxy style Varnish est paramétré pour gérer les 304 par défaut.

Il ne s'agit pas d'une mise à jour, mais de plusieurs mises à jour, qui ont été détectées avant l'apparition de Penguin, toujours au moment du lancement de la saison de Noël : entre le 15 novembre et le 20 décembre. Ces mises à jour n'ont jamais été officialisées par Google. Elles étaient caractérisées par un chamboulement des pages de résultat sur des requêtes marchandes, avec un nettoyage massif des thin affiliates, c'est pour cela que l'on a parlé de mises à jour "thin affiliates". A mon avis c'est une dénomination assez abusive, car ces changements d'algorithmes ne ciblaient pas QUE les thin affiliates.

En réalité, Google semble tout bonnement mettre à jour son algorithme pour améliorer ses résultats en vue de la peak season, en une ou plusieurs fois, cela semble un pattern récurrent depuis plusieurs années maintenant (cf les mises à jour de l'année dernière). Ces mises à jour de fin d'année ont toujours un volet "spécial requêtes marchandes" comme la phantom update du 17 novembre dernier. Dans la pratique ces mises à jour ont des caractéristiques différentes année après année.

Il y'a aussi apparemment un filtre algorithmique qui semble attaquer spécifiquement les sites de type "thin affiliates" (déjà vu à l'oeuvre plusieurs fois).

Les "thin affiliates" sont des sites d'affiliation sans valeur ajoutée, dont le modèle consiste à capter du trafic SEO pour le revendre aux affiliants. Reconnaître ces sites faisait l'objet d'une partie des anciens guides du quality rater (pas du dernier, je ne sais pas pourquoi).

Je donne une astuce testée sur pas mal de plateformes pour régler le pb du crawl des facettes.

La façon 100% efficace d'empêcher le crawl d'urls, c'est d'utiliser le fichier robots.txt. Mais au départ on ne peut pas, parce que tantôt la syntaxe correspond à une url que l'on veut voir crawler et indexée, tantôt à une syntaxe que l'on veut bloquer...

La solution c'est d'utiliser deux syntaxes d'urls selon les cas :

- la syntaxe que l'on veut bloquer. En général c'est la syntaxe brute, genre url technique http://www.domaine.com/search.asp?cat=123&sku=458&taille=44

et on bloque tout se ce qui commence par search...

- la syntaxe que l'on veut voir crawler et indexer : et pour cela on réécrit l'url : http://www.domaine.com/r/search.asp?cat=123&sku=458&taille=44mais on peut aussi en profiter pour avoir une url plus "pretty"

A chaque fois que l'on affiche sur le site un lien que l'on veut voir crawler et indexer : on le présente avec la syntaxe réécrite. Pour les autres cas : la syntaxe brute. Et hop le tour est joué.

C'est compatible avec l'astuce de captain_torche (qui est aussi une vraie bonne pratique que je recommande) : pour accéder aux pages filtrées, tu auras deux chemins :

- le formulaire qui te fait atterrir sur la syntaxe brute. Comme cela, si un petit malin copie colle l'url de ta page filtrée par facettes sur un autre site, et Google découvre l'url, Google ne crawlera toujours pas cette syntaxe

- les liens en dur présents dans la navigation (menus, suggestions etc...) qui utilisent la syntaxe réécrite

Et pour info : le message sur le nombre anormalement élevé d'urls est bien lié aux urls crawlables, découvertes sur le site, et n'a rien à voir avec l'indexation.