Через полгода после запуска почти любой проект на 1С-Битрикс начинает расти не так, как задумывалось на старте: к «Новостям» добавляется «Блог», к «Портфолио» — «Кейсы» со своей структурой полей, к одному инфоблоку «Каталог» пристраивают костыль под акции. Если структура инфоблоков изначально не была спроектирована с запасом, каждое такое расширение превращается в мини-переделку: миграцию данных, правку шаблонов, перенастройку прав. Хуже всего — эти переделки почти всегда обнаруживаются в разгар работы, когда откладывать уже нельзя.
Ниже — методология проектирования структуры инфоблоков на старте проекта: как описать типы контента до того, как в админке появится первый раздел, как выбирать типы свойств осознанно, а не «на глазок», и как избежать главной ловушки — инфоблока, который делает всё и потому не делает ничего хорошо. Это относится к любому типу контента — не только к каталогу товаров, но и к новостям, портфолио, вакансиям и филиалам. Разбор опирается на нашу практику разработки каталогов товаров на 1С-Битрикс, где цена ошибки в структуре данных особенно высока.
Коротко
- Проектируйте структуру от типов контента и их жизненного цикла, а не копированием пунктов меню сайта.
- Один инфоблок — один тип контента со своей логикой публикации; инфоблок «на всё» — типичный антипаттерн, который перестаёт масштабироваться.
- Тип свойства выбирайте осознанно: «Список» и привязки экономнее и предсказуемее «Строки» для всего, что фильтруется или структурируется.
- Связи между инфоблоками (привязка к элементам/разделам) избавляют от дублирования одних и тех же данных в разных местах.
- Соглашение о наименовании кодов и полей стоит зафиксировать один раз в начале — это дешевле, чем разбираться в PROP_17 через год.
Почему структуру нельзя проектировать «на ходу»
Соблазн начать разработку сразу с админки — завести инфоблок «Новости», добавить пару свойств, посмотреть, как выглядит на фронте, — понятен: так быстрее увидеть результат. Проблема в том, что решения, принятые «по ходу дела», почти всегда учитывают только сегодняшний список требований и ничего не говорят о том, как контент будет расти через полгода-год. Свойство, заведённое как «Строка» для трёх текущих брендов, при росте до полусотни превращается в двадцать вариантов написания одного и того же бренда; раздел меню, скопированный «в лоб» в дерево разделов инфоблока, оказывается неудобной основой для фильтрации, когда появляется вторая ось классификации.
Переделка структуры на живом проекте всегда дороже, чем правильное проектирование на старте: нужно не просто поменять настройку, а перенести уже накопленные данные, поправить все места в шаблонах и коде, которые обращаются к старой структуре, и — если сайт уже проиндексирован — не потерять положение в поиске при возможной смене URL. Час, потраченный на проектирование до старта разработки, почти всегда экономит недели на этапе роста.
Из чего состоит инфоблок
Прежде чем проектировать структуру, полезно чётко разложить по полочкам, из чего инфоблок собран технически — это определяет, какие решения вообще доступны на этапе проектирования.
- Инфоблок (тип + сам инфоблок). Контейнер верхнего уровня. Тип инфоблока группирует однородные инфоблоки (например, тип «Каталоги» объединяет инфоблоки товаров разных брендов), сам инфоблок — конкретная сущность с собственным набором разделов, элементов и свойств.
- Разделы. Иерархическое дерево рубрик внутри инфоблока — категории каталога, рубрики новостей, разделы портфолио.
- Элементы. Конкретные записи внутри разделов — товар, новость, кейс, вакансия, филиал.
- Свойства. Поля элемента (и, отдельно, поля раздела) с заданным типом данных — строка, число, список, файл, привязка к элементам другого инфоблока и так далее.
Проектирование структуры — это последовательный выбор для каждого из этих четырёх уровней: сколько нужно инфоблоков и типов, как устроено дерево разделов, какие элементы в нём будут жить и какими свойствами описываться. Пропуск любого из уровней на этапе планирования — источник будущих переделок.
Шаг 1: описываем типы контента, а не копируем меню
Частая методическая ошибка — открыть карту сайта и один в один превратить пункты меню в инфоблоки: есть пункт «Новости» — заводим инфоблок «Новости», есть «Акции» — заводим инфоблок «Акции». Меню сайта — это навигация для посетителя, она может меняться от редизайна к редизайну, и она ничего не говорит о том, какие данные на самом деле нужно хранить и как они связаны между собой.
Правильная отправная точка — описать типы контента как самостоятельные сущности, независимо от того, как они будут называться в меню. Для каждого типа контента стоит явно зафиксировать: какие у него уникальные атрибуты, кто его создаёт и модерирует, как часто он публикуется, есть ли у него версионность и нужны ли отдельные права доступа. Например, «Акции» и «Новости» на первый взгляд похожи (заголовок, текст, дата, фото), но у акций обычно есть дата начала/окончания действия и, возможно, привязка к конкретным товарам — а значит, это разные сущности с разным набором свойств, даже если из меню они выглядят как соседние пункты одного типа.
Соглашение о наименованиях с первого дня
Небольшая, но недооценённая часть проектирования — договориться о правилах наименования кодов инфоблоков, разделов и свойств прежде, чем в админке появится первая сущность. Без явного соглашения команда, которая растёт со временем, неизбежно приходит к разнобою: одно свойство называется BRAND, другое — MANUFACTURER, хотя оба хранят производителя; в одном инфоблоке символьный код на латинице, в другом — транслит с цифрами.
| Что называем | Правило | Пример |
|---|---|---|
| Символьный код инфоблока | Латиница, snake_case, по смыслу | news, portfolio, branches |
| Код свойства | Латиница, UPPER_SNAKE_CASE, без сокращений «на свой вкус» | MANUFACTURER, а не MANUF |
| Человекочитаемое название | По-русски, единообразно во всех инфоблоках | «Бренд» — везде «Бренд», не «Производитель» в одном месте |
| Символьный код раздела | Латиница, транслит без произвольных сокращений | internet-magaziny, не im |
Зафиксируйте эти правила одной страницей в проектной документации до начала работы в админке — это разовая инвестиция, которая экономит часы разбора «а что такое PROP_17» на каждом следующем этапе проекта, включая работу новых разработчиков, которые подключатся позже.
Проектирование дерева разделов
Дерево разделов — это не просто способ разложить элементы по папкам, а инструмент классификации, от которого зависят фильтрация, навигация и SEO-структура URL. При проектировании стоит заранее ответить на несколько вопросов: нужна ли многоуровневая иерархия или достаточно одного уровня; будет ли элемент относиться только к одному разделу или к нескольким одновременно (в 1С-Битрикс это отдельная настройка — множественная привязка к разделам); как глубоко нужно уходить в детализацию, чтобы не получить либо пустые «разделы ради разделов», либо, наоборот, один гигантский раздел с тысячами элементов без внутренней структуры.
Отдельно стоит спроектировать, что будет осью классификации, если у контента потенциально есть несколько независимых измерений — например, у портфолио это может быть и отрасль клиента, и тип решения (интернет-магазин, корпоративный сайт, B2B-портал). Если оба измерения нужны одновременно, дерево разделов справляется только с одним из них — второе измерение лучше вывести отдельным свойством типа «список», а не пытаться смоделировать двумя пересекающимися деревьями разделов.
Осознанный выбор типов свойств
Выбор типа свойства — решение с долгими последствиями: свойство типа «Строка» легко завести, но плохо фильтруется, плохо нормализуется и почти всегда превращается в разнобой написаний («Москва», «москва», «г. Москва») при накоплении данных. Ориентируйтесь на таблицу ниже при выборе типа для каждого нового свойства.
| Тип свойства | Когда использовать | Риск при неверном выборе |
|---|---|---|
| Список | Конечный набор значений: статус, категория, бренд | Строка вместо списка → разнобой написаний, сломанная фильтрация |
| Число / целое | Цена, вес, срок, количество — всё, что участвует в диапазонах | Строка вместо числа → невозможна сортировка и диапазонный фильтр |
| Привязка к элементам | Связь с записью другого инфоблока (например, «похожие кейсы») | Дублирование текста вместо связи → рассинхрон при правке |
| Привязка к разделам | Ссылка на категорию другого инфоблока или того же дерева | Хранение названия раздела текстом вместо ссылки → «слепая» связь |
| Привязка к HL-справочнику | Большой общий справочник значений на десятки тысяч записей | Список Bitrix вместо HL при росте справочника → тяжёлая админка |
| Файл / изображение | Медиа-контент элемента | Хранение пути к файлу строкой вместо типа «Файл» → нет валидации и предпросмотра |
| Строка | Действительно уникальный, не структурируемый текст (заголовок, артикул) | — |
Практическое правило: если по свойству когда-либо потребуется фильтровать, сортировать или группировать элементы — это не «Строка». Строка оправдана только там, где значение по определению уникально для каждого элемента и не участвует в классификации.
Множественные свойства: когда они нужны
Отдельное проектное решение — делать ли свойство множественным (у элемента может быть несколько значений одного свойства сразу). Типичные кандидаты — теги, категории применения, файлы галереи, связанные материалы. Ошибка в обе стороны обходится дорого: сделать множественным то, что по смыслу должно быть одним значением (например, «статус публикации»), создаёт риск логических ошибок в коде и шаблоне, которые обрабатывают такое свойство как единственное значение. А сделать одиночным то, что по смыслу множественно (например, «применимые отрасли» у решения из портфолио, когда решение подходит сразу нескольким), заставляет либо дублировать элементы под каждую отрасль, либо городить костыль со строкой через запятую.
Правило простое: если бизнес-логика допускает у одного элемента несколько значений одновременно и это не искусственная ситуация — свойство множественное с самого начала. Переключить одиночное свойство в множественное после накопления данных технически возможно, но требует аккуратной миграции значений.
Связи между инфоблоками вместо дублирования
Когда одна и та же сущность нужна в контексте разных типов контента — например, «бренд» упоминается и в каталоге, и в новостях о поступлениях, и в фильтре сайта, — соблазн просто продублировать текстовое поле «Бренд» в каждом инфоблоке. Это работает до первого переименования: если бренд сменил название или произошло слияние двух брендов, придётся вручную поправить значение во всех местах, где оно продублировано текстом, и почти наверняка что-то будет упущено.
Правильное решение — вынести общую сущность в отдельный инфоблок или highload-справочник и связывать с ней остальные инфоблоки через свойство типа «привязка к элементам» (или «привязка к HL-блоку»). Тогда бренд существует в системе в одном месте, у него может быть собственная страница, логотип, описание — а все инфоблоки, которым нужен бренд, просто на него ссылаются. Переименование или правка происходит один раз и мгновенно отражается везде, где есть ссылка.
Антипаттерн «один инфоблок на всё»
Обратная крайность — завести один инфоблок «Контент» или «Материалы» и пытаться уместить в него новости, акции, кейсы и статьи, различая их одним служебным свойством «Тип материала». На старте это кажется экономией: меньше сущностей в админке, один компонент вывода на всё. На практике это одна из самых дорогих архитектурных ошибок.
- Свойства расползаются. У новости не нужны поля кейса (бюджет, срок), у кейса не нужны поля акции (даты действия) — но в общем инфоблоке они физически присутствуют у каждого элемента, создавая пустые и запутывающие поля.
- Права доступа невозможно разграничить точно. Если у новостей одна модерация, а у кейсов — другая, в общем инфоблоке настроить это раздельно нельзя: права выдаются на инфоблок или раздел целиком.
- Логика публикации конфликтует. Разная периодичность, разные workflow согласования, разные сроки жизни контента — всё это плохо уживается в одной сущности.
- Вывод усложняется. Шаблон компонента вынужден постоянно проверять «а что это за тип материала» и ветвиться внутри — вместо того чтобы каждый инфоблок выводился своим простым шаблоном.
Как это выглядит в админке 1С-Битрикс
Создание инфоблока и настройка его свойств происходит в разделе «Контент → Инфоблоки». Схематично форма создания свойства с выбором типа выглядит так:
Когда закладывать highload-блок заранее
Highload-блок стоит рассматривать уже на этапе проектирования, если для какого-то справочника заранее видно, что он вырастет до тысяч или десятков тысяч записей без внутренней иерархии — типичные примеры: полный справочник артикулов поставщика, единый список серийных номеров, большой географический справочник населённых пунктов. Такие данные плохо подходят для обычного списочного свойства инфоблока: список Bitrix хранится плоско и при большом числе значений заметно нагружает админку и выборки.
Закладывать highload-блок с первого дня для каждого потенциально большого справочника не обязательно — если объём сейчас невелик, можно начать со списка и мигрировать при росте. Но полезно заранее понимать, какие справочники — кандидаты на такую миграцию, и не встраивать в код и шаблоны жёсткие предположения, что это именно свойство-список инфоблока, которые потом придётся переписывать. Подробно порог перехода и техническую механику разбирает статья «Highload-блоки в 1С-Битрикс: большие справочники и характеристики».
Что учесть для будущего роста контента
Проектирование с запасом не означает добавлять «на всякий случай» десятки полей, которые никогда не понадобятся, — это тоже ошибка, только с другой стороны. Речь о нескольких конкретных практиках, которые не усложняют структуру сегодня, но экономят время завтра:
- Оставляйте резерв в дереве разделов. Не создавайте максимально глубокую иерархию сразу, но продумайте, куда «встанет» новая категория через год, не ломая существующие URL.
- Выносите потенциально общие сущности отдельно с первого дня. Если бренд, автор или регион используются больше чем в одном инфоблоке — сразу делайте отдельную сущность со связью, а не дублируйте текстом «пока не понадобится».
- Документируйте структуру, а не держите её в голове одного разработчика. Таблица «инфоблок → назначение → ключевые свойства → связи» экономит часы при передаче проекта или подключении нового специалиста.
- Проверяйте структуру на втором сценарии использования до запуска. Если планируется второй похожий раздел (второй бренд, вторая страна, вторая линейка), проверьте на нём структуру мысленно ещё до разработки — это вскрывает скрытые допущения быстрее, чем ожидание реального роста.
Частые ошибки
- Копируют пункты меню сайта в инфоблоки один в один вместо анализа типов контента и их жизненного цикла.
- Заводят свойство «Строка» там, где нужен «Список» — получают разнобой написаний при накоплении данных.
- Дублируют общие сущности (бренд, автор, регион) текстом в разных инфоблоках вместо связи через привязку.
- Делают один инфоблок «на всё» с разными типами контента внутри — теряют возможность разграничить права и логику публикации.
- Не фиксируют соглашение о наименовании кодов — через полгода в проекте разнобой BRAND / MANUFACTURER / PROIZVODITEL.
- Проектируют дерево разделов под одну ось классификации, хотя контенту реально нужны две независимые оси.
- Игнорируют потенциальный рост справочника до объёмов, требующих highload-блока, и жёстко завязывают код на список инфоблока.
- Не документируют структуру — при передаче проекта новый разработчик тратит дни на реверс-инжиниринг того, что можно было прочитать за 10 минут.
Чек-лист проектирования структуры
- Типы контента описаны отдельно от меню сайта — с атрибутами, логикой публикации и правами доступа для каждого.
- Соглашение о наименовании зафиксировано — коды инфоблоков, свойств и разделов, единый регистр и язык.
- Дерево разделов спроектировано под реальную ось классификации, вторая ось (если есть) вынесена свойством.
- Тип каждого свойства выбран осознанно — «Строка» только там, где значение действительно уникально и не структурируется.
- Множественность свойств определена по бизнес-логике, а не по умолчанию.
- Общие сущности вынесены отдельно и связаны привязкой, а не продублированы текстом.
- Потенциально большие справочники отмечены как кандидаты на highload-блок при росте.
- Структура задокументирована одной таблицей, доступной всей команде проекта.
Вывод
Структура инфоблоков — это не техническая формальность, которую можно доработать «потом», а архитектурное решение с долгим сроком жизни, сравнимое по значимости со структурой базы данных в любом другом проекте. Час на то, чтобы описать типы контента, выбрать типы свойств осознанно и договориться о наименованиях, окупается уже на первом расширении сайта — когда новый раздел встраивается в готовую структуру за час, а не превращается в миграцию на неделю.
