У серпні 2025 року SEO-спільнота в LinkedIn збурилась: сторінки Perplexity Discover масово з'явились у Google Search. Паттерн виглядав як класичний programmatic SEO — автоматична генерація сторінок на trending topics, сотні URL в індексі, стабільне ранжування. Дискусія розгорілась навколо тези "Perplexity грає в programmatic SEO краще за всіх".
Технічний аналіз source code спростував цю тезу повністю. На кожній сторінці Perplexity Discover — однаковий Perplexity, однакова meta description, rel=canonical на homepage. Жодної ознаки SEO-оптимізації — ні унікальних заголовків, ні page-level canonical, ні структурованих даних під ранжування. Це не programmatic SEO. Це щось принципово інше — і розуміння цієї різниці змінює стратегію паблішера.
📚 Зміст статті
Архітектура Google Discover — як система насправді влаштована
9-етапний пайплайн: від краулу до feedback loop
Більшість SEO-гайдів про Google Discover зводяться до "використовуй великі зображення і пиши цікаво". Реальна архітектура складніша. Дослідник Metehan Yesilyurt провів декомпіляцію 87 498 класів Google App і опублікував детальний аналіз SDK-телеметрії, який розкриває внутрішню механіку системи.
Пайплайн складається з восьми послідовних етапів, і порядок їх виконання критично важливий для паблішерів:
- Content Ingestion. Google краулить і індексує контент. Entity extraction присвоює Knowledge Graph MID-ідентифікатори (
/m/xxxxx або /g/xxxxx) розпізнаним темам — саме вони стають ключами для персоналізації. - Structured Data & Open Graph Parsing. Парсер витягує метадані сторінки з чітко визначеним порядком пріоритетності: Schema.org JSON-LD перевіряється першим, потім Open Graph теги, потім Twitter Card, потім generic HTML meta. Це hardcoded fallback chain — якщо JSON-LD містить поле, OG-теги для цього поля ніколи не досягаються.
- Content Classification. Контент присвоюється до одного з 13 типів кластерів і класифікується для ієрархії feed.
- Content Filtering — двохрівнева архітектура. Система операції два незалежних фільтри:
filter_collection_status (рівень домену/паблішера) і filter_entity_status (рівень окремого URL). Критично: collection-level фільтр запускається до interest matching і ранжування. Паблішер, заблокований на цьому рівні, не досягає ranking stage незалежно від релевантності контенту. - User Interest Matching. Entity MID контенту зіставляється з interest profile користувача через систему персоналізації NAIADES.
- Ranking (Server-Side). Ранжування відбувається на сервері. Client-side код показує, які дані упаковуються і надсилаються на сервер, але самі ranking моделі не спостерігаються з клієнта.
- Feed Assembly. Контент організовується і доставляється через gRPC streaming, background WorkManager sync або beacon push.
- Feedback Loop. Взаємодії користувача (відхилення, підписки, збереження) повертаються в персоналізацію. Відхилений контент отримує постійний tombstone — він більше ніколи не з'явиться.
NAIADES: система персоналізації зсередини
| Підтип | Enum value | Що означає |
|---|
SUBTYPE_PERSONAL_UPDATE_MID_BASED_NAIADES | 793 | Персоналізація на основі Knowledge Graph entity |
SUBTYPE_PERSONAL_UPDATE_QUERY_BASED_NAIADES | 792 | Персоналізація на основі пошукових запитів |
SUBTYPE_PERSONAL_UPDATE_RECALL_BOOST | 797 | Підвищення пріоритету retrieval до ранжування |
SUBTYPE_PERSONAL_UPDATE_WPAS | 800 | Web Publisher Articles Signal — реєстрація в Publisher Center |
SUBTYPE_PERSONAL_UPDATE_AIM_THREAD_NAIADES | 856 | AI Mode thread-based персоналізація |
Два підтипи особливо важливі для паблішерів. WPAS (Web Publisher Articles Signal) — реєстрація в Google Publisher Center дає окрему класифікацію в NAIADES: контент зареєстрованого паблішера проходить через інший шлях у пайплайні. RECALL_BOOST підвищує пріоритет контенту на етапі retrieval — ще до ранжування, що означає більший шанс взагалі потрапити в candidate pool.
Fallback chain для метаданих: що парсить система
Декомпільований клас парсера розкриває точний порядок зчитування метаданих. Ключовий висновок: Schema.org JSON-LD перевіряється першим для title, author і publisher — не OG-теги. OG-теги є запасним варіантом:
Title: Schema.org JSON-LD → og:title → twitter:title → generic title
Author: Schema.org JSON-LD → generic author meta
Publisher: Schema.org JSON-LD → og:site_name
Image: og:image → twitter:image → og:image:secure_url → twitter:image:src → generic image
П'ятирівневий fallback chain для зображення означає: система дуже наполегливо намагається знайти картинку. Мінімальна ширина для hero card — 1200px.
Tombstoning і "rug pull"
Два механізми, про які більшість паблішерів не знають. Tombstoning (з bska.java): відхилений користувачем контент отримує постійний булевий прапорець tombstoned = true і більше ніколи не з'являється в цього користувача. Один невдалий матеріал, який масово відхиляють — може заблокувати весь домен на collection-level.
"Rug pull" (лічильник background_refresh_rug_pull_count): контент може бути доставлений у feed і потім ретроактивно видалений під час background refresh. Discover може відкликати контент, який вже знаходився у feed — не лише фільтрувати до показу.
Детальний технічний розбір пайплайну з посиланнями на конкретні Java-класи — у дослідженні Search Engine Land про кваліфікацію і фільтрацію контенту в Google Discover.
Архітектура Perplexity Discover — що source code насправді говорить
Анатомія сторінки Perplexity Discover на рівні HTML
Аналіз source code сторінок Perplexity Discover, задокументований у Search Engine Journal, виявив чотири технічних паттерни, кожен з яких є навмисним архітектурним рішенням:
1. Однаковий title на всіх сторінках:
title Perplexity title
Без жодної прив'язки до теми сторінки. У класичному SEO це миттєвий сигнал thin content або технічного боргу. Тут — навмисна уніфікація: title є brand identifier, а не keyword container.
2. Однакова meta description на кожній сторінці без виключень:
meta name="description"content="Perplexity is a free AI-powered answer engine that
provides accurate, trusted, and real-time answers to any question."
Жодної варіативності залежно від контенту сторінки. Система не намагається генерувати snippet-оптимізований опис під тему кожного trending topic.
3. rel=canonical → homepage на кожній Discover-сторінці:
link rel="canonical" href="https://www.perplexity.ai/" /
Це пряма машиночитана інструкція пошуковику: "канонічним документом для цієї сторінки є homepage, не поточний URL". Весь потенційний link equity, який могли б акумулювати окремі Discover-сторінки, директивно консолідується на root domain.
4. Відсутність page-level Schema.org розмітки під ранжування. На відміну від типового news publisher, який розмічає кожну статтю як NewsArticle або Article з headline, author, datePublished — Discover-сторінки не мають structured data, яка б дозволила пошуковику класифікувати їх як окремі змістовні документи.
Декомпозиція архітектурного рішення: чому кожен паттерн є навмисним
Розглянемо кожне рішення через призму технічних наслідків і альтернатив, від яких Perplexity відмовилась.
Чому не унікальні title? Автоматична генерація унікальних title під trending topics технічно тривіальна — це одна шаблонна функція. Відмова від неї означає свідомий вибір не будувати keyword-to-URL mapping. Trending topic "Bitcoin price today" міг би стати title;Bitcoin price today — Perplexity title за стандартною programmatic SEO логікою. Цього немає.
Чому canonical → homepage, а не noindex? Якби Perplexity хотіла просто виключити Discover-сторінки з індексу — вона використала б meta name="robots" content="noindex";. Натомість обрано canonical → homepage. Різниця принципова: noindex блокує індексацію і втрачає будь-які посилальні сигнали. canonical → homepage дозволяє Google сканувати сторінки і при цьому передає всі посилальні сигнали на root domain. Це максимізація domain-level авторитету при мінімізації page-level ранжування.
Чому не персоналізований feed? На відміну від Google Discover, де ~80% контенту визначається user interest graph, Perplexity Discover показує однаковий trending feed усім користувачам. Відсутність персоналізації — не технічне обмеження (Perplexity має достатньо даних про поведінку користувачів), а архітектурний вибір на користь discovery-логіки: користувач бачить що є trending globally, а не відображення власних інтересів.
Pipeline генерації контенту: що відбувається на рівні системи
Попри відсутність SEO-сигналів, Perplexity генерує Discover-сторінки автоматично і в масштабі. Реконструйований pipeline виглядає так:
- Trending signal detection. Система моніторить пошукові запити і зовнішні сигнали для виявлення trending topics у реальному часі.
- RAG retrieval під тему. Для кожного trending topic запускається retrieval pipeline — той самий, що обслуговує пошукові запити користувачів: vector search по індексу, reranking за релевантністю і авторитетністю джерела.
- LLM synthesis. На основі відібраних документів LLM генерує синтезовану відповідь із атрибуцією до першоджерел.
- Server-side rendering на ephemeral URL. Результат рендериться на публічному URL з фіксованими
title, meta description і canonical → homepage.
Крок 2 є ключовим для паблішерів: retrieval pipeline Discover використовує ті самі сигнали авторитетності, що й звичайний пошук Perplexity. Контент, який потрапляє в Discover як першоджерело — це контент, якому RAG-система вже присвоїла достатній авторитет при reranking. Потрапляння в Discover є індикатором позиції в RAG-авторитетності, а не самостійним SEO-каналом.
Порівняння архітектур — таблиця для розуміння Google Discover vs Perplexity Discover
| Параметр | Google Discover | Perplexity Discover |
|---|
| Мета сторінок | Ранжування в персоналізованому feed кожного користувача окремо | Server-side rendered ephemeral content для прямих відвідувачів; domain-level авторитет через canonical → homepage |
|---|
| Title / meta | Унікальні, читаються з JSON-LD першим, потім og:title як fallback | Ідентичні на всіх сторінках: <title>Perplexity</title> — brand identifier, не keyword container |
|---|
| Canonical стратегія | Self-referencing canonical — кожна сторінка є канонічною для себе | canonical → homepage на всіх Discover-URL — свідома консолідація link equity на root domain |
|---|
Чому не noindex | N/A — сторінки призначені для індексації | canonical обрано замість noindex: зберігає посилальні сигнали на domain рівні, не блокує сканування |
|---|
| Ranking signals | pCTR model, image fallback chain (5 рівнів), freshness buckets, entity MID matching, WPAS signal (Publisher Center) | Відсутні навмисно — page-level ранжування не є метою архітектури |
|---|
| Персоналізація | ~80% user interest graph через NAIADES (MID-based + query-based subtypes), search history, location, device | Відсутня — однаковий trending feed для всіх користувачів незалежно від поведінки |
|---|
| Feedback loop | Dismissed URL → permanent tombstoned=true; collection-level block передує interest matching і ранжуванню | Відсутній — ephemeral контент замінюється новими trending topics без накопичення user feedback |
|---|
| Freshness логіка | Freshness buckets з bemp.java: 0_DAYS → 1_TO_7_DAYS → 8_TO_14_DAYS → 15_TO_30_DAYS → TAIL | Binary: trending topic активний → сторінка існує; тема застаріла → сторінка замінюється або зникає |
|---|
| Тривалість релевантності | Evergreen + trending — обидва типи можуть стабільно утримуватись у feed | Виключно ephemeral — архітектура не передбачає довгострокового утримання URL |
|---|
| Розподіл трафіку | Персоналізований feed → referral click → landing page паблішера | Direct → App → brand search; паблішер отримує трафік через цитування, не через Discover-URL |
|---|
| Ризик алгоритмічного штрафу | Core updates, Discover-specific updates, tombstoning cascade, collection-level block при масових відхиленнях | Мінімальний: система не залежить від Google-ранжування, canonical знімає thin content ризик |
|---|
| Роль паблішера | Активна: JSON-LD Schema першим у fallback chain, og:image 1200px+, Publisher Center реєстрація, entity authority в ніші | Непряма: потрапляння як першоджерело у RAG retrieval pipeline — результат авторитетності домену, не page-level оптимізації |
|---|
Що це означає для паблішерів — нова логіка дистрибуції
Стратегія для Google Discover
Розуміння внутрішньої архітектури дає конкретні технічні дії, а не загальні рекомендації:
1. Publisher Center і WPAS-сигнал. Реєстрація в Google Publisher Center дає контенту окремий підтип класифікації в NAIADES — WPAS. Це означає, що контент зареєстрованого паблішера проходить через окремий шлях у пайплайні ще до ранжування. Це один із небагатьох прямих важелів, які паблішер контролює повністю.
2. Schema.org JSON-LD — не OG-теги як основа. Парсер Google Discover перевіряє JSON-LD першим для title, author і publisher. Якщо ваш сайт використовує лише og:title без Article JSON-LD — ви покладаєтесь на fallback шлях. Мінімальна коректна розмітка для Discover:
{"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "Заголовок статті",
"author": {
"@type": "Person",
"name": "Ім'я автора"
},
"publisher": {
"@type": "Organization",
"name": "Назва видання"
},
"datePublished": "2026-03-04",
"dateModified": "2026-03-04"
}
3. Зображення: 1200px — мінімум для hero card. П'ятирівневий image fallback chain означає, що система наполегливо шукає зображення. Але hero card (великий формат у feed) доступний лише для зображень від 1200px. og:image знаходиться на першому місці в fallback chain для зображень — встановіть його явно.
4. Уникайте meta-тегів notranslate і nopagereadaloud. Обидва повністю зупиняють parsing pipeline. Якщо ваш CMS або translation plugin автоматично додає ці теги — контент може взагалі не потрапити в пайплайн Discover.
5. Один article:content_tier. Якщо використовуєте paywall класифікацію, вживайте рівно одне значення: free, metered або locked. Кілька значень на одній сторінці логують warning і можуть порушити класифікацію.
6. February 2026 Discover Core Update: локальний кут і глибина. Лютневий апдейт посилив регіональну персоналізацію і зменшив кількість унікальних доменів у топі. Стратегічний висновок: generalist coverage поступається місцем локальній або нішевій глибині. Entity authority в конкретній темі важливіший за широке охоплення.
7. Tombstoning — управління якістю критичне. Один матеріал, який масово відхиляють, може тригернути collection-level block на весь домен. Discover — не канал для тестування слабкого контенту.
Стратегія для Perplexity Discover
Perplexity Discover — принципово інший канал із принципово іншою логікою. Тут немає ranking signals, які можна оптимізувати. Натомість є RAG-авторитетність — верифікованість джерела через машиночитані бази даних.
Для паблішера потрапляння в Perplexity Discover як цитоване джерело означає, що RAG-система визнала матеріал достатньо авторитетним для включення у відповідь. Це не SEO-ранжування — це editorial selection за критеріями AI-системи.
Ключові важелі для Perplexity Discover:
- Участь у Perplexity Publishers Program — прямий канал підвищення видимості в системі
- Верифікованість автора і домену через Wikidata, Crunchbase, Schema.org
sameAs - Свіжість контенту — freshness score максимальний у перші 48 годин після публікації
- Цитування від джерел, які вже цитує Perplexity — потрапляння в "коло довіри" RAG-системи
Паралельна стратегія: чому ці канали не конкурують
Google Discover і Perplexity Discover вимагають різних дій, але не суперечать одне одному. Google Discover — це персоналізований граф, де паблішер оптимізує технічні сигнали (JSON-LD, image, Publisher Center) щоб алгоритм показав контент потрібній аудиторії. Perplexity Discover — це AI editorial selection, де паблішер будує машиночитану авторитетність щоб RAG-система обрала його як джерело.
Різні KPI, різні метрики успіху, різні технічні дії — але паблішер 2026 року потребує обох каналів одночасно.
Programmatic SEO — що насправді відбулось і чому LinkedIn помилився
Щоб зрозуміти, чому діагноз "programmatic SEO" технічно некоректний, потрібно формалізувати що саме є необхідними умовами programmatic SEO як інженерного паттерну — і перевірити кожну з них проти реального source code Perplexity Discover.
Технічний чекліст: необхідні умови programmatic SEO
Programmatic SEO як інженерний паттерн має чіткі технічні ознаки. Кожна з них є необхідною — відсутність хоча б однієї означає, що система не є programmatic SEO у визначеному сенсі:
| Технічна ознака | Мета в programmatic SEO | Perplexity Discover |
|---|
Унікальний <title> на кожній сторінці | Точне попадання в пошуковий запит, CTR-оптимізація | ❌ Однаковий: Perplexity на всіх сторінках |
Унікальна meta description | Snippet-оптимізація під цільовий запит | ❌ Однакова на всіх сторінках без виключень |
Page-level rel=canonical | Збереження link equity на цільовому URL | ❌ canonical → homepage — свідома консолідація link equity геть від сторінки |
Structured data під ранжування (Article, FAQPage тощо) | Rich snippets, entity matching в Knowledge Graph | ❌ Відсутня page-level Schema.org розмітка під ранжування |
| Намір потрапити в пошуковий індекс як цільова URL | Основна мета всієї системи | ❌ Відсутній — canonical → homepage прямо сигналізує протилежне |
Результат: Perplexity Discover не відповідає жодній з необхідних технічних умов programmatic SEO. Це не питання інтерпретації — це питання читання HTML.
Чому сторінки все одно потрапили в Google Search
Google індексує публічні URL за умовчанням, якщо немає явної директиви noindex у HTTP-заголовку або <meta name="robots" content="noindex">. Perplexity не встановила noindex — і Google проіндексував сторінки відповідно до свого стандартного поводження з публічним контентом.
При цьому наявність canonical → homepage теоретично мала б запобігти ранжуванню окремих Discover-сторінок як самостійних документів. Те, що вони все одно з'явились у Google Search — окремий технічний феномен, який свідчить про те, що Google не завжди дотримується canonical директиви, особливо якщо контент сторінки достатньо унікальний, щоб алгоритм вирішив ігнорувати сигнал консолідації. Це відомий паттерн: canonical є "рекомендацією", а не директивою типу noindex.
Іншими словами: потрапляння в Google Search є результатом поведінки Google-алгоритму всупереч явному сигналу від Perplexity — а не результатом SEO-оптимізації з боку Perplexity.
Що це насправді — і який паттерн коректніший
З інженерної точки зору Perplexity Discover є server-side rendered ephemeral content pipeline: система автоматично генерує сторінки на основі trending signals, рендерить їх для прямих відвідувачів і агресивно консолідує SEO-авторитет на root domain через canonical. Мета — direct traffic і brand habit, не search distribution.
Найближчий аналог у веб-архітектурі — не programmatic SEO, а news aggregator з ephemeral URL structure: контент генерується автоматично і в масштабі, але URL не є цільовою одиницею для пошукового ранжування — цільовою одиницею є сам домен і brand recall.
Висновок
Google Discover і Perplexity Discover мають однакову назву і поверхнево схожу функцію — показувати контент без явного пошукового запиту. Але архітектурно це протилежні системи з протилежними контрактами з аудиторією і паблішером.
Google Discover — персоналізований граф із feedback loops, де паблішер активно оптимізує технічні сигнали: Schema.org JSON-LD (перший у fallback chain, не OG-теги), зображення від 1200px, реєстрація в Publisher Center для WPAS-сигналу, entity authority в ніші. Одна помилка — масове tombstoning матеріалу — може заблокувати весь домен на collection-level.
Perplexity Discover — destination play із canonicalized ephemeral content, де оптимізація під пошуковий алгоритм свідомо відсутня. Для паблішера це не канал прямого трафіку — це сигнал того, що RAG-система визнала джерело достатньо авторитетним для цитування.
Дві системи — два різних контракти. Google Discover: ти оптимізуєш сигнали → алгоритм вирішує, кому показати. Perplexity Discover: ти будуєш верифіковану авторитетність → AI-система обирає тебе як джерело. Паблішер 2026 року потребує обох — але з чітким розумінням, що в кожному з них є важелем, а що є ілюзією контролю.
Джерела та посилання:
Читайте також у цій серії:
Ключові слова:
perplexity discovergoogle discover архітектураnaiades персоналізаціяprogrammatic seotombstoning googlepublisher center wpascanonical стратегіяdiscover для паблішерівperplexity publishe
