Магазин на InSales — чудовий старт, але коли бізнес росте, SaaS-обмеження стають гальмом. Немає прямого доступу до бази, не можна встановити довільний код, складно інтегруватися з зовнішніми сервісами. Міграція на власну CMS — 1С-Бітрікс — вирішує ці проблеми. Однак перенесення даних — складне завдання: втрата даних або падіння SEO-позицій трапляються часто. Ми розробили методику, яка виключає ці ризики. За 8–10 робочих днів ми перенесемо магазин з повним збереженням даних, мінімальним даунтаймом та гарантією цілісності. Нижче — конкретні кроки та підводні камені, зібрані на більш ніж 50 проектах. Автоматизація через InSales API дозволяє виконати вивантаження в 10 разів швидше ручного експорту.
Обмеження InSales та що доступно через API
InSales — SaaS-платформа. Доступ до даних — тільки через API або експортні формати. Прямого SQL немає. Основний спосіб — REST API InSales, авторизація за ключем додатка, відповідь у JSON. Також доступні YML/CSV-вивантаження з адмінки (товари, замовлення).
Через API InSales доступні:
- Товари:
GET /admin/products.json — товари з варіантами, характеристиками, зображеннями. Пагінація по 100 записів. Поля: id, title, body_html, vendor, product_type, variants[], collections[], images[], fields_values[].
- Варіанти (variants) — аналог торгових пропозицій. Містять
sku, price, compare_at_price, quantity, weight, опції.
- Категорії:
GET /admin/collections.json — список з parent_id.
- Замовлення:
GET /admin/orders.json — замовлення з позиціями, адресами, статусами. Обмеження за датою.
- Покупці:
GET /admin/clients.json — клієнти з адресами.
Скрипт збору даних
Пишемо PHP-скрипт, який посторінково запитує дані з InSales API та зберігає в проміжний формат (JSON-файли або проміжна БД). Враховуємо rate limiting: не більше 2 запитів на секунду. При каталозі 10 000 товарів (100 сторінок × 100 товарів) — мінімум 50 секунд тільки на товари.
GET https://{shop}.myinsales.ru/admin/products.json
Authorization: Basic base64(api_key:api_password)
Як перенести товари, варіанти та зображення?
Після збору даних будуємо імпорт. Ось таблиця відповідності полів InSales → Бітрікс:
| Поле InSales |
Поле Бітрікс |
Примітка |
title |
NAME |
– |
body_html |
DETAIL_TEXT |
HTML |
fields_values[] |
Властивості інфоблоку |
Створюються динамічно |
collections[] |
Розділи інфоблоку |
|
variants[].price |
CATALOG_PRICE |
Ціна |
variants[].quantity |
CATALOG_QUANTITY |
Залишок |
images[] |
CFile::SaveFile() |
Завантажуємо на сервер |
Для варіантів: якщо у товара один варіант — це простий товар, ціну та залишок ставимо на сам елемент. Якщо варіантів кілька — створюємо торгові пропозиції в інфоблоці ТП, опції варіантів стають властивостями ТП.
Зображення: API повертає URL на CDN InSales. Завантажуємо через curl, зберігаємо на сервер, реєструємо через CFile::SaveFile(). Важливо: після переїзду CDN InSales може стати недоступним, тому всі зображення фізично копіюємо. Для подальшої синхронізації з 1С використовується CommerceML.
Перенесення замовлень, клієнтів та SEO
Покроково:
- Отримати список замовлень через
GET /admin/orders.json.
- Маппінг статусів (
new→N, confirmed→P, delivering→D, delivered→F, cancelled→C).
- Створити замовлення в
b_sale_order через CSaleOrder::Add().
- Клієнтів створити через
CUser::Add(); для guest-замовлень — або без реєстрації, або створити користувача за email.
InSales зберігає SEO-поля (seo_title, seo_description) — витягуємо через API (поля fields_values або окремі атрибути). URL в InSales будуються за шаблоном /products/{handle} та /categories/{handle}. Будуємо 301-редиректи зі старих URL на нові.
Обмеження API InSales
Не всі дані доступні через API. InSales не видає історію змін замовлень (тільки поточний статус), історію переглядів товарів, дані аналітики. Якщо потрібна детальна історія — просимо клієнта експортувати через адміністративний інтерфейс InSales перед відключенням магазину.
Чому важлива автоматизація через InSales API?
Ручний експорт через адмінку InSales займає багато часу та схильний до помилок. Автоматизація через API скорочує час вивантаження до 30% порівняно з ручною працею. Наприклад, каталог з 10 000 товарів через API вивантажується за 1 годину, а вручну — більше 3 годин. Крім того, API виключає людський фактор при зіставленні полів. Економія бюджету за рахунок автоматизації досягає 40% — це дозволяє направити кошти на розвиток магазину. Зв'яжіться з нами, щоб оцінити економію для вашого проекту.
Процес міграції
Етапи та терміни
| Етап |
Типові терміни |
| Аналіз API InSales, структури даних |
0,5 дня |
| Написання скрипта збору через API |
1–2 дні |
| Проектування інфоблоків в Бітрікс |
1 день |
| Імпорт товарів, варіантів, категорій |
2–3 дні |
| Завантаження зображень |
1 день |
| Замовлення, клієнти |
1 день |
| SEO-редиректи |
0,5 дня |
| Тестування |
1 день |
| Разом |
8–10 робочих днів |
Обмеження InSales API — головний уповільнюючий фактор. Великий каталог (50 000+ SKU) потребуватиме кількох годин лише на збір даних з урахуванням rate limiting.
Типові помилки при міграції
| Помилка |
Наслідки |
Рішення |
| Ігнорування rate limiting |
Блокування IP на 24 години |
Реалізувати затримки між запитами |
| Пряма вставка HTML в DETAIL_TEXT без очищення |
Ламається верстка |
Використовувати HTMLPurifier або CFile::MakeFileArray() |
| Пропуск маппінгу статусів замовлень |
Замовлення втрачаються |
Створити таблицю відповідності заздалегідь |
| Перенесення без 301 редиректів |
Втрата SEO-позицій |
Налаштувати редиректи до запуску |
Що входить в роботу?
Міграція під ключ за 8–10 днів. Входить:
- Повна документація по перенесених даних та структурі.
- Передача всіх доступів та інструкція з подальшої роботи.
- Гарантійна підтримка 2 тижні після міграції.
Вартість проекту розраховується індивідуально після аналізу. Замовте міграцію та отримайте гарантоване збереження даних і SEO-позицій.
Міграція сайтів на 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
