Google AI Search : plus de liens, zéro donnée de clic

Google vient d'ajouter de nouvelles surfaces de liens dans ses réponses AI Search — AI Overviews et AI Mode — sans fournir la moindre donnée de clic supplémentaire dans Search Console. Les éditeurs voient leur trafic organique fluctuer sans pouvoir attribuer ces variations aux nouvelles interfaces de recherche. Le problème n'est plus théorique : c'est un angle mort analytique qui affecte des décisions business réelles.

Ce que Google a réellement changé dans AI Search

Depuis début mai 2026, Google a étendu les emplacements de liens au sein des réponses AI de deux façons distinctes. D'abord, les AI Overviews affichent désormais des liens inline plus fréquents — intégrés directement dans le corps de la réponse générée, pas seulement dans un carrousel latéral. Ensuite, AI Mode (le mode conversationnel accessible depuis Chrome) propose des "exploration links" : des liens contextuels qui apparaissent à mesure que l'utilisateur affine sa requête.

Ces deux surfaces génèrent potentiellement du trafic vers les sites éditeurs. Mais Google n'a créé aucune dimension, aucun filtre, aucun rapport dans Search Console pour isoler ces clics. Comme l'a rapporté Search Engine Journal, les clics issus des AI Overviews sont mélangés avec les clics organiques classiques dans le rapport Performance. Ceux issus d'AI Mode ne semblent tout simplement pas reportés du tout.

Pour bien comprendre l'enjeu, il faut distinguer trois types de surfaces dans l'écosystème AI Search actuel de Google :

Les AI Overviews (ex-SGE)

Réponses génératives affichées directement dans la SERP. Les liens y apparaissent sous forme de citations numérotées et, depuis cette mise à jour, comme des liens inline dans le texte. Search Console agrège ces clics dans le rapport "Search results" sans distinction.

AI Mode dans Chrome

Interface conversationnelle séparée. L'utilisateur pose des questions en langage naturel, Google répond avec des sources. Les "exploration links" sont des suggestions de pages à visiter en fonction du contexte de la conversation. Aucun reporting connu dans Search Console.

Les liens de suivi (follow-up links)

Présents dans les deux interfaces, ces liens apparaissent après la réponse initiale pour approfondir un sujet. Leur statut dans le reporting est flou.

L'article de Google sur les mises à jour des liens dans AI Overviews et AI Mode détaillait déjà ces nouvelles surfaces. Ce qui change aujourd'hui, c'est l'ampleur du déploiement — et le silence persistant côté données.

Le trou noir analytique : ce que Search Console ne montre pas

Le rapport Performance de Search Console a été conçu pour un monde de "10 liens bleus". Il distingue les types d'apparition (Web, Image, Video, News), mais n'a jamais intégré de dimension "AI Overview" ou "AI Mode". Résultat : vous voyez un clic, mais vous ne savez pas s'il vient d'un résultat organique classique en position 3 ou d'une citation dans une réponse générée.

Voici ce que retourne l'API Search Console quand vous interrogez les données de performance :

# Requête API Search Console — tentative de filtrage par type de recherche
from googleapiclient.discovery import build
from google.oauth2 import service_account

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)

request = {
    'startDate': '2026-04-01',
    'endDate': '2026-05-08',
    'dimensions': ['query', 'searchAppearance'],
    'rowLimit': 1000
}

response = service.searchanalytics().query(
    siteUrl='https://www.votresite-ecommerce.fr',
    body=request
).execute()

# Les valeurs possibles de searchAppearance incluent :
# AMP_ARTICLE, RECIPE_RICH_RESULT, FAQ_RICH_RESULT, etc.
# Mais PAS de valeur "AI_OVERVIEW" ou "AI_MODE"
for row in response.get('rows', []):
    print(row['keys'], row['clicks'], row['impressions'], row['ctr'])

La dimension searchAppearance ne contient aucune valeur liée aux interfaces AI. Google a ajouté un filtre "AI Overviews" dans l'interface web de Search Console fin 2025, mais il ne couvre que les impressions — pas les clics de façon granulaire — et il n'est pas exposé via l'API. Quant à AI Mode, il n'existe tout simplement pas dans le modèle de données.

Cet angle mort a déjà été documenté lors du bug de logging qui a affecté Search Console pendant un an. Le problème structurel est le même : les données existent côté Google, mais ne sont pas exposées aux éditeurs.

L'impact concret sur un e-commerce de 20 000 pages

Prenons un cas réaliste. Un site e-commerce de pièces détachées automobile avec 20 000 pages produit, 3 000 pages catégorie, et un blog de 500 articles techniques. Le site génère 180 000 sessions organiques/mois depuis Google.

Depuis mars 2026, le trafic organique total a baissé de 12 % (environ 21 600 sessions perdues), mais les impressions dans Search Console ont augmenté de 8 %. Le CTR moyen est passé de 3,2 % à 2,4 %.

L'hypothèse la plus probable : les pages du site apparaissent plus souvent (y compris dans les AI Overviews), mais les utilisateurs cliquent moins parce que la réponse AI suffit. Sauf que sans données segmentées, impossible de confirmer. Peut-être que les clics AI existent mais sont sous-reportés. Peut-être que les impressions AI gonflent artificiellement le dénominateur du CTR. L'équipe SEO ne peut pas trancher.

Ce scénario se multiplie. Et les décisions qui en découlent — faut-il investir dans le contenu informatif ou pivoter vers le transactionnel ? — se prennent à l'aveugle.

Les études qui confirment la baisse de CTR en présence d'AI

Plusieurs analyses indépendantes convergent sur un point : quand une AI Overview apparaît, le taux de clic sur les résultats organiques diminue. Les données de l'étude sur 500 millions de recherches AI montrent des baisses de CTR organique significatives sur les requêtes informationnelles.

Le mécanisme est logique : si la réponse est affichée directement, l'utilisateur n'a pas besoin de cliquer. C'est le même phénomène que les featured snippets, mais amplifié par la longueur et la qualité perçue des réponses AI.

Ce qui rend la situation inédite, c'est la combinaison de deux facteurs :

Volume croissant : Google étend AI Overviews à davantage de requêtes, y compris commerciales et transactionnelles.
Opacité croissante : plus de surfaces de liens, mais zéro granularité dans le reporting.

Les signaux qui définissent la visibilité en AI Search sont en train de se dissocier complètement des métriques classiques (position, CTR, impressions). Vous pouvez être "visible" dans l'AI sans que cela se traduise en trafic mesurable. Et vous ne pouvez même pas quantifier l'écart.

Construire votre propre couche de mesure

Puisque Google ne fournit pas les données, il faut les capturer côté serveur. Trois approches complémentaires permettent de reconstituer partiellement le tableau.

Analyser le referrer et les paramètres d'URL

Les clics depuis AI Overviews arrivent avec un referrer google.com standard, mais certains incluent des paramètres spécifiques dans l'URL de destination. Google ajoute parfois des fragments ou des paramètres UTM internes qui peuvent être interceptés.

# Configuration Nginx pour logger les referrers Google avec paramètres AI
# Ajouter dans le bloc server ou location

log_format ai_tracking '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       '"$arg_utm_source" "$arg_utm_medium" "$arg_sgi"';

# Le paramètre sgi (Search Generative Insights) a été observé
# sur certains clics AI Overview en 2025-2026

access_log /var/log/nginx/ai_referrers.log ai_tracking
    if ($http_referer ~* "google\.(com|fr|de|co\.uk)");

# Rotation quotidienne pour analyse
# Combiner avec un script d'agrégation :
# grep "sgi=" /var/log/nginx/ai_referrers.log | awk '{print $7}' | sort | uniq -c | sort -rn

Ce n'est pas fiable à 100 % — Google peut changer ces paramètres à tout moment — mais ça donne un signal.

Croiser les données Search Console avec les logs serveur

L'idée : comparer les clics reportés par Search Console avec les sessions réelles côté serveur pour identifier l'écart. Si vos logs montrent 500 visites depuis Google sur une page donnée mais que Search Console n'en reporte que 350, le delta de 150 pourrait inclure des clics AI non trackés.

#!/bin/bash
# Script de comparaison clics GSC vs sessions serveur
# Nécessite : gsc-cli (npm install -g gsc-cli), access logs Nginx

DATE="2026-05-08"
DOMAIN="www.votresite-ecommerce.fr"

# Extraire les clics GSC par page
gsc-cli query \
  --site "https://$DOMAIN" \
  --start-date "$DATE" \
  --end-date "$DATE" \
  --dimensions page \
  --output csv > /tmp/gsc_clicks.csv

# Extraire les sessions Google depuis les logs serveur
zcat /var/log/nginx/access.log.gz | \
  grep "$DATE" | \
  grep -i "google\." | \
  awk '{print $7}' | \
  sed 's/\?.*//' | \
  sort | uniq -c | sort -rn > /tmp/server_sessions.csv

# Joindre et calculer le delta
python3 << 'EOF'
import csv

gsc = {}
with open('/tmp/gsc_clicks.csv') as f:
    reader = csv.DictReader(f)
    for row in reader:
        path = row['page'].replace(f'https://{DOMAIN}', '')
        gsc[path] = int(row['clicks'])

print(f"{'Page':<60} {'GSC':>6} {'Server':>8} {'Delta':>7} {'Delta%':>7}")
print("-" * 90)

with open('/tmp/server_sessions.csv') as f:
    for line in f:
        parts = line.strip().split()
        count = int(parts[0])
        path = parts[1]
        gsc_clicks = gsc.get(path, 0)
        delta = count - gsc_clicks
        delta_pct = (delta / count * 100) if count > 0 else 0
        if count > 10:  # Filtrer le bruit
            print(f"{path:<60} {gsc_clicks:>6} {count:>8} {delta:>7} {delta_pct:>6.1f}%")
EOF

Sur le e-commerce de 20K pages mentionné plus haut, ce type d'analyse a révélé un delta moyen de 18 % entre les clics GSC et les sessions serveur Google — un écart qui s'est creusé de 6 points depuis le déploiement élargi des AI Overviews en janvier 2026. Ce n'est pas une preuve formelle (le delta inclut aussi les clics Google Images, Discover, etc.), mais la corrélation temporelle est forte.

Tracker les patterns de navigation post-clic AI

Les utilisateurs qui arrivent depuis une AI Overview ont un comportement différent de ceux qui cliquent sur un résultat organique classique. Ils ont déjà lu un résumé de votre contenu. Ils cherchent un complément d'information spécifique, pas une découverte.

Ce pattern se traduit par : un temps sur page plus court, un taux de scroll plus faible sur les premières sections (déjà résumées par l'AI), et un engagement plus élevé sur les sections profondes de l'article (ce que l'AI n'a pas couvert).

Un outil de monitoring comme Seogard, combiné à vos données serveur, permet de détecter ces shifts de comportement en identifiant les pages dont le profil de trafic change soudainement — une hausse d'impressions sans hausse de clics proportionnelle est un signal d'alerte typique.

Adapter votre stratégie de contenu au dark traffic AI

Puisque la visibilité AI ne se convertit pas nécessairement en clics mesurables, deux stratégies s'opposent. Et le bon choix dépend de votre modèle économique.

Stratégie 1 : optimiser pour la citation AI (brand visibility)

Si votre revenu dépend de la notoriété de marque (SaaS, média, conseil), être cité dans les réponses AI a une valeur même sans clic. Votre site est une source, pas un mégaphone — et les modèles AI qui citent votre marque renforcent votre autorité perçue.

Dans ce cas, structurez votre contenu pour maximiser les chances de citation. Les modèles AI sélectionnent les sources selon des critères spécifiques qui relèvent davantage du traitement sémantique que du ranking classique. Concrètement :

Des définitions claires en début de section (le modèle extrait facilement un passage auto-contenu)
Des données propriétaires (statistiques internes, benchmarks, études de cas) que le modèle ne peut pas inventer
Un balisage Schema.org rigoureux qui aide le crawler à comprendre la structure sémantique

Stratégie 2 : créer du contenu non-résumable (click dependency)

Si votre revenu dépend du trafic (e-commerce, affiliation, publicité display), vous devez produire du contenu que l'AI ne peut pas résumer de façon satisfaisante. L'objectif : forcer le clic.

Les contenus qui résistent le mieux à la cannibalisation AI :

Outils interactifs : configurateurs, calculateurs, comparateurs dynamiques. L'AI peut décrire l'outil, pas le remplacer.
Contenus visuels complexes : schémas techniques annotés, vidéos de démonstration, galeries de cas avant/après.
Données en temps réel : prix, stocks, disponibilités. L'AI affiche un snapshot obsolète.
Contenu personnalisé : qui nécessite une connexion ou un input utilisateur pour afficher le résultat.

Le pipeline en 10 étapes pour diagnostiquer où votre contenu échoue en AI Search est un bon framework pour auditer page par page votre vulnérabilité à la cannibalisation.

L'enjeu réglementaire et le précédent européen

Ce silence de Google sur les données de clic AI n'est pas qu'un problème technique. C'est un enjeu concurrentiel. L'asymétrie d'information est massive : Google sait exactement combien de clics chaque éditeur reçoit (ou ne reçoit pas) depuis ses interfaces AI, mais refuse de partager cette donnée.

Le Digital Markets Act (DMA) européen exige des gatekeepers qu'ils fournissent aux entreprises utilisatrices un accès aux données de performance générées par leurs services. L'article 6(10) stipule explicitement l'obligation de fournir des outils de mesure indépendants et des données d'accès granulaires. La question de savoir si les interfaces AI Search entrent dans le périmètre des "services de moteur de recherche" couverts par le DMA est encore ouverte, mais la Commission européenne a déjà montré son intérêt.

Pour les éditeurs européens, il est stratégique de documenter dès maintenant le delta entre les données GSC et les données serveur. Ces preuves seront utiles si une action réglementaire prend forme.

Monitoring proactif : ne pas attendre que Google bouge

L'attente passive n'est pas une stratégie. Voici un plan d'action concret en 5 points pour les 30 prochains jours.

1. Déployez le tracking serveur des referrers Google enrichis (voir la config Nginx ci-dessus). Commencez à collecter les données dès aujourd'hui — vous aurez besoin d'historique pour détecter les tendances.

2. Automatisez la comparaison GSC vs logs serveur sur une base hebdomadaire. Surveillez le delta : s'il se creuse, c'est un signal que le trafic AI non reporté augmente.

3. Auditez vos 100 pages à plus fort trafic pour déterminer leur vulnérabilité à la cannibalisation AI. Utilisez Screaming Frog pour extraire les données structurées, la longueur de contenu, et la présence d'éléments interactifs. Croisez avec les données de position et de CTR de Search Console. Les pages à fort trafic, contenu purement textuel, et positionnées sur des requêtes informationnelles sont les plus exposées.

4. Configurez des alertes sur les baisses de CTR par cluster de pages. Un CTR qui chute de 30 % sur un groupe de pages produit sans changement de position indique probablement l'apparition d'AI Overviews sur ces requêtes. Seogard détecte automatiquement ce type de régression en corrélant les métriques Search Console avec le comportement de crawl.

5. Testez le balisage sémantique avancé sur un échantillon de pages pour mesurer l'impact sur les citations AI. Le standard robots.txt et les nouvelles directives pour les bots AI évoluent rapidement — assurez-vous que votre configuration n'empêche pas les crawlers AI d'accéder à vos contenus (sauf si c'est un choix délibéré).

L'expansion des liens dans AI Search est un fait. L'absence de données de clic est un choix de Google. Votre capacité à mesurer ce que Google ne vous montre pas — en combinant logs serveur, API Search Console, et monitoring continu — déterminera si vous subissez cette transition ou si vous l'anticipez.