Google Discover décompilé : ce que le SDK Android révèle sur l'algorithme

Quelqu'un a décompilé l'application Google Android. 87 498 classes Java, 13 fichiers DEX, et des mois de travail de désobfuscation plus tard, Metehan Yesilyurt a publié ce qui ressemble à la première radiographie sérieuse du pipeline client-side de Google Discover.

Ce n'est pas une théorie. C'est du code.

Le fonctionnement interne de Google (Discover)

La plupart des guides sur Discover s'arrêtent à une recette basique :

"Produisez du contenu de qualité, soignez vos images, ciblez les bons sujets."

C'est vrai, mais incomplet.

Ce que l'analyse du SDK Google révèle sur le fonctionnement de Discover, c'est qu'il existe une seconde couche de décision, entièrement côté client, qui peut tuer votre SEO sans que le serveur ne soit jamais au courant.

En réalité, le pipeline Discover se déroule en 8 étapes

La première, l'ingestion, est celle que tout le monde connaît. Google crawle, indexe, extrait les entités du Knowledge Graph.

Après, vient le parsing des métadonnées structurées, puis la classification en catégories, puis le filtrage à deux niveaux, puis le matching avec le profil d'intérêts de l'utilisateur via le système NAIADES, puis le classement côté serveur, puis l'assemblage du feed, et enfin la boucle de rétroaction basée sur les interactions.

Ce qui est frappant, c'est l'ordre.

Le filtre de collection, celui qui bloque un domaine entier, s'exécute avant le matching d'intérêts et avant le ranking. Un éditeur bloqué au niveau collection n'atteint jamais l'étape de classement, quelle que soit la pertinence de son contenu pour l'utilisateur. C'est le même type de logique de filtration en amont qu'on observe dans les nouvelles règles de stratégie SEO 2026 : l'algorithme élimine avant de classer.

Les priorités dans le SEO sur Discover

JSON-LD d'abord, OG tags ensuite, et c'est câblé en dur

Voilà ce qui devrait faire changer les priorités de beaucoup d'équipes SEO. La classe de parsing du SDK (dkpg.java) révèle une chaîne de fallback précise et non modifiable pour chaque champ.

Pour l'optimisation du titre, l'ordre est le suivant. Schema.org JSON-LD en premier.

Si ce dernier est absent, og:title. Si absent, twitter:title. Si absent, attribut title générique. Pour l'auteur et l'éditeur, même logique. Le JSON-LD prime sur tout.

Pour l'optimisation des images, la chaîne est différente puisqu'il n'y a pas de JSON-LD image dans cette hiérarchie. Le SDK cherche og:image, puis twitter:image, puis og:image:secure_url, puis twitter:image:src, puis un attribut générique image. Five levels deep, le système cherche vraiment à trouver une image, ce qui confirme son poids dans la décision d'affichage.

La conclusion pratique est directe. Si vous n'avez implémenté que des OG tags sans balisage JSON-LD, vous utilisez le chemin de secours.

Le SDK passera par votre og:title uniquement parce que le champ JSON-LD est vide. Ce n'est pas une catastrophe, mais ce n'est pas la voie principale. On retrouve cette logique de hiérarchisation dans notre analyse des balises meta SEO : ce que vous ne déclarez pas explicitement, Google l'interprète à sa façon.

Les 2 balises qui peuvent tuer votre SEO sur Google Discover

Si votre site est mal optimisé SEO et qu'une page présente l'une de ces 2 balises meta, le comportement du SDK sera radical. Elles ne dégradent pas le parsing, elles l'interrompent complètement via une exception dans dkri.java.

Quand l'une ou l'autre est détectée, le système lève une erreur et arrête de traiter la page. Si votre CMS ou votre plugin de traduction injecte notranslate en tant que balise meta, votre contenu peut sortir entièrement du pipeline de parsing, sans alerte, sans signal dans la Search Console.

C'est le type d'information qu'on ne trouve pas dans la documentation officielle.

Auditez IMPERATIVEMENT vos templates dans vos CMS Woocommerce, Prestashop, et Shopify. Si vous ne savez pas comment faire, contactez-nous.

Important : le "tombstoning", quand un contenu est marqué mort pour toujours

Quand un utilisateur appuie sur "Ne plus voir ce contenu", le contenu est tombstoné de façon permanente.

Qu'est-ce que le tombstoning ?

Le tombstoning est un mécanisme de filtrage binaire et local au SDK Android de Google qui consiste à supprimer instantanément de l'affichage un article pourtant validé par le serveur, dès lors que celui-ci échoue à des tests de conformité techniques ou contextuels spécifiques sur l'appareil de l'utilisateur, comme une résolution d'image insuffisante, une redondance avec le contenu déjà vu ou un signal de sécurité négatif.

La classe bska.java documente un mécanisme appelé tombstoning. Un contenu tombstoné porte un flag booléen dans son objet d'état, accompagné d'un stallState, d'un lastKnownState (INSERTED, REMOVED, UNKNOWN) et d'un flag purged. C'est un cycle de vie complet enregistré côté client.

Les conséquences d'un tombstoning

Lorsqu'un contenu a été tombstoné, il ne revient pas. Ce qui est plus intéressant et plus problématique pour les éditeurs, c'est ce qu'il se passe à l'échelle du domaine. Le filtre de collection (filter_collection_status) opère au niveau éditeur. Un article qui génère suffisamment de feedback négatif peut déclencher un filtrage qui s'applique à l'ensemble du domaine, pas seulement à l'URL incriminée.

L'analyse du code source révèle également un autre mécanisme : le background_refresh_rug_pull_count. Le feed peut injecter du contenu et le retirer ensuite lors d'un refresh en arrière-plan. Discover n'est pas un snapshot statique. C'est un flux vivant qui peut vous effacer rétroactivement. Ce phénomène s'inscrit dans la dynamique plus large d'enshittification de Google, une dégratation volontaire de Google dans des mécanismes opaques qui pénalisent les éditeurs sans recours visible.

NAIADES et le signal WPAS

Pourquoi vous devez vous inscrire à Publisher Center ?

Pour Google Discover, le système de personnalisation s'appelle NAIADES, et ses sous-types sont énumérés dans fiqc.java. On y trouve notamment deux signaux directement actionnables.

Signal 1 : La personnalisation NAIADES

Le premier signal est SUBTYPE_PERSONAL_UPDATE_MID_BASED_NAIADES (enum 793). Il indique une personnalisation basée sur les entités du Knowledge Graph. Concrètement, si votre contenu est bien associé à des MIDs (/m/xxxxx ou /g/xxxxx) reconnus, il a plus de chances d'être matché avec les profils d'intérêts des utilisateurs.

Signal 2 : Le Web Publisher Articles Siglan (WPAS)

Le second signal est SUBTYPE_PERSONAL_UPDATE_WPAS (enum 800). WPAS signifie Web Publisher Articles Signal. Son existence dans le code confirme que les éditeurs enregistrés sur Google News Publisher Center reçoivent une classification distincte dans le pipeline de personnalisation. Ce n'est pas un levier de ranking direct, c'est côté serveur et non observable, mais c'est un signal de catégorisation différent, avant même le ranking. Le RECALL_BOOST (enum 797) suggère quant à lui une priorité de récupération augmentée depuis le pool de candidats, avant le classement final.

Optimiser WPAS en tant qu'expert SEO 

Pour optimiser votre SEO sur Google Discover, par rapport aux signaux WPAS et NAIADES, vous devrez impérativement déployer des images haute résolution, au minimum 1200px, et des balises Open Graph parfaitement structurées pour valider l'évaluation de qualité technique calculée par le moteur NAIADES. En complément, vous devrez optimiser l'impact visuel et la diversité thématique de vos contenus pour maximiser le signal WPAS.

Cela garantira ainsi que vos articles de blog conservent leur ranking lors de l'arbitrage final du layout (et la composition esthétique du flux sur le smartphone de l'utilisateur).

Les 13 catégories pour vos feed cards

Chaque "carte du feed" appartient à une catégorie. L'analyse en identifie 13.

Les plus significatifs pour les éditeurs sont neoncluster (la catégorie principal), mustntmiss (une file prioritaire pour le contenu jugé essentiel), deeptrends et deeptrendsfable (narratifs de tendances), garamondrelatedarticlegrouping (regroupements d'articles liés sous un même fil thématique) et geotargetingstories (contenu géolocalisé).

mustntmiss est particulièrement révélateur. Il confirme l'existence d'une file de priorité absolue, un segment du feed que le système considère comme incontournable pour l'utilisateur. Les critères de classification SEO dans ces catégories ne sont pas observables depuis le client, mais son existence change la façon de penser la concurrence dans le feed. C'est d'ailleurs un angle que notre approche du GEO et SEO on-site travaille en parallèle : être présent dans les signaux de pertinence entité avant même la requête.

Le système Beacon et l'avantage structurel du sport

Il existe un canal push dans Discover. Le système Beacon permet aux serveurs de Google de pousser du contenu directement sur l'appareil, sans attendre une requête de l'utilisateur. Mais selon le code de bqmt.java, ce canal ne supporte aujourd'hui que deux types de contenu. Les scores sportifs et les récapitulatifs financiers. Tout le reste déclenche une erreur "Unsupported BeaconContent type".

Les éditeurs sportifs bénéficient de plus de dix types de notifications dédiées (SPORTS_AWARENESS_NOTIF, SPORTS_BREAKING_NEWS_NOTIF, SPORTS_LIVE_ACTIVITY_NOTIF, etc.) contre un seul type pour les breaking news générales. Ce n'est pas une nuance. C'est une infrastructure notificationnelle disproportionnée qui donne aux contenus sport un accès privilégié au push en temps réel.

Ce que le "article:content_tier" fait vraiment

Le code de dkri.java reconnaît exactement trois valeurs pour cette balise. "free" (le défaut, considéré comme accessible), "metered" (compte comme paywallé) et "locked" (idem). Si la valeur est absente, le système part du principe que le contenu est libre.

Ce qui est moins documenté, c'est le warning explicite dans le code. Si plusieurs valeurs article:content_tier sont détectées sur la même page, ce qui peut arriver avec certains CMS ou plugins Schema, le système logue une erreur (code 38468). Une seule valeur, proprement déclarée. Pas deux.

4 quick wins à appliquer cette semaine

Voici ce que l'étude du code du SDK Google nous apporte sur des micro-actions à faire rapidement :

• Vérifiez que vos templates ne contiennent pas de balise notranslate en tant que meta tag, pas en attribut HTML, en balise meta. Auditez tous vos plugins de traduction. Vérifiez également l'unicité de votre article:content_tier : une seule valeur par page, point.
• Implémentez du JSON-LD Schema.org complet si ce n'est pas déjà fait, en priorisant les champs title, author et publisher. Vous passez du chemin de fallback au chemin prioritaire. Pour les images, vérifiez systématiquement qu'elles font au minimum 1200px de large. La chaîne de fallback image est longue, mais la taille reste un critère d'éligibilité au format "large card".
• Inscrivez-vous à Google News Publisher Center si ce n'est pas fait. Le signal WPAS crée une classification distincte dans NAIADES. Ce n'est pas une garantie de ranking, mais c'est une qualification différente dans le pipeline de personnalisation. C'est exactement le type d'action technique que notre accompagnement en référencement naturel intègre dès l'audit initial.
• Travaillez votre association aux entités du Knowledge Graph. Le sous-type MID-based de NAIADES confirme que le matching entre les entités de votre contenu et les InterestID des utilisateurs est un mécanisme central. Plus vos sujets sont clairement ancrés dans le graphe de connaissances de Google, plus le matching peut opérer.

Ce queça change pour votre stratégie Discover

L'analyse de Yesilyurt ne livre pas les pondérations du serveur. Elle ne dit pas ce qui fait ranker un contenu mieux qu'un autre parmi les candidats sélectionnés.

...Ce qu'elle fait, c'est exposer toutes les portes par lesquelles votre contenu peut sortir du pipeline avant même d'arriver à cette décision.

C'est un changement de perspective utile. Optimiser son SEO pour Discover, ce n'est pas seulement produire du contenu pertinent et espérer que l'algorithme serveur vous repère. C'est aussi auditer votre technique pour s'assurer que le client Android ne vous élimine pas silencieusement après que le serveur vous a déjà choisi.

Le SEO Discover a toujours eu deux parties. Maintenant, on sait à quoi ressemble la seconde. Et si on regardait ensemble ce que votre implémentation technique dit au SDK de Google ?