МАТЧАСТЬ / STRUCTURED DATA & MACHINE READABILITY / DOCUMENT 21 / 02.09.2026

Structured Data и машиночитаемость «Матчасти»

Как превратить внутренний Entity Graph в понятные поисковикам и внешним системам страницы: JSON-LD, Organization, Person, Article, NewsArticle, Dataset, BreadcrumbList, WebSite, mainEntity, sameAs, идентификаторы, авторство и provenance. Документ отделяет внутреннюю модель данных от экспортной Schema.org-проекции и фиксирует правила, при которых разметка остаётся честной и поддерживаемой.

JSON-LDосновной формат structured data для «Матчасти»

1 graphединые @id связывают publisher, автора, компанию, публикацию и тему

visible = markupразметка не должна утверждать больше, чем реально видно на странице

0гарантий rich result / ranking / AI citation только за счёт schema

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

Внутренняя модель «Матчасти» богаче Schema.org, а JSON-LD является её аккуратной публичной проекцией. Мы не проектируем базу под требования конкретного rich result. Сначала хранится правильный Entity Graph, затем сервер формирует подходящую разметку для конкретного типа страницы.

INTERNAL SOURCE OF TRUTH PostgreSQL Entity Graph │ ├─ entities ├─ relations ├─ claims ├─ verification ├─ publications ├─ sources └─ versions ↓ STRUCTURED DATA MAPPER ↓ JSON-LD ↓ Google / Yandex / generic parsers / future consumers

2. Structured data не является SEO-магией

Google прямо указывает: structured data помогает понять содержание страницы и может сделать страницу eligible для расширенного отображения, но даже корректная разметка не гарантирует rich result. Яндекс также сообщает, что Schema.org может использоваться полностью или частично и не гарантирует показ размеченной информации в выдаче.

Нельзя продавать «Schema.org-разметку» как гарантию роста позиций. Это инфраструктура понимания и качества данных.

3. Формат: JSON-LD

Google поддерживает JSON-LD, Microdata и RDFa и рекомендует JSON-LD. Яндекс также умеет обрабатывать JSON-LD для ряда сценариев и предоставляет валидатор. Для «Матчасти» выбираем JSON-LD как единственный основной формат, чтобы не размазывать semantic logic по HTML-шаблонам.

Формат	Решение	Почему
JSON-LD	Основной	Отделяется от presentation layer, удобно генерировать из Entity Graph, хорошо тестируется.
Microdata	Не основной	Слишком тесно связывает данные с HTML-разметкой.
RDFa	Не основной	Нет отдельной пользы для нашего MVP.

4. Главный quality rule: видимый контент и JSON-LD совпадают

Google запрещает misleading structured data и разметку контента, скрытого от пользователя. Если в JSON-LD указано «500 сотрудников», но на странице этого факта нет или он не подтверждён, мы создаём ненужный риск.

DATABASE FACT → allowed for public? → verified enough? → visible on page? → then structured data НЕ: database contains marketing claim → silently insert into JSON-LD → user never sees it

5. Один reusable semantic graph на странице

Лучше формировать один согласованный JSON-LD graph, чем пять независимых блоков, где организация называется по-разному.

@graph: WebPage Article Person Organization BreadcrumbList links via: "@id": "https://mathchast.com/companies/acme#entity" "@id": "https://mathchast.com/experts/ivan#person" "@id": "https://mathchast.com/#publisher"

Это проектная архитектура JSON-LD. Она упрощает consistency и повторное использование объектов.

6. Стабильные @id

Entity	@id pattern
Mathchast publisher	`https://mathchast.com/#publisher`
WebSite	`https://mathchast.com/#website`
Company entity	`https://mathchast.com/companies/acme#entity`
Person	`https://mathchast.com/experts/ivan#person`
Article	`https://mathchast.com/articles/x#article`
WebPage	`https://mathchast.com/articles/x#webpage`

Если slug меняется и старый URL редиректится, mapper должен обновить публичный @id на canonical URL, а внутренняя entity identity всё равно остаётся immutable UUID.

7. Главная страница: WebSite

Google использует WebSite structured data на главной странице как главный сигнал предпочтительного site name. Для mathchast.com:

{ "@type": "WebSite", "@id": "https://mathchast.com/#website", "url": "https://mathchast.com/", "name": "Матчасть", "alternateName": ["Mathchast", "mathchast.com"] }

Google отдельно отмечает, что WebSite site-name markup размещается на доменной главной странице, а не на каждом внутреннем URL.

8. Издатель «Матчасть»: Organization

Google рекомендует Organization markup на home/about page самой организации, чтобы лучше понять административные данные и disambiguate организацию. Это подходящий use case для самой «Матчасти» как издателя.

Mathchast Publisher Organization: name legalName url logo description contactPoint address if applicable taxID if appropriate/public sameAs verified external identities publishingPrinciples foundingDate later

Не копировать в publisher Organization чужие company entities. Publisher = организация, управляющая «Матчастью».

9. Company pages: важный нюанс

Google Organization guide в первую очередь описывает разметку собственной организации сайта. Карточка внешней компании в business directory — другой use case. Schema.org Organization всё равно корректно описывает сущность, но мы не должны обещать клиенту «Google Organization rich result» только потому, что вставили Organization JSON-LD.

Для внешней company page базовая схема:

WebPage └─ mainEntity → Organization Organization: name legalName if public/verified url = official site identifier / taxID where appropriate sameAs only true same-entity pages logo description address where public/relevant WebPage: url = Mathchast company page mainEntity = Organization @id

10. Company page example

{ "@context":"https://schema.org", "@graph":[ { "@type":"WebPage", "@id":"https://mathchast.com/companies/acme#webpage", "url":"https://mathchast.com/companies/acme", "name":"Acme — профиль компании", "mainEntity":{"@id":"https://mathchast.com/companies/acme#entity"}, "isPartOf":{"@id":"https://mathchast.com/#website"} }, { "@type":"Organization", "@id":"https://mathchast.com/companies/acme#entity", "name":"Acme", "legalName":"ООО «Акме»", "url":"https://acme.ru/" } ] }

Это проектный пример «Матчасти», не готовая универсальная рекомендация Google для любого каталога.

11. Brand и Legal Entity не смешивать

Schema.org имеет отдельный тип Brand. Если публичная страница описывает бренд, а не конкретное юрлицо, structured data должно следовать смыслу внутренней entity.

BRAND: @type Brand name "Example" ORGANIZATION: @type Organization legalName "ООО Example Tech" relations: brand / owner / parentOrganization в зависимости от фактической связи

12. sameAs: только идентичность

Schema.org определяет sameAs как URL страницы, которая однозначно указывает на тот же объект. Это не «любая ссылка, где нас упомянули».

URL	sameAs?
Официальный verified профиль компании в авторитетном сервисе	Да
Wikidata entity той же компании	Да
Официальная социальная страница	Да
Статья в СМИ о компании	Нет
Кейс партнёра с упоминанием компании	Нет
Случайный каталог с похожим названием	Нет

13. identifier

Schema.org поддерживает общий identifier, а Google Organization documentation также распознаёт конкретные administrative identifiers вроде taxID и iso6523Code. Внутренняя таблица identifiers документа 19 должна маппиться только в соответствующие публичные свойства.

INTERNAL: scheme=INN value=... PUBLIC: taxID where semantically appropriate INTERNAL: scheme=LEI → iso6523Code = 0199:... НЕ: пихать все internal UUID, fraud IDs и private keys в публичный JSON-LD.

14. Экспертные страницы: ProfilePage только для подходящего use case

Google говорит, что ProfilePage предназначен для сайтов, где creator — человек или организация — публикует first-hand perspectives. В качестве неподходящего примера Google прямо приводит review site с организацией, не связанной с сайтом.

Поэтому эксперт, который реально является автором/контрибьютором «Матчасти», может быть кандидатом на ProfilePage. Просто внешняя Person directory card — нет автоматически.

Страница	Markup
Эксперт публикует колонки на «Матчасти», есть author activity	`ProfilePage` + `mainEntity: Person`
Эксперт только упомянут в базе, не создаёт контент на площадке	`WebPage` + `mainEntity: Person`
Обычная внешняя company-directory page	Не использовать Google ProfilePage автоматически

15. Person

Person fields: name alternateName where real url = Mathchast creator profile if applicable sameAs verified identity pages jobTitle if visible/current affiliation where accurate image description identifier internal/public where appropriate

Исторические employment relations во внутреннем graph богаче, чем Schema.org markup. В JSON-LD выводим только корректное и понятное текущему page context представление.

16. Article family

Google поддерживает Article, NewsArticle и BlogPosting. Разметка может помочь Google понять заголовок, изображения, даты и автора.

Mathchast type	Schema
Обычный разбор / экспертная статья	`Article`
Новость	`NewsArticle`
Кейс	`Article` + structured internal case relations
Интервью	`Article`
Research article без downloadable dataset	`Article`
Research page с реальным dataset	`Article` + `Dataset` object

17. CaseStudy как внутренний тип, а не выдуманная Google-схема

Не придумывать @type: "CaseStudy", если такого типа нет в используемом словаре/поддерживаемой модели. Внутри CMS кейс остаётся отдельным content type, а наружу маппится на валидный Article и связанные Organization entities.

18. Article core fields

Article: headline description image datePublished dateModified author publisher mainEntityOfPage about mentions citation where useful isBasedOn where appropriate PLUS: Mathchast internal relations не обязаны все иметь Schema.org-аналог.

19. Авторство

Google рекомендует включать всех видимых авторов, каждого отдельно; указывать корректный type Person/Organization и по возможности URL или sameAs. В author.name должно быть именно имя автора, а не должность, издатель или «написано экспертом».

GOOD: author: [ { "@type":"Person", "name":"Иван Иванов", "url":"https://mathchast.com/experts/ivan" } ] BAD: author.name = "Иван Иванов, CMO компании X, эксперт Матчасти"

20. Publisher

В обычном Mathchast Article publisher = «Матчасть», даже если автор — внешний эксперт или компания.

Коммерческий advertiser/sponsor не должен подменять publisher. Он хранится отдельной relation и раскрывается visible disclosure.

21. datePublished / dateModified

Поле	Правило
datePublished	Дата первой публичной публикации
dateModified	Только при реальном содержательном обновлении
Background analytics update	Не менять dateModified
Correction	Менять при существенной правке + visible correction/update context

Это синхронизируется с lastmod из документа 18 и versioning из документа 16.

22. Image markup

Google для Article рекомендует несколько high-resolution изображений, в частности с пропорциями 16:9, 4:3 и 1:1; image URLs должны быть crawlable/indexable и соответствовать размеченному контенту.

Для «Матчасти» visual pipeline стоит сразу уметь генерировать несколько editorial crops одного approved master visual.

MASTER → 16:9 → 4:3 → 1:1 metadata: asset_id source/provenance width height mime public URL alt AI-generated flag if applicable

23. Dataset для собственных исследований

Google поддерживает Dataset, DataCatalog и DataDownload для описания настоящих наборов данных. Dataset markup должен описывать dataset metadata, а не просто любую статью с цифрами.

Research output	Dataset?
CSV/JSON/XLSX с результатами исследования	Да
Публичная таблица данных с определённой структурой	Да
Статья «мы опросили 100 компаний», но data не опубликованы	Article; Dataset только если есть реально описываемый dataset
Обычная новость с одной цифрой	Нет

24. Dataset core

Dataset: name description creator datePublished dateModified license identifier sameAs if same dataset elsewhere distribution: DataDownload contentUrl encodingFormat temporalCoverage / spatialCoverage where relevant measurementTechnique where appropriate

Для «Матчасти» это сильная будущая возможность: собственные исследования становятся не только статьями, но и реально обнаруживаемыми data assets.

25. Provenance для research

Dataset structured data особенно хорошо сочетается с нашим provenance-aware Entity Graph.

Research Publication → creator Mathchast → dataset → methodology page → source data → download → version → license → publication date Это сильнее, чем PDF без metadata.

26. BreadcrumbList

Google и Яндекс используют BreadcrumbList. Яндекс отдельно поддерживает BreadcrumbList в JSON-LD для навигационных цепочек.

Article: Главная → Статьи → Заголовок Case: Главная → Кейсы → Название кейса Company: Главная → Компании → Acme

Breadcrumb должен соответствовать видимой навигационной логике сайта.

27. Topic pages

Для curated topic hub базовый semantic type может быть CollectionPage или WebPage с about/mainEntity на Topic-like concept. Не нужно пытаться создать fake Google rich-result type, которого нет.

Главная задача topic page — понятный HTML и graph links. Structured data — вспомогательный слой.

28. ItemList для списков

ItemList можно использовать для машинного описания curated lists, когда порядок имеет смысл. Но это не означает, что Google покажет специальный rich result.

Topic hub: CollectionPage → mainEntity Topic concept → hasPart / main content → ItemList selected publications Directory: CollectionPage → list of organizations Не: тысяча nested entities в одном JSON-LD ради "максимум schema".

29. about vs mainEntity

Schema.org data model различает:

Property	Смысл	Пример
mainEntity	Главный объект, который описывает страница	Company page → Organization
about	О чём CreativeWork; объектов может быть несколько	Article → Company X, AI Visibility, SaaS
mainEntityOfPage	Обратная связь entity/creative work с основной страницей	Article → canonical WebPage
sameAs	Другой URL того же самого объекта	Organization → verified Wikidata/profile

Не использовать sameAs вместо about.

30. mentions

Для публикаций можно проецировать approved entity mentions в mentions / about. Но не нужно экспортировать каждый автоматически распознанный AI candidate.

internal mention: candidate → editor approved → meaningful relation? → then eligible for public structured data unapproved LLM extraction → stays internal

31. citations

Schema.org CreativeWork поддерживает citation relationships. Это подходит для research-heavy материалов, но Google Article rich-result docs не делают citation обязательным полем.

Мы можем использовать citation для generic machine readability, при этом обычные HTML-ссылки на источники остаются обязательными для человека.

32. publishingPrinciples

Schema.org Organization поддерживает publishingPrinciples — URL документа с принципами издателя. Для «Матчасти» это хороший semantic bridge к Mathchast_14.

publisher Organization: "publishingPrinciples": "https://mathchast.com/policies/editorial"

33. Рекламный статус в schema

Не существует волшебного Schema.org-поля, которое заменяет российскую маркировку «Реклама», advertiser info и erid.

Коммерческий статус должен:

быть видим в HTML;
храниться в data model;
влиять на ссылки;
попадать в compliance workflow.

Schema.org можно использовать для publisher/sponsor/author relations там, где это семантически корректно, но правовая маркировка живёт отдельно.

34. sponsor

Research funded by Company X: Article/Research: sponsor → Organization X VISIBLE: "Исследование подготовлено при поддержке X" Если это реклама: дополнительно российская маркировка НЕ: sponsor schema = замена disclosure

35. author, contributor и sponsor не смешивать

Роль	Property
Человек написал материал	author
Организация издала материал	publisher
Компания профинансировала исследование	sponsor
Компания является темой статьи	about
Компания просто упомянута	mentions

36. Case relationships

Schema.org не передаёт всю нашу case semantics. Поэтому:

INTERNAL: VENDOR_IN_CASE → Agency CLIENT_IN_CASE → Brand RESULT_CLAIM → +40% PUBLIC JSON-LD: Article about → relevant organizations author publisher mentions VISIBLE HTML: "Исполнитель" "Клиент" "Результат" Future: additional semantic mapping if standards support it.

37. Verification badges и structured data

Не придумывать нестандартные свойства типа "verified": true внутри Schema.org object, если это не определено словарём.

Verification живёт:

в visible UI;
во внутренней data model;
в properties, которые реально отражают подтверждённые facts;
в публичной methodology page.

Позже можно предоставить отдельный public API/provenance endpoint, но не загрязнять стандартный Schema.org несуществующими полями.

38. Claim provenance не помещается полностью в Schema.org

Это нормально. Structured data не должна быть копией всей базы.

PUBLIC PAGE: "Основана: 2018" [Источник] Schema: foundingDate: 2018 Internal: claim_id source_id verified_at validity agent confidence version

39. Structured data generator как отдельный backend module

PageViewModel → SemanticMapper → JSON-LD graph Mapper rules: company_page() expert_page() article_page() news_page() case_page() research_page() topic_page() homepage() NO: редактор вручную вставляет JSON-LD в rich-text editor.

40. Schema versioning

Schema.org и поисковые требования меняются. Значит mapper должен иметь версию.

semantic_mapper_version = 1.3 publication health stores: last_generated validation_result mapper_version после rule update: bulk re-render without touching article content.

41. Server-side generation

JSON-LD генерировать на сервере одновременно с HTML. Не зависеть от отдельного client-side fetch, который может не успеть выполниться или рассинхронизироваться.

42. SSR + visible data consistency

SERVER: fetch entity graph → build page model → render visible HTML → render JSON-LD from SAME model не: HTML from database A JSON-LD from stale cache B

43. Cache invalidation

Event	Нужно перестроить JSON-LD?
PublicationUpdated	Да
Author relation changed	Да
Company legalName verified	Да на company page / related where rendered
View counter +1	Нет
Internal AI embedding refresh	Нет

44. Rich Results Test vs Schema Markup Validator

Tool	Что проверяет
Google Rich Results Test	Google-specific supported rich-result types и ошибки
Schema Markup Validator	Общую корректность Schema.org vocab
Yandex structured data validator	Распознавание разметки и требования Яндекс-сервисов
URL Inspection	Что Google реально видит на deployed URL

45. CI validation

Разметку нужно тестировать в CI, а не проверять вручную после запуска.

TEST FIXTURES: company_verified.html company_brand.html expert_creator.html article.html case_partner.html research_dataset.html news.html topic.html CI: parse JSON-LD validate required internal rules snapshot test check canonical consistency fail deploy on critical semantic errors

46. Internal semantic linter

ERROR: Article author not visible Company JSON-LD name != visible name canonical URL mismatch dateModified < datePublished sameAs points to Mathchast media mention Dataset has no actual dataset ProfilePage used on plain external company directory advertiser injected as publisher → BLOCK / WARNING

47. Public content should remain understandable without JSON-LD

JSON-LD — дополнительный semantic channel, не замена хорошему HTML.

Если удалить script JSON-LD, пользователь и crawler всё равно должны видеть:

заголовок;
автора;
дату;
компанию;
источники;
disclosure;
основной текст;
связанные сущности.

48. Open Graph и social metadata

Open Graph не заменяет Schema.org, но нужен как отдельная presentation metadata layer для социальных превью.

HEAD META LAYERS: title / description canonical robots Open Graph Twitter-like card metadata where relevant JSON-LD alternate/RSS later

Все слои должны брать название/URL/изображение из одного PageViewModel.

49. Duplicate metadata

Нельзя допускать ситуацию: canonical говорит URL A, og:url — URL B, JSON-LD url — URL C.

SOURCE OF TRUTH: canonical_url used by: og:url WebPage.url Article.mainEntityOfPage sitemap share links

50. Site name consistency

Google учитывает WebSite structured data, og:site_name, title/headings и visible homepage content. Поэтому публично везде используем одно основное имя: «Матчасть», с Mathchast как альтернативным латинским вариантом при необходимости.

51. Company name consistency

visible: Acme JSON-LD name: Acme legal block: ООО «Акме» JSON-LD legalName: ООО «Акме» НЕ: visible "Acme" JSON-LD name "Лучший сервис Acme №1"

52. Topic vocabulary

Schema.org не решит за нас ontology topics. Topic node и aliases остаются внутренними, а наружу мы можем использовать:

about;
keywords;
DefinedTerm / DefinedTermSet там, где это оправдано;
topic URLs как нормальные HTML links.

Не перегружать MVP сложной semantic-web ontology только потому, что она возможна.

53. keywords

keywords не должны превращаться в скрытый SEO keyword stuffing.

Если используем keywords в Article, они генерируются из утверждённых topic relations, а не из списка коммерческих запросов клиента.

54. Language

HTML: lang="ru" Article: inLanguage = "ru" future EN translation: separate page inLanguage = "en" correct canonical/hreflang architecture later

55. Research methodology as machine-readable relation

У каждого исследования может быть:

Research Article → isBasedOn → source material / dataset → subjectOf / about → topics → creator → publisher → Dataset → methodology URL → license → citation list

Даже если конкретное свойство не влияет на Google rich result, оно может быть полезно generic consumers и нашей собственной consistency.

56. External API vs JSON-LD

JSON-LD страницы достаточно для public semantic layer MVP. Отдельный open API не нужен только ради «машиночитаемости».

API появится, когда будет реальный consumer use case: агентства, analytics, партнёры, research exports.

57. Не публиковать private internal graph

Internal data	JSON-LD?
Verified public legalName	Да при уместности
Public official domain	Да
Fraud risk score	Нет
Verification document metadata private	Нет
Unpublished claim candidate	Нет
Private agency/client contract	Нет
Public sponsor relation	Может быть

58. Structured data и AI systems

Структурированная разметка полезна как дополнительный явный сигнал сущностей, но «Матчасть» не должна утверждать, что Schema.org гарантирует попадание или цитирование в ChatGPT, Gemini или другие AI-системы.

AI machine-readability строится шире:

ясный HTML;
stable URLs;
explicit entities;
sources;
structured data;
sitemaps;
crawler accessibility;
consistent naming;
original information.

Crawler rules и AI bots будут разобраны в Mathchast_22.

59. Почему Entity Graph важнее «schema plugin»

PLUGIN APPROACH: page title → generates some JSON-LD MATHCHAST APPROACH: verified entity graph → knows legalName → knows brand → knows author relation → knows company role in case → knows source → knows sponsor → knows topic → produces consistent JSON-LD Разница = data quality.

60. Company page machine-readable contract

VISIBLE + SEMANTIC: WebPage mainEntity Organization name legalName description url official verified identifiers where public logo address where appropriate sameAs verified identities related experts visible related publications visible NO: hidden marketing claims fake awards unverified "№1" paid links disguised as identity

61. Expert page contract

If active creator: ProfilePage mainEntity Person If directory/reference only: WebPage mainEntity Person Person: name description image jobTitle if verified/current affiliation if accurate sameAs verified url Activity: hasPart/articles only where semantically correct

62. Article page contract

WebPage Article BreadcrumbList Article: headline description image datePublished dateModified author publisher Mathchast mainEntityOfPage about mentions citation sponsor if visible inLanguage

63. News page contract

NewsArticle same base as Article + actual news event timing + source / author + datePublished + dateModified only real update НЕ: marketing press release marked as NewsArticle если по сути это рекламный landing.

64. Case page contract

Article about: Vendor organization Client organization Topics visible structured blocks: problem task process result limitations verification status internal graph keeps: VENDOR_IN_CASE CLIENT_IN_CASE RESULT_CLAIM JSON-LD does not invent unsupported custom properties.

65. Research page contract

Article + Dataset only if real dataset exists + creator/publisher + methodology visible + citation/source relations + license + DataDownload for public files

66. Topic page contract

CollectionPage / WebPage main topic visible description/definition selected related content BreadcrumbList optional: ItemList NO: indexable blank tag page with only 2 links.

67. Homepage contract

WebSite Organization publisher WebPage possibly CollectionPage semantics where appropriate site name: Матчасть alternate: Mathchast publisher: legal/admin data logo publishingPrinciples

68. Validation pipeline

DEV → schema unit tests → generic Schema validator STAGING → rendered-page parser → internal semantic lint PRODUCTION SAMPLE → Google Rich Results Test → URL Inspection → Yandex validator MONITOR → Search Console structured data reports → production crawler → alert on template regression

69. Error severity

Error	Severity
Invalid JSON-LD syntax	Critical
Author missing from Article markup	High
Marked-up fact hidden from visible page	Critical quality
Wrong canonical URL	Critical
sameAs points to media mention	High semantic error
Non-Google schema property ignored by Google	Not necessarily error if valid Schema.org
Missing optional field	Low

70. «Больше разметки» не всегда лучше

Google отдельно советует давать меньше, но полных и точных recommended properties, вместо попытки заполнить всё некачественными данными.

GOOD: 5 accurate properties BAD: 35 properties 12 guessed 8 stale 4 hidden 3 copied from marketing deck 8 inconsistent

71. Structured data spam

Google general guidelines предупреждают, что spammy/misleading markup может привести к manual action по structured data и потере eligibility для rich results.

Поэтому commercial client не может «заказать» себе дополнительные schema claims, которых нет в видимом проверенном профиле.

72. Commercial client permissions

Клиент может	Клиент не может
предложить official sameAs URL	самостоятельно редактировать JSON-LD
подтвердить legalName/domain	вставить fake award
добавить source к claim	сделать «№1» скрытым Schema property
исправить факт	назначить чужого эксперта author

73. Schema admin preview

В CMS полезно дать редактору вкладку «Machine view».

PUBLIC PREVIEW STRUCTURED DATA PREVIEW ENTITY RELATIONS SOURCES LINK REL CANONICAL INDEX STATE warnings: "sameAs not verified" "author URL missing" "Dataset has no distribution" "Organization legalName differs from visible page"

74. Open Graph и visual consistency

Один approved image asset может использоваться для:

Article.image;
og:image;
social preview;
internal feed card.

Но система может генерировать разные crops, сохраняя связь с master asset.

75. Schema migration

Schema.org / Google update → change mapper → test → bulk invalidate rendered pages → re-render JSON-LD → validate sample → monitor Не нужно: редактировать вручную 50 000 статей.

76. Что не строить в MVP

Не строить	Почему
RDF endpoint / SPARQL	Нет потребности
Собственную ontology на 500 терминов	Рано
Полный open knowledge API	Позже
Автоматический schema generation LLM без rules	Слишком высокий semantic drift
Все Schema.org types сразу	Поддержка станет хрупкой
ProfilePage для всех карточек	Неверный use case

77. MVP structured data set

P0: WebSite Organization (Mathchast publisher) WebPage Organization (company mainEntity) Person Article NewsArticle BreadcrumbList P1: ProfilePage for real contributors Dataset DataDownload CollectionPage ItemList P2: Product / Service public pages if product need appears additional research/data vocabularies

78. Event-driven regeneration

PublicationPublished → generate structured data EntityVerified → rebuild company page schema ExpertRelationshipChanged → rebuild expert + affected recent article references PublicationUpdated → dateModified + JSON-LD update EntityMerged → new canonical entity → redirects → schema references update

79. Machine readability score

Не делать публичный «AI-ready score», но внутри можно проверять:

page_machine_health canonical consistent JSON-LD valid main entity present author resolved publisher resolved dates valid sources visible sameAs verified image crawlable breadcrumb valid index state valid → PASS / WARN / FAIL

80. Structured data и Publication Health

Mathchast_32 должен мониторить structured data так же, как HTTP и canonical.

Если после deploy Article schema исчезла на 500 публикациях, это production incident.

81. Самая важная связь с будущим AI Visibility

AI Visibility layer будет намного сильнее, если бренд/эксперт/публикация уже имеют стабильную сущностную идентичность. Тогда citations и mentions можно нормализовать не только по строковому совпадению имени, а по graph entity.

"Acme" "Acme AI" "ООО Акме" "acme.ru" → same internal entity → same publication history → same AI visibility record

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

Утвердить JSON-LD mapper поверх Entity Graph. Внутренняя PostgreSQL-модель остаётся source of truth и не ограничивается Schema.org. На главной используются WebSite и Organization самого издателя. External company page моделируется как WebPage с mainEntity Organization; Google ProfilePage не используется для обычных company directory cards. Экспертные ProfilePage применяются только там, где человек/организация реально является creator на площадке. Публикации используют Article/NewsArticle, исследования при наличии реального набора данных дополняются Dataset. sameAs используется только для подтверждённой идентичности. Structured data генерируется сервером из тех же данных, что видит пользователь, проходит CI/production validation и входит в Publication Health.

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

Mathchast_21 structured data → Mathchast_22 robots / sitemap / IndexNow / AI crawlers → Mathchast_23 content types → Mathchast_24 CMS → Mathchast_26 distribution → Mathchast_28 editorial seed content → Mathchast_32 publication health → Mathchast_33 AI visibility → Mathchast_40 technical architecture

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

Конкретные @id patterns, mapper architecture, page contracts, semantic linter, CI pipeline и MVP schema set являются проектными решениями «Матчасти». Для поведения Google определяющим источником считается Google Search Central, поскольку Schema.org описывает словарь шире, чем конкретные Google features. Все machine-readable данные должны синхронизироваться с видимым содержанием, verification state и canonical URL.