Послуги з міграції сайтів на 1С-Бітрікс

Міграція сайтів на 1С-Бітрікс

Перше, що ламається при переїзді — URL-структура. WordPress генерує /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, Бітрікс за замовчуванням хоче /catalog/section/element/. Якщо не проставити 301-редирект на кожну проіндексовану адресу — пошукові системи фіксують масові 404, і через два тижні трафік просідає на 50-80%. Ми починаємо будь-яку міграцію зі сканування старого сайту через Screaming Frog і формування повної карти редиректів ще до написання першого рядка коду.

З яких платформ мігруємо

За роки роботи переносили проєкти з десятків систем:

CMS:

• WordPress / WooCommerce → 1С-Бітрікс. Таблиці wp_posts, wp_postmeta, wp_wc_product_meta_lookup → інфоблоки та highload-блоки. Варіації товарів (WC Variable Product) мапляться в торгові пропозиції (b_catalog_product).
• OpenCart / ocStore → 1С-Бітрікс. Структура oc_product, oc_product_description, oc_product_to_category переїжджає в ієрархію інфоблоків. Мультимовність OpenCart → мовні версії властивостей.
• Joomla / VirtueMart → 1С-Бітрікс
• MODX Revolution → 1С-Бітрікс. Ресурси MODX з TV-змінними → елементи інфоблоків із властивостями.
• Drupal, PrestaShop → 1С-Бітрікс

SaaS:

• Tilda → 1С-Бітрікс (бізнес переріс конструктор, потрібна 1С-інтеграція)
• InSales, Shopify → 1С-Бітрікс
• 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-дані: мета-теги (title, description), alt-теги, URL-структура. Головне завдання — зберегти всі URL або проставити коректні 301.

Медіа: зображення, документи, відео — зі збереженням шляхів та оптимізацією через CFile::MakeFileArray().

Процес міграції

1. Аудит (1-3 дні). Скануємо Screaming Frog: усі URL, статус-коди, мета-теги, зображення. Розбираємо структуру БД, кастомні доробки, інтеграції. На виході — детальна карта: що, куди, як переїжджає. Саме тут з'ясовується, що «простий магазин на WooCommerce» має 47 плагінів і кастомну логіку ціноутворення.

2. Проєктування архітектури (2-5 днів). Мапінг: типи контенту → інфоблоки, поля → властивості, довідники → highload-блоки. Архітектура не просто вміщує старі дані — вона робить їх зручними для роботи в Бітрікс.

3. Скрипти міграції (3-10 днів). Жодного ручного копіювання. PHP-скрипти читають зі старої БД (або API), трансформують і пишуть через API Бітрікс (CIBlockElement::Add, \Bitrix\Sale\Order::create). Автоматизація дозволяє запускати міграцію повторно — критично для тестування.

4. Staging (1-2 дні). Повне перенесення на тестовий сервер. Перевіряємо цілісність: кількість товарів, збереження властивостей, коректність URL, роботу фільтрів. Проганяємо чекліст із 50+ пунктів.

5. Дизайн/шаблони (1-4 тижні). Редизайн — нові шаблони. Без редизайну — адаптація верстки під шаблонізатор Бітрікс (template.php, result_modifier.php).

6. 301-редиректи. Повна карта в .htaccess або nginx.conf. Кожна проіндексована URL старого сайту → відповідна сторінка нового. Пропустити одну — втратити сторінку з індексу. Генеруємо автоматично, перевіряємо скриптом після перемикання.

7. Фінальна міграція (1 день). Дельта-імпорт свіжих даних (замовлення та контент, що з'явилися після тестової міграції), перемикання DNS, моніторинг у реалтаймі. Зазвичай вночі — мінімум впливу на відвідувачів.

8. Постміграційний контроль (2-4 тижні). Моніторимо Google Search Console та Яндекс.Вебмайстер: індексація, позиції, crawl errors. Стежимо за трафіком і конверсіями в аналітиці. Будь-які відхилення — реагуємо негайно.

Збереження SEO-позицій

Втрата органічного трафіку — головний страх, і обґрунтований.

• 1:1 мапінг URL — де можливо, через CUrlRewriter і ЧПУ-налаштування інфоблоку зберігаємо точну структуру. Де не можна — 301.
• Автогенерація карти — парсимо Screaming Frog експорт, зіставляємо зі slug-ами нових елементів, генеруємо конфіг 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 та Вебмайстер одразу після перемикання.

Міграція інтеграцій

Зовнішні інтеграції — окремий пласт:

• Платіжні системи — перепідключення 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.ua → адаптивний Бітрікс. Без редиректу мобільних URL — 404 для мобільних користувачів. Враховуємо в карті редиректів.

Чекліст

1. Повне сканування: Screaming Frog / Sitebulb — усі URL, зображення, PDF
2. Експорт SEO: title, description, h1, canonical, hreflang
3. Фіксація позицій за ключовими запитами — без цього не зрозумієте, що змінилося
4. Бекап файлів і БД. Перевірити, що відновимо — на практиці, не в теорії
5. Реєстр інтеграцій: платіжки, доставка, CRM, аналітика, розсилки, колтрекінг
6. Карта редиректів: старий URL → новий для кожної проіндексованої сторінки
7. Тестова міграція на staging з повною перевіркою
8. Мобільна версія: усі сторінки коректні, мобільні URL у редиректах
9. Нова sitemap.xml готова до подання
10. План відкату: DNS збережені, конфіг задокументований, доступ до старого хостингу є