Мультирегиональность и поддомены для SEO на 1С-Битрикс

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

Эта статья — подробное практическое руководство по мультирегиональности интернет-магазина на 1С-Битрикс: чем поддомены отличаются от папок и от одного домена с геолокацией, как определять регион покупателя, как подменять цены, склады и контакты, как уникализировать региональные метатеги и тексты, как не наплодить дублей с помощью canonical и когда вообще нужен hreflang. Материал вырос из нашей практики разработки мультирегиональных сайтов на 1С-Битрикс — по делу, без обещаний «магии продвижения».

Что такое мультирегиональность и зачем она магазину

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

Важно сразу развести две стороны задачи, которые часто путают:

• Коммерческая (продажи). Разные цены, склады, контакты и логистика по регионам. Это про то, чтобы покупателю было удобно и чтобы он видел релевантные условия своего города.
• Поисковая (SEO). Отдельные региональные страницы, привязанные к городам, уникальные метатеги и тексты, правильная работа с дублями. Это про то, чтобы магазин ранжировался в каждом регионе по местным запросам.

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

Как мультирегиональность влияет на продажи и трафик

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

Вот что даёт грамотная мультирегиональная структура:

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

Три модели: поддомены, папки, один домен

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

• Региональные поддомены — msk.shop.ru, spb.shop.ru, ekb.shop.ru. Каждый город живёт на своём поддомене, который в Яндексе можно явно привязать к региону.
• Региональные папки — shop.ru/msk/, shop.ru/spb/. Города — это разделы основного домена.
• Один домен с определением региона — shop.ru без региональных URL, только динамическая подмена цен и контактов по геолокации.

Сравним их по ключевым критериям:

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

Региональные поддомены msk. и spb.

Поддомены — самая мощная и самая ресурсоёмкая модель. Для каждого города создаётся отдельный поддомен третьего уровня: msk.shop.ru, spb.shop.ru и так далее. В Яндекс.Вебмастере каждый такой поддомен добавляется как отдельный сайт, и ему явно назначается регион. Это главный козырь модели: поисковик прямо понимает, что ekb.shop.ru — это про Екатеринбург, и показывает его местным пользователям.

Что нужно для поддоменов на 1С-Битрикс:

• DNS-записи. Wildcard-запись *.shop.ru или отдельные A/CNAME на каждый поддомен, указывающие на тот же сервер.
• SSL-сертификат. Wildcard-сертификат *.shop.ru, чтобы все поддомены открывались по HTTPS без предупреждений.
• Настройка сайтов. Либо многосайтовость Битрикса (каждый поддомен — отдельный сайт со своими настройками), либо один сайт, который разбирает хост и подставляет регион.
• Свои robots.txt и sitemap.xml на каждом поддомене с правильным Host и картой.
• Уникализация контента — метатеги, тексты, цены, склад, контакты по региону.

Плюсы поддоменов: максимальный региональный SEO-трафик, чёткая привязка к городам, восприятие как самостоятельных площадок, возможность гибко различать ассортимент и цены. Минусы: сложность (DNS, SSL, многосайтовость), риск дублей при недостаточной уникализации, необходимость отдельно наращивать траст каждого поддомена и следить за техникой на каждом из них.

Папки /msk/ и /spb/

Модель папок реализует регионы как разделы основного домена: shop.ru/msk/, shop.ru/spb/. Технически это проще поддоменов — не нужны отдельные DNS-записи, wildcard-SSL и многосайтовость. Всё живёт на одном сайте, а регион определяется первым сегментом пути.

Сильные стороны папок:

• Наследование траста. Все региональные страницы работают в пределах авторитетного основного домена, а не начинают набирать вес с нуля.
• Простота технической поддержки. Один сертификат, один DNS, один сайт в админке.
• Единая аналитика. Весь трафик в одном счётчике без «размазывания» по поддоменам.

Слабые стороны тоже есть. Привязать отдельную папку к региону в Яндексе сложнее, чем поддомен: региональность домена в вебмастере задаётся, как правило, на весь сайт, а не на отдельный каталог. Поэтому папки чаще работают как посадочные под региональные запросы за счёт уникального контента, но без такой же явной геопривязки, как у поддоменов. Для среднего магазина, которому важнее простота и который не готов вести десятки поддоменов, папки — разумный компромисс. Структуру таких региональных разделов удобно проектировать в связке с общей SEO-структурой сайта.

Один домен с определением региона

Третья модель — вообще без региональных URL. Есть один домен shop.ru, а регион определяется по IP и/или выбору пользователя, после чего сайт подменяет цены, склад, телефон и город в шапке. Для покупателя это удобно: он попадает на сайт и сразу видит «свои» условия. Но для поисковой оптимизации регионов эта модель почти ничего не даёт — отдельных страниц под города нет, привязывать нечего, локальный трафик собирается только по основному региону.

Когда этой модели достаточно:

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

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

Определение региона: IP, выбор, поддомен

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

1. По адресу (поддомен или папка). Если пользователь зашёл прямо на spb.shop.ru или на /spb/, регион уже задан самим URL — это самый явный и надёжный сигнал.
2. По ручному выбору. В шапке сайта стоит переключатель города. Если посетитель выбрал город сам, выбор запоминается в куках и имеет приоритет над автоопределением — человек лучше знает, что ему нужно.
3. По IP-адресу (GeoIP). Если ни адрес, ни куки не заданы, регион определяется автоматически по IP через базу геолокации — это стартовое предположение для нового посетителя.

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

GeoIP и штатная геолокация в Битрикс

В 1С-Битрикс есть штатный инструментарий для геолокации. Модуль геолокации умеет определять местоположение посетителя по IP и по данным браузера, а справочник регионов и городов даёт основу для привязки цен и складов. На практике для определения города по IP используют GeoIP-базы (их подключают к серверу или к самому Битриксу), а результат раскладывается по внутреннему справочнику местоположений.

Как это обычно устроено под капотом:

• База GeoIP сопоставляет IP-адрес с городом/регионом. Базы бывают разной точности; для России достаточно уровня города.
• Справочник местоположений Битрикса хранит иерархию страна → регион → город и связывает её с типами цен, складами и настройками доставки.
• Определённый регион сохраняется в сессии и куках, чтобы не пересчитывать его на каждый запрос и уважать ручной выбор.
• Хост поддомена в мультисайтовой схеме переопределяет автоопределение: адрес важнее IP.

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

Региональные цены и типы цен

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

Логика такая: для каждого региона (или группы регионов) заводится свой тип цены — «Розница Москва», «Розница Урал», «Розница Юг». У товара по каждому типу цены хранится своя стоимость. Определив регион посетителя, сайт показывает цену соответствующего типа. Возможны разные схемы:

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

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

Цена — половина дела; вторая половина — наличие. Товар, который есть в Москве, может отсутствовать в Новосибирске, и показывать «в наличии» там, где его нет, — прямой путь к отменённым заказам и недовольным покупателям. В 1С-Битрикс складской учёт ведётся по складам, и склады привязываются к регионам.

Как строится региональное наличие:

• Склады по городам. Заводятся склады «Москва», «Санкт-Петербург», «Екатеринбург» с остатками по каждому SKU.
• Привязка склада к региону. Определённому региону соответствует один или несколько складов, чьи остатки показываются посетителю.
• Расчёт доступности. Наличие в карточке считается по складам региона, а не по всему магазину суммарно.
• Резерв и заказ. При оформлении товар резервируется на региональном складе, откуда фактически поедет к покупателю.

Наличие тесно связано с торговыми предложениями: если у товара есть размеры и цвета, то остаток каждого SKU считается по региональному складу отдельно. Механику самих вариаций мы подробно разбираем в статье про торговые предложения (SKU) в 1С-Битрикс — в мультирегиональном магазине к ней добавляется лишь измерение «склад региона». Практический вывод: остаток — это всегда пара «что» и «где», и в мультирегиональности «где» становится таким же важным, как «что».

Контакты, доставка и реквизиты по городам

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

Что обычно подменяется по региону:

• Телефон и режим работы. Местный номер (или федеральный 8-800, но с указанием города) в шапке и подвале.
• Адреса и пункты выдачи. Магазины, ПВЗ и точки самовывоза конкретного города.
• Условия доставки. Сроки, стоимость, зоны, способы — они реально различаются по регионам.
• Карта и schema.org. Локальная разметка организации с адресом города усиливает региональность.
• Реквизиты. Если в разных городах работают разные юрлица — правильные данные для договоров и документов.

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

Региональные метатеги и уникализация

Мы подошли к сердцу SEO-части мультирегиональности — уникализации. Без неё все региональные страницы остаются копиями друг друга, и никакая привязка не спасёт от восприятия их как дублей. Первый и самый действенный инструмент уникализации — региональные метатеги: title, description и H1 с подстановкой города.

Это делается шаблонами метатегов, где переменная города подставляется в шаблон. Например:

Title:       Диваны в [city_where] — купить в интернет-магазине [city_short]
Description: Диваны в [city_where]: доставка, наличие на складе, [phone].
H1:          Диваны в [city_where]

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

Кроме метатегов, уникализируют:

• SEO-тексты категорий. Вводный текст раздела с органичным упоминанием города и локальной спецификой (доставка, склад, сроки).
• Хлебные крошки и заголовки. Отражают регион, где это уместно.
• Цены, склад, контакты. Уже сами по себе делают страницу фактически разной.
• Блоки доставки и оплаты с региональными условиями.

Дубли контента и как их избежать

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

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

Canonical для региональных страниц

Отдельно и внимательно — про canonical, потому что здесь совершают самую разрушительную ошибку. Тег <link rel="canonical"> говорит поисковику, какая версия страницы главная. В мультирегиональности критично важно, чтобы canonical каждой региональной страницы указывал на неё саму (в пределах своего поддомена), а не на основной домен.

Сравните две ситуации:

Неправильно (kazan.shop.ru):
  <link rel="canonical" href="https://shop.ru/catalog/divany/">
  → региональная страница отдаёт вес основному домену и выпадает из индекса

Правильно (kazan.shop.ru):
  <link rel="canonical" href="https://kazan.shop.ru/catalog/divany/">
  → региональная страница каноническая сама для себя и остаётся в индексе

Логика простая: если казанская страница объявляет каноническим московский адрес, она сама себя вычёркивает из выдачи — поисковик решает, что «настоящая» версия на основном домене, и казанский трафик не получает никто. Поэтому в мультирегиональном проекте canonical всегда «замкнут» внутри своего поддомена или региональной папки. Общие принципы работы с caнonical и дублями мы разбираем в статье про ЧПУ и канонические адреса — в регионах к ним добавляется единственное, но жёсткое правило: canonical не должен «утекать» на другой хост.

hreflang: когда он действительно нужен

Вокруг hreflang в контексте регионов много путаницы, поэтому расставим точки. Атрибут hreflang предназначен для языковых и страновых версий сайта. Он сообщает поисковику: «эта версия — для русскоязычных пользователей из России (ru-RU), а вот эта — для русскоязычных из Казахстана (ru-KZ), а эта — на английском (en-US)». Для городов одной страны на одном языке hreflang не нужен и эффекта не даёт.

Когда hreflang уместен:

• Разные страны. У магазина есть версии для России, Казахстана, Беларуси — тогда hreflang помогает показать нужную страновую версию.
• Разные языки. Русская и английская (или казахская) версии — hreflang разводит их по языку.
• Комбинация страна+язык. ru-RU, ru-BY, kk-KZ — точная адресация локали.

Когда hreflang НЕ нужен: Москва, Казань, Екатеринбург — это города одной страны на одном языке. Их региональность решается привязкой в вебмастере, уникализацией и правильными canonical, а не hreflang. Попытка прописать hreflang между городами одной страны в лучшем случае бесполезна, в худшем — путает поисковик. Разграничение простое: hreflang — про локаль (страна+язык), региональность — про город. Разберитесь, что именно у вас: если это Россия и русский язык на всех «регионах», hreflang вам не понадобится.

Sitemap и robots.txt для поддоменов

Каждый поддомен технически — отдельный сайт, и поисковики читают его robots.txt и sitemap.xml по своему адресу: kazan.shop.ru/robots.txt, а не общий файл основного домена. Отсюда жёсткое требование: у каждого поддомена должны быть свои корректные robots и sitemap.

Что важно на каждом поддомене:

• robots.txt с правильным Host. Директива Host (для Яндекса) и Sitemap должны указывать именно на этот поддомен, а не на основной домен.
• Свой sitemap.xml. В карте — только URL этого поддомена, без ссылок на другие города.
• Единые правила закрытия. Технические разделы, корзина, фильтры-мусор закрываются на каждом поддомене одинаково.

Пример правильного robots.txt для поддомена (упрощённо):

# kazan.shop.ru/robots.txt
User-agent: *
Disallow: /bitrix/
Disallow: /personal/
Disallow: /*?set_filter=
Host: https://kazan.shop.ru
Sitemap: https://kazan.shop.ru/sitemap.xml

Типичная ошибка — отдавать один и тот же robots.txt основного домена на все поддомены. Тогда на казанском поддомене в Host и Sitemap стоит московский адрес, и поисковик получает противоречивые сигналы. В Битриксе это решается либо многосайтовостью (у каждого сайта свой robots), либо динамической генерацией robots.txt и sitemap с подстановкой актуального хоста. Общие принципы настройки этих файлов — в отдельной статье про robots.txt и sitemap.xml для 1С-Битрикс; для мультирегиональности к ним добавляется правило «на каждый хост — свой файл».

Автогенерация региональных страниц

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

Что нужно для автогенерации:

1. Справочник регионов. Единый список городов с формами склонения, кодом, привязкой к типу цен и складам.
2. Шаблоны метатегов с переменными города. Один шаблон title/description/H1 на категорию, город подставляется автоматически.
3. Механизм подмены. Компоненты и шаблон читают текущий регион и подставляют цены, склад, контакты.
4. Генерация robots и sitemap. Для каждого поддомена — свои файлы, формируемые по хосту.
5. Правила уникализации текстов. Хотя бы шаблонные вводные тексты категорий с городом, а для приоритетных страниц — ручная доработка.

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

Штатные и модульные решения

Реализовать мультирегиональность на 1С-Битрикс можно тремя путями, и у каждого своя цена и гибкость.

Готовые решения с региональностью «из коробки» и специализированные модули регионов закрывают типовые сценарии: определение города, подмена цен и контактов, региональные метатеги, работа с поддоменами. Они экономят время, но привязывают проект к логике конкретного вендора и не всегда покрывают нестандартные требования. Штатная многосайтовость даёт полный контроль, но требует аккуратной ручной настройки каждого поддомена. Кастом уместен там, где бизнес-логика регионов сложная (например, разные юрлица, нестандартные зоны цен, интеграция с несколькими 1С).

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

Нагрузка и кэш при множестве регионов

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

Правильные приёмы работы с кэшем в мультирегиональности:

• Регион в ключе кэша. В ключ кэша компонентов и составного кэша добавляется код региона — тогда каждая региональная версия кэшируется отдельно.
• Разделение тяжёлого и лёгкого. Каталог и меню кэшируются по региону, а быстрая подмена телефона и города в шапке делается отдельным лёгким механизмом.
• Умеренное число регионов. Каждый регион множит объём кэша; десятки городов — это десятки копий кэша, что нужно учитывать по дисковому пространству и памяти.
• Прогрев кэша по регионам. Для крупных проектов кэш популярных страниц прогревают заранее по каждому региону, чтобы первый посетитель не собирал страницу «вживую».

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

Риски: клоакинг и переспам городами

У мультирегиональности есть свои «грабли», за которые поисковики наказывают. Два главных риска — клоакинг и переспам топонимами.

Клоакинг — это показ поисковому роботу и пользователю разного контента. В региональном контексте в него легко скатиться случайно: например, если по IP робота (московского) сайт всегда отдаёт московскую версию, а пользователю — другую, либо если определение региона работает так, что бот видит один контент, а человек — другой. Чтобы не попасть под подозрение в клоакинге, регион должен определяться прозрачно и одинаково для всех, а региональные версии — быть доступны по своим постоянным адресам (поддоменам/папкам), а не подменяться «на лету» для одного и того же URL по-разному для бота и человека.

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

Ещё несколько рисков, о которых стоит помнить:

• Пустые поддомены-клоны. Десятки поддоменов без уникализации — прямой путь под фильтр за дубли.
• Ложная региональность. Московский телефон и склад на всех «региональных» поддоменах — поисковик и пользователь это раскусывают.
• Битые canonical. Утечка canonical на основной домен обнуляет региональные страницы в индексе.
• Технический разнобой. Разные robots/sitemap, неверный Host, отсутствие SSL на части поддоменов.

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

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

1. Выберите модель. Поддомены, папки или один домен — исходя из числа регионов, различий в ценах и ресурсов на поддержку.
2. Заведите справочник регионов. Список городов с формами склонения, кодами, привязкой к типам цен и складам.
3. Настройте определение региона. GeoIP по IP, ручной выбор в шапке с приоритетом, привязка региона к хосту поддомена.
4. Поднимите инфраструктуру. Для поддоменов — DNS (wildcard), wildcard-SSL, многосайтовость или разбор хоста.
5. Свяжите цены и склады. Типы цен по регионам, склады по городам, расчёт наличия по региону.
6. Подмените контакты и доставку. Телефон, адреса, ПВЗ, условия и сроки доставки по каждому городу.
7. Уникализируйте метатеги. Шаблоны title/description/H1 с переменными города, региональные SEO-тексты для топовых категорий.
8. Настройте canonical. На каждом поддомене canonical замкнут внутри своего хоста, без утечки на основной домен.
9. Сделайте robots и sitemap на каждый хост. Свои Host и Sitemap, карта только по своему поддомену.
10. Настройте кэш по региону. Код региона в ключах кэша всех региональнозависимых блоков.
11. Привяжите регионы в вебмастере. Каждый поддомен — отдельный сайт со своим регионом в Яндекс.Вебмастере.
12. Проверьте сквозной сценарий. Определение города → цены → склад → контакты → корзина → заказ → письма — везде согласованный регион.

Частые ошибки

Эти промахи встречаются в мультирегиональных проектах чаще всего и дорого обходятся в трафике и продажах:

• Поддомены-клоны без уникализации. Десятки копий одной страницы — дубли и фильтры вместо трафика.
• Canonical утекает на основной домен. Региональные страницы сами себя вычёркивают из индекса.
• Один robots.txt на все поддомены. Неверные Host и Sitemap, плохая индексация регионов.
• Кэш без учёта региона. Покупатель видит цены и склад чужого города.
• Молчаливая подмена региона по IP. Без возможности исправить — чужой город отпугивает покупателя.
• Переспам городами в текстах. Перечисление всех городов на каждой странице — переоптимизация и пессимизация.
• hreflang между городами одной страны. Инструмент для стран/языков применён не по назначению.
• Ложная региональность. Московские телефон и склад на всех «региональных» поддоменах.
• Цена согласована только в карточке. Корзина, заказ и письма берут «базовый» тип — покупатель видит разные суммы.
• Регион «прибили» в последний момент. Архитектурное решение отложили, и оно ломает существующие URL и кэш.

Чек-лист запуска

Сведём всё в практический список для приёмки перед выкладкой региональной сети:

1. Модель выбрана и обоснована. Поддомены/папки/один домен — под задачи и ресурсы.
2. Регион определяется корректно. IP + ручной выбор с приоритетом + хост поддомена, с возможностью сменить город.
3. Цены по регионам согласованы. Верный тип цен на всём пути: витрина → корзина → заказ → письма.
4. Склад и наличие по региону. Остаток считается по складам города, резерв на нужном складе.
5. Контакты подменяются. Телефон, адреса, ПВЗ, доставка — по каждому городу и совпадают с реальностью.
6. Метатеги уникальны. title/description/H1 с городом, региональные тексты для топовых категорий.
7. Canonical замкнут в поддомене. На каждом хосте canonical ссылается на этот же хост.
8. Robots и sitemap на каждый хост. Свои Host и Sitemap, карта в пределах поддомена.
9. Кэш учитывает регион. Код региона в ключах, никакой утечки чужих цен.
10. Регионы привязаны в вебмастере. Каждый поддомен добавлен и получил свой регион.
11. hreflang — только для стран/языков. Между городами одной страны его нет.
12. Сквозной сценарий проверен. Реальная покупка из нескольких городов — цены, склад, контакты согласованы.

Вывод

Мультирегиональность на 1С-Битрикс — это не «поднять пару поддоменов», а связная система из коммерческой и поисковой частей. С коммерческой стороны магазин учится определять регион покупателя и показывать ему свои цены, склад, контакты и доставку. С поисковой — создаёт для каждого города отдельные региональные страницы, уникализирует их метатеги и тексты, аккуратно закрывает дубли через canonical и привязку в вебмастере, а на каждом поддомене раздаёт свои robots и sitemap. Сделать красивую подмену цен несложно; по-настоящему важно сделать региональную сеть уникальной и технически чистой, чтобы поисковик воспринимал её как локальные версии, а не как клонов.

Соберите связку целиком: продуманную модель структуры, корректное определение региона с приоритетом ручного выбора, согласованные по всему пути цены и склад, уникальные метатеги и тексты по городам, canonical, замкнутый внутри поддомена, свои robots и sitemap на каждый хост, кэш с учётом региона и привязку в вебмастере. И держитесь в стороне от клоакинга и переспама городами. Настроенная так, мультирегиональность превращает один магазин в десятки региональных витрин, которые продают и ранжируются в своих городах — ровно то, ради чего бизнес выходит за пределы одного региона.