Le téléphone sonne. Un client : « Google ne voit plus mon site. Enfin, je crois. Le trafic a chuté de moitié en dix jours et je n'ai rien touché. » Je demande combien de pages il a. « Environ 12 000. » Et combien sont indexées ? Silence. Il ne sait pas. Voilà le problème : la plupart des sites ne meurent pas d'un mauvais contenu, ils meurent d'un angle mort technique que personne ne mesure.
C'est exactement pour ça qu'une liste d'indicateurs clés pour mesurer son SEO technique ne ressemble pas à un tableau de bord marketing. Un KPI de trafic vous dit ce qui s'est passé. Un KPI technique vous dit pourquoi, et surtout ce qui va casser dans trois semaines si vous ne bougez pas. Ce sont deux métiers différents.
Points clés à retenir
- Un KPI technique se mesure sur le crawl, l'indexation et le rendu — pas sur les sessions.
- Le premier indicateur à surveiller est le ratio pages indexées / pages soumises, pas le trafic.
- TTFB, LCP et le taux d'erreurs serveur sont vos trois signaux d'alerte précoces.
- Un tableau de bord technique utile tient sur 8 à 10 lignes. Au-delà, personne ne le regarde.
- Priorisez selon la taille du site : sous 500 pages, l'indexation prime ; au-delà, le crawl budget devient central.
Qu'est-ce qu'un indicateur SEO technique, au juste ?
La confusion est constante dans les tableaux de bord que je vois passer. On y mélange allègrement le taux de conversion, la position moyenne et les Core Web Vitals comme s'il s'agissait de la même famille de chiffres. Ça n'a aucun sens.
La frontière entre technique et marketing
Un indicateur technique décrit l'état de santé de l'infrastructure que Google doit parcourir. Il répond à des questions binaires ou quasi binaires : la page est-elle accessible ? Rendue ? Canonique ? Rapide ? Il ne dépend pas de la qualité éditoriale, ni de la demande du marché, ni de la concurrence.
Un indicateur marketing — trafic organique, CTR, position moyenne — décrit la performance qui résulte de tout ça, contenu compris. Les deux se pilotent ensemble, mais on ne les répare pas de la même façon. Si votre taux d'indexation s'effondre, augmenter votre production d'articles ne servira à rien.
Pourquoi cette distinction change votre façon de travailler
Sur un site que j'ai repris il y a quelques années, 40 % des pages n'étaient jamais crawlées. Personne ne s'en était aperçu parce que le trafic global restait stable — les pages fortes compensaient. Le jour où la page forte a perdu son classement, tout s'est effondré d'un coup. Un KPI technique mal suivi, c'est une dette qui se rembourse en une nuit.
La liste des indicateurs techniques à suivre
Voici ceux que je considère comme non négociables. Pas dix-huit. Huit catégories, avec les seuils que j'utilise en pratique — des seuils issus de mon expérience terrain, pas de recettes universelles : votre contexte peut les décaler.
| Indicateur | Ce qu'il mesure | Seuil de vigilance | Fréquence |
|---|---|---|---|
| Taux d'indexation | Pages indexées / pages soumises | < 85 % | Hebdomadaire |
| Crawl budget consommé | Requêtes Googlebot / pages utiles | > 30 % sur des URL sans valeur | Mensuelle |
| TTFB | Temps de réponse serveur | > 600 ms | Quotidienne |
| LCP | Affichage du plus grand élément | > 2,5 s | Hebdomadaire |
| Erreurs 4xx / 5xx | Pages cassées ou serveur en défaut | Toute hausse soudaine | Quotidienne |
| Pages en double (canonicals) | Signaux de canonicalisation | > 5 % des URL | Mensuelle |
| Données structurées valides | Erreurs de balisage | 1 seule erreur bloquante | Mensuelle |
| Rendu JS effectif | Contenu visible après exécution | Écart avec le HTML brut | Trimestrielle |
L'indexation : le premier chiffre à regarder le matin
Si vous ne devez surveiller qu'une chose, c'est le ratio pages indexées sur pages soumises. Un site sain tourne au-dessus de 85 % sur ses pages utiles. En dessous, il y a une cause : soit des pages sans valeur que Google ignore volontairement (et c'est parfois normal), soit un problème de qualité perçue, soit un blocage technique — noindex oublié, redirection cassée, contenu dupliqué massif.
Attention : 100 % n'est pas un objectif. Sur les 12 000 pages du client dont je parlais, environ 3 000 étaient des fiches produits vides ou générées par filtre. Google avait raison de les ignorer. J'ai passé deux semaines à vouloir les faire indexer avant de comprendre mon erreur. On a fini par les passer en noindex, et le crawl budget s'est libéré pour les vraies pages.
Le crawl budget : utile seulement au-delà d'un certain volume
Franchement, en dessous de quelques milliers de pages, le crawl budget est un faux débat. Google crawle tout ce qui compte en quelques jours. Au-delà, ça devient un indicateur de premier plan.
Ce qu'on mesure concrètement : la part de requêtes de Googlebot qui aboutissent sur des URL sans intérêt — paramètres de tri, pages de recherche interne, filtres à combinaisons infinies. Si cette part dépasse un tiers, vous perdez du budget utile. La correction est souvent bête : un robots.txt bien écrit et une balise noindex sur les résultats de recherche interne.
Vitesse et Core Web Vitals : TTFB avant LCP
Tout le monde regarde LCP. Moi, je regarde d'abord le TTFB.
Pourquoi ? Parce que le TTFB est le signal le plus précoce. Quand un serveur commence à saturer, le TTFB grimpe avant que le LCP ne bouge, avant que le trafic ne chute, avant que Google ne réagisse. J'ai vu un site passer de 200 ms à 1,4 s de TTFB sur une période de trois semaines sans que personne ne s'en aperçoive — la base de données avait un problème d'index non détecté. Le trafic a chuté un mois après le début du problème.
- TTFB : visez sous 400 ms, alerte à 600 ms
- LCP : sous 2,5 s pour être dans le vert, alerte à 3 s
- CLS et INP : utiles, mais plus difficiles à corréler avec une perte de classement en pratique
Un détail que je n'ai compris qu'après plusieurs itérations : les Core Web Vitals se mesurent sur le terrain (données réelles) et en laboratoire (test isolé). Les deux divergent souvent. Fiez-vous d'abord au terrain, mais gardez le labo pour reproduire un problème.
Ce que la plupart des listes oublient : le rendu et les balises
Les indicateurs de rendu JS manquent presque partout. Et pourtant, sur les sites modernes, c'est là que se cachent les pires surprises.
Le rendu JavaScript : l'écart entre HTML brut et contenu final
Comparez ce que Googlebot voit dans le HTML initial et ce qu'il voit après exécution du JavaScript. Si un contenu critique — un prix, une description, un lien interne — n'apparaît qu'après exécution, vous prenez un risque. Ce n'est pas fatal en soi, mais ça devient grave quand le rendu échoue ou prend trop de temps.
Ma méthode : je prends les 20 pages les plus stratégiques, je compare les deux versions à la main, une fois par trimestre. Fastidieux, oui. Mais j'ai déjà trouvé deux menus de navigation entièrement dépendants du JS sur un site où personne ne s'en doutait.
Canonicals, hreflang et données structurées
Ces trois-là se surveillent ensemble parce qu'ils partagent un point commun : une erreur coûte silencieusement. Un canonical mal placé désindexe une page sans prévenir. Un hreflang inversé envoie les internautes allemands vers la version française. Une donnée structurée invalide fait disparaître les rich snippets sans jamais faire baisser le trafic — juste le CTR.
Le seuil que j'utilise : dès qu'une erreur bloquante apparaît sur une page à fort trafic, je la traite dans la semaine. Les erreurs sur des pages secondaires attendent le cycle mensuel.
Comment prioriser ces indicateurs selon votre situation
Une liste de vingt KPI qu'on ne regarde pas vaut zéro. La question n'est pas « quoi mesurer » mais « quoi regarder en premier ».
Selon la taille du site
Sous 500 pages : indexation et erreurs 4xx/5xx. Le crawl budget ne vous concerne pas encore. Concentrez-vous sur la propreté.
Entre 500 et 5 000 pages : ajoutez les canonicals et le TTFB. Le rendu JS commence à compter si votre site est dynamique.
Au-delà de 5 000 pages : tout entre en jeu, crawl budget en tête. C'est là que les erreurs coûtent le plus cher.
Selon le type de site
Un e-commerce surveille en priorité l'indexation des pages catégories et les canonicals de filtres. Un média surveille le crawl des archives et la fraîcheur des sitemaps. Une place de marché ajoute le hreflang et les données structurées. Le socle technique reste le même, la pondération change.
Concrètement, dans mon tableau de bord type, je garde 8 lignes : indexation, crawl, TTFB, LCP, erreurs serveur, canonicals, données structurées, rendu. Le reste va dans une vue secondaire que je consulte une fois par mois. Ce qui n'est pas visible ne se pilote pas.
Un dernier mot sur la mesure
Il y a une chose que personne ne dit assez : un indicateur technique qui ne déclenche jamais d'alerte est un indicateur mort. Si votre taux d'indexation reste à 92 % pendant deux ans sans que vous n'ayez jamais eu à intervenir, soit votre site est exceptionnellement sain, soit — plus probable — vous ne mesurez pas ce qu'il faut.
Le bon réflexe, c'est de fixer un seuil, de le faire déclencher, puis de comprendre pourquoi. Un KPI ne sert pas à rassurer. Il sert à vous déranger au bon moment. Si vos chiffres vous laissent tranquille trop longtemps, allez voir du côté du TTFB et du rendu JS. C'est là que dorment les mauvaises nouvelles.
