Перенос WordPress на Битрикс: карта данных, адреса и приёмка

Перенос WordPress на Битрикс — это проект миграции контента, структуры адресов и редакционных процессов с одной системы управления сайтом на другую, а не «переустановка движка». Работу ведут по карте переноса данных: сначала фиксируют, что именно переезжает и что при этом теряется, затем переносят на копию, сверяют адреса и содержимое и только после этого переключают рабочий сайт.

Задача бизнеса и границы переноса

Перенос WordPress на Битрикс начинают не с выбора инструментов, а с формулировки причины. Пока причина не названа, невозможно понять, что считать успехом, а что — недоработкой. Причины бывают разными: необходимость связать сайт с учётными системами компании, требование единой административной панели для нескольких ресурсов, ограничения по сопровождению, планы по развитию каталога и личного кабинета. Мы не оцениваем, какая система «лучше»: у каждой есть свои сильные стороны, и выбор диктуется задачами бизнеса, а не сравнением продуктов.

Границы проекта удобно зафиксировать письменно, до старта. В типовом случае внутрь попадают: текстовый контент, структура разделов, адреса страниц, медиафайлы, меню, формы обратной связи, метаданные страниц и правила перенаправления. За границы обычно выносят полную переработку дизайна, новые интеграции, изменение логики каталога, пересборку личного кабинета. Если что-то из этого нужно, это отдельная задача со своим планом, а не «заодно» в миграции.

Ответственные распределяются так. Заказчик отвечает за смысловое содержание и приёмку: он подтверждает, что тексты, разделы и правила работы редакции сохранены. Исполнитель отвечает за техническую часть: перенос данных, настройку адресов, проверку работоспособности. Редактор или контент-менеджер проверяет, что материалы открываются и редактируются так, как ожидалось. Специалист по инфраструктуре отвечает за копии, доступы и переключение.

Наблюдаемый результат миграции описывается просто: сайт открывается по привычным адресам, содержимое на месте, редакция может работать, старые адреса ведут на новые страницы. Это и есть предмет приёмки. Отдельно стоит проговорить ограничение: сам перенос не улучшает позиции в поиске и не даёт роста трафика. Он лишь сохраняет то, что было, в новой среде. Всё, что касается развития, — отдельные работы.

Что именно переносим: карта переноса данных

Карта переноса данных — главный рабочий документ проекта. Это таблица, где для каждого типа объекта указано: откуда берём, куда кладём, что переносим полностью, что переносим частично, что не переносим и кто проверяет результат. Без такой карты миграция превращается в набор догадок, а приёмка — в спор о том, «должно ли это было переехать».

Заполняют карту до начала работ, на основе инвентаризации исходного сайта. Инвентаризация — это не «посмотреть меню», а пройти по всем типам записей, разделам, файлам и настройкам и выписать их в список. Полезно сразу отмечать, какие объекты созданы вручную, а какие формируются автоматически: автоматически созданные сущности часто не нужно переносить как контент, их достаточно воспроизвести настройками.

Отдельная колонка «что не переносим» не менее важна, чем «что переносим». В неё попадают, например, черновики, тестовые записи, устаревшие дубли, служебные страницы, которые больше не нужны. Решение по каждому такому объекту фиксирует заказчик: удалить, оставить как есть или перенести. Молчаливое удаление контента — одна из самых частых причин конфликтов на приёмке.

Как устроен перенос WordPress на Битрикс: этапы

Перенос WordPress на Битрикс удобно разбить на последовательные этапы, у каждого из которых есть входные данные и проверяемый результат. Этапы не стоит совмещать: пока не закрыт предыдущий, следующий опирается на неподтверждённые данные.

Инвентаризация и рабочая копия

На этом шаге собирают полный перечень объектов и делают копию исходного сайта. Копия нужна, чтобы работать с данными, не затрагивая рабочий ресурс. Параллельно фиксируют текущее состояние: какие адреса существуют, какие страницы открываются, какие формы работают. Это «слепок», с которым потом сравнивают результат. Про резервное копирование и правила хранения копий подробно написано в материале Резервное копирование сайта на Битрикс.

Подготовка площадки

Готовят среду, в которую будет перенесён сайт: отдельный адрес для тестовой версии, доступы, базовые настройки. Важно, чтобы тестовая площадка была закрыта от индексации и от случайных посетителей. Доступы и роли описываются заранее — кому что нужно для работы, — чтобы не выдавать лишних прав. Общие принципы работы с доступами и настройками разобраны в статье Администрирование сайта на Битрикс.

Перенос контента

Контент переносят по карте: сначала структуру разделов, затем материалы, затем медиафайлы и метаданные. Порядок важен, потому что материалы привязываются к разделам, а изображения — к материалам. Если переносить в обратном порядке, часть связей придётся восстанавливать вручную.

Адреса и перенаправления

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

Проверка и переключение

Финальный этап — сверка тестовой версии с исходным «слепком», исправление расхождений и переключение рабочего сайта. Переключение делают в согласованное время, с планом возврата: если что-то пойдёт не так, должна быть возможность вернуться к прежнему состоянию. После переключения сайт наблюдают: проверяют доступность, формы, адреса, работу редакции.

Соответствие адресов и редакционные процессы

Адреса — самая чувствительная часть миграции. Если страница переехала, а её адрес изменился без перенаправления, посетитель увидит ошибку, а накопленные внешние ссылки будут вести в никуда. Поэтому для каждого значимого адреса заводят пару «старый → новый» и проверяют её. Адреса, которые не меняются, тоже попадают в список — их проверяют на доступность.

Практический приём: список адресов выгружают из исходного сайта и прогоняют по нему проверку на тестовой версии. Так видно, какие адреса отвечают корректно, какие отдают ошибку, а какие ведут на промежуточную страницу. Цепочки перенаправлений (когда адрес ведёт на адрес, который снова перенаправляет) нежелательны: их лучше схлопывать в один переход.

Редакционные процессы меняются вместе с системой. Нужно заранее ответить на вопросы: кто создаёт страницы, кто публикует, кто отвечает за разделы, как выглядит путь материала от черновика до публикации. Если в старой системе была своя логика ролей, её переносят осмысленно, а не копируют один в один. Иногда проще упростить схему прав, чем воспроизводить исторически сложную.

Отдельно стоит договориться о правилах оформления: как называются разделы, как формируются заголовки, где хранятся изображения, какие поля обязательны. Эти договорённости фиксируют короткой инструкцией для редакции. Инструкция — часть результата проекта, потому что без неё люди возвращаются к старым привычкам и создают беспорядок в новой структуре.

Учебный пример: перенос каталога и блога на тестовых данных

Учебный пример. Данные условные и приведены только для иллюстрации порядка действий.

Входные условия. Условная компания «Ромашка» ведёт сайт на WordPress: 120 страниц, 340 записей блога, 6 рубрик, около 900 изображений, три формы обратной связи, меню из 24 пунктов. Причина переезда — необходимость связать сайт с внутренними учётными системами компании. Дизайн решено сохранить, новые разделы не добавлять.

Шаг 1. Инвентаризация. Составляют карту переноса данных: выписывают все страницы, записи, рубрики, файлы, формы и пункты меню. Отдельно отмечают 18 черновиков и 40 устаревших записей — заказчик решает их не переносить.

Шаг 2. Копия и тестовая площадка. Делают копию исходного сайта и разворачивают тестовую версию на отдельном адресе, закрытом от посетителей. Фиксируют «слепок»: список адресов и перечень работающих форм.

Шаг 3. Перенос. Сначала создают структуру разделов, затем переносят страницы, записи блога, изображения и метаданные. Рубрики и метки восстанавливают по карте. Меню собирают заново по списку пунктов.

Шаг 4. Адреса. Структуру адресов решено сохранить. По списку из «слепка» проверяют каждую страницу: открывается ли она, совпадает ли содержимое. Для 12 адресов, которые всё же изменились из-за переименования разделов, настраивают перенаправления.

Шаг 5. Проверка. Редактор проходит по разделам и сверяет тексты, даты и рубрики. Исполнитель проверяет изображения, формы и метаданные. Заказчик подтверждает, что черновики и устаревшие записи не перенесены.

Шаг 6. Переключение. Работы выполняют в согласованное время, с планом возврата. После переключения проверяют доступность сайта, работу форм и адресов, вход в административную панель.

Проверка результата. Сравнивают тестовую версию со «слепком»: все адреса из списка отвечают корректно, содержимое совпадает, формы доставляют письма, редакция может войти и отредактировать материал. Расхождения из списка исправлений закрыты. Только после этого проект считают завершённым.

Как проверить результат и принять работу

Приёмка опирается на карту переноса данных и «слепок», а не на общее впечатление. Проверку удобно вести по группам объектов, фиксируя результат по каждой.

Содержимое. Сверяют тексты страниц и записей, даты, авторов, привязку к рубрикам. Проверяют, что не появилось пустых материалов и дублей. Отдельно смотрят, что удалённые по решению заказчика объекты действительно отсутствуют.

Адреса. Проходят по списку адресов и убеждаются, что каждый отвечает корректно. Проверяют перенаправления: они ведут на нужные страницы и не образуют цепочек. Смотрят, что тестовая версия закрыта от индексации, а рабочие адреса доступны.

Медиафайлы. Проверяют, что изображения и документы открываются, отображаются в нужном размере и не потеряли подписи. Отдельно смотрят материалы с большим числом изображений — там потери заметнее всего.

Формы и уведомления. Отправляют тестовые заявки и убеждаются, что письма приходят нужным получателям, а данные сохраняются. Проверяют, что в форме нет лишних или пропавших полей.

Доступы и редакция. Проверяют, что учётные записи созданы только для нужных людей, права соответствуют ролям, а редактор может выполнить обычный цикл: создать материал, отредактировать, опубликовать.

Если по какому-то пункту есть расхождение, его вносят в список исправлений с ответственным и повторяют проверку после устранения. Приёмка считается завершённой, когда список пуст, а не когда «в целом всё хорошо».

Типичные ошибки и ограничения

Ошибка первая — начинать перенос без карты данных. В этом случае часть объектов теряется, а споры на приёмке идут о том, что вообще должно было переехать.

Ошибка вторая — работать сразу на рабочем сайте. Любое изменение без копии и тестовой площадки повышает риск потерять данные и усложняет возврат к прежнему состоянию.

Ошибка третья — менять адреса без перенаправлений. Даже аккуратный перенос контента не спасает, если старые адреса перестают отвечать.

Ошибка четвёртая — переносить всё подряд, включая черновики, дубли и устаревшие материалы. Это раздувает структуру и усложняет работу редакции.

Ошибка пятая — не проверять формы и уведомления. Форма может выглядеть рабочей, но письма не доходить до получателя.

Ошибка шестая — забыть про инструкцию для редакции. Без неё люди работают по старым привычкам и быстро создают беспорядок в новой структуре.

Ограничения тоже стоит назвать честно. Перенос не улучшает позиции в поиске и не увеличивает трафик сам по себе. Он не заменяет аудит и не исправляет накопленные проблемы исходного сайта — их можно решить отдельно, например в рамках Аудит сайта на Битрикс. Перенос не добавляет новых функций: если нужны интеграции или новый каталог, это отдельные работы. И наконец, перенос не отменяет необходимости в дальнейшем сопровождении сайта.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, исполнителю нужен набор сведений. Чем полнее данные, тем точнее оценка и тем меньше сюрпризов в процессе.

• Перечень типов объектов: страницы, записи, рубрики, метки, медиафайлы, формы, меню.
• Количество объектов по каждому типу.
• Список адресов или возможность выгрузить его из исходного сайта.
• Описание текущей структуры разделов и правил вложенности.
• Сведения о формах: какие поля, куда уходят заявки, кто получатель.
• Перечень учётных записей и ролей редакции.
• Решение по спорным объектам: что переносим, что удаляем.
• Требования к срокам и окну переключения.
• Сведения о том, какие внешние системы должны быть связаны с сайтом после переезда.
• Контакт ответственного за приёмку со стороны заказчика.

Если каких-то данных нет, это не блокирует старт, но оценка будет приблизительной. Лучше потратить время на инвентаризацию, чем переделывать перенос.

Таблица принятия решения

Таблица помогает договориться по спорным ситуациям до начала работ.

Чек-лист перед переключением

• Карта переноса данных заполнена и согласована с заказчиком.
• Сделана копия исходного сайта и зафиксирован «слепок» адресов.
• Тестовая площадка закрыта от индексации и посторонних посетителей.
• Контент перенесён и сверен по всем типам объектов из карты.
• Медиафайлы открываются и отображаются корректно.
• Список адресов проверен, перенаправления настроены и не образуют цепочек.
• Формы отправляют тестовые заявки нужным получателям.
• Учётные записи и права редакции соответствуют ролям.
• Редактор прошёл обычный цикл: создание, редактирование, публикация.
• Подготовлена короткая инструкция для редакции.
• Согласовано время переключения и описан план возврата.
• После переключения проверены доступность сайта, формы и адреса.

Вопросы и ответы

Если проект затрагивает не только перенос, но и развитие сайта на новой системе, эти работы планируют отдельно — например, в рамках разработка сайтов на Битрикс.