Региональное SEO для B2B-каталога: поддомены, папки или отдельные сайты

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

В российской B2B-выдаче заявки чаще приходят из Яндекса, поэтому отдельная геопривязка обычно важнее привычной для Google нарезки папками. На живых каталогах это чаще всего означает поддомены, если у города своя оферта, и папки, если различий мало, а домен уже с историей. Отдельный сайт на каждый город почти никогда не нужен одному бизнесу с одним каталогом.

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

Зачем региональное SEO владельцу B2B

Обычный сайт отвечает, продаёте ли вы то, что ищут. Региональный добавляет второе условие: продаёте ли вы это здесь, в понятный срок и на понятных условиях. Для запросов вроде «кран-балка купить», «таль электрическая» или «поставка строп» Яндекс собирает выдачу в Екатеринбурге и в Москве по-разному. Он смотрит не только текст, но и связь ресурса с городом: адрес, телефон, карточку в Яндекс Бизнесе, поведение людей из региона и то, есть ли у страницы местный смысл.

Формулировка «продаём по всей России» эту логику не отменяет. Компания из одного города может закрывать поставки в десятки регионов и при этом проигрывать в локальной выдаче тем, у кого есть склад, самовывоз, свой срок или хотя бы честная посадочная с условиями именно для этого города. Архитектура сайта нужна не ради пачки новых URL, а чтобы эти различия было чем показать и поисковику, и закупщику.

Регион при этом не запирает сайт в одной точке на карте. У Яндекса принадлежность к городу помогает в локальной выдаче, но не запрещает показываться там, где страница всё равно релевантна. Имеет смысл не размножать витрину ради галочки, а дать понятный сигнал: какая версия для кого.

Три схемы — и почему это решение не только про SEO

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

Вывеска «Яндекс любит поддомены» ещё не проект. Та же схема на 1С-Битрикс, Laravel и Next.js сажается по-разному. Разработка потом определяет, сможете ли вы менять цену и срок по городу без ручного копирования всего каталога. Поэтому каждый вариант стоит смотреть сразу с двух сторон: как его видит поиск и во что он выльется в сопровождении.

Региональные поддомены: spb.site.ru, kazan.site.ru

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

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

В Яндексе у такой схемы есть понятная выгода. Поддомен воспринимается как отдельный сайт, регион настраивается точечно, проще привязать карточку филиала в Яндекс Бизнесе и не смешивать адреса разных городов на одном URL. Если одна площадка просядет по качеству, остальная сетка чаще остаётся рабочей.

Платить за это приходится сопровождением. Каждый поддомен растёт почти сам: ссылки и поведение не складываются так свободно, как внутри одного адреса. Google слабее реагирует на такую нарезку, если тексты почти одинаковые. Сертификаты, карты сайта, метрики и шаблоны множатся, и ошибка в одном месте разъезжается по всей сетке. Яндекс предупреждает прямо: если содержимое поддомена почти совпадает с основным сайтом, один из адресов могут признать неглавным — тогда региональная версия выпадет из поиска.

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

Типичные поломки растут из той же экономии. Федеральный сайт копируют, меняют «Москва» на «Самара» и считают регион готовым. Поддомен забывают добавить в Вебмастер или закрывают от индексации. Людям показывают одну версию по городу, роботу — другую, и часть страниц не попадает в индекс. В кабинете выбран город, а локальных контактов и карточки в Яндекс Бизнесе нет. Либо федеральный домен и городской поддомен бьются за одни и те же запросы, потому что так и не решили, кто из них главный.

Папки: site.ru/spb/, site.ru/kazan/

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

Google к такой схеме обычно спокойнее: вес ссылок остаётся на одном адресе, история домена работает на всю структуру, сопровождение дешевле. Если команда небольшая, а городов три-восемь, это часто самый здравый старт — при условии, что правила URL зафиксированы и версии не плодятся через параметры, cookie и дубли вроде /spb/ и /sankt-peterburg/.

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

Ошибки здесь те же по природе, что и на поддоменах, только живут внутри одного хоста. Во всех папках один текст, отличается только город в шаблоне. Регион выбирается cookie, и робот видит случайную версию. Папки формально есть, но сайт их не признаёт: нет списка городов и переходов с федеральной витрины. Либо страницам /msk/ и /spb/ вешают языковые пометки как разным странам. Для городов внутри России на одном языке это не тот инструмент.

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

Отдельные сайты: site-spb.ru, site-kazan.ru

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

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

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

Что видно, если поставить схемы рядом

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

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

Критерий	Поддомены	Папки	Отдельные сайты
Сложность внедрения	Средняя / высокая: DNS, сертификаты, Вебмастер на каждый хост	Ниже: ветки в CMS и правила адресов	Высокая: отдельные площадки и контент
Сила в Яндексе	Высокая, если есть локальный смысл и свои контакты	Средняя: зависит от филиалов и качества страниц	Высокая точечно, но дорого и с риском склейки
Сила в Google	Средняя, вес дробится	Обычно выше за счёт единого домена	Слабая на старте
Управление для команды	Одна система возможна, но контуров больше	Самое удобное при общей витрине	Самое тяжёлое без сильной команды
Как сажается в разработке	Несколько сайтов/хостов, общая база, региональные правила	Одно приложение, регион как ветка адреса и данных	Несколько проектов или полная изоляция контуров
Риск дублей	Высокий при шаблонной подмене города	Высокий на больших каталогах	Высокий, плюс склейка между доменами
Стоимость поддержки	Растёт с числом городов	Ниже при аккуратной CMS	Самая высокая

Как это сажается в CMS: Битрикс, Laravel, Next.js

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

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

На Next.js и похожем стеке критично заранее договориться, какие страницы существуют как отдельные адреса. Иначе команда уезжает в подмену контента на одном URL: человеку из Краснодара показывается одно, роботу — другое. Для поиска это плохая схема. Регион должен быть в адресе, а не только в cookie.

Стек не выбирает схему за вас. Битрикс ускоряет сетку сайтов, Laravel удобнее для сложных правил, Next.js требует самой жёсткой карты URL ещё на проектировании. В этой логике собирался и ROPESYSTEMS.

Как это устроено на ROPESYSTEMS

ROPESYSTEMS — интернет-магазин грузоподъёмного оборудования с каталогом на 10 000+ позиций, SEO и интеграцией с Битрикс24. Регионы вынесены на поддомены, потому что городам нужна была не страница «мы тоже работаем в вашем городе», а своя витрина.

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

Чтобы витрины не разъехались вручную, в админке доработали генерацию мета-тегов по городу. Шаблон сам собирает title и description для конкретного поддомена, а не редактор проходит тысячи карточек. Описания разделов каталога тоже живут в шаблонах: отдельно заложены тексты под Краснодар и Екатеринбург. У товаров при этом разные цены и даты доставки. Поисковик и покупатель видят не склонение города, а разные условия сделки.

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

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

Как Яндекс и Google читают регион

Даже удачный выбор URL не сработает, если поисковик не понимает, к какому городу относится страница.

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

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

Google устроен иначе. Кнопки «привязать сайт к Новосибирску» у него нет: он смотрит на URL, текст, профили организации и ссылки. Языковые пометки нужны, когда версии отличаются языком или страной. Для site.ru/spb/ и site.ru/kazan/ на одном русском языке они почти ничего не решают. Если страницы-близнецы, Google чаще склеит их сам. Для рынка РФ важнее отдельные адреса без подмены по IP, честные контакты и разный коммерческий смысл. Другая страна — уже не ещё один город.

Когда регионы превращаются в дубли

Поисковые сигналы бессильны, если сорок городов отличаются только словом в заголовке. Тогда система видит один документ во множестве зеркал.

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

На каталоге из тысяч позиций нельзя умножить карточку на число городов. Рабочая модель одна: общий товарный контур, региональные посадочные и категории, наличие и срок как свойства предложения, цена — только если она правда разная. В индекс стоит отдавать не каждую комбинацию «город + артикул», а то, что ищут: городские категории, популярные линейки, поставку и сервис в регионе.

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

Что проверить до запуска

• Зафиксировать не «все миллионники», а города ближайшего года и отличие каждого: склад, срок, самовывоз, цена, сервис.
• Выбрать одну схему адресов и убрать пересечения с www, http и параметрами в ссылке.
• Открыть роботам все региональные адреса без подмены по IP.
• Сделать у каждой версии свой заголовок и первый экран, не только автозамену города.
• Сверить контакты на сайте с Яндекс Бизнесом.
• Если это поддомены — добавить каждый в Вебмастер, указать регион и отдать свою карту сайта.
• Прописать, какая страница отвечает за федеральный запрос, какая за городской.
• Не умножать каталог слепо: наличие, цена и срок должны браться из правил системы.
• Оставить переход между федеральной витриной и городом и список регионов, который видит поисковик.
• Настроить заявки в аналитике по городам.
• Заложить регламент на новый город: контент, контакты, карточка организации и проверка дублей до индексации.

Что из этого следует

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

Для среднего B2B на российском рынке в 2026 году обычно живы две модели. Либо аккуратные папки на домене, который уже имеет вес. Либо поддомены для городов с реальной локальной экономикой — как на ROPESYSTEMS, где общий каталог не клонировали, а развели витрины по цене, сроку и шаблонам. Отдельные домены остаются исключением.

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