Товары при переносе интернет-магазина с Битрикс на 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.
Там же сохраните отчёт «Ссылки» — список сайтов, которые ссылаются на ваш. Эти адреса проверьте в карте редиректов в первую очередь, а после переезда попросите владельцев самых ценных сайтов заменить ссылки на новые.
Что сайт делает, кроме витрины
Выпишите все функции сайта: обмен с учётной системой, онлайн-оплата, расчёт доставки, выгрузки на маркетплейсы и прайс-агрегаторы, письма покупателям, личный кабинет, скидки и купоны, формы заявок. По каждой решите: переносим как есть, меняем или отказываемся. Отказаться от функции, которой никто не пользуется, проще всего сейчас.
Что и чем переносится
| Данные | Способ переноса | На что смотреть |
|---|---|---|
| Разделы, товары, характеристики, цены, остатки | CSV-импорт WooCommerce или скрипт | какие свойства станут атрибутами для фильтра |
| Торговые предложения (размер, цвет) | CSV-импорт как вариации или скрипт | у каждой вариации свой артикул, цена, остаток |
| Изображения и файлы | загрузка по URL или копирование файлов | alt-тексты стандартный импорт не переносит |
| Статьи, новости, страницы | скрипт или вручную | даты публикации, ссылки внутри текстов |
| Покупатели и пароли | только скриптом | дубли e-mail, форматы хешей паролей |
| История заказов | только скриптом | даты, статусы, связь с покупателем |
| Title, description, H1 | скрипт в поля SEO-плагина | каждая страница из индекса |
Структура магазина на 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) хеши бывают трёх видов. Какой лежит у конкретного покупателя, зависит от версии Битрикс и настроек сервера на момент сохранения пароля:
- Современный формат SHA-512: строка начинается с
$6$, длина около 106 символов. - Старый формат: соль плюс MD5 от соли и пароля.
- Совсем старый формат: 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 часа.













