Google Discover dostarcza treści setkom milionów użytkowników każdego dnia, ale jego wewnętrzna mechanika pozostaje w dużej mierze nieprzejrzysta. Większość porad SEO na temat Discover pochodzi z oficjalnej dokumentacji Google lub anegdotycznych obserwacji wydawców. W tym artykule przyjrzymy się innej perspektywie — temu, co możemy odkryć analizując telemetrię, konwencje nazewnictwa zdarzeń i kod po stronie klienta aplikacji Google.
Najważniejsze wnioski w pigułce
Priorytet danych strukturalnych:
- JSON-LD Schema.org ma pierwszeństwo przed tagami Open Graph — to utrwalona hierarchia w kodzie
- Tagi OG działają jako fallback, nie jako preferowane źródło danych
- System sprawdza pola w ściśle określonej kolejności: JSON-LD → OG → Twitter Cards → standardowe meta tagi
Dwupoziomowa architektura filtrowania:
- Filtr na poziomie wydawcy (collection level) blokuje całą domenę przed etapem rankingowym
- Filtr na poziomie pojedynczego URL (entity level) działa bardziej precyzyjnie
- Odrzucone treści otrzymują permanentną flagę tombstoned i nie wracają do feedu
System personalizacji NAIADES:
- Siedem potwierdzonych podtypów personalizacji, w tym bazujące na encjach Knowledge Graph
- Sygnał WPAS prawdopodobnie odpowiada za treści z zarejestrowanych wydawców w Google News Publisher Center
- RECALL_BOOST zwiększa priorytet pobierania treści jeszcze przed etapem rankingowym
Pipeline i optymalizacja:
- Paywalle wykrywane przez isAccessibleForFree (JSON-LD) i article:content_tier (OG)
- Meta tagi nopagereadaloud i notranslate całkowicie blokują przetwarzanie strony
- System Beacon aktywnie wypycha do urządzeń tylko wyniki sportowe i notowania giełdowe
Pipeline treści — od crawlingu do wyświetlenia
Discover przetwarza treści w kilku obserwowanych etapach, z których każdy pozostawia wyraźne ślady telemetryczne. Najpierw następuje crawling i indeksacja, podczas których Google przypisuje identyfikatory Knowledge Graph (MIDs w formacie /m/xxxxx lub /g/xxxxx) do rozpoznanych encji.
Następnie parser po stronie klienta wydobywa metadane strony zgodnie ze ścisłą hierarchią: JSON-LD Schema.org jest sprawdzane jako pierwsze, potem tagi Open Graph, następnie Twitter Cards, a na końcu ogólne meta tagi HTML. To nie jest preferencja — to zakodowana kolejność fallbacku. Jeśli JSON-LD zawiera dane pole, tagi OG dla tego pola w ogóle nie są sprawdzane.
Po parsowaniu treść trafia do klasyfikacji i przypisywana jest do typów klastrów w hierarchii feedu. Kluczowy moment następuje później — system działa na dwóch osobnych poziomach filtrowania: filter_collection_status (poziom wydawcy/domeny) i filter_entity_status (poziom pojedynczego URL). Oba są śledzone jako metryki Discover w ścieżce /client_streamz/android_gsa/discover/app_content/.
Dopiero po przejściu filtrów treść trafia do dopasowania z profilem użytkownika przez system personalizacji NAIADES. Ranking dzieje się po stronie serwera — kod klienta ujawnia tylko, jakie dane są pakowane i wysyłane, ale samych modeli rankingowych nie da się zaobserwować od strony urządzenia.
Warto zwrócić uwagę na kolejność tych kroków. Filtr na poziomie kolekcji działa przed dopasowaniem zainteresowań i rankingiem. Oznacza to, że wydawca zablokowany na poziomie kolekcji nigdy nie dociera do etapu rankingowego, niezależnie od tego, jak istotna mogłaby być jego treść dla konkretnego użytkownika.
Dane strukturalne i Open Graph — co faktycznie parsuje kod
Wydawcy często zastanawiają się, które meta tagi Discover rzeczywiście wykorzystuje. Zdekompilowana klasa parsera ujawnia dokładne tagi i ich hierarchię priorytetów. Kluczowe odkrycie: dane strukturalne Schema.org JSON-LD są sprawdzane jako pierwsze dla tytułu, autora i wydawcy — nie tagi Open Graph. Tagi OG są fallbackiem, co jest zakodowane w logice łańcucha zastępczego.
Dla tytułu system sprawdza kolejno: JSON-LD (TEXT_TYPE_TITLE), og:title, twitter:title, a na końcu standardowy tag title. W przypadku autora: JSON-LD (TEXT_TYPE_AUTHOR), potem atrybut name=“author”. Dla wydawcy: JSON-LD (TEXT_TYPE_PUBLISHER), następnie og:site_name.
Obrazy są obsługiwane inaczej — priorytet ma og:image, potem twitter:image, og:image:secure_url, twitter:image:src, i na końcu ogólny tag image. Język jest wykrywany najpierw przez mechanizm execution-based, potem sprawdzany jest og:locale, inLanguage z JSON-LD, a jeśli wszystko zawiedzie — system przyjmuje domyślnie “en” (pod warunkiem odpowiedniej flagi serwera).
System wykrywa paywalle w ścisłej kolejności: najpierw isAccessibleForFree (wartość boolean w JSON-LD, domyślnie true), potem article:content_tier, który rozpoznaje dokładnie trzy wartości: “free” (oczekiwany standard), “metered” (liczony jako paywall) oraz “locked” (również paywall). Jeśli na stronie znajduje się więcej niż jedna wartość article:content_tier, kod loguje ostrzeżenie z kodem zdarzenia 38468.
Dwa meta tagi całkowicie zatrzymują pipeline przetwarzania: nopagereadaloud wywołuje błąd DISALLOWED_FOR_READOUT, a notranslate — DISALLOWED_FOR_TRANSLATION. Jeśli Twój CMS lub wtyczka do tłumaczeń wstrzykuje notranslate jako meta tag, Twoje treści mogą w ogóle nie wejść do tego pipeline’u.
Filtrowanie treści — dwupoziomowa architektura blokowania
System filtrowania Discover działa na wielu poziomach, a każdy jest śledzony przez własną metrykę streamz specyficzną dla Discover. Poziom kolekcji (filter_collection_status) blokuje treści od wydawcy lub domeny. Poziom encji (filter_entity_status) blokuje pojedynczy URL. Oba są parametryzowane przez “reason” — powód blokady.
Gdy użytkownik wybiera „Nie pokazuj treści od [Wydawcy]" w menu karty, uruchamia to filtr na poziomie kolekcji. Pojedynczy artykuł, który wygeneruje wystarczająco dużo negatywnych sygnałów, może wyciszyć całą publikację. Ta reakcja dotyczy wszystkich treści z danej domeny, nie tylko artykułu wywołującego. Algorytm może rozszerzyć filtrowanie na poziomie wydawcy.
Ważne zastrzeżenie: to są liczniki telemetryczne po stronie klienta. Potwierdzają one istnienie mechanizmów filtrowania, ale dokładne progi po stronie serwera, mechanizmy naprawcze i sposób mapowania wartości “reason” na działania użytkowników nie są obserwowalne z poziomu klienta. Google może zmienić te konfiguracje w dowolnym momencie bez aktualizacji aplikacji.
Odrzucone treści są permanentnie rejestrowane z flagą boolean tombstoned w obiekcie stanu treści. Stan treści śledzi również stallState, lastKnownState (INSERTED/REMOVED/UNKNOWN) i purged — tworząc kompletny zapis cyklu życia. Treści oznaczone jako tombstoned nie wracają do powierzchni.
System personalizacji NAIADES i jego siedem podtypów
Kod ujawnia system personalizacji o nazwie NAIADES z wieloma podtypami treści, wszystkie potwierdzone jako wartości enum. SUBTYPE_PERSONAL_UPDATE_MID_BASED_NAIADES (793) sugeruje personalizację opartą na encjach z Knowledge Graph. SUBTYPE_PERSONAL_UPDATE_QUERY_BASED_NAIADES (792) działa w oparciu o zapytania wyszukiwania, z wariantem z persistentnym logowaniem (805).
SUBTYPE_PERSONAL_UPDATE_RECALL_BOOST (797) zwiększa priorytet pobierania z puli kandydatów, co oznacza wzmocnienie treści podczas retrieval, jeszcze przed rankingiem. SUBTYPE_PERSONAL_UPDATE_WPAS (800) to prawdopodobnie Web Publisher Articles Signal — sygnał odpowiadający rejestracji w Google News Publisher Center. Treści od zarejestrowanych wydawców otrzymują osobną klasyfikację w pipeline personalizacji. Istnieje też wariant z persistentnym logowaniem (811).
SUBTYPE_PERSONAL_UPDATE_AIM_THREAD_NAIADES (856) sugeruje personalizację opartą na wątkach AI Mode. Te podtypy to nazwy enum w systemie klasyfikacji treści. Potwierdzają istnienie kategorii, ale ile wagi niesie każdy podtyp w rankingu to decyzja po stronie serwera, której nie możemy zaobserwować.
Eksperymenty kontrfaktyczne i system Beacon
Discover prowadzi eksperymenty kontrfaktyczne. Kod potwierdza SHOW_SKIPPED_DUE_TO_COUNTERFACTUAL (wartość enum 16) — treści wstrzymane dla celów testów A/B, oraz VISIBILITY_REPRESSED_COUNTERFACTUAL — stan logowania Visual Element używany w aplikacji Google, który oznacza elementy celowo wyciszone do pomiaru eksperymentów.
Szczególnie interesujący jest licznik background_refresh_rug_pull_count, który śledzi przypadki, gdy treść została wypchana do feedu, a następnie usunięta podczas odświeżania w tle. Oznacza to, że Discover może wycofać treści, które były już w feedzie, nie tylko filtrować je przed wyświetleniem.
Większość treści Discover przychodzi przez żądania feed oparte na pull, ale istnieje też kanał push. System Beacon pozwala serwerom Google proaktywnie wypychać treści do urządzenia użytkownika. Z dekompilowanego kodu wynika, że Beacon obecnie obsługuje dokładnie dwa typy treści: wyniki sportowe (SportsScoreAmbientDataDocument) i notowania giełdowe (InvestmentRecapAmbientDataDocument). Cokolwiek innego wywołuje błąd “Unsupported BeaconContent type” i jest odrzucane.
Treści sportowe mają ponad 10 dedykowanych typów notyfikacji: SPORTS_AWARENESS_NOTIF, SPORTS_GAME_CRICKET_MILESTONE_NOTIF, SPORTS_BREAKING_NEWS_NOTIF, SPORTS_LIVE_ACTIVITY_NOTIF i więcej. Ogólne breaking news mają tylko jeden: BREAKING_NEWS_NOTIF. Strukturalna inwestycja w infrastrukturę notyfikacji sportowych jest znacząco większa.
Podsumowanie
Analiza telemetrii SDK Google Discover ujawnia, że to nie jest prosty system rekomendacji. To wielowarstwowa architektura z priorytetyzacją JSON-LD nad tagami OG, dwupoziomowym filtrowaniem na poziomie wydawcy i URL, oraz zaawansowanym systemem personalizacji NAIADES z siedmioma potwierdzonymi podtypami. Kluczowe jest zrozumienie, że filtr na poziomie kolekcji działa przed rankingiem — wydawca zablokowany tam nie dociera do etapu dopasowania z użytkownikiem. Permanentne tombstoning odrzuconych treści i możliwość wycofania już wyświetlonych materiałów przez rug pull pokazują, jak dynamicznie system zarządza jakością feedu.
Źródło: Metehan Yesilyurt, “Google Discover Architecture: Clusters, Classifiers, OG Tags , NAIADES - What SDK Telemetry Reveals”, metehan.ai, luty 2026
