Vous ouvrez le rapport de couverture, et là, le chiffre tombe : 2 340 URL en erreur. Vous fermez l'onglet. Vous vous dites que vous verrez ça demain. J'ai fait exactement ça pendant des mois sur un site de 40 000 pages — jusqu'au jour où j'ai compris que la moitié de ces « erreurs » étaient des fantômes et que l'autre moitié coûtait vraiment des positions.
Car le rapport de couverture de la Search Console a un problème de fond : il mélange allègrement ce qui empêche Google de crawler, ce qui l'empêche d'indexer, et ce qui vous concerne à peine. Confondre les trois, c'est perdre des semaines à corriger des URL qui n'ont jamais eu d'importance. Cet article est ma méthode pour trier tout ça, prioriser, et vérifier que la correction a vraiment pris.
Points clés à retenir
- Une « erreur de crawl » et une « erreur de couverture » ne désignent pas la même chose : la première bloque l'exploration, la seconde bloque l'indexation.
- Toutes les erreurs ne se valent pas. Un 5xx sur une page qui génère du trafic passe avant vingt soft 404 sur des pages de filtres.
- Le statut « Exploré, actuellement non indexé » n'est pas une erreur : dans la majorité des cas, c'est un choix de Google qu'il faut comprendre avant de contester.
- Corriger, c'est bien. Demander la réindexation et suivre la décroissance du compteur, c'est ce qui prouve que ça a marché.
- Le rapport de couverture se lit par cause racine, jamais URL par URL quand on passe les 500 lignes.
Erreur de crawl ou erreur de couverture : la distinction qui change tout
Avant de toucher à quoi que ce soit, il faut poser cette différence, parce que beaucoup de confusions viennent de là. Le rapport de couverture vous dit ce que Google a réussi à faire d'une URL : la découvrir, l'explorer, la stocker, l'indexer. Une erreur de crawl, c'est le tout premier maillon qui casse — Googlebot n'a pas pu récupérer la page du tout.
Une erreur de couverture est plus large : la page a peut-être été explorée sans problème, mais elle n'est pas indexée pour une raison quelconque (balise noindex, doublon, contenu jugé trop pauvre).
Pourquoi la nuance a un impact concret
Sur un site où j'intervenais, le rapport affichait fièrement 1 800 URL « non indexées ». Le client voulait les faire toutes indexer. J'ai regardé : 1 200 d'entre elles étaient des pages de recherche interne générées à la volée, sans aucune valeur. Les indexer aurait été une faute. Le bon geste était de les bloquer proprement, pas de les forcer.
Le réflexe « tout doit être indexé » est le piège numéro un de ce rapport. Google vous signale un état. À vous de décider si cet état est un problème.
- Erreur de crawl : Googlebot n'a pas pu accéder à la ressource (serveur en vrac, blocage, timeout).
- Erreur d'indexation : la page a été lue mais exclue de l'index (noindex, canonical vers une autre URL, doublon).
- Exclusion volontaire : un choix d'architecture que vous avez posé (robots.txt, paramètres d'URL).
- Faux positif : une URL qui n'existe plus ou qui n'a jamais compté.
Comment prioriser les statuts d'erreur du rapport de couverture
Voici la matrice que j'utilise, et je vais être franc : elle m'a fait gagner un temps fou. Toutes les erreurs ne méritent pas votre lundi matin. Certaines méritent votre lundi matin tout de suite, d'autres peuvent attendre trois mois sans conséquence.
| Statut | Impact SEO réel | Urgence | Délai de reprise en compte |
|---|---|---|---|
| 5xx (erreur serveur) | Élevé — Googlebot abandonne, peut désindexer à terme | Immédiat | Quelques jours après correction |
| 404 et 410 sur pages à trafic | Élevé — perte de lien et de signal | 48 h | 1 à 2 semaines |
| Soft 404 | Moyen — contenu vide ou renvoyant 200 sans substance | Sous 2 semaines | 2 à 4 semaines |
| 401 / 403 | Variable — souvent voulu, parfois accidentel | À auditer | Variable |
| Bloqué par robots.txt | Faible si volontaire, élevé si accidentel | Audit | Immédiat après déblocage |
| Redirection en chaîne | Moyen — dilue le signal | Sous 1 mois | 2 à 3 semaines |
Ce qui passe en premier, sans négociation
Les 5xx. Toujours. Un serveur qui renvoie 503 par intermittence, c'est Googlebot qui repart bredouille et qui, à force, raréfie ses visites. Sur un site e-commerce, j'ai vu un pic de 5xx passer inaperçu pendant dix jours parce que le rapport de couverture les regroupait sous un compteur discret. Résultat : environ 40 % du catalogue sorti de l'index en trois semaines. Le correctif serveur a pris deux heures. La réindexation complète, elle, a mis presque deux mois.
Ensuite, les 404 sur des pages qui généraient du trafic organique. Là, pas de mystère : soit vous redirigez vers l'équivalent le plus proche en 301, soit vous remettez la page en ligne si sa suppression était une erreur.
Ce qui peut attendre sans que ça coûte
Les soft 404 sur des pages de filtres, de pagination profonde, de paramètres de tri. Le rapport vous les liste, c'est agaçant, mais ça n'a quasiment aucun effet sur votre visibilité. J'ai longtemps cru l'inverse, et j'ai gaspillé des journées entières là-dessus avant de comprendre.
Diagnostiquer par cause racine, pas URL par URL
Un rapport à 5 000 lignes ne se traite pas ligne par ligne. Ça, c'est ce que j'ai essayé de faire au début — je vous déconseille. On ouvre l'export, on trie, on corrige, on ressort, et trois jours plus tard le compteur affiche exactement le même chiffre parce que la cause racine n'a jamais été traitée.
La bonne approche : cliquer sur un statut dans le rapport, puis regarder les exemples d'URL que Google vous montre. Ils ne sont pas là par hasard. Ils pointent presque toujours vers un motif répétable.
Les motifs qui reviennent presque à chaque fois
- Un paramètre d'URL oublié dans le robots.txt qui génère des milliers de variantes.
- Un lien interne cassé dans un menu ou un footer, propagé sur tout le site.
- Une redirection mal configurée qui pointe vers une autre redirection (la fameuse chaîne).
- Une balise noindex laissée active après une phase de test en préproduction.
Ce dernier cas, je l'ai vécu. Un développeur avait poussé un noindex global en recette et l'avait laissé en production sur une section entière. Le rapport signalait des « Exclues par une balise noindex » : 312 URL. On les a débloquées en une ligne de configuration, et Google a remis les pages en index en une dizaine de jours. Le plus dur n'était pas le correctif, c'était de mettre la main sur la cause.
Cherchez le motif. Une fois que vous l'avez, la correction se fait au niveau du template, du serveur ou de la configuration — pas page par page.
La méthode de vérification post-correction (et l'erreur que je faisais)
Corriger ne suffit pas. Il faut vérifier. Et c'est là que j'ai commis ma plus grosse erreur méthodologique : je corrigeais, je regardais le lendemain, je voyais le chiffre inchangé, et je concluais que ça n'avait pas marché. Faux. La réindexation prend du temps. Parfois beaucoup.
La méthode qui fonctionne, étape par étape :
- Corriger la cause racine, puis vérifier en direct sur une URL témoin avec l'inspection d'URL de la Search Console. La balise noindex a disparu ? Le code HTTP renvoie bien 200 ?
- Demander explicitement la réindexation sur les URL les plus stratégiques, jamais sur tout le catalogue.
- Suivre la décroissance du compteur dans le temps, pas sur 24 h. Comptez 1 à 3 semaines pour des corrections simples, davantage pour un volume important.
- Croiser avec le rapport d'indexation des pages si vous avez accès à des outils complémentaires, pour voir si les pages remontent réellement en index.
Sur le projet à 40 000 pages dont je parle plus haut, la première vague de corrections concernait environ 900 URL en 5xx. Au bout de trois semaines, le compteur était descendu à 610 — et j'ai mis plusieurs mois à comprendre pourquoi il stagnait. La cause : un second correctif n'avait jamais été déployé sur un sous-domaine que personne ne monitorait.
Combien de temps faut-il vraiment attendre ?
Comptez large. Une page en 404 corrigée en 301 ne sera recrawlée qu'à la prochaine visite de Googlebot, qui peut arriver dans deux jours comme dans trois semaines selon la fréquence d'exploration du site. Pour un site jeune et peu crawl-limité, c'est rapide. Pour un site à forte profondeur, c'est l'inverse.
Ne récorrigez pas une page tous les trois jours en la forçant à s'indexer. Ça ne fera rien de bon. La demande de réindexation est un signal, pas un bouton magique.
Structurer le crawl pour éviter la rechute
Une erreur corrigée qui revient, c'est le scénario le plus courant. Pourquoi ? Parce que le site continue de générer les mêmes URL problématiques. Il faut donc une stratégie de fond, pas seulement des correctifs.
Les leviers concrets :
- Sitemap XML propre, qui ne liste que les URL en 200 et bien indexables.
- robots.txt relu à chaque déploiement, pas seulement à la mise en production initiale.
- Surveillance des paramètres d'URL pour éviter la génération infinie de variantes.
- Revue régulière du rapport de couverture, une fois par mois, avec un filtre sur les statuts critiques.
Un point que personne ne dit assez : le rapport de couverture n'est pas qu'un outil de réparation. C'est un outil de surveillance. Quand le compteur monte soudainement, c'est presque toujours le signe qu'un déploiement a cassé quelque chose. J'ai mis du temps à établir cette habitude, et elle m'a évité au moins deux incidents majeurs depuis.
La vraie question n'est pas « comment corriger ces erreurs de crawl », mais plutôt « comment ne plus les voir apparaître ». Les corrections manuelles traitent les symptômes. Un crawl structuré, vérifié à chaque déploiement, traite la cause.
Et si vous ne devez retenir qu'une chose de cet article, c'est peut-être celle-ci : le rapport de couverture raconte une histoire sur votre site. À vous de décider si cette histoire est un problème à régler, ou une architecture à assumer.
