Crawl automatique de Google : qu'est-ce que ça change ?
Jusqu'au 8 janvier 2024, les sites présentant des problèmes de disponibilité pouvaient utiliser un outil de limitation de la vitesse de crawl dans la Search Console. "Dans certains cas, l'exploration de votre site par Google peut entraîner une surcharge critique sur votre infrastructure ou un manque à gagner lors d'une panne. Pour remédier à ce problème, vous pouvez décider de réduire le nombre de requêtes effectuées par Googlebot", expliquait la firme de Mountain View. Cet outil, disponible depuis plus de 10 ans, mettait plus d'une journée pour mettre en place les nouvelles limites. Son effet ne durait que 90 jours. Il était peu utilisé par les éditeurs.
Cet arrêt de l'outil s'appuie sur l'amélioration de la logique de crawl de Google. "Celui-ci comprend mieux la capacité du serveur du site qu'il crawle à pouvoir être plus ou moins répondant et disponible", explique Mathieu Chapon, fondateur de Peak Ace. "Le moteur de recherche est aussi devenu meilleur pour mesurer les pages qu'il doit visiter régulièrement et celles qu'il doit visiter moins souvent. Probablement qu'il y a un peu d'IA derrière qui permet d'apprendre de ses crawls précédents. Egalement, avec les règles de robots.txt, de noindex et de canonical, il doit être beaucoup plus strict. Et puis, sans doute qu'il a amélioré son infra et doit être plus fort pour crawler en parallèle plusieurs pages du site simultanément."
500, 503 et 429
Une autre façon de signaler des problèmes d'indisponibilité du serveur peut être de passer par les codes 500, 503 et 429 pour les éditeurs. Pour rappel, le code HTTP 500 Internal server error indique un problème inopiné rencontré par le serveur, ce qui ne lui a pas permis de répondre à la requête. Le code 503 montre que le serveur n'est pas prêt à traiter la requête. "Ce code est un moyen technique pour Google de comprendre que le serveur est surchargé", rappelle Mathieu Doubey, manager du pôle SEO chez L'Agence WAM. "Il faut continuer de l'utiliser même si Google peut voir que la page web se charge lentement." Le code 429 dévoile quant à lui que trop de requêtes ont été réalisées pendant un certain laps de temps.
"Comme l'outil n'est plus actif, il faut nécessairement permettre à Google de comprendre quand il peut ou ne peut pas charger un serveur", raconte Mathieu Doubey. "Si Google arrive à pallier beaucoup de problème de lui-même, c'est quand même mieux d'optimiser le comportement des sites vis-à-vis de l'attendu. Il faut éviter de laisser le moteur de recherche américain décider pour nous le plus souvent."
Cette manière de faire est actuellement recommandée par Google. "Si vous devez rapidement réduire la vitesse d'exploration pendant une courte période (par exemple, quelques heures ou un ou deux jours), renvoyez une page d'erreur informative avec un code d'état de réponse HTTP 500, 503 ou 429 au lieu d'afficher tout le contenu.", explique le géant américain. En envoyant de nombreux codes d'état de réponse HTTP 500, 503 et 429, Google doit pouvoir réduire la vitesse d'exploration du site. "La modification se reflète à la fois dans l'exploration des URL qui renvoient ces erreurs et dans le site Web dans son ensemble", expose le géant américain. "Une fois le nombre d'erreurs réduit, la vitesse d'exploration recommence à augmenter automatiquement." Google déconseille d'ailleurs d'adopter cette méthode pendant plus de quelques jours. Sous peine de voir l'URL en question être supprimée de son index.
Une recommandation appliquée en partie du côté de l'agence Peak Ace. "Nous recommandons à l'éditeur de passer par la 503 en cas d'urgence", révèle Mathieu Chapon. "Elle est très précise car elle dit, en quelques sortes : "je suis indisponible actuellement, repasse plus tard." C'est la meilleure réponse à fournir quand on a un site qui a des difficultés. Bien entendu, ce n'est pas une réponse qu'il faut essayer de garder très longtemps, car elle n'envoie pas un excellent signal."
Moins de 300 ms pour charger le code source
Pour permettre à Google de crawler davantage de pages, et éviter ces situations d'urgence, il peut aussi être intéressant de travailler sur la vitesse de chargement du site, d'après Mathieu Chapon. En effet, celle-ci constitue un des critères pris en compte par Google pour définir le temps qu'il va passer à explorer un site web, avec le nombre et la profondeur des pages ou encore la fréquence des mises à jour. Plus le temps passé à crawler est important, plus les pages peuvent être visitées, indexées et positionnées. "On regarde beaucoup les indicateurs sur Page Speed Insight, mais on oublie qu'hormis le temps de rendition, c'est important d'avoir une bonne disponibilité serveur", analyse Mathieu Chapon
Différents outils permettent d'améliorer le temps de chargement du site. "Par exemple, Akamai est un serveur proxy qui permet de générer une version allégée de la page. Pour cela, il compresse principalement son poids. La solution française Fasterize est comparable, mais elle offre plus de possibilités, comme la réécriture de la page ou des URLs. "L'objectif, selon Mathieu Chapon, est d'atteindre moins de 300 ms pour le chargement du code source html. "Pour que Google puisse être capable de crawler le plus possible de pages jugées utiles et intéressantes pour le SEO", estime-t-il. D'après son expérience, les résultats peuvent être non négligeables. "Un site sur l'assurance avait des problèmes de disponibilité. Il pouvait tomber une fois par semaine, pendant quelques heures, sur des requêtes très concurrentielles comme "assurance auto" ou "assurance maison". Après avoir réglé le problème de temps de chargement, il a acquis des positions stables et intéressantes dans le temps. Car Google a jugé le site de confiance et légitime à se positionner. Celui-ci répondait toujours correctement à la requête des internautes et affichait sa capacité à pouvoir présenter un contenu."
Toujours pour éviter les surcharges serveur, " il y a également ce qu'on appelle le load balancing", explique Mathieu Doubey. Appelée aussi répartition de charge, cette technologie permet de distribuer la charge de travail entre différents serveurs ou applications. Avec pour objectif d'optimiser la performance globale de l'infrastructure, son rendement et sa capacité.