Un nouveau type de rapport apparaît dans la Search Console de certains sites britanniques : des métriques d'impressions spécifiques à l'AI Search, séparées des résultats organiques classiques. C'est la première fois que Google fournit des données structurées sur la visibilité dans ses réponses générées par IA. Et ça change fondamentalement la façon dont vous allez mesurer — et défendre — votre trafic organique.
Ce que Google teste exactement
D'après les captures rapportées par Search Engine Journal, le test introduit deux éléments dans Search Console :
- Un filtre "AI Search" dans le rapport Performance, permettant d'isoler les impressions générées par les AI Overviews (AIOs) des impressions organiques traditionnelles.
- Un rapport dédié avec des métriques spécifiques : impressions AI, clics depuis les blocs AI, et potentiellement un CTR distinct.
Le test est limité à un sous-ensemble de sites UK. Pas de déploiement global annoncé.
Pourquoi c'est structurellement différent des données actuelles
Jusqu'à maintenant, les impressions dans Search Console mélangeaient tout. Si votre page était citée dans un AI Overview, l'impression était comptabilisée dans le même bucket que vos résultats position 1-10. Vous n'aviez aucun moyen de distinguer :
- Une impression "classique" en position 3 sur une SERP traditionnelle
- Une citation dans un bloc AI Overview sans lien cliquable direct
- Une apparition dans un panneau AI avec lien vers votre page
Cette opacité rendait impossible toute analyse sérieuse de l'impact des AIOs sur le trafic. Vous voyiez vos impressions monter sur certaines requêtes, mais votre CTR s'effondrait — sans pouvoir attribuer la cause.
Le nouveau rapport corrige ce problème. En séparant les métriques AI des métriques organiques classiques, vous pouvez enfin calculer un CTR AI distinct et le comparer au CTR organique traditionnel sur les mêmes requêtes.
Ce que le rapport ne dit probablement pas (encore)
Soyons lucides sur les limites. Le test actuel semble se concentrer sur les impressions et clics. Il ne fournit vraisemblablement pas :
- La position exacte de votre citation dans le bloc AI (premier lien cité vs. cinquième source)
- Le taux de citation : combien de fois votre contenu est utilisé par le modèle sans être crédité
- La cannibalisation : le delta entre le trafic que vous auriez reçu via le résultat organique classique et celui que vous recevez via l'AIO
C'est un premier pas. Pas la solution complète. Google a tout intérêt à montrer que l'AI Search génère de la valeur pour les éditeurs — leur guidance officielle sur le sujet est d'ailleurs déjà critiquable.
Implications techniques pour le tracking et le reporting
Si ce rapport se déploie globalement, il va falloir adapter vos pipelines de données SEO. Voici les changements concrets à anticiper.
Mise à jour de vos scripts d'extraction Search Console
La plupart des équipes SEO avancées utilisent l'API Search Console pour alimenter des dashboards custom. L'API expose le endpoint searchAnalytics.query avec un paramètre type qui accepte actuellement web, image, video, news, discover, et googleNews.
Si Google ajoute un type aiSearch (ou équivalent), vos scripts doivent être mis à jour. Voici un exemple de ce que pourrait donner l'extraction avec le client Python officiel :
from googleapiclient.discovery import build
from google.oauth2 import service_account
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = '/path/to/service-account.json'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES)
service = build('searchconsole', 'v1', credentials=credentials)
# Requête actuelle (trafic web classique)
request_web = {
'startDate': '2026-05-01',
'endDate': '2026-05-31',
'dimensions': ['query', 'page'],
'type': 'web',
'rowLimit': 25000
}
# Requête hypothétique pour AI Search (type à confirmer au déploiement)
request_ai = {
'startDate': '2026-05-01',
'endDate': '2026-05-31',
'dimensions': ['query', 'page'],
'type': 'aiSearch', # nom hypothétique — surveiller la doc API
'rowLimit': 25000
}
response_web = service.searchanalytics().query(
siteUrl='https://www.votre-ecommerce.fr',
body=request_web
).execute()
response_ai = service.searchanalytics().query(
siteUrl='https://www.votre-ecommerce.fr',
body=request_ai
).execute()
# Fusion et calcul du delta CTR
for row_ai in response_ai.get('rows', []):
query = row_ai['keys'][0]
page = row_ai['keys'][1]
ctr_ai = row_ai['ctr']
# Trouver le CTR web correspondant
matching_web = next(
(r for r in response_web.get('rows', [])
if r['keys'][0] == query and r['keys'][1] == page),
None
)
if matching_web:
ctr_delta = ctr_ai - matching_web['ctr']
if ctr_delta < -0.05: # Alerte si le CTR AI est 5 points sous le CTR web
print(f"⚠ Cannibalisation probable: {query} | {page} | "
f"CTR web: {matching_web['ctr']:.2%} → CTR AI: {ctr_ai:.2%}")Ce script est évidemment spéculatif sur le nom exact du type API. Mais la logique de comparaison web vs. AI est celle que vous devrez implémenter dès le déploiement. Surveillez la documentation officielle de l'API Search Console pour le nom exact du paramètre.
Segmentation dans vos dashboards Looker Studio / BigQuery
Si vous exportez vos données Search Console vers BigQuery (via le bulk export natif ou un pipeline custom), vous allez devoir créer des vues segmentées. Exemple de requête SQL pour isoler les requêtes où l'AI Search cannibalise le trafic organique :
WITH web_data AS (
SELECT
query,
page,
SUM(impressions) AS web_impressions,
SUM(clicks) AS web_clicks,
SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS web_ctr
FROM `project.dataset.search_console_web`
WHERE data_date BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY query, page
),
ai_data AS (
SELECT
query,
page,
SUM(impressions) AS ai_impressions,
SUM(clicks) AS ai_clicks,
SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ai_ctr
FROM `project.dataset.search_console_ai_search`
WHERE data_date BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY query, page
)
SELECT
w.query,
w.page,
w.web_impressions,
w.web_ctr,
a.ai_impressions,
a.ai_ctr,
(a.ai_ctr - w.web_ctr) AS ctr_delta,
-- Estimation de la perte de clics
CAST(w.web_impressions * (w.web_ctr - COALESCE(a.ai_ctr, 0)) AS INT64) AS estimated_lost_clicks
FROM web_data w
LEFT JOIN ai_data a ON w.query = a.query AND w.page = a.page
WHERE a.ai_impressions > 100 -- Filtre sur les requêtes avec volume AI significatif
AND (a.ai_ctr - w.web_ctr) < -0.03 -- CTR AI inférieur de 3+ points
ORDER BY estimated_lost_clicks DESC
LIMIT 200;Ce type de requête vous donne une liste priorisée des pages où l'AI Search vous coûte du trafic. C'est la base d'un plan d'action : faut-il optimiser le contenu pour mieux apparaître dans les AIOs, ou faut-il cibler des requêtes où les AIOs ne se déclenchent pas ?
Scénario concret : un e-commerce mode de 8 000 pages
Prenons un cas réaliste. Vous gérez le SEO d'un e-commerce mode français avec 8 000 pages indexées : 3 500 fiches produit, 2 000 pages catégorie/sous-catégorie, 1 200 articles blog, et le reste en pages institutionnelles.
Situation avant les rapports AI Search
Depuis le déploiement massif des AI Overviews en France (début 2026), vous observez sur Search Console :
- Impressions globales : +18% sur les requêtes informationnelles ("comment choisir une veste en lin", "taille jean Levi's 501 femme")
- CTR moyen : passé de 3,2% à 2,1% sur ces mêmes requêtes
- Clics : -12% net malgré la hausse d'impressions
Vous suspectez une cannibalisation AI, mais impossible de le prouver. Votre direction marketing veut des chiffres. "Le SEO perd du terrain" est tout ce que vous pouvez dire.
Situation avec les rapports AI Search
Avec la segmentation AI, vous pouvez enfin produire ce type d'analyse :
- Sur la requête "comment choisir une veste en lin" :
- Web classique : 4 200 impressions/mois, CTR 4,8%, 202 clics
- AI Search : 6 800 impressions/mois, CTR 0,9%, 61 clics
- Total clics : 263 (vs. ~320 estimés avant les AIOs)
- Perte nette : ~57 clics/mois sur cette seule requête
Extrapolé sur vos 1 200 articles blog (qui captent l'essentiel des requêtes informationnelles), vous pouvez estimer une perte de 2 500 à 4 000 clics/mois attribuable spécifiquement aux AI Overviews.
Mais — et c'est là que ça devient intéressant — vous découvrez aussi que sur certaines requêtes transactionnelles ("veste en lin homme pas cher"), votre CTR AI est supérieur au CTR web classique. Pourquoi ? Parce que l'AIO cite votre fiche produit avec le prix, et l'utilisateur clique directement sans passer par les 10 liens bleus. Sur ces requêtes, l'AI Search vous fait gagner du trafic.
Le plan d'action qui en découle
-
Requêtes informationnelles : restructurer le contenu pour maximiser la citation dans les AIOs (réponses directes en haut d'article, données structurées FAQ, paragraphes concis). C'est exactement le type de contenu qu'il faut optimiser pour la visibilité AI.
-
Requêtes transactionnelles : renforcer le balisage structuré Product, Offer, AggregateRating pour que l'AIO affiche vos produits avec prix et avis.
-
Requêtes où les AIOs ne se déclenchent pas : identifier ces requêtes (souvent très longue traîne, très locales, ou très récentes) et les prioriser dans votre calendrier éditorial.
Préparer votre balisage structuré pour l'AI Search
Les AI Overviews ne citent pas les sources au hasard. L'extraction repose sur la capacité du modèle à identifier des réponses fiables et structurées. Le balisage structuré joue un rôle croissant dans cette sélection.
Schema.org étendu pour la lisibilité machine
Allez au-delà du balisage de base. Sur vos pages produit, un balisage Product complet avec offers, review, brand et hasMerchantReturnPolicy donne au modèle les signaux nécessaires pour extraire une réponse riche :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Veste en lin homme – Coupe droite",
"brand": {
"@type": "Brand",
"name": "Maison Textile"
},
"description": "Veste en lin lavé, coupe droite, doublure coton. Fabriquée au Portugal.",
"sku": "VLH-2026-042",
"offers": {
"@type": "Offer",
"price": "129.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-09-30",
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "https://schema.org/ReturnByMail"
},
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"addressCountry": "FR"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 2,
"unitCode": "DAY"
},
"transitTime": {
"@type": "QuantitativeValue",
"minValue": 2,
"maxValue": 4,
"unitCode": "DAY"
}
}
}
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "238"
},
"material": "Lin lavé",
"countryOfOrigin": {
"@type": "Country",
"name": "Portugal"
}
}
</script>Ce niveau de détail (politique de retour, délais de livraison, matière, pays de fabrication) est ce qui différencie un balisage que le modèle peut exploiter d'un balisage minimal qui ne sert qu'à afficher des rich snippets classiques. La question de la lisibilité machine de votre marque va bien au-delà du simple schema.org.
Identifier les pages citées dans les AIOs
En attendant le déploiement global du rapport AI Search, vous pouvez déjà traquer quelles pages sont citées dans les AI Overviews. Une approche programmatique avec Puppeteer ou Playwright :
import { chromium } from 'playwright';
interface AIOResult {
query: string;
cited: boolean;
citedUrl: string | null;
aioPresent: boolean;
}
async function checkAIOCitation(
queries: string[],
targetDomain: string
): Promise<AIOResult[]> {
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
locale: 'fr-FR',
geolocation: { latitude: 48.8566, longitude: 2.3522 },
userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
});
const results: AIOResult[] = [];
for (const query of queries) {
const page = await context.newPage();
await page.goto(
`https://www.google.fr/search?q=${encodeURIComponent(query)}`,
{ waitUntil: 'networkidle' }
);
// Attendre le chargement éventuel du bloc AI Overview
await page.waitForTimeout(3000);
// Sélecteur du conteneur AI Overview (à adapter — Google change régulièrement)
const aioContainer = await page.$('[data-attrid="ai-overview"]');
// Alternative : chercher le conteneur SGE/AIO par d'autres attributs
const aioAlt = await page.$('.kp-wholepage .aiOverview, .M8OgIe');
const aioPresent = !!(aioContainer || aioAlt);
let cited = false;
let citedUrl: string | null = null;
if (aioPresent) {
const container = aioContainer || aioAlt;
const links = await container!.$$('a[href]');
for (const link of links) {
const href = await link.getAttribute('href');
if (href && href.includes(targetDomain)) {
cited = true;
citedUrl = href;
break;
}
}
}
results.push({ query, cited, citedUrl, aioPresent });
await page.close();
// Respecter un délai pour éviter le blocage
await new Promise(r => setTimeout(r, 5000 + Math.random() * 5000));
}
await browser.close();
return results;
}
// Usage
const queries = [
'comment choisir veste en lin homme',
'meilleure veste lin été 2026',
'veste lin homme pas cher livraison rapide'
];
checkAIOCitation(queries, 'votre-ecommerce.fr').then(results => {
results.forEach(r => {
console.log(`${r.query}: AIO=${r.aioPresent}, Cité=${r.cited}, URL=${r.citedUrl}`);
});
});Quelques précautions : ce scraping est fragile (les sélecteurs CSS de Google changent constamment), il viole les ToS de Google, et il ne scale pas au-delà de quelques dizaines de requêtes sans risque de CAPTCHA. Utilisez-le pour un échantillon représentatif, pas pour un audit exhaustif.
Comment les données AI Search changent la stratégie de contenu
L'arrivée de ces métriques force une refonte de la façon dont les équipes SEO priorisent le contenu.
La fin du "trafic informationnel gratuit"
Depuis 15 ans, le contenu informationnel (guides, tutos, comparatifs) était le pilier de l'acquisition SEO. Vous publiez un guide exhaustif, vous captez du trafic informationnel, vous convertissez une fraction en clients.
Les AI Overviews changent cette équation. Sur les requêtes informationnelles, l'AIO fournit souvent une réponse suffisante. L'utilisateur n'a plus besoin de cliquer. Vos impressions montent (votre page est "citée"), mais vos clics baissent.
Les nouveaux rapports AI Search vont rendre cette réalité mesurable et indiscutable. Attendez-vous à des conversations difficiles avec les équipes content : "Votre guide à 3 000 mots génère 12 000 impressions AI mais seulement 85 clics."
Trois catégories de requêtes à segmenter
Avec les données AI Search, vous pouvez construire une matrice de priorisation :
Catégorie 1 — AI-positive : requêtes où votre CTR AI est supérieur à votre CTR web. Typiquement des requêtes transactionnelles où l'AIO met en avant votre produit avec prix. Stratégie : maximiser le balisage structuré, enrichir les données produit.
Catégorie 2 — AI-neutre : requêtes où l'AIO ne se déclenche pas (encore). Souvent des requêtes longue traîne, locales, ou très récentes. Stratégie : investir massivement sur ce segment, c'est votre trafic organique "classique" préservé.
Catégorie 3 — AI-cannibale : requêtes où l'AIO répond à la place de votre page. CTR AI très bas, impressions AI élevées. Stratégie : soit vous optimisez pour être la source citée n°1 (avec un lien cliquable), soit vous réallouez vos efforts vers les catégories 1 et 2.
Cette segmentation n'était pas possible sans les rapports dédiés. C'est ce qui rend ce test structurellement important — bien au-delà d'une simple mise à jour d'interface Search Console.
Ce que Google ne dit pas : les enjeux politiques derrière ce test
Ce test n'arrive pas par hasard. Il s'inscrit dans un contexte de pression croissante des éditeurs et des régulateurs sur la transparence des AI Overviews.
Le problème du "zero-click AI"
Les éditeurs de contenu — médias, e-commerce, SaaS — se plaignent depuis le lancement des AIOs que Google utilise leur contenu pour générer des réponses sans renvoyer de trafic. C'est le problème du zero-click poussé à l'extrême.
En fournissant des métriques AI séparées, Google fait deux choses :
-
Il se protège juridiquement : "Regardez, nous donnons aux éditeurs les outils pour mesurer leur visibilité AI." C'est un argument défensif face aux régulateurs européens (DMA, DSA) et aux procédures antitrust US.
-
Il cadre le narratif : en ne fournissant que les impressions et clics AI (sans le delta de cannibalisation), Google peut mettre en avant les cas où l'AI Search ajoute de la visibilité. Les cas de cannibalisation restent à la charge de l'éditeur pour les calculer.
C'est exactement ce qui s'est passé lors des annonces I/O 2026 — les démos officielles mettent en avant les gains, pas les pertes.
La question des agents AI
Au-delà des AI Overviews dans la SERP, la vision de Google — telle que décrite par Sundar Pichai — est celle d'agents AI qui interagissent avec les sites. La question de la visibilité dans ces agents est encore plus opaque que celle des AIOs.
Les rapports AI Search dans Search Console pourraient évoluer vers un tracking des interactions agents (Gemini, Google Assistant avancé) avec votre contenu. Mais pour l'instant, on n'en est pas là. Le test actuel se limite à l'AI Search dans la SERP.
Parallèlement, des initiatives comme le Agent Readiness Score de Cloudflare montrent que l'écosystème se structure pour mesurer la compatibilité des sites avec les agents AI. Les rapports Google s'inscrivent dans cette tendance plus large.
Actions immédiates : que faire maintenant
Le rapport n'est pas encore disponible globalement. Mais vous pouvez vous préparer.
1. Auditer votre visibilité AI actuelle
Avant d'avoir les données officielles, établissez votre baseline. Utilisez Screaming Frog pour exporter la liste de vos pages indexées avec leurs requêtes principales (via l'intégration Search Console de Screaming Frog), puis croisez manuellement un échantillon de 50-100 requêtes avec les SERPs réelles pour identifier la présence d'AIOs.
2. Structurer votre pipeline de données
Préparez vos tables BigQuery / votre dashboard Looker Studio pour accueillir une nouvelle dimension "search_type = ai_search". Si vous utilisez un outil de monitoring SEO comme Seogard, vérifiez qu'il peut ingérer et segmenter les nouvelles métriques dès leur disponibilité API — la détection de régressions sur le CTR AI sera aussi critique que la surveillance des meta ou des canonicals.
3. Cartographier vos contenus par vulnérabilité AI
Classez vos pages en trois buckets :
- Haute vulnérabilité : contenu informationnel pur, réponse facilement synthétisable par un LLM (définitions, comparatifs simples, FAQ)
- Vulnérabilité moyenne : contenu mixte info/transactionnel, partiellement substituable
- Faible vulnérabilité : contenu transactionnel, expérientiel, ou nécessitant une interaction (configurateur produit, outil interactif, contenu communautaire)
Cette cartographie vous permettra de réagir rapidement dès que les données AI Search seront disponibles. Au lieu de découvrir la cannibalisation, vous l'aurez anticipée.
4. Surveiller les régressions de balisage structuré
Si le balisage structuré influence la citation dans les AIOs, une régression silencieuse (schema.org cassé après un déploiement, données structurées invalidées après une migration de CMS) peut faire disparaître vos pages des AI Overviews sans que vous le remarquiez. Ce type de casse arrive constamment — les migrations de framework sont un terrain miné pour les meta et les données structurées.
Ce test est un point d'inflexion, pas une feature
Google ne teste pas un nouveau bouton dans Search Console. Il commence à rendre mesurable ce qui était jusqu'ici une boîte noire. Les équipes SEO qui auront préparé leur infrastructure de données, cartographié leur vulnérabilité AI, et adapté leur stratégie de contenu seront celles qui transformeront ces métriques en avantage concurrentiel. Les autres découvriront l'ampleur de la cannibalisation six mois trop tard. Un outil de monitoring continu comme Seogard, configuré pour alerter sur les variations de CTR AI vs. CTR organique dès que l'API le permettra, fera la différence entre réaction et anticipation.