Перенос базы товаров с Битрикс на самописную

Коротко: Перенос товаров с Bitrix на самописную платформу требует глубокого аудита структуры данных и маппинга атрибутов. Чтобы избежать потери SEO-трафика и разрыва связей, необходимо сохранить URL-адреса, настроить 301-редиректы и использовать кастомные скрипты для миграции вместо стандартного экспорта. Главный риск - нарушение целостности данных при несовпадении схем баз данных.

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов и приложений под ключ. Если нужна помощь - напишите нам.

Аудит текущей структуры данных в Bitrix

Прежде чем писать скрипт миграции, нужно понять, в каком состоянии находится база в 1С-Битрикс. Это не просто список товаров, а сложная иерархия, где данные разбросаны по множеству таблиц. В стандартной архитектуре Bitrix информация о товаре может храниться в разных местах: свойства (Highload-блоки или Iblock) отдельно, цены (Price) отдельно, остатки (Stock) могут подтягиваться из внешней 1С. Если вы планируете переезд на самописную систему, важно понять, как именно эти данные связаны между собой.

Одной из критических точек является модуль documentgenerator (версия 26.200.100 на текущий момент) и модуль form (версия 26.0.0). Если ваши товарные характеристики или дополнительные документы привязаны к этим модулям, их структура может отличаться от классических свойств инфоблока. Нужно выгрузить структуру не только самих товаров, но и всех связей. Например, если у вас есть сложные связи между товаром и его характеристиками (размер, цвет, материал), важно зафиксировать, как они реализованы: через стандартные свойства или через отдельные таблицы.

Проведите ревизию "мусорных" данных. За годы работы в Bitrix в базе часто копятся дубли, товары без артикулов, пустые описания или некорректные категории. Переносить этот хаос на новую платформу - плохая стратегия. Лучше очистить базу на этапе аудита, чем потом тратить бюджет на исправление ошибок в новой системе. Составьте реестр всех существующих типов данных: названия полей, их типы (строка, число, массив, привязка к элементу) и обязательность заполнения.

Важный нюанс - проверка связей. Проверьте, не зависят ли товары от сложных условий отображения, которые прописаны в логике шаблонов Bitrix. Если на старом сайте товар показывается только при наличии определенного свойства, в новой системе этот механизм должен быть реализован аналогично, иначе часть ассортимента просто "исчезнет" для покупателя после переезда.

Подготовка схемы базы данных для новой платформы

Самописная платформа дает свободу, но и накладывает на разработчика полную ответственность за архитектуру. Если в Bitrix вы работали с готовыми инфоблоками, то здесь вам придется проектировать таблицы с нуля. Не пытайтесь просто скопировать структуру Bitrix. Архитектура Bitrix избыточна для многих задач, и попытка воссоздать её "один в один" приведет к переусложненной базе, которая будет тормозить при росте нагрузки.

При проектировании новой схемы базы данных учитывайте масштабируемость. Если у вас 10 000 товаров - это одна задача, если 500 000 - совсем другая. Рекомендуется разделять статические данные (название, артикул, описание) и динамические (остатки, цены, скидки). Динамические данные должны обновляться максимально быстро, поэтому их лучше держать в отдельных таблицах, чтобы не перегружать основную базу при каждом обновлении цен через API.

Рассмотрите вопрос нормализации данных. В Bitrix свойства часто хранятся в "плоском" виде или в EAV-модели (Entity-Attribute-Value), что удобно для гибкости, но крайне медленно при сложных выборках. Для самописной системы лучше использовать более структурированный подход. Например, если у вас есть фиксированный набор характеристик для всех товаров, создайте под них отдельные колонки. Если характеристики всегда разные - используйте JSON-поля (если ваша БД это поддерживает, например, PostgreSQL), это даст баланс между гибкостью и скоростью.

Не забудьте про индексы. При проектировании схемы сразу определите, по каким полям будет идти поиск и фильтрация. Обычно это артикул, ID производителя, категория и основные характеристики. Без правильно настроенных индексов даже самая быстрая самописная платформа начнет "лежать" при попытке пользователя отфильтровать товары по цвету и размеру одновременно.

Методы экспорта: XML, JSON или прямой SQL-запрос

Выбор метода экспорта зависит от объема данных и квалификации команды. Есть три основных пути, и у каждого свои подводные камни.

Первый и самый простой - это экспорт через стандартные средства Bitrix в форматы XML или JSON. Это удобно, если вам нужно быстро выгрузить небольшую часть каталога или если вы используете готовые коннекторы. JSON предпочтительнее для современных веб-приложений, так как он нативен для JavaScript и легко парсится. Однако стандартный экспорт Bitrix часто "режет" сложные связи и не выгружает специфические настройки свойств, которые вы настраивали кастомно.

Второй метод - прямой SQL-запрос к базе данных MySQL. Это самый быстрый и полный способ. Вы можете выгрузить данные напрямую из таблиц `b_iblock_element`, `b_iblock_property` и так далее. Это позволяет вытащить всё: от скрытых системных полей до связей с другими модулями. Но здесь есть риск: если вы не знаете структуру таблиц Bitrix (а она довольно запутанная), можно случайно выгрузить "битые" данные или нарушить логику связей. Плюс, прямой доступ к базе требует осторожности, чтобы не создать нагрузку на работающий сайт в момент выгрузки.

Сравнение методов:

Третий путь - использование API. Это наиболее "чистый" способ с точки зрения логики, так как вы получаете данные так, как их видит сама система. Но при объеме в сотни тысяч товаров этот метод будет крайне медленным. Оптимальная стратегия - комбинирование: использовать API для проверки данных и SQL для массовой выгрузки тяжелых блоков (например, описаний или контента).

Как сохранить SEO-ссылки и метатеги при переезде

SEO - это то, ради чего часто и происходит переезд. Если вы просто перенесете товары, но у товаров изменятся URL-адреса (ЧПУ), вы потеряете позиции в поисковой выдаче. Поисковые роботы придут на старые адреса, получат 404 ошибку, и ваш трафик обвалится. Для сохранения позиций необходимо реализовать механизм редиректов.

Главное правило: старый URL должен перенаправлять на новый. Это делается с помощью 301-го редиректа (Permanent Redirect). Вам нужно составить карту соответствий (Mapping Table): "старый URL" -> "новый URL". Эту таблицу нужно составить еще на этапе аудита Bitrix. Важно учитывать не только URL самого товара, но и структуру категорий, если она изменилась.

Метатеги (Title, Description, H1) и контент должны переноситься без изменений. В Bitrix они могут храниться в свойствах инфоблока. Убедитесь, что при переносе кодировка не "поплывет" и спецсимволы не превратились в непонятные наборы знаков. Если вы используете дополнительные модули для SEO (например, Open Graph для соцсетей), их данные также нужно выгрузить отдельно.

Что касается изображений, важно не просто перенести файлы, но и сохранить их связи с товарами. Если вы планируете сменить формат изображений (например, с тяжелых PNG на WebP для ускорения сайта), это нужно делать на этапе импорта в новую базу. Не забудьте про Alt-теги у картинок - они критически важны для SEO изображений в Google и Яндекс.

Сопоставление атрибутов и обработка сложных связей

Это самый трудоемкий этап миграции. В Bitrix свойства могут называться "Цвет", а в вашей новой системе поле может называться `color_id`. Вам нужно создать таблицу маппинга (сопоставления), где указано, какое поле из старой базы в какое поле новой базы должно попасть.

Сложность заключается в типах данных. Например, в Bitrix свойство может быть "списком", где значением является ID элемента, а в вашей системе это может быть просто строковое значение или ссылка на другую таблицу. Если вы не учтете это при переносе, вы получите "битые" связи: товар будет числиться за цветом, которого не существует в новой базе.

Особое внимание уделите связям "многие-ко-многим". Например, когда один товар может относиться к нескольким брендам или категориям. В SQL-структуре Bitrix это часто реализуется через промежуточные таблицы. При переносе на самописную платформу вам нужно будет преобразовать эти записи в соответствующий формат вашей новой архитектуры. Если вы пропустите этот шаг, товар может "зависнуть" без категории, и он исчезнет из фильтров на сайте.

Пример из практики: у вас есть товар с характеристиками "Материал: хлопок, полиэстер". В Bitrix это может быть одно текстовое поле. В новой системе вы хотите сделать это отдельными чекбоксами для фильтрации. В этом случае при переносе вам придется написать скрипт, который будет парсить строку, разбивать ее по разделителю (запятая) и записывать в новую таблицу связей. Это требует глубокого понимания того, как данные были введены изначально.

Автоматизация миграции с помощью кастомных скриптов

Ручной перенос товаров невозможен, если у вас в каталоге больше пары сотен позиций. Вам потребуются кастомные скрипты, написанные на Python или PHP. Процесс должен быть разбит на этапы: Экспорт -> Трансформация -> Загрузка.

Этап трансформации (ETL - Extract, Transform, Load) является ключевым. Скрипт должен не просто перекладывать данные, а "лечить" их. Например, если в Bitrix цена была записана как строка с символом валюты "р.", скрипт должен превратить ее в число (integer/decimal) для новой базы. Если в поле "Артикул" есть лишние пробелы, скрипт должен их обрезать.

Используйте логирование на каждом этапе. Если скрипт встретит товар с некорректными данными, он не должен "падать". Он должен записать ошибку в лог-файл и продолжить работу с остальными товарами. После завершения работы у вас должен получиться отчет: "Перенесено 10 000 товаров, 50 товаров с ошибками (см. лог), 2 товара пропущены". Это позволит вам точечно исправить проблемные позиции вручную, не переделывая весь процесс.

Для ускорения процесса миграции на больших объемах используйте пакетную вставку (Bulk Insert). Вместо того чтобы отправлять по одному SQL-запросу на каждый товар, скрипт должен формировать пакеты по 500-1000 записей и отправлять их одним запросом. Это сокращает время миграции в десятки раз.

Типичные ошибки и как избежать потери контента

Ошибки на этапе миграции стоят очень дорого. Вот основные группы проблем, с которыми сталкиваются компании:

1. Потеря иерархии категорий. Часто при экспорте товары выгружаются "плоским" списком, и связь с родительской категорией теряется. В итоге на новом сайте все товары оказываются в папке "Без категории". Всегда проверяйте целостность дерева категорий до начала массовой загрузки товаров.

2. Проблема с кодировками и спецсимволами. Если база Bitrix работала в одной кодировке, а новая база настроена иначе, вы получите "кракозябры" вместо названий товаров. Это убьет SEO и сделает сайт нечитаемым. Проверяйте кодировку (UTF-8) на обоих концах процесса.

3. Дублирование контента. Если в процессе миграции скрипт сработал дважды или в базе Bitrix были дубли, вы можете получить на новом сайте идентичные товары. Это негативно сказывается на SEO. На этапе загрузки добавьте проверку на уникальность по артикулу или SKU.

4. Потеря медиа-файлов. Часто разработчики переносят текстовые данные, но забывают про физические файлы изображений. В итоге в базе ссылки есть, а картинки не отображаются. Сначала переносите медиа-библиотеку, и только потом - связи товаров с этими картинками.

Чтобы избежать этих проблем, всегда делайте тестовый перенос на "песочнице" (staging-сервере). Никогда не запускайте основной скрипт миграции сразу на "боевом" сервере, даже если вы уверены в своем коде.

Тестирование целостности данных после переноса

После того как скрипты отработали, наступает этап верификации. Нельзя просто посмотреть на страницу товара и сказать: "Да, всё ок". Тестирование должно быть системным. Сначала проверяется количественный показатель: сколько товаров было в Bitrix и сколько стало в новой системе. Разница должна быть объяснима только теми товарами, которые были помечены как "мусор" или "невалидные".

Затем проводится проверка типов данных. Нужно убедиться, что цены остались числами, даты - датами, а не строками. Проверяйте наличие обязательных атрибутов. Если у вас в новой системе товар не может существовать без атрибута "Бренд", убедитесь, что после переноса все товары имеют этот атрибут.

Важный этап - функциональное тестирование. Проверьте работу фильтров. Выберите в интерфейсе сайта "Черный" цвет и "Размер XL" - если товаров не появилось или их количество не совпадает с ожидаемым (на основе выгрузки из старой базы), значит, связь атрибутов нарушена.

Финальный шаг - проверка SEO-соответствия. Проверьте несколько случайных URL-адресов на наличие 301-х редиректов. Убедитесь, что метатеги (Title, Description) на страницах товаров в новой системе в точности соответствуют старым. Только после прохождения всех этих проверок можно считать миграцию успешно завершенной и переключать трафик на новый сайт.

Что запомнить:

• Всегда делайте аудит структуры данных и связей в Bitrix до начала разработки новой схемы.
• Сохраняйте SEO-трафик через 301-е редиректы и сохранение URL.
• Используйте комбинированный подход (SQL + API) для максимально полного экспорта.
• Автоматизируйте процесс через ETL-скрипты с обязательным логированием ошибок.
• Проводите многоэтапное тестирование: количественное, структурное и функциональное.