Перенесення з MODX на 1С-Бітрікс: аудит, міграція та SEO за 7–11 днів

Перенесення з MODX на 1С-Бітрікс: повний розбір процесу

Ми часто беремо проекти, де MODX перестає справлятися з ростом бізнесу. Типова ситуація: клієнт скаржиться на повільну інтеграцію з 1С (через сторонні компоненти), відсутність вбудованої CRM та обмежений функціонал інтернет-магазину — при каталозі в 10 000 товарів miniShop2 починає гальмувати. Перехід на 1С-Бітрікс вирішує ці завдання, але потребує чіткого плану та глибокого розуміння обох систем. Міграція під ключ включає аудит, повне перенесення даних, налаштування 301-редиректів та навчання команди. Терміни — від 7 до 11 робочих днів, точна вартість розраховується після аудиту.

Повний процес перенесення даних з MODX Revolution на 1С-Бітрікс передбачає збереження всіх позицій та даних. Грамотна міграція скорочує час на розробку типового функціоналу на 40–60% завдяки готовим інтеграціям через CommerceML.

Проблеми, які вирішуємо

• Повільна інтеграція з 1С: MODX потребує сторонніх модулів, які часто працюють нестабільно. Бітрікс має штатний обмін через CommerceML, що пришвидшує синхронізацію в 3–5 разів.
• Відсутність CRM: У MODX немає вбудованої CRM, доводиться використовувати зовнішні сервіси. Бітрікс надає повноцінну CRM із бізнес-процесами.
• Обмежений каталог: miniShop2 починає гальмувати при великій кількості товарів. Інфоблоки Бітрікс оптимізовані для каталогів на десятки тисяч позицій.
• SEO-втрати: При ручному перенесенні губляться URL, мета-теги, позиції. Ми налаштовуємо 301-редиректи та переносимо SEO-дані.

Як ми це робимо: технічні деталі

Наш підхід базується на аналізі структури MODX та автоматизованому маппінгу в інфоблоки Бітрікс. Ми використовуємо PHP-скрипти для вичитування даних з таблиць MODX та створення елементів інфоблоків через API CIBlockElement::Add. Для зображень використовуємо CFile::MakeFileArray.

Приклад з практики: На проекті з каталогом 12 000 товарів та 40 TV-змінними ми автоматизували маппінг і перенесли контент за 2 дні замість ручного копіювання, яке зайняло б тиждень. Завдяки штатним механізмам CommerceML час обробки замовлення скоротився з 8с до 1.2с.

Модель даних MODX Revolution

MODX зберігає контент у таблицях з префіксом modx_. Ключові таблиці:

• modx_site_content — всі ресурси: сторінки, статті, папки. Поля: id, pagetitle, longtitle, alias, content, introtext, parent, template, published, publishedon, createdby, createdon, menutitle, description, content_type, uri.
• modx_site_tmplvar_contentvalues — значення TV-змінних для ресурсів: tmplvarid, contentid, value.
• modx_site_tmplvars — визначення TV-змінних: name, caption, type, elements, default_text.
• modx_site_templates — шаблони.
• modx_users, modx_user_attributes — користувачі.
• modx_categories — категорії снипетів/чанків.

Для магазинів на miniShop2 додаються таблиці msProduct, msProductOption, msCategory, msOrder, msOrderProduct. Розуміння цієї схеми — основа для коректного маппінгу в інфоблоки Бітрікс.

Дерево сторінок MODX → структура Бітрікс

MODX будує сайт як дерево ресурсів. У Бітрікс структура визначається фізичними файлами в директоріях плюс адміністративна частина. Статичні сторінки (корпоративний сайт, «Про компанію», «Контакти») переносяться двома способами:

1. Сторінками Бітрікс — створюємо PHP-файли в потрібних папках, контент прописуємо через $APPLICATION->SetPageProperty() та компоненти.
2. Елементами інфоблоку — якщо сторінок багато і вони однотипні (блог, новини).

TV-змінні → властивості інфоблоку

TV-змінні (Template Variables) — аналог властивостей інфоблоку. Маппінг типів:

На типовому проекті буває до 50 TV-змінних. Ми автоматично читаємо їхні визначення та створюємо відповідні властивості інфоблоку.

Процес перенесення контенту

Скрипт на PHP послідовно обробляє ресурси MODX:

1. Визначає розділ інфоблоку за parent (рекурсивно будується дерево розділів).
2. Збирає TV-значення через JOIN таблиць modx_site_tmplvar_contentvalues та modx_site_tmplvars.
3. Створює елемент інфоблоку через CIBlockElement::Add().

Поле uri в MODX — готова ЧПУ-адреса. Зберігаємо його як CODE елемента та формуємо 301-редиректи.

Зображення. У TV-змінних типу image зберігаються шляхи виду /assets/images/photo.jpg. Копіюємо файли на сервер Бітрікс та реєструємо через CFile::MakeFileArray().

miniShop2 → Бітрікс Каталог

Якщо на MODX встановлений miniShop2:

• msProduct (JOIN до modx_site_content) → елементи інфоблоку каталогу.
• msProductOption — опції товару (колір, розмір) → торгові пропозиції.
• msCategory → розділи інфоблоку.
• msOrder / msOrderProduct → b_sale_order / b_sale_basket.
• Ціни з msProduct.price → b_catalog_price з потрібним типом ціни.

Бітрікс виграє у MODX в інтеграціях з 1С в 3–5 разів швидше завдяки штатним механізмам CommerceML.

Переваги міграції на Бітрікс

Бітрікс надає готову CRM, бізнес-процеси, інтеграцію з 1С та маркетплейсами. MODX таких можливостей не має — їх доводиться реалізовувати сторонніми рішеннями. Перехід на Бітрікс скорочує час на розробку типового функціоналу на 40–60%.

Чанки, снипети та шаблони

Чанки (modx_site_htmlsnippets) та снипети (modx_site_snippets) — це код шаблонізатора MODX (Smarty/Twig або нативний PHP). Вони не переносяться автоматично. Весь функціонал реалізується заново через компоненти Бітрікс. Це найбільш трудомісткий етап, якщо сайт використовував складні снипети (pdoMenu, pdoPage, FormLister).

SEO-редиректи

MODX при ввімкнених friendly_urls будує URL по полю uri. Якщо використовувався AliasListing — URL міг включати повний шлях з дерева. Ми збираємо маппінг old_uri → new_url та прописуємо редиректи. Згідно з документацією 1С-Бітрікс, модуль «Пошукова оптимізація» дозволяє керувати редиректами без програмування.

Що входить в роботу

• Повний аудит структури MODX: ресурси, TV, розширення, miniShop2.
• Проектування інфоблоків та маппінг полів.
• Розробка скрипту міграції: контент, TV, зображення, замовлення.
• Перенесення та налаштування торгових пропозицій (якщо застосовно).
• Налаштування 301-редиректів та перевірка індексації.
• Навчання команди роботі в Бітрікс.
• Підтримка протягом 30 днів після запуску.

Терміни орієнтовно

Без miniShop2 міграція з MODX досить швидка — структура даних зрозуміла, TV добре маппуються на властивості інфоблоку. Оцінимо ваш проект безкоштовно — зв'яжіться з нами для консультації.

Міграція сайтів на 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().

Як відбувається міграція?

Як зберегти 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)

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

Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:

• Платіжні системи — 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 збережені, конфіг задокументовано, доступ до старого хостингу є.

Терміни та економія

Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.

Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.