Google Discover 2026 : les 9 étapes du pipeline de classement selon Metehan Yeşilyurt

L'Essentiel :

Google Discover fonctionne comme un pipeline en neuf étapes, dont plusieurs sont des portes binaires : admissible ou non. La démarche de Metehan Yeşilyurt, qui observe les traces côté client Android plutôt que de spéculer sur le serveur, permet de reconstituer ce déroulé. Résultat : certaines étapes sont des filtres qui coupent la route avant même d'évaluer la qualité du contenu. Comprendre cette hiérarchie change la façon d'optimiser pour Discover.

La méthode : regarder le client, pas fantasmer le serveur

Avant d'entrer dans les neuf étapes, un détour s'impose pour comprendre la méthodologie mise en place par Metehan Yeşilyurt pour son analyse du pipeline de Google Discover. Un SDK (Software Development Kit) est une boîte à outils logicielle embarquée dans les applications Android - dont l'application Google. Ce que Metehan Yeşilyurt fait dans son analyse, ce n'est pas pirater Discover. Il observe ce que le système déclare : noms d'événements, compteurs de télémétrie, structures de métadonnées, paramètres de feature flags. Ces traces existent parce que l'équipe produit a besoin de diagnostiquer, tester et itérer.

La limite est claire : le modèle de ranking principal et la logique serveur restent invisibles. Mais l'architecture côté client suffit souvent à comprendre le déroulé - les étapes, les filtres, l'ordre des opérations, les variables qui remontent. C'est suffisant pour agir.

Étape 1 - Eligibility : la porte la plus sous-estimée

Certains signaux peuvent arrêter le pipeline très tôt. Metehan cite notamment des balises du type notranslate et nopagereadaloud qui peuvent bloquer certains flux de traitement. Ce n'est pas le genre d'optimisation qui améliore un score. C'est du binaire : admissible ou non.

Sur le terrain, cela signifie qu'on peut se faire éliminer avant même d'être évalué - souvent à cause d'un plugin, d'un template hérité, ou d'une directive ajoutée sans y penser. Un audit HTML à froid, régulier, fait partie de l'hygiène de base.

Étape 2 - Fetch et Preprocess : les erreurs techniques comptent avant tout

Discover ne lit pas ton article comme un humain. Il le récupère, le normalise, extrait ce dont il a besoin. À ce stade, les problèmes techniques font perdre la partie : contenu instable, images cassées, redirections multiples, timeouts. Metehan insiste sur les mécanismes de préchargement et de mise à jour - autant de signaux que la page doit être techniquement irréprochable à tout moment.

Étape 3 - Metadata extraction : l'Open Graph comme objet éditorial

L'un des apports les plus concrets de l'analyse est la place des métadonnées Open Graph. Le client parse un ensemble réduit de tags, et og:title et og:image ne sont pas de simples étiquettes d'affichage. Ces champs sont extraits et envoyés dans un payload qui nourrit probablement un modèle de pCTR (predicted click-through rate).

Conséquence directe : le og:title n'est pas un duplicat automatique du H1. L'image OG n'est pas une vignette "au hasard". C'est un couple titre-image qui joue directement sur la décision de clic dans le flux.

Étape 4 - Visual quality gate : l'image comme filtre, pas comme déco

Discover est un flux visuel. Metehan évoque des signaux de qualité d'image, des dimensions, des flags "low quality", et des seuils qui conditionnent le format de carte. Le point important n'est pas "mettre une grande image" - c'est de comprendre qu'il existe une porte : certaines images font passer en carte riche, d'autres dégradent en format pauvre, d'autres disqualifient.

Concrètement, cela signifie standardiser les dimensions sur tout le site, choisir des visuels lisibles en petit, et bannir les images floues ou trop "template".

Étape 5 - Collection-level gate : le couperet avant le matching

C'est l'élément le plus surprenant de l'analyse. Metehan décrit un filtre au niveau publisher appliqué avant le matching d'intérêt, avant le pCTR, avant le ranking. Si vous êtes filtré ici, Google ne se demande même pas si votre contenu correspond à l'utilisateur.

L'idée d'asymétrie est centrale : une pénalité globale peut être déclenchée plus facilement qu'un boost global. L'objectif n'est donc pas "faire un carton une fois", c'est éviter de générer des rejets répétés. Dans un flux, le rejet se paie au niveau du domaine, pas seulement de l'URL.

Étape 6 - Interest matching : être lisible thématiquement par la machine

Une fois dans la course, Discover cherche à estimer si le contenu correspond aux intérêts de l'utilisateur, en s'appuyant sur des entités et des catégories liées au Knowledge Graph. C'est un rappel utile pour les éditeurs : Discover n'est pas une SERP. C'est une recommandation personnalisée.

Cela pousse vers la cohérence des clusters thématiques, la récurrence des entités, et un maillage interne qui raconte une ligne éditoriale plutôt qu'une collection d'articles isolés. C'est l'un des aspects où travailler son maillage interne a un impact direct sur la distribution dans Discover.

Étape 7 - Freshness weighting : la fenêtre des 7 premiers jours

Metehan parle de buckets de fraîcheur : un poids maximal sur les 7 premiers jours, puis une perte progressive jusqu'à 30 jours, puis une décroissance continue mesurée en heures. Discover aime le neuf, structurellement.

En pratique, cela signifie que la publication n'est pas un geste unique - c'est une séquence. Les 48 à 72 premières heures sont le moment où concentrer les signaux positifs : newsletter, push, social, mise en avant sur la home. Si un article est fragile, le forcer pendant cette fenêtre peut coûter plus cher qu'un non-événement, en termes de réputation de domaine.

Étape 8 - pCTR & ranking : le titre comme levier de classement

Le pCTR (predicted Click-Through Rate) apparaît comme une brique clé. Si og:title est injecté dans les métadonnées et utilisé par un modèle de clic, alors le titre devient un levier de ranking, pas seulement un emballage. Le piège serait la sur-optimisation : dans un flux, le pire scénario est un clic déçu. Les signaux post-clic comptent autant que le pCTR lui-même. Pour évaluer la qualité de vos title et savoir si elles vont performer dans la plateforme, Metehan a d'ailleurs vibe codé un outil que je trouve très intéressant et que je vous invite à tester, le Discover pCTR Predictor.

Étape 9 - Feedback memory : la mémoire du rejet

La dernière étape transforme Discover en système d'apprentissage continu. Metehan évoque des "tombstones" : des enregistrements persistants côté appareil qui marquent des contenus dismissés, potentiellement de manière irréversible à l'échelle de l'utilisateur. Si quelqu'un a dit non, le système évite de re-proposer.

Conséquence : on n'optimise pas Discover seulement pour être vu, on l'optimise pour être accepté. Un site Discover-friendly ressemble à un média qui a compris son lecteur - pas à un site qui court après un pic de trafic.

Ce qu'il faut retenir sans s'illusionner

La force de l'analyse de Metehan Yeşilyurt est de forcer à penser Discover comme un pipeline, pas comme un oracle. Il y a des portes techniques. Il y a des portes de réputation. Il y a des étapes de matching et de scoring. Et il y a une mémoire du feedback.

Si vous ne deviez garder qu'un réflexe : traitez Discover comme un produit de recommandation. Vous ne cherchez pas seulement à "être classé". Vous cherchez à être proposé, cliqué, puis validé. C'est précisément là que les éditeurs se trompent. Ils veulent la visibilité, mais ne prennent pas au sérieux le coût du rejet.