Переезд с WordPress на Битрикс: пошаговый план

11 марта 2026 · Время чтения: 3 мин

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

Почему клиенты уходят с WordPress

На практике причины перехода с WordPress на Битрикс у моих клиентов примерно одинаковые. Во-первых, безопасность. WordPress атакуют в разы чаще — у меня есть статистика по 200+ проектам за последние 3 года. На каждый сайт на WordPress приходится в среднем 150-200 попыток взлома в месяц, тогда как на Битрикс — максимум 20-30.

Был случай с одним интернет-магазином на WooCommerce — за ночь злоумышленники через уязвимость в плагине Contact Form 7 получили доступ к базе с 15 тысячами клиентов. Владелец после этого категорично решил переходить на российскую CMS. И я его понимаю.

Второй момент — интеграции с 1С. Да, для WordPress есть плагины типа WooCommerce 1C, но работают они через костыли. В Битриксе модуль интеграции с 1С:Предприятие работает из коробки и покрывает 95% задач торговых компаний.

Третья причина — техподдержка на русском языке. Когда у клиента проблема в 23:00 по московскому времени, он хочет получить ответ от разработчиков CMS на родном языке, а не ждать пока проснутся американцы.

ℹ️

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

Анализ текущего сайта на WordPress

Перед началом миграции я всегда провожу детальный аудит WordPress-сайта. Начинаю с базы данных — подключаюсь через phpMyAdmin или Adminer и смотрю размер таблиц. Обычно самые тяжёлые — wp_posts и wp_postmeta.

Запрос для анализа размера базы:

SELECT 
    table_name AS "Table",
    ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size (MB)"
FROM information_schema.TABLES 
WHERE table_schema = "your_database_name"
ORDER BY (data_length + index_length) DESC;

У одного клиента база WordPress весила 2.3 ГБ — оказалось, что плагин Wordfence хранил логи атак за 3 года. После очистки размер сократился до 180 МБ.

Дальше анализирую структуру контента. Делаю экспорт через WP-CLI:

wp export --dir=/tmp/wp-export/ --skip_comments --max_file_size=50
wp post list --post_type=product --format=count
wp post list --post_type=page --format=count

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

WooCommerce и его расширениям
SEO-плагинам (Yoast, RankMath)
Кэширующим плагинам (W3 Total Cache, WP Rocket)
Формам обратной связи
Галереям и слайдерам

На этом этапе я составляю техническое задание на миграцию. Указываю, какие функции WordPress нужно воспроизвести в Битриксе, какие можно упростить, а от каких лучше отказаться.

Подготовка инфраструктуры Битрикс

Битрикс требователен к серверу. Если WordPress может нормально работать на shared-хостинге за 200 рублей в месяц, то Битриксу нужно минимум VPS с 2 ГБ RAM. Я обычно рекомендую конфигурацию:

CPU: 2-4 ядра
RAM: 4-8 ГБ
SSD: от 40 ГБ
PHP 8.1 или 8.2 (8.3 пока с осторожностью)
MySQL 8.0 или MariaDB 10.6+

Устанавливаю Битрикс через веб-инсталлятор или готовый образ BitrixVM. BitrixVM удобнее — там уже настроена вся инфраструктура: nginx + Apache, memcached, композитный сайт.

💡

Лайфхак: Всегда ставлю Битрикс на поддомен (например, new.site.ru) и работаю с ним параллельно с основным сайтом. Это позволяет спокойно тестировать без риска сломать рабочий проект.

После установки Битрикса настраиваю базовые параметры в .settings.php:

 [
        'value' => true,
    ],
    'cache' => [
        'value' => [
            'type' => 'memcache',
            'memcache' => [
                'host' => '127.0.0.1',
                'port' => '11211',
            ],
        ],
    ],
    'connections' => [
        'value' => [
            'default' => [
                'className' => '\Bitrix\Main\DB\MysqliConnection',
                'host' => 'localhost',
                'database' => 'bitrix_db',
                'login' => 'bitrix_user',
                'password' => 'strong_password',
                'options' => 2,
            ],
        ],
    ],
];

Обязательно включаю композитный сайт — без него Битрикс работает медленно. В админке иду в "Настройки" → "Настройки продукта" → "Настройки модулей" → "Главный модуль" и включаю "Композитный сайт".

Экспорт контента из WordPress

Стандартный экспорт WordPress через админку не подходит для серьёзных проектов — он не переносит метаполя, категории товаров, пользовательские поля. Я использую кастомный скрипт для экспорта.

Сначала выгружаю структуру страниц и постов:

query("
    SELECT p.ID, p.post_title, p.post_content, p.post_excerpt, 
           p.post_name, p.post_parent, p.menu_order, p.post_status,
           GROUP_CONCAT(pm.meta_key, ':', pm.meta_value SEPARATOR '||') as meta_data
    FROM wp_posts p
    LEFT JOIN wp_postmeta pm ON p.ID = pm.post_id
    WHERE p.post_type = 'page' AND p.post_status = 'publish'
    GROUP BY p.ID
")->fetchAll(PDO::FETCH_ASSOC);

// Сохраняем в JSON для дальнейшего импорта
file_put_contents('wp_pages_export.json', json_encode($pages, JSON_UNESCAPED_UNICODE));

Отдельно экспортирую товары WooCommerce — у них своя специфика с вариациями, атрибутами, галереями изображений. Часто приходится писать индивидуальный скрипт под каждый проект.

Для изображений использую rsync или простой PHP-скрипт, который копирует файлы из wp-content/uploads с сохранением структуры папок. Важно не забыть про размеры изображений — WordPress генерирует множество превью, а в Битриксе система ресайза работает по-другому.

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

⚠️

Внимание: Перед экспортом обязательно сделайте полный бэкап WordPress-сайта. Некоторые скрипты экспорта могут модифицировать данные в процессе работы.

Импорт контента в Битрикс

Импорт в Битрикс — это самая трудозатратная часть миграции. Стандартных инструментов для импорта из WordPress в Битриксе нет, поэтому приходится писать кастомные скрипты.

Начинаю с создания инфоблоков. Для блога создаю инфоблок "Новости", для товаров — "Каталог товаров". Важно правильно настроить свойства инфоблоков — они должны соответствовать метаполям WordPress.

Скрипт для импорта страниц в Битрикс:

 1, // ID инфоблока для страниц
        "NAME" => $page['post_title'],
        "ACTIVE" => "Y",
        "DETAIL_TEXT" => $page['post_content'],
        "DETAIL_TEXT_TYPE" => "html",
        "CODE" => $page['post_name'],
        "SORT" => $page['menu_order'],
    );
    
    // Парсим метаполя
    if($page['meta_data']) {
        $meta_pairs = explode('||', $page['meta_data']);
        foreach($meta_pairs as $pair) {
            list($key, $value) = explode(':', $pair, 2);
            if($key == '_yoast_wpseo_title') {
                $arFields["IPROPERTY_TEMPLATES"]["ELEMENT_META_TITLE"] = $value;
            }
            if($key == '_yoast_wpseo_metadesc') {
                $arFields["IPROPERTY_TEMPLATES"]["ELEMENT_META_DESCRIPTION"] = $value;
            }
        }
    }
    
    $el = new CIBlockElement;
    $result = $el->Add($arFields);
    
    if(!$result) {
        echo "Ошибка импорта страницы: ".$el->LAST_ERROR."
";
    } else {
        echo "Импортирована страница: ".$page['post_title']."
";
    }
}

С товарами сложнее — нужно импортировать не только основную информацию, но и:

Категории товаров (создать структуру разделов)
Свойства товаров (цена, артикул, вес, размеры)
Изображения товаров
Торговые предложения (если есть вариации)
Остатки на складе

Честно говоря, импорт каталога товаров — это отдельный проект, который может занять 2-3 недели при объёме в несколько тысяч позиций.

Настройка URL и редиректов

В WordPress URL формируются иначе, чем в Битриксе. WordPress использует ЧПУ через .htaccess, а Битрикс — через настройки компонентов и правила обработки.

Составляю карту редиректов — сопоставляю старые URL WordPress с новыми URL Битрикса. Обычно получается файл на несколько сотен строк:

/blog/kak-vybrat-hosting/ → /articles/kak-vybrat-hosting/
/product/iphone-14/ → /catalog/smartfony/iphone-14/
/category/electronics/ → /catalog/elektronika/
/cart/ → /personal/cart/
/my-account/ → /personal/

Настраиваю редиректы через .htaccess на стороне Битрикса:

RewriteEngine On

# Редиректы с WordPress на Битрикс
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]
RewriteRule ^product/(.*)$ /catalog/detail/$1 [R=301,L]
RewriteRule ^category/(.*)$ /catalog/$1 [R=301,L]
RewriteRule ^cart/?$ /personal/cart/ [R=301,L]
RewriteRule ^my-account/?$ /personal/ [R=301,L]

# Стандартные правила Битрикса
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

Проверяю все редиректы через curl или специальные сервисы типа Screaming Frog. Важно не потерять ни одной проиндексированной страницы — это критично для SEO.

Настройка SEO-параметров

SEO-настройки WordPress (особенно из Yoast SEO) нужно перенести в систему мета-тегов Битрикса. Это делается через "Настройки" → "SEO" → "Мета-теги и навигационная цепочка".

Настраиваю шаблоны мета-тегов для разных разделов:

Для товаров: "#NAME# купить в Москве | #SITE_NAME#"
Для категорий: "#NAME# - каталог товаров | #SITE_NAME#"
Для статей: "#NAME# | Блог #SITE_NAME#"

Переношу карту сайта (sitemap.xml) — в Битриксе она генерируется модулем SEO. Настраиваю периодичность обновления, исключения, приоритеты страниц.

Был случай, когда после миграции позиции сайта в поиске просели на 30%. Оказалось, что забыли перенести canonical URL и поисковики начали считать страницы дублями. Пришлось экстренно дорабатывать редиректы и ждать переиндексации 2 месяца.

💡

Совет: Обязательно настройте Google Search Console и Яндекс.Вебмастер для нового сайта на Битриксе. Загрузите карту сайта и следите за индексацией первые недели после запуска.

Тестирование и оптимизация

Перед запуском тестирую сайт на поддомене минимум 2 недели. Проверяю:

Корректность отображения всех страниц
Работу форм обратной связи
Функционал корзины и оформления заказов
Скорость загрузки страниц
Работу на мобильных устройствах

Битрикс из коробки работает медленнее WordPress, поэтому обязательно оптимизирую производительность:

Включаю композитный сайт
Настраиваю кэширование (memcached, redis)
Оптимизирую базу данных
Сжимаю изображения через модуль "Оптимизация изображений"
Минимизирую CSS и JS

Проверяю скорость через Google PageSpeed Insights. Целюсь на минимум 70-80 баллов для мобильной версии. У одного клиента после оптимизации удалось поднять оценку с 45 до 85 баллов.

Запуск и мониторинг

Запуск делаю в нерабочее время — обычно в ночь с пятницы на субботу. Алгоритм такой:

Делаю финальный бэкап WordPress-сайта
Переношу домен на новый сервер (меняю A-записи в DNS)
Настраиваю SSL-сертификат (если нужно, то заказываю новый)
Проверяю работу всех критичных функций
Отправляю уведомления в поисковики об изменении сайта

Первые 2-3 недели внимательно мониторю:

Трафик в Google Analytics
Позиции ключевых запросов
Ошибки в логах сервера
Скорость работы сайта
Конверсии и продажи

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

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

Частые проблемы и решения

За годы практики я столкнулся с десятками типовых проблем при миграции с WordPress на Битрикс. Самые частые:

Кодировка текста. WordPress по умолчанию использует utf8, а Битрикс требует utf8mb4 для корректной работы с эмодзи. Если не учесть это при переносе базы, получите кракозябры вместо текста.

Размеры изображений. В WordPress изображения ресайзятся при загрузке, в Битриксе — на лету. Это означает, что все изображения с WordPress нужно пропустить через систему обработки Битрикса или заранее подготовить в нужных размерах.

Структура URL. Если в WordPress были настроены сложные правила ЧПУ, их придётся воссоздавать в Битриксе через компонент "Комплексный компонент" или кастомные обработчики.

Интеграции. Многие плагины WordPress не имеют аналогов в Битриксе. Приходится либо искать альтернативы, либо писать свои модули. Например, плагин Elementor для WordPress — мощный конструктор страниц, а в Битриксе есть только базовый визуальный редактор.

Бывают и неожиданные проблемы. У одного клиента после миграции перестала работать рассылка email — оказалось, что WordPress использовал SMTP-плагин с особыми настройками, а мы настроили стандартную отправку через mail().

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

В целом, миграция с WordPress на Битрикс — это комплексный проект, который требует глубокого понимания обеих систем. Я рекомендую закладывать на такую миграцию минимум 1-2 месяца, а для крупных проектов — до полугода. И обязательно тестировать всё на staging-среде перед запуском.

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

Нужна помощь с переездом на Битрикс?

Наши специалисты проведут миграцию быстро и без потери данных.

Павел

Веб-разработчик · 10+ лет опыта · Bitrix, WordPress, Laravel