Erreurs de crawl : les reperer et les corriger efficacement

Vous tapez « erreurs de crawl » dans Google et vous tombez sur des articles qui vous expliquent comment améliorer votre battement de jambes. Avouez que c'est déroutant.

Le crawl, en natation, c'est la nage la plus rapide. Le crawl, en SEO, c'est la façon dont Google parcourt votre site. Deux mondes. Un seul mot. Et une bonne partie des contenus que vous trouverez sur le sujet parlent du mauvais.

Je vais donc trancher tout de suite : cet article traite du crawl des moteurs de recherche, pas de la brasse. Si vous cherchiez des conseils pour votre virage, passez votre chemin. Si vous voulez comprendre pourquoi une page bien écrite ne se fait pas indexer, vous êtes au bon endroit. J'ai vu ce problème des dizaines de fois sur des sites clients, et dans neuf cas sur dix, la cause est bête. Vraiment bête.

Les erreurs de crawl les plus fréquentes (et pourquoi elles arrivent)

La majorité des erreurs de crawl ne viennent pas d'une incompétence technique. Elles viennent d'une accumulation de petites décisions prises sans vue d'ensemble.

Quelqu'un bloque un dossier en staging. Quelqu'un d'autre ajoute un noindex sur une page temporaire. Six mois plus tard, le site est en production et ces deux lignes traînent encore. Personne ne les voit, parce que personne ne les cherche.

Pourquoi ces erreurs passent inaperçues

Google ne vous envoie pas de notification quand il n'arrive pas à crawler une page. Il essaie, il échoue, il passe à autre chose. Silencieusement.

C'est ce qui rend le diagnostic compliqué. Une page peut parfaitement s'afficher pour un visiteur humain, être rapide, bien écrite, et rester invisible dans les résultats. Le contenu est bon. Le signal, non.

Franchement, c'est la partie la plus frustrante du métier. Vous corrigez le fond, vous peaufinez la forme, et le problème était une ligne de texte dans un fichier que personne ne lit jamais.

Le rôle du budget de crawl

Les robots d'exploration ne parcourent pas votre site à l'infini. Ils disposent d'une enveloppe limitée par site, qu'on appelle le budget de crawl. Plus votre site est grand, plus cette enveloppe compte.

Sur un site de 30 pages, ce budget est largement suffisant. Sur un site de 30 000 pages, chaque URL inutile crawlé est du temps perdu pour les autres. Une pagination infinie mal gérée, des paramètres d'URL qui génèrent des milliers de variantes, des pages de recherche internes indexables : autant de gouffres.

J'ai repris un site e-commerce qui expédiait plus de 40 000 URL à Google, dont la grande majorité était des combinaisons de filtres sans intérêt. Une fois ces URL bloquées ou en noindex, les vraies pages produits se sont mises à s'indexer en quelques jours au lieu de plusieurs semaines. Le contenu n'avait pas changé. Le signal, si.

Comment corriger les erreurs de crawl, étape par étape

Il n'existe pas de méthode universelle, mais il existe un ordre logique. Le voici.

Diagnostiquer avant de corriger

Avant de toucher au robots.txt ou à une balise, il faut savoir ce qui se passe. Deux outils suffisent dans la plupart des cas : la Search Console de Google, et un outil d'analyse de logs ou de crawl type Screaming Frog.

La Search Console vous dit quelles pages sont indexées, lesquelles ne le sont pas, et parfois pourquoi. L'outil de crawl vous montre ce que vos propres robots voient. Croisez les deux. Une page absente de la Search Console mais présente dans votre crawl a un problème de signal. Une page absente des deux a peut-être un problème plus profond.

Ne corrigez jamais à l'aveugle. J'ai perdu une semaine entière sur un projet à modifier des balises que je croyais fautives, alors que le vrai coupable était un robots.txt que je n'avais pas ouvert. Leçon retenue.

Vérifier le robots.txt

C'est la première chose à contrôler, et de loin la plus fréquente. Le fichier robots.txt se trouve à la racine de votre domaine. Il indique aux robots ce qu'ils ont le droit d'explorer.

Une ligne mal écrite peut bloquer tout un dossier. Un Disallow: / malencontreux bloque tout le site. Et ça arrive plus souvent qu'on ne le croit, notamment quand un fichier de développement est copié en production sans être relu.

Vérifiez aussi que vous ne bloquez pas le rendu de vos ressources CSS et JavaScript. Si Google ne peut pas charger ces fichiers, il voit une page cassée.

Traquer les noindex oubliés

La balise noindex est plus sournoise que le robots.txt, parce qu'elle se cache dans le code de la page elle-même. Vous pouvez avoir un robots.txt impeccable et une page bloquée par un noindex dans son en-tête.

Ma méthode : un audit rapide de toutes les balises meta robots du site, une fois par trimestre. Un simple crawl avec un filtre sur noindex suffit à repérer les oublis. Sur un site que j'ai repris l'an dernier, trois pages de catégorie principales portaient encore un noindex hérité d'une migration. Elles avaient perdu plus de 60 % de leur trafic sans que personne ne s'en aperçoive.

Nettoyer et mettre à jour le sitemap

Un sitemap n'est pas une obligation, mais c'est un bon indicateur. Le problème, c'est qu'il devient rarement obsolète tout seul. Les pages supprimées y restent. Les redirections s'accumulent. Les URL renvoient vers des erreurs 404 ou 500.

Un sitemap qui contient autant d'URL en erreur que d'URL valides envoie un signal de qualité médiocre. Mettez-le à jour automatiquement si possible. Sinon, prévoyez un contrôle régulier.

Un détail qu'on oublie souvent : un sitemap ne force pas l'indexation. Il suggère. Si la page est bloquée ailleurs, le sitemap n'y changera rien.

Erreurs 404, 500 et chaînes de redirections : le nettoyage

Les erreurs de crawl ne se limitent pas au blocage volontaire. Les erreurs de serveur et les redirections mal gérées en font aussi partie.

Le cas des erreurs 404

Une 404 n'est pas toujours un problème. Une page supprimée qui renvoie une 404 propre, c'est normal et sain. Le problème, c'est la 404 sur une page qui devrait exister, ou la 404 qui découle d'un lien interne cassé.

Pour les pages supprimées définitivement, une redirection 301 vers une page proche reste la meilleure option quand elle a du sens. Pour les pages sans équivalent, assumez la 404. Google finira par la retirer de son index.

Les chaînes de redirections

Une redirection qui pointe vers une autre redirection qui pointe vers une autre redirection. Trois sauts, quatre sauts. Chaque saut consomme du budget de crawl et dilue le signal transmis.

La règle est simple : une seule redirection, de l'ancienne URL vers l'URL finale. Jamais de chaîne. Un audit de redirections permet de repérer ces enchaînements et de les aplatir.

Les erreurs 5xx

Une erreur 500 signale un problème serveur. Google reviendra tester la page, mais si l'erreur persiste, il finira par la retirer de son index. C'est un signal grave, à traiter en priorité. Vérifiez vos logs serveur quand vous constatez des pics de 5xx.

Comparatif : quel outil pour quel problème

Voici un tableau récapitulatif des outils que j'utilise, et à quoi ils servent concrètement.

Outil	Ce qu'il détecte	Limite principale
Search Console	Pages non indexées, couverture, sitemaps	Ne montre pas tout, mise à jour différée
Screaming Frog	Balises meta robots, redirections, erreurs 4xx/5xx	Ne voit que ce que vos robots voient
Analyse de logs serveur	Comportement réel des robots de Google	Demande une certaine maîtrise technique
Outil de test robots.txt	Validité du fichier robots.txt	Ne teste qu'une URL à la fois

Aucun de ces outils ne fait le travail à votre place. Ils montrent des symptômes. La cause, c'est vous qui la trouvez.

Questions fréquentes

Combien de temps faut-il pour qu'une page s'indexe après correction ?

Ça dépend de la taille du site et de son historique. Sur un petit site, une page corrigée peut être réindexée en quelques jours. Sur un site de plusieurs milliers de pages, comptez plusieurs semaines. Vous pouvez accélérer les choses en soumettant l'URL à l'indexation manuellement depuis la Search Console.

Faut-il bloquer les pages de recherche internes ?

Dans la majorité des cas, oui. Les pages de résultats de recherche interne génèrent des milliers d'URL différentes, sans valeur éditoriale, et consomment du budget de crawl. Le plus propre est de les passer en noindex, plutôt que de les bloquer dans le robots.txt.

Mieux vaut-il utiliser noindex ou robots.txt pour retirer une page ?

Pour retirer une page de l'index, utilisez noindex. Le robots.txt empêche le crawl, mais pas l'indexation d'une page déjà connue. Si un robot ne peut pas explorer une page, il ne verra pas le noindex qu'elle contient. Utilisez donc le robots.txt pour économiser du budget de crawl, et le noindex pour retirer une page de l'index.

Une erreur de crawl peut-elle être sans impact sur le référencement ?

Oui, et c'est important de le savoir. Une erreur 404 sur une page sans valeur ni lien entrant n'a pratiquement aucun effet. Toutes les erreurs ne méritent pas votre attention. Concentrez-vous sur celles qui touchent des pages stratégiques.

Ce qu'il faut retenir, et ce que ça change pour vous

Les erreurs de crawl sont rarement spectaculaires. Elles sont discrètes, silencieuses, et souvent anciennes.

La bonne nouvelle : la plupart se corrigent en quelques minutes, une fois identifiées. Le robots.txt, la balise noindex, le sitemap, les redirections. Quatre points de contrôle qui règlent la majorité des cas.

Reste une question que je me pose souvent, et sur laquelle je n'ai pas de réponse définitive : combien de bonnes pages dorment sur des sites bloqués par une ligne oubliée ? Probablement beaucoup. C'est ce qui rend ce travail ingrat, mais nécessaire.

La prochaine fois qu'une page refuse de s'indexer, ne réécrivez pas son contenu. Ouvrez d'abord le robots.txt. Vous gagnerez du temps.