Un client m'appelle un mardi matin, paniqué. La veille, son site faisait 1 200 visites par jour depuis Google. Ce matin : 340. Il n'a rien changé. Ou plutôt, si : son développeur a "juste mis à jour le thème" le week-end. Et personne n'a pensé à vérifier une chose qui aurait révélé le problème en 90 secondes.
Cette chose, c'est la Search Console. Pas celle qu'on ouvre une fois par mois pour jeter un œil aux clics. Celle qu'on lit vraiment, rapport par rapport, quand quelque chose cloche. Et honnêtement, la majorité des sites que j'audite utilisent moins de 20 % de ce que l'outil sait faire.
Savoir comment utiliser Google Search Console pour identifier les problèmes techniques, ce n'est pas une compétence de développeur. C'est une compétence de lecture. Vous regardez les bons rapports, dans le bon ordre, et vous comprenez en quelques minutes si votre problème vient de l'indexation, de la performance ou d'une pénalité.
Points clés à retenir
- Le rapport Indexation des pages est le premier endroit où chercher une chute de trafic — pas les Performances.
- « Explorée, actuellement non indexée » est la statut le plus mal compris de l'outil, et souvent le plus révélateur.
- Le rapport Expérience de page traduit vos Core Web Vitals en langage lisible : LCP, INP, CLS.
- Un problème technique se diagnostique dans cet ordre : indexation → exploration → expérience → actions manuelles.
- Une inspection d'URL ne dit pas ce que Google pense de tout votre site, seulement d'une page.
- Les données structurées ont leur propre rapport, et une erreur y passe souvent inaperçue pendant des mois.
Comment utiliser Google Search Console pour identifier les problèmes techniques
Il y a une erreur que je vois tout le temps. Les gens ouvrent la Search Console, vont directement dans Performances, voient une courbe qui descend, et cherchent la cause dans ce rapport. Mauvaise pièce. Le rapport Performances vous montre que quelque chose s'est cassé. Il ne vous dit jamais pourquoi.
Pour le pourquoi, il faut aller dans la colonne de gauche, section « Indexation ». C'est là que vivent 80 % des problèmes techniques que je rencontre.
Le rapport Indexation des pages
Deux nombres comptent ici : le total de pages « Indexées » et le total de pages « Non indexées ». Le deuxième est un seau fourre-tout. À l'intérieur, une dizaine de motifs d'exclusion, et tous ne sont pas des erreurs.
Ceux qui doivent vous alerter :
- Erreur serveur (5xx) — votre hébergement lâche. À traiter immédiatement.
- Erreur 404 — page supprimée sans redirection. Fréquent après une refonte.
- Page avec redirection — souvent normal, mais une chaîne de redirections trop longue dilue le signal.
- Détectée, actuellement non indexée — Google a vu la page et a décidé de ne pas l'indexer. Souvent un problème de qualité ou de duplication, parfois un simple manque de liens internes.
Et puis il y a le plus sournois : « Explorée, actuellement non indexée ». Le robot de Google est passé, a lu la page, et l'a rejetée. Ça n'a rien à voir avec un blocage technique — c'est un jugement éditorial. J'ai mis six mois à comprendre la différence entre « Explorée » et « Détectée » quand j'ai commencé. Six mois. Sur un site de 400 pages, ça représentait environ 60 articles bloqués que je croyais parfaitement indexés.
Le bon réflexe : cliquez sur chaque motif, prenez les 20 premières URL listées, et regardez si elles partagent un point commun. Même gabarit de page ? Même dossier ? Même date de publication ? C'est presque toujours un pattern identifiable en cinq minutes.
Le rapport sitemaps
Un sitemap qui n'a pas été lu depuis trois semaines, c'est un drapeau rouge. Soit il contient une erreur de format, soit il pointe vers des URL bloquées par le robots.txt, soit il a été déplacé et vous n'avez pas mis à jour l'adresse dans la Search Console.
Vérifiez aussi l'écart entre le nombre d'URL annoncées dans le sitemap et le nombre de pages réellement indexées. Pas besoin qu'ils soient égaux. Mais un écart de 80 % dans un sens ou dans l'autre mérite une explication.
Exploration et inspection d'URL : le diagnostic page par page
Quand une page précise pose problème — celle qui a chuté, celle qui ne se référence plus — la première chose à faire n'est pas de la modifier. C'est de l'inspecter.
L'outil d'inspection d'URL vous donne quatre informations qui comptent :
- L'URL canonique choisie par Google (parfois pas celle que vous croyez).
- Si la page est indexable ou non.
- Le dernier crawl du robot, avec une date.
- La version mobile rendue, si JavaScript entre en jeu.
Attention à un piège que j'ai vu coûter cher : l'inspection d'URL vous parle d'une seule page. On a tendance à l'oublier et à généraliser une conclusion. « Ma page d'accueil est indexée, donc tout est bon. » Non. Chaque gabarit de page peut se comporter différemment.
Fichier robots.txt et blocages
Le rapport dédié vous dit immédiatement si votre robots.txt empêche l'exploration de ressources importantes. J'ai déjà vu un site de e-commerce bloquer tout le dossier /images/ — résultat, les pages se chargeaient, mais Google ne pouvait pas voir les visuels produits. Aucune erreur visible côté utilisateur. Trois semaines de trafic en baisse avant qu'on trouve.
Un point rassurant : vous n'avez pas besoin de connaître la syntaxe du robots.txt pour diagnostiquer ici. Le rapport l'interprète et vous signale les lignes problématiques.
Expérience de page : lire les Core Web Vitals sans être développeur
Ce rapport est le grand absent des articles qui parlent de la Search Console. Dommage, parce qu'il traduit les Core Web Vitals en quelque chose de lisible.
Trois métriques comptent :
| Métrique | Ce qu'elle mesure | Seuil à viser |
|---|---|---|
| LCP (Largest Contentful Paint) | Le temps d'affichage du plus gros élément visible | Sous 2,5 secondes |
| INP (Interaction to Next Paint) | La réactivité aux clics et tapotements | Sous 200 ms |
| CLS (Cumulative Layout Shift) | Le décalage visuel pendant le chargement | Sous 0,1 |
La Search Console segmente en « Bon », « À améliorer » et « Mauvais », et distingue mobile et ordinateur. Regardez mobile en priorité, c'est là que les scores cassent.
Une règle que je me suis fixée après plusieurs erreurs : ne jamais optimiser un Core Web Vital juste parce qu'il est « À améliorer ». Un LCP à 2,6 secondes sur une page qui ne vous rapporte rien n'est pas un problème. Concentrez-vous sur les URL qui génèrent des impressions ou du chiffre d'affaires. J'ai perdu deux semaines sur un blog mort avant de comprendre ça.
Les autres rapports à ne pas négliger
Trois rapports complètent le diagnostic. Ils passent souvent en dernier, alors qu'ils devraient faire partie de la routine.
Données structurées
Une erreur de balisage peut vous faire perdre vos rich snippets dans les résultats. Le rapport liste les éléments valides et ceux qui posent problème, type par type. Corrigez, puis utilisez le bouton de validation : Google vous confirmera que le correctif est passé.
Le piège, ici, c'est de traiter ça comme une urgence. Une donnée structurée cassée dégrade l'affichage, elle ne bloque pas l'indexation. Priorisez selon l'impact réel.
Actions manuelles
Une action manuelle est une pénalité appliquée par un humain chez Google. C'est rare, mais quand ça arrive, vous le voyez ici avec le motif exact. Aucun autre outil ne vous donnera cette information. Prenez l'habitude d'y jeter un œil une fois par mois — trente secondes, et vous dormez plus tranquille.
Performances, pour dater le problème
On y revient : le rapport Performances n'est pas le lieu du diagnostic, mais c'est le lieu de la datation. Filtrez par période (7 jours vs 7 jours précédents), comparez, et regardez la date exacte où la chute commence. Ensuite, vous n'avez plus qu'à croiser cette date avec votre calendrier. Mise à jour ? Migration d'hébergeur ? Changement de plugin ?
Dans le cas du client du début de cet article, la chute datait précisément du samedi après-midi. La mise à jour du thème. Le rapport Indexation affichait 180 nouvelles erreurs 5xx. Aucune magie, juste deux rapports lus dans le bon ordre.
En résumé
- Diagnostiquez dans l'ordre : indexation, exploration, expérience, actions manuelles.
- Le rapport Performances date le problème, il ne l'explique pas.
- Un motif d'exclusion isolé ne veut rien dire. Un motif répété sur 20 URL, oui.
- Priorisez toujours selon l'impact business, pas selon la sévérité technique affichée.
Voilà ce que je retiens après avoir vu passer une bonne centaine d'audits : les pannes ne s'annoncent presque jamais. Elles laissent des traces, mais il faut savoir où regarder. La Search Console n'est pas un tableau de bord qu'on consulte pour se rassurer. C'est un outil de forensic.
Alors la prochaine fois que votre trafic bouge d'un côté ou de l'autre, ne cherchez pas l'explication dans la courbe. Ouvrez l'Indexation. Comptez les nouveaux motifs. Cherchez le pattern. Et posez-vous une question que peu de gens se posent réellement : est-ce que je sais encore ce qui a changé sur mon site cette semaine ?
Parce que le vrai problème technique, très souvent, n'est pas technique.
