Вы наверняка замечали, что на сайтах компаний, которые работают с разными регионами, контент меняется в зависимости от города. Например, находите вы идеальную пиццу «Пепперони» за 350 рублей. Думаете «Ого, как дешево!». А потом замечаете, что сайт неправильно определил ваш город и вместо московской цены показал тульскую. Меняете город с Тулы на Москву, и цена пиццы меняется на 600 рублей. Что уже ближе к реальности :)

Как видите, цена товара зависит от региона. И не только она. На сайтах федеральных компаний часто меняются следующие данные:

• каталог — наличие товаров в конкретном городе и цена;
  
• скидки и акции;
  
• условия доставки;
  
• контакты;
  
• новости;
  
• SEO-тексты, метатеги и другие штуки.
  
  

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

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

Итак, разберем все по порядку.

По IP

Есть публичные базы IP-адресов, куда провайдеры передают информацию об IP и городах, к которым те привязаны. На своих проектах мы используем базу IPGeoBase.

Есть несколько способов подключиться к базе.

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

По браузерной геолокации

С помощью HTML5 и Geolocation API браузер тоже может определять геолокацию пользователя. Эти данные точнее, чем из баз IP-адресов. Например, в барнаульском офисе Сибирикса IP Московский. Но браузер четко видит Барнаул.

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

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

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

Есть несколько способов сделать сайты с разным контентом для разных городов.

1. Независимая копия

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

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

2. Копия на уровне CMS

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

Пример: Славспорт.

3. Кастомные механизмы

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

Пример: На сайте Орматека разные цены хранятся с привязкой к городу. А свойство «Где полежать» хранит товары с привязкой к городам, в которых можно полежать на матрасах.

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

Есть несколько вариантов, как сделать многосайтовость в рамках одной админки.

Вариант 1

Сделать сайты с разными доменами: moscow.site.ru. По домену на город или регион. На одной лицензии Битрикса можно сделать 2 сайта с разными доменами. Если вам нужно больше — можно купить дополнительные лицензии (от 1620 рублей за один сайт).

Плюсы:

• Более простая техническая реализация.
  
• Когда пользователь ищет какой-нибудь конкретный товар на сайте, в результатах поиска будет только этот товар из его города.
  
• В Яндекс.Вебмастере можно будет задать каждому сайту с поддоменом по региону.
  
  

Минусы:

• Покупка дополнительных SSL-сертификатов — либо по одному для каждого домена, либо сертификат Wildcard.
  
• Несколько сайтов с одинаковым контентом (пусть и не полностью) ухудшит ранжирование в поисковиках. Поэтому нужно делать уникальный контент: новости, отзывы, вакансии и т.д.
  
  

Вариант 2

Сделать разные папки в админке. Тогда URL сайта будет выглядеть следующим образом: site.ru/moscow.

Плюсы:

• Не нужно докупать дополнительные лицензии и SSL-сертификаты.
  
• Индексируется поисковиками быстрее, чем сайты на поддоменах.
  
  

Минусы:

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

Какой из вариантов — домены или папки — лучше, вопрос холиварный. У SEO-специалистов нет единого и четкого мнения на этот счет.

Вариант 3

Кастомные решения — тут у всех по-разному. Зависит от задач и подкованности разработчиков.

Рассмотрим распространенные решения, которые чаще всего встречаются на наших проектах. А так как сайты мы делаем на Битриксе, то о нем и пойдет речь.

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

Есть несколько способов выводить информацию по остаткам для разных городов. Мы пользуемся двумя.

1. Штатный инструмент Битрикса «Склады». С его помощью создаем склады для каждого города или филиала. Информация об остатках на них выгружается из ERP или вносится вручную.

Каждый склад привязывается к городу, в котором находится. Для этого разработчики задают соответствие складов и городов. В итоге сайт показывает остатки на складах города, который определяется по IP.

2. Если заказчик не может отгрузить это свойство — наличие — то можно сделать кастомное поле в товаре, где задается наличие. Делается это ручками, поэтому подходит только тем магазинам, где не более 300 товаров. Такой вариант подойдет сайтам, у которых наличие товара не зависит от его количества на складе. Речь об услугах, пример — доставка пиццы. Она не хранится на складе, ее либо могут приготовить, либо нет. Поэтому в поле «наличие» будет либо «1», либо «0» — третьего не дано.

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

1. Цены можно задавать через сущность «Типы цен». Тогда цены можно подтянуть из системы (1С или другой ERP) или задать товару вручную в специальной вкладке.

2. Пару раз нас просили создать кастомные поля для ввода цен. Но мы такой вариант не поддерживаем — он ломает штатные плюшки Битрикса: скидки, интеграцию. Все это потом придется делать кастомно. И, скорее всего, такой вариант выйдет дороже, чем работа с «Типами цен».

Нас просили вывести в товаре матрицу «размер/цвет», на пересечении которой будет задаваться цена. Это удобно для ряда ситуаций с точки зрения ввода данных. Но если клиенту при этом нужны поля для ввода цен в админке, в идеале они должны работать как обертка над родными, системными полями 1С Битрикс.

Если акции и скидки в разных филиалах одной сети различаются, на сайте это тоже можно реализовать.

1. Создать собственный справочник по городам и обрабатывать его в провайдере цен.

2. Написать собственные условия для применения скидок.

3. Установить готовое решение, которое позволит задавать разные скидки городам и регионам. Из таких мы знаем сервис HucksterBot.

Привязать новости (да и другой текстовый контент) к городу можно несколькими способами.

1. Создать отдельные поля ввода для каждого города.

2. Добавить для блока выбор, в каких городах его показывать, а в каких — нет.

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

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

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

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

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

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

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

1. Можно сделать то же, что и с текстами — задавать метатеги и SEO-тексты для разных городов с помощью фигурных скобок. Делать это вручную или добавить кастомные поля ввода в админке.

2. Создать отдельный инфоблок, в котором для каждой ссылки можно прописывать собственное SEO.

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

1. Можно создать отдельный инфоблок «Контакты», и там задать данные по всем городам, в которых есть филиалы компании. В таком случае, когда сайт определит город пользователя, он автоматически покажет актуальные контакты.

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

Яндекс.Маркет — большая тема, которую лучше разбирать отдельно. Если коротко, то для каждого города, который вы хотите представить в Маркете, понадобится отдельный фид — файл с каталогом в формате YML, CSV или XLS.

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