La première fois que j'ai ouvert un export de crawl, j'ai fait défiler des milliers de lignes et j'ai refermé le fichier. Tout semblait urgent. Les codes d'erreur s'empilaient, les titres se répétaient, et je ne savais pas quelle colonne regarder. Depuis, je lis ces tableaux dans un ordre fixe. Un rapport de crawl SEO est un inventaire : il photographie le site tel qu'un robot le parcourt, à un instant donné. Il montre quelles URLs ont été trouvées, comment le serveur a répondu, et comment les pages se relient.
Les points à retenir
- Le crawl liste les URLs atteintes par les liens, avec leur code HTTP, leur profondeur et quelques balises.
- Je commence par les 404, les 500 et les chaînes de redirections, avant de toucher aux textes.
- La profondeur et le nombre de liens internes montrent quelles pages sont faciles à atteindre.
- Titres, H1 et canoniques se lisent par tri, pour faire remonter les familles d'URLs identiques.
- Je sors du tableau avec une liste courte d'actions, groupées par cause.
- Je relance le même périmètre après les corrections, pour voir ce qui a vraiment bougé.
Ce que le fichier contient vraiment
Une photo prise en suivant les liens
Le robot part d'une ou plusieurs URLs, souvent l'accueil. Il suit les liens présents dans le HTML, puis ceux des pages suivantes, jusqu'à la limite que vous avez fixée. Chaque ligne décrit en général une URL : code de réponse, titre, méta description, H1, balise canonique, liens internes reçus, profondeur.
Ce mode de collecte a une suite concrète. Une page sans lien interne n'apparaît pas, sauf si vous l'avez mise dans la liste de départ ou dans un sitemap que l'outil ingère. J'ai déjà pris une fiche pour « absente de problèmes » alors qu'elle manquait du fichier. Elle était orpheline. Le robot ne l'avait jamais croisée.
Les trous à connaître avant de conclure
Le fichier ignore les requêtes tapées chez Google et le rôle commercial de chaque URL. Selon le mode de rendu, il peut aussi rater un texte affiché seulement après exécution du JavaScript. Quand une page sort vide dans l'export et pleine dans le navigateur, je vérifie le rendu avant de réécrire quoi que ce soit.
Le crawl date de l'heure du run. Une coupure pendant une mise en ligne reste imprimée dans le tableau. Je note cette heure. Si le site était en travaux, je relance une fois la production calme, et je lis le second fichier.
Les colonnes que je trie en premier
Codes HTTP et redirections
Je filtre tout ce qui ne répond pas en 200.
- 404 : la page est introuvable. S'il reste des liens internes vers elle, je corrige ces liens. S'il existe une page réellement proche, une redirection unique peut prendre le relais.
- 410 : le retrait est assumé. Je m'en sers quand rien ne doit remplacer l'URL.
- 500 et 503 : le serveur a échoué ou s'est dit indisponible. Une rubrique entière dans ce cas m'envoie vers l'hébergement. Quelques URLs isolées se traitent une par une.
- 301 et 302 : l'URL envoie ailleurs. Une redirection seule est souvent normale. Une chaîne (A vers B, puis B vers C) allonge le chemin. Je vise un seul saut vers la destination finale.
Les 200 constituent le tas principal. Je les ouvre ensuite, par d'autres tris.
Canonique, indexabilité, temps de réponse
Sur les pages en 200, la balise canonique mérite un filtre tout de suite. Pour une page que vous voulez voir indexer, elle pointe en principe vers elle-même, ou elle est absente si c'est votre règle. Quand elle pointe ailleurs, la page désigne une autre URL comme originale. C'est parfois voulu, pour une variante ou un filtre. C'est parfois un modèle copié trop vite : j'ai vu une boutique dont les fiches canonisaient vers l'accueil. Le filtre « canonique différente de l'URL » a regroupé la famille d'un coup.
La colonne d'indexabilité, quand l'outil la calcule, résume noindex, canonique externe et certains blocages. Je la prends comme un drapeau, puis j'ouvre deux URLs pour confirmer. Un head qui mélange une balise statique et une balise injectée plus bas peut fausser le drapeau.
Le temps de réponse vient après. S'il est haut sur un seul modèle (toutes les catégories, aucune fiche), le sujet est ce modèle. Une moyenne sur tout le site masque ce contraste.
Profondeur et liens internes
Compter les clics depuis le départ
La profondeur compte les clics depuis l'URL de départ. L'accueil est souvent à 0. Une rubrique du menu passe à 1. Une fiche atteinte après une longue suite de clics affiche 4, 5 ou davantage.
Je trie de la profondeur la plus grande vers la plus petite, puis je regarde le type de page. Une mention légale loin dans l'arborescence peut rester là. Un guide ou une fiche qui porte une vraie demande, enfoui au même niveau, gagne à recevoir un lien depuis une rubrique, un article proche ou un bloc en bas de contenu.
Le nombre de liens internes entrants se lit avec la profondeur. Une page proche de l'accueil, tenue par un seul lien, disparaît du parcours si ce lien saute. Une page plus profonde, citée par de nombreux articles, reste trouvable. Les deux chiffres ensemble valent mieux que l'un des deux.
Regrouper par familles d'URL
Un long export se comprend par dossiers : /blog/, /categorie/, /produit/, pagination, paramètres du type ?tri= ou ?page=.
La pagination qui reprend toujours la même canonique, les facettes qui multiplient des URLs presque identiques, la recherche interne qui reste accessible au robot : ces familles apparaissent dès qu'on filtre le chemin. Quelques lignes prises au hasard ne montrent pas la règle. La famille entière, si.
| Signal dans l'export | Lecture prudente | Premier geste |
|---|---|---|
| 404 avec des liens internes | Un menu ou un texte pointe encore vers une page morte | Corriger les liens, ou rediriger vers une page proche |
| Chaîne de redirections (deux sauts ou plus) | Le robot fait un détour avant la page finale | Pointer le premier lien vers l'URL finale |
| Canonique externe sur des fiches uniques | Le modèle désigne une autre page comme originale | Vérifier le template avant de réécrire le texte |
| Profondeur haute sur une page utile | Peu de parcours y mènent depuis l'accueil | Ajouter un lien depuis une rubrique ou un article proche |
| Même title sur de nombreuses URLs | Plusieurs pages se présentent sous le même intitulé | Écarter les titres selon le sujet réel de chaque URL |
| noindex sur une page à montrer | La page demande à rester hors de l'index | Confirmer que ce noindex est voulu |
Titres, H1 et copies
Faire remonter les identiques par le tri
Je trie la colonne title, puis la colonne H1. Les valeurs identiques se retrouvent côte à côte. Deux articles qui partagent un titre entier viennent souvent d'un champ oublié dans le CMS, ou d'une pagination qui recopie la page 1 sans ajouter de repère.
Le H1 vide sur tout un modèle se voit avec le même geste : filtre « H1 vide », puis regard sur le chemin. Si le vide est cantonné à un espace compte, je laisse. S'il couvre le blog, le modèle d'article a un trou.
La méta description en double vient plus tard. Une fois, j'ai réécrit une pile de méta pendant que les titles restaient copiés. Au crawl suivant, les titres n'avaient pas bougé. L'ordre compte : d'abord ce qui distingue la page dans les résultats, ensuite le texte d'accompagnement.
Savoir quand la ressemblance est saine
Toute répétition ne demande pas une réécriture.
- Copie subie : le même title sort d'un bug de modèle. On corrige le template.
- Variante voulue : un paramètre de suivi ou un tri répète la page, avec une canonique déjà propre. On vérifie la règle, on évite de rédiger quatre versions.
- Page mince : le texte se ressemble parce que la page n'a presque rien à dire. Là, le contenu a un rôle.
- Page utilitaire : des pages d'auteur ou de mentions peuvent partager une structure, tant que le nom ou le rôle change et qu'elles ne visent pas la même requête.
Passer du tableau à quelques actions
L'ordre de lecture que je garde
- Je note la date, le périmètre et si le rendu JavaScript était actif.
- Je filtre les codes d'erreur et les chaînes de redirection.
- Je filtre les canoniques externes et les noindex surprenants.
- Je trie profondeur et liens internes sur les modèles qui portent les pages utiles.
- Je trie titles et H1 pour les copies.
- Je recoupe avec les pages déjà vues dans les résultats, et avec les URLs que je sais stratégiques même si elles sont jeunes.
Ce dernier recoup se fait hors du crawl. Le fichier décrit un état technique. Il ignore quelle page reçoit déjà des impressions. Sans ce recoup, on peaufine une URL que personne ne demande, pendant qu'une page visible reste en 404 ou en canonique fantaisiste.
Une liste groupée par cause
J'écris quatre colonnes : URL, constat, action, modèle concerné. Dès qu'une cause touche toute une famille, je garde une ligne pour le modèle, et je cite deux exemples. Corriger le template une fois évite de rouvrir chaque fiche dans l'éditeur.
Je range ensuite les actions en quatre paquets : réponses du serveur, indexabilité, maillage, textes dupliqués. Puis je m'arrête. Un export donne envie de tout traiter dans l'après-midi. Les paquets tiennent sur plusieurs jours. Le recrawl n'est comparable que si le périmètre reste le même : même domaine, mêmes départs, mêmes limites. Deux réglages différents produisent deux photos qu'on ne peut pas superposer.
Le second fichier vaut plus que le premier
Un crawl jamais relu reste un fichier de plus dans un dossier. Le passage utile arrive après quelques corrections, avec les mêmes réglages. Les 404 que vous avez fermées doivent sortir des liens internes. Les titles copiés doivent s'écarter. Si une famille canonise encore vers l'accueil, le modèle n'a pas bougé : réécrire les paragraphes n'y changera rien.
Conservez le premier export à côté du second. Deux fichiers datés remplacent l'impression floue du genre « il y avait pas mal d'erreurs ». Vous voyez quelle famille a diminué, et laquelle est revenue après une mise en ligne. C'est à ce moment-là que le tableau cesse d'être une liste inquiétante et devient un suivi.
Questions fréquentes
Un rapport de crawl SEO suffit-il à suivre sa visibilité ?
Les deux lectures se complètent. Le crawl montre ce que le robot de l'outil a suivi et ce que le serveur a répondu. La Search Console montre comment Google parcourt le site, ce qu'il indexe et sur quelles requêtes les pages apparaissent. Une 404 présente des deux côtés monte dans la liste. Une page vue dans la Search Console et absente du crawl mérite souvent un lien interne.
Faut-il crawler l'intégralité du site à chaque lecture ?
Sur un petit site, un passage complet reste simple à relire. Sur un gros catalogue, je limite le run aux rubriques que je m'apprête à modifier, plus l'accueil et les pages qui y mènent. Je note ce qui est resté hors périmètre. Un passage large trouve sa place avant une refonte et après, quand la question porte sur tout le domaine.
Que faire des URLs à paramètres dans l'export ?
Je les groupe par nom de paramètre. Un paramètre de suivi qui duplique chaque page se règle par canonique ou par une règle d'URL, selon ce que le site sait appliquer. Un paramètre de tri qui change l'ordre d'une catégorie se juge à part : parfois la vue est utile, parfois elle répète la catégorie sans apport. Filtrer sur le point d'interrogation donne déjà l'ampleur du sujet.
À quel rythme relancer ce crawl ?
Je le relance après chaque lot de corrections, puis à un rythme plus calme, par exemple au moment d'un point sur le site. Un run quotidien brouille la lecture : trop de fichiers, trop peu de changements assumés entre deux exports. Deux crawls comparables, séparés par un vrai travail, apprennent davantage qu'une pile d'exports jamais ouverts.