Setting up Multi-regional Site in 1C-Bitrix
Multi-regional setup is when Moscow sees one price and content, Yekaterinburg sees another, and search engines index both variants separately. In Bitrix this is achieved through several approaches with different tradeoffs in implementation complexity and SEO results.
Three architectural approaches
Subdomains: msk.example.com, ekb.example.com. Each subdomain is a separate site in multi-site installation (b_lang). Clean solution from SEO perspective — different URLs for different regions. More complex to maintain: content needs to be synchronized between sites or shared infoblocks used with filtering by site attachment.
Directories: example.com/msk/, example.com/ekb/. Technically simpler: one site, different sections. SEO worse than subdomains, but acceptable with proper geotargeting setup in search console.
GET parameter or cookie: example.com/?region=msk. Bad choice for SEO — one URL, different content, search engine can't distinguish.
For serious projects — subdomains. For small ones — directories.
Implementation through subdomains in multi-site
Create several sites in Bitrix (b_lang): msk with SERVER_NAME = msk.example.com, ekb with SERVER_NAME = ekb.example.com. Each site has its own language code and settings.
Infoblocks in Bitrix are tied to sites through b_iblock_site table. Infoblock can be shared for all sites or separate for each. For product catalog, usually one shared infoblock, regional prices managed through price lists (b_catalog_price with user group attachment).
Regional prices: create price types in catalog (/bitrix/admin/cat_price_type.php) — "Moscow", "Regions". User when moving to regional site automatically falls into group with needed price type. Group assignment logic — in OnAfterUserAuthorize and when region changes.
Determining user region
Automatic determination through IP + manual through "city selection popup". sale module contains class \Bitrix\Sale\Location\LocationTable and b_sale_location table with city/region hierarchy. But for IP geolocation Bitrix doesn't provide built-in solution — use third-party services (MaxMind GeoIP, Sypex Geo, DaData).
Typical scheme: on first visit determine region by IP through external API or local GeoIP database, show popup "Your city — Yekaterinburg? Yes / Choose another", save choice to session and cookie with long TTL.
$regionId = $_COOKIE['user_region'] ?? detectRegionByIp($_SERVER['REMOTE_ADDR']);
$_SESSION['REGION_ID'] = $regionId;
// Redirect to needed subdomain if not matching
SEO settings for multi-regional site
In Yandex.Webmaster for each subdomain set up geotargeting: Moscow → msk.example.com, Yekaterinburg → ekb.example.com. This allows search engine to rank regional versions by corresponding regions.
Tag hreflang for regional variants in Russian not needed (it's for languages, not regions). But canonical — needed: if one URL accessible from both subdomains, point canonical to primary.
In Bitrix canonical is set in template through $APPLICATION->SetPageProperty('canonical', 'https://msk.example.com' . $APPLICATION->GetCurPage()).
Regional phones and addresses
Content specific to region — phones, office addresses, delivery conditions. Either site settings in b_option with region suffix, or separate "Offices" infoblock with region attachment through property. Component on contacts page filters offices by current site/region.