МАТЧАСТЬ / INFORMATION ARCHITECTURE / DOCUMENT 18 / 02.09.2026

Информационная архитектура «Матчасти»

Какие типы страниц существуют на mathchast.com, как связать компании, экспертов, темы, публикации и исследования в один knowledge graph, какие URL должны индексироваться, что не должно попадать в поиск, как строить canonical, breadcrumbs, topic hubs, sitemap и внутреннюю навигацию без взрыва миллионов тонких страниц.

7основных публичных типов сущностей/разделов

1канонический URL на каждый самостоятельный объект

0индексируемых комбинаций фильтров по умолчанию

≤3целевых перехода от главной до ключевого публичного контента

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

Строить «Матчасть» не как блог с категориями, а как публичный business knowledge graph. Статья, компания, эксперт, тема, исследование и кейс являются отдельными сущностями, которые связываются между собой. URL-структура должна отражать тип объекта, но смысл связей хранится в data model, а не зашивается в бесконечно глубокие папки.

MATHCHAST HOME ├─ TOPICS ├─ COMPANIES ├─ EXPERTS ├─ ARTICLES ├─ CASES ├─ RESEARCH └─ NEWS ENTITY GRAPH: COMPANY ↔ EXPERT ↔ PUBLICATION ↔ TOPIC ↔ PRODUCT / SERVICE ↔ SOURCE ↔ OTHER COMPANY Навигация сайта = проекция graph, а не само хранилище graph.

2. Почему не строить всё внутри /blog/

Blog-first

/blog/category/article

Компания и эксперт становятся просто метаданными статьи. Позже трудно строить reputation, profiles, citations и data products.

Entity-first

/companies/company-name
/experts/name
/articles/slug

Каждая сущность имеет самостоятельную публичную жизнь и связи.

3. Базовая структура URL

Тип	URL	Назначение	Индексировать?
Компания	`/companies/{slug}`	Verified business entity	При eligibility
Эксперт	`/experts/{slug}`	Публичный профиль человека	При eligibility
Статья	`/articles/{slug}`	Экспертный/редакционный материал	Да
Кейс	`/cases/{slug}`	Структурированный business case	Да
Исследование	`/research/{slug}`	Исследование / dataset story	Да
Новость	`/news/{slug}`	Новостной материал	Да
Тема	`/topics/{slug}`	Curated topic hub	Только approved hub
Отрасль	`/industries/{slug}`	Business vertical	После достаточной полноты
Поиск	`/search?q=...`	Внутренний search	Нет
Фильтры	`?topic=&industry=&sort=`	UX-фильтрация	Нет по умолчанию

4. Почему короткие URL лучше глубокой иерархии

Google рекомендует логичную и понятную человеку URL-структуру. Яндекс также рекомендует уникальные URL и понятную ссылочную структуру, при этом глубина вложенности влияет на скорость обнаружения страниц.

Мы не кодируем всю taxonomy в URL. Статья может одновременно относиться к AI, маркетингу, SaaS и конкретной компании. Если зашить это в путь, один объект быстро получит несколько «естественных» адресов и начнутся canonical/duplicate проблемы.

НЕ: /marketing/ai/saas/cases/company-x/article-name ДА: /cases/article-name А связи: case → topic: AI case → topic: SaaS case → industry: Marketing case → company: X хранятся отдельно.

5. Slug policy

Правило	Решение
Читаемый slug	Да
Транслитерация русских заголовков	Основной вариант для MVP
Кириллица в URL	Технически возможна, но усложняет копирование/аналитику; не основной вариант
Дата в URL	Не нужна для большинства типов
Company ID в публичном URL	Только при collision fallback
Slug меняется при новом заголовке	Нет после публикации
Очень длинный title → очень длинный slug	Сокращать до смыслового ядра

6. Collision policy

companies/vector companies/vector-2 ← плохо как финальный UX лучше collision resolver: companies/vector companies/vector-tech или companies/vector-12345 но: canonical identity определяется internal entity_id, а не slug.

Для юридических лиц могут совпадать бренды. В публичном UI обязательно показывать disambiguation: город, отрасль, официальный сайт или юридическое имя.

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

Главная «Матчасти» должна быть reader-first, а не витриной тарифов.

/ ├─ главное исследование / материал ├─ свежие разборы ├─ темы ├─ кейсы ├─ компании / эксперты в контексте материалов ├─ research/data └─ мягкий B2B entry "Для бизнеса" НЕ: 70% hero "КУПИТЕ ПУБЛИКАЦИЮ"

Коммерческий продукт живёт в отдельной ветке /for-business, но сам публичный домен должен доказывать наличие реального медиа.

8. Раздел «Компании»

/companies → directory landing /companies/{slug} → overview → verified facts → official links → experts → publications → cases → research mentions → external media portfolio later → corrections / status

Company page не должна быть SEO-страницей, заполненной повторяющимися фразами. Основная ценность — структурированные данные и связи.

9. Index eligibility для компаний

Создание entity в базе не означает автоматическое создание индексируемой страницы.

Состояние	Публичный URL	Index	Sitemap
Imported shell	Может существовать технически	noindex / не выдавать публично	Нет
Minimal reference entity	Да	По completeness threshold	Если indexable
Claimed	Да	Не автоматически	После eligibility
Verified + meaningful data	Да	Да	Да
Verified + publications/experts	Да	Высокий приоритет	Да

Точный completeness threshold появится в Mathchast_19/20.

10. Эксперт

/experts/{slug} NAME role current company past/related affiliations where verified expertise topics bio verified links publications quotes research participation correction/contact route

Эксперт не должен быть «author archive». Это самостоятельная Person entity, которая может быть связана с несколькими компаниями и материалами во времени.

11. Статьи, кейсы, исследования и новости должны оставаться разными типами

Тип	Почему отдельный
Article	Свободная экспертная/объясняющая структура
Case	Problem → process → result; отдельные structured fields
Research	Methodology, sample, dataset, findings, limitations
News	Event date, subject, source, factual update

Позже это позволит создавать отдельные machine-readable представления и аналитические продукты.

12. Topics — важнее обычных тегов

Topic — curated entity, а не автоматически созданный tag.

topic: AI Visibility имеет: title definition scope parent topics related topics experts companies best materials research FAQ/background editorial owner index eligibility

Новый свободный тег автора не должен автоматически создавать /topics/random-keyword.

13. Topic hub как главный механизм Context Bridge

Идея «Тематического моста» становится частью архитектуры: если новая коммерческая тема действительно расширяет editorial scope, сначала/параллельно формируется curated topic node и несколько содержательных связей.

EXISTING TOPIC A ↘ BRIDGE ARTICLE ↘ NEW TOPIC B ├─ explainer ├─ expert ├─ company └─ partner case Это graph expansion, а не SEO camouflage.

14. Topic states

State	Публичность
PROPOSED	Только внутри CMS
INTERNAL	Используется для классификации, URL не индексируется
CURATED	Имеет редакционный hub
INDEXABLE	Полноценная публичная landing page
MERGED	301 на каноническую тему
ARCHIVED	Историческая тема / redirect или archive по ситуации

15. Industries

Industry — более стабильная business taxonomy, чем topic.

INDUSTRY: Software Marketing E-commerce IT Infrastructure Professional Services ... TOPICS внутри/между industries: AI Agents GEO CRM Attribution Automation ...

Не создавать сотни отраслевых pages до появления реальных компаний и контента.

16. Один объект — один canonical URL

Google и Яндекс оба рассматривают rel="canonical" как сигнал/рекомендацию при похожих и дублирующихся URL. Google дополнительно учитывает redirects, sitemap inclusion и другие сигналы.

На всех самостоятельных публичных страницах — self-canonical. В sitemap попадает только канонический URL.

https://mathchast.com/articles/example HTTP 200 canonical → https://mathchast.com/articles/example НЕ: ?utm_source=... ?ref=... ?sort=... /amp /print как отдельные canonicals

17. Tracking parameters

URL	Поведение
`/articles/x?utm_source=telegram`	200, canonical → clean URL
`?ref=company`	Canonical → clean URL; лучше tracking event без альтернативной версии контента
`?sort=new` на list	Не индексировать как отдельную страницу
`?topic=ai&industry=software`	UX filter, не отдельный search landing по умолчанию

18. Faceted navigation — потенциальный взрыв URL

Google отдельно называет faceted navigation одним из самых частых источников overcrawl: комбинации фильтров способны создать практически бесконечное URL-пространство и замедлить обнаружение полезных страниц.

Для «Матчасти» фильтры каталога не должны автоматически становиться индексируемыми URL.

/companies filters: industry topic city size verified has_cases has_experts USER: может фильтровать SEARCH BOT: не получает миллионы indexable combinations SEO landing: создаётся только вручную, если редакция признаёт её отдельным useful hub.

19. Что делать с пустыми filter combinations

Если filter URL всё же crawlable и не имеет результатов, Google рекомендует возвращать настоящий 404 для бессмысленных комбинаций, а не генерировать бесконечные пустые страницы.

Но основной MVP-подход проще: filter state не является публичным indexable content object.

20. Internal search

/search?q=crm USER: получает результаты SEARCH ENGINES: noindex не включать в sitemap не использовать как permanent topic page если запрос становится важной темой: editor creates /topics/crm

21. Breadcrumbs

Google описывает breadcrumb как способ показать место страницы в иерархии и помочь пользователю перемещаться вверх по структуре.

Страница	Breadcrumb
Article	Главная → Статьи → Материал
Case	Главная → Кейсы → Кейс
Research	Главная → Исследования → Исследование
Company	Главная → Компании → Компания
Topic	Главная → Темы → Тема

Topic association не обязательно отражать в единственной breadcrumb hierarchy, потому что материал может иметь несколько тем. Темы отображаются отдельными ссылками.

22. Structured breadcrumb

В Mathchast_21 будет детальная schema, но архитектура уже резервирует BreadcrumbList для каждого основного публичного типа.

23. Navigation depth

Яндекс рекомендует ясную ссылочную структуру и отмечает, что глубина вложенности влияет на скорость обнаружения страниц.

ЦЕЛЬ: ключевой свежий материал ≤ 3 клика от главной пример: Home → Topic → Article или: Home → Cases → Case

Не превращать архив в пагинацию на сотни экранов без альтернативных topic/entity links.

24. Связи внутри article page

ARTICLE PAGE header → author/expert → company affiliation → paid/editorial status body → source citations → mentioned entities footer/context → topics → related articles → company profile → expert profile → next useful material НЕ: 50 SEO-related links без контекста

25. Company → publication relation

Нужно различать роль компании в материале:

Relation	Пример
AUTHOR_COMPANY	Компания предоставила partner article
SUBJECT	Материал о компании
CLIENT	Клиент в кейсе агентства
VENDOR	Исполнитель/поставщик в кейсе
MENTIONED	Просто упомянута
DATA_SOURCE	Источник данных
SPONSOR	Спонсор исследования

Это важно и для публичного контекста, и для будущей AI Visibility аналитики.

26. Expert → publication relation

Relation	UI
AUTHOR	Автор
INTERVIEWEE	Герой интервью
COMMENTATOR	Экспертный комментарий
RESEARCHER	Автор/участник исследования
MENTIONED	Упоминание

27. Entity mentions внутри текста

Имена компаний и экспертов в тексте можно связывать с их entity pages только там, где это естественно для читателя. Не превращать каждое повторение названия в ссылку.

Первое релевантное упоминание — хороший default. Остальные связи доступны через structured context blocks.

28. Home feed ≠ archive

Feed

Алгоритмически/редакционно выбранные свежие материалы. Может учитывать качество, свежесть, темы и reader interests.

29. Pagination

Не использовать бесконечный JS-scroll как единственный способ доступа к старым материалам. У crawler и пользователя должны быть обычные HTML-ссылки на следующие страницы/элементы.

Яндекс прямо рекомендует обычные crawlable <a href> ссылки между документами. Google также исходит из crawlable URL discovery.

30. Sitemap architecture

Google ограничивает один sitemap 50 МБ в несжатом виде или 50 000 URL. При большем объёме используются несколько файлов и sitemap index.

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

Разделение sitemap по типам полезно даже до лимита 50 000 URL: легче диагностировать indexing health каждого класса страниц.

31. Что попадает в sitemap

URL	Sitemap?
Canonical published article	Да
Indexable verified company	Да
Draft	Нет
Noindex shell entity	Нет
Search result	Нет
Filter combination	Нет
Redirect URL	Нет
Removed URL	Нет

32. lastmod

lastmod изменяем только при существенном обновлении содержания страницы, а не при каждом background job, счётчике просмотров или косметическом render.

UPDATE lastmod: факты основной текст methodology important structured fields DON'T: view count analytics timestamp minor UI cache refresh

33. Canonical consistency rule

Для indexable URL должны совпадать: HTTP 200 self-canonical internal links → canonical sitemap → canonical hreflang later → canonical family structured data url → canonical OpenGraph url → canonical Расхождение = Publication Health error

34. Duplicate profiles

Одна из самых сложных будущих задач — company/entity duplicate resolution.

duplicate detected: "ООО Вектор" "Vector" "Вектор ИТ" same INN/domain → merge entities → choose canonical entity_id → merge relations → old public URL 301 → aliases preserved → audit history

35. Brand ≠ legal entity

Не пытаться уместить бренд, ООО и группу компаний в одну таблицу «company».

На публичной IA для MVP можно показывать одну понятную company page, но data model должен заранее различать:

ORGANIZATION ├─ LEGAL_ENTITY ├─ BRAND └─ GROUP relations: BRAND_OWNED_BY LEGAL_ENTITY_PART_OF_GROUP OPERATES_BRAND PREVIOUS_NAME SUCCESSOR_OF

Детально — в Mathchast_19.

36. Product/service pages

Не запускать публичный массовый каталог продуктов в MVP. Это быстро создаст миллионы слабых commercial pages.

Product/Service entity можно хранить внутри graph, но индексируемые публичные product pages появятся только если у них появится самостоятельный reader use case.

37. Geography

Не создавать автоматически:

/companies/moscow /companies/saas/moscow /companies/saas/moscow/ai /companies/saas/moscow/ai/verified ...

Город/регион — filter/data attribute. Публичный geographic hub появляется только при отдельной редакционной/справочной ценности.

38. Search landing pages

Запрещено автоматически превращать популярные внутренние запросы в индексируемые страницы.

Правильный workflow:

popular search query → editorial signal → analyst checks demand/content → if real topic: create curated Topic → definition → selected companies → selected experts → materials → sources → INDEXABLE

39. Topic merge и synonyms

"Generative Engine Optimization" "GEO" "AI Search Optimization" могут быть: canonical topic = AI Visibility aliases = [...] related concepts = [...] поэтому: не три почти одинаковых public pages, а одна entity + aliases / relations.

40. Multilingual architecture

На MVP основная аудитория русскоязычная. Не создавать автоматически английские копии всех страниц.

Этап	Решение
MVP	RU only
Если появляется реальный EN demand	Отдельные переведённые canonical pages с явной language relation
Machine translation массово	Не индексировать автоматически без quality review

41. /for-business

/for-business ├─ /publish ├─ /formats ├─ /pricing ├─ /agencies ├─ /visibility ├─ /editorial-services └─ /rules

Это product marketing layer. Он не должен дублировать публичные статьи и company/entity pages.

42. /methodology и /policies

Для trust «Матчасти» методологии и политики должны быть полноценной публичной частью IA, а не PDF в подвале.

/methodology ├─ research ├─ ratings (later) └─ ai-visibility (later) /policies ├─ editorial ├─ corrections ├─ advertising ├─ links ├─ ai ├─ privacy └─ takedown

43. Источники и документы

Для research-heavy материалов позже может появиться Source entity, но не надо создавать публичную страницу для каждого URL автоматически.

SOURCE stored: title publisher url published_at accessed_at source_type snapshot metadata relations PUBLIC SOURCE PAGE: только если появляется собственная value, например dataset / official report / methodology object.

44. Canonical vs redirect

Ситуация	Инструмент
Страница реально переехала	301/308
Доступны tracking-параметры одной страницы	Self canonical на clean URL
Дубликат company profile после merge	301 на canonical entity
Похожая, но самостоятельная статья	Не canonical на другую только ради SEO
Paginated archive	Каждая страница имеет свою URL-логику; не canonical всё на page 1

45. Index states как поле платформы

index_state: INTERNAL NOINDEX ELIGIBLE INDEXABLE INDEXED_OBSERVED DEINDEXED_OBSERVED REMOVED Важно: INDEXABLE ≠ INDEXED Это разделяет: наше техническое решение и наблюдаемое решение поисковика.

46. Robots и IA

Детально crawler policy будет в Mathchast_22, но IA уже определяет технические классы, которые не предназначены для поиска:

admin;
cabinet;
checkout;
draft preview;
internal search;
filter explosion;
API private endpoints;
temporary upload assets;
experiments/preview routes.

47. Reader navigation

ЧИТАТЕЛЬ МОЖЕТ НАЧАТЬ С: СТАТЬИ → увидеть компанию → эксперта → тему → кейс → исследование КОМПАНИИ → увидеть экспертов → публикации → кейсы → mentions ТЕМЫ → понять термин → увидеть лучшие материалы → компании → экспертов → research То есть нет тупиковых страниц.

48. Entity pages должны иметь unique value

Page	Минимальная уникальная value
Company	Verified structured facts + relations
Expert	Verified identity/expertise + publications
Topic	Definition + curated graph, не просто список ссылок
Industry	Meaningful directory/context, не пустая filter page
Article	Самостоятельный reader answer

49. IA и commercial content

Partner content находится в тех же смысловых разделах, что и editorial content, если он действительно соответствует теме. Commercial status — metadata/disclosure, а не отдельный SEO-подвал.

/cases/automation-case status: PARTNER_AD topic: automation company: X НЕ: /sponsored/clients/x/seo-post-17282

При этом фильтр «Партнёрские материалы» может существовать для прозрачности.

50. IA не должна скрывать рекламу

Интеграция paid article в обычный topic graph не означает сокрытие коммерческой природы. Label, advertiser info и legal status остаются явными.

51. MVP navigation menu

МАТЧАСТЬ Разборы Кейсы Исследования Компании Темы Поиск [Для бизнеса] НЕ НУЖНО СРАЗУ: Эксперты отдельным верхним пунктом Новости отдельным крупным пунктом Рейтинги Отзывы Marketplace

Эксперты и новости существуют как типы страниц, но не обязаны занимать главное меню до появления достаточного объёма.

52. Footer

О проекте Редакционная политика Исправления Реклама и партнёрские материалы Политика ссылок AI policy Для бизнеса Тарифы Контакты Правовые документы Privacy Sitemap / RSS

53. RSS

Публичный RSS логично заложить для редакционных материалов/типов, но не создавать отдельную индексируемую HTML-копию каждого feed. RSS станет дополнительным distribution interface.

54. API URLs

Публичная web IA и API namespace разделяются.

WEB: https://mathchast.com/companies/x API: https://mathchast.com/api/v1/companies/... или отдельный api host позже /private / admin: authentication required not indexable

55. Technical SSR requirement

Яндекс рекомендует, чтобы важный индексируемый контент был доступен поисковому роботу в HTML, а не существовал только после клиентского JavaScript execution.

Публичные entity/content pages «Матчасти» проектировать SSR/server-rendered или equivalent pre-rendered HTML-first. Интерактивность накладывается поверх.

56. IA QA checklist перед запуском

Для каждого public page type: □ один canonical URL □ 200 status □ self canonical □ unique title □ unique main content □ crawlable HTML links □ breadcrumb □ entity/topic relations □ no accidental filter URLs □ index_state □ sitemap rule □ redirect rule □ structured data hook □ publication lifecycle state □ analytics identity

57. MVP: что строим

Раздел	MVP
/articles	Да
/cases	Да
/research	Да
/news	Да как тип; menu optional
/companies	Да
/experts	Да как pages; directory can be later
/topics	Да, curated
/industries	Data layer first, public hubs selectively
/products	Нет публичного массового каталога
/reviews	Позже
/ratings	Позже

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

Утвердить entity-first information architecture. Основные публичные URL-типы: companies, experts, articles, cases, research, news и curated topics. Каждый самостоятельный объект имеет один canonical URL и постоянный internal ID. Фильтры, внутренний поиск, технические страницы и автоматически созданные shell entities не индексируются. Topic/industry pages создаются только при самостоятельной reader value. Partner content интегрируется в нормальный topic graph с явным disclosure. Sitemap разделяется по типам контента, а URL lifecycle и redirect registry продолжают правила документа 16.

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

Mathchast_18 information architecture → Mathchast_19 entity graph & data model → Mathchast_20 verification → Mathchast_21 structured data → Mathchast_22 crawlers / sitemap / IndexNow → Mathchast_23 content types → Mathchast_26 distribution → Mathchast_27 reader product → Mathchast_40 technical architecture

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

URL examples, entity types, index eligibility states, taxonomy states, navigation structure and MVP menu are product decisions «Матчасти». Search-engine-specific statements are based on current Google Search Central and Яндекс Вебмастер documentation and should be rechecked before production migrations.