Silo-структура (силосная архитектура): проектирование тематических кластеров
1. Архитектура и принцип работы
Работа начинается со сбора семантики: выгружаем запросы, чистим от мусора, кластеризуем по топам и леммам. Дальше каждый кластер получает хаб-страницу — она отвечает на общий интент и ссылается вниз на дочерние статьи. Внутри силоса ссылки идут вертикально (хаб → статья, статья → хаб) и горизонтально только между родственными статьями. Между силосами — минимум связей, обычно через главное меню или одну общую категорию. Такой каркас даёт краулеру однозначный путь: он видит тему кластера, её границы и вес хаба. Анкоры внутри силоса описывают сущность, а не «здесь» и «подробнее». На этапе проектирования фиксируем URL-шаблон (например, /tema/podtema/), хлебные крошки и правила перелинковки, чтобы разработчик не изобрёл свою архитектуру по ходу вёрстки.
2. Математическая механика и триггеры ранжирования
Механика опирается на распределение внутреннего веса и плотность тематических связей. Для каждого кластера считаем: N — число запросов, покрытых хабом; C — число дочерних URL; L_in — входящие ссылки из других силосов (держать ≤ 2–3); L_out — исходящие в чужие силосы (≤ 2). Плотность связей внутри силоса: D = E / (C × (C−1)), где E — число внутренних рёбер; целевой диапазон D = 0,15–0,35, выше — риск «ссылочных колец». Вес хаба оцениваем через PageRank-подобную итерацию: PR(p) = (1−d)/N + d × Σ PR(q)/L(q), d = 0,85; хаб должен получать не менее 60% веса кластера. Покрытие семантики: K = (запросы с целевой страницей) / (все запросы кластера) ≥ 0,9. Дубли интентов ловим по коэффициенту Жаккара по топ-10: J = |A∩B| / |A∪B|; при J > 0,5 страницы сливаем или канонизируем.
3. Специфика в Яндекс (YATI) vs Google
Яндекс сильнее реагирует на коммерческие и региональные факторы внутри кластера: хаб под «купить» и статья под «что это» в одном силосе дают размытие, поэтому коммерческие и информационные ветки разделяем. Яндекс любит чёткие хлебные крошки и микроданные BreadcrumbList, быстрее перестраивает веса при смене перелинковки. Google больше опирается на граф ссылок и топологию: изолированные силосы с редкими мостами читаются как тематические хабы, но при переспаме внутренними анкорами включает фильтры. В Google полезнее явные Hub-страницы с коллекцией ссылок и schema ItemList. В обоих поисковиках работает правило: анкор должен совпадать с сущностью целевой страницы, а не с ВЧ-запросом хаба.
4. Нормативы SLA и диагностическая матрица
| Параметр / Метрика | Эталон по SLA | Критическая ошибка |
|---|---|---|
| Покрытие семантики K | ≥ 0,9 | < 0,7 |
| Плотность связей D внутри силоса | 0,15–0,35 | > 0,45 |
| Мосты между силосами (входящие L_in) | ≤ 3 | > 6 |
5. Пошаговый инженерный протокол внедрения
- Собрать семантику и кластеризовать по топ-10 и леммам, зафиксировать границы силосов в таблице: кластер → запросы → интент → тип страницы.
- Назначить хаб каждому кластеру, проверить покрытие K ≥ 0,9 и слить дубли с J > 0,5 через canonical или объединение контента.
- Спроектировать URL-шаблон и хлебные крошки, прописать правила перелинковки: вертикаль хаб ↔ статья, горизонталь только внутри силоса, мосты между силосами ≤ 3.
- После запуска снять краулингом граф ссылок, посчитать D и вес хаба, убрать лишние мосты и добавить недостающие ссылки на хабы из меню и карты сайта.
# Проверка плотности связей силоса
D = E / (C * (C - 1))
assert 0.15 <= D <= 0.35, f"Плотность {D:.2f} вне нормы: пересмотреть перелинковку"
# Слияние дублей по Жаккару топ-10
J = len(set(top_a) & set(top_b)) / len(set(top_a) | set(top_b))
if J > 0.5:
merge_or_canonical(url_a, url_b)6. Типичные ошибки при оптимизации
- Сваливать в один силос коммерческие и информационные запросы: хаб начинает конкурировать сам с собой, а статьи не получают вес.
- Строить перелинковку «всё со всем» внутри кластера: D уходит выше 0,4, появляются ссылочные кольца и размытие анкоров.
- Оставлять силос без хаба или с хабом-заглушкой: краулер не находит точку входа в тему, дочерние страницы висят на глубине 4–5 кликов.