Inside Google Discover : 20 pipelines, 42M cards décryptés

Une analyse de trois mois de feeds Google Discover, documentée par Search Engine Land, révèle une architecture que peu de publishers soupçonnent : 20 pipelines distincts, 42 millions de cards observées, et des mécanismes de distribution qui n'ont rien à voir avec le ranking organique classique. Ce n'est pas un algorithme monolithique — c'est un système de broadcasting multi-canal où chaque pipeline obéit à ses propres règles de sélection et de promotion.

L'architecture pipeline : ce que révèlent les données

Google Discover n'est pas un flux unique. L'étude met en lumière une architecture modulaire où au moins 20 pipelines alimentent le feed utilisateur en parallèle. Chaque pipeline est spécialisé : actualités chaudes, tendances émergentes, vidéo, contenu evergreen, publicités natives, sports, météo, et des catégories plus granulaires encore.

Le point critique pour les publishers : votre contenu ne "rentre" pas dans Discover de manière uniforme. Il est candidat à un ou plusieurs pipelines, et chaque pipeline a son propre seuil de qualification, sa propre fréquence de rafraîchissement, et sa propre logique de scoring.

Les pipelines identifiés et leur comportement

Sur les 20 pipelines documentés, cinq concentrent l'essentiel du volume :

News/Breaking : rafraîchissement toutes les 2-5 minutes, durée de vie courte (< 24h), favorise les sources avec un historique E-E-A-T fort en actualité.
Trending Topics : alimenté par les signaux de Google Trends et les requêtes Search en spike, fenêtre de 6-48h.
Video : pipeline dédié au contenu vidéo (YouTube, mais aussi Web Stories et vidéos intégrées), scoring qui intègre le watch time estimé.
Evergreen/Interest : contenu non-daté, distribué sur des semaines ou mois, corrélé aux centres d'intérêt long-terme de l'utilisateur.
Ads : cartes sponsorisées, mêlées au contenu organique, environ 8-12% du volume total observé.

Les 15 autres pipelines couvrent des niches (recettes, shopping, sports scores, podcasts, etc.) et représentent individuellement un volume plus faible mais un CTR souvent supérieur, car le ciblage d'intérêt est plus précis.

Volume et distribution des 42 millions de cards

Le chiffre de 42 millions de cards sur trois mois de collecte est cohérent avec l'échelle de Discover. Google ne publie pas de chiffres officiels sur le nombre d'utilisateurs Discover, mais le rapport d'usage de Google Search Console confirme que Discover génère des volumes de trafic comparables — parfois supérieurs — au Search organique pour les sites éditoriaux.

La distribution n'est pas gaussienne. Une minorité de cards (~3%) capte plus de 60% des impressions totales. C'est un système winner-takes-most, similaire au PageRank mais appliqué au feed personnel. Un article qui performe dans le pipeline Trending Topics peut accumuler 500K impressions en 12h, puis disparaître complètement.

Pourquoi certains contenus obtiennent une visibilité broadcast

Le terme "broadcast-level visibility" est approprié. Contrairement au Search où l'utilisateur exprime une intention, Discover pousse le contenu vers l'utilisateur. Le mécanisme de sélection combine trois couches que les publishers peuvent influencer.

Couche 1 : Éligibilité technique

Avant tout scoring éditorial, Google vérifie des prérequis techniques stricts. Un contenu qui échoue à cette étape ne sera jamais candidat, quel que soit son intérêt éditorial.

Les critères documentés dans la documentation Google sur Discover incluent :

Page indexée dans Google Search (prérequis non négociable)
Conforme aux Content policies
Image de haute qualité : au minimum 1200px de large, activée via max-image-preview:large

Ce dernier point est un killer silencieux. Si vos meta robots ne l'autorisent pas explicitement, votre contenu est exclu de Discover :

<!-- Configuration minimale pour l'éligibilité Discover -->
<head>
  <meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1">
  
  <!-- Open Graph — utilisé par Discover pour la card preview -->
  <meta property="og:title" content="Titre optimisé pour le feed (60 chars max)">
  <meta property="og:description" content="Description engageante, 120-150 chars">
  <meta property="og:image" content="https://media.votresite.fr/articles/hero-image-1200x675.jpg">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="675">
  <meta property="og:type" content="article">
  
  <!-- Article structured data -->
  <meta property="article:published_time" content="2026-04-09T08:00:00+02:00">
  <meta property="article:modified_time" content="2026-04-09T08:00:00+02:00">
  <meta property="article:author" content="https://votresite.fr/auteurs/marie-dupont">
</head>

Un point que beaucoup ignorent : l'image OG doit être crawlable et accessible rapidement. Si votre CDN retourne un 302 temporaire ou un temps de réponse > 2s sur l'image, Discover peut sélectionner un fallback de moindre qualité — ou ignorer la card.

Couche 2 : Scoring d'engagement prédictif

Une fois éligible, le contenu est évalué par un modèle de scoring qui prédit l'engagement utilisateur. Ce scoring n'est pas le même que le ranking Search. Il intègre :

CTR prédictif basé sur le titre, l'image, et le topic match avec l'utilisateur
Engagement historique du domaine dans le pipeline concerné
Fraîcheur pondérée selon le pipeline (critique pour News, marginale pour Evergreen)
Entity matching entre le contenu et le profil d'intérêt de l'utilisateur (basé sur le Knowledge Graph)

Ce dernier point est fondamental et sous-exploité. Discover ne fonctionne pas par mots-clés. Il fonctionne par entités. Un article sur "la nouvelle politique de prix d'Apple" sera distribué aux utilisateurs dont le profil contient l'entité /m/0k8z (Apple Inc.) — pas aux utilisateurs qui ont cherché "prix iPhone" la veille.

Vous pouvez vérifier les entités associées à votre contenu via le Natural Language API de Google Cloud :

# Analyse d'entités sur le contenu d'un article
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://language.googleapis.com/v2/documents:analyzeEntities" \
  -d '{
    "document": {
      "type": "HTML",
      "content": "<html><body>'"$(curl -s https://votresite.fr/article-cible | python3 -c 'import sys,html; print(html.escape(sys.stdin.read()))')"'</body></html>",
      "languageCode": "fr"
    },
    "encodingType": "UTF8"
  }' | jq '.entities[] | select(.salience > 0.05) | {name, type, salience, metadata}'

Si les entités retournées ne correspondent pas aux entités que vous visez, votre contenu sera distribué au mauvais segment — ou pas distribué du tout. C'est l'équivalent Discover d'un keyword mismatch en Search, mais beaucoup plus difficile à diagnostiquer.

Couche 3 : Le boost pipeline

C'est l'insight le plus actionable de l'étude. Certains pipelines ont un effet multiplicateur sur la distribution. Le pipeline Trending Topics, par exemple, peut exposer un article à 10-50x plus d'utilisateurs que le pipeline Evergreen, parce qu'il cible un pool plus large (tous les utilisateurs intéressés par le topic en spike, pas seulement ceux avec un intérêt long-terme).

Pour les publishers, ça signifie qu'un article qui "attrape" le pipeline Trending au bon moment bénéficie d'une visibilité broadcast — comparable à une position Featured Snippet sur une requête à 500K recherches/jour, mais sans que l'utilisateur ait eu besoin de chercher quoi que ce soit.

Structured data et signaux techniques que Discover exploite

La documentation officielle reste volontairement vague sur les signaux exploités par Discover. Mais le croisement des données de l'étude avec les tests terrain révèle des patterns clairs.

Schema.org Article et NewsArticle

Le balisage NewsArticle est fortement corrélé à la sélection dans le pipeline News/Breaking. Ce n'est pas officiellement un facteur de ranking Discover, mais c'est un signal de classification de pipeline. Un article balisé NewsArticle avec une datePublished récente sera évalué prioritairement par le pipeline News.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Les 20 pipelines Google Discover révélés par 3 mois de données",
  "description": "Analyse technique des mécanismes de distribution de Google Discover.",
  "image": [
    {
      "@type": "ImageObject",
      "url": "https://media.votresite.fr/articles/discover-pipelines-hero.jpg",
      "width": 1200,
      "height": 675
    },
    {
      "@type": "ImageObject",
      "url": "https://media.votresite.fr/articles/discover-pipelines-square.jpg",
      "width": 1200,
      "height": 1200
    }
  ],
  "datePublished": "2026-04-09T08:00:00+02:00",
  "dateModified": "2026-04-09T08:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Marie Dupont",
    "url": "https://votresite.fr/auteurs/marie-dupont",
    "sameAs": [
      "https://twitter.com/mariedupont",
      "https://www.linkedin.com/in/mariedupont"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "VotreSite",
    "logo": {
      "@type": "ImageObject",
      "url": "https://votresite.fr/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://votresite.fr/articles/google-discover-pipelines"
  },
  "isAccessibleForFree": true
}
</script>

Trois détails qui comptent :

Plusieurs formats d'image : Discover utilise des formats de card différents selon le pipeline et le device. Fournir un format 16:9 ET un format 1:1 maximise les chances d'obtenir la large card (qui génère un CTR 2-3x supérieur).
isAccessibleForFree: true : pour les sites avec paywall, ce signal détermine si Discover affiche la card avec l'indicateur "free" ou "paywall". Les cards free ont un CTR significativement supérieur.
Author sameAs : les liens vers les profils sociaux de l'auteur alimentent le Knowledge Graph author entity. Un auteur reconnu comme entité par Google bénéficie d'un boost E-E-A-T mesurable dans Discover.

Headers HTTP pour le contrôle du cache Discover

Un aspect rarement documenté : Discover respecte — partiellement — les directives de cache HTTP pour déterminer la fraîcheur d'un contenu. Un article avec un Cache-Control: max-age=86400 sera réévalué moins fréquemment qu'un article avec max-age=3600.

Pour du contenu actualité que vous voulez voir distribué rapidement dans le pipeline News :

# Nginx — Configuration pour les articles actualité
location ~ ^/articles/actu/ {
    add_header Cache-Control "public, max-age=1800, s-maxage=300";
    add_header X-Robots-Tag "max-image-preview:large, max-snippet:-1";
    
    # Priorité au crawl rapide via IndexNow
    # Notification Bing + Yandex en webhook post-publication
}

# Articles evergreen — cache plus long, Discover réévalue moins souvent
location ~ ^/articles/guides/ {
    add_header Cache-Control "public, max-age=604800, s-maxage=86400";
    add_header X-Robots-Tag "max-image-preview:large, max-snippet:-1";
}

Ce n'est pas un levier direct de ranking, mais ça influence la fréquence de réévaluation du contenu par les pipelines Discover, et donc la réactivité de la distribution.

Scénario concret : un média en ligne de 8 000 pages

Prenons le cas d'un média tech francophone — 8 000 articles publiés, 40-60 nouveaux articles/semaine, équipe de 6 rédacteurs. Trafic mensuel : 2,5M sessions dont 35% via Discover (875K sessions/mois).

Le problème

Après une refonte frontend (migration de WordPress vers un headless CMS basé sur Next.js), le trafic Discover chute de 35% en 10 jours. Les impressions Search Console Discover passent de 12M/mois à 7,8M. Le CTR reste stable (~7,2%), donc le problème est côté distribution, pas côté engagement.

Le diagnostic

L'équipe technique vérifie les points suivants :

1. Meta robots — L'audit Screaming Frog révèle que le nouveau template article n'inclut plus max-image-preview:large. La directive par défaut est nosnippet (hérité d'un composant SEO copié d'un autre projet).

2. Images OG — Le nouveau composant next/image sert les images en WebP avec lazy loading. Problème : le crawler Discover accède à l'URL OG image et reçoit un placeholder blur de 32px. L'image pleine résolution n'est servie qu'après exécution JavaScript côté client.

3. Structured data — Le schéma NewsArticle a été remplacé par Article lors de la migration. Le pipeline News ne classe plus le contenu correctement.

4. Temps de réponse — Le passage au headless CMS a introduit une API call côté serveur qui ajoute 800ms au TTFB. Discover favorise les pages qui répondent vite — le seuil observé empiriquement est < 1.2s TTFB.

La correction

// next.config.ts — Correction des headers pour Discover
const nextConfig = {
  async headers() {
    return [
      {
        source: '/articles/:slug*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1'
          },
          {
            key: 'Cache-Control',
            value: 'public, max-age=1800, s-maxage=300, stale-while-revalidate=3600'
          }
        ]
      }
    ];
  },
  images: {
    // Forcer le serving d'images OG en format accessible sans JS
    unoptimized: false,
    domains: ['media.votremedia.fr'],
  }
};

export default nextConfig;

// components/ArticleSEO.tsx — Correction du schema et de l'image OG
import Head from 'next/head';

interface ArticleSEOProps {
  article: {
    title: string;
    excerpt: string;
    heroImage: string; // URL directe, pas optimized
    publishedAt: string;
    modifiedAt: string;
    author: { name: string; url: string; socials: string[] };
    isNews: boolean;
  };
}

export function ArticleSEO({ article }: ArticleSEOProps) {
  // Distinction Article vs NewsArticle selon la catégorie
  const schemaType = article.isNews ? 'NewsArticle' : 'Article';
  
  // Image OG : URL directe vers le CDN, pas via next/image
  // Discover doit pouvoir accéder à l'image sans exécuter JS
  const ogImageUrl = `${article.heroImage}?w=1200&h=675&fit=crop&auto=format`;
  const ogImageSquare = `${article.heroImage}?w=1200&h=1200&fit=crop&auto=format`;

  const schema = {
    '@context': 'https://schema.org',
    '@type': schemaType,
    headline: article.title,
    description: article.excerpt,
    image: [
      { '@type': 'ImageObject', url: ogImageUrl, width: 1200, height: 675 },
      { '@type': 'ImageObject', url: ogImageSquare, width: 1200, height: 1200 }
    ],
    datePublished: article.publishedAt,
    dateModified: article.modifiedAt,
    author: {
      '@type': 'Person',
      name: article.author.name,
      url: article.author.url,
      sameAs: article.author.socials
    },
    isAccessibleForFree: true
  };

  return (
    <Head>
      <meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1" />
      <meta property="og:image" content={ogImageUrl} />
      <meta property="og:image:width" content="1200" />
      <meta property="og:image:height" content="675" />
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
      />
    </Head>
  );
}

Le résultat

Après déploiement des corrections :

J+3 : les impressions Discover remontent de 7,8M à 9,5M (le pipeline News recommence à distribuer)
J+7 : retour à 11,2M d'impressions (95% du niveau pré-migration)
J+14 : stabilisation à 12,6M — supérieur au niveau initial, grâce à la double image (16:9 + 1:1) qui a augmenté le taux de sélection en large card

Le trafic Discover perdu représentait ~300K sessions/mois pendant 10 jours, soit un manque à gagner estimé à 45K€ en revenus publicitaires pour ce média. Une régression de ce type, silencieuse dans les métriques Search classiques, n'est détectable que par un monitoring dédié du rapport Discover dans Search Console — ou par un outil de monitoring comme Seogard qui alerte automatiquement quand les meta robots ou les structured data changent sur un template critique.

Stratégie pipeline-aware : optimiser pour le bon canal

Comprendre l'existence des pipelines change la stratégie éditoriale. Vous ne publiez plus "pour Discover" en général — vous ciblez un pipeline spécifique.

Pipeline News/Breaking : la course au timing

Ce pipeline valorise la vélocité. Le premier publisher à couvrir un sujet en spike a un avantage disproportionné. L'étude montre que les 2-3 premières sources indexées sur un topic en trending captent 70%+ des impressions du pipeline.

Implications pratiques :

Configurez des alertes Google Trends en temps réel sur vos verticales
Réduisez le time-to-index : utilisez l'API d'indexation Google pour les contenus éligibles (pages avec schema NewsArticle ou JobPosting)
Pré-produisez des templates pour les événements prévisibles (keynotes Apple, résultats trimestriels, élections)

Le rapport Discover de Search Console, combiné à l'API Search Console, vous permet de mesurer précisément quels articles ont capté du trafic pipeline News vs Evergreen, en corrélant datePublished et la courbe d'impressions.

Pipeline Evergreen/Interest : le jeu long

Ce pipeline est plus intéressant pour le ROI long-terme. Un article evergreen qui entre dans ce pipeline peut générer du trafic Discover pendant des mois, avec des résurgences périodiques.

Les signaux clés pour ce pipeline :

Contenu approfondi (> 2000 mots) avec des entités clairement définies
Mise à jour régulière de dateModified (pas du thin content statique)
Engagement signal fort : les articles qui génèrent du temps de lecture élevé et peu de pogo-sticking sont redistribués

Un piège courant : la tentation de republier un article avec une nouvelle datePublished pour le rendre "frais". Google a spécifiquement adressé ce problème — les articles dont le contenu n'a pas substantiellement changé mais dont la date a été mise à jour sont pénalisés dans Discover. Le contenu dupliqué déguisé en mise à jour est un anti-pattern dangereux.

Pipeline Video : le levier sous-exploité

Le pipeline vidéo est le moins saturé et offre le meilleur ratio effort/visibilité pour les publishers qui ne sont pas des pure players vidéo. L'étude montre que les articles contenant une vidéo intégrée (pas seulement un lien YouTube) ont 2,4x plus de chances d'être sélectionnés par ce pipeline.

Le balisage VideoObject dans le structured data est le signal technique déclencheur :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Comment fonctionnent les pipelines Google Discover",
  "description": "Explication technique des 20 pipelines de distribution Discover",
  "thumbnailUrl": "https://media.votresite.fr/videos/discover-thumb.jpg",
  "uploadDate": "2026-04-09T08:00:00+02:00",
  "duration": "PT4M30S",
  "contentUrl": "https://media.votresite.fr/videos/discover-pipelines.mp4",
  "embedUrl": "https://www.youtube.com/embed/XXXXX"
}
</script>

Monitoring et détection des régressions Discover

Le rapport Discover de Search Console est votre première ligne de défense, mais il a des limites : données disponibles avec 48-72h de retard, pas de segmentation par pipeline, pas d'alerte automatique.

Automatiser la surveillance

Les rapports Search Console que la plupart des équipes ignorent incluent justement les données Discover. Mais pour un monitoring proactif, vous devez aller plus loin.

Un script de surveillance basique via l'API Search Console :

# discover_monitor.py — Alerte si les impressions Discover chutent de > 20%
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
from datetime import datetime, timedelta
import statistics

creds = Credentials.from_authorized_user_file('credentials.json')
service = build('searchconsole', 'v1', credentials=creds)

site_url = 'sc-domain:votresite.fr'

def get_discover_data(start_date, end_date):
    response = service.searchanalytics().query(
        siteUrl=site_url,
        body={
            'startDate': start_date,
            'endDate': end_date,
            'dimensions': ['date'],
            'type': 'discover',  # Clé : filtrer sur le type Discover
            'rowLimit': 1000
        }
    ).execute()
    return response.get('rows', [])

# Comparer les 7 derniers jours vs les 7 jours précédents
today = datetime.now()
recent = get_discover_data(
    (today - timedelta(days=9)).strftime('%Y-%m-%d'),
    (today - timedelta(days=3)).strftime('%Y-%m-%d')  # 48h de délai
)
previous = get_discover_data(
    (today - timedelta(days=16)).strftime('%Y-%m-%d'),
    (today - timedelta(days=10)).strftime('%Y-%m-%d')
)

recent_impressions = sum(r['impressions'] for r in recent)
previous_impressions = sum(r['impressions'] for r in previous)

if previous_impressions > 0:
    change_pct = ((recent_impressions - previous_impressions) / previous_impressions) * 100
    if change_pct < -20:
        print(f"⚠️ ALERTE: Impressions Discover en baisse de {change_pct:.1f}%")
        print(f"   Période récente: {recent_impressions:,} impressions")
        print(f"   Période précédente: {previous_impressions:,} impressions")
        # Déclencher notification Slack/email ici
    else:
        print(f"✓ Discover stable: {change_pct:+.1f}% ({recent_impressions:,} impressions)")

Ce script détecte les chutes globales, mais pas les causes. Pour identifier si la régression vient d'un changement technique (meta robots, structured data, image OG), vous avez besoin d'un monitoring qui audite en continu les templates critiques et corrèle les changements techniques avec les variations de trafic Discover.

Les signaux d'alerte à surveiller

En s'appuyant sur les KPIs techniques pertinents pour le SEO, voici les métriques spécifiques Discover à monitorer :

Impressions/jour par top 50 URLs Discover (chute > 30% = investigation immédiate)
CTR moyen par type de contenu (si le CTR chute mais les impressions sont stables, c'est un problème de card preview, pas de distribution)
Ratio large card / standard card : non disponible directement dans l'API, mais déductible des variations de CTR par article
Temps de réponse des images OG : un CDN lent tue la qualité de la card

Les équipes qui automatisent leurs checks SEO dans le CI/CD ont un avantage structurel : chaque déploiement vérifie que les meta robots, structured data, et images OG sont conformes aux exigences Discover avant la mise en production.

L'impact des product feeds et du contenu AI sur Discover

L'étude révèle un pipeline Discover dédié au contenu shopping/product, ce qui confirme que les product feeds nécessitent une stratégie organique — Discover est un canal de distribution directe pour les fiches produit, pas seulement pour le contenu éditorial.

Pour les e-commerce, le pipeline shopping Discover sélectionne des produits basés sur l'historique d'intérêt de l'utilisateur, mais aussi sur les signaux de prix (promotions, baisses de prix détectées via le Merchant Center). C'est un levier de trafic gratuit que la plupart des e-commerce ignorent complètement.

Quant au contenu généré automatiquement, l'étude ne montre pas de pénalité spécifique Discover pour le contenu AI — mais le scoring d'engagement prédictif défavorise naturellement le contenu générique. Un article AI qui n'apporte pas d'angle original sera scoré faiblement par le modèle de CTR prédictif et ne passera jamais le seuil de distribution des pipelines à fort volume.

Ce que ça change pour votre stratégie

Ces données confirment que Discover n'est pas un bonus aléatoire — c'est un canal de distribution structuré, avec des règles techniques précises et des leviers d'optimisation mesurables. Les publishers qui traitent Discover comme un canal à part entière (avec ses propres KPIs, ses propres templates optimisés, et son propre monitoring) captent une part disproportionnée du trafic.

L'insight le plus actionable de cette analyse : arrêtez de penser "mon article est-il bon pour Discover ?" et commencez à penser "quel pipeline vais-je cibler, et ai-je les prérequis techniques pour y être éligible ?". La différence entre un article à 5K impressions et un article à 500K impressions, c'est souvent une directive meta robots manquante, une image OG mal servie, ou un schéma Article au lieu de NewsArticle. Des régressions techniques silencieuses que seul un monitoring continu — via Seogard ou un équivalent — peut détecter avant qu'elles ne coûtent des dizaines de milliers d'euros de trafic perdu.