Google Discover dirige aujourd’hui une part majeure du trafic des médias, mais ses règles restent en grande partie invisibles. Une analyse de code côté client publiée début 2026 offre pourtant une fenêtre sur les mécanismes qui façonnent la sélection des articles : elle reconstitue un pipeline en neuf étapes, met en lumière des priorités inattendues dans la lecture des métadonnées et révèle un filtrage capable d’exclure définitivement des contenus. Pour les équipes éditoriales, ces informations ne sont pas de la théorie technique : elles expliquent pourquoi un article pertinent peut ne jamais atteindre un lecteur, ou pourquoi une image mal déclarée suffit à dégrader drastiquement la visibilité. Cet article retrace ces découvertes et en tire des conseils concrets pour l’optimisation des contenus, en gardant à l’esprit que l’observation porte sur le code client à un instant donné et que Google peut ajuster ses logiques côté serveur à tout moment. En lisant ces coulisses, on comprend mieux comment la recommandation et le machine learning se combinent pour produire un contenu personnalisé dans le flux d’information.
Comment Google Discover sélectionne les articles : les 9 étapes observées
L’analyse reconstitue un cheminement en neuf étapes : du crawl et de l’indexation initiale, à l’extraction d’entités liées au Knowledge Graph, en passant par l’analyse des métadonnées, la classification en clusters, puis un filtrage par éditeur et par URL avant la correspondance avec les centres d’intérêt, le classement côté serveur, la construction du flux et enfin la collecte des interactions utilisateur. Cet ordre est important car il conditionne l’accès même au processus de ranking : si un contenu est éliminé au stade du filtrage éditeur, il ne sera jamais évalué par l’algorithme de classement, quelle que soit sa pertinence pour un lecteur donné. Les équipes SEO et rédactionnelles doivent donc considérer chaque étape comme un point de contrôle opérationnel et non comme une simple formalité technique.
Insight : comprendre l’enchaînement des étapes permet de hiérarchiser les corrections et d’éviter de perdre du temps à optimiser des éléments qui ne seront pas lus.
Pourquoi l’ordre du filtrage peut coûter cher aux éditeurs
Le placement du filtre éditeur avant la correspondance avec les intérêts individuels signifie qu’une opération de blocage peut annuler la visibilité d’un site entier. Concrètement, un nombre suffisant d’utilisateurs qui cliquent sur « ne plus afficher ce média » active un mécanisme baptisé dans le code « tombstoning » : le domaine ou l’URL est marqué comme définitivement rejeté.
Pour illustrer, imaginez Aurélien, responsable numérique d’une petite rédaction. Un article accusé de sensationnalisme reçoit plusieurs rejets rapides ; le système de filtrage au niveau du domaine s’enclenche et la plupart des contenus du site quittent le flux. Aurélien ne voit pas d’erreur côté serveur : l’explication est bien dans ce chaînage client-side, et récupérer la visibilité exige une stratégie à l’échelle du site, pas seulement des corrections article par article. Insight : la réputation globale d’un média pèse autant que la qualité d’un article isolé.
Métadonnées et balises : pourquoi Schema.org prime sur Open Graph
La lecture des métadonnées par Discover suit une hiérarchie précise. Le code montre que les données structurées au format Schema.org (JSON-LD) sont consultées en priorité, puis viennent les balises Open Graph, ensuite les Twitter Cards et enfin les balises HTML classiques. Autrement dit, un champ renseigné en JSON-LD empêche souvent l’examen des balises og: correspondantes.
Deux balises particulières, notranslate et nopagereadaloud, ont un effet radical : leur présence stoppe le traitement de la page. Des CMS ou plugins de traduction qui injectent automatiquement ces meta tags peuvent donc faire disparaître des pages du pipeline sans que l’équipe éditoriale le sache immédiatement. Insight : la priorité accordée à Schema.org impose de vérifier en premier lieu le JSON-LD sur chaque page stratégique.
Comment vérifier et corriger vos balises pour le flux
Le problème courant est une configuration automatique de plugins qui produit un JSON-LD incomplet ou erroné, tandis que les balises Open Graph semblent correctes à l’œil. La méthode opérationnelle consiste à auditer le JSON-LD en production, corriger le titre, l’auteur et l’image déclarés, puis tester l’impact en surveillant le trafic Discover sur les jours suivants.
En pratique, soigner la déclaration des images dans le JSON-LD est crucial : la qualité de l’image est un signal exploité dans le calcul du pCTR remonté aux serveurs. Pour des ressources visuelles, suivez les bonnes pratiques de référencement des images afin d’éviter des pertes d’audience évitables. Insight : corriger le JSON-LD produit souvent des gains immédiats, là où d’autres optimisations prendraient plus de temps.
Filtrage à deux niveaux et personnalisation : le rôle de NAIADES
Le code met en lumière un filtrage distinct au niveau du domaine (« collection ») et au niveau de l’URL (« entity »). Les deux mécanismes implémentent un rejet permanent des contenus signalés, sans procédure d’appel visible côté client. La personnalisation du flux repose sur un composant interne nommé NAIADES, qui combine les sujets consultés, l’historique de recherche et un signal éditeur appelé WPAS, apparemment lié à l’inscription au Publisher Center.
Le titre joue un rôle central : il est extrait, sérialisé et envoyé pour alimenter un modèle de prédiction du taux de clic (pCTR). L’image, la fraîcheur et le degré de clickbait perçu influencent aussi ce score. Le code indique une fenêtre de visibilité marquée autour des premiers jours de publication, avec une décroissance notable au-delà d’une semaine, bien que des contenus plus anciens puissent parfois resurgir. Insight : la stratégie éditoriale doit intégrer la fraîcheur comme variable clé et soigner surtout titres et images dans les premières 48 à 72 heures.
Conséquences pratiques pour la stratégie éditoriale
Pour Aurélien et son équipe, cela signifie qu’il ne suffit pas d’optimiser un buzz ponctuel : la réputation du domaine, la cohérence des métadonnées et la qualité d’ensemble des publications conditionnent la présence dans le flux. Une seule page fortement rejetée peut déclencher un effet de domino sur l’ensemble du site, et il n’existe pas d’action rapide équivalente à un « boost » global pour compenser un tombstoning.
Concrètement, mettre en place une surveillance continue des signaux Discover, tester les titres via outils d’estimation de pCTR, et appliquer des corrections rapides sur le JSON-LD et les images sont des mesures prioritaires. Pour l’imagerie, reportez-vous aux recommandations pour optimiser vos images pour Google Discover afin de réduire les risques liés à une mauvaise déclaration ou à une qualité visuelle insuffisante. Insight : un plan d’action systématique, réactif et centré sur la réputation du domaine reste la meilleure défense contre une perte de visibilité.
