KPIs SEO technique : les métriques qui comptent vraiment

Un site e-commerce de 22 000 pages perd 34 % de son trafic organique en trois semaines. L'équipe SEO lance un audit : aucune pénalité manuelle, aucun changement d'algorithme identifié, contenus inchangés. Le problème : une mise à jour du CDN a introduit un header X-Robots-Tag: noindex sur 8 000 pages catégories. Personne ne suivait le ratio de pages indexées par rapport aux pages crawlées. Personne ne mesurait rien côté technique au-delà du trafic global.

Le trafic organique est un indicateur de résultat. Il vous dit que quelque chose a changé — pas ce qui a changé, ni où, ni pourquoi. Pour piloter la santé SEO technique d'un site à grande échelle, il faut des métriques avancées, granulaires, et surtout automatisées.

Crawl budget : mesurer ce que Googlebot consomme réellement

Le crawl budget n'est pas un chiffre unique. C'est la combinaison de deux facteurs : le crawl rate limit (vitesse maximale à laquelle Googlebot crawl sans dégrader le serveur) et le crawl demand (l'intérêt que Google porte à vos URLs). Mesurer le crawl budget, c'est surveiller la friction entre ce que vous voulez faire indexer et ce que Google décide de crawler.

Les métriques à extraire de la Search Console

Le rapport "Statistiques d'exploration" dans Google Search Console (section Paramètres > Statistiques d'exploration) fournit trois données essentielles :

Nombre total de requêtes de crawl par jour : une chute brutale indique un problème serveur ou un signal négatif envoyé à Googlebot.
Taille totale du téléchargement : si elle augmente sans que vous ajoutiez de pages, vous servez probablement du contenu dupliqué ou des ressources inutiles.
Temps moyen de réponse du serveur : au-dessus de 500 ms de façon soutenue, Google réduit son crawl rate.

Le problème de la Search Console, c'est la granularité. Vous avez des données agrégées, sans pouvoir filtrer par répertoire ou type de page. Pour un site de 15 000+ pages, il faut croiser avec les logs serveur.

Analyse de logs : le vrai tableau de bord crawl

L'analyse de logs est le seul moyen de savoir exactement quelles pages Googlebot visite, à quelle fréquence, et quelles pages il ignore. Voici un pipeline minimal pour extraire les hits Googlebot depuis des access logs Nginx :

# Extraire les hits Googlebot du jour, grouper par répertoire, trier par volume
grep "Googlebot" /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sed 's/\?.*//g' \
  | awk -F'/' '{print "/"$2"/"$3"/"}' \
  | sort | uniq -c | sort -rn | head -30

Ce one-liner vous donne la répartition du crawl par section du site. Sur un e-commerce typique, vous découvrirez souvent que Googlebot passe 40 % de son temps sur des pages de navigation à facettes au lieu de crawler vos pages produit stratégiques.

Les KPIs à suivre en log analysis :

Métrique	Seuil d'alerte	Signification
Crawl ratio (pages crawlées / pages indexables)	< 70 % sur 30 jours	Googlebot ne découvre pas toutes vos pages
Fréquence de crawl par page stratégique	< 1 fois / 7 jours	Pages considérées comme peu prioritaires
% de crawl sur pages non-indexables	> 20 %	Gaspillage de crawl budget
Codes 5xx servis à Googlebot	> 2 % des requêtes	Problème d'infrastructure

Un outil comme Screaming Frog Log Analyzer permet de croiser ces données avec un crawl technique pour identifier les pages orphelines (jamais crawlées car absentes du maillage interne) — un problème directement lié à votre architecture de liens internes.

Couverture d'indexation : le ratio qui résume tout

Le KPI le plus sous-estimé en SEO technique : le ratio d'indexation. C'est le rapport entre le nombre de pages que vous souhaitez voir indexées et le nombre de pages réellement dans l'index Google.

Formule :

Ratio d'indexation = (Pages indexées valides / Pages indexables soumises) × 100

Un site sain affiche un ratio supérieur à 90 %. En dessous de 80 %, vous avez un problème structurel. En dessous de 60 %, c'est une hémorragie silencieuse.

Automatiser le suivi avec l'API Search Console

La Search Console expose les données d'indexation via l'API URL Inspection. Mais pour un suivi à grande échelle, le rapport "Pages" (anciennement "Couverture") est plus exploitable. Voici comment extraire programmatiquement les données via l'API Search Console en TypeScript :

import { google } from 'googleapis';

const auth = new google.auth.GoogleAuth({
  keyFile: './service-account.json',
  scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
});

const searchconsole = google.searchconsole({ version: 'v1', auth });

async function getIndexationStats(siteUrl: string) {
  // Récupérer les données de performance pour calculer 
  // le nombre de pages recevant au moins 1 impression
  const response = await searchconsole.searchanalytics.query({
    siteUrl,
    requestBody: {
      startDate: '2026-03-09',
      endDate: '2026-04-08',
      dimensions: ['page'],
      rowLimit: 25000,
      dataState: 'final',
    },
  });

  const pagesWithImpressions = response.data.rows?.length ?? 0;
  const totalImpressions = response.data.rows?.reduce(
    (sum, row) => sum + (row.impressions ?? 0), 0
  ) ?? 0;

  console.log(`Pages avec ≥1 impression (30j) : ${pagesWithImpressions}`);
  console.log(`Impressions totales : ${totalImpressions}`);

  // Comparer avec le nombre de pages indexables du sitemap
  const sitemapResponse = await searchconsole.sitemaps.list({ siteUrl });
  const sitemaps = sitemapResponse.data.sitemap ?? [];
  
  for (const sitemap of sitemaps) {
    console.log(
      `${sitemap.path} — URLs soumises : ${sitemap.contents?.[0]?.submitted}, ` +
      `URLs indexées : ${sitemap.contents?.[0]?.indexed}`
    );
  }
}

getIndexationStats('https://www.monsite-ecommerce.fr');

Ce script vous donne deux données complémentaires : le nombre de pages réellement visibles dans les SERPs (celles avec au moins une impression) et l'écart entre URLs soumises via sitemap et URLs indexées. L'écart entre les deux est votre zone d'ombre.

Les raisons d'exclusion à monitorer en priorité

Dans le rapport "Pages" de la Search Console, certains statuts d'exclusion sont critiques :

"Crawlée, non indexée" : Google a vu la page mais a décidé qu'elle ne méritait pas l'index. Souvent un signal de thin content ou de contenu dupliqué.
"Détectée, pas encore explorée" : backlog de crawl. Sur un gros site, si ce chiffre augmente, votre crawl budget est insuffisant ou votre maillage ne pousse pas ces pages.
"Exclue par la balise noindex" : normal si intentionnel. Catastrophique si c'est un bug de déploiement — exactement le scénario du header CDN mentionné en introduction.
"Autre page avec balise canonical adéquate" : vérifiez que les canonicals pointent bien là où vous le souhaitez. Les rapports Search Console sous-exploités fournissent le détail URL par URL.

La variation de ces chiffres est plus importante que leur valeur absolue. Une augmentation de 500 pages "Crawlée, non indexée" en une semaine est un signal d'alerte immédiat.

Core Web Vitals : les métriques de performance qui impactent le ranking

Depuis 2021, les Core Web Vitals sont un signal de ranking confirmé. En 2026, avec l'introduction d'INP (Interaction to Next Paint) en remplacement de FID, et le durcissement progressif des seuils, ces métriques ne sont plus optionnelles.

Les trois métriques et leurs seuils

Métrique	Bon	À améliorer	Mauvais
LCP (Largest Contentful Paint)	≤ 2.5s	2.5s – 4s	> 4s
INP (Interaction to Next Paint)	≤ 200ms	200ms – 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 – 0.25	> 0.25

La subtilité : Google utilise les données field (données réelles des utilisateurs Chrome via le CrUX report), pas les données lab (Lighthouse, PageSpeed Insights en mode simulé). Vous pouvez avoir un score Lighthouse de 95 et échouer les CWV en field parce que vos utilisateurs sont sur des connexions 3G avec des Android d'entrée de gamme.

Mesurer les CWV à l'échelle du site

Pour un site de plusieurs milliers de pages, mesurer page par page n'est pas viable. L'API CrUX permet d'extraire les données par origine (domaine) ou par URL :

# Requête CrUX API pour les données d'origine
curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=VOTRE_CLE_API" \
  -H "Content-Type: application/json" \
  -d '{
    "origin": "https://www.monsite-ecommerce.fr",
    "formFactor": "PHONE",
    "metrics": [
      "largest_contentful_paint",
      "interaction_to_next_paint",
      "cumulative_layout_shift"
    ]
  }' | jq '.record.metrics'

La granularité par formFactor est essentielle. Un site peut passer les CWV sur desktop et les rater sur mobile — et c'est le mobile que Google utilise pour le ranking (mobile-first indexing).

Pour le suivi temporel, le Chrome DevTools Performance panel reste l'outil de diagnostic le plus précis quand vous avez identifié une page problématique. Mais pour le monitoring continu, il faut une solution automatisée qui alerte quand un déploiement dégrade les CWV.

Le piège du SSR et des CWV

Un cas fréquent : une équipe migre un SPA React vers Next.js avec SSR, espérant améliorer le LCP. Le LCP s'améliore effectivement (le HTML arrive plus vite), mais l'INP se dégrade parce que l'hydration JavaScript bloque le thread principal pendant 800 ms. Le choix entre SSR et CSR a des implications directes sur les CWV, et les trade-offs doivent être mesurés, pas devinés.

Le KPI à suivre ici : le pourcentage de pages avec de bonnes CWV (les trois métriques au vert). La Search Console le fournit dans le rapport "Expérience sur la page", segmenté par mobile et desktop.

Codes de réponse HTTP : le système nerveux de votre site

Les codes HTTP sont probablement le KPI technique le plus ancien et le plus fiable. Un crawl complet de votre site doit produire un rapport de distribution des codes de réponse. Toute déviation de la baseline est un signal.

Distribution cible vs. réalité

Pour un site e-commerce de 22 000 pages en bonne santé :

Code	Attente	Alerte si
200	> 85 % des URLs crawlées	< 80 %
301	< 10 %	> 15 % (chaînes de redirections probables)
302	< 1 %	> 2 % (redirections temporaires qui devraient être 301)
404	< 3 %	> 5 % (pages supprimées sans redirection)
410	Variable selon la stratégie	Inattendu
5xx	0 %	> 0.5 %

Les pages en 404 sur un e-commerce sont inévitables — les produits en rupture créent naturellement du churn. Ce qui compte, c'est le delta : 200 nouvelles 404 après un déploiement, ça ne devrait jamais passer inaperçu.

Automatiser la détection dans le pipeline CI/CD

Intégrer un check de codes HTTP dans votre pipeline de déploiement empêche les catastrophes du vendredi soir. Voici un check basique en script shell qui valide un échantillon d'URLs critiques avant de passer en production :

#!/bin/bash
# seo-smoke-test.sh — à intégrer dans le pipeline CI/CD
# Vérifie que les URLs stratégiques retournent un 200

URLS=(
  "https://staging.monsite-ecommerce.fr/"
  "https://staging.monsite-ecommerce.fr/chaussures-homme/"
  "https://staging.monsite-ecommerce.fr/chaussures-femme/running/nike-air-zoom/"
  "https://staging.monsite-ecommerce.fr/sitemap-index.xml"
)

ERRORS=0

for url in "${URLS[@]}"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$url")
  if [ "$STATUS" -ne 200 ]; then
    echo "FAIL: $url returned $STATUS"
    ERRORS=$((ERRORS + 1))
  else
    echo "OK:   $url returned $STATUS"
  fi
done

# Vérifier que la page produit ne contient pas de noindex accidentel
NOINDEX_CHECK=$(curl -s "https://staging.monsite-ecommerce.fr/chaussures-femme/running/nike-air-zoom/" \
  | grep -ci "noindex")
if [ "$NOINDEX_CHECK" -gt 0 ]; then
  echo "FAIL: noindex détecté sur une page stratégique"
  ERRORS=$((ERRORS + 1))
fi

if [ "$ERRORS" -gt 0 ]; then
  echo "SEO smoke test FAILED — $ERRORS erreur(s)"
  exit 1
fi

echo "SEO smoke test PASSED"
exit 0

Ce script est volontairement basique. Pour un système de checks SEO complet dans le CI/CD, il faut couvrir les canonicals, les hreflang, les balises structurées, et le comportement du SSR.

Métriques de santé du maillage interne et du sitemap

Le maillage interne et le sitemap XML sont les deux leviers directs par lesquels vous communiquez la structure de votre site aux moteurs de recherche. Les mesurer, c'est vérifier que votre message passe.

Profondeur de crawl et distribution de PageRank interne

La profondeur de crawl (nombre de clics depuis la homepage pour atteindre une page) est un proxy de l'importance que vous accordez à une page. Screaming Frog calcule ce metric automatiquement dans l'onglet "Crawl Depth".

KPIs à suivre :

% de pages indexables à profondeur > 3 : idéalement < 20 %. Au-delà, ces pages reçoivent peu de PageRank interne et sont crawlées moins fréquemment. Le choix entre structure plate et structure profonde a un impact direct ici.
Pages orphelines (0 lien interne pointant vers elles) : devrait être 0 pour les pages indexables. Un crawl Screaming Frog croisé avec la liste sitemap détecte immédiatement les orphelines.
Ratio liens internes / pages : un site de 22 000 pages avec seulement 50 000 liens internes a un maillage anémique. Un site avec 2 millions de liens internes a probablement un problème de mega menu ou de footer surchargé.

Santé du sitemap XML

Le sitemap n'est pas un "fire and forget". Il doit être monitoré :

Écart sitemap vs. index : si vous soumettez 22 000 URLs et que Google n'en indexe que 14 000, vous avez 8 000 URLs à investiguer.
URLs dans le sitemap qui retournent autre chose que 200 : chaque 301, 404 ou 410 dans le sitemap est un signal de mauvaise hygiène. Screaming Frog permet de crawler un sitemap et filtrer par code de réponse.
Fraîcheur du <lastmod> : si toutes vos URLs affichent la même date <lastmod>, Google finit par ignorer cette directive. Le <lastmod> doit refléter la date réelle de dernière modification substantielle du contenu.

Assembler le tableau de bord : fréquence et seuils d'alerte

Avoir les bons KPIs ne sert à rien sans la bonne fréquence de mesure et les bons seuils d'alerte. Voici une matrice de monitoring basée sur un site de taille moyenne (5 000 à 30 000 pages).

Fréquence de mesure par type de métrique

Métrique	Fréquence	Source	Outil
Codes HTTP (pages stratégiques)	À chaque déploiement	Smoke tests CI/CD	Script custom, Seogard
Distribution codes HTTP (site entier)	Hebdomadaire	Crawl technique	Screaming Frog, Sitebulb
Ratio d'indexation	Quotidien	Search Console API	Script custom, Seogard
Crawl stats Googlebot	Quotidien	Logs serveur	ELK stack, Oncrawl
Core Web Vitals (field)	Hebdomadaire	CrUX API	Script custom, web.dev
Core Web Vitals (lab)	À chaque déploiement	Lighthouse CI	GitHub Actions
Profondeur de crawl	Mensuel	Crawl complet	Screaming Frog
Pages orphelines	Mensuel	Crawl + sitemap	Screaming Frog

Définir des seuils qui déclenchent une action

Un seuil d'alerte mal calibré génère du bruit (trop sensible) ou laisse passer des incidents (pas assez sensible). Le bon calibrage dépend de votre site, mais voici une approche :

Établir une baseline sur 30 jours de données stables.
Seuil warning : déviation de ±10 % par rapport à la baseline.
Seuil critique : déviation de ±25 % ou valeur absolue dangereuse (ex : > 0 pages stratégiques en 5xx).

Pour aller plus loin sur le calibrage des seuils, le sujet est traité en détail dans cet article sur les alertes SEO.

Le point essentiel : les métriques SEO techniques ne sont utiles que si elles sont lues régulièrement et déclenchent des actions. Un dashboard Looker Studio que personne ne consulte est pire qu'une absence de dashboard — il donne l'illusion du contrôle. Un outil de monitoring comme Seogard résout ce problème en poussant des alertes quand les régressions SEO les plus fréquentes sont détectées, plutôt que d'attendre qu'un humain pense à vérifier un rapport.

Scénario concret : diagnostic d'une chute de trafic en 72 heures

Pour rendre tout cela tangible, voici un cas réaliste.

Contexte : un site média de 18 000 articles, trafic organique de 1,2 M sessions/mois. Lundi matin, le trafic a chuté de 22 % par rapport à la semaine précédente.

Heure 0 – Triage par les KPIs :

Ratio d'indexation (via Search Console API) : stable à 88 %. Pas de déindexation massive.
Crawl stats (via logs) : le crawl Googlebot a chuté de 45 % vendredi après-midi.
Codes HTTP (via logs, filtrés sur Googlebot) : 12 % de réponses 503 servies à Googlebot entre vendredi 16h et samedi 10h.

Heure 6 – Investigation :

Les 503 coïncident avec un déploiement infrastructure (mise à jour de la couche de cache Varnish). Le nouveau config Varnish retournait 503 quand le cache était froid, au lieu de passer la requête au backend. Googlebot, qui crawle à haute fréquence sur un site média, a reçu des milliers de 503 et a réduit son crawl rate.

Heure 24 – Correction :

Rollback de la config Varnish. Soumission des sitemaps via l'API Indexing pour signaler à Google que le site est de nouveau disponible.

Heure 72 – Mesure de la récupération :

Le crawl Googlebot remonte à 80 % de son niveau normal. Le trafic commence à remonter. Récupération complète en 10 jours.

Sans le suivi quotidien des logs serveur filtrés par Googlebot et la corrélation avec les déploiements, ce diagnostic aurait pris des semaines. Le monitoring continu est ce qui fait la différence entre une chute de 22 % pendant 10 jours et une chute de 22 % pendant 2 mois.

Les KPIs SEO techniques ne sont pas des vanity metrics. Ratio d'indexation, distribution du crawl, codes HTTP servis aux bots, Core Web Vitals field, profondeur de maillage — chacune de ces métriques est un capteur qui détecte un type de problème spécifique. La clé n'est pas d'en suivre le maximum, mais de suivre les bonnes métriques à la bonne fréquence, avec des seuils d'alerte qui déclenchent une investigation avant que le trafic ne chute.