Структура сайта на основе спроса: услуги, статьи и посадочные страницы

Что начинается после карты спроса

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

На этом этапе не собирают семантику, не решают заново, нужен ли отдельный URL, и не настраивают редиректы. Утвержденные решения превращают в рабочую систему:

• назначают тип и основную задачу каждой страницы;
• определяют родителя, уровень и ближайших соседей;
• проектируют входы, переходы и следующий шаг;
• утверждают правила URL и шаблонов;
• фиксируют индексируемость и технические сигналы;
• готовят карту переноса, если меняются действующие адреса;
• назначают владельца и условие пересмотра.

Для меня здесь проходит важная граница между исследованием и системой. Если вопрос о необходимости страницы еще открыт, архитектура не должна маскировать неопределенность. Такую страницу возвращают в карту спроса, а не прячут в меню «на всякий случай».

Архитектура не равна меню, Sitemap или списку URL

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

У сайта может быть аккуратное меню и при этом слабая архитектура. Например, услуги и статьи находятся в разных разделах, но не связаны между собой. Тогда читатель не видит логичного продолжения, а поисковые системы получают меньше внутренних сигналов о связи страниц.

Архитектура включает несколько слоев. Я проверяю их вместе: смысл без навигации оставляет читателя в тупике, навигация без ясных ролей размножает похожие маршруты, а техническая схема без владельцев быстро расходится с реальным маркетингом.

Меню показывает только выбранную часть навигации. XML Sitemap помогает поисковым системам обнаруживать указанные в нем страницы, но не описывает всю пользовательскую логику и не гарантирует обход или индексацию (Google о файлах Sitemap, Яндекс о Sitemap).

Список URL тоже недостаточен. Из него не видно, зачем существуют две близкие страницы, какая из них является основной для темы и куда должен перейти человек после чтения.

Назначьте каждой странице одну основную роль

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

Я разделяю страницы не по тому, как они выглядят, а по работе, которую выполняют в системе. Одна страница может помогать на нескольких этапах, однако у нее должна быть одна основная задача. Иначе услуга превращается в энциклопедию, статья - в рекламную листовку, а посадочная - в копию общего раздела. Такое смешение мешает и контенту, и рекламе: разные каналы ведут на один компромиссный ответ, который никому не подходит полностью.

Хаб направления

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

Хаб не обязан содержать полный ответ по каждой подтеме. Его задача - дать обзор, критерии выбора и ясные переходы.

Страница услуги

Страница услуги помогает оценить предложение и принять решение об обращении. На ней нужны состав работ, кому подходит услуга, процесс, ограничения, факторы стоимости, доказательства и следующий шаг.

Она не должна поглощать все информационные вопросы только потому, что они содержат название услуги.

Посадочная страница

Посадочная страница ведет человека по конкретному сценарию: для определенной аудитории, задачи, предложения или кампании. Она оправдана, когда сценарий действительно отличается, а содержание не является простой перестановкой блоков общей услуги.

Если посадочная почти полностью повторяет другую страницу, команда сначала решает вопрос дубля и основной страницы, а уже затем выбирает canonical, объединение или другой технический вариант. Google описывает canonical как сигнал для одинаковых или очень похожих страниц. Если страницы решают разные задачи, сначала нужно решить, нужны ли обе и чем отличается их содержание (документация Google о canonical).

Экспертная статья

Статья снимает информационный барьер: помогает разобраться, сравнить подходы, оценить риск или подготовиться к решению. Она должна давать самостоятельную пользу и естественно связываться с услугой, кейсом или следующим материалом.

Общая тема не делает статью дочерней страницей услуги автоматически. Ее место определяется задачей читателя и логикой хаба.

Кейс

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

Например, в кейсе о 37 договорах для юридической компании услуги и сценарии обращения разведены по задачам. Для архитектуры важен сам принцип: кейс подтверждает работу системы и ведет к релевантному предложению, но не становится основной коммерческой страницей услуги.

Служебная страница

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

Для конфиденциальных разделов нужна авторизация. robots.txt управляет обходом и не является защитой закрытых данных (Яндекс об ограничении индексирования).

Паспорт страницы

Чтобы не передавать между командами только название и URL, на каждую утвержденную страницу заполняют короткий паспорт. Для меня это договор о роли страницы: маркетинг фиксирует ее задачу и место в пути клиента, а редакция, дизайн и разработка получают одинаковые границы решения.

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

Особенно полезно зафиксировать ближайшего соседа и отличие. Это заставляет объяснить разницу между похожими сущностями до разработки. Если команда не может отличить две страницы одним предложением, вероятно, их роли еще не разведены.

Соберите одну ветку целиком

Перед проектированием всего сайта проверьте одну приоритетную ветку целиком: от входа до целевого действия. Так быстрее обнаруживаются повторяющиеся роли, тупики, лишние уровни и разрыв между обещанием канала и содержанием страницы.

Утвержденная карта спроса уже содержит решения:

• оставить общий хаб направления;
• сохранить самостоятельные услуги проектирования, монтажа и обслуживания;
• создать посадочную для комплексной вентиляции офисов, потому что сценарий и доказательства отличаются;
• подготовить статью о техническом задании;
• использовать кейсы как доказательства;
• не создавать отдельную страницу под каждую перестановку слов.

Черновая ветка может выглядеть так:

Главная└── Вентиляция коммерческих зданий    ├── Проектирование вентиляции    ├── Монтаж вентиляции    ├── Обслуживание вентиляции    └── Решения для объектов        └── Вентиляция офисовЭкспертный центр└── Как подготовить техническое задание на вентиляциюКейсы└── Вентиляция офисного здания: проект, монтаж и запуск

Это не означает, что статья и кейс оторваны от сервисной ветки. Иерархия показывает основное место, а контекстные ссылки создают рабочие маршруты между типами страниц.

Паспорт страницы «Проектирование вентиляции»

Почему статья не становится дочерней услугой

Материал о техническом задании полезен заказчику до выбора конкретного подрядчика и может поддерживать несколько услуг. Поэтому он живет в экспертном центре, получает контекстные ссылки на проектирование и монтаж и возвращает читателя к подходящему сценарию.

Размещать все статьи внутри /services/ только ради тематической близости не требуется. Важнее понятное место материала, доступные HTML-ссылки и последовательный путь пользователя.

Почему посадочная не копирует услугу

Страница «Вентиляция офисов» отвечает на задачу, связанную с конкретным типом объекта: учитывает ограничения действующего офиса, этапность работ, требования к шуму, размещению оборудования и запуску. Страница «Проектирование вентиляции» отвечает на отдельную профессиональную услугу для разных типов коммерческих объектов.

Если содержание офисной страницы почти не отличается, ее не следует создавать только ради формулировки запроса. Решение возвращается в карту спроса.

Проверьте страницу в контексте

Спрос для меня является одним из входов, а не единственным архитектором сайта: раздел нужен только там, где у бизнеса есть предложение, доказательства и ресурс поддерживать содержание.

Паспорт нельзя оценивать в отрыве от остального сайта. Я проверяю страницу как часть общей модели: какое обещание привело человека, какой ответ он получает, какое доказательство видит и какое действие может совершить дальше. Для каждой страницы ответьте на четыре вопроса.

Где ее находят на сайте

Родитель должен помогать выбрать дочернюю страницу, а не просто содержать общее слово. Попав на хаб, человек понимает различия между направлениями и может продолжить путь.

Дополнительный уровень оправдан, когда он действительно облегчает выбор и будет поддерживаться несколькими самостоятельными страницами. Папка с единственным материалом и пустой хаб обычно добавляют переход, но не объясняют структуру.

Google рекомендует логично организовывать сайт и связывать важные страницы релевантными ссылками. Это помогает пользователям и поисковым системам понимать отношения между материалами, но не обещает позицию (руководство Google для начинающих). Яндекс также советует группировать близкую информацию в понятные разделы (рекомендации Яндекса по структуре).

В официальных рекомендациях Google и Яндекса нет фиксированного лимита «не дальше трех кликов». При этом Яндекс отмечает: чем глубже расположена страница, тем больше времени может пройти до ее включения в индекс. Поэтому у важной страницы должны быть обычные внутренние ссылки и понятный путь, не зависящий от внутреннего поиска или случайной ссылки.

С чем ее путают

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

Запишите различие в формате:

Страница A помогает ..., а страница B помогает ...

Если продолжения совпадают, проверьте, нужны ли два адреса.

Откуда на нее приходят

Человек не всегда начинает с главной. Статья, кейс или услуга могут стать первой страницей визита. В паспорте отметьте реальные входы: поисковый запрос, рекламное объявление, внешний материал, меню, хаб, внутренняя ссылка или прямой переход.

Канал входа влияет на контекст, но сам по себе не требует копировать страницу. Если задача одна, лучше сохранить одну основную страницу и согласовать сообщение рекламы, контента и навигации с ее ролью.

Куда идут дальше

Покажите, как человек продолжает выбор: от хаба к услуге, от общей услуги к отраслевому сценарию, от статьи к сравнению подходов, от кейса к использованной услуге или между материалами, которые продолжают один вопрос.

Ссылки должны объяснять, что находится дальше. Формулировка «как подготовить техническое задание» полезнее безымянного «читать подробнее».

После ответа предложите логичное продолжение: изучить связанную услугу, посмотреть доказательство, перейти к следующему материалу, рассчитать задачу или связаться с командой.

Один и тот же призыв не подходит всем типам страниц. После информационной статьи ссылка на критерии выбора или релевантный кейс может быть уместнее формы. После страницы услуги следующий шаг, наоборот, должен помогать начать обсуждение. Так архитектура связывает разные каналы в один путь, не заставляя каждую страницу одновременно продавать, обучать и доказывать все сразу.

Разделите глобальную и контекстную навигацию

Глобальное меню отвечает за основные направления сайта. В него не нужно помещать каждую статью, посадочную и узкую услугу. При большом объеме это усложняет выбор и превращает меню в отражение базы данных. Я предпочитаю сохранять глобальную навигацию короткой, а глубину темы раскрывать через хабы и контекстные связи.

Хабы раскрывают состав конкретного направления. Они принимают людей из меню и поиска, объясняют различия и распределяют их по дочерним страницам.

Контекстные ссылки соединяют разные ветки: статью с услугой, кейс с решением, услугу с отраслевым сценарием. Именно здесь архитектура становится полезным маршрутом, а не деревом папок.

Для поисковых систем важные переходы должны быть доступны как обычные ссылки <a> с href. Элементы, которые меняют экран только через обработчик события без доступного адреса, могут не дать надежного пути обхода (Google о сканируемых ссылках).

Полная методика внутренней перелинковки является отдельным этапом. В архитектуре достаточно задать обязательные типы связей и владельцев, а тексты ссылок, приоритет и контроль страниц без входящих внутренних ссылок оформить в отдельной спецификации.

Зафиксируйте устойчивые правила URL

URL должен быть понятным, стабильным и предсказуемым для команды. Его задача - однозначно идентифицировать страницу и поддерживать управляемую систему адресов. Для маркетинга стабильность особенно важна: реклама, аналитика, контент и внешние материалы должны ссылаться на одну и ту же сущность, а не догонять косметические переезды.

Практические правила:

• использовать читаемые слова и единый формат;
• применять дефисы между словами;
• избегать лишних параметров и разных адресов для одного содержания;
• не зашивать в URL элементы, которые скоро изменятся: рекламный слоган, должность, временный статус;
• заранее определить правила для услуг, статей, кейсов и посадочных;
• хранить один канонический вариант протокола, домена и завершающего слеша;
• не менять работающий адрес только ради более красивой формулировки или ключевой фразы.

Google рекомендует простые описательные URL. При этом Google отдельно указывает, что само наличие ключевых слов в доменном имени или пути URL вряд ли дает заметный эффект для ранжирования, кроме отображения в строке навигации. Поэтому польза стабильности обычно выше косметического переезда (руководство Google для начинающих, рекомендации Google по структуре URL).

Иерархия сайта и путь URL могут быть согласованы, но не обязаны зеркально совпадать. Перемещение статьи в другой смысловой хаб не всегда требует менять ее адрес. Сначала оцените пользу для пользователя, стоимость миграции и риск разрыва накопленных связей.

Что передать SEO-специалисту и разработчику

Маркетологу не нужно настраивать следующие элементы самостоятельно. Его задача - сохранить смысловую систему: какие страницы публичны, как связаны и какую роль выполняют. SEO-специалист и разработчик переводят эти требования в HTML и поисковую инфраструктуру и возвращают проверяемый результат.

Доступные ссылки

Проверьте, что у каждой индексируемой страницы есть хотя бы один понятный путь через обычную ссылку. Страница, которая присутствует только в XML Sitemap, может быть обнаружена поисковой системой, но остается слабой частью пользовательского маршрута.

Хлебные крошки

Хлебные крошки показывают положение текущей страницы и позволяют перейти на более общий уровень. Их логика может отражать типичный путь пользователя, а не буквальную строку URL.

Для разметки можно использовать BreadcrumbList. Google и Яндекс описывают ее как способ передать цепочку навигации. Корректная разметка не гарантирует специальное отображение в выдаче (Google о хлебных крошках, Яндекс о навигационных цепочках).

XML Sitemap

В Sitemap включают канонические URL, предназначенные для индексирования. Файл помогает поисковым системам обнаруживать страницы, но не заменяет внутренние ссылки.

Если сайт автоматически публикует материалы, генерация Sitemap тоже должна быть автоматической. Ручной список быстро расходится с реальным состоянием.

Canonical

Для дублирующих или очень похожих версий задают согласованный canonical и поддерживают его внутренними ссылками и Sitemap. Разные интенты нельзя «развести» canonical: сначала требуется содержательное решение.

Определите индексируемость до публикации

Не каждая доступная страница должна участвовать в поиске. Решение принимают по роли и содержанию, а не по шаблону целиком. Это позволяет не смешивать публичный контент, временные рекламные сценарии, служебные функции и закрытые разделы в один индексируемый массив.

noindex, canonical, ограничение обхода и авторизация решают разные задачи. Их нельзя использовать как взаимозаменяемые переключатели.

Для генеративных функций Google Поиска не нужны llms.txt, другие специальные машиночитаемые файлы или особая разметка schema.org. Действуют обычные основы SEO: доступность и индексируемость страниц, полезное уникальное содержание, понятная техническая структура и структурированные данные, соответствующие видимому содержанию (Google о генеративных функциях поиска).

Подготовьте перенос до изменения адресов

Если архитектура затрагивает действующие URL, перенос является частью проекта, а не работой «после запуска». Он затрагивает не только поиск: старые адреса могут использовать реклама, рассылки, презентации, партнерские публикации и внутренняя отчетность.

Для каждой изменяемой страницы составьте таблицу:

Старый адрес должен вести на наиболее близкий новый ответ, а не массово на главную. Одновременно обновляют внутренние ссылки, canonical, Sitemap, хлебные крошки, рекламные адреса и внешние профили, которыми управляет компания.

Google рекомендует заранее сопоставлять старые и новые URL, настраивать постоянные редиректы и обновлять внутренние сигналы (Google о переносе URL). Яндекс также описывает редиректы, Sitemap и последовательное обновление адресов при изменении структуры (Яндекс об изменении структуры сайта).

Даже корректный перенос не обещает отсутствия колебаний. Поэтому до выпуска сохраняют исходный срез индексации и трафика, после - проверяют коды ответа, цепочки редиректов, выбранные canonical, обход и фактически ранжирующиеся страницы.

Если действующий URL уже понятен, индексируется и соответствует роли, его не нужно менять только ради совпадения с новым деревом.

Проведите стресс-тест архитектуры

Хорошая архитектура одинаково читается маркетингом, редакцией, дизайном и разработкой: у команды не возникает четырех разных версий того, зачем существует страница.

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

Добавление новой услуги

Команда должна понимать:

• кто решает, тянет ли тема на отдельную страницу;
• в какой хаб она входит;
• какой шаблон получает;
• с какими страницами может конфликтовать;
• откуда получает первые ссылки;
• кто отвечает за содержание.

Если для каждой новой услуги приходится заново изобретать правила, архитектура не стала системой.

Добавление сотой статьи

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

Изменение названия направления

Проверьте, можно ли обновить навигацию и заголовки без обязательной смены всех URL. Это показывает, не слишком ли адреса зависят от временных формулировок.

Одна страница подходит двум разделам

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

Сценарий без поискового спроса

Страница может быть нужна продажам, поддержке или текущим клиентам. Архитектура не запрещает ее только из-за отсутствия подтвержденной частотности. Для нее отдельно определяют роль, доступность, индексацию и место в интерфейсе.

Чек-лист перед передачей в работу

Архитектура готова к передаче, если:

• все страницы взяты из утвержденной карты или имеют отдельное бизнес-обоснование;
• у каждой страницы есть одна основная роль;
• для похожих страниц сформулировано различие;
• родитель помогает выбрать дочернюю страницу;
• важные страницы имеют понятные входы и следующий шаг;
• глобальное меню, хабы и контекстные связи не смешаны;
• правила URL едины и не требуют косметических переездов;
• индексируемость назначена по роли и качеству;
• ссылки, доступные поисковым роботам, хлебные крошки, XML Sitemap и канонические URL согласованы;
• для изменяемых адресов подготовлена карта переноса;
• назначены владелец и триггер пересмотра;
• новую страницу можно добавить по тем же правилам без изобретения отдельной системы.

Архитектура готова, когда маркетинг, редакция, дизайн и разработка одинаково понимают роль каждой страницы. Если каждая команда читает одну схему по-своему, проектирование еще не закончено.

Если архитектуру нужно проверить до разработки, команда SEO-продвижения Медиакода сверит роли страниц, индексируемость и внутренние связи, а команда разработки сайтов оценит шаблоны и безопасный перенос URL.