Budget de crawl

C’est la question à poser en premier, parce que le sujet est souvent invoqué à tort.

Un site de quelques centaines de pages n’a pas de problème de budget de crawl. Google explore l’ensemble sans difficulté, et les pages non indexées le sont pour une autre raison, généralement leur contenu.

Trois profils sont concernés.

Les sites à très grand nombre d’adresses : catalogues e-commerce avec filtres, sites d’annonces, plateformes générant des pages par combinaison de critères.

Les sites lents, où chaque page coûte cher en temps de réponse et réduit mécaniquement le nombre de pages explorées.

Les sites qui produisent des adresses en quantité sans le savoir, cas fréquent où le nombre réel dépasse de plusieurs ordres de grandeur ce que le propriétaire croit avoir mis en ligne.

Trois signaux, du plus accessible au plus précis.

Le libellé « Découverte, actuellement non indexée » dans la Search Console. Google connaît l’adresse et n’a pas pris le temps de la lire. Quand ce statut concerne un nombre important de pages utiles, c’est le symptôme le plus net.

Les statistiques d’exploration de la Search Console. Elles donnent le nombre de pages explorées par jour, le temps de réponse moyen et la répartition par type de fichier. Un temps de réponse élevé et une exploration dominée par des ressources plutôt que par des pages sont deux alertes. La façon dont un crawler choisit sa route explique ces deux chiffres.

Les journaux du serveur. C’est la seule source complète : elle dit exactement quelles adresses Google a visitées, à quelle fréquence, et avec quel code de réponse. L’analyse révèle presque toujours qu’une part importante de l’exploration part sur des adresses sans valeur.

Cinq postes reviennent, dans cet ordre de fréquence.

Les paramètres d’URL. Filtres, tris, pagination et identifiants de session multiplient les adresses pour un même contenu. Sur un catalogue, quelques centaines de produits produisent facilement des dizaines de milliers d’adresses explorables.

Les redirections en chaîne. Chaque maillon consomme une exploration. Un site qui a connu plusieurs refontes en accumule sans que personne ne les remarque.

Les pages en erreur. Google continue de revisiter longtemps des adresses qui ont disparu.

Les contenus quasi identiques. Pages de tag, archives par date, versions imprimables, résultats de recherche interne indexables.

Les ressources lourdes. Images non optimisées et fichiers de script volumineux consomment une part du budget qui n’est pas consacrée aux pages.

Dans l’ordre d’efficacité.

Bloquer dans le fichier robots.txt ce qui ne doit jamais être exploré. C’est le seul levier qui empêche réellement l’exploration. Il vise les recherches internes, les combinaisons de filtres et les espaces sans intérêt public. La balise canonique ne joue pas ce rôle : elle regroupe les signaux mais laisse Google visiter.

Aplatir les redirections. Faire pointer chaque ancienne adresse directement vers sa destination finale.

Réduire les temps de réponse. Un serveur deux fois plus rapide permet à Google d’explorer davantage de pages dans le même effort.

Supprimer ou fusionner les pages sans valeur. Un site plus petit et plus dense est mieux exploré qu’un site étendu et creux.

Resserrer le maillage interne. Les pages importantes doivent être atteignables en peu de clics depuis la page d’accueil. Une page enfouie à six niveaux est visitée rarement, quelle que soit sa qualité.

Bloquer massivement dans le fichier robots.txt des adresses déjà indexées ne les fait pas disparaître des résultats. Google cesse de les explorer, mais il les conserve, sans pouvoir constater qu’elles devraient être retirées.

L’ordre correct est inverse : laisser l’exploration ouverte, poser une balise noindex, attendre que la désindexation soit effective, puis seulement bloquer l’exploration.

C’est un chantier d’audit technique, et il commence toujours par mesurer combien d’adresses le site propose réellement, avant de décider lesquelles méritent d’être explorées.