Информационный раздел, выросший без плана, выглядит похоже у всех: сотни статей по случайным запросам, страницы, перекрывающие друг друга, и ни одной точки входа, которая объяснила бы тему целиком. Поисковик в таком разделе путается не меньше читателя: не понимает, какая страница главная, и расшвыривает запросы по настроению. Архитектура pillar и кластеров наводит порядок: одна страница-фундамент раскрывает тему широко, десяток-другой страниц-спиц раскрывает её части глубоко, и вся конструкция связана ссылками в узнаваемую систему.
Это не термин из презентаций, а рабочая схема, которую SEO-команды копируют уже второе десятилетие, потому что она отвечает сразу на три вопроса: как охватить тему целиком, как распределить вес между страницами и как не утонуть в собственной текстовой свалке. Ниже разбор всех узлов: карта интентов, URL структура, внутренние ссылки, разметка, поддержка и типовые ошибки.
Что такое pillar page и чем он отличается от обычной длинной статьи
Pillar page - это страница-фундамент, которая раскрывает широкую тему обзорно и раздаёт читателя на глубокие материалы по частям темы. Она отвечает на вопросы "что это, как устроено, из каких этапов состоит" и по каждому блоку отдаёт 100-300 слов сути, а дальше ссылается на страницу кластера, где тема разобрана до дна. Головной запрос типа "SEO для стартапа" ведёт на pillar, а узкие запросы типа "как собрать семантику для нового сайта" ведут на кластерные страницы.
От длинной статьи в блоге pillar отличается ролью, а не длиной. Статья живёт сама по себе и решает одну задачу, pillar обслуживает целый раздел: собирает трафик по верхнему запросу, распределяет вес по ссылкам, служит витриной темы и навигацией. Практический тест простой: если страницу можно удалить без потери навигации по разделу, это просто статья. Если её удаление разрывает раздел на осколки, перед вами pillar.
Глубина фундамента - отдельная дисциплина. Pillar обязан быть обзорным: попытка расписать каждый подвопрос на пару тысяч слов превращает страницу в нескончаемый свиток, который конкурирует со всеми спицами сразу и проигрывает каждой. Правильный фундамент отвечает на верхний запрос полнее и структурнее, чем любая отдельная спица, но в каждом разделе оставляет читателю ощущение, что здесь об этом есть отдельный разбор. Оглавление из 8-12 смысловых блоков - хороший индикатор: структура фундамента и есть будущая структура кластера.
Форматов у фундамента три. Информационный гид раскрывает концепцию и терминологию, чаще встречается в экспертных нишах. Продуктовый pillar собирает вокруг линейки или услуги все смежные вопросы. Сравнительный фундамент держит на себе перечни и матрицы выбора. В информационном разделе сайта обычно работают с первым типом, и ниже речь именно о нём.
Карта интентов как разложить семантику темы по страницам без каннибализации
Архитектура начинается не с текстов, а с таблицы запросов. Семантику собирают привычными инструментами: Wordstat даёт первичный список, Key Collector помогает убрать мусор и сгруппировать, Ahrefs и Semrush показывают, какие запросы реально приводят трафик конкурентам, а блоки похожих вопросов в выдаче подсказывают скрытые потребности читателя.
Дальше работает правило выдачи: у запросов, чьи топ-10 страниц совпадают больше чем наполовину, один интент, и им нужна одна страница. У запросов с разными выдачами интенты разные, и их растаскивают по разным страницам кластера. Головной, самый широкий запрос достаётся pillar, узкие вопросы и хвосты уходят на спицы. Проверка каннибализации делается той же таблицей: если два запроса назначены одной странице, а выдача у них разная, один из них уводится на отдельный URL.
При раскладке учитывают тип запроса. Информационные запросы ведут в кластер, коммерческие - на страницы услуг, навигационные обычно закрываются главной или разделом, и претендовать на них статьями нет смысла. Отдельная проверка - чужие кластеры: отчёт топ страниц конкурента в Ahrefs показывает, какие именно материалы приносят ему трафик по теме, и такой список часто экономит месяц исследований. Чужие спицы не копируют, а используют как чек-лист покрытия.
К объёму стоит подходить без фанатизма. Рабочий кластер обычно укладывается в 10-30 страниц: меньше - тема раскрыта не полностью, больше - раздел расползается и по ссылкам, и по краулинговому бюджету. Каждой странице кластера назначают один интент и один список из 3-7 целевых запросов, и этот список закрепляется в таблице, а не в памяти автора.
URL структура и схема внутренних ссылок внутри кластера
Структура URL отражает иерархию. Короткий URL у фундамента и вложенные URL у спиц сообщают поисковику о подчинённости страниц:
https://example.com/seo/ - pillar "SEO для стартапа"
https://example.com/seo/technical/ - кластер о технической проверке
https://example.com/seo/keywords/ - кластер о семантике
https://example.com/seo/local/ - кластер о локальном продвижении
https://example.com/seo/links/ - кластер о ссылкахСхема ссылок повторяет схему спиц у колеса. Pillar ссылается на каждую страницу кластера, желательно из смыслового блока, а не из подвала. Каждая спица ссылается на фундамент в первом упоминании темы или через навигационную цепочку. Между спицами прокладывают 2-4 смысловых перехода там, где темы действительно соседствуют, а не по принципу "все на всех". Анкоры пишут описательные и разные: навигационная цепочка отдаёт роль, а не слова "читайте также".
Отдельное правило - внешние ссылки концентрируют на фундаменте. Именно pillar рассылают журналистам, ставят в подписи экспертов, цитируют в гостевых материалах, потому что усилие, вложенное в одну страницу, распределяется потом по всей конструкции через внутренние ссылки. Спицы при этом работают на конверсию и длинный хвост, и внешние ссылки на них приятный бонус, а не цель.
Глубина от главной до любой страницы кластера держится в пределах трёх кликов. Техническую проверку схемы удобно делать Screaming Frog: отчёт покажет и страницы-сироты, и слишком глубокие вложения, и неработающие ссылки. В Xml карту кластер кладут отдельным сегментом, чтобы обновления раздела были видны в Search Console точечно.
Разметка Schema.org которая делает связи страниц видимыми для машин
Разметка дублирует иерархию на языке данных. На фундаменте уместен тип CollectionPage со списком частей кластера, на спицах - Article с указанием темы и навигационной цепочкой:
{
"@context": "https://schema.org",
"@type": "CollectionPage",
"name": "SEO для стартапа",
"url": "https://example.com/seo/",
"hasPart": [
{"@type": "Article", "name": "Техническая проверка сайта", "url": "https://example.com/seo/technical/"},
{"@type": "Article", "name": "Сбор семантики", "url": "https://example.com/seo/keywords/"}
],
"dateModified": "2026-04-18"
}Правила сцепки прежние: разметка обязана повторять то, что видно на странице, список hasPart не должен содержать битых ссылок, а дата обновления в коде должна совпадать с реальной правкой контента. На кластерных страницах указывают about с темой и BreadcrumbList с положением страницы в цепочке. Разметка не заменяет живые ссылки, она подчёркивает уже существующую структуру, и поисковик читает её именно так.
Поддержка кластера почему заброшенный раздел теряет позиции
Кластер - живая система, а не разовый проект. Страницы стареют: цифры устаревают, конкуренты обновляют свои материалы, часть спиц теряет запросы. Явление известно как распад контента: страница, которая год назад держала позицию по широкому запросу, медленно сползает, потому что выдача предпочитает более свежие и полные ответы. Кластеры с регулярной поддержкой почти не болеют этой болезнью.
Рабочий цикл поддержки выглядит так. Раз в квартал редакция открывает Search Console и смотрит, по каким запросам раздел присутствует, а по каким потерян. Упавшие спицы обновляют: свежие цифры, новые блоки, честная дата правки. Появившиеся новые грани темы закрывают новыми страницами кластера, а не дописыванием всего в фундамент. Каннибалов, когда две страницы делят один интент, склеивают редиректом, выбирая более сильную. Нулевые страницы без запросов и ссылок либо переписывают, либо выводят из индекса, без жалости.
Честность дат - часть гигиены. Менять дату обновления без реальных правок - короткий путь к потере доверия и читателя, и поисковика, каждая правка обязана менять что-то весомое: цифру, вывод, блок шагов. Полезно вести журнал обновлений прямо в таблице кластера: когда правили, что добавили, на какие позиции откликнулась выдача. Через год такой журнал превращается в знание о том, как тема реагирует на заботу.
Показатель здоровья кластера один: доля запросов темы, по которым сайт показан в выдаче. Если раздел закрывает восемь из десяти смысловых блоков темы, столп держится. Если четыре - тема раскрыта наполовину, и выручает только слабость конкурентов.
Ошибки архитектуры кластеров которые съедают бюджет краулинга
Первая ошибка - сироты. Страница кластера без единой внутренней ссылки на неё невидима и для читателя, и для робота, сколько бы труда в неё ни вложили. Вторая - тонкие дубли: три страницы, отвечающие на один вопрос чуть разными словами, конкурируют друг с другом и размывают релевантность всей теме. Третья - гигантомания: кластер из двухсот страниц невозможно ни поддерживать, ни перелинковать осмысленно, и он превращается в текстовое болото.
Технические ошибки обходятся дороже. Ссылки, отрисовываемые сценарием после загрузки, поисковик может не увидеть. Длинные цепочки редиректов разбазаривают вес. Страницы меток и фильтров, попавшие в индекс, создают тысячи дублирующих URL. Наконец, смешение интентов: коммерческая страница, на которой пытаются ранжироваться ещё и за информационные запросы, проигрывает обоим конкурентам сразу. Диагностика стандартная: Site Audit от Ahrefs и Screaming Frog показывают сирот, дубли, глубину и битые ссылки одним отчётом.
Контентные ошибки не дешевле технических. Шаблонные заголовки вида "Всё о теме" на каждой спице роняют кликабельность в выдаче: читатель видит три одинаковых подзаголовка и выбирает чужой сайт. Одинаковые первые абзацы, пересказывающие определение, приучают поисковик считать страницы похожими ещё до сравнения смысла. Наконец, спицы без автора и даты выглядят забытыми, и кластер из забытых страниц проигрывает разделу, который явно живёт и обновляется.
Порядок запуска кластера от исследования темы до первых позиций
Запуск укладывается в короткую очерёдность, и держаться её полезнее, чем писать первые тексты:
- собрать семантику темы и разложить запросы по интентам на основе выдачи;
- выбрать формат pillar page под интент головного запроса и утвердить список спиц;
- зафиксировать URL структуру, схему ссылок и анкоры в таблице раздела;
- написать и опубликовать pillar page с обзорной глубиной и списком кластеров;
- выпускать кластерные страницы партиями, начиная с спиц с максимальным потенциалом;
- связать страницы живыми ссылками и разметкой, добавить сегмент в карту сайта;
- мониторить охват темы в Search Console и вести квартальный цикл обновления.
Сроки у схемы скромные и предсказуемые. Первые хвосты спицы собирают через считанные недели после индексации, фундамент вытягивает широкий запрос за месяцы, а полная отдача конструкции наступает после второго-третьего цикла поддержки. Кто ждёт чудес в первый месяц, бросает на середине; кто держит ритм, получает раздел, который конкурентам дорого обойти.
Выгода архитектуры раскрывается медленно и верно. Первые спицы собирают хвосты, фундамент вытягивает широкий запрос, ссылки внутри кластера передают вес от новых страниц к старым, а вся конструкция в итоге занимает в тематике столько места, сколько позволяет бюджет. В выдаче с генеративными ответами выигрывают источники, закрывающие тему целиком: ассистенты цитируют не страницы, а базы знаний, и кластер - это именно база, собранная вручную и подписанная именем вашего сайта.