Розробка сайту послуг на 1С-Бітрікс

Розробка сайту послуг на 1С-Бітрікс

Сайт послуг — не інтернет-магазин. Немає кошика, складських залишків, торгових пропозицій. Натомість — картки послуг із десятком нестандартних полів, онлайн-запис, калькулятор вартості, прив'язка спеціалістів до напрямків і CRM, яка має ловити кожну заявку. Бітрікс це вміє, але архітектура інфоблоків, яка ідеально лягає на каталог товарів, для послуг потребує продуманої адаптації.

Структура інфоблоків для каталогу послуг

Послуги — це інфоблок із типом services. Розділи інфоблоку — категорії: «Юридичні послуги», «Бухгалтерський облік», «Аудит». Елементи — конкретні послуги: «Реєстрація ТОВ», «Податковий аудит», «Ліквідація ФОП».

Типові властивості елемента:

Розділи інфоблоку теж отримують користувацькі властивості через UF-поля: UF_SECTION_ICON (SVG-іконка категорії), UF_SECTION_DESCRIPTION (розгорнутий опис для SEO). Стандартне поле DESCRIPTION розділу занадто обмежене — немає HTML, немає візуального редактора у версіях до 23.x.

Глибина вкладеності. Для сайту юридичної компанії достатньо одного рівня: категорія → послуга. Для медичного центру з десятьма напрямками і сотнею процедур потрібна дворівнева структура: напрямок → підкатегорія → послуга. Бітрікс підтримує необмежену вкладеність розділів, але компонент catalog.section.list вимагає ручного налаштування DEPTH_LEVEL і кастомного шаблону для коректного відображення.

Онлайн-запис: від веб-форм до інтеграції з календарем

Це функція, заради якої часто і починають проєкт. Два принципово різних підходи.

Штатний модуль form. Форма створюється в адмінці, поля налаштовуються візуально. Компонент bitrix:form.result.new виводить форму на сторінці. Результати зберігаються в таблицях b_form_*. Переваги: швидке налаштування, експорт у CSV, сповіщення на email. Обмеження: немає прив'язки до конкретної послуги без додаткового прихованого поля, немає вибору дати/часу «з коробки», немає інтеграції з календарем спеціаліста.

Кастомна форма запису через інфоблок + CRM. Створюємо інфоблок «Записи на прийом» із полями: послуга (прив'язка), спеціаліст (прив'язка), дата, час, ім'я клієнта, телефон, статус. Форма на фронті — React-компонент або кастомний шаблон з AJAX-відправкою через bitrix:main.ajax. При збереженні елемента обробник OnAfterIBlockElementAdd створює лід у Бітрікс24 через REST API:

CRest::call('crm.lead.add', [
    'fields' => [
        'TITLE' => 'Запис: ' . $serviceName,
        'NAME' => $clientName,
        'PHONE' => [['VALUE' => $phone, 'VALUE_TYPE' => 'WORK']],
        'SOURCE_ID' => 'WEB',
        'UF_CRM_SERVICE_ID' => $serviceId,
    ]
]);

Для повноцінного календаря запису — інтеграція з модулем calendar Бітрікс24. Через REST API (calendar.event.add) створюємо подію в календарі спеціаліста. На фронті показуємо вільні слоти, запитуючи зайнятість через calendar.event.get з фільтром за датою та співробітником.

Важливий нюанс — часові зони. Якщо компанія працює в декількох регіонах, часові зони спеціалістів можуть відрізнятися. REST API Бітрікс24 повертає час у зоні сервера. На фронті потрібно конвертувати до зони клієнта. Без цього запис на 14:00 у Києві перетвориться на 14:00 у Лондоні — зсув на дві години.

Картка послуги: компонент, зв'язки, мікророзмітка

Картка послуги виводиться компонентом bitrix:news.detail із кастомним шаблоном. Не catalog.element — модуль catalog тут надлишковий, він тягне за собою торгові пропозиції, типи цін, складський облік.

У result_modifier.php картки підвантажуємо пов'язані дані:

• Спеціалісти — CIBlockElement::GetList() за ID із властивості SPECIALISTS. Фото, посада, стаж. Кешується тегованим кешем із тегом iblock_id_XX
• Схожі послуги — з того ж розділу, виключаючи поточну, сортування за SORT. Ліміт 3-4 картки
• Портфоліо — кейси, прив'язані до цієї послуги через властивість-прив'язку в інфоблоці «Портфоліо»

Мікророзмітка Service за schema.org — у шаблоні компонента. Мінімальний набір: name, description, provider (організація), areaServed. Якщо вказано діапазон цін — додаємо offers із priceSpecification. Google Search Console покаже, чи розпізнав робот розмітку, через 2-3 дні після індексації.

Портфоліо та кейси: побудова довіри

Окремий інфоблок portfolio. Елемент — один кейс. Властивості:

• CLIENT — назва клієнта (рядок або прив'язка до інфоблоку «Клієнти»)
• SERVICES — прив'язка до інфоблоків послуг (множинна)
• GALLERY — файл (множинний), фотогалерея проєкту
• RESULT_TEXT — HTML, опис результату
• DURATION_PROJECT — рядок, терміни виконання
• TESTIMONIAL — HTML, відгук клієнта

Компонент bitrix:news.list із кастомним шаблоном — вивід сіткою або каруселлю. Фільтрація за послугою: на сторінці картки послуги підвантажуємо кейси з фільтром PROPERTY_SERVICES = ID поточної послуги. На загальній сторінці портфоліо — фільтр за розділами послуг через AJAX-підвантаження.

Перехресна навігація «послуга ↔ кейс» — найцінніший шлях користувача на сайті. Потенційний клієнт читає про послугу, прокручує до релевантних кейсів, бачить результати, залишає заявку. Якщо портфоліо ізольоване на окремій сторінці без фільтра за послугою — конверсія падає. Зв'язок будується в result_modifier.php з обох боків: картки послуг показують пов'язані кейси, картки кейсів посилаються на послуги.

Зображення для галереї обробляються через CFile::ResizeImageGet() — генеруємо прев'ю 400x300 для сітки і повнорозмірні для перегляду. WebP-конвертація через параметр BX_RESIZE_IMAGE_PROPORTIONAL_ALT.

Команда та прив'язка спеціалістів

Інфоблок «Спеціалісти» — елементи з полями: фото, ПІБ, посада, стаж, опис, сертифікати (множинний файл). Прив'язка до послуг — двостороння: у картці спеціаліста показуємо його послуги, у картці послуги — спеціалістів.

Реалізація: властивість SPECIALISTS в інфоблоці послуг (прив'язка до елементів інфоблоку спеціалістів). Зворотна вибірка — CIBlockElement::GetList() з фільтром PROPERTY_SPECIALISTS = ID спеціаліста. Кешування обов'язкове — без нього на сторінці «Команда» з 20 спеціалістами і їхніми послугами буде 21 запит до бази.

Для медичних і б'юті-сайтів критична сторінка спеціаліста з розкладом. Розклад — або з Бітрікс24 (REST API calendar.event.get), або з кастомного інфоблоку «Розклад» з елементами-слотами. Другий варіант простіший у реалізації, але вимагає ручного оновлення розкладу менеджером.

SEO для каталогу послуг

Кожна послуга — унікальні title, description, keywords. Шаблони META задаються на рівні інфоблоку через «SEO → Шаблони META для елементів»:

• {=this.Name} — назва послуги
• {=this.PreviewText} — анонс
• {=parent.Name} — назва розділу (категорії)

Шаблон title для послуги: {=this.Name} — {=parent.Name} | Компанія. Для розділів: {=this.Name} — каталог послуг | Компанія. Перевизначення для конкретного елемента — через поля ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION.

ЧПУ — через налаштування інфоблоку: URL_SECTION = /services/#SECTION_CODE#/, URL_DETAIL = /services/#SECTION_CODE#/#ELEMENT_CODE#/. Символьний код генерується з назви транслітерацією. Перевіряємо унікальність — дублі кодів ламають маршрутизацію.

Хлібні крихти — компонент bitrix:breadcrumb. Автоматично будує ланцюжок за структурою розділів інфоблоку. Для JSON-LD розмітки BreadcrumbList — додаємо скрипт у result_modifier.php.

Калькулятор вартості

Для сайтів ремонтних, будівельних, клінінгових компаній калькулятор — основний інструмент лідогенерації.

Фронтовий калькулятор — React/Vue-компонент, логіка розрахунку на клієнті. Параметри (ціни за одиницю, коефіцієнти) зберігаються в Highload-блоці і підвантажуються через REST API або AJAX-контролер. Результат розрахунку відправляється як лід у CRM. Плюс: миттєвий відгук. Мінус: клієнт бачить формулу розрахунку у вихідному коді.

Серверний калькулятор — кожна зміна параметра відправляє запит на сервер через Bitrix\Main\Engine\Controller. Формула прихована. Підходить для складних розрахунків із залежностями (площа приміщення → тип покриття → кількість матеріалу → вартість робіт).

Багатофіліальність

Для компанії з офісами в декількох містах — інфоблок «Філії»: адреса, телефон, координати, графік роботи, фото. Прив'язка послуг до філій через властивість BRANCHES — не всі послуги доступні у всіх філіях.

На фронті — визначення міста за IP через ipgeobase або bitrix:main.site.selector. Фільтрація послуг за обраною філією: у компоненті news.list додаємо фільтр PROPERTY_BRANCHES = ID поточної філії. Місто зберігається в cookie або сесії.

Карта філій — bitrix:map.yandex.view для Яндекс.Карт або кастомна інтеграція з Google Maps API. Координати зберігаються у властивості типу «Прив'язка до карти».

Інтеграція з CRM

Кожна форма на сайті — потенційний лід. Інтеграція з Бітрікс24 CRM через REST API:

• Форма заявки → crm.lead.add із джерелом WEB, прив'язкою до послуги через UF-поле
• Онлайн-запис → crm.lead.add + calendar.event.add
• Калькулятор → crm.lead.add із розрахунком у коментарі
• Зворотний дзвінок → crm.lead.add із позначкою «Передзвонити»

UTM-мітки з URL передаються в лід через поля UTM_SOURCE, UTM_MEDIUM, UTM_CAMPAIGN. Це дає змогу відстежувати, який рекламний канал привів клієнта.

Хмарний Бітрікс24 — авторизація через OAuth 2.0 або вхідний вебхук. Коробковий — через модуль crm, прямий доступ до API на тому ж сервері.

Етапи розробки

1. Аналіз і проєктування (1-2 тижні) — аудит поточного сайту (якщо є), структура послуг, користувацькі сценарії, прототипи ключових сторінок
2. Дизайн (1-3 тижні) — UI-кіт, макети адаптивних сторінок, дизайн картки послуги, форми запису, калькулятора
3. Розробка backend (2-4 тижні) — інфоблоки, компоненти, інтеграція з CRM, форми, калькулятор
4. Розробка frontend (2-3 тижні) — верстка шаблонів, інтерактивні компоненти, адаптив
5. Контент і SEO (1-2 тижні) — наповнення, налаштування META-шаблонів, sitemap, robots.txt
6. Тестування та запуск (1 тиждень) — функціональне тестування, перевірка форм, кросбраузерність

Типові помилки на сайтах послуг

• Послуги як сторінки, а не елементи інфоблоку. Кожна послуга — статична сторінка в структурі сайту. Немає фільтрації, немає сортування, неможливо автоматично побудувати каталог. Переробка — міграція контенту в інфоблок і переписування URL із 301-редиректами
• Форми без інтеграції з CRM. Заявки потрапляють на email і губляться. Менеджер не бачить історії комунікацій із клієнтом. Інтеграція з CRM займає 2-3 дні розробки, але окупається за тиждень
• Однакові META-теги на всіх послугах. Google сприймає це як дубльований контент. Шаблони META з підстановкою назви послуги та розділу — базова гігієна, яка часто ігнорується