МАТЧАСТЬ / PUBLICATION HEALTH & ANALYTICS / DOCUMENT 32 / 02.09.2026

Publication Health и аналитика публикаций

Как доказать клиенту, что опубликованный материал существует, технически корректен, доступен поисковикам, связан с сайтом и начинает получать реальные показы, переходы и внешние рефералы. Документ разделяет то, что контролирует «Матчасть», то, что наблюдается во внешних системах, и то, что нельзя обещать. Определяет Publication Health, Search Proof, события аналитики, Google Search Console, Яндекс Вебмастер, IndexNow, отчёт +7/+30/+60, технические алерты и data model для будущего AI Visibility.

3 слояControlled → Observed → Outcome; их нельзя смешивать в один «SEO score»

URL-levelpublication_id остаётся главным ключом даже после изменения slug/redirect

+7/+30/+60базовые окна наблюдения после публикации

No guaranteesIndexNow, sitemap и Search Console не гарантируют индекс или позицию

1. Главное решение

Разделить аналитику публикации на три независимых контура: техническое состояние страницы, внешнее обнаружение/поиск и реальное поведение читателей. Клиент никогда не должен видеть зелёную галочку «SEO работает», собранную из несопоставимых сигналов.

1. CONTROLLED / PUBLICATION HEALTH то, что контролирует Mathchast HTTP canonical robots schema sitemap links disclosure assets crawler access 2. OBSERVED / SEARCH PROOF то, что сообщили внешние системы Google crawl/index status Google impressions/clicks/queries Yandex search/index status Yandex impressions/clicks/queries external referrals 3. OUTCOMES поведение после контакта reads company profile visits official-site clicks CTA leads later AI visibility later

2. Почему это фундаментальный продуктовый слой

Большинство площадок умеет сказать клиенту «статья опубликована». «Матчасть» должна уметь доказать гораздо больше: какой именно URL опубликован, отвечает ли он 200, какой canonical видит система, присутствует ли он в sitemap, когда отправлено уведомление об изменении, когда Google его последний раз сканировал, появился ли он в поиске, по каким запросам получил показы и какие реальные действия произошли после чтения.

Search Proof — один из трёх будущих moat-модулей вместе с AI Visibility и Next Best Publication.

3. Что нельзя объединять

Факт	Что он означает	Чего не означает
HTTP 200	Страница доступна	Google её проиндексировал
URL в sitemap	Мы сообщили URL как кандидат	Он обязательно индексируется
IndexNow 200	Endpoint принял уведомление	Страница вошла в индекс
Google crawled	Google посещал URL	URL показывается в Search
Google indexed	URL/канонический объект доступен индексу	Есть impressions
Impressions	Страница показывалась	Человек прочитал статью
Click	Пользователь перешёл	Стал лидом

4. Publication Health — наше обещание

В базовый SKU можно уверенно включать именно Publication Health, потому что значительная часть его признаков контролируется самой платформой.

PUBLICATION HEALTH URL 200 Canonical correct Indexability allowed robots allowed Sitemap present lastmod correct JSON-LD valid OpenGraph present Images accessible Disclosure correct Commercial rel correct Internal links present Topic/entity connected Redirect state correct OAI-SearchBot allowed by policy IndexNow event sent where applicable

5. Health ≠ Indexing

Название статуса должно быть «Технически готово к обнаружению», а не «Проиндексировано». Индексацию подтверждают только внешние наблюдения.

6. Publication Health states

UNKNOWN → CHECKING → HEALTHY or: WARNING DEGRADED CRITICAL Examples: WARNING: optional schema field missing DEGRADED: canonical mismatch internal CRITICAL: 500 noindex unexpectedly ad disclosure missing broken canonical target.

7. Health score?

Можно иметь внутренний numeric score для triage, но клиенту лучше показывать конкретные проверки и overall state. «92/100 SEO Health» создаёт ложную точность.

8. Hard checks

Проверка	Healthy	Critical condition
HTTP	200	4xx/5xx
Canonical	Self/expected canonical	Points to wrong publication
Robots meta	Index allowed for public indexable page	Unexpected noindex
robots.txt	Crawler allowed according policy	Required crawler blocked accidentally
Structured data	Parseable / consistent	Contradicts visible page
Disclosure	Required label rendered	Paid material missing required disclosure
Outbound links	Policy-derived rel	Commercial link lost sponsored

9. Soft checks

cover/image optimal? meta description? breadcrumb complete? optional schema properties? related content count? topic depth? company profile relation? Warning: improve later but no need to take page offline.

10. URL identity

Analytics привязывается к immutable publication_id, а URL является версионируемым адресом.

publication_id = UUID-123 URL history: 2026-09-04 /articles/old-slug 2026-11-12 /articles/new-slug analytics: same publication_id redirect: old → new reports: continuous history.

11. Почему нельзя хранить аналитику только по URL

После смены slug, рубрики, домена или migration история расколется на две страницы. Документ 16 уже требует URL history и redirects, а analytics должен следовать тому же принципу.

12. Canonical monitoring

Google прямо указывает, что canonical — предпочтение, а не абсолютная команда: Google может выбрать другой representative URL. В Search Console URL Inspection возвращает и user-declared canonical, и Google-selected canonical.

OUR CHECK: userCanonical = https://mathchast.com/cases/acme GOOGLE OBSERVED: googleCanonical = https://mathchast.com/cases/acme → MATCH If mismatch: → warning → investigate duplicate / signals.

13. Canonical mismatch не равен penalty

Это диагностический сигнал. Нужно понять, почему внешний поисковик считает другой URL более представительным.

14. Sitemap policy

Google рекомендует включать в sitemap canonical URLs и использовать <lastmod> только для действительно значимых обновлений; Google игнорирует priority и changefreq.

Include: canonical 200 indexable public Exclude: draft preview noindex redirect source filter/search duplicate removed.

15. Sitemap lastmod

Одинаковое правило используется в трёх местах:

publication.updated_at meaningful = sitemap lastmod = visible Updated date when relevant = IndexNow/update event trigger TYPO? usually not substantial New research section/data? substantial.

16. Sitemaps by type

/sitemap-index.xml /sitemaps/articles.xml /sitemaps/cases.xml /sitemaps/research.xml /sitemaps/news.xml /sitemaps/companies.xml /sitemaps/experts.xml /sitemaps/topics.xml

Разделение нужно прежде всего для диагностики, а не из-за размера на раннем этапе.

17. Search Console Sitemaps API

Google Search Console API позволяет list/get/submit sitemaps для подтверждённого property. Это стоит использовать для site-level health, но сам факт submitted sitemap не доказывает status отдельной страницы.

18. Google URL Inspection API

Это основной официальный URL-level источник для Google Search Proof.

API возвращает index verdict, coverage state, robots status, indexing state, last crawl time, fetch state, Google canonical, user canonical, known sitemap и другие данные по URL в свойстве Search Console.

google_url_observation: verdict coverage_state robots_txt_state indexing_state last_crawl_time page_fetch_state google_canonical user_canonical sitemaps[] observed_at

19. Ограничение URL Inspection API

Текущая официальная документация API говорит, что программный метод проверяет состояние версии в индексе; live indexability test через этот API не предоставляется.

Поэтому собственный Publication Health crawler проверяет live page, а Google API — внешний indexed state. Эти два наблюдения дополняют друг друга.

20. Квоты URL Inspection

Google в официальном анонсе URL Inspection API указывает лимиты на Search Console property: 2 000 запросов в день и 600 в минуту.

Mathchast scale: 100–1000 publications → enough for prioritized URL checks Do not: inspect every URL every minute.

21. Google Inspection schedule

New publication: T+6h optional T+1d T+3d T+7d T+14d T+30d After indexed: reduce frequency High-value: periodic Incident: on demand.

Расписание — проектная гипотеза, не рекомендация Google.

22. Google indexing request

В UI Search Console можно вручную запрашивать indexing через URL Inspection. Google предупреждает, что request не гарантирует inclusion и indexing может занять от дня до недели/двух; для большого количества URL предпочтительнее sitemap.

Не обещать клиенту автоматическую кнопку «Отправили в Google Indexing API» для обычной статьи.

23. Google Indexing API — важное ограничение

Официальный Google Indexing API предназначен только для страниц с JobPosting или livestream BroadcastEvent в VideoObject. Обычные статьи, кейсы, исследования и company pages «Матчасти» через него отправлять нельзя.

NORMAL MATHCHAST ARTICLE: Google discovery: ✓ sitemap ✓ internal links ✓ normal crawling ✓ Search Console observation NOT: ✕ generic Indexing API abuse.

24. IndexNow

IndexNow позволяет сообщить участвующим поисковикам о новом, изменённом или удалённом URL. Ответ HTTP 200 означает только, что endpoint получил URL, а не то, что страница проиндексирована.

PublicationPublished → IndexNow URL_UPDATED Meaningful update → IndexNow URL_UPDATED Removed / migrated → submit changed/deleted URL state according implementation store: submitted_at endpoint response attempt.

25. IndexNow batch

Протокол позволяет отправлять до 10 000 URL в одном POST. Для «Матчасти» лучше отправлять event-driven small batches, а не ждать огромных ночных пакетов.

26. IndexNow не заменяет sitemap

Использовать оба: sitemap описывает устойчивый canonical corpus, IndexNow быстро сообщает об изменениях участвующим поисковикам.

27. Yandex + IndexNow

Яндекс официально перечисляет IndexNow среди способов уведомления о новых и изменённых страницах и показывает результаты indexing в Webmaster.

28. Yandex Reindex API

Яндекс Вебмастер API также имеет endpoint отправки конкретной страницы в очередь переобхода и возвращает task_id с остатком квоты.

P0: IndexNow + sitemap P1: Yandex reindex API for important/problem URLs with quota-aware queue.

29. Не отправлять всё повторно

Каждое autosave/typo не должно создавать IndexNow и reindex request. Система должна понимать substantive publication event.

30. Yandex important page monitoring

Yandex Webmaster API умеет возвращать для важных URL HTTP/indexing status, searchable state, crawl dates, исключение из поиска и target URL, который может быть redirect/canonical/duplicate.

Это почти готовый внешний «Publication Health observation» для Яндекса.

yandex_url_observation: searchable http_code/status access_date last_access excluded_url_status target_url observed_at

31. Yandex indexing history

Webmaster API позволяет получать историю количества индексированных страниц и HTTP-группы; отдельные endpoints дают samples и историю появления/исчезновения страниц в поиске.

32. Google Search Performance

Per publication: impressions clicks CTR average position dimensions: query page country device date search appearance where useful.

33. Search Console API не возвращает абсолютно все строки

Официальная документация Search Analytics API прямо предупреждает, что API ограничен внутренними пределами Search Console и возвращает top rows, а не гарантированно все данные.

Поэтому нельзя говорить клиенту: «Вот полный список всех Google-запросов, по которым вас видели».

34. Query privacy

Google Search Console также может скрывать редкие запросы по privacy-причинам. Итоговые clicks/impressions могут не совпадать с суммой видимых query rows.

35. Search Console latency

Search Console обычно публикует данные с задержкой около 2–3 дней; recent rows могут быть preliminary. API теперь позволяет запрашивать fresh/incomplete data через dataState=all или hourly data, но такие значения могут ещё изменяться.

Dashboard: Final data vs Preliminary data Never show: 0 today as "no impressions" when data isn't ready.

36. Search data timestamps

На каждом search chart показывать «данные по состоянию на…» и отдельно measurement period.

37. Search Console time zone

Search Console daily reporting использует Pacific Time в основных views/API semantics. Это может расходиться с Europe/Moscow/UTC business analytics.

Хранить raw source timezone и нормализованные reporting windows; не сравнивать «день к дню» из разных систем без пояснения.

38. Yandex Search Queries

Яндекс Вебмастер даёт impressions, clicks, CTR и position по запросам/URL. API popular search queries предоставляет top-3000 за неделю и позволяет выбирать до 500 запросов по показам или кликам; UI может работать с более широким набором.

Per URL: Yandex impressions clicks CTR position queries date window

39. Не сравнивать позицию Google и Yandex как одну метрику

Разные поисковые системы, выборки, география, персонализация и aggregation. В dashboard они живут отдельно.

40. Search Proof stages

STAGE 0 Published STAGE 1 Discoverable technically STAGE 2 Crawler observed STAGE 3 Indexed/searchable observed STAGE 4 Impressions observed STAGE 5 Clicks observed STAGE 6 Downstream action observed

41. Клиентский статус

Internal stage	Client wording
Published	«Опубликовано»
Healthy	«Страница технически доступна для обнаружения»
Google crawled	«Google посещал страницу»
Google indexed	«Google сообщает об индексировании»
Impressions	«Появились показы в Google»
Yandex searchable	«Страница присутствует в поиске Яндекса»

42. Не использовать «SEO успешно»

Нет одного бинарного момента, когда SEO «сработало».

43. First-party reader analytics

Events: publication_impression publication_open meaningful_read scroll_depth optional source_link_click company_profile_click expert_profile_click topic_click related_click official_site_click cta_click save follow share_click

44. Meaningful read

Определение должно быть простым и стабильным. Например: минимальное активное время + достаточная глубина для длины текста. Не выдавать его за доказательство полного прочтения.

Example internal: active_time ≥30s AND scroll ≥50% OR long-format calibrated rule Name in report: "содержательные чтения" with methodology.

45. Pageview ≠ reader

Metric	Смысл
Pageviews	Загрузки/просмотры страницы
Sessions	Сеансы
Users	Оценка пользователей по first-party method
Meaningful reads	Сеансы, прошедшие reader threshold
Official-site clicks	Переходы на подтверждённый внешний ресурс

46. Bot filtering

Reader analytics должна отделять известных crawlers/bots от человеческих sessions. При этом crawler hits полезны как отдельная technical telemetry.

HUMAN_ANALYTICS vs CRAWLER_LOG Known: Googlebot YandexBot OAI-SearchBot GPTBot Bingbot etc.

47. Server logs как независимый источник

For important pages: HTTP request user-agent status timestamp path response time bot class Use: crawler availability incident diagnosis Do not expose: raw IP logs to clients.

48. OAI-SearchBot

OpenAI официально отделяет search crawling от training policy и сообщает, что издатели, разрешающие OAI-SearchBot, могут отслеживать referral traffic из ChatGPT; ChatGPT автоматически добавляет utm_source=chatgpt.com в referral URLs из Search results.

В Publication Analytics это даёт реальный observable signal: ChatGPT referral traffic.

49. ChatGPT referral ≠ ChatGPT citation count

Переход с utm_source=chatgpt.com доказывает referral, но не показывает все случаи упоминания или цитирования URL внутри ChatGPT. Полноценное AI Visibility измеряется отдельно в Mathchast_33.

50. Referral classification

source_type: GOOGLE_SEARCH YANDEX_SEARCH CHATGPT OTHER_AI TELEGRAM EMAIL CLIENT_SHARE EXTERNAL_SITE DIRECT INTERNAL PROMOTED UNKNOWN

51. AI referrer detection

signals: utm_source=chatgpt.com referrer hostname known campaign params Rules versioned: because providers change.

52. Do not invent AI attribution

Если referrer отсутствует, нельзя решать «наверное пришёл из Gemini» по user-agent.

53. Internal distribution attribution

internal_ref: home main_feed topic related company expert search collection When clicked: event includes surface + slot + publication.

54. Owned channel attribution

Telegram: campaign_id + UTM Email: issue_id + UTM Client share: share_link_id / UTM optional Promoted later: campaign_id mandatory.

55. Organic and paid separation

Отчёт должен отдельно показывать organic/internal distribution, editorial amplification, owned channels и paid distribution.

56. Outbound click tracking

click event: publication_id destination_id link_role destination_domain timestamp surface session anonymized id URL stored normalized.

57. Не делать opaque redirect для всех ссылок

Mathchast_17 уже рекомендует прямые ссылки + event tracking, а не обязательные промежуточные redirect URLs.

58. CTA tracking

CTA: official site contact download form product event: cta_id type publication_id campaign destination.

59. Leads later

Если в будущем «Матчасть» хостит lead form, lead count становится контролируемым событием. Но lead quality/sale остаётся external outcome.

60. Client-side analytics и ad blockers

Некоторая first-party web-аналитика может не фиксировать часть sessions из-за блокировщиков/JS. Server logs и client events дают разные картины. Не обещать абсолютную точность users.

61. Measurement source hierarchy

Metric	Source of truth
HTTP/canonical/schema	Mathchast Health crawler
Google index/crawl state	Google Search Console URL Inspection
Google impressions/clicks	Search Console Search Analytics
Yandex search state	Yandex Webmaster
Yandex query stats	Yandex Webmaster
On-site reading	Mathchast first-party analytics
ChatGPT referral	Mathchast analytics + UTM/referrer

62. Никакой «средней позиции сайта» в клиентском отчёте без контекста

Position — агрегированная метрика по запросам/географиям/устройствам. Она полезна для диагностики, но не должна подаваться как «ваша статья на 8-м месте» без query scope.

63. Query-level report

Google query: "ai visibility b2b" impressions clicks CTR average position window Clearly: Search Console-reported privacy/top-row limitations.

64. Query clusters

P1: сгруппировать запросы семантически для понятности, но raw source values сохранять неизменными.

65. Brand vs non-brand

Brand: Acme Acme AI Acme case Non-brand: AI visibility B2B GEO ... Rules: client-approved brand aliases versioned.

66. Search Proof core client view

GOOGLE Technical: ✓ page healthy Observed: Last crawl: 09 Sep Indexed: yes Google canonical: matches Last 30d: Impressions: 420 Clicks: 31 Queries visible: 18 YANDEX: Searchable: yes Impressions: 170 Clicks: 12

67. No-data state

Google: «Search Console пока не сообщает показы» Possible: new page data delay no impressions privacy aggregation Not: «0 = статья не индексируется».

68. New site no-data

Google предупреждает, что для нового сайта/newly-added Search Console property данные могут появляться не сразу, иногда до недели.

69. Observation timestamp

Каждый external snapshot хранит observed_at, а не перезаписывает «текущее состояние» без истории.

70. Time series model

publication_search_daily: publication_id engine date impressions clicks ctr position data_state source_updated_at ingested_at

71. URL Inspection snapshot

publication_index_snapshot: publication_id engine observed_at verdict crawl_time canonical searchable/indexed reason raw_source_ref

72. Health check snapshot

publication_health_snapshot: publication_id checked_at http canonical robots schema sitemap links assets disclosure crawler_policy overall issues[]

73. Event analytics storage

raw events: short retention / privacy policy aggregates: publication_daily_metrics daily: views meaningful_reads internal_clicks outbound_clicks saves follows shares source breakdown.

74. Why daily aggregates

Клиенту нужны тренды и доказательства, а не миллиард сырых event rows. Raw events существуют для вычисления/anti-fraud, aggregates — для отчёта.

75. Fraud filtering

exclude/flag: known bots datacenter bursts same session click loops internal staff traffic load tests preview traffic health crawlers paid distribution later: additional fraud model.

76. Internal staff traffic

Редакторы, клиентский preview и automated screenshots не должны искусственно поднимать pageviews статьи.

77. Preview isolation

preview URL: noindex signed analytics environment=preview excluded from production reader metrics.

78. Published page internal QA traffic

staff session marker or known authenticated staff exclude from: client-facing views retain: technical logs.

79. Data correction

Analytics itself can have incidents. Search Console has published data anomalies in 2026. Поэтому external data ingestion must preserve source/date and allow annotation.

annotation: Google Search Console data anomaly 2026-04... affected metric: impressions report: source warning icon.

80. Metrics are versioned by methodology

meaningful_read v1 meaningful_read v2 report stores: metric_definition_version Never silently recalculate old client report with new methodology without note.

81. Publication timeline

Один из лучших интерфейсов клиента — временная шкала доказательств.

04 Sep Published 04 Sep IndexNow sent 05 Sep Yandex crawled 06 Sep Google crawled 08 Sep Google indexed observed 09 Sep First Google impression 11 Sep First Yandex click 16 Sep First ChatGPT referral 04 Oct +30d report

82. Timeline не обещает порядок

Google может дать impression до того, как наша scheduled URL Inspection job записала indexed snapshot. Поэтому timeline показывает observed_at, а не выдумывает точную causal chronology поисковика.

83. Baseline

Before publication: company search baseline brand visibility existing page set Publication-level: no historical URL exists Client-level before/after: separate methodology Mathchast_34.

84. +7 report

+7 DAYS Technical health crawl/index observations first impressions if any distribution reader signals issues No: big ROI conclusion.

85. +30 report

+30 DAYS health history search impressions/clicks query examples internal distribution reader engagement outbound clicks AI referrals first AI visibility results if package → recommended next action.

86. +60 report

+60 DAYS search trend long-tail activity query expansion external referrals AI observations comparison with +30 content gaps next publication recommendation.

87. +90/+180 later

Для evergreen и premium monitoring можно продолжать, но не делать обязательным для базового Publish.

88. Base Publish analytics window

Базовый Publish может включать постоянный basic dashboard и 30-дневный summary, а active Search/AI monitoring более длинного периода — платный add-on.

89. Что остаётся после monitoring expiration

Remains: historical metrics publication health basic public URL past reports Stops: premium external polling AI prompt runs advanced alerts deep query analysis.

90. Client dashboard: top card

ОПУБЛИКОВАНО 04.09.2026 Publication Health HEALTHY ✓ Google Indexed observed ✓ Yandex In search ✓ 30d: Google impressions 420 Search clicks 43 Reads 612 Official-site clicks 37 ChatGPT referrals 6

91. Никогда не показывать «Indexed ✓» без source

Tooltip/label должен говорить: «По данным Google Search Console» или «По данным Яндекс Вебмастера».

92. Publication Health detail

HTTP ✓ Canonical ✓ Robots ✓ Sitemap ✓ Structured data ✓ Assets ✓ Advertising label ✓ Outbound link policy ✓ OAI Search access ✓ Last check: 02 Sep 18:40

93. Search Proof detail

Google Search Console Last sync: ... Index status Last crawl Canonical Sitemaps Performance: 7d / 30d / 90d queries devices countries Yandex: same conceptual structure.

94. External state wording

Bad wording	Good wording
«Мы проиндексировали страницу»	«Google сообщает, что страница индексируется/проиндексирована»
«Мы дали 420 показов в Google»	«Search Console зафиксировал 420 показов»
«Матчасть подняла вас на 8 место»	«Средняя позиция по наблюдаемым запросам составила…»

95. Search Console property

Mathchast владеет доменом, поэтому Search Console property принадлежит самой платформе. Клиенту не нужно давать OAuth к Search Console «Матчасти».

96. Client privacy across search queries

Publication A client sees: metrics for own publication/entity scope Not: full site's secret query data other clients' unpublished/commercial analytics.

97. Editorial dashboard gets broader view

site-wide: index coverage query gaps topic performance template issues crawler incidents commercial vs editorial trends.

98. Page Indexing report caveat

Google Search Console многие reports строит на representative samples, хотя Page Indexing предоставляет полные totals и ограниченный список примеров. Для конкретного клиентского URL использовать URL Inspection, а не пытаться вывести индивидуальный status из site-level sample table.

99. Indexability incident types

HTTP_FAILURE NOINDEX_UNEXPECTED ROBOTS_BLOCK CANONICAL_MISMATCH REDIRECT_LOOP SITEMAP_MISSING SCHEMA_INVALID DISCLOSURE_MISSING ASSET_FAILURE GOOGLE_FETCH_FAIL YANDEX_EXCLUDED BROKEN_INTERNAL_LINK MALWARE_DESTINATION

100. Severity

Severity	Response
P0 Critical	Published paid URL unavailable / disclosure missing / wrong content
P1 High	Unexpected noindex, canonical to wrong page, major crawler block
P2 Medium	Schema warning, broken related link, image issue
P3 Low	Optional metadata improvement

101. Health check frequency

Immediately after publish +5 minutes +1 hour Active first month: daily/periodic Long-term: daily or several times/week for paid/public permanent URLs Critical events: on deploy/update.

Точная частота — engineering/cost decision.

102. Site-wide canary checks

Перед тем как проверять 5 000 страниц, проверять типовые canary URLs каждого шаблона.

article case research news company expert topic if template-wide failure: incident → avoid 500 duplicate alerts.

103. Deploy checks

after frontend/backend deploy: canonical robots JSON-LD disclosure analytics outbound events status sitemap on canary pages.

104. URL health worker

mathchast_crawler → fetch canonical URL → parse HTML → checks → snapshot → compare prior → issue event if changed.

105. Avoid JavaScript-only critical metadata

Документы 21/22 уже рекомендуют SSR/HTML-first. Health checker должен проверять raw server response прежде всего; optional rendered-browser check используется как second layer.

106. Screenshot visual regression?

Не core Publication Health, но P1 canary visual check полезен после больших frontend deploys.

107. Broken outbound links

periodic: HEAD/GET carefully destination status redirect domain security signal If broken: editor/client action according link role.

108. Broken source vs broken advertiser link

Link role	Response
Editorial source	Find archive/new official source, preserve citation context
Advertiser official site	Client/entity update
Malware/unsafe	Immediate disable/review

109. External redirect drift

Проверять final destination. Купленный домен рекламодателя через год может редиректить в совершенно другое место.

110. Structured data health

parse JSON-LD @context expected type @id references canonical match visible content consistency author/publisher dates image access Google rich result eligibility: separate/volatile.

111. Rich result не является KPI

Google меняет поддерживаемые search appearances. В 2026, например, FAQ rich results были прекращены. Не строить Product Health вокруг «количества rich-result типов».

112. Search appearance versioning

If Google removes feature: report history remains UI deprecates metric no "health failure".

113. Crawler policy health

Expected: Googlebot allowed Yandex bots allowed OAI-SearchBot according publisher policy GPTBot according separate training policy check: robots.txt version effective rules last changed.

114. OAI-SearchBot and GPTBot separate

Не объединять «доступ ChatGPT» в один switch. Search crawler и training crawler имеют разные назначения/policies.

115. Search/AI crawler log dashboard

Last 30d: Googlebot requests YandexBot requests OAI-SearchBot requests GPTBot requests Bingbot requests status distribution blocked 5xx latency.

116. Crawl log ≠ inclusion

Визит OAI-SearchBot не доказывает, что статья будет использована или процитирована ChatGPT.

117. Reader analytics privacy

Client receives: aggregates No: raw IP individual reader identity personal history query tied to named user unless explicit lead form and lawful basis.

118. Minimum cohort threshold

Для чувствительных breakdowns (география, device, etc.) можно не показывать очень малые сегменты, чтобы не создавать ложную точность/privacy leakage.

119. Client-specific analytics

Publication owner: full aggregate metrics Other public reader: no private analytics Editorial: site-level analytics Agency: only delegated clients.

120. Metric definitions public methodology

Создать /methodology/analytics с определениями:

view meaningful read impression search click outbound click AI referral index observation measurement window data delay preliminary data.

121. Report provenance

Every metric card: source window last sync methodology preliminary/final Example: Google impressions Source: Search Console 01–30 Sep Final through 28 Sep.

122. Report snapshot

report_id publication_id window generated_at data_cutoff metric_definition_versions source sync timestamps annotations.

123. PDF export

PDF — immutable snapshot; live dashboard can change as late external data arrives.

124. Client report sections

1. Publication 2. Technical health 3. Search discovery 4. Search performance 5. Mathchast distribution 6. Reader engagement 7. Outbound actions 8. External/AI referrals 9. Changes since previous window 10. Limitations 11. Next action

125. «Что произошло» vs «Почему произошло»

Analytics reliably observes the first. Causality requires a stronger methodology.

Observed: Google impressions grew 40% Possible explanation: new queries / aging / distribution Do not: "рост произошёл из-за публикации" without causal evidence.

126. Before/after methodology deferred

Полная causal/temporal comparison будет Mathchast_34. Здесь analytics engine только обеспечивает quality data and time snapshots.

127. Content edits and analytics

Major update: publication version event report timeline: before version 4 after version 5 Search data: same publication_id version marker overlay.

128. Do not reset analytics after update

Сохранять lifetime + per-version/per-window views.

129. Redirect analytics

old URL hits → 301 → new URL server metric: redirect hits search data: may temporarily appear on old/new URLs normalize: publication identity but retain raw URL dimension.

130. Domain migration

При будущем переезде domain-level отчет должен сохранять continuity по publication_id и отдельно показывать migration date.

131. Archived publication

ARCHIVED but public: health continues search history preserved REMOVED: health state expected 404/410/redirect search removal tracked historical report preserved.

132. 404 vs incident

404 является Critical только если publication lifecycle ожидает ACTIVE. Для намеренно removed URL это expected state.

133. Health expected-state engine

ACTIVE: expect 200/indexable MOVED: expect redirect → canonical target REMOVED: expect 404/410 per policy PREVIEW: expect noindex/auth ARCHIVED: depends archive policy.

134. Client SLA connection

If ACTIVE paid publication: HTTP 5xx > threshold → incident → restore → SLA measurement External Google not indexed: not platform uptime SLA.

135. Publication uptime

Это одна из действительно контролируемых premium promises позже: public URL availability.

136. Uptime measurement

synthetic checks multi-region later interval status latency exclude: scheduled maintenance per policy report: availability %, incidents.

137. Not P0 multi-region SLA

В MVP достаточно external uptime monitor + own health worker. Formal SLA появится в Mathchast_42.

138. Search Console credentials

Google service/OAuth access stored server-side least privilege read-only where possible secret rotation audit. Yandex OAuth: same principles.

139. Search Console ingestion failure

Source status: DELAYED dashboard: «Данные Google временно не обновляются. Последняя синхронизация: ...» Do not: replace with zeros.

140. Source freshness states

FRESH DELAYED STALE ERROR per: Google Performance Google URL Inspection Yandex first-party analytics AI monitoring.

141. Backfill

Если API был недоступен 2 дня, job должен уметь backfill historical date windows where source allows it.

142. Search Analytics ingestion

daily: request prior final days + optional fresh data store upsert by: source date publication/page query dimension retain: data_state.

143. RowLimit/pagination

Search Console API поддерживает rowLimit до 25 000 и startRow pagination, но документация всё равно предупреждает, что API не гарантирует все rows.

Использовать pagination для максимального доступного coverage, но не представлять результат как exhaustive query universe.

144. Site-wide vs page filter

client report: filter by exact canonical page or normalized URL history site intelligence: property-level aggregation.

145. Search data ownership

В оферте/privacy/business terms описать, что «Матчасть» может использовать агрегированные/de-identified site-wide performance data для улучшения продукта и редакционного анализа, без раскрытия private client analytics.

146. Research use of aggregated analytics

Potential future: "Как быстро индексируются B2B cases" Use: aggregated anonymous platform dataset Need: methodology privacy no individual client disclosure.

147. Search latency benchmark as data moat

Через год «Матчасть» сможет иметь собственные distributions:

median time: publish → first crawl publish → index observed publish → first impression publish → first click by: format topic content quality not as guarantee.

148. This can improve client expectations

"Для похожих материалов: median first Google impression = X days P25–P75 = ..." Clearly: historical benchmark not SLA.

149. Publication Health as sales proof

Даже до большого трафика клиент получает tangible proof: live URL, canonical, sitemap, crawler visibility, structured data and external search observations.

150. Search Proof as repeat engine

Published → impressions → visible queries → gaps → topics competitors cover → next publication This bridges: Doc 32 → 33 → 35.

151. Search query → content gap

Article gets impressions for: "AI visibility report" but no clicks → snippet/intent review Company gets no coverage for: "AI agents security" → gap candidate.

152. CTR interpretation

Low CTR can depend on position, query intent, SERP features and brand recognition. Не выдавать «низкий CTR = плохой заголовок» автоматически.

153. Position interpretation

Average position fluctuates and aggregates multiple impressions. Не строить contract/KPI вокруг одной average position number.

154. Search impressions as early signal

Для новых публикаций impressions часто полезнее clicks: они показывают, что page начала участвовать в поисковой выдаче даже до значимого traffic.

155. Zero impressions after 30d

Investigate: index state? topic demand? canonical? content usefulness? internal links? query fit? new site age? Do not automatically: refund / republish duplicate.

156. Search health alert logic

If: was indexed then suddenly excluded → alert If: impressions drop 90% → diagnostic, not incident automatically If: canonical switches unexpectedly → alert.

157. External data anomaly vs page issue

Перед массовым alert по 500 публикациям проверять site-wide source anomaly / Search Console incident / deploy.

158. Analytics architecture

PUBLIC SITE ↓ first-party event collector ↓ event queue ↓ aggregator ↓ PostgreSQL analytics tables HEALTH WORKER ↓ health snapshots GOOGLE CONNECTOR ↓ Search Console snapshots YANDEX CONNECTOR ↓ Webmaster snapshots REPORT SERVICE ↓ client dashboard / PDF

159. Do we need ClickHouse immediately?

Нет. Для MVP и ранних объёмов PostgreSQL + daily aggregates достаточно. Вынос event analytics в ClickHouse/аналитическое хранилище нужен после реального роста.

160. Existing server fit

Существующий PostgreSQL/Redis/MinIO и 64 GB RAM более чем достаточны для первых client/report workloads. Worker architecture из server audit хорошо подходит для crawler and connector jobs.

161. Recommended services

mathchast_backend mathchast_worker mathchast_crawler mathchast_analytics_worker later: mathchast_connectors mathchast_report_worker

162. Redis queues

health_fast health_periodic search_google search_yandex analytics_aggregate reports alerts

163. Rate limiting external APIs

Google Inspection quota и Yandex reindex quotas учитываются централизованно; важные paid URLs имеют priority, а не каждый public entity проверяется одинаково часто.

164. Prioritization

P0: active paid publication incident P1: new paid publication research flagship P2: editorial evergreen P3: low-value old page observation.

165. Caching inspection results

same URL recent snapshot no meaningful page change → do not call API repeatedly.

166. External API raw response

Сохранять нормализованные fields + ограниченный raw payload/reference для debugging, но не строить всю систему на непрозрачном JSON blob.

167. Connector schema version

source_version mapping_version ingested_at If Google/Yandex changes API: migrate parser without rewriting history.

168. Alert delivery

Internal: Slack/Telegram/email later incident dashboard Client: only meaningful client-affecting issues No: "schema optional property warning" at 03:00.

169. Client alert examples

Critical: «Публикация временно недоступна. Команда уже устраняет проблему.» Resolved: «Страница снова доступна. Недоступность: 14 минут.» Search: «Google изменил выбранный canonical. Мы проверяем причину.»

170. What client should NOT be alerted about

API retry one bot 429 temporary preliminary search dip internal queue lag optional metadata warning.

171. Internal incident correlation

100 URLs show noindex same deploy → one incident not: 100 independent tickets.

172. Report credibility

Каждый PDF/web report должен иметь раздел «Как считаем» и автоматически генерируемый data cutoff.

173. Client export

PDF: executive summary CSV: daily metrics queries where source permits distribution data No: raw personal analytics events.

174. Agency export later

publication_id client URL health Google indexed G impressions/clicks Y impressions/clicks reader metrics report date.

175. Public analytics?

Не показывать публичный счётчик просмотров на каждой статье в MVP. Это создаёт vanity/gameability и раскрывает коммерческую информацию.

176. Editorial can use analytics internally

what readers save second-click source clicks research shares search queries → improve newsroom not chase clicks only.

177. Paid vs editorial comparison

Полезно internally смотреть quality outcomes, но не превращать в публичный leaderboard клиентов.

178. Publication analytics does not equal client analytics

Publication analytics: our page Client's own website: outside system unless UTM/lead integration Cannot see: sale CRM conversion unless client connects data later.

179. Future GA/CRM connector

P2: клиент может добровольно подключить own analytics/CRM to measure downstream outcomes. Не MVP и требует строгой privacy/permissions model.

180. UTM client attribution

official-site CTA: utm_source=mathchast utm_medium=referral utm_campaign=publication_id optional Client sees: their analytics can attribute Mathchast referrals.

181. UTM not on every editorial source

Не добавлять Mathchast campaign UTM на внешние editorial sources. Tracking applies to intentional client/owned campaign destinations, not scholarly/source citations.

182. First-party analytics vendor

Архитектурно не зависеть от Google Analytics для client product. Можно использовать GA/Matomo/Umami/PostHog для внутреннего удобства, но billable client metrics должны иметь собственный event definition/data store.

183. Why

контроль definitions;
stable publication_id;
internal distribution attribution;
privacy model;
не зависеть от внешнего UI/API;
возможность строить reports из одного normalized layer.

184. Client metrics immutable?

Raw observations immutable, aggregates can be recomputed when bug fixed. Report snapshots remain immutable with annotation/correction.

185. Analytics correction

bug: bot traffic included fix: recalculate historical aggregate dashboard: updated old PDF: retained + correction note / new report if material.

186. Metric confidence

Не нужен fake confidence score. Use data quality labels:

FINAL PRELIMINARY PARTIAL DELAYED ESTIMATED UNAVAILABLE

187. Google final/preliminary mapping

Search Console API: dataState final → FINAL dataState all/hourly_all with incomplete metadata → PRELIMINARY.

188. Report annotations

publication update Google anomaly site incident campaign boost Telegram post major external event → chart annotation.

189. Why annotations matter

Без них клиент видит spike и начинает придумывать причинность.

190. Research use: distribution benchmarks

After enough data: median views by format median first impression query breadth related CTR Used: internal planning client historical benchmarks later.

191. Never promise benchmark before sample

«Средняя статья получает 1 200 просмотров» нельзя писать, пока нет устойчивой выборки и понятной methodology.

192. Publication Health P0

P0: HTTP/status canonical robots/meta sitemap presence lastmod JSON-LD parse/consistency assets disclosure link rel internal relation check IndexNow send/log health snapshots incident alert first-party pageviews meaningful read basic outbound clicks distribution source UTM/referrer classification.

193. Search Proof P1

Google: Search Console property URL Inspection Search Analytics Yandex: Webmaster API important URLs search queries index observations Client: +7/+30 reports timeline query table data freshness labels.

194. P1.5 / AI-referral layer

ChatGPT referrals known AI referrers OAI-SearchBot logs crawler dashboard Do not yet: claim full AI citation coverage.

195. P2

historical benchmarks advanced anomaly detection agency exports client own analytics connectors lead/CRM attribution search query clustering brand/non-brand data warehouse advanced uptime/SLA.

196. Что НЕ строить в MVP

Не строим	Почему
Generic Google Indexing API submission for articles	Официально не предназначен для них
One «SEO score»	Ложная точность
Guaranteed index badge	External outcome
Realtime Search Console claims	Source has delays/preliminary data
Public view counters	Vanity/gaming
Client raw IP/session export	Privacy/no need
Full causal ROI attribution	Needs separate methodology/data

197. Acceptance test для одной новой статьи

Publish article Within minutes: ✓ URL 200 ✓ canonical ✓ schema ✓ sitemap ✓ IndexNow log ✓ analytics ✓ disclosure/links Later: Google crawler observed Google index state observed Yandex state observed As data arrives: impressions clicks queries reads outbound referrals At +30: reproducible client report.

198. Acceptance test migration

Change URL old: 301 → new new: 200 self canonical sitemap updated internal links updated analytics: same publication_id Search Proof: old/new raw states preserved continuity maintained.

199. Acceptance test external delay

Google data unavailable 48h Dashboard: last synced timestamp DELAYED no fake zeros Later: backfill report updates.

200. Acceptance test incident

deploy breaks canonical on all cases canary catches → one template incident → stop further deploy/alert → fix → recheck all affected → IndexNow/update where meaningful → audit.

201. Главный коммерческий экран после публикации

Не «Статья опубликована», а «Путь публикации»:

Технически готова ✓ ↓ Google посетил ✓ ↓ Google index observed ✓ ↓ Первые показы ✓ ↓ Первые клики ✓ ↓ Читатели переходят на профиль/сайт ✓ ↓ AI referrals / Visibility ↓ Следующий пробел

202. Это превращает waiting time в продукт

Клиенту не приходится каждые два дня вручную гуглить заголовок или писать менеджеру «она уже индексируется?».

203. Связь с unit economics

Publication Health mostly automated → высокий marginal value при низкой variable cost. Search Proof increases perceived value базового SKU и создаёт естественный upsell в monitoring.

204. Связь с Reader Product

search impression → visit → meaningful read → related click → follow/save → return Doc 32 supplies: measurement Doc 27: reader experience.

205. Связь с AI Visibility

Publication Health: can AI crawler access? Referral: did ChatGPT send traffic? AI Visibility: did models mention/cite brand/page? Three different questions.

206. Связь с Next Best Publication

Observed queries + content gaps + AI source gaps + entity coverage → next publication brief.

207. Основной anti-pattern

BAD REPORT: SEO score 94 Indexed ✓ Views 1,340 Position 7 AI ready ✓ GOOD REPORT: Mathchast checks: all technical checks healthy Google Search Console: indexed state observed on date X 420 impressions / 31 clicks in window queries shown are partial/top data Yandex: searchable observed ... Mathchast: 612 reads 37 official-site clicks ChatGPT: 6 attributable referrals Limitations: external inclusion/position not guaranteed.

208. Рекомендованный MVP dashboard status

PUBLICATION HEALTH Healthy DISCOVERY Google: observed indexed Yandex: observed in search PERFORMANCE 30d Search impressions Search clicks Reads Outbound clicks REFERRALS Search Internal Telegram ChatGPT Other

209. Решение документа

Утвердить Publication Health + Search Proof как два раздельных продукта данных. Publication Health проверяет только то, что контролирует «Матчасть»: HTTP, canonical, robots, sitemap, JSON-LD, assets, disclosures, outbound rel, internal graph and crawler policy. Search Proof хранит timestamped observations из Google Search Console и Яндекс Вебмастера: crawl/index/searchable state, canonical, impressions, clicks, queries и позиции в их фактическом source scope. IndexNow используется как notification protocol, но его HTTP 200 не трактуется как индексирование. Google generic Indexing API для обычных статей не используется, потому что официально он ограничен JobPosting/BroadcastEvent. First-party analytics измеряет чтение, internal navigation, company/profile/official-site clicks и source attribution; ChatGPT referrals выделяются по официальному utm_source=chatgpt.com, но не подменяют AI citation monitoring. Все метрики имеют source, data cutoff, definition version и FINAL/PRELIMINARY/DELAYED state. Отчёты строятся на +7/+30/+60, сохраняют timeline и постепенно приводят пользователя к Mathchast_33/34/35.

210. Что этот документ разблокирует

Mathchast_32 Publication Health → Mathchast_33 AI Visibility metrics → Mathchast_34 before/after methodology → Mathchast_35 Next Best Publication → Mathchast_37 agency reporting → Mathchast_38 GTM proof → Mathchast_40 technical architecture → Mathchast_42 monitoring/SLA/incidents → Mathchast_43 MVP roadmap

Источники исследования

Health thresholds, check schedules, event taxonomy, +7/+30/+60 report windows, meaningful-read definition, internal severity model, storage schemas, source freshness states, client wording and P0/P1/P2 scope are проектные решения «Матчасти». External systems are explicitly treated as observations rather than guarantees. Before implementation, API quotas, authorization scopes and current provider fields should be revalidated against live documentation.