Розробка сайту нерухомості на 1С-Бітрікс під ключ

Відвідувач сайту нерухомості застосовує 4–6 фільтрів, перемикається між списком і картою, зберігає об'єкти в обране. Якщо пошук гальмує, він іде на агрегатори. Наша розробка сайту нерухомості на 1С-Бітрікс з окремими інфоблоками та просторовим індексом вирішує це завдання в 3 рази швидше типових рішень. Це дає реальну економію — портал окупається за 6–8 місяців за рахунок конверсії (при середньому чеку).

Архітектура інфоблоків: як зберігати об'єкти нерухомості

При розробці сайту нерухомості на 1С-Бітрікс перше питання — один інфоблок на всі типи чи окремий під квартири, будинки, комерцію. Відповідь залежить від кількості унікальних властивостей.

Один інфоблок + розділи за типами працює, якщо властивості перетинаються на 70%+. Площа, ціна, адреса, координати, фотографії — спільні. Кількість кімнат — тільки для квартир, площа ділянки — тільки для будинків. Порожні властивості не займають місце в b_iblock_element_property (рядок не створюється, якщо значення null). Плюс: єдиний bitrix:catalog.smart_filter за всіма типами, єдина видача в пошуку, один шаблон списку.

Окремі інфоблоки виправдані, коли у комерційної нерухомості 15 властивостей, яких немає у житлової (клас приміщення, тип оренди, висота стель, вантажний ліфт, потужність електрики). Змішувати їх в одному інфоблоці — засмічувати фільтр. Мінус: агрегований пошук за всіма типами потребуватиме кастомний компонент з UNION-логікою або Elasticsearch.

Рекомендована структура для порталу на 10К+ об'єктів:

• Інфоблок «Житлова нерухомість» — розділи: Квартири, Будинки, Таунхауси
• Інфоблок «Комерційна нерухомість» — розділи: Офіси, Торгові, Склади
• Highload-блок «Житлові комплекси» — довідник ЖК з прив'язкою об'єктів через PROPERTY_COMPLEX_ID
• Highload-блок «Райони» — довідник з полігонами для пошуку по карті
• Highload-блок «Забудовники» — компанії з реквізитами та логотипами

Властивості об'єкта нерухомості — мінімум 30 полів. Критично важливі для фільтрації:

| Властивість | Тип | Індексація | | PRICE | N (число) | Фасетний індекс | | AREA | N | Фасетний індекс | | ROOMS | L (список) | Фасетний індекс | | FLOOR | N | Фасетний індекс | | FLOORS_TOTAL | N | Звичайний | | DISTRICT | S:Highload | Фасетний індекс | | COMPLEX_ID | S:Highload | Фасетний індекс | | COORDINATES | S (рядок, "lat,lng") | Ні | | DEAL_TYPE | L (продаж/оренда) | Фасетний індекс |

Координати зберігаються як рядок "55.7558,37.6173" — парсяться на фронті для відображення на карті. Зберігати в двох окремих властивостях (LATITUDE, LONGITUDE) не варто — немає сценарію, де потрібна фільтрація за однією координатою.

Як організувати фільтрацію на карті?

Розробка сайту нерухомості на 1С-Бітрікс потребує продуманої фільтрації на карті. Штатний bitrix:catalog.smart_filter покриває 60% завдань — чекбокси, списки, діапазони. Але для нерухомості потрібні речі, які він не вміє з коробки.

Повзунки діапазонів (range sliders) для ціни та площі. Smart filter віддає MIN_VALUE та MAX_VALUE для числових властивостей через масив $arResult['ITEMS']. На фронті будуємо два input + slider на базі noUiSlider або rc-slider. Значення передаються через GET-параметри ?arrFilter_P1_MIN=3000000&arrFilter_P1_MAX=8000000. Проблема: при кожній зміні повзунка — перезавантаження сторінки. Рішення — AJAX-підвантаження результатів через bitrix:catalog.section з параметром AJAX_MODE=Y та кастомним JavaScript, який перехоплює submit форми фільтру.

Фільтрація по карті — малювання області пошуку. Користувач малює полігон або коло на карті, система повертає об'єкти всередині області. Штатний smart filter цього не вміє. Реалізація:

1. На фронті — Yandex.Maps API, ymaps.GeoObject з editable: true або ymaps.Polygon через інструмент малювання. Користувач малює область, JavaScript збирає масив координат вершин полігону.
2. AJAX-запит на бекенд з координатами полігону. На стороні PHP — алгоритм Ray Casting (point-in-polygon): для кожного об'єкта перевіряємо, чи потрапляють його координати всередину полігону. При 50К об'єктів повний перебір — 20-40ms, прийнятно. При 200К+ — потрібний просторовий індекс.
3. Просторовий індекс на MySQL/MariaDB: колонка POINT типу GEOMETRY, індекс SPATIAL, запит через ST_Contains(polygon, point). Але Бітрікс не зберігає властивості інфоблоків як GEOMETRY. Рішення — додаткова таблиця project_realty_geo з полями ELEMENT_ID, LOCATION POINT, SPATIAL INDEX. Синхронізація через обробник події OnAfterIBlockElementUpdate.

// Обробник синхронізації координат
EventManager::getInstance()->addEventHandler(
    'iblock', 'OnAfterIBlockElementUpdate',
    function ($arFields) {
        if ($arFields['IBLOCK_ID'] !== REALTY_IBLOCK_ID) return;
        GeoIndexService::updatePoint(
            $arFields['ID'],
            $arFields['PROPERTY_VALUES']['COORDINATES']
        );
    }
);

4. Результат AJAX-запиту — масив ELEMENT_ID, який передається в основний CIBlockElement::GetList через фільтр ['ID' => $geoFilteredIds]. Таким чином, просторова фільтрація комбінується з smart filter.

Кластеризація маркерів. При 5К+ маркерів на карті Yandex.Maps починає гальмувати. ymaps.Clusterer групує близькі маркери автоматично. Але при зумі на район з 200 об'єктами в одному будинку (ЖК) кластер розгортається в кашу. Рішення — кастомний ClusterPlacemark з підказкою «14 квартир у ЖК Сонячний» та посиланням на відфільтрований список.

AJAX-оновлення і карти, і списку синхронно. Користувач рухає повзунок ціни → оновлюється список → оновлюються маркери на карті. Користувач рухає карту → оновлюється список об'єктів у видимій області. Це потребує єдиного контролера стану на фронті. Архітектура: React/Vue-компонент (або vanilla JS з pub/sub), який тримає поточні фільтри + видиму область карти (bounding box) і при зміні будь-якого параметра робить один AJAX-запит. Відповідь містить і HTML списку, і JSON координат для маркерів.

// Псевдокод синхронізації карти та списку
function updateResults() {
    const filters = collectFilters(); // smart filter values
    const bounds = map.getBounds();   // [[lat1,lng1],[lat2,lng2]]
    filters.geo_bounds = bounds;

    fetch('/api/realty/search/', {
        method: 'POST',
        body: JSON.stringify(filters)
    })
    .then(r => r.json())
    .then(data => {
        renderList(data.html);
        renderMarkers(data.markers); // [{id, lat, lng, price, title}]
    });
}

map.events.add('boundschange', debounce(updateResults, 300));
filterForm.addEventListener('change', updateResults);

Чому важлива просторова індексація?

Без просторового індексу пошук по полігону на 50К об'єктів методом Ray Casting дає 20-40ms, що прийнятно. Але на 500К об'єктів час зростає до 400ms — користувач помітить затримку. SPATIAL індекс на колонці POINT скорочує запит до 5-10ms. Тому для великих порталів ми обов'язково створюємо окрему гео-таблицю, синхронізовану через подію OnAfterIBlockElementUpdate.

Згідно з документацією, фасетні індекси обов'язкові для каталогів з великою кількістю елементів — їх використання знижує час фільтрації до 50 разів.Документація 1С-Бітрікс

Картка об'єкта

Картка квартири — це 30+ полів, фотогалерея, відеотур, 3D-панорама, розташування на карті, інфраструктура поруч, іпотечний калькулятор. Все це — один виклик bitrix:news.detail з кастомним шаблоном.

Фотогалерея — множинна властивість типу «Файл». Вивід через Swiper.js з lazy-завантаженням. Прев'ю — CFile::ResizeImageGet() з параметром BX_RESIZE_IMAGE_PROPORTIONAL, 400x300. Повноекранний перегляд — оригінал до 1920px.

3D-панорама та відеотур. Панорама — iframe з Matterport, Kuula або власний viewer на Pannellum.js. Відеотур — YouTube/Vimeo embed. Обидва зберігаються як рядкові властивості з URL. У шаблоні — умовний рендер: якщо заповнено PROPERTY_PANORAMA_URL — показуємо вкладку «3D-тур».

Іпотечний калькулятор — чистий JavaScript, без звернення до сервера. Формула ануїтетного платежу, три повзунки (вартість, перший внесок, термін), результат — щомісячний платіж. Ставки підтягуються з Highload-блоку «Банки-партнери» при завантаженні сторінки.

Інтеграції із зовнішніми системами

XML-фіди для агрегаторів. ЦІАН, Avito, Yandex.Realty — у кожного свій формат XML. Загальна логіка: агент Бітрікса (CAgent) запускається раз на годину, вибирає активні об'єкти, формує XML, кладе в /upload/feeds/.

• Yandex.Realty — формат realty-feed, кореневий елемент <realty-feed>, всередині <offer> з обов'язковими полями type, category, location, price, area, image
• ЦІАН — формат cian-feed, елемент <object>, своя система категорій (flatSale, flatRent, commercialSale), обов'язкові поля відрізняються від Yandex
• Avito — формат Avito Autoload, елемент <Ad>, категорія Нерухомість, підкатегорія залежить від типу

Кожен фід — окремий клас-генератор, що наслідує абстрактний BaseFeedGenerator. Маппінг властивостей інфоблоку на поля XML — у конфігу, не в коді. Це дозволяє додати новий агрегатор без розробника.

Обсяг фіду: 10К об'єктів → XML ~15MB. Генерація — 30-60 секунд. При 50К+ об'єктів генерація може зайняти 5 хвилин — виносимо у фонове завдання або нарізаємо на частини.

CRM-інтеграція та агенти. Заявка з картки об'єкта → лід в Бітрікс24. REST API: crm.lead.add з полями TITLE, SOURCE_ID, UF_CRM_REALTY_ID (кастомне поле — ID об'єкта). Webhook або OAuth — залежить від того, один портал чи кілька.

Рієлтори — окремий інфоблок або Highload-блок. Кожен об'єкт прив'язаний до агента через PROPERTY_AGENT_ID. На сторінці агента — його об'єкти, контакти, рейтинг. Авторизований агент може редагувати свої об'єкти через bitrix:iblock.element.edit.form з обмеженням по CREATED_BY.

Користувацький функціонал: обране та порівняння

Обране для неавторизованих — cookie або localStorage. Масив ID об'єктів, максимум 50. На сервері — middleware в init.php, який при кожному запиті перевіряє cookie REALTY_FAVORITES та додає в $arResult ознаку IN_FAVORITES. Для авторизованих — Highload-блок UserFavorites з полями USER_ID, ELEMENT_ID, DATE_ADD.

Порівняння — аналогічно, але з виводом таблиці властивостей у два-три стовпці. Компонент читає ID з cookie/Highload, робить GetList по масиву ID, рендерить таблицю з горизонтальним скролом.

SEO для тисяч сторінок

Ручний ввід meta для кожної з 10К квартир — неможливо. Шаблони SEO через налаштування інфоблоку:

• #ELEMENT_NAME# — назва об'єкта
• UF_DISTRICT — район, підставляється через обробник OnBeforeIBlockElementSeo
• Формула: Купити {тип} {кімнати}-кімн. у {район} — {ціна} ₽ | {сайт}

Мікророзмітка Schema.org RealEstateListing — в template.php картки об'єкта:

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "name": "2-кімн. квартира, 65 м², Центральний район",
  "url": "https://site.ru/kvartiry/123/",
  "datePosted": "2025-01-15",
  "offers": {
    "@type": "Offer",
    "price": "8500000",
    "priceCurrency": "RUB"
  }
}

Canonical URL, hreflang для мультимовності, XML sitemap через модуль seo з розбивкою по інфоблоках — до 50К URL на файл.

Продуктивність на 50К+ об'єктів

Фасетні індекси — обов'язково. Без них bitrix:catalog.smart_filter на 50К елементів з 15 фільтрованими властивостями — 3-5 секунд. З фасетним індексом — 50-150ms. Перебудова через Bitrix\Iblock\PropertyIndex\Manager::buildIndex($iblockId), запускається по крону після масового оновлення.

Посторінкова навігація — bitrix:system.pagenavigation з lazy-scroll (підвантаження при прокрутці). LIMIT + OFFSET на великих вибірках деградує — при OFFSET 40000 MySQL все одно сканує 40К рядків. Альтернатива — курсорна пагінація по ID > $lastId, але штатні компоненти її не підтримують. Для перших 200 сторінок OFFSET прийнятний.

| Масштаб | Терміни | | Сайт агентства, до 500 об'єктів | 6-10 тижнів | | Портал міста, 5-10К об'єктів, карта + фільтри | 10-16 тижнів | | Федеральний портал, 50К+ об'єктів, фіди, CRM | 14-24 тижні |

Що входить в розробку порталу нерухомості

• Проектування структури даних (інфоблоки, HL-блоки, просторовий індекс)
• Дизайн адаптивних сторінок (картка, список, карта)
• Розробка фільтрації з картою та режимом малювання області
• Інтеграція з агрегаторами (ЦІАН, Avito, Yandex.Realty) через XML-фіди
• Підключення іпотечного калькулятора
• Налаштування SEO-шаблонів та мікророзмітки
• Інтеграція з CRM (Бітрікс24, amoCRM)
• Навантажувальне тестування та оптимізація
• Навчання адміністраторів
• 3 місяці гарантійної підтримки після запуску

Терміни не включають наповнення контентом та налаштування рекламних кампаній — це паралельні процеси, які стартують на етапі тестування. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо детальне КП протягом дня. Отримайте консультацію та зрозумійте, як ваш майбутній портал буде приносити ліди.

Більше 10 років досвіду в розробці на Бітрікс та 50+ проектів нерухомості дозволяють нам гарантувати результат. Замовте розробку сайту нерухомості під ключ — отримайте портал, який приносить ліди. На одному з нещодавніх проектів економія на серверних ресурсах після впровадження просторового індексу склала понад 150 000 руб. на рік, а витрати на підтримку скоротилися на 20%.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.