Перенос сайта на WordPress с другой CMS под ключ

Перенос сайта на WordPress с другой CMS начинается не с установки темы и не с кнопки «Импорт». Сначала нужно понять, что именно хранит текущий сайт, какие URL уже индексируются, какие формы отправляют заявки, где находятся изображения, что связано с CRM, оплатой, аналитикой и другими внешними сервисами.

Если просто скопировать тексты и картинки, новый сайт может выглядеть нормально, но потерять важные связи: старые адреса страниц начнут отдавать 404, формы перестанут передавать заявки, часть метаданных исчезнет, а нестандартные сущности из старой CMS окажутся обычным текстом.

Поэтому в A.S Groups я рассматриваю миграцию как отдельный технический проект: сначала инвентаризация и карта переноса, затем новая структура WordPress, импорт данных, проверка URL и интеграций, тестовый запуск и только после этого переключение рабочего сайта.

Когда перенос на WordPress действительно имеет смысл

Менять CMS только потому, что разработчику привычнее WordPress, неправильно. Если текущая система стабильно решает задачи бизнеса, поддерживается командой и не мешает развитию, миграция может создать больше расходов, чем пользы.

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

Типичные причины рассмотреть миграцию

редактору сложно самостоятельно менять страницы и материалы;
старый шаблон или модули мешают адаптиву и обновлению дизайна;
поддержка CMS или конкретных расширений стала проблемной;
нужны новые формы, CRM, API, личный кабинет или автоматизация;
структура контента уже не соответствует тому, как развивается бизнес;
для каждой небольшой доработки приходится разбираться в закрытой или сильно кастомизированной системе.

Я сам когда-то начинал с DLE, позже работал с другими движками и постепенно перешёл на WordPress. Эту личную сторону вопроса я отдельно описывал в статье почему я так и не полюбил OpenCart, Bitrix и Joomla после WordPress. Но в клиентской миграции личные предпочтения вторичны: сначала нужно доказать, что новая архитектура действительно решает задачу.

Что нужно перенести кроме страниц

Список зависит от исходной CMS. На небольшом корпоративном сайте это могут быть страницы, статьи, рубрики и изображения. На крупном проекте появляются пользовательские типы данных, документы, авторы, фильтры, связи между сущностями, формы, SEO-поля и интеграции.

Что проверяем	Что может потребоваться в WordPress
Страницы и статьи	Pages, Posts или собственные post types
Рубрики и разделы	Categories или custom taxonomies
Дополнительные поля	ACF, Carbon Fields или собственная модель данных
Изображения и файлы	Media Library с корректными ссылками
Формы	Новая реализация и повторное подключение обработчиков
SEO-данные	title, description, canonical, redirects, schema при необходимости
Интеграции	API, webhooks, CRM, платёжные и другие сервисы

WordPress умеет импортировать данные из ряда систем через раздел Tools → Import. Официальная документация перечисляет, например, импорт для Blogger, LiveJournal, Movable Type/TypePad, RSS, Tumblr и WordPress. Но Bitrix, Joomla, OpenCart, DLE и многие кастомные CMS нельзя считать универсальным сценарием «один файл — одна кнопка». Там часто нужен промежуточный экспорт, API или собственный скрипт преобразования данных.

Сначала инвентаризация, потом код

Перед переносом я фиксирую текущую структуру сайта. Нужен список индексируемых URL, типов контента, меню, форм, внешних интеграций, файлов и важных шаблонов. Если сайт большой, полезно отдельно составить таблицу соответствий: старый URL, новая сущность WordPress, новый URL, редирект и статус проверки.

Это помогает не обнаруживать уже после запуска, что старый раздел документов существовал в отдельном модуле, а половина ссылок из поиска ведёт на адреса, которые никто не включил в план.

Новая модель данных должна быть понятной

Одна из ошибок миграции — буквально копировать архитектуру старой CMS в WordPress. Если в старой системе всё хранилось в одном огромном типе материала с десятками условных полей, необязательно повторять эту конструкцию.

В WordPress можно отдельно определить страницы, записи, товары, проекты, услуги, сотрудников, объекты или документы. Для связанной информации используются таксономии и дополнительные поля. Цель — чтобы после миграции администратор понимал, где редактировать данные, а разработчику не приходилось каждый раз распутывать структуру старой системы.

Если нужна разработка такой структуры с нуля, это уже часть услуги WordPress-разработки A.S Groups, а не механический импорт.

Как перенести URL и снизить SEO-риски

При смене CMS поисковой системе всё равно, какой движок стоит в админке. Для неё важны доступность страниц, содержимое, внутренние ссылки, canonical, статус-коды, sitemap и другие сигналы.

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

Фраза «перенос без потери SEO» звучит красиво, но обещать неизменные позиции было бы неправильно: выдача зависит не только от миграции. Реальная задача разработчика — контролировать технические риски: не создавать массовые 404, не закрыть нужные страницы от индексации, не потерять metadata, не сломать canonical и не оставить старые внутренние ссылки.

SEO-проверка перед запуском

собрать список старых важных URL;
сохранить адреса или подготовить карту 301-редиректов;
перенести или заново настроить title и description;
проверить canonical и robots directives;
обновить XML sitemap;
проверить внутренние ссылки;
убедиться, что тестовый домен или staging не попал в индекс;
после запуска контролировать 404 и ответы сервера.

Изображения нельзя просто оставить на старом домене

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

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

Формы и интеграции обычно приходится пересобирать

Контактная форма в Bitrix или Joomla не переносится в WordPress как самостоятельная рабочая сущность. Даже если внешний вид повторить быстро, за формой может стоять отправка писем, CRM, Telegram, webhook, аналитическая цель, защита от спама и логирование.

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

Bitrix → WordPress

В Bitrix проект может сильно зависеть от компонентов, инфоблоков и конкретной структуры шаблона. Поэтому сначала нужно понять, какие данные являются контентом, а какие существуют только как часть компонента. Инфоблоки часто логично преобразовать в post types, taxonomies и поля WordPress, но соответствие проектируется под конкретный сайт.

Joomla → WordPress

При переносе Joomla важно разобрать категории, материалы, меню, модули и расширения. Часть контента можно преобразовать автоматически, но нестандартные компоненты и поля требуют отдельной карты. Особенно внимательно нужно проверять URL: структура маршрутов у двух CMS различается.

OpenCart → WordPress

Если OpenCart используется как интернет-магазин, речь обычно уже не просто о WordPress, а о WooCommerce. Тогда появляются товары, варианты, категории, характеристики, клиенты, заказы, способы оплаты и доставки. Такой перенос нужно планировать отдельно от обычной миграции корпоративного сайта.

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

DLE → WordPress

В DLE многое зависит от структуры шаблонов, дополнительных полей и того, насколько проект был доработан вручную. На старых сайтах встречается логика, которая существует не как отдельный модуль, а прямо внутри шаблонов. Перед миграцией её нужно найти и решить, должна ли она вообще повторяться в новом WordPress.

Почему я предпочитаю сначала сделать тестовый перенос

Переключать рабочий домен сразу после первого импорта рискованно. На staging-версии можно проверить выборку материалов, медиа, URL, адаптив, формы и интеграции, не затрагивая посетителей.

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

Как может выглядеть технический процесс

Аудит. Снимаем структуру исходного сайта, URL и интеграции.
Проектирование. Определяем post types, taxonomies, поля и шаблоны WordPress.
Тестовый импорт. Переносим часть данных и проверяем преобразование.
Миграционный скрипт. Автоматизируем повторяемые операции там, где это оправдано.
SEO-карта. Фиксируем сохранённые URL и редиректы.
Интеграции. Восстанавливаем формы, CRM, API и внешние сервисы.
QA. Проверяем страницы, медиа, мобильную версию и основные сценарии.
Финальная синхронизация. Переносим изменения, появившиеся после тестовой копии.
Запуск. Переключаем сайт и проверяем ответы сервера и ключевые URL.

Можно ли использовать стандартный WordPress Import

Да, если источник поддерживается и его данные соответствуют возможностям импортера. WordPress официально описывает импорт записей, комментариев, custom fields, страниц и категорий из WXR для другого WordPress-сайта, а также несколько импортёров для сторонних платформ.

В обратную сторону WordPress Export формирует WXR/XML и может включать posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies и users. Это удобно именно для WordPress → WordPress. При миграции из совершенно другой CMS сначала нужно получить данные из её собственного формата и привести их к новой модели.

Сколько стоит перенос сайта на WordPress

Фиксированная цена без просмотра исходного проекта мало что говорит. Два сайта с одинаковыми десятью страницами могут отличаться в разы: у одного только тексты и изображения, у второго — формы, каталог, личный кабинет, API и сотни старых URL.

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

Что я могу сделать в A.S Groups

Могу разобрать существующий сайт на Bitrix, Joomla, OpenCart, DLE, самописной CMS или другой системе и подготовить план перехода на WordPress: что переносится автоматически, что нужно пересобрать, какие URL сохранить и какие интеграции восстановить.

Если миграция оправдана, собираю целевую структуру WordPress, переношу данные, настраиваю редиректы, формы и необходимые интеграции, а перед запуском проверяю тестовую версию. Если после аудита окажется, что дешевле и безопаснее доработать текущую CMS, перенос не должен становиться самоцелью.

Официальные материалы WordPress

Частые вопросы

Можно ли перенести сайт на WordPress полностью автоматически?

Иногда значительную часть контента можно импортировать автоматически, но нестандартные поля, модули, формы, интеграции и URL часто требуют отдельной логики. Сначала нужно посмотреть исходную CMS и структуру данных.

Сохранятся ли позиции в Google и Яндексе?

Гарантировать неизменные позиции нельзя. При миграции можно снизить технические риски: сохранить важные URL, настроить корректные 301-редиректы, перенести метаданные и проверить индексационные настройки.

Можно ли перенести только контент, а дизайн сделать новым?

Да. Более того, при переходе между разными CMS шаблон обычно разумнее собрать под новую систему, а не пытаться механически копировать старую внутреннюю архитектуру.

Нужно ли отключать старый сайт на время переноса?

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

Можно ли перенести интернет-магазин с OpenCart?

Да, но это отдельный сценарий миграции на WordPress + WooCommerce, где нужно дополнительно разбирать товары, варианты, заказы, клиентов, оплату и доставку.

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

Следующий шаг

Нужно решить похожую задачу?

Предлагать аудит исходного сайта, карту миграции и перенос на WordPress без обещаний гарантированного сохранения позиций; акцент на контроле SEO-рисков, данных, URL и интеграций.

Обсудить задачу