Перенесення інтернет-магазину з Бітрікс на WooCommerce без втрати даних

Товари під час перенесення інтернет-магазину з Бітрікс на WooCommerce зазвичай потрапляють у новий магазин повністю. Покупці з паролями та історія замовлень втрачаються значно частіше: вбудований імпорт WooCommerce завантажує лише товари, а одне замовлення в Бітрікс розкладено щонайменше по п’яти таблицях бази даних. Нижче — порядок перенесення магазину з Бітрікс на WordPress і WooCommerce: аудит старого сайту, каталог, покупці без зміни пароля, замовлення, позиції в Google і перевірка перед перемиканням.

Аудит: що є на сайті зараз

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

Список усіх адрес

Повний список URL збирають із трьох джерел, кожне показує своє:

• sitemap.xml — сторінки, які Бітрікс включив до карти сайту за своїми налаштуваннями;
• краулер (програма, яка обходить сайт за посиланнями, наприклад Screaming Frog) — усе, на що є внутрішні посилання, зокрема картинки та PDF;
• Google Search Console, звіт «Ефективність» за сторінками — адреси, на які люди реально приходять із пошуку, зокрема старі акції та зняті товари, яких давно немає ні в меню, ні в sitemap.

У магазині на Бітрікс до списку потрапляють адреси, про які власник зазвичай не пам’ятає: сторінки з index.php у кінці адреси, пагінація на кшталт ?PAGEN_1=2, сторінки розумного фільтра з /filter/…/apply/, файли з папки /upload/ (фото, прайси, інструкції). Усі вони потім увійдуть до карти редиректів.

Одразу вивантажте із Search Console кліки та покази за сторінками хоча б за рік: після запуску трафік треба буде з чимось порівнювати. Для великого каталогу надійніше вивантаження через API Search Console.

Там само збережіть звіт «Посилання» — список сайтів, які посилаються на ваш. Ці адреси перевірте в карті редиректів насамперед, а після переїзду попросіть власників найцінніших сайтів замінити посилання на нові.

Що сайт робить, крім вітрини

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

Що і чим переноситься

Структура магазину на WordPress

Структуру нового магазину проєктують до імпорту: якщо завантажити товари, а адреси та фільтр продумати потім, половину роботи доведеться переробляти.

Адреси сторінок

WooCommerce за замовчуванням будує адреси так: товар — /product/nazvanie/, категорія — /product-category/nazvanie/. У Бітрікс каталог зазвичай влаштовано інакше, наприклад /catalog/razdel/tovar/. Базову частину адреси змінюють у розділі «Налаштування → Постійні посилання», точне повторення вкладених шляхів Бітрікс іноді потребує доопрацювання кодом.

Наша позиція: якщо категорії та картки дають помітний трафік із пошуку, адреси варто зберегти — менше редиректів, менше приводів для коливань у видачі. Якщо структура старого сайту заплутана і пошук її майже не цінує, адреси можна змінювати, але карта редиректів має покривати кожен старий URL.

Характеристики та фільтр

Властивості товарів із Бітрікс потрапляють у WooCommerce або в атрибути, або в довільні поля. Атрибути беруть участь у фільтрі та у варіаціях товару, довільні поля просто виводяться в картці.

Типова картина: у старому фільтрі 20 характеристик, покупці користуються трьома-чотирма, у частини товарів половина значень порожня. Переїзд — слушний момент це почистити: вирішіть, які властивості стануть атрибутами, які залишаться текстом у картці, а які не потрібні взагалі. Перевірте, чи однаково записані значення: «Синій», «синій» і «Синій » з пробілом після імпорту стануть трьома різними значеннями фільтра.

Тестова копія

Новий магазин збирають на тестовому сервері або піддомені, закритому від індексації. Старий сайт увесь цей час приймає замовлення, тому перед перемиканням роблять фінальне дозавантаження: замовлення, нових покупців, змінені паролі та залишки, що з’явилися після першого перенесення. На ці години зміни в каталозі на старому сайті заморожують.

Перед запуском закриття від індексації знімають: Google окремо попереджає, що забутий noindex або заборона в robots.txt заважає індексації нового сайту.

Якщо ви ще обираєте, як буде влаштовано майбутній магазин, подивіться, що входить до розробки інтернет-магазину на WordPress.

Перенесення товарів у WooCommerce

Коли вистачить стандартного імпорту

Вбудований імпорт товарів із CSV створює прості та варіативні товари, завантажує атрибути, підтягує зображення за посиланнями до медіатеки й оновлює товари, знайдені за ID або артикулом (SKU). Обмеження описано в тій самій документації:

• новому товару не можна задати свій ID — WooCommerce видасть наступний вільний номер;
• alt-тексти зображень імпорт не додає і не оновлює;
• якщо хостинг старого сайту не віддає картинку за прямим посиланням, зображення не завантажиться, і його доведеться додати вручну.

Для каталогу з простих товарів із кількома характеристиками CSV-імпорту зазвичай достатньо: вивантажили з Бітрікс, привели колонки до формату WooCommerce, завантажили, перевірили.

Коли потрібен скрипт

Скрипт перенесення потрібен, якщо в каталозі є хоча б щось із переліченого:

• торгові пропозиції з власними цінами, залишками та фотографіями;
• кілька типів цін (роздрібна, оптова): у Бітрікс ціни зберігаються окремою таблицею і прив’язані до типів;
• пов’язані товари, комплекти, документи до товарів, відгуки;
• описи з посиланнями на інші сторінки сайту — посилання треба переписати на нові адреси, інакше кожне вестиме через редирект.

Торгові пропозиції в документації Бітрікс описані як SKU, «одиниця складської наявності». У WooCommerce їм відповідають варіації варіативного товару: кожна отримує свій артикул, ціну та залишок, а значення розміру чи кольору стають атрибутами.

Збережіть старі ідентифікатори. У товару в Бітрікс є ID, артикул і поле «Зовнішній код» (XML_ID): через зовнішній код магазин зазвичай пов’язаний з обліковою системою, старий ID знадобиться під час перенесення замовлень. Запишіть усі три значення в поля нового товару.

Зображення

Фото товарів у Бітрікс лежать у папці /upload/, і під час переїзду їхні адреси змінюються. Google радить включати до плану переїзду адреси зображень, відео та файлів. Якщо картинки давали трафік із пошуку за зображеннями або їх багато, надійніше копіювати файли напряму і записувати пари «старий шлях — новий шлях» у ту саму карту редиректів. Завантаження за URL через імпорт підходить, коли фото небагато і трафіку вони не дають.

Покупці та паролі без скидання

Покупці

Покупець у WooCommerce — це користувач WordPress із платіжною адресою та адресою доставки. Під час перенесення користувачів із Бітрікс на WordPress забирають логін, e-mail, ім’я, телефон, адреси з профілів покупця та дату реєстрації.

Головна перешкода — повторювані e-mail. У Бітрікс перевірка унікальності e-mail під час реєстрації за замовчуванням вимкнена, і за роки в однієї людини накопичуються два-три облікові записи з однією адресою. WordPress другого користувача з тим самим e-mail не створить і відповість помилкою «Sorry, that email address is already used!». До перенесення вирішіть, що робити з дублями: зазвичай облікові записи об’єднують в один і прив’язують до нього всі замовлення.

Паролі

Бітрікс не зберігає пароль у відкритому вигляді, у базі лежить лише хеш — незворотний «відбиток» пароля. За хешем система перевіряє введений пароль, але відновити сам пароль із нього не можна. Тому «перенести паролі» означає перенести хеші й навчити WordPress їх перевіряти.

За вихідним кодом ядра Бітрікс (клас Bitrix\Main\Security\Password) хеші бувають трьох видів. Який лежить у конкретного покупця, залежить від версії Бітрікс і налаштувань сервера на момент збереження пароля:

1. Сучасний формат SHA-512: рядок починається з $6$, довжина близько 106 символів.
2. Старий формат: сіль плюс MD5 від солі та пароля.
3. Зовсім старий формат: MD5 від пароля без солі.

WordPress починаючи з версії 6.8 перевіряє паролі так. Хеш довжиною до 32 символів він порівнює як звичайний MD5 — третій формат Бітрікс проходить без доопрацювань. Хеш, записаний не у власному форматі WordPress, система перевіряє стандартною функцією PHP password_verify(). Вона сумісна з crypt(), а саме через crypt() Бітрікс створює SHA-512, тож перший формат теж працює штатно. Для другого формату пишуть невеликий обробник на офіційному фільтрі check_password: він повторює алгоритм Бітрікс і повідомляє WordPress, що пароль правильний.

Далі WordPress працює сам: після успішного входу він перераховує пароль із чужим форматом хешу в bcrypt (із префіксом $wp$2y$) і зберігає в базу. Цю поведінку описано в оголошенні про перехід WordPress 6.8 на bcrypt. Покупець вводить старий пароль і входить, не помічаючи переїзду, а хеші Бітрікс поступово зникають із бази.

Скидання пароля знадобиться у трьох випадках:

• покупець входив через соцмережу, і пароля в нього немає;
• на сайті стояв нестандартний модуль авторизації, який зберігав паролі по-своєму;
• після об’єднання дублів в облікового запису залишився пароль одного зі старих облікових записів, а покупець пам’ятає інший.

Таким покупцям вистачить звичайного посилання «Забули пароль?» — до запуску перевірте, що листи з нового сайту доходять і не потрапляють у спам. Масову розсилку «змініть пароль» ми не радимо: вона лякає людей і схожа на фішинг.

Вивантаження покупців із хешами паролів — персональні дані. Передавайте файл захищеним каналом і видаліть із серверів одразу після імпорту.

Перенесення історії замовлень

Чому її втрачають

У Бітрікс замовлення зберігається частинами: шапка в таблиці b_sale_order, товарні позиції в b_sale_basket, ПІБ, телефон і адреса в b_sale_order_props_value, оплати в b_sale_order_payment, відвантаження в b_sale_order_delivery. Вивантаження в CSV таку структуру не передає, а імпорт WooCommerce замовлення не завантажує взагалі. Залишається скрипт, який збирає кожне замовлення з усіх таблиць і створює заново у WooCommerce.

У нових магазинах WooCommerce з версії 8.2 (жовтень 2023 року) замовлення за замовчуванням зберігаються у власних таблицях (High-Performance Order Storage, HPOS). Документація WooCommerce вимагає працювати із замовленнями через функції самого WooCommerce, тому скрипт створює замовлення через об’єкт WC_Order, без прямого запису в базу.

Підводні камені

• Дати. Через REST API WooCommerce (інтерфейс для зовнішніх програм) дату створення замовлення задати не можна, поле лише для читання: усі замовлення отримають дату імпорту. Скрипт записує вихідну дату без обмежень.
• Залишки. WooCommerce списує товар зі складу, коли замовлення переходить у статус «Обробка», «На утриманні» або «Виконано», незалежно від способу створення замовлення. Тому історичні замовлення в цих статусах скрипт заздалегідь позначає як такі, що вже списали залишки, інакше склад нового магазину піде в мінус. Скасовані та невдалі замовлення так позначати не можна: за позначкою WooCommerce поверне на склад товар, який ніхто не списував, і залишки виявляться завищеними.
• Листи. Під час зміни статусу, наприклад на «Виконано», WooCommerce пише покупцеві. Якщо не вимкнути сповіщення на час імпорту, покупці отримають листи про давно закриті замовлення за всі роки.
• Номери. За замовчуванням номер замовлення у WooCommerce збігається з його внутрішнім ID. Покупці та менеджери пам’ятають старі номери, тому старий номер зберігають і виводять замість нового.
• Статуси. У Бітрікс статуси замовлень налаштовуються під магазин. У WooCommerce набір стандартний: «Очікує оплати», «Обробка», «На утриманні», «Виконано», «Скасовано», «Повернено», «Не вдалося». Потрібна таблиця відповідності.
• Видалені товари. У старих замовленнях трапляються товари, яких уже немає в каталозі. Позиція замовлення все одно зберігає назву, кількість і суму.
• Гостьові замовлення. Замовлення без реєстрації переносяться без прив’язки до користувача.

Переносити все чи зробити архів

Якщо покупці повертаються, заходять в особистий кабінет і повторюють замовлення, історію переносять у WooCommerce повністю. Якщо історія потрібна лише менеджерам для довідок і звітів, її іноді розумніше вивантажити в окремий архів: дешевше, але покупець в особистому кабінеті старих замовлень не побачить.

Облікова система, оплата, доставка

Обмін з обліковою системою, який працював на Бітрікс, на WordPress не переїде: це модуль Бітрікс, його налаштування, розклад і зіставлення полів залишаються на старому сайті. На WooCommerce обмін налаштовують заново — готовим плагіном, якщо він є для вашої облікової системи, або окремим доопрацюванням. Що підійде, залежить від того, що вміє віддавати і приймати облікова система; це з’ясовують під час аудиту. Збережені артикули та зовнішні коди тут допомагають: за ними облікова система знаходить товари нового сайту без ручного зіставлення.

Заново підключають і перевіряють:

• платіжні системи (тестова оплата та повернення на реальній картці);
• служби доставки та розрахунок вартості;
• вивантаження товарів на маркетплейси та прайс-агрегатори;
• шаблони листів покупцеві та сповіщення менеджерам;
• лічильники аналітики та цілі.

Редиректи та SEO під час переїзду

Основний документ із теми — посібник Google про переїзд сайту зі зміною URL. Нижче — те, що з нього стосується магазину.

Карта 301-редиректів

Карта редиректів — таблиця «стара адреса → нова адреса» для кожного URL зі списку, зібраного під час аудиту. Правила Google:

• Постійні серверні редиректи, код 301 або 308. Правила вебсервера та плагін редиректів у WordPress для Google однаково серверні.
• Без ланцюжків: стара адреса веде одразу на кінцеву. Ланцюжки з’являються непомітно — на старому сайті вже були редиректи з http на https і з www на домен без www, зверху додаються нові. Google допускає не більше трьох переходів.
• Не на головну. Масовий редирект старих сторінок на головну Google може розцінити як «м’яку 404»: сервер відповідає, що зі сторінкою все гаразд, а Google вважає її помилкою і прибирає з індексу.
• Код 404 або 410 для всього, що ви свідомо не переносите. Якщо у знятого товару є пряма заміна, редирект веде на неї.
• Картинки та файли теж входять до карти.
• Мінімум рік. Google радить тримати редиректи якомога довше, загалом не менше року. Ми не знімаємо їх узагалі, поки вони не заважають.

Окремо продумайте адреси з параметрами: ?PAGEN_1=2 перетворюється на /page/2/, а сторінки розумного фільтра, які давали трафік, ведуть на найближчу за змістом категорію або на такий самий відфільтрований список на новому сайті.

Метатеги, канонічні адреси, sitemap

• Title, description і H1 переносять для кожної сторінки, яка була в індексі.
• Кожна нова сторінка вказує в коді сама на себе як на основну версію (тег rel="canonical"). Якщо сайт має мовні версії, їхні взаємні посилання (розмітку hreflang) переналаштовують на нові адреси.
• Alt-тексти картинок записують скриптом, стандартний імпорт їх не переносить. Розмітку товарів (ціна та наявність у видачі Google) перевіряють інструментом Google «Перевірка розширених результатів».
• Внутрішні посилання в меню, текстах і описах товарів ведуть на нові адреси напряму, без редиректу.
• Новий sitemap.xml містить лише нові адреси, його надсилають у Search Console.
• robots.txt нового сайту закриває лише службові сторінки: кошик, оформлення замовлення, особистий кабінет.

День запуску

Якщо домен залишається тим самим, інструмент «Зміна адреси» в Search Console не потрібен: він лише для зміни домену. Якщо змінюється хостинг, Google радить за тиждень до переїзду знизити TTL DNS-записів (час, на який провайдери запам’ятовують IP-адресу сайту) до кількох годин і переконатися, що підтвердження прав у Search Console переживе переїзд — наприклад, HTML-файл підтвердження треба перенести на новий сервер.

Після перемикання перевірте редиректи: окремі адреси — інструментом перевірки URL у Search Console, весь список з аудиту — скриптом або краулером. Потім надішліть новий sitemap.

Що буде з позиціями

У перші тижні позиції можуть коливатися. Google пише прямо: видимість у пошуку під час переїзду тимчасово змінюється, і це нормально. У невеликих і середніх сайтів основна частина сторінок переїжджає за кілька тижнів, у великих — довше. Обіцянка «позиції не зміняться ні на день» суперечить документації Google.

Переїзд без втрати позицій на практиці означає переїзд без тривалої втрати. Якщо через кілька тижнів трафік не повернувся до попереднього рівня, майже завжди є помилка: пропущені редиректи, втрачені тексти або забутий noindex.

Після запуску стежте за чотирма речами:

• звіт «Сторінки» в Search Console — помилки 404 і сторінки, виключені з індексу;
• кліки за сторінками порівняно з вивантаженням, збереженим до переїзду;
• позиції за головними запитами, раз на тиждень протягом першого місяця-двох;
• помилки 404 у логах сервера — туди потрапляють адреси, яких не знайшов жоден краулер.

Чекліст перед запуском

Пройдіть його на тестовій копії, коли перенесення даних завершено.

Дані

• [ ] Кількість товарів, варіацій, покупців і замовлень збігається зі старим сайтом (з урахуванням свідомо виключеного).
• [ ] У варіацій правильні ціни та залишки, фото на місці.
• [ ] Вхід в особистий кабінет працює зі старими паролями для кожного з трьох форматів хешів.
• [ ] В особистому кабінеті видно старі замовлення з вихідними датами та номерами.
• [ ] Дублі e-mail об’єднані, замовлення прив’язані до потрібних облікових записів.
• [ ] Замовлення, реєстрації та залишки зі старого сайту за час робіт дозавантажені.

Магазин

• [ ] Тестове замовлення проходить повністю: кошик, оформлення, оплата, лист покупцеві та менеджеру.
• [ ] Обмін з обліковою системою відпрацював хоча б один повний цикл.
• [ ] Розрахунок доставки та вивантаження на маркетплейси працюють.
• [ ] Листи із сайту доходять і не потрапляють у спам.
• [ ] Каталог і картки відкриваються не повільніше, ніж на старому сайті (причини розібрано в статті «Чому гальмує WooCommerce»).

SEO

• [ ] Кожен URL з аудиту віддає 200, 301 на кінцеву адресу, 404 або 410, без ланцюжків.
• [ ] Title, description, H1 перенесені, canonical вказує на саму сторінку.
• [ ] noindex знято, robots.txt не закриває каталог.
• [ ] Новий sitemap готовий до надсилання в Search Console.
• [ ] Вивантаження кліків і показів із Search Console до переїзду збережено.

Відкат

• [ ] Свіжі резервні копії старого сайту та бази є; старий сервер не вимикають, поки новий не пропрацював без збоїв.

Як із переїздом допомагає RIVERIT

Пропонуємо перенесення сайтів та інтернет-магазинів з Бітрікс на WordPress. Переносимо практично будь-які дані, зокрема покупців та історію замовлень; те, що не вивантажується стандартними засобами, переносимо скриптами. Переїзди з Бітрікс на WooCommerce ми вже робили, приклади перенесення з Бітрікс на WordPress зібрані в наших кейсах. Після запуску беремо магазин на техпідтримку WordPress: технічне SEO (sitemap, robots, редиректи, помилки індексації), оновлення, резервні копії, моніторинг сайту, реакція на звернення — до 1 години.