Google Discover, décodé

Si Discover est un immense journal avec de nombreux kiosques de distribution, Content est le principal. Environ un article sur trois en France entre dans Discover par ce pipeline. C'est là que la plupart des articles éditoriaux atterrissent en premier avant d'être éventuellement amplifiés par d'autres pipelines.

Moonstone est le pipeline avec la plus grosse portée en France. Une fois qu'un article y est sélectionné, il est diffusé à une énorme audience. Le hic : il favorise fortement les sites avec un long historique de fort engagement, ce qui explique pourquoi un seul acteur régional (Ouest-France) capte la majorité de son volume.

Un pipeline centré sur les tests produits, bons plans, guides cadeaux et inspirations shopping. Les articles y ont une durée de vie inhabituellement longue — 3-4 jours contre quelques heures pour la breaking news — parce que l'intention d'achat dure. Excellent pipeline pour les sites affiliés et les magazines e-commerce.

Feedads est le pipeline pubs/contenus sponsorisés. Il est presque totalement isolé des pipelines éditoriaux : 99,8 % des URLs qui passent par Feedads n'apparaissent nulle part ailleurs dans Discover. Les éditeurs éditoriaux interagissent rarement avec lui directement.

Le rôle d'Aura est d'injecter de la diversité dans le flux — faire remonter des articles longs et bien documentés qui complètent le flot du breaking news. Il récompense la profondeur, la narration et la recherche plutôt que la vélocité de la breaking news.

Mustntmiss est le pipeline 'à ne pas manquer' de Discover — Google marque certains articles comme lectures essentielles sur un sujet et double leur priorité. Une fois qu'un article entre dans Mustntmiss, sa visibilité double environ par rapport à un placement Content standard.

Le pipeline breaking news. L'article médian sur ce pipeline a 2,2 heures — en standards Discover, c'est quasiment du temps réel. Près de la moitié de son contenu n'apparaît nulle part ailleurs, ce qui en fait un canal pur breaking news.

Creatorcontent fait remonter du contenu lié à l'activité sociale — principalement des posts X/Twitter en France (75 % de ses sources). Il a explosé ×33 en 3 mois, reflet du pari de Google sur le contenu créateur. Un site sans présence X active renonce à une part croissante du trafic Discover.

Astria a une propriété inhabituelle : il ne fait pas remonter les articles immédiatement — le délai médian entre publication et exposition est de 1,5 jour. Cela en fait un pipeline 'second souffle'. Les articles qui n'ont pas pris au jour 1 peuvent trouver une seconde vie via Astria au jour 2-3.

Fait remonter les histoires géographiquement pertinentes pour l'endroit où se trouve l'utilisateur. Un accident de la circulation à Toulouse ne remonte qu'aux utilisateurs à Toulouse ou à proximité via ce pipeline.

Le pipeline dédié à la presse régionale. Deux tiers de son contenu lui sont uniques. Les médias nationaux n'y apparaissent quasiment jamais — c'est le terrain de jeu des quotidiens régionaux (Ouest-France, La Voix du Nord, Sud Ouest, etc.).

Derrière les carrousels 'Top stories' et widgets Showcase, ce pipeline regroupe plusieurs articles qui couvrent le même événement. Être inclus dans un tel groupe amplifie massivement le trafic.

Quand un utilisateur a déjà cliqué un de tes articles, Relatedcontentruby s'active pour lui en proposer d'autres sur des sujets similaires. C'est comme ça qu'un seul carton peut multiplier tes visites — bonne raison de publier des clusters thématiques cohérents.

Plus un utilisateur scrolle profondément dans son flux Discover, plus ce pipeline s'active pour remplir le slate. Son volume a fait ×7 en 3 mois, signal que Google s'appuie de plus en plus sur les utilisateurs engagés pour consommer plus de contenu par session.

Le pipeline dédié au contenu vidéo (principalement diffusions YouTube). Massif sur le marché anglophone (13 % de portée) mais à peine présent en France (~36 hits en 3 mois = niveau bruit). Pour les éditeurs FR, la vidéo n'est pas un levier Discover prioritaire.

Système de détection en deux étapes. Deeptrendsfable repère qu'un sujet commence à tendance (pic soudain de requêtes, mentions, partages sociaux). Deeptrends prend ensuite le relais pour continuer à l'amplifier tant que la tendance persiste.

Une architecture spécialisée où le serveur Google pousse activement des notifications sans attendre que l'utilisateur ouvre le flux Discover. Limité aux scores sportifs en direct et récaps de marchés financiers pour l'instant.

La toute première étape. Le crawler Google récupère l'URL, lit le HTML et extrait chaque entité qu'il reconnaît (personnes, lieux, marques, événements). Chaque entité est associée à un identifiant Knowledge Graph (MID). Les sites dans Google News sont crawlés en quelques minutes ; les autres attendent 1-24 heures.

Le SDK Google App contient une classe explicitement nommée SchemaOrg{parsedMetatags, jsonLdScripts}. La décompilation a révélé que quand le JSON-LD est présent, il SUPPLANTE ce qu'Open Graph ou Twitter Card déclarent. La plupart des guides SEO se sont trompés pendant des années — ils conseillaient d'optimiser OG, mais Discover priorise JSON-LD.

Le code de Google App confirme 13 types de clusters. Ton article n'est pas tagué 'actu tech' — il est tagué avec une combinaison d'IDs de clusters internes (moonstone-cluster, neoncluster, content-cluster, etc.). Un article peut chevaucher plusieurs clusters à la fois. C'est comme ça qu'un même article peut être amplifié par plusieurs pipelines.

L'étape brutale. Deux filtres tournent : 'collection' filtre au niveau du domaine (site entier blacklisté ? out), 'entity' filtre au niveau de l'URL (cet article spécifique viole une politique ? out). Cette étape tourne AVANT le ranking, donc un site blacklisté n'est même pas évalué pour la pertinence — il est déjà exclu.

La couche personnalisation. NAIADES regarde : qui est cet utilisateur (ses embeddings — Nephesh, Picasso, VanGogh), avec quels sujets il a engagé (MID-based), ce qu'il a cherché récemment (Query-based), de quoi parle sa session courante. Puis associe les articles aux utilisateurs avec un fort alignement.

Le scoring proprement dit. Se passe entièrement sur les serveurs Google et reste l'étape la plus opaque. Ce qu'on sait : il est fortement informé par les signaux comportementaux de NavBoost (clics, temps passé, pogo-sticking) plus les signaux qualité des étapes 1-2 (qualité des données structurées, cohérence d'entités) et le matching de personnalisation de l'étape 5.

Révélation critique de la décompilation du SDK : quand tu scrolles Discover, tu ne parcours pas une liste de cartes pré-calculée. Le flux est un stream gRPC, assemblé en continu pendant que tu scrolles. Les cartes peuvent être insérées, rétrogradées ou retirées en temps réel selon ce que tu fais.

La boucle de fermeture. Chaque action que tu fais (clic, swipe pour fermer, 'ne plus afficher ça', partage, dwell long) revient dans le système. Le contenu dismissed est 'tombstoned' à vie pour cet utilisateur. NavBoost intègre la nouvelle donnée comportementale et ajuste les scores au niveau du site. La boucle tourne en temps réel — en quelques secondes.

Si tu ne dois retenir qu'un seul nom technique de ce glossaire, c'est celui-là. NavBoost surveille chaque clic, temps passé, scroll, pogo-stick et partage — principalement via Chrome — et rescore en continu sites et articles. Sur Discover (contrairement au SEO classique), les effets NavBoost sont instantanés : un mauvais article est coupé en quelques heures.

NAIADES est la couche qui décide 'cet article doit-il être montré à CET utilisateur spécifique'. NavBoost dit à quel point un article est 'bon' en général ; NAIADES dit s'il est pertinent pour toi spécifiquement. Il utilise 7 sous-types — MID-based (entités qui t'intéressent), Query-based (recherches récentes), WPAS (statut publisher), RECALL_BOOST, AIM Thread et d'autres.

Vois le Knowledge Graph comme le grand fichier d'index de Google : chaque personne, lieu, marque, événement notable a sa propre fiche avec un identifiant unique (MID). Discover utilise cet index pour comprendre de quoi parle VRAIMENT ton article — pas juste les mots-clés. Plus ton article mentionne d'entités correctement reconnues, mieux Discover peut le matcher avec la bonne audience.

Chaque entité du Knowledge Graph a un MID — son 'numéro de sécurité sociale' dans les systèmes Google. Apple Inc. = /m/0k8z. Tim Cook = /m/0gxhdx. Quand ton article résout correctement vers des entités avec des MIDs stables, Discover indexe ces MIDs aux côtés de ton URL et route le trafic en conséquence.

Quand ton article dit 'Apple', Google doit décider : quelle Apple ? Le fruit, l'entreprise, le label musical, une personne spécifique ? L'entity linking est l'algorithme qui résout cette ambiguïté à partir du contexte, puis attache le bon MID. Une dénomination incohérente nuit à l'entity linking.

SAFT est le système interne Google qui fait tourner l'extraction d'entités à grande échelle sur tout le web. Il gère la résolution de coréférence ('il' → 'Tim Cook'), l'extraction de relations ('a fondé' entre 'Steve Jobs' et 'Apple'), et alimente tout ça dans le Knowledge Graph.

Un 'twiddler' est un petit module de re-ranking qui prend la liste de résultats déjà scorée et applique des ajustements de dernière minute (booster certaines fraîcheurs, rétrograder les doublons, imposer des quotas de diversité). Discover en chaîne plusieurs. Leur effet est faible par twiddler mais cumulatif.

Si Google juge que ton titre ne correspond pas à ce que l'article délivre vraiment, Goldmine peut le réécrire à la volée pour l'affichage dans les cartes search/Discover — à partir de ton H1, og:title, headline JSON-LD, voire un texte synthétisé. Une divergence entre H1 et Title augmente le risque que Goldmine te réécrive (souvent mal).

Nephesh est la représentation 'qui tu es' la plus profonde, la moins mobile. Elle se construit sur des mois à partir de ton comportement sur tous les produits Google et bouge rarement de manière dramatique. Quand tu te connectes sur un appareil tout neuf, Nephesh te 'connaît' déjà — c'est pour ça que ton flux Discover est personnalisé dès le jour 1.

Picasso tourne en batch (toutes les quelques heures / jours) et synthétise deux signaux complémentaires : STAT (Short-Term Affinity Track, quelques semaines) et LTAT (Long-Term Affinity Track, quelques mois). Plus mobile que Nephesh mais toujours bien plus lent que ta session courante.

VanGogh tourne SUR TON TÉLÉPHONE en temps réel. Au fur et à mesure que tu ouvres, scrolles, cliques, swipes dans la session courante, VanGogh se met à jour en quelques secondes. C'est ce qui rend Discover réactif : tu dismisses deux articles clickbait → le slate suivant s'éloigne déjà du clickbait.

Tout comme Nephesh embedde un utilisateur, Site2vec embedde un site. C'est l'empreinte mathématique du sujet global de ton site. Discover compare Site2vec(ton site) à des user embeddings pour décider de l'affinité au niveau site, et au Site2vec d'autres sites pour repérer concurrents et chevauchements.

Calculé à partir de Site2vec, ce score répond : 'à quel point le contenu de ce site est-il regroupé autour d'un thème cohérent ?'. Un site avec un focus clair (ex. magazine vélo) score haut. Un site d'actu généraliste score plus bas. SiteFocusScore élevé = Discover fait confiance au site comme autorité sur sa niche.

La contrepartie de SiteFocusScore. SiteRadius mesure À QUELLE DISTANCE tes articles dérivent du centroïde de ton site. Petit rayon = discipline thématique stricte ; grand rayon = contenu éparpillé. Discover pénalise les sites à grand rayon parce qu'ils ont l'air opportunistes.

Si tu as récemment lu des articles tagués /m/0k8z (Apple Inc.), le scoring MID-based remonte d'autres articles tagués avec le même MID pour toi. C'est pour ça que ton flux Discover devient 'collant' sur les entités qui t'intéressent — une fois qu'Apple est dans ton actif MID, des cartes Apple continuent de remonter.

Ton flux Discover réagit à ce que tu as cherché dans Search. Tu as cherché 'meilleures machines à expresso à moins de 500 €' hier ? Du contenu expresso remonte dans Discover aujourd'hui. La fenêtre est courte (quelques jours) mais l'effet est fort — le 'follow-up surfacing' est l'un des mécanismes les plus fiables de Discover.

Si ton site est enregistré (et approuvé) au Google Publisher Center, WPAS donne à chacun de tes articles un boost faible mais persistant dans la distribution. Inscription gratuite, ~10 minutes, élève matériellement ton plafond de distribution. Que la plupart des éditeurs hors presse l'ignorent reste un mystère.

Au moment où Discover assemble ton slate, il pioche dans un énorme pool d'articles candidats. RECALL_BOOST augmente la probabilité qu'un article spécifique soit tiré dans le set candidats au départ. Exposition plus précoce et plus large que ce que NavBoost seul justifierait.

AIM signifie Affinity-Interest Modelling. Un AIM Thread est un 'fil' thématique que tu tires — disons que tu suis la Coupe du monde sur plusieurs sessions. NAIADES persiste ce fil entre les sessions et fait remonter du contenu de suite même plusieurs jours plus tard, avant que le sujet ne remonte naturellement de tes autres signaux.

Le signal précoce le plus important. Discover montre ta carte à une petite audience d'abord ; si le CTR est élevé (~7-12 % en France), l'article est amplifié. En-dessous de ~3 %, la distribution est coupée rapidement. La combinaison titre-image fait 80 % du CTR — soigne-les ou rien d'autre ne compte.

Si un utilisateur reste 90+ secondes sur ton article, NavBoost lit ça comme 'le titre a tenu'. S'il rebondit en 8 secondes, c'est 'sur-vendu/clickbait'. Le dwell time est plus dur à fausser que le CTR — même le trafic bot peine à imiter les patterns de lecture réels.

L'utilisateur clique ta carte, voit la page, retourne immédiatement à Discover. C'est un pogo-stick. C'est le pire genre de clic — Google SAIT maintenant que le titre a sur-vendu et que l'utilisateur est énervé. Même un seul pogo-stick est mauvais ; un taux élevé tue la distribution en minutes.

Google catégorise les clics en 'longs' (l'utilisateur a eu sa réponse) ou 'courts' (il est revenu chercher mieux). Discover combine ça avec le dwell time et le pogo-stick pour scorer la satisfaction. Les sites avec un fort ratio long-click sont systématiquement promus.

Discover instrumente cette séquence d'événement très finement. La latence entre 'arrivée sur l'article' et 'retour' est l'un des proxies de qualité les plus propres disponibles — bien plus dur à truquer que le CTR ou les pageviews.

Si les utilisateurs lâchent constamment à 30 %, c'est signe que la lede perd du temps avant d'arriver à la valeur. S'ils scrollent à 90 %+, tu as réussi la structure. Les articles longs avec un faible scroll depth sont un drapeau rouge Discover.

Quand un utilisateur clique 'Ne plus afficher ça' ou 'Pas intéressé par ce site', Discover inscrit un marqueur permanent contre cette combinaison. Le contenu (ou le site entier) n'apparaîtra plus jamais dans le flux de cet utilisateur. Per-user, mais irréversible au niveau utilisateur.

Si tu publies un article, obtiens de la distribution, puis modifies ou retires l'article d'une manière qui casse la promesse initiale (ex. paywall après coup, redirection vers du contenu pub-lourd), Discover compte ça comme un 'rug pull'. Les valeurs élevées corrèlent avec une fiabilité éditoriale faible et la distribution est rognée.

Vague 1 (~1000-5000 impressions) : la phase de test, audience restreinte, utilisée pour estimer CTR et dwell. Vague 2 (~50k-500k) : test élargi si les signaux sont bons. Vague 3 (1M+) : amplification massive — seuls ~5 % des articles l'atteignent. Cette exposition progressive est pourquoi les heures 0-2 après publication sont critiques.

Les trois signes vitaux que Google vérifie à chaque visite. En manquer un est un plafond dur sur la distribution Discover. Le standard est 'pass-rate ≥ 75 % des visites' — au moins 3 visiteurs sur 4 doivent atteindre les cibles.

LCP mesure quand l'image principale ou le plus gros bloc de texte devient visible. En-dessous de 2,5 s = l'utilisateur perçoit la page comme 'rapide'. Entre 2,5-4 s = médiocre. Au-dessus de 4 s = mauvais — les utilisateurs commencent à rebondir. L'image hero est généralement l'élément LCP sur un article Discover.

Somme de tous les shifts de mise en page inattendus. Vise < 0,1. Coupables fréquents : publicités qui chargent après le contenu principal (tout saute vers le bas), images sans width/height explicite, polices qui swappent. Mobile particulièrement pénalisant — une seule insertion pub peut faire péter ton CLS.

A remplacé FID en 2024. Mesure chaque interaction (taps, frappes clavier) sur toute la durée de vie de la page, puis prend la plus lente. En-dessous de 200 ms = réactif. Au-dessus de 500 ms = saccadé, JavaScript bloque le main thread. Les scripts pubs lourds sont le coupable n°1.

Le temps entre la requête utilisateur et l'arrivée du tout premier octet de HTML. En-dessous de 500 ms = bon. Au-dessus de 800 ms = ton serveur tire toute l'expérience vers le bas. Les hébergements mutualisés bon marché ont souvent TTFB > 1 s — ça rend à lui seul la performance Discover impossible.

Score composite qui combine LCP, CLS, INP, TBT, etc. Discover est mobile-first, donc le score desktop ne compte pas — seul le score mobile (4G lente, appareil moyen) compte. En-dessous de 70 = ta distribution est matériellement plafonnée, même si les CWV individuels passent.

Les évaluateurs qualité Google (humains) jugent le contenu sur ces quatre axes. Experience : l'auteur a-t-il vraiment vécu ça ? Expertise : est-il un expert reconnu ? Authoritativeness : le site a-t-il un track record sur le sujet ? Trustworthiness : est-ce précis et transparent ? E-E-A-T fort = distribution Discover soutenue. Faible = plafonné en Vague 1.

Si ton contenu peut affecter la santé, l'argent, la sécurité ou les décisions de vie d'une personne, Google applique une barre qualité bien plus haute. Les articles YMYL ont besoin d'auteurs vérifiés (Schema Person + bio + credentials), de sources réputées, et de disclaimers clairs. Le contenu YMYL bâclé est écrasé par les évaluateurs qualité ET HCS.

HCS a été intégré à l'algorithme principal en 2024. Il évalue si le contenu apporte une vraie valeur originale ou recrache juste ce qu'il y a déjà partout. Signal AU NIVEAU SITE : quelques pages thin peuvent tirer toute la distribution de ton site vers le bas, même sur tes bons articles. La récupération exige de retirer ou réécrire le contenu thin, pas seulement les nouvelles pages.

Active depuis mai 2024, appliquée agressivement. Cas classique : un grand site d'actu loue un sous-répertoire /coupons à une boîte d'affiliation. Google pénalise désormais ça — le contenu parasitaire est bloqué ET le site hôte se mange un coup de réputation.

L'astuce classique 'montrer du texte propre à Google, rediriger les humains vers du spam'. Le cloaking moderne est plus subtil — du JavaScript qui swappe le contenu selon le fingerprinting user-agent. Discover le détecte via la télémétrie Chrome (le DOM rendu chez les vrais utilisateurs ne matche pas ce que Googlebot a vu). Déclenche action manuelle et suspension Discover complète.

Quelques milliers de contractuels dans le monde. Ils n'affectent pas directement les rankings — leurs évaluations entraînent les modèles ML de Google. Le manuel rater (170+ pages, public) est la meilleure source sur ce que Google considère comme 'qualité'. Le lire est un avantage déloyal.

Quand l'un de tes articles devient un carton sur Discover, ton site entier en bénéficie temporairement — les autres articles voient un CTR plus haut, une remontée plus rapide, une distribution plus large. Le halo dure 7-21 jours. C'est pour ça que les éditeurs chassent 'un breakout par semaine' plus que 'une baseline régulière'.

Un petit bloc JSON dans ton <head> qui dit à Google exactement de quoi parle ta page, en format lisible par machine. Le SDK Google App a été décompilé et le parser priorise explicitement JSON-LD sur Open Graph et Twitter Card. Si ton JSON-LD dit une chose et ton og:title une autre, Discover fait confiance au JSON-LD.

Un vocabulaire partagé maintenu par Google, Microsoft, Yahoo et Yandex. Il définit des centaines de types (Article, Person, Recipe, Event, Product, etc.) et de propriétés (name, author, datePublished, etc.). Utilisé correctement, tous les grands moteurs de recherche comprennent ton contenu de la même manière.

Un sous-type spécialisé d'Article pour le contenu d'actualité à fort facteur temps. NewsArticle accepte dateline, printSection et d'autres propriétés journalistiques. Le parser Google App traite NewsArticle différemment d'Article générique — le préférant pour la distribution. Mais mal employé sur du contenu evergreen, il peut déclencher des rétrogradations.

Dans ton JSON-LD NewsArticle, l'auteur doit être un objet Person complet : name, url (page auteur), sameAs (Wikipedia, X, LinkedIn), jobTitle, knowsAbout. Une donnée auteur absente ou superficielle est la cause n°1 d'échec d'un article YMYL à percer dans Discover.

Le JSON-LD de chaque NewsArticle doit référencer ton site comme publisher Organization : name, url, logo (avec width/height explicite), sameAs (profils sociaux), foundingDate. C'est ce qui lie tes articles à une entité reconnue dans le Knowledge Graph et débloque les boosts type WPAS.

Dit à Google : cet article vit à /tech/iphone/test-iphone-16. Alimente le fil d'Ariane qui remplace parfois la ligne d'URL dans les cartes. Aide Google à comprendre la structure de catégories de ton site — alimente SiteFocusScore et SiteRadius.

Quand tu référencies une image dans un balisage Article, enveloppe-la en ImageObject avec dimensions explicites. Ça permet à Google de choisir le bon recadrage hero pour la carte Discover et accélère la mesure du LCP. Une URL d'image nue sans métadonnées laisse Google deviner.

Wikidata est l'épine dorsale de données structurées que Google utilise pour désambiguïser les entités. Ajouter des liens sameAs depuis ton Schema Person/Organization vers des Q-IDs Wikidata aide concrètement Google à résoudre tes entités et à t'attribuer un MID stable. Gratuit, domaine public, 15 minutes par entité.

Sans cette directive, ton image hero ne peut pas être utilisée comme vignette de carte Discover en grand format — Discover tombe sur un crop minuscule de 100x100 ou pas d'image du tout. La balise la plus oubliée sur les sites qui veulent percer dans Discover. Ajoute-la dans ton <meta name="robots"> aux côtés de index, follow.

Le visuel à plus fort effet de levier sur la page. Le minimum 1200×800 de Discover n'est pas négociable — en-dessous, l'image est encadrée de bandes et le CTR chute de 30-50 %. Le hero doit être original, net, émotionnellement engageant. Les photos stock sous-performent la photographie originale de 2-3× sur le CTR.

Les deux ratios qu'utilise Discover. 16:9 pour la majorité des cartes, 4:3 pour les emplacements compacts. Si ton image hero n'est pas déjà dans l'un de ces ratios, Google la recadre — souvent mal (en sortant le sujet du cadre). Produis ton hero en 16:9 (1344×756 ou plus) et tu contrôles ce qui reste visible.

Google détecte instantanément une photo stock ou une image repostée 100× via le hash d'image inversée. Les visuels originaux (ta propre photo, illustrations sur-mesure, prises produit) surperforment le stock de 2-3× sur le CTR — souvent d'un ordre de grandeur sur les sujets concurrentiels.

Le standard C2PA ajoute une balise d'origine cryptographique aux images, indiquant si elles viennent d'un appareil photo ou d'un générateur IA. Les champs IPTC peuvent aussi porter cette info. Discover ne bannit pas les images IA, mais une imagerie IA non divulguée présentée comme preuve photographique sur des sujets YMYL est signalée et rétrogradée.

Quand une page a plusieurs images candidates, le alt text aide Discover à choisir la plus pertinente. Reste descriptif (ce qu'il y a dans l'image) et thématiquement pertinent (utilise ton mot-clé cible naturellement). Le bourrage de mots-clés se retourne contre toi.

Il doit y avoir exactement un H1 par article, et il doit matcher le titre que les utilisateurs voient dans la carte Discover. Une divergence entre H1 et Title est l'un des déclencheurs Goldmine les plus fréquents — Google réécrit ton titre (mal) quand il ne peut pas lui faire confiance.

La copy à plus fort effet de levier sur toute la page. Discover l'affiche souvent tel quel, parfois tronqué à 70 caractères. Sweet spot : 50-65 caractères. Les 50 premiers caractères doivent contenir l'accroche curiosité parce que c'est ce qui survit à la troncature sur petit écran mobile.

Discover n'affiche la meta description que sur une fraction des cartes (surtout les grands formats). Ce n'est pas le levier principal, mais elle reste un arbitre pour la prédiction de CTR dans certains pipelines. Ne l'ignore pas, n'en fais pas une obsession non plus.

Construit à l'origine par Facebook pour le partage social. Le parseur Discover utilise og:* comme source SECONDAIRE, uniquement quand JSON-LD est absent ou incomplet. og:image est consulté pour l'image de carte quand il n'y a pas de Schema ImageObject. Garde og:* aligné avec JSON-LD pour éviter une réécriture Goldmine.

Utilisée par X/Twitter (et désormais le pipeline creatorcontent indirectement). Pour le ranking Discover, c'est le DERNIER fallback après JSON-LD et Open Graph. Mais ça vaut quand même le coup de la régler correctement parce que creatorcontent la lit spécifiquement quand les articles sont partagés sur X.

Déclarée via <link rel='canonical'>. Quand un même contenu vit sur plusieurs URLs (mobile/desktop, syndication, pagination), la canonique dit à Discover laquelle est LA bonne. Une canonique incohérente ou auto-canonique-puis-pas-auto est un moyen connu de fragmenter ton propre score NavBoost.

Inscription gratuite, ~10 minutes de setup. Les sites Publisher Center approuvés obtiennent : (1) le boost de personnalisation WPAS, (2) une latence de crawl en moins d'une minute vs 1-24 h pour les sites non enregistrés, (3) éligibilité à Google News. L'action à plus fort ROI pour tout site qui vise Discover.

Une API REST où tu POSTes une URL et Google la crawle en quelques minutes. Officiellement limitée aux types Schema JobPosting et BroadcastEvent — mais les éditeurs de news l'utilisent couramment comme voie rapide non officielle pour la breaking. À utiliser avec parcimonie : l'abus déclenche du throttling.

Un sitemap spécialisé qui signale 'ces URLs sont des news à fort facteur temps' à Googlebot. Les URLs dans news.xml sont crawlées en quelques minutes (vs heures pour sitemap.xml standard). 1000 URLs max, uniquement les articles de moins de 48 h. Ping Search Console à chaque mise à jour.

Souvent présenté à tort comme une solution miracle pour 'indexer plus vite' — mais Google a explicitement indiqué qu'il ignore les signaux IndexNow. Utile pour la visibilité Bing, neutre pour Discover. Plusieurs CDNs (Cloudflare) l'activent par défaut ; c'est OK, mais n'en attends pas d'effets Discover.

La combinaison dont Discover a besoin : index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1. Tout ce qui est plus restrictif (noindex, max-snippet:50) plafonne silencieusement ta distribution. Cause #1 du syndrome 'pourquoi mon site n'apparaît jamais dans Discover ?'.

Ressource limitée. Si ton site a 100k pages thin, Googlebot gaspille son budget dessus au lieu de crawler tes articles frais. Élague le bois mort (balise noindex sur les pages tag, archives paginées, etc.) pour concentrer le budget là où ça compte.

Gratuit, 5 minutes pour la vérification. L'onglet Discover spécifique n'apparaît qu'une fois que ton site a cumulé > 100 impressions Discover sur 16 mois — sa simple existence est un signal d'éligibilité. Tracke Discover séparément de Search.

Montre les impressions Discover totales, les clics, le CTR et la perf par article sur les 16 derniers mois. N'expose pas les pipelines ni les sous-types NAIADES — pour ça il te faut des outils tiers comme 1492.vision ou DiscoReady.

Un humain chez Google a examiné ton site et appliqué une pénalité pour une violation claire des règles (spam, texte caché, contenu piraté, abus de réputation de site). Visible dans Search Console > Actions manuelles. Nécessite une demande de réexamen pour être levée, souvent après remédiation concrète.

Le système lui-même a décidé de te rétrograder, aucune intervention humaine, aucune notification. Détectable uniquement par des chutes brutales et durables d'impressions Discover pendant que Search reste stable. Pour récupérer, il faut corriger le signal sous-jacent — le plus souvent des déclencheurs du Helpful Content System.

Google déploie 3 à 6 mises à jour nommées par an. Les Core Updates retunent le ranking ; les Spam Updates visent les violations. Les sites Discover peuvent perdre 70 %+ de distribution sur une seule update — bien plus volatile que sur Search. Le retour à la normale arrive rarement avant l'update suivante.

Hack controversé mais documenté : dans la première heure après publication, drive 100-300 clics directs aux apparences 'réelles' (notifs push, partages sociaux, CTAs internes au site). NavBoost lit l'engagement élevé en H1 et déclenche la Vague 2. Risque : la détection anti-fraude Google repère les patterns mécaniques. Plus la source est propre (vrais utilisateurs), plus c'est safe.

Construis une base d'abonnés push (OneSignal, Outpush). Dans les 30 minutes suivant la publication, push l'article vers ton audience chaude. Leurs clics comptent comme 'directs' dans NavBoost — même effet que le hack des clics directs mais 100 % légitime. Les sites avec 100k+ abonnés push peuvent auto-déclencher la Vague 2 de manière fiable.

L'algorithme Discover prend une 'décision instinctive' en H0-H2 sur la base des signaux Vague 1. Si CTR + dwell + scroll-depth sont tous bons, la Vague 2 se déclenche en moins de 90 minutes. S'ils sont médiocres, l'article est plafonné silencieusement. À partir de H2, la trajectoire est en grande partie verrouillée.

Les pics d'activité utilisateurs Discover varient selon les thématiques. Lifestyle / horoscope : 5h-7h heure FR. Tech / business : 8h-10h. Entertainment : 19h-22h. Publier dans la bonne fenêtre peut multiplier la Vague 1 par 5-10× et déclencher une Vague 2 qui ne serait jamais partie sinon. Levier sous-coté.

Des mises à jour de fond (nouvelles sections, chiffres rafraîchis, dates actualisées) sur un article déjà distribué peuvent déclencher un nouveau cycle Discover, avec le bénéfice de l'historique NavBoost de l'article. Les mises à jour cosmétiques (changer dateModified sans vrai changement de contenu) sont détectées et rétrogradées.

Nommé d'après une étude de cas notable. Quand un auteur a un profil solide et bien construit (Schema Person + bio + sameAs vers X/Wikipedia + historique de publication actif), chaque nouvel article qu'il signe bénéficie de l'autorité accumulée de l'auteur. Souvent un lift de 1,5-3× sur le CTR Vague 1.

Chaque site reconnu par Google comme entité publishing a un Google Web Profile à profile.google.com/cp/[id]. La présence de cette URL est la preuve la plus propre que ton domaine est dans l'index entité de Google. L'outil DiscoReady Profiler le récupère pour n'importe quel site en une seconde.

La plateforme sur laquelle tu lis ce glossaire. Outils gratuits (Profiler, Title Lab, Image Validator, Schema Auditor, Audit 1 min) + le Guide Premium dont est tiré ce glossaire.

La source dominante qui alimente le pipeline creatorcontent en France. Un site sans présence X active (un compte vérifié qui publie des URLs d'articles avec des hooks, accumule de l'engagement) renonce à une part croissante du trafic Discover.

Étude de cas de référence : fréquence de publication élevée, couverture thématique large, jamais clairement leader sur un pipeline donné. La stratégie volume fonctionne mais plafonne ton plafond par article — l'inverse du modèle de domination par pipeline d'Ouest-France.

Le cas de succès de référence dans le Discover francophone. Construit des verticales thématiques serrées (actu régionale, sport, lifestyle), chacune assez forte pour dominer son pipeline respectif. Capture la plus grosse part de Moonstone, Webkicklocalstories et Mustntmiss en France.

Une fois ton trafic Discover significatif (~100k visites/mois), passer d'AdSense à une régie spécialisée comme HBAgency génère typiquement 2-3× plus de revenu par millier d'impressions. Le levier de monétisation #1 pour les sites Discover FR.

Un SaaS français pour les notifications push navigateur/web. Fréquemment utilisé pour driver les 100-300 clics de la première heure qui déclenchent l'amplification Vague 2. Plus propre que l'injection mécanique de clics parce que les clics viennent de vrais abonnés opt-in.

Outil d'analytics tiers conçu spécifiquement pour Discover. Révèle dans quels pipelines (parmi les 20+) chacun de tes articles est entré, quelle est leur performance par pipeline et comment ça se compare aux concurrents. Autour de 200-500 €/mois — rentable au-delà de 100k visites Discover/mois.