La plupart des SEO ouvrent la Google Search Console pour vérifier deux choses : les clics dans le rapport Performance et les erreurs dans le rapport Pages (ex-Coverage). Puis ils ferment l'onglet. C'est comme acheter un oscilloscope pour vérifier si une pile est chargée.
La GSC contient des rapports et des données qui, combinés intelligemment, permettent de diagnostiquer des problèmes invisibles dans Screaming Frog ou Semrush : des patterns de crawl anormaux, des signaux de qualité dégradés, des fuites d'index silencieuses. Voici les rapports que vous sous-exploitez — et comment en extraire des décisions techniques concrètes.
Le rapport Crawl Stats : votre fenêtre sur le comportement réel de Googlebot
Le rapport Crawl Stats (Paramètres > Statistiques d'exploration) est le rapport le plus sous-utilisé de la GSC. Il ne vous dit pas ce que Google devrait crawler. Il vous dit ce que Googlebot a réellement fait sur votre site ces 90 derniers jours.
Les métriques qui comptent
Trois graphiques sont disponibles : le nombre total de requêtes d'exploration, la taille totale de téléchargement, et le temps de réponse moyen. La plupart des SEO regardent les courbes sans creuser. La vraie valeur se trouve dans les ventilations.
Cliquez sur n'importe quel graphique pour accéder aux breakdowns par :
- Type de réponse (200, 301, 304, 404, 500…)
- Type de fichier (HTML, JavaScript, CSS, Image, JSON…)
- Objectif (Actualisation vs Découverte)
- Type de Googlebot (Smartphone, Desktop, Image, Video, AdsBot…)
C'est dans ces ventilations que les anomalies apparaissent. Un scénario concret : vous gérez un e-commerce de 18 000 pages produit sous Next.js. Après une mise en production un jeudi soir, vous remarquez dans Crawl Stats que le ratio de crawl "Découverte" chute de 35% à 8% en 5 jours, tandis que le crawl "Actualisation" explose. Traduction : Googlebot re-crawle en boucle des pages qu'il connaît déjà mais ne découvre plus de nouvelles URLs. Le problème ? Un bug dans le composant de pagination qui a cassé les liens <a href> de la navigation à facettes, les remplaçant par des onClick JavaScript sans fallback HTML. Googlebot ne suivait plus les liens.
Sans le rapport Crawl Stats, ce type de régression peut rester invisible pendant des semaines — le temps que les pages orphelines commencent à sortir de l'index.
Détecter un crawl budget gaspillé
Filtrez par type de fichier. Si les requêtes sur les fichiers JavaScript et CSS représentent plus de 40-50% du volume total de crawl, c'est un signal d'alerte. Googlebot dépense son budget à télécharger vos assets au lieu de crawler vos pages HTML.
Vérifiez votre configuration de cache. Un Cache-Control mal configuré sur vos fichiers statiques force Googlebot à les re-télécharger à chaque passage :
# Mauvais : pas de directive de cache sur les assets statiques
location /static/ {
try_files $uri =404;
}
# Bon : cache long-terme sur les assets immutables (fingerprinted)
location /static/ {
try_files $uri =404;
add_header Cache-Control "public, max-age=31536000, immutable";
}
# Pour les fichiers JS/CSS non fingerprinted, un cache intermédiaire
location ~* \.(js|css)$ {
add_header Cache-Control "public, max-age=604800, stale-while-revalidate=86400";
}Un temps de réponse moyen qui dépasse 800ms de manière constante est un autre signal. Ce n'est pas un facteur de ranking direct, mais Google documente explicitement que des temps de réponse élevés réduisent le crawl rate (source Google Search Central). Sur un site de 18 000 pages, un temps de réponse qui passe de 400ms à 1200ms peut réduire le volume de pages crawlées par jour de 30 à 50%.
Exploiter Crawl Stats via l'API
Le rapport Crawl Stats dans l'interface est limité à 90 jours sans export. Pour un suivi longitudinal, utilisez l'API Search Console combinée aux données de vos logs serveur. Voici un script Python pour extraire les données de crawl et les stocker :
from google.oauth2 import service_account
from googleapiclient.discovery import build
import json
from datetime import datetime
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'service-account.json'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)
# Récupérer les stats de crawl
# Note : l'endpoint urlInspection est plus fiable pour des URLs spécifiques
site_url = 'https://www.votre-ecommerce.fr/'
# Inspection d'URL en batch pour vérifier le statut d'indexation
def inspect_url(url: str) -> dict:
request = {
'inspectionUrl': url,
'siteUrl': site_url
}
response = service.urlInspection().index().inspect(body=request).execute()
result = response['inspectionResult']['indexStatusResult']
return {
'url': url,
'verdict': result.get('verdict'),
'coverageState': result.get('coverageState'),
'crawledAs': result.get('crawledAs'),
'lastCrawlTime': result.get('lastCrawlTime'),
'pageFetchState': result.get('pageFetchState'),
'robotsTxtState': result.get('robotsTxtState'),
'indexingState': result.get('indexingState'),
}
# Inspecter les URLs critiques
critical_urls = [
'https://www.votre-ecommerce.fr/categorie/chaussures-running',
'https://www.votre-ecommerce.fr/categorie/chaussures-trail',
# ... vos 200 URLs catégorie
]
results = []
for url in critical_urls:
data = inspect_url(url)
results.append(data)
print(f"{data['url']} -> {data['verdict']} | Last crawl: {data['lastCrawlTime']}")
# Export pour analyse
with open(f'crawl_inspection_{datetime.now().strftime("%Y%m%d")}.json', 'w') as f:
json.dump(results, f, indent=2)Ce script utilise l'API URL Inspection pour vérifier en batch le statut d'indexation de vos URLs stratégiques. Limité à 2 000 requêtes par jour et par propriété, ce qui suffit pour monitorer vos pages catégorie et vos templates critiques. Pour un suivi continu et automatisé de ces métriques, un outil de monitoring SEO comme Seogard peut déclencher des alertes dès qu'une page stratégique perd son indexation.
Le rapport Removals : un indicateur de crise silencieux
Le rapport Removals (Suppressions) est composé de trois onglets que presque personne ne consulte : Suppressions temporaires, Contenu obsolète, et SafeSearch Filtering.
Suppressions temporaires : les accidents de production
L'onglet "Suppressions temporaires" liste les URLs pour lesquelles quelqu'un a explicitement demandé une suppression via l'outil de suppression d'URL de la GSC. Le problème : sur les équipes de plus de 3 personnes, il arrive régulièrement qu'un développeur ou un chef de projet utilise cet outil sans comprendre ses implications. Une suppression temporaire masque l'URL des résultats pendant environ 6 mois, mais elle ne la désindexe pas définitivement. Si personne ne surveille ce rapport, vous pouvez avoir des dizaines d'URLs stratégiques masquées sans le savoir.
Vérifiez ce rapport une fois par semaine. Chaque entrée suspecte doit être annulée immédiatement.
Contenu obsolète : les signaux envoyés par des tiers
L'onglet "Contenu obsolète" montre les demandes de suppression de cache envoyées par des utilisateurs externes via l'outil Remove Outdated Content. N'importe qui peut soumettre une demande si le contenu affiché dans le snippet Google ne correspond plus au contenu réel de la page.
Ce rapport est un canari dans la mine. Si vous voyez des demandes apparaître en masse, cela signifie que vos pages retournent un contenu différent de celui que Google a en cache. Causes fréquentes : une migration de contenu mal gérée, un problème de SSR/CSR où le contenu client-side n'est pas rendu côté serveur, ou des pages produit passées en rupture de stock dont le contenu a été vidé.
Index Coverage en profondeur : au-delà des erreurs évidentes
Le rapport Pages (anciennement Index Coverage) affiche les URLs en erreur, valides, valides avec avertissement, et exclues. La majorité des SEO se concentrent sur les erreurs 5xx et les 404. Les vraies pépites sont dans les statuts d'exclusion.
"Discovered - currently not indexed" vs "Crawled - currently not indexed"
Ces deux statuts sont souvent confondus. Ils indiquent des problèmes radicalement différents.
Discovered - currently not indexed : Google connaît l'URL (via le sitemap ou un lien interne) mais n'a pas jugé utile de la crawler. Cela signifie un problème de priorité de crawl. Vos pages ne sont pas assez bien liées en interne, ou Google considère qu'elles n'apporteront pas assez de valeur pour justifier le crawl. C'est fréquent sur les sites avec une architecture trop profonde ou un maillage interne faible.
Crawled - currently not indexed : Google a crawlé la page mais a décidé de ne pas l'indexer. Le problème est qualité du contenu. Google a vu la page et l'a jugée insuffisante : contenu trop mince, contenu dupliqué, ou cannibalisation avec une autre page du site.
Le ratio entre ces deux statuts vous dit où concentrer vos efforts. Si 80% de vos exclusions sont "Discovered - not indexed", travaillez votre maillage interne et votre crawl budget. Si c'est "Crawled - not indexed", travaillez la qualité et la différenciation de votre contenu.
Extraire la liste complète des URLs exclues
L'interface GSC limite l'affichage à 1 000 URLs par statut. Pour un site de 15 000+ pages, c'est insuffisant. Utilisez l'export vers Google Sheets directement depuis le rapport, ou mieux, croisez avec votre sitemap :
# Télécharger votre sitemap et extraire toutes les URLs
curl -s https://www.votre-ecommerce.fr/sitemap-index.xml | \
grep -oP '<loc>\K[^<]+' | \
while read sitemap_url; do
curl -s "$sitemap_url" | grep -oP '<loc>\K[^<]+'
done > all_sitemap_urls.txt
# Compter par pattern d'URL
echo "=== Répartition des URLs dans le sitemap ==="
echo "Produits: $(grep -c '/produit/' all_sitemap_urls.txt)"
echo "Catégories: $(grep -c '/categorie/' all_sitemap_urls.txt)"
echo "Blog: $(grep -c '/blog/' all_sitemap_urls.txt)"
echo "Total: $(wc -l < all_sitemap_urls.txt)"
# Comparer avec les URLs indexées (export GSC)
# Après export du rapport Pages > Valides > format CSV
comm -23 <(sort all_sitemap_urls.txt) <(sort gsc_indexed_urls.txt) > not_indexed.txt
echo "URLs dans le sitemap mais non indexées: $(wc -l < not_indexed.txt)"
# Identifier les patterns des URLs non indexées
echo "=== Patterns des URLs non indexées ==="
cat not_indexed.txt | \
sed 's|https://www.votre-ecommerce.fr/||' | \
cut -d'/' -f1-2 | \
sort | uniq -c | sort -rn | head -20Ce croisement entre sitemap et données GSC révèle souvent des patterns surprenants. Sur un e-commerce de 15 000 pages, vous pourriez découvrir que 3 200 pages produit avec des variantes de navigation à facettes se retrouvent dans le sitemap alors qu'elles ne devraient pas y être — polluant le crawl budget et diluant les signaux d'indexation.
Le rapport Links : la donnée de backlinks que vous payez ailleurs
Le rapport Links de la GSC est systématiquement sous-évalué. Les SEO préfèrent Ahrefs ou Majestic. Pourtant, la GSC fournit une donnée que personne d'autre n'a : les liens que Google a réellement pris en compte dans son index.
Liens externes : détecter les pertes invisibles
Le rapport "Top linking sites" et "Top linked pages" vous donne une vue complète. L'export vous permet d'obtenir jusqu'à 100 000 lignes de liens externes.
La vraie utilité : le suivi temporel des pertes de liens. Google ne fournit pas d'historique dans l'interface, mais en exportant ces données mensuellement et en les comparant, vous détectez les backlinks perdus — souvent avant que l'impact ne se manifeste dans le trafic.
Scénario : votre site e-commerce de sport reçoit un lien depuis un article du Monde.fr sur une page catégorie /categorie/chaussures-trail. Six semaines plus tard, Le Monde archive l'article et le lien disparaît. Votre page catégorie perd son unique lien depuis un domaine d'autorité. Le trafic organique de cette page baisse de 23% sur les 4 semaines suivantes, mais comme c'est une page parmi 200 catégories, personne ne le remarque dans les dashboards globaux.
Un export mensuel du rapport Links, diffé avec le mois précédent, aurait détecté cette perte immédiatement. Un outil de monitoring comme Seogard automatise cette détection en alertant dès qu'un backlink stratégique disparaît.
Liens internes : la radiographie de votre maillage
Le rapport "Internal links" est plus utile que n'importe quel crawl Screaming Frog pour une raison simple : il montre les liens internes tels que Google les voit. Si votre mega menu injecte des liens via JavaScript et que Googlebot ne les exécute pas correctement, ces liens n'apparaîtront pas dans ce rapport — alors qu'ils apparaîtraient dans Screaming Frog configuré en mode JS rendering.
Croisez les deux sources. Si Screaming Frog trouve 847 liens internes vers votre page catégorie principale et que la GSC n'en montre que 12, vous avez un problème de rendu JavaScript côté Googlebot.
L'API Search Analytics : les dimensions cachées
Le rapport Performance dans l'interface est limité à 5 000 lignes par export. L'API Search Analytics (documentation officielle) permet d'aller beaucoup plus loin avec des combinaisons de dimensions impossibles dans l'interface.
Dimension searchAppearance
La dimension searchAppearance vous révèle quels types de résultats enrichis déclenchent des impressions pour votre site : RICH_RESULT, AMP_BLUE_LINK, VIDEO, REVIEW_SNIPPET, etc. C'est la seule manière fiable de mesurer l'impact réel de vos données structurées sur la visibilité.
Combiner les dimensions pour trouver les anomalies
L'interface GSC ne permet que deux dimensions simultanées. L'API en autorise trois. Cela débloque des analyses impossibles autrement :
from googleapiclient.discovery import build
from google.oauth2 import service_account
import pandas as pd
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
credentials = service_account.Credentials.from_service_account_file(
'service-account.json', scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)
def get_search_analytics(site_url: str, start_date: str, end_date: str) -> pd.DataFrame:
"""
Requête 3 dimensions : page + query + device
Impossible dans l'interface GSC.
"""
rows = []
start_row = 0
while True:
request = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['page', 'query', 'device'],
'rowLimit': 25000,
'startRow': start_row,
'dataState': 'final' # Uniquement données consolidées
}
response = service.searchanalytics().query(
siteUrl=site_url, body=request
).execute()
batch = response.get('rows', [])
if not batch:
break
for row in batch:
rows.append({
'page': row['keys'][0],
'query': row['keys'][1],
'device': row['keys'][2],
'clicks': row['clicks'],
'impressions': row['impressions'],
'ctr': row['ctr'],
'position': row['position']
})
start_row += len(batch)
if len(batch) < 25000:
break
return pd.DataFrame(rows)
df = get_search_analytics(
'https://www.votre-ecommerce.fr/',
'2026-03-01',
'2026-03-31'
)
# Trouver les pages avec un écart de position desktop/mobile > 10 places
pivot = df.groupby(['page', 'device']).agg({
'position': 'mean',
'impressions': 'sum'
}).reset_index()
desktop = pivot[pivot['device'] == 'DESKTOP'][['page', 'position', 'impressions']]
mobile = pivot[pivot['device'] == 'MOBILE'][['page', 'position', 'impressions']]
merged = desktop.merge(mobile, on='page', suffixes=('_desktop', '_mobile'))
merged['position_gap'] = abs(merged['position_desktop'] - merged['position_mobile'])
# Pages avec un écart significatif = problème de rendu mobile probable
anomalies = merged[
(merged['position_gap'] > 10) &
(merged['impressions_mobile'] > 100)
].sort_values('position_gap', ascending=False)
print(anomalies.head(20))Un écart de position supérieur à 10 places entre desktop et mobile sur une même page est un signal fort. Les causes les plus fréquentes : du contenu masqué en mobile (accordéons non crawlables), des problèmes de viewport, ou des temps de chargement mobile dégradés. Consultez l'article sur les performances de page pour creuser cet axe.
Le rapport Expérience : les signaux que Google mesure vraiment
Le rapport Core Web Vitals de la GSC est basé sur les données réelles du Chrome User Experience Report (CrUX). Contrairement à Lighthouse qui mesure en conditions de laboratoire, ces données reflètent l'expérience des vrais utilisateurs.
Le piège du "bon" en labo, "mauvais" en production
Votre page catégorie peut obtenir un score Lighthouse de 95 en local et échouer les Core Web Vitals en production. Les causes : les scripts tiers (analytics, chat, publicités) chargés uniquement en production, les images servies depuis un CDN lent pour certaines régions géographiques, ou les interactions utilisateur qui déclenchent des layout shifts non reproductibles en labo.
Le rapport GSC regroupe vos URLs par groupes de pages similaires (par template). C'est fondamental : un problème de CLS sur votre template produit affecte potentiellement 15 000 pages d'un coup. Screaming Frog ne peut pas vous donner cette information car il n'a pas accès aux données de terrain.
Croiser Core Web Vitals et Performance
Exportez le rapport Core Web Vitals (URLs "mauvaises" et "à améliorer") et croisez avec les données de Performance pour ces mêmes URLs. Vous obtiendrez la corrélation entre métriques de vitesse dégradées et perte de CTR/position sur votre propre site. C'est une donnée d'autant plus fiable qu'elle est spécifique à votre contexte, contrairement aux études génériques.
Le rapport Sitemaps et les erreurs silencieuses
Le rapport Sitemaps ne sert pas uniquement à vérifier que votre sitemap est soumis. Il contient une information critique : le ratio entre URLs soumises et URLs indexées.
Si votre sitemap contient 18 000 URLs et que Google n'en indexe que 11 400, vous avez un taux d'indexation de 63%. Ce n'est pas forcément alarmant — certaines exclusions sont normales (pages canonicalisées, pages paginées). Mais si ce ratio chute de 10 points en un mois, c'est un signal de régression majeur.
Les causes de chute brutale du taux d'indexation sont souvent les mêmes : un déploiement mal contrôlé qui a introduit des noindex en masse, une régression SSR qui retourne des pages vides à Googlebot, ou des redirections en chaîne introduites par une migration d'URL.
Surveillez aussi les erreurs de parsing du sitemap. Un sitemap qui retourne un 200 avec un body HTML (page d'erreur custom) au lieu du XML attendu est un classique. Google ne vous enverra pas d'alerte — il ignorera simplement le sitemap.
Automatiser la surveillance : combiner GSC et logs serveur
La GSC seule ne suffit pas. Sa force maximale s'exprime quand vous croisez ses données avec vos logs serveur. L'approche : comparer ce que Googlebot crawle réellement (logs) avec ce que Google déclare avoir indexé (GSC).
Les divergences entre les deux sources révèlent des problèmes invisibles autrement. Si vos logs montrent que Googlebot crawle une URL quotidiennement mais que la GSC la marque "Crawled - currently not indexed", la page est probablement jugée de trop faible qualité pour l'index — malgré un crawl régulier. Investir dans le maillage interne ne résoudra pas le problème ; c'est le contenu qui doit être retravaillé.
À l'inverse, si une URL stratégique n'apparaît pas dans vos logs Googlebot depuis 30 jours alors qu'elle est dans votre sitemap, vérifiez immédiatement son statut dans le rapport Pages. Elle est probablement passée en "Discovered - currently not indexed".
La GSC est un outil de diagnostic, pas de monitoring. Elle vous montre l'état à un instant T, avec un délai de 2 à 4 jours sur les données. Pour transformer ces diagnostics en système d'alerte continu — avec des seuils et fréquences adaptés à votre contexte — il faut automatiser la collecte et la comparaison. C'est exactement le rôle d'une couche de monitoring comme Seogard, qui agrège ces signaux et détecte les régressions avant qu'elles n'impactent le trafic.
Les rapports avancés de la GSC sont gratuits, exhaustifs, et basés sur les données réelles de Google. Ils méritent plus qu'un coup d'œil mensuel — ils méritent d'être intégrés dans votre workflow de monitoring quotidien.