Основные ошибки при разработке интернет-магазина и каталога на 1С-Битрикс

Большинство серьёзных проблем в B2B-каталогах на 1С-Битрикс рождаются не тогда, когда сайт уже тормозит. Они закладываются раньше — на этапе проектирования структуры данных, модели каталога и подхода к интеграциям.

Типичная ситуация: менеджер по закупкам вводит OEM-номер или кросс, а сайт либо ничего не находит, либо выдаёт нерелевантную выдачу. При этом товар в каталоге есть. На небольших объёмах такие ошибки ещё можно терпеть. Когда позиций становится 10–30 тысяч, а поиск идёт именно по артикулам и кроссам, цена каждого неудачного решения резко возрастает: падает скорость, ухудшается поиск, растёт стоимость поддержки и теряется гибкость развития.

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

Ошибки на этапе проектирования и архитектуры

Самая дорогая ошибка — неправильная структура каталога. Многие начинают с одного большого инфоблока «Товары» и набивают в него всё подряд: свойства строками, торговые предложения через свойства, разделы «как получится». Через полгода–год выясняется, что фильтры тормозят, свойства плодятся дублями, а любое новое требование (региональные цены, дополнительные характеристики, кросс-номера) требует серьёзной переделки.

Вторая классическая проблема — строковые свойства вместо справочников. Когда в каталоге тысячи артикулов, производителей и кросс-номеров, строки быстро превращают базу в помойку. Появляются «Bosch», «BOSCH» и «Бош», поиск деградирует, а обновление из 1С становится источником новых ошибок.

Как делают часто	Как лучше
Один огромный инфоблок + свойства строками	Инфоблоки 2.0, отдельные SKU, справочники в Highload-блоках
Разделы «как удобно сейчас»	Разделы с учётом SEO и логики B2B-пользователя
Торговые предложения через свойства	Отдельный инфоблок SKU с жёсткой привязкой по XML_ID

Highload-блоки — это специальные таблицы Битрикса для хранения больших справочников. Они работают значительно быстрее обычных свойств, когда значений много.

Правильная архитектура с самого начала экономит месяцы работы позже. Мы неоднократно видели это на каталогах грузоподъёмного оборудования (10 000+ позиций) и запчастей для спецтехники.

Ошибки в работе с каталогом и поиском

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

На практике это выглядит так: человек вводит часть номера — ничего не находит. Меняет раскладку — тоже ничего. Пытается найти аналог — система молчит, хотя товар в каталоге есть. В итоге менеджеры получают звонки «у вас этого нет?», хотя позиция на сайте есть, просто её невозможно найти.

Особенно это заметно на каталогах запчастей. Там кросс-номера — не дополнительная информация, а основной инструмент работы.

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

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

Ошибки производительности

Самый частый сценарий: на этапе разработки всё «летает», а через полгода, когда каталог вырос и накопились свойства, страницы разделов и фильтров начинают открываться по 5–12 секунд.

Главный виновник обычно — фасетный индекс (специальная таблица, которая ускоряет работу умного фильтра). При большом количестве свойств, разделов и SKU она раздувается до миллионов записей, и MySQL перестаёт эффективно обрабатывать запросы. Добавьте сюда тяжёлые выборки в компонентах, подсчёт количества элементов там, где он не нужен, и выполнение тяжёлых агентов на хитах пользователей — получите классическую картину «сайт тупит именно в рабочее время».

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

SEO-ошибки, заложенные на этапе разработки

Многие SEO-проблемы больших каталогов появляются не из-за отсутствия текстов, а из-за того, как изначально спроектированы URL, фильтры и пагинация.

Типичная картина: фильтры генерируют тысячи страниц с разными комбинациями параметров, пагинация создаёт дубли, canonical настроен неправильно или отсутствует, а страницы 404 отдают код 200. Поисковик начинает индексировать мусор, а полезные страницы товаров и разделов теряют вес.

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

Правильный подход — проектировать ЧПУ и правила индексации фильтров с самого начала, а не «потом поправим».

Ошибки интеграций с 1С, CRM, остатками и ценами

Интеграция с 1С — одна из самых частых точек отказа на больших каталогах. Ошибки здесь редко всплывают в первые недели. Обычно они проявляются через несколько месяцев: появляются дубли из-за смены XML_ID, цены маппятся неправильно, остатки обновляются с задержкой, а обмен начинает падать по таймауту, когда объём данных растёт.

XML_ID — это уникальный идентификатор элемента, по которому Битрикс понимает, что товар из 1С уже существует и его нужно обновить, а не создать заново. Если с ним работают неаккуратно, каталог начинает расползаться.

На B2B-проектах последствия особенно чувствительны: менеджеры работают в двух системах, клиенты видят неактуальные остатки, а доверие к сайту падает.

Ошибки в администрировании и поддержке

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

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

Ошибки безопасности и обновлений

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

Особенности больших каталогов (10 000+ позиций)

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

Опыт работы с каталогами грузоподъёмного оборудования (10 000+) и запчастей для спецтехники (30 000+) показывает одну и ту же закономерность: решения, которые нормально работают на небольших объёмах, на больших каталогах требуют другого подхода уже на этапе проектирования.

Чек-лист перед запуском или при приёмке проекта

Критично проверить:

• Структура инфоблоков и свойств рассчитана на рост каталога?
• Справочники вынесены в Highload-блоки там, где значений много?
• Поиск по артикулам и кроссам работает так, как реально ищут B2B-пользователи?
• Умный фильтр и листинги показывают приемлемую скорость на реальном объёме данных?
• Обмен с 1С устойчив на больших объёмах и корректно работает с XML_ID?

Важно проверить:

• Настроены canonical, пагинация и правила индексации фильтров?
• Остатки и цены обновляются достаточно оперативно?
• Есть документация по структуре и ключевым доработкам?
• Код не содержит правок ядра?
• Понятен процесс дальнейшей поддержки и развития?

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

Когда каталог уже работает и накопились последствия старых решений, или когда проект только проектируется и хочется сразу сделать правильно, имеет смысл провести аудит или привлечь команду с опытом именно больших B2B-каталогов на Битрикс. В Éxitos Lab мы регулярно работаем с такими проектами — в том числе с каталогами запчастей и промышленного оборудования на десятки тысяч позиций — и можем помочь как на этапе проектирования, так и при разборе уже существующего сайта.