Ви переносите сайт з DataLife Engine на 1С-Бітрікс, і користувачі скаржаться на зламані URL, зниклі коментарі або неробочий вхід. DLE — популярний двигун новинних порталів, але його архітектура застаріла: хеші паролів MD5, плоска структура бази та відсутність вбудованої підтримки торговельних каталогів. Міграція DLE на Бітрікс — складний процес, але він відкриває доступ до гнучкості інфоблоків, REST API та інтеграції з 1С через CommerceML. Наша команда спеціалізується на 1С-Бітрікс розробці понад 10 років, виконавши 50+ успішних перенесень. Оцінимо ваш проєкт за два дні, без передоплати.
Які проблеми вирішуємо
Паролі
DLE використовує MD5 або sha256 — Бітрікс не сприймає ці хеші. Проста заміна призведе до блокування користувачів. Ми впроваджуємо шим-модуль: перевіряємо старий хеш при вході, через CUser::CheckPassword() оновлюємо на штатний формат. Користувач не помічає переходу.
SEO-посилання
DLE генерує URL виду /category/article.html. У Бітрікс структура /catalog/article/. Без 301 редиректів ви втрачаєте до 70% трафіку. Ми мапимо старі alt_name на нові CODE та налаштовуємо редиректи через mod_rewrite або компонент bitrix:main.urlrewrite. Мета-теги з dle_post_extras переносяться в SEO-властивості інфоблоку.
Обсяг даних
При 50 000+ публікаціях стандартні SQL-запити зависають. Ми використовуємо пакетну вставку через CIBlockElement::Add з вимкненням подій та кешування. Індекс ix_sort та теговане кешування (CACHE_TYPE = A) прискорюють завантаження каталогу в 10 разів.
Як ми це робимо
Перенесення публікацій в інфоблок «Новини». Маппінг полів:
DLE (dle_post) |
Бітрікс (інфоблок) |
title |
NAME |
short_story |
PREVIEW_TEXT (html) |
full_story |
DETAIL_TEXT (html) |
date |
ACTIVE_FROM |
alt_name |
CODE |
approve, category |
ACTIVE, IBLOCK_SECTION_ID |
Категорії створюються першими через CIBlockSection::Add(), зі збереженням ієрархії (parentid → IBLOCK_SECTION_ID).
Додаткові поля (xfields) парсяться з рядка формату field1|value1||field2|value2 та зберігаються у властивості інфоблоку:
// Парсинг extra_fields из DLE
$extraFields = [];
foreach (explode('||', $row['xfields']) as $pair) {
[$key, $val] = explode('|', $pair, 2);
$extraFields[$key] = $val;
}
У реальному проєкті з 20 000 публікацій ми перенесли 150 000 зображень, перезібрали галереї та відновили зв'язки з категоріями. Аудит після міграції показав розбіжність лише 3% — всі помилки виправили за день.
Як перенести користувачів без втрати даних?
База користувачів DLE (dle_users) містить до 100 000 записів. CUser::Add() у циклі повільний — оптимізуємо через CLanguage::GetList() та CGroup::GetList() для кешування груп. Паролі залишаємо в полі PASSWORD як тимчасовий хеш, а при вході перевіряємо через стару функцію dle_hash(). Після першої зміни пароля користувач перемикається на штатний.
Що робити з SEO-посиланнями після міграції?
Всі старі URL повинні редиректитися на нові. Збираємо список із dle_post.alt_name та dle_category.alt_name, генеруємо 301 редиректи в .htaccess або налаштовуємо в Бітрікс через компонент bitrix:main.urlrewriter.add. Мета-теги переносяться у властивості інфоблоку UF_SEO_TITLE та UF_SEO_DESCRIPTION. SEO-міграція з обов'язковим перенесенням мета-тегів зберігає до 90% позицій у пошуковій видачі.
Процес роботи
- Аналітика — аудит БД DLE, виявлення несумісностей, оцінка обсягу. Складаємо карту полів.
- Проєктування — створюємо інфоблоки, властивості, розділи. Налаштовуємо теговане кешування та інтеграцію з 1С через CommerceML.
- Реалізація — скрипти експорту/імпорту в PHP 8.1+. Пакетне завантаження через
CIBlockElement::Add з вимкненням подій.
- Тест — звірка кількості елементів, перевірка авторизації, редиректів, зображень.
- Деплой — перенесення на продакшен, моніторинг логів, тиждень підтримки.
Порівняння швидкості: Бітрікс з налаштованим кешуванням видає сторінку каталогу в 7,5 разів швидше за DLE — 0,2 с проти 1,5 с. Порівняння продуктивності проведено на типовому сервері з 8 ГБ ОЗУ. На одному з проєктів міграція дозволила знизити час генерації сторінки з 3 секунд до 0.3 секунди, що безпосередньо вплинуло на конверсію та поведінкові фактори.
Терміни орієнтовно
| Обсяг |
Термін |
| до 5 000 публікацій, без xfields |
2–4 тижні |
| 5 000–50 000 публікацій, з користувачами |
5–8 тижнів |
| 50 000+, з галереями та коментарями |
2–4 місяці |
Типові помилки при міграції з DLE
- Не налаштовані 301 редиректи — падіння трафіку до 70%.
- Ігнорування xfields — втрата додаткових даних.
- Пряма вставка хешів паролів — блокування входу.
Що входить у роботу
- Повний дамп БД та файлів (страховка від втрати).
- Створення інфоблоків, властивостей, розділів.
- Перенесення публікацій, користувачів, коментарів, зображень.
- Налаштування 301 редиректів та SEO-метаданих.
- Навчання адміністраторів роботі з Бітрікс.
- Технічна підтримка 7 днів після запуску.
Приклад налаштування редиректу в .htaccess:
RewriteRule ^category/(.*)\.html$ /catalog/$1/ [R=301,L]
Отримайте консультацію — оцінимо проєкт за два дні. Ми гарантуємо збереження даних та прозору звітність на кожному етапі. Наша команда має 10+ років досвіду з 1С-Бітрікс та DLE, понад 50 успішних міграцій. Замовте міграцію прямо зараз, щоб не втратити трафік та користувачів. Якщо ви плануєте міграцію, зв'яжіться з нами — ми оцінимо обсяг робіт та терміни.
Міграція сайтів на 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 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
