Налаштування QR-кодів для швидкого переходу до товару 1С-Бітрікс
Ми налаштовуємо QR-коди для інтернет-магазинів на 1С-Бітрікс, щоб ваш офлайн-канал приносив вимірювані продажі. Типова ситуація: надрукували 1000 етикеток з QR, а через місяць змінили структуру каталогу — всі посилання зламалися. Наші інженери вирішують цю проблему на етапі проєктування, обираючи правильну стратегію URL — за артикулом або ID товару. За багато років роботи ми реалізували понад 30 проєктів з інтеграцією QR у торгові каталоги — від невеликих інтернет-магазинів до мереж з 50 000 товарами. У цій статті розберемо, які технічні рішення працюють у продакшені, як уникнути битих посилань і чому кешування критичне при тисячах товарів. Якщо вам потрібне готове налаштування — зв'яжіться, ми оцінимо проєкт за 1 день.
Складський працівник сканує QR-код на коробці та потрапляє на картку товару в каталозі. Маркетолог друкує QR на ціннику в офлайн-магазині — покупець сканує та бачить відгуки, характеристики, кнопку «Купити». Завдання технічно просте, але деталі реалізації визначають, чи буде система працювати стабільно при тисячах товарів.
Який URL для QR-коду обрати?
QR-код — це закодований URL. Питання в тому, який URL кодувати, щоб він не зламався при зміні структури каталогу.
Пряме посилання на товар (https://shop.by/catalog/product/artikul-123/) — працює, поки не зміниться ЧПУ-адреса товару. Перейменували розділ каталогу — всі надруковані QR-коди стали битими.
Посилання через редирект за ID (https://shop.by/qr/1234/) — надійніше. Створюється PHP-сторінка або обробник у urlrewrite.php, який за ID товару отримує актуальний URL через CIBlockElement::GetByID() та робить 301-редирект. QR-код не залежить від структури каталогу.
Посилання за XML_ID або артикулом (https://shop.by/qr/?sku=ART-0042) — найкращий варіант для інтеграції з 1С, де артикул — основний ідентифікатор. Згідно з документацією 1С-Бітрікс, API дозволяє шукати елемент за будь-якою властивістю. Обробник шукає елемент за властивістю ARTICLE і робить редирект.
| Тип посилання |
Надійність |
Коли використовувати |
| Прямий URL |
Низька (ламається при зміні ЧПУ) |
Для тимчасових акцій, коли каталог не редагується |
| Редирект за ID |
Висока (не залежить від ЧПУ) |
Для стабільних QR-кодів на постійних носіях |
| Редирект за артикулом |
Дуже висока (стійкий до переїздів) |
Для інтеграції з 1С, при частому оновленні каталогу |
Як прискорити генерацію QR-кодів?
На сервері QR генерується PHP-бібліотекою. Два робочих варіанти:
-
chillerlan/php-qrcode — компактна, без залежностей, генерує SVG та PNG.
- endroid/qr-code — більше можливостей (логотип всередині QR, кольори), але важча.
Встановлення через Composer: composer require chillerlan/php-qrcode. Генерація в компоненті catalog.element: у result_modifier.php додається код, який створює SVG-рядок QR для поточного товару. SVG вбудовується в шаблон через $arResult['QR_CODE_SVG'].
Для масової генерації (друк каталогу, етикетки) створіть окрему сторінку /admin/qr-export/, яка генерує PDF з QR-кодами для вибраних товарів. Бібліотека TCPDF або Dompdf справляється з завданням.
Кешування та продуктивність
Генерація одного QR займає 5–15 мс. На сторінці каталогу з 30 товарами — до 450 мс тільки на QR. Рішення: генерувати QR один раз і зберігати як файл у /upload/qr/{ELEMENT_ID}.svg. При зміні URL товару (подія OnAfterIBlockElementUpdate) — видаляти файл, щоб при наступному запиті згенерувався новий.
Приклад оптимізації: при каталозі в 10 000 товарів економія серверного часу сягає 80%
Якщо не кешувати, при кожному перегляді списку товарів генеруватиметься 10 000 QR-кодів заново. З кешуванням — тільки при першому зверненні або після зміни товару. Це знижує навантаження на сервер і прискорює завантаження сторінок.
UTM-мітки та аналітика
Додавайте в URL всередині QR UTM-параметри: ?utm_source=qr&utm_medium=offline&utm_campaign=price_tag. Це дозволить у Яндекс.Метриці та Google Analytics відстежити, скільки переходів дають офлайн-носії. Параметри не впливають на редирект — обробник їх просто прокид�е.
Як відбувається налаштування під ключ?
| Етап |
Дія |
Результат |
| Аналітика |
Вивчаємо структуру каталогу та вимоги |
Вибір стратегії URL (артикул або ID) |
| Розробка |
Створюємо обробник редиректів та кешування |
Стабільні QR-коди |
| Інтеграція |
Генерація QR на сторінці товару (SVG) + масова вигрузка PDF |
Готові файли для друку |
| Тестування |
Перевіряємо редиректи, UTM, продуктивність |
Робота без помилок |
| Деплой |
Завантаження на бойовий сервер, документація |
Підтримка 30 днів |
Що входить у налаштування QR-кодів під ключ?
У комплексне налаштування входить:
- Аналіз поточної структури URL та вибір оптимальної стратегії (артикул або ID)
- Розробка обробника редиректів з урахуванням кешування
- Інтеграція генерації QR-кодів на сторінці товару (SVG-вставка)
- Налаштування масової вигрузки QR у PDF для друку на цінниках та етикетках
- Додавання UTM-міток з можливістю змінювати кампанії без передруку QR
- Документація з експлуатації та інструкція для маркетолога
- Безкоштовна підтримка протягом 30 днів після запуску
Замовте налаштування QR-кодів — розрахуємо вартість за 1 робочий день. Отримайте готове рішення з гарантією стабільної роботи при будь-яких обсягах каталогу. Зв'яжіться з нами для консультації.
Міграція сайтів на 1С-Бітрікс
Переїзд на нову CMS — завжди стрес для сайту. Якщо проігнорувати URL-структуру, через два тижні трафік падає на 50–80 %. WordPress генерує /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, а Бітрікс за замовчуванням хоче /catalog/section/element/. Без карти 301-редиректів пошуковики фіксують масові 404. Ми починаємо будь-яку міграцію зі сканування старого сайту через Screaming Frog і складаємо повну карту редиректів ще до першого рядка коду. Як сказано в документації 1С-Бітрікс: коректна міграція вимагає повного маппінгу URL.
За 7 років ми перенесли понад 50 проєктів — від лендінгів до каталогів на 300 000 товарів. Середній термін — 2–8 тижнів. Оцінку проєкту робимо безкоштовно за 1 день — зв'яжіться для попереднього розрахунку.
Які CMS ми переносимо на Бітрікс?
За роки роботи дані мігрували з десятків систем.
Блоги та корпоративні сайти: WordPress / WooCommerce → 1С-Бітрікс. Таблиці wp_posts, wp_postmeta, wp_wc_product_meta_lookup маппяться в інфоблоки та highload-блоки. Варіації товарів (WooCommerce Variable Product) стають торговими пропозиціями (b_catalog_product).
Інтернет-магазини: OpenCart / ocStore → 1С-Бітрікс. Структура oc_product, oc_product_description, oc_product_to_category переїжджає в ієрархію інфоблоків. Мультимовність OpenCart перетворюється на мовні версії властивостей. Joomla / VirtueMart, MODX Revolution (TV-змінні → властивості інфоблоків), Drupal, PrestaShop — аналогічно.
SaaS-платформи: Tilda, InSales, Shopify, Wix, Squarespace. Бізнес переріс конструктор — потрібні 1С-інтеграції та управління залишками.
Самописні двигуни: реверсимо БД і відновлюємо бізнес-логіку за вихідним кодом.
Що переноситься?
Контент: сторінки, статті, новини → інформаційні інфоблоки. Каталог: категорії → розділи, товари → елементи з прив'язкою до b_catalog_product, властивості → властивості інфоблоку або highload-довідники. Зображення, відгуки, FAQ.
E-commerce: товари з варіаціями (торгові пропозиції), ціни в b_catalog_price (мультивалютні через b_catalog_currency), залишки по складах b_catalog_store_product, знижки (b_sale_discount), історія замовлень (b_sale_order + b_sale_basket).
Користувачі: клієнтська база — b_user + UF-поля. Паролі в кожній CMS хешуються по-своєму: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Ми пишемо кастомний CUser::LoginByHash з fallback на старий алгоритм — клієнт вводить пароль один раз, система перехешує в bcrypt Бітрікса.
SEO-дані: мета-теги, alt-теги, URL-структура. Головне завдання — зберегти всі URL або проставити 301-редиректи.
Медіа: зображення, документи, відео — зі збереженням шляхів та оптимізацією через CFile::MakeFileArray().
Як відбувається міграція?
| Етап |
Тривалість |
Що робимо |
| Аудит |
1–3 дні |
Скануємо Screaming Frog: всі URL, статус-коди, мета-теги. Аналізуємо структуру БД, кастомні доробки, інтеграції. Складаємо карту перенесення. |
| Проектування архітектури |
2–5 днів |
Маппінг: типи контенту → інфоблоки, поля → властивості, довідники → highload-блоки. Архітектура має бути зручною для адміністрування в Бітрікс. |
| Скрипти міграції |
3–10 днів |
PHP-скрипти читають зі старої БД (або API), трансформують і пишуть через API Бітрікса (CIBlockElement::Add, \Bitrix\Sale\Order::create). Запускаємо повторно при тестуванні. |
| Staging |
1–2 дні |
Повне перенесення на тестовий сервер. Перевіряємо цілісність: кількість товарів, властивості, URL, фільтри. |
| Дизайн / шаблони |
1–4 тижні |
Редизайн або адаптація верстки під шаблонізатор Бітрікса (template.php, result_modifier.php). |
| 301-редиректи |
1–2 дні |
Повна карта в .htaccess або nginx.conf. Кожен проіндексований URL → відповідна сторінка нового сайту. |
| Фінальна міграція |
1 день |
Дельта-імпорт свіжих даних, перемикання DNS, моніторинг. |
| Постміграційний контроль |
2–4 тижні |
Моніторимо Google Search Console та Яндекс.Вебмастер: індексація, позиції, crawl errors. |
Як зберегти SEO-позиції?
Втрата органічного трафіку — головний страх, і він обґрунтований. Ось як ми його уникаємо.
Маппінг URL 1:1 — де можливо, через CUrlRewriter та ЧПУ-налаштування інфоблоку зберігаємо точну структуру. Де не можна — 301. Автогенерація карти редиректів: парсимо експорт Screaming Frog, зіставляємо з slugs нових елементів, генеруємо конфіг nginx. Кожен редирект перевіряється curl -I після перемикання.
Перенесення мета-тегів: title, description, h1 переносяться як є у властивості ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION. Canonical: rel="canonical" через SEO-компонент Бітрікс. Дуби відсікаємо: www/без www, http/https, параметри сортування. Sitemap: нова sitemap.xml через модуль seo Бітрікса, подача в Search Console та Вебмастер одразу після перемикання.
Порівняння швидкості: Бітрікс у 3 рази швидше обробляє каталог із 100 000 товарів, ніж OpenCart, завдяки тегованому кешуванню та оптимізації запитів до b_catalog_product.
Що входить у роботу (deliverables)
| Що отримує клієнт |
Опис |
| Документація |
Карта редиректів, опис маппінгу, схема БД |
| Доступи |
Адміністративна панель, FTP/SSH, API-ключі |
| Навчання |
Відеоуроки або консультація з роботи з Бітрікс |
| Підтримка |
2 тижні постміграційного моніторингу та фіксу багів |
| Гарантія |
Повернення до старого сайту протягом 48 годин при форс-мажорі |
Міграція інтеграцій
Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:
- Платіжні системи —
sale.paysystem зі збереженням історії транзакцій.
- Доставка — налаштування
sale.delivery.handler (СДЕК, Укрпошта).
- CRM — прив'язка до Бітрікс24 або збереження поточної через REST API.
- 1С — налаштування обміну через CommerceML. Часто це головна причина міграції на Бітрікс.
- Email-маркетинг — перенесення підписників, шаблонів, вебхуків.
- Аналітика — e-commerce tracking під нову структуру dataLayer.
Типові помилки при міграції
Кожна з цих помилок призводила до втрати позицій і клієнтів.
Втрата URL без редиректів — найруйнівніший промах. /product/123 замість /catalog/item-name.html — без 301 це масові 404 та обвал трафіку. Ми генеруємо карту автоматично і перевіряємо кожен редирект після перемикання.
Дублювання контенту: один товар доступний з www і без, по HTTP і HTTPS, з GET-параметрами фільтрації — п'ять URL замість одного. SEO-вага розмивається. Налаштовуємо canonical, 301 для варіацій, robots.txt з Disallow для параметрів.
Биті зображення: абсолютні URL в контенті (src="https://old-site.ru/img/photo.jpg"), втрата якості при перетисканні. Замінюємо на відносні шляхи, переносимо зі збереженням структури, перевіряємо HTTP 200 для кожного файлу.
Втрата мета-тегів і мікророзмітки: title, description, Schema.org можуть не перенестися або перенестися криво. Робимо повний маппінг і перевірку на staging.
Відвалені форми та інтеграції: змінилися ID, API-ключі, вебхуки. Складаємо реєстр усіх інтеграцій до початку і перевіряємо кожну після.
Мобільна версія: старий m.site.ru → адаптивний Бітрікс. Без редиректу мобільних URL — 404 для мобільних користувачів. Враховуємо в карті редиректів.
Перед міграцією обов'язково: 1) повне сканування Screaming Frog / Sitebulb; 2) експорт SEO (title, description, h1, canonical, hreflang); 3) фіксація позицій за ключовими запитами; 4) бекап файлів і БД з перевіркою відновлення; 5) реєстр усіх інтеграцій; 6) карта редиректів для кожної проіндексованої сторінки; 7) тестова міграція на staging з повною перевіркою; 8) коректна мобільна версія та редиректи з m.site.ru; 9) нова sitemap.xml готова до подачі; 10) план відкату: DNS збережені, конфіг задокументовано, доступ до старого хостингу є.
Терміни та економія
| Тип проєкту |
Терміни |
Коментар |
| Інформаційний сайт (до 500 стор.) |
2–4 тижні |
Контент + дизайн + редиректи |
| Інтернет-магазин (до 10 000 товарів) |
4–8 тижнів |
Каталог + замовлення + інтеграції |
| Великий магазин (100 000+ товарів) |
2–4 місяці |
Кастомні скрипти + навантажувальне тестування |
Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.
Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
