Как спроектировать структуру каталога

Структура каталога решает не только, где в меню будут «товары» и «услуги». От неё зависит, как клиент будет выбирать, какие страницы смогут работать под поисковый спрос, насколько удобно будет обновлять ассортимент и не придётся ли через полгода переделывать половину сайта.

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

Что входит в структуру каталога

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

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

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

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

Сначала определить формат каталога

Перед проектированием нужно понять, какую задачу должен решать каталог. От этого зависят карточки, фильтры, кнопки, интеграции, CMS и даже структура URL.

Каталог может работать по-разному:

• показывать ассортимент и вести к заявке;
• помогать выбрать услугу или комплектацию;
• собирать запросы на расчёт;
• продавать через корзину;
• поддерживать B2B-сценарии с индивидуальными условиями;
• быть SEO-разделом под разные группы спроса;
• работать как витрина без онлайн-оплаты.

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

Если товар типовой, цена фиксирована, наличие актуально, а клиент готов купить без консультации, структура будет ближе к интернет-магазину: корзина, оформление заказа, статусы, оплата, доставка, личный кабинет, интеграции с учётной системой.

Перед проектированием полезно ответить на вопросы:

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

Если есть сомнения между витриной, заявочным каталогом и интернет-магазином, сначала стоит разобраться с форматом. Для этого подойдёт материал «Каталог или интернет-магазин: как выбрать формат».

Как проектировать разделы и подкатегории

Главная ошибка при создании структуры каталога — строить её по внутренней логике компании. Например, по отделам, поставщикам, складским группам или привычным названиям из прайс-листа. Для сотрудников это удобно, но клиент может выбирать совсем иначе.

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

Каталог можно группировать по разным принципам:

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

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

Когда нужна отдельная категория

Категория оправдана, если:

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

Категория сомнительна, если:

• в ней одна-две позиции без перспективы расширения;
• название понятно только сотрудникам компании;
• она отличается от другой категории только формулировкой;
• её проще реализовать как фильтр;
• у неё нет отдельного пользовательского сценария;
• она создаётся только «чтобы было больше страниц».

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

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

Свойства товаров: основа карточек, фильтров и SEO

Свойства — это не второстепенные поля в админке. Именно они определяют, как будут работать фильтры, сравнение, карточки, сортировки, посадочные страницы и интеграции.

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

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

Свойства можно условно разделить на несколько групп:

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

Перед разработкой стоит задать правила:

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

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

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

Фильтры и сортировки: не чем больше, тем лучше

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

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

Фильтр стоит добавлять, если:

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

Фильтр лучше не добавлять, если:

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

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

Отдельный вопрос — индексация фильтров. Комбинации параметров могут создавать полезные посадочные страницы, но могут и плодить технические дубли. Например, страница «товары бренда X» может быть осмысленной, а случайная комбинация из пяти фильтров — нет. Это нужно решать заранее, а не после того, как поисковые системы увидят тысячи малоценных URL.

Базовые SEO-решения лучше закладывать до запуска: структура URL, метаданные, канонические страницы, закрытие технических параметров, карта сайта, хлебные крошки. Подробнее об этом — в статье «Как подготовить сайт к SEO до запуска».

Карточка товара или услуги: структура данных, а не только дизайн

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

Для товарного каталога в карточке обычно нужно предусмотреть:

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

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

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

Что проверить в карточке до разработки

Перед запуском дизайна и верстки стоит пройтись по вопросам:

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

Если каталог должен приводить пользователя к обращению, структура карточек, кнопки, формы и сценарии заявки нужно продумывать вместе. Подробно об этом — в материале «Как подготовить каталог к заявкам и продажам».

SEO-посадочные страницы в каталоге

Каталог может формировать поисковые посадочные не только через основные категории. В зависимости от ассортимента и спроса посадочными могут быть:

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

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

Для SEO-посадочной в каталоге нужно заранее определить:

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

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

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

CMS и управление каталогом

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

В CMS должно быть удобно:

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

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

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

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

Типичные ошибки при проектировании каталога

Ошибки в структуре редко видны на первом экране. Они проявляются позже: когда ассортимент растёт, запускается реклама, начинается SEO-продвижение, менеджеры получают неполные заявки, а редактор тратит слишком много времени на обновления.

Чаще всего встречаются такие проблемы:

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

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

Как безопасно начать проектирование

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

Практичный порядок такой:

1. Определить формат: заявочный каталог, витрина, интернет-магазин или раздел продукции.
2. Описать основные пользовательские сценарии выбора.
3. Составить черновое дерево категорий.
4. Проверить, не смешаны ли разные принципы группировки.
5. Разделить категории, фильтры и SEO-посадочные.
6. Описать типы товаров или услуг.
7. Для каждого типа определить набор свойств.
8. Отобрать свойства, которые станут фильтрами.
9. Продумать структуру карточки.
10. Решить, какие страницы должны индексироваться.
11. Согласовать требования к CMS и интеграциям.
12. Проверить, как из каталога пользователь отправляет заявку.

Хороший результат проектирования — не просто список разделов. Это рабочая модель каталога: какие страницы есть, какие данные в них хранятся, как пользователь выбирает, как редактор управляет, как SEO-структура не конфликтует с фильтрами и как всё это можно развивать.

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