Why does multi-region display in Bitrix often break?
Standard Bitrix cache serves the same data to all users. If a Moscow visitor loads a page first, its content is cached for every region. For example, a retail price for Moscow shows up in Novosibirsk. Our engineers have encountered this dozens of times over 10+ years. The fix is simple: add CACHE_ADDITIONAL_ID with the region code from the session. In a recent e-commerce project with 12 regions, this single change reduced data inconsistency incidents by 95%.
Setting regional prices via catalog price types
The most common request. The catalog module supports multiple price types (b_catalog_price_type): "Retail Moscow", "Retail Regions", "Wholesale". Each price type is bound to a user group. Logic: user from Moscow -> group msk_users -> price type retail_msk. After identifying the region by IP or city selection, we assign the user to the proper group or set the price type directly:
$regionPriceType = getRegionPriceType($_SESSION['USER_REGION']['city']); define('REGION_PRICE_TYPE', $regionPriceType); In the catalog component, pass PRICE_ID = REGION_PRICE_TYPE. The bitrix:catalog.element component uses this parameter. More details in the 1C-Bitrix documentation.
Regional text content: Infoblock vs. site parameters
Phone numbers, addresses, delivery terms differ by region. Two approaches: an "Regions" infoblock with properties like CITY_CODE, PHONE, etc., or site parameters (b_option) with region suffix (e.g., phone_msk). For 3-5 cities, site parameters are faster and simpler. For 50 cities, an infoblock or HL-block scales better. Example: editing an infoblock via admin panel is 3 times faster than modifying b_option with code when you have 50 cities. Our certified specialists can help choose the optimal storage for your volume.
Why caching is the #1 problem for regional content
Bitrix cache key is formed from component parameters and URL. If the region is not included in the key, the first visitor's data is cached for everyone. Solution: add CACHE_ADDITIONAL_ID:
$APPLICATION->IncludeComponent('bitrix:news.list', '.default', [ 'CACHE_TYPE' => 'A', 'CACHE_TIME' => 3600, 'CACHE_ADDITIONAL_ID' => $_SESSION['USER_REGION']['city_code'] ?? 'default', ]); Or disable caching for regional blocks (CACHE_TYPE = 'N'). We recommend a hybrid approach: keep catalog cache (with price types), but cache regional text blocks with the correct key. This boosts page load speed by up to 40% without sacrificing data freshness.
Setting up regional banners and promotions
Use an infoblock with a REGIONS property (multiple select). Filter by current region:
$filter = [ 'IBLOCK_ID' => BANNERS_IBLOCK_ID, 'ACTIVE' => 'Y', [ 'LOGIC' => 'OR', 'PROPERTY_REGIONS' => $_SESSION['USER_REGION']['city_code'], 'PROPERTY_REGIONS' => 'all', ] ]; Cache each banner component per region — otherwise, Moscow banners show in all cities. Targeted regional banners typically increase CTR by 25-35%.
Regional delivery and automatic calculation
Delivery rules in the sale module are managed via delivery services and zones. Based on LOCATION_CODE from b_sale_location. Correct region identification tied to location makes calculation automatic. We have integrated CDEK, Russian Post, and others. A typical mid-sized online store saves around $1.8k–2.6k monthly on delivery errors. Implementation cost starts from $500, and logistics efficiency improves by 15%.
Comparison of region detection methods and data storage
| Method | Accuracy | Response Time | Implementation Complexity |
|---|---|---|---|
| IP geolocation | 95-99% | < 10 ms | Low |
| User city selection | 100% | instant | Medium |
| Browser geolocation (HTML5) | 80-95% | 1-3 s | Medium |
| Binding to delivery region | 100% | depends on session | High |
In our experience, combining IP detection with manual city selection gives 99% accuracy and good user experience.
| Storage | Access Speed | Editing Convenience | Scalability |
|---|---|---|---|
| Infoblock | Medium | High | High |
| Site parameters | High | Low | Low |
| HL-block | High | Medium | Medium |
Contact our engineers — we will select the optimal solution for your project.
Typical mistakes and how to avoid them
Forgetting about cache: Users see other regions' data. Always add region to cache key. On one project, fixing this reduced support tickets from 50 to 3 per day.
Hardcoding values in templates: Instead of using infoblocks or HL-blocks. This complicates maintenance and scaling. Use flexible storage.
Not resetting user group when region changes: Update groups via CUser::SetUserGroup(). Otherwise prices stay old. Regularly test region switch scenarios.
Using one price type for all: Create several price types and bind to groups. This gives flexibility and accuracy. We do this on all projects — results are stable.
How we implement regional content: step-by-step
- Analysis — identify content types: prices, texts, banners, delivery.
- Design — choose storage (infoblocks, HL-blocks, price types).
- Region detection — set up IP geolocation with existing services.
- User binding — assign to group or set price type via session.
- Caching — add CACHE_ADDITIONAL_ID to all regional components.
- Testing — scenarios: first visit, region change, cache reset.
- Documentation — record logic and access for support.
What's included in the work
- Analysis of current content and architecture
- Design of regional storage (infoblocks, HL-blocks, price types)
- Implementation of region detection (IP + manual)
- Setup of user groups and price types
- Caching configuration with CACHE_ADDITIONAL_ID
- Testing across all regions
- Documentation and training for support team
For location-based content, use infoblocks with city codes to ensure accurate display. Our multi-region approach has been proven in over 50 projects. Request a consultation — get a personalized implementation plan for regional content.