Sommaire
Dans le dernier épisode du podcast Search Off the Record, Gary Illyes a levé le voile sur une stratégie qui semble paradoxale : Google veut réduire son crawling pour l’optimiser. Une déclaration qui a fait bondir la communauté SEO lorsqu’elle a fuité sur LinkedIn via Barry Schwartz.
La fausse équation : plus de crawling = meilleur référencement
L’un des mythes les plus tenaces du SEO vient d’être démoli par l’équipe de Google Search. Non, un crawling intensif n’indique pas forcément la qualité d’un site. Gary Illyes l’explique sans détour : « Si nous crawlons beaucoup votre site, cela peut signifier qu’il est de haute qualité… ou qu’il a été piraté et génère plein de nouvelles URLs. »
Cette confusion pousse de nombreux propriétaires de sites à demander explicitement plus de crawling via les formulaires Google – une démarche vouée à l’échec. Comme l’explique Gary, Google ne peut qu’imposer des limitations sur le budget de crawl, jamais augmenter artificiellement la fréquence.
L’If-Modified-Since : la clé méconnue de l’optimisation
L’en-tête HTTP If-Modified-Since représente l’une des optimisations les plus négligées du web moderne. Quand Google envoie cette requête, le serveur peut répondre par un simple code 304 « Not Modified » au lieu de renvoyer l’intégralité de la page.
Le gain paraît dérisoire mais s’avère colossal à l’échelle : quelques centaines d’octets au lieu de dizaines de milliers. Gary Illyes martèle l’enjeu : « Nous envoyons 1000 octets au lieu de 100 000 octets. »
Sauf que voilà : la plupart des serveurs ignorent cette requête et renvoient systématiquement un code 200 avec le contenu complet. Un gâchis de bande passante qui exaspère visiblement l’équipe crawling de Google.
Le cauchemar mathématique des paramètres URL
Les paramètres URL représentent la bête noire du crawling efficace. Gary Illyes expose crûment le problème : « Techniquement, vous pouvez ajouter un nombre quasi-infini de paramètres à n’importe quelle URL. »
Concrètement ? Google doit d’abord crawler pour déterminer si ?utm_source=facebook&utm_medium=social&session_id=xyz123 modifie réellement le contenu par rapport à l’URL de base. Une perte de temps considérable qui pourrait être évitée.
La solution existe pourtant : utiliser intelligemment le fichier robots.txt pour bloquer les espaces d’URLs parasites. Gary suggère même que cette approche pourrait résoudre la plupart des plaintes de sur-crawling. Reste à savoir combien de webmasters exploitent réellement cette possibilité.
Le Saint Graal : le transfert par chunks différentiels
L’innovation la plus ambitieuse évoquée dans l’épisode frise la science-fiction : le transfert de contenu par segments modifiés. Plutôt que de renvoyer une page entière, le serveur pourrait indiquer précisément : « Seuls les octets 500 à 700 ont changé, voici le nouveau contenu. »
Gary Illyes surveille une proposition soumise à l’IETF pour standardiser cette approche. Lizzi Sassman pousse la réflexion plus loin : « Sur une page produit, le prix change tout le temps, mais la description de cette paire de chaussures reste identique. »
John Mueller tempère l’enthousiasme : « Implémenter ça ressemble à un cauchemar. » Mais Gary assume : « C’est le genre de défi fou qu’on aime bien. »
Les Stats de crawling : le diagnostic oublié
John Mueller pointe une négligence qui le fait sortir de ses gonds : les webmasters qui ignorent les statistiques de crawling dans Search Console. Notamment le temps de réponse moyen qui révèle des problèmes concrets.
« Votre serveur met trois secondes à répondre en moyenne au lieu de 100 millisecondes ? C’est un problème technique objectif que vous pouvez porter à votre équipe serveur », explique-t-il. Contrairement aux problèmes de pertinence où les facteurs de ranking restent flous, ici les chiffres parlent d’eux-mêmes.
Hébergeurs : les grands absents du diagnostic
Gary Illyes ne mâche pas ses mots concernant les hébergeurs qui rejettent systématiquement la responsabilité sur Google : « Nous voyons que nous ne pouvons pas nous connecter à votre serveur. Pourquoi ne voudrions-nous pas nous y connecter ? »
Cette défaillance du support technique force Google à des diagnostics complexes. Les DNS qui bloquent, les serveurs qui refusent les connexions, les réseaux qui filtrent Googlebot… autant de problèmes techniques que les hébergeurs préfèrent imputer à Google plutôt que d’investiguer.
« Si vous savez comment fonctionne une connexion entre un client et un serveur, dire que le problème vient du client quand il ne peut pas se connecter au serveur, c’est tiré par les cheveux », tranche Gary.
L’éducation avant la technique
John Mueller reste pragmatique : l’éducation surpasse souvent les innovations techniques. Il observe que « la sensibilisation au fonctionnement du crawling s’est considérablement améliorée » grâce notamment aux CMS populaires comme WordPress.
L’objectif ? Que les développeurs anticipent l’impact de leurs choix avant de déployer des paramètres de tracking qui transforment 1000 URLs en 100 millions de variations inutiles. Car comme le souligne Gary, même avec des ressources importantes, « nous pourrions passer ce temps sur des URLs qui aideront vraiment votre site. »
Cette philosophie rejoint d’ailleurs les constats sur la volatilité des outils de mesure : mieux vaut comprendre les mécaniques que multiplier les métriques.
Source : Podcast Search Off the Record – Episode 79 avec John Mueller, Lizzi Sassman et Gary Illyes.
