Un client m'appelle un mardi matin, paniqué : son trafic organique a chuté de 40 % en dix jours. Pas de pénalité manuelle, pas de concurrent qui débarque, pas de changement d'algo annoncé. On a mis quatre heures à trouver. Son hébergeur avait basculé son site sur un serveur saturé, et le TTFB était passé de 180 ms à 2,3 secondes. Googlebot avait simplement arrêté de crawler aussi souvent. Dix jours de crawl perdu, ça ne se voit sur aucun graphique de trafic avant deux à trois semaines.
Voilà pourquoi j'ai fini par abandonner la demi-douzaine de tableaux de bord « SEO » que je bricolais. Ils regardaient tous le trafic, les positions, les backlinks. Aucun ne regardait ce que Googlebot faisait réellement sur le site. Or, en SEO technique, les indicateurs clés de performance qui comptent ne sont pas ceux qu'on affiche en réunion. Ce sont ceux qui décrivent la relation entre votre serveur et le robot.
Points clés à retenir
- Les KPI de SEO technique mesurent le crawl, l'indexation et la vitesse serveur — pas le trafic.
- Le taux d'indexation (pages indexées / pages soumises) est l'indicateur le plus révélateur, et le plus ignoré.
- Un TTFB au-delà de 800 ms réduit la fréquence de crawl bien avant que le trafic ne bouge.
- Surveillez 6 à 8 indicateurs techniques maximum. Au-delà, personne ne les lit.
- Un site e-commerce et un site média n'ont pas les mêmes priorités de surveillance.
- Reliez chaque KPI technique à une perte de CA estimée, sinon il restera ignoré par la direction.
Un KPI SEO technique, c'est quoi au juste ?
La définition qu'on trouve partout — « indicateur quantitatif ou qualitatif mesurant l'efficacité d'une action vers un objectif » — ne sert à rien. Elle s'applique à n'importe quoi, du NPS au taux de clics sur une bannière. Le problème n'est pas la définition, c'est l'usage qu'on en fait.
Un KPI technique, dans ma pratique, répond à une question unique : est-ce que le robot peut voir, comprendre et garder cette page ? Si l'indicateur ne répond pas à cette question, ce n'est pas un KPI technique. C'est un KPI de performance, de contenu, ou de popularité, et il a sa place ailleurs.
Ce qui distingue un indicateur technique d'un indicateur de trafic
Le trafic organique est un indicateur de résultat. Il arrive en bout de chaîne, après que tout le reste a fonctionné. Le problème avec les indicateurs de résultat : quand ils se dégradent, la cause est déjà vieille de plusieurs semaines.
Un indicateur technique, lui, se dégrade avant le résultat. C'est toute sa valeur. Une remontée d'erreurs 5xx sur trois jours annonce une chute de trafic dans le mois. Un taux d'indexation qui décroche de 85 % à 62 % annonce un problème de contenu dupliqué ou de budget de crawl gaspillé.
Deux indicateurs qui n'ont aucun sens isolés
Il y a un piège classique : regarder la vitesse de crawl seul. Un site crawlé 40 000 fois par jour peut sembler en pleine forme. Sauf que si 32 000 de ces hits concernent des URLs de paramètres ou des pages en 404, le robot tourne à vide. Le chiffre est gros, il est inutile.
Toujours croiser. Nombre de hits de crawl divisé par nombre d'URLs uniques touchées. Sur un site e-commerce sain, je vise un ratio proche de 1,5. Au-delà de 4, une part importante du budget part dans le vide.
Quels indicateurs techniques surveiller en priorité ?
Je vais être direct : la plupart des listes que vous trouverez empilent quinze KPI et vous laissent vous débrouiller. C'est une façon de ne rien prioriser. Voici les sept qui comptent vraiment, dans l'ordre où je les regarde.
- Taux d'indexation : pages indexées sur pages soumises. En dessous de 70 % sur un site de contenu, il y a un problème.
- Couverture des erreurs serveur : 5xx, 429, timeouts. À zéro en régime normal.
- TTFB médian par groupe d'URLs, pas en moyenne globale (une moyenne cache tout).
- Ratio hits de crawl / URLs uniques, calculé sur 7 ou 14 jours.
- Respect du robots.txt et absence de blocages involontaires sur des ressources critiques.
- Fraîcheur du sitemap : date de dernière modification réellement lue par le robot.
- Core Web Vitals sur les pages d'entrée principales (LCP, INP, CLS).
Sept. Pas quinze. Si vous en suivez plus, c'est que vous ne savez pas lesquels comptent, et votre tableau de bord finira ignoré comme les miens l'étaient.
À quelle fréquence regarder chaque indicateur ?
La fréquence est aussi importante que le choix. Un indicateur regardé au mauvais rythme génère du bruit, et le bruit tue la confiance dans l'outil.
| Indicateur | Fréquence | Seuil d'alerte | Délai d'impact trafic |
|---|---|---|---|
| Erreurs 5xx / 429 | Quotidienne | Toute remontée sur 48 h | 2 à 4 semaines |
| TTFB médian | Hebdomadaire | > 800 ms | 3 à 6 semaines |
| Taux d'indexation | Mensuelle | < 70 % | 4 à 8 semaines |
| Ratio crawl / URLs | Mensuelle | > 4 | Indirect, via indexation |
| Core Web Vitals | Trimestrielle | Page en « faible » | Variable |
Avouons-le, la fréquence quotidienne sur les erreurs serveur demande une automatisation. Sinon vous passerez votre vie à ouvrir des rapports. Un simple script qui compte les 5xx par jour et vous envoie un mail si le chiffre dépasse un seuil fait le travail.
Les seuils ne sont pas les mêmes selon le site
J'ai appris ça à mes dépens. Un site média et une boutique en ligne ne se surveillent pas pareil, et calquer les seuils de l'un sur l'autre m'a fait rater deux incidents.
Sur un média, le renouvellement de contenu est quotidien. Le budget de crawl se concentre naturellement sur les nouvelles pages. Ce qu'il faut surveiller, c'est la vitesse d'indexation des articles publiés du jour : un article qui met plus de 48 heures à apparaître, c'est trop. Sur une boutique, l'enjeu est inverse. Les fiches produits existent déjà, elles changent rarement. Ce qu'il faut surveiller, c'est la stabilité du crawl sur les catégories et les fiches à forte marge.
Un site local, avec vingt pages, n'a besoin d'aucun des indicateurs précédents. Il a besoin d'un TTFB correct et d'une indexation complète. Point. Le reste est du bruit d'agence.
Comment relier un KPI technique à une perte de chiffre d'affaires ?
C'est la question qu'on me pose le plus souvent en réunion de direction. Et c'est légitime : personne ne finance une surveillance qui ne parle pas en euros.
La méthode est simple, à condition d'accepter une part d'estimation. Prenez un groupe d'URLs, estimez le trafic organique qu'elles reçoivent, multipliez par le taux de conversion du site et par le panier moyen. Vous obtenez un revenu organique par groupe.
Un exemple chiffré sur un cas réel
Sur un site e-commerce que je suivais, une catégorie principale représentait environ 22 % du trafic organique et 18 % du chiffre d'affaires organique. Le TTFB médian sur cette catégorie a dérivé de 400 ms à 1,6 seconde en un mois, à cause d'une requête non optimisée ajoutée par un développeur.
Sur les six semaines suivantes, la fréquence de crawl Googlebot sur ces URLs a baissé d'environ 35 %. Le trafic organique de la catégorie a suivi, en baisse de 20 % au bout de huit semaines. En euros, ça représentait à peu près 3 800 € de CA organique mensuel perdu. Un correctif de trois heures de développement a tout remis en ordre.
Le chiffre à retenir n'est pas les 3 800 €. C'est le délai. Entre la dégradation technique et la perte de chiffre, il s'est écoulé deux mois. Sans indicateur direct sur le TTFB, ce dev était invisible.
Ce qui fait bouger une direction, ce n'est pas le KPI
Un TTFB à 1,6 seconde ne fait réagir personne. « 3 800 € de CA en risque ce mois-ci, corrigeable en trois heures » fait réagir tout le monde. Le travail de traduction fait partie du suivi, il ne vient pas après.
Donc, règle que je m'impose : aucun indicateur technique dans un tableau de bord de direction s'il n'est pas accompagné d'une estimation de revenu à la baisse ou à la hausse. Les indicateurs purement techniques, je les garde dans un tableau de bord opérationnel séparé, lu par l'équipe qui peut agir dessus.
Le trafic issu de l'IA : faut-il le suivre dès maintenant ?
Oui. Et c'est ce qui manque à presque tous les tableaux de bord que je croise, y compris les miens il y a dix-huit mois.
Le trafic référent depuis les assistants et les réponses génératives existe, il est mesurable, et il se comporte différemment du trafic classique. Les visites arrivent en plus petit volume mais avec une intention souvent plus avancée. Sur un site B2B que je suis, le trafic issu de ces sources représentait environ 4 % des sessions organiques, mais avec un taux de conversion nettement supérieur à la moyenne du canal organique.
Le problème technique : ce trafic est mal catégorisé dans la plupart des outils d'analytics. Il tombe dans « referral » ou « direct » selon les cas. Il faut créer un groupe de canaux dédié et y lister les domaines référents concernés.
Trois indicateurs à suivre pour ce canal
- Part du trafic organique attribuable aux interfaces génératives, en pourcentage hebdomadaire.
- Taux de conversion de ce canal comparé au reste de l'organique.
- Pages du site citées en source, si vous avez les moyens de le détecter (les outils dédiés existent, ils restent imparfaits).
Ce troisième point est le plus instable. La détection des citations est encore approximative et change souvent. Je le surveille, je ne le pilote pas encore.
Les erreurs qui rendent vos indicateurs faux
Il y a un moyen sûr de produire un tableau de bord technique qui ne sert à rien : mesurer large au lieu de mesurer juste. Trois erreurs reviennent systématiquement.
Erreur n°1 : agréger au lieu de segmenter
Le TTFB moyen du site est une donnée inutile. Une page rapide et une page lente se moyennent en une valeur « correcte » qui masque les deux problèmes. Segmentez par type de gabarit : accueil, catégorie, fiche, article. Le diagnostic arrive tout seul.
Erreur n°2 : figer les seuils une fois pour toutes
Le seuil de 800 ms sur le TTFB que je vous ai donné plus haut est un point de départ, pas une loi. Un site média avec beaucoup d'images et un site d'API n'ont pas le même plancher technique atteignable. Établissez un seuil à partir de votre historique : quelle était la valeur quand le crawl se portait bien ?
Erreur n°3 : surveiller sans que personne ne soit responsable
Celle-ci m'a coûté cher. J'avais monté un suivi nickel sur les erreurs 5xx, avec alertes. Sauf que personne n'était désigné pour réagir à l'alerte. Une alerte sans destinataire n'est pas un KPI, c'est une notification qu'on apprend à ignorer. Maintenant, chaque indicateur a un nom en face dans le tableau.
Le tableau de bord qui tient dans le temps
Il n'existe pas de tableau de bord parfait. Il existe des tableaux de bord qu'on regarde encore six mois après les avoir montés, et les autres.
Le mien tient sur une page. Sept indicateurs, une fréquence claire, un seuil d'alerte par ligne, un responsable désigné, et une estimation de revenu en face des trois plus critiques. Rien d'autre. Ceux que j'avais construits avec vingt métriques et des graphiques partout, je les ai tous abandonnés en quelques semaines.
La vraie question, en fin de compte, n'est pas de savoir combien d'indicateurs suivre. C'est de savoir lequel des vôtres vous alerterait aujourd'hui si quelque chose cassait cette nuit. Si vous n'en avez pas un seul qui réponde oui, le problème n'est pas dans les métriques. Il est dans le fait que votre SEO technique se pilote encore à l'aveugle, en attendant que le trafic descende pour comprendre ce qui s'est passé. Et à ce moment-là, comme mon client de mardi matin, il est déjà un peu tard.