Мультирегиональность на 1С-Битрикс: один сайт вместо копий под каждый город

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

Что на самом деле означает «регион» для интернет-магазина

Провести грань полезно до покупки любого модуля. У мультирегиональности есть два уровня, и они требуют очень разных объёмов работ.

Лёгкий уровень — информационный. Задача: посетитель видит контакты, адрес, телефон и e-mail своего города, а служебные данные подставляются в общий каркас страницы. Здесь достаточно переменных и компонента переключения региона. Именно так устроен, например, модуль KLITE: Мультирегиональность: он подставляет региональные данные через теги вида , #REGION_PHONE# в шаблонах, инфоблоках и контенте страниц, умеет склонять название региона по шести падежам и приводить телефон и e-mail к формату ссылки (tel:, mailto:). Добавление нового региона здесь не требует правки шаблонов и контента.

Коммерческий уровень — бизнес-логика. Задача сложнее: у региона должны быть свои цены, свои склады и остатки, свой набор доставок и способов оплаты, свой менеджер и свои SEO-профили. Это уже не «подстановка текста», а правила, которые действуют в каталоге, карточке товара, корзине и на оформлении заказа.

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

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

Первое, что нужно понимать про любую мультирегиональность: определение региона — это цепочка источников, а не одна кнопка.

• GeoIP по IP-адресу. Все четыре решения опираются на штатную инфраструктуру 1С-Битрикс: в описании Bussol RegionsPro перечислены GeoIP2, Sypex Geo, а также внутренние сервисы Main\Service\GeoIp и Sale\Location\GeoIp.
• Резервные внешние провайдеры. У RegionsPro и RegionsUltra предусмотрены fallback-провайдеры (в описаниях названы IPWhoIs и IPAPI) с настраиваемым порядком обращения и сетевым таймаутом. Если сервис возвращает координаты, модуль сопоставляет их с ближайшим настроенным регионом — это снижает зависимость от того, как внешний сервис пишет название города.
• GPS браузера. Если по IP определить регион не удалось, может использоваться HTML5 Geolocation — но только после явного разрешения пользователя. В описаниях особо подчёркнуто: координаты пользователя не сохраняются в базе данных, в сессии остаётся только идентификатор найденного региона.
• Ручной выбор и поддомен. Регион может задаваться поддоменом или ранее сделанным выбором посетителя.

У Bussol RegionsPro есть отдельная диагностика GeoIP: администратор видит, какой IP фактически получает сайт, откуда он взят, порядок IP-кандидатов, результаты отдельных обработчиков и итоговый результат. Это не косметика — при жалобах «сайт показывает не мой город» именно эта цепочка объясняет причину.

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

Архитектура: один домен, поддомены, отдельные домены или регион в URL

Это решение принимается до покупки модуля, потому что от него зависят и DNS, и SEO, и требования к веб-серверу.

Поддерживаются и смешанные структуры: мультиязычные и многосайтовые, в том числе сайты на одном домене в подпапках (примеры форматов вида example.ru/ru/moscow/ и example.ru/kz/almaty/ приведены в описаниях). Для каждого сайта в RegionsPro отдельно настраиваются активность региональности, формат URL, настройки компонента выбора, cookies и региональная конфигурация.

Отдельно про режим поддоменов в KLITE: Мультирегиональность: только там каждый регион индексируется как самостоятельный сайт — с отдельной картой сайта, отдельным robots.txt и уникальными заголовками за счёт подстановки города, а правила перезаписи настраиваются автоматически. Для одного домена этот аргумент не работает: поддомены и URL-схемы дают разный SEO-эффект, и обещать «индексацию как отдельных сайтов» на одном домене нельзя.

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

Механика переменных похожа во всех решениях, но набор полей отличается.

• KLITE: Мультирегиональность — теги , #REGION_PHONE# и аналогичные в шаблонах, инфоблоках и контенте; изменение региональных переменных выполняется в одном поле админраздела и применяется ко всем страницам и всем письмам.
• Bussol: Мультирегиональность — маркеры , #REGION_PHONE#, #REGION_ADDRESS# для итогового HTML, региональные поля также доступны в почтовых событиях.
• Bussol RegionsUltra — не фиксированный набор, а произвольные региональные поля: адрес склада, минимальная сумма заказа, график работы, текст доставки, название филиала, реквизиты, ссылка на мессенджер, юридическая информация. Дальше значения используются как переменные вроде #REGION_WORK_TIME#, #REGION_WAREHOUSE_ADDRESS#, #REGION_MIN_ORDER#.

Склонения тоже решают практическую задачу, а не украшают текст. RegionsUltra поддерживает формы «Москва / Москвы / Москве / Москву / Москвой / о Москве», чтобы получить естественные конструкции: «Купить оборудование в Москве», «Доставка до Москвы», «Склад в Москве». Без склонений все региональные заголовки звучат шаблонно и одинаково — это видно и посетителю, и поисковику.

Региональные цены, скидки и наценки

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

Bussol RegionsUltra добавляет к этому явные сценарии: «Москва — розничная цена + склад Москва», «Казань — региональная цена + склад Казань», «Оптовый покупатель — оптовая цена независимо от базового регионального сценария». То есть региональная цена не обязана побеждать всегда: группа клиента может её переопределить.

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

Склады, остатки и ассортимент по региону

Логика везде одна: региону (или группе регионов) назначается набор доступных складов, и посетитель видит ассортимент и наличие в соответствии со своей конфигурацией. Склады могут назначаться напрямую региону, наследоваться от группы или изменяться правилами.

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

Для управления ассортиментом, а не только остатками, в Bussol RegionsPro есть фильтрация каталога по региону: элементы инфоблока по LINK_REGION и разделы по UF_REGION. Это позволяет скрывать товары и категории, недоступные в регионе, на уровне выборки, а не через десятки условий в шаблоне.

В Bussol: Мультирегиональность эта же задача решается через «геозависимые товары и разделы» — региональную фильтрацию каталога с использованием настроенных свойств и фильтров. Формально это гибче (свои свойства под свой проект), но и требует, чтобы свойства были заведены и заполнены.

Доставка, оплата и проверка на стороне сервера

Самый частый дефект внедрения — «мы скрыли лишние доставки в интерфейсе». Скрытие в вёрстке не является ограничением: заказ можно собрать в обход формы.

В описаниях трёх решений подчёркнуто, что ограничения проверяются повторно на стороне сервера перед сохранением заказа. Для Bussol RegionsPro прямо сказано: региональные ограничения повторно проверяются, а логика не должна зависеть только от клиентской части сайта. То же заявлено в Bussol RegionsUltra. Практические сценарии, которые это закрывает:

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

Отдельная полезная деталь RegionsPro — расчёт доставки прямо в карточке товара, до перехода в корзину, с использованием штатного механизма sale и учётом текущего региона. Это уменьшает количество «неожиданностей» на последнем шаге оформления, где и теряются заказы.

Региональные валюты есть в Bussol RegionsUltra: Россия → RUB, Казахстан → KZT, Беларусь → BYN, Армения → AMD; валюта назначается региону, группе или правилом, для конвертации используется штатная инфраструктура валют Битрикс. Если проект работает только внутри одной страны, этот блок вам не понадобится.

SEO при мультирегиональности: профили, robots.txt и canonical

Заменить название города в заголовке — не SEO, а подстановка строки. Полноценный региональный SEO-контур состоит из профилей и технических файлов.

В Bussol RegionsPro есть SEO-центр с профилями для всех регионов, группы регионов и конкретного региона. Для профиля настраиваются TITLE, H1, DESCRIPTION, ROBOTS, CANONICAL и SEO-текст; поддерживаются маркеры #REGION_*#, а настройка конкретного региона имеет приоритет над общими. Плюс региональное управление robots.txt и sitemap.xml — это актуально для отдельных доменов, поддоменов, региональных URL и большого количества посадочных страниц.

В Bussol RegionsUltra аналогичный SEO Center и управление региональными техническими файлами. В KLITE: Мультирегиональность к этому прилагаются мультирегиональный sitemap.xml, robots.txt для каждого региона и автоматическая настройка правил перезаписи — но в привязке к режиму поддоменов.

И отдельный риск, о котором легко забыть: композитный режим. В описании RegionsPro указано, что компонент выбора региона учитывает особенности композита, персональный выбор и результат GeoIP не берутся из сохранённой статической HTML-копии страницы, а региональная часть работает через динамический фрейм с отдельным AJAX-запросом. Без этого посетитель может получить региональные данные другого пользователя из кеша. У Bussol: Мультирегиональность поддержка композита и многосайтовости решена через динамический фрейм компонента и AJAX-уточнение региона.

Движок правил: где заканчивается «выбор города» и начинается логика

Главное различие между решениями — не в количестве настроек, а в том, есть ли движок правил.

Bussol RegionsPro и Bussol RegionsUltra содержат визуальный Rule Engine. Условия правила могут учитывать сайт, регион, код региона, группу регионов, группу пользователя, конкретный товар, раздел каталога, бренд, сумму корзины, день недели, время и URL страницы; комбинации работают через AND / OR, у правил есть приоритет и возможность прекратить дальнейшую обработку.

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

Пример из описания RegionsPro: для группы регионов — региональный тип цены, товары только с двух выбранных складов, бесплатная доставка при корзине от 30 000 ₽ и автоматическое назначение нужного менеджера. Для другой группы — другой склад, другой набор доставок и наценка. Пример RegionsUltra: оптовым покупателям из Центрального федерального округа при заказе от 100 000 ₽ включается оптовый тип цены, используется центральный склад, применяется скидка 5%, остаются только нужные доставки и назначается отдельный менеджер.

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

Группы регионов и наследование настроек

Как только городов становится больше десяти, настройка каждого отдельно превращается в проблему сопровождения. Bussol RegionsPro и Bussol RegionsUltra предлагают иерархические группы с наследованием: например, Россия → Центральный регион → Москва и область → Москва.

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

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

Проверка конфигурации: симулятор, конфликты и откат

Это тот блок, который отличает «профессиональный» уровень от базового, и именно его чаще всего недооценивают при выборе.

Bussol RegionsPro содержит Симулятор региона: он проверяет сценарий без изменения cookie и без переключения реального региона пользователя и показывает, в какие группы входит регион, откуда унаследованы настройки, какие правила проверялись, какие сработали, а также итоговый коммерческий и SEO-профиль.

Bussol RegionsUltra идёт дальше по управлению изменениями:

• Draft → Test → Publish. Пока конфигурация в черновике, посетители работают с опубликованной версией.
• Проверка конфликтов. Модуль находит правила с одинаковым приоритетом, меняющие один и тот же тип цены, регионы с противоречащими настройками, отсутствие обязательной конфигурации, несовместимые унаследованные параметры, регион без склада, пересекающиеся SEO-профили, не настроенную валюту.
• История и откат. Хранится история опубликованных конфигураций с возможностью восстановить предыдущую рабочую ревизию.
• Health Center контролирует версию PHP, необходимые модули, GeoIP, настройки, количество регионов, правил и групп, SEO-профили, конфликты и проблемы конфигурации.

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

Многосайтовость, импорт регионов и перенос между средами

Если проект уже многосайтовый, проверьте это до покупки. Bussol: Мультирегиональность поддерживает отдельные настройки по сайтам, а в поставку входит демонстрационный справочник регионов: 8 федеральных округов, 86 субъектов и 1 629 населённых пунктов, импортируемых фоновым агентом и сопоставляемых с местоположениями, имеющимися на сайте. При необходимости привязки корректируются администратором — рассчитывать на «импортировалось и сразу правильно» не стоит.

У Bussol RegionsUltra для крупных проектов есть массовое управление через импорт и экспорт XLSX, CSV и JSON-конфигураций: переносятся регионы, контакты, цены, склады, доставки, оплаты, менеджеры, SEO и произвольные поля. Там же — перенос конфигурации между development, staging и production с раздельной работой над LIVE- и DRAFT-конфигурацией. Для интеграторов и командной разработки это экономит основное время внедрения.

Готовые решения: что из коробки предлагает базовый уровень

Чтобы не переплачивать, полезно понимать объём базового функционала.

Bussol: Мультирегиональность — автоматическое определение города через GeoIP и предложение подтвердить его, три режима селектора (компактный выпадающий список, поиск, трёхуровневая навигация «округ → регион → город»), региональные домены и поддомены, контакты представительств, привязка регионов к типам цен и складам, подстановка переменных в HTML и почтовые события, компонент bussol:regions.selector на нативном JavaScript без jQuery. Требования в описании: «1С-Битрикс: Управление сайтом» редакций «Малый бизнес» и «Бизнес», PHP 8.2 или новее, модули main, iblock, sale, а для типов цен и складов — catalog.

Технические требования у Bussol RegionsPro те же по составу модулей, и там отдельно указано, что jQuery не требуется и зависимость от шаблонов Aspro или другого готового решения отсутствует. Это важно при смене шаблона: модуль не придётся переустанавливать вместе с дизайном.

Типичные ошибки внедрения мультирегиональности

• Скрывать доставку и оплату в шаблоне. Ограничение без серверной проверки обходится; проверяйте заказ при сохранении, а не только форму.
• Показывать региональную цену без ограничения склада. Покупатель видит низкую цену и оформляет заказ на недоступный склад — или наоборот.
• Забыть про композитный режим. Персональный выбор региона не должен приходить из статической HTML-копии.
• Навязывать GeoIP-регион. Автоматическое определение, подтверждение, ручной выбор и закрытие предложения — разные состояния; их нужно различать.
• Включать глобальные ограничения сразу на живом сайте. В описании базового модуля прямо сказано: глобальные ограничения по умолчанию выключены, включать их нужно после проверки на конкретном магазине.
• Строить поддомены без подготовки. Режим поддоменов требует предварительной настройки DNS, веб-сервера и HTTPS.
• Ждать идеального GeoIP. Точность определения города зависит от провайдера и сетевой инфраструктуры — закладывайте fallback и ручной выбор.
• Одинаковый SEO для всех городов. Без региональных профилей и canonical десятки страниц конкурируют сами с собой.
• Коммерческая логика в коде. Каждая новая комбинация «регион + бренд + сумма корзины» превращается в доработку и релиз.

Чек-лист выбора модуля

Пройдите по пунктам и отметьте, что реально нужно. Каждый «да» поднимает уровень требований.

• Сколько у вас складов и есть ли они в разных городах? Один — хватит базового уровня.
• Отличаются ли цены по регионам, и есть ли типы цен в каталоге?
• Зависит ли способ доставки или оплаты от территории?
• Нужны ли ограничения для B2B-клиентов или групп пользователей?
• Сколько регионов ожидается через год: 5, 50 или 500?
• Нужны ли разные валюты и страны?
• Планируете ли поддомены или отдельные домены (проверьте DNS, HTTPS, правила перезаписи)?
• Используется ли композитный режим?
• Нужны ли региональные TITLE, H1, DESCRIPTION, canonical, robots.txt и sitemap.xml?
• Есть ли несколько администраторов, которым нужно тестировать изменения до публикации и откатывать их?
• Нужен ли перенос конфигурации между dev, staging и production?
• Совпадают ли версия PHP и модули (main, iblock, sale, catalog) с требованиями модуля?
• Есть ли шаблон нестандартного решения — и заявлена ли совместимость?

Если «да» больше трёх по второму блоку (регионы десятками, правила, откат, многосайтовость) — смотрите в сторону платформ с движком правил и управлением конфигурацией: Bussol RegionsPro или Bussol RegionsUltra, с оглядкой на заявленные различия (валюты, произвольные поля, импорт, Health Center и аналитика — в сторону Ultra). Если задача ограничена контактами и лёгкой привязкой цен и складов — достаточно Bussol: Мультирегиональность. Если нужен режим поддоменов с отдельной индексацией и готовым набором переменных с падежами — смотрите KLITE: Мультирегиональность.

Что сделать после установки

1. Спроектировать дерево регионов и групп до заполнения данных.
2. Проверить справочник регионов и привязки к местоположениям, которые уже есть на сайте.
3. Настроить контакты и переменные, затем селектор города — и только после этого переходить к коммерции.
4. Включить ограничения цен, складов, доставок и оплаты поэтапно, проверяя каталог, корзину и оформление заказа.
5. Прогнать сценарии в симуляторе и убедиться, что регион сохраняется в заказе.
6. Настроить региональные SEO-профили, canonical и технические файлы.
7. Проверить публичную часть и сбросить кеш — включая композитные копии страниц.

Итог

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