Identifier et bloquer les requêtes Googlebot gourmandes en ressources

Bloquer les requêtes Googlebot gourmandes en ressources implique d’identifier des URL spécifiques ou des modèles de fichiers qui consomment une quantité excessive de CPU et de mémoire serveur, puis d’utiliser des directives robots.txt ou des codes d’état HTTP pour gérer l’accès. Ce processus garantit que votre serveur reste stable tout en permettant au robot d’exploration de trouver votre contenu le plus précieux. En surveillant les logs du serveur et la Search Console, vous pouvez identifier précisément les scripts ou les fichiers volumineux qui ralentissent le processus de crawl et affectent la vitesse de votre site.

Qu’est-ce qui caractérise une requête gourmande en ressources ?

Une requête gourmande en ressources se produit lorsqu’un robot d’exploration visite une page qui nécessite un effort serveur important pour être traitée. Cela arrive souvent avec des URL dynamiques qui génèrent du contenu à la volée. Par exemple, une page de résultats de recherche sur un site e-commerce pourrait déclencher des requêtes de base de données complexes à chaque visite de Googlebot. Ces requêtes consomment plus de RAM et de CPU qu’un simple fichier HTML statique.

Les fichiers multimédias volumineux et les scripts non optimisés entrent également dans cette catégorie. Si Googlebot tente de récupérer des centaines d’images haute résolution ou de gros documents PDF dans un court laps de temps, la charge du serveur augmente. Ce comportement peut ralentir le site pour les utilisateurs humains réels. L’identification de ces modèles est la première étape vers une gestion efficace du crawl.

Comment les logs serveur peuvent-ils identifier l’intensité du crawl ?

Les logs serveur fournissent un enregistrement brut de chaque interaction entre Googlebot et votre site web. Chaque entrée contient l’adresse IP, l’horodatage et l’URL spécifique demandée. En filtrant ces logs pour l’agent utilisateur Googlebot, vous pouvez voir quelles sections de votre site sont explorées le plus fréquemment. Les accès à haute fréquence sur le même répertoire indiquent souvent une boucle de crawl ou une structure de site inefficace.

Votre serveur web conserve un enregistrement de chaque requête faite à votre site, y compris celles provenant de Googlebot.

Google Search Central

L’analyse du temps de réponse pour ces requêtes vous aide à trouver les goulots d’étranglement. Si certaines URL prennent systématiquement plus de 2 secondes pour répondre au robot, elles sont gourmandes en ressources. Vous pouvez utiliser des outils comme awk ou grep sur les serveurs Linux pour extraire ces données. Recherchez les codes d’état comme 200 qui ont des valeurs de ‘temps pris’ élevées dans votre format de log.

Champs courants à surveiller dans les logs serveur

• Adresse IP du client : Vérifie si la requête provient réellement d’une plage IP Google.
• URL de la requête : Identifie le chemin spécifique, y compris les paramètres de requête comme ?sort=price.
• Code d’état HTTP : Indique si la requête a réussi (200) ou a causé une erreur (500).
• Temps pris : Mesure les millisecondes que le serveur a passées à traiter la requête.
• Agent utilisateur : Confirme s’il s’agit de la version mobile ou de bureau de Googlebot.

Utilisation de robots.txt pour gérer l’accès du robot

Le fichier robots.txt est votre outil principal pour communiquer avec les robots des moteurs de recherche. Vous pouvez utiliser la directive ‘Disallow’ pour empêcher Googlebot d’accéder aux répertoires gourmands en ressources. Par exemple, si vos pages de recherche interne ralentissent le serveur, vous pouvez bloquer complètement le chemin /search/. Cela empêche le robot d’initier ces appels coûteux à la base de données.

Une configuration appropriée garantit que le robot consacre son temps aux pages qui favorisent la visibilité dans les recherches.

Google Search Central

Il est important d’être spécifique avec vos directives. Bloquer des fichiers CSS ou JavaScript essentiels peut empêcher Googlebot de rendre vos pages correctement. Cela pourrait entraîner des problèmes d’indexation où votre site apparaît cassé dans les résultats de recherche. Testez toujours vos modifications robots.txt dans le testeur robots.txt de la Google Search Console avant de les pousser en production.

Pourquoi Googlebot surcharge-t-il parfois un serveur ?

Googlebot tente d’explorer votre site aussi vite que votre serveur le permet sans causer de problèmes. Cependant, si la configuration de votre serveur est faible ou si votre site contient des ‘espaces infinis’, le robot pourrait involontairement provoquer un pic de charge. Les espaces infinis sont souvent causés par des widgets de calendrier ou des systèmes de filtrage complexes qui créent un nombre infini d’URL uniques. Chacune de ces URL uniques ressemble à une nouvelle page pour le robot.

De plus, une augmentation soudaine de nouveau contenu peut déclencher une poussée de l’activité de crawl. Si vous migrez un site ou téléchargez des milliers de nouveaux produits, Googlebot travaillera plus dur pour découvrir et indexer ces éléments. Si le serveur n’est pas prêt pour ce volume, il peut avoir du mal à servir les requêtes à la fois pour le bot et pour vos clients. La surveillance du rapport sur les statistiques de crawl dans la Search Console vous aide à voir ces tendances tôt.

Comment Alien Road applique la gestion du crawl

Chez Alien Road, nous suivons un processus systématique pour protéger les ressources serveur de nos clients tout en maintenant une forte visibilité dans les recherches. Nous commençons par un audit approfondi des logs serveur pour identifier les 5 % d’URL qui consomment le plus de temps de traitement. Dans un compte typique, nous constatons souvent que les filtres dynamiques ou les ID de session sont les principaux coupables. Nous mettons ensuite en œuvre des règles spécifiques pour gérer ces cas.

Par exemple, pour une boutique Shopify avec des balises de produit complexes, nous pourrions trouver Googlebot explorant des milliers de combinaisons de filtres. Nous exploitons l’outil Paramètres d’URL et le fichier robots.txt pour limiter ce comportement. Notre équipe met en place des alertes automatisées qui nous avertissent si le temps de réponse moyen pour Googlebot dépasse un seuil spécifique. Cela nous permet de réagir avant qu’un ralentissement du serveur n’affecte l’expérience utilisateur.

Notre processus d’audit étape par étape

• Collecte des logs : Nous rassemblons 30 jours de logs serveur bruts pour voir les modèles de crawl à long terme.
• Vérification du bot : Nous effectuons des recherches DNS inversées pour nous assurer que le trafic est bien Googlebot légitime et non un scraper.
• Identification des chemins : Nous regroupons les URL par répertoire pour trouver quelles sections du site sont les plus gourmandes en ressources.
• Mise en œuvre des directives : Nous mettons à jour le fichier robots.txt pour interdire les chemins lourds non essentiels.
• Surveillance des performances : Nous suivons les ‘Statistiques de crawl’ dans la GSC pour confirmer que la charge a diminué.

Pouvez-vous utiliser des codes d’état pour ralentir Googlebot ?

Si votre serveur est sous stress immédiat, vous pouvez utiliser des codes d’état HTTP pour signaler à Googlebot de ralentir. Le code d’état 429 (Trop de requêtes) est spécifiquement conçu à cet effet. Lorsque Googlebot reçoit un code 429, il comprend qu’il doit réduire son taux de crawl pendant une période. Il s’agit d’une solution temporaire pour éviter un crash total du serveur lors d’un trafic élevé.

Une autre option est le code d’état 503 (Service indisponible). Cela indique au robot que le serveur est temporairement incapable de traiter la requête. De plus, vous pouvez utiliser l’en-tête ‘Retry-After’ avec un code 503 pour suggérer quand le robot devrait revenir. Bien qu’efficaces, ils doivent être utilisés avec parcimonie, car des erreurs 503 ou 429 persistantes peuvent éventuellement entraîner la suppression des pages de l’index.

Plan d’action pour les jours à venir

Commencez par accéder à votre Google Search Console et naviguez vers le rapport ‘Statistiques d’exploration’ sous le menu Paramètres. Vérifiez le graphique ‘Temps de réponse moyen’ pour tout pic important. Si vous voyez des pics, demandez vos journaux de serveur bruts à votre hébergeur ou à votre équipe informatique. Recherchez les URL qui ont été demandées pendant ces périodes de pointe pour identifier les ressources lourdes.

Une fois que vous avez identifié les chemins problématiques, mettez à jour votre fichier robots.txt pour les bloquer. Si les ressources sont nécessaires au rendu de la page, comme de gros fichiers JavaScript, envisagez d’optimiser le code ou d’utiliser un Content Delivery Network (CDN) pour décharger la pression sur le serveur. Continuez à surveiller les Statistiques d’exploration quotidiennement pour vous assurer que vos modifications ont l’effet souhaité sur les performances du serveur.