Google Discover est devenu la première source de trafic des médias français, loin devant la recherche organique. Pourtant, les mécanismes qui décident quels articles apparaissent dans le flux restent largement opaques. Metehan Yesilyurt, chercheur spécialisé en SEO et en search, a publié fin février 2026 une analyse technique détaillée fondée sur l’observation du code côté client de l’application Google sur Android. Sans accès aux serveurs ni aux algorithmes de classement, ce travail reconstitue le parcours complet qu’un contenu doit emprunter avant d’apparaître (ou non) dans le flux personnalisé ou, comme le dit le chercheur lui-même :
C’est comme lire l’étiquette nutritionnelle sur un aliment emballé. On ne voit pas l’usine, mais l’étiquette en dit long sur ce qu’il y a à l’intérieur.
9 étapes entre le crawl et l’affichage dans le flux Discover
L’analyse met en évidence un pipeline structuré en neuf étapes successives, chacune laissant des traces observables dans le code de l’application :
- Crawl et indexation du contenu par Google,
- Extraction d’entités : les sujets sont rattachés à des identifiants du Knowledge Graph,
- Analyse des métadonnées de la page (titre, auteur, image, langue),
- Classification du contenu en catégories (clusters),
- Filtrage au niveau de l’éditeur et de l’URL,
- Correspondance avec les centres d’intérêt de l’utilisateur ou l’utilisatrice,
- Classement côté serveur (non observable depuis le client),
- Construction et affichage du flux,
- Collecte des interactions (clics, rejets, abonnements).
L’enseignement principal réside dans l’ordonnancement de ces étapes. Le filtrage éditeur (étape 5) intervient avant la correspondance avec les intérêts et le classement. Cela signifie donc qu’un média bloqué à ce stade ne parvient jamais jusqu’à l’algorithme de ranking, quelle que soit la pertinence de ses articles pour un lecteur donné.
Schema.org passe avant Open Graph dans la lecture des balises
L’une des découvertes les plus concrètes de cette analyse concerne l’ordre dans lequel Discover lit les métadonnées d’une page. Contrairement à une idée répandue, ce ne sont pas les balises Open Graph qui sont consultées en priorité, mais les données structurées Schema.org au format JSON-LD. L’ordre de lecture observé dans le code est le suivant : Schema.org d’abord, puis og:title, puis twitter:title, puis les balises HTML génériques. Cette hiérarchie fonctionne comme une chaîne de repli. Ainsi, si le champ est renseigné en JSON-LD, les balises OG correspondantes ne sont jamais atteintes.
En pratique, un site dont les données structurées seraient mal configurées pourrait voir Discover afficher des informations erronées, même si ses balises Open Graph sont correctement remplies. Autre point notable : deux balises meta spécifiques (notranslate et nopagereadaloud) provoquent un arrêt complet du traitement de la page. Les sites dont le CMS ou un plugin de traduction injecte l’une de ces balises risquent donc d’être exclus du pipeline sans le savoir.
Schema.org, Open Graph, Twitter Cards : de quoi parle-t-on ?
Un système de filtrage à deux niveaux, où un seul clic peut tout bloquer
L’analyse du code par Metehan Yesilyurt révèle une architecture de filtrage qui opère sur deux niveaux distincts. Le premier, dit « collection », agit au niveau du domaine entier. Lorsqu’un nombre suffisant d’utilisateurs et d’utilisatrices choisissent l’option « Ne plus afficher ce média » dans leur flux, l’ensemble des contenus du site peut être supprimé de Discover. Le second niveau, dit « entity », cible une URL spécifique. Dans les deux cas, le contenu écarté est marqué comme définitivement rejeté (un mécanisme que le code désigne sous le terme de « tombstoning »). Il ne réapparaîtra pas.
L’asymétrie du système mérite d’être soulignée. Un utilisateur ou une utilisatrice peut bloquer un domaine entier d’un seul geste, mais il n’existe aucun mécanisme symétrique permettant de « booster » globalement un éditeur. Un article générant des réactions négatives peut donc avoir des conséquences bien au-delà de sa propre visibilité, en pénalisant l’ensemble du média. Ce constat renforce l’importance de la qualité éditoriale à l’échelle du site, pas uniquement article par article.
NAIADES, le système de personnalisation au cœur du flux
L’analyse identifie un système interne baptisé NAIADES, responsable de la personnalisation du flux Discover. Celui-ci s’appuie sur plusieurs types de signaux pour faire correspondre un contenu aux intérêts d’un utilisateur : les sujets consultés, l’historique de recherche et un signal éditeur désigné sous l’acronyme WPAS, qui semble lié à l’inscription au Google News Publisher Center (sans confirmation côté serveur à ce stade, nous apprend l’étude).
Côté classement, le titre joue un rôle central. Selon l’analyse, il est extrait, sérialisé et transmis aux serveurs de Google, où il alimente un modèle de prédiction du taux de clic (pCTR). La qualité de l’image et le degré de « clickbait » perçu entrent également dans ce calcul. Metehan Yesilyurt a d’ailleurs développé un outil open source qui tente d’estimer le CTR potentiel d’un titre sur Discover, en croisant plusieurs dimensions de qualité avec une pénalité pour les formulations trop racoleuses. Le calibrage exact de cet outil n’est toutefois pas documenté. Ces observations rejoignent les priorités affichées par Google lors de sa récente Core Update dédiée à Discover, qui vise notamment à limiter la visibilité des contenus sensationnalistes.
7 jours pour exister dans le flux Discover
Le code fait apparaître un système de classification de la fraîcheur découpé en plusieurs paliers. Sans que les seuils exacts soient documentés, l’analyse suggère que la fenêtre de visibilité d’un article dans Discover se joue principalement dans les premiers jours suivant sa publication, avec une décroissance marquée au-delà de sept jours. Cette mécanique de fraîcheur n’exclut pas la remontée ponctuelle de contenus plus anciens (comme l’a observé Virginie Clève dans ses travaux sur Discover), mais elle confirme que la récence reste un facteur déterminant dans la construction du flux.
Ce que vous lisez ici est un instantané, pas un plan permanent. Considérez-le comme une grille de lecture sur le fonctionnement actuel de ces systèmes, pas comme une garantie sur leur fonctionnement futur, prévient Metehan Yesilyurt.
Dernière précision, et pas des moindres : comme expliqué ci-dessus, cette analyse repose sur un instantané du code client à un moment donné. Google peut modifier ses systèmes côté serveur sans mise à jour de l’application. Les seuils de blocage, les poids exacts des signaux de classement et les critères de décision internes restent hors de portée de ce type d’observation. Ce travail éclaire la mécanique du pipeline, pas les réglages précis de l’algorithme.
FAL Group