Как перенести сайт Drupal на WordPress: полное техническое руководство

Миграция с Drupal на WordPress означает перенос содержимого базы данных, медиафайлов, структуры URL и учётных записей пользователей из архитектуры CMS на основе сущностей Drupal в модель типов записей WordPress — без потери SEO-позиций, нарушения внутренних ссылок или возникновения простоев. Процесс включает импорт контента на уровне базы данных через плагин FG Drupal to WordPress, последующее сопоставление постоянных ссылок, настройку 301-редиректов и восстановление темы.

Это руководство охватывает каждый этап миграции с точными техническими деталями: стратегия резервного копирования перед миграцией, настройка среды, извлечение учётных данных базы данных, импорт с помощью плагина, согласование структуры URL и проверка после запуска. Независимо от того, используете ли вы Drupal 7, 9 или 10, приведённый ниже рабочий процесс применим в любом случае.

Зачем переходить с Drupal на WordPress

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

Немаловажен и аргумент производительности. Установка WordPress на правильно настроенном VPS-хостинге с LiteSpeed, объектным кэшированием и NVMe-хранилищем стабильно превосходит по производительности раздутый стек Drupal на общей инфраструктуре.

Основные мотивы миграции по сценариям использования:

• Редакционные команды, недовольные UX административной панели Drupal и медленными рабочими процессами публикации
• Агентства, консолидирующие клиентские сайты на единой управляемой CMS
• Разработчики, снижающие накладные расходы на обслуживание из-за цепочек зависимостей модулей Drupal
• SEO-команды, стремящиеся к более тесной интеграции с нативными инструментами WordPress, такими как Yoast или Rank Math

Drupal vs. WordPress: сравнение архитектур

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

Наиболее критичное архитектурное различие — модель сущностей контента. Drupal хранит параграфы, пользовательские поля и ссылки на таксономию в нескольких связанных таблицах. Плагин FG Drupal to WordPress сопоставляет их с мета-данными записей и терминами таксономии WordPress, однако сложные макеты на основе параграфов потребуют ручного восстановления.

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

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

• Проведите аудит инвентаря контента Drupal: типы узлов, словари таксономии, количество пользователей, количество файлов и общий размер базы данных
• Определите модули Drupal, не имеющие эквивалента в WordPress (например, Rules, сложная логика Webform, Commerce)
• Убедитесь, что сервер WordPress соответствует минимальным требованиям: PHP 8.1+, MySQL 8.0+ или MariaDB 10.6+, лимит памяти PHP 256 МБ
• Определите окно для миграции — в идеале период с минимальным трафиком
• Включите режим обслуживания в Drupal во время финального прохода импорта, чтобы предотвратить расхождение контента
• Убедитесь, что сервер WordPress может подключиться к хосту базы данных Drupal (тот же сервер, удалённый хост или SSH-туннель)

Шаг 1: Создайте резервную копию сайта Drupal

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

Резервное копирование базы данных через Drush

Если у вас установлен Drush (стандарт для Drupal 9/10), это самый быстрый метод:

drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzip

Резервное копирование базы данных через mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Резервное копирование директории файлов

tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/

Резервное копирование через phpMyAdmin (графический метод)

1. Войдите в phpMyAdmin через панель управления хостингом
2. Выберите базу данных Drupal в левой боковой панели
3. Нажмите Экспорт, выберите метод экспорта Быстрый, формат SQL
4. Нажмите Вперёд, чтобы скачать файл .sql

Храните все архивы резервных копий вне сервера — загрузите их в удалённое хранилище или скачайте локально через SFTP. Резервная копия, которая хранится только на том же сервере, что и мигрируемый сайт, — не настоящая резервная копия.

Шаг 2: Установите WordPress на целевой сервер

Установите чистый экземпляр WordPress в целевой среде. Не импортируйте контент Drupal в существующий сайт WordPress, если вы явно не планировали слияние контента — импортёр не выполняет дедупликацию.

Требования к серверу

Для крупных сайтов Drupal (10 000+ узлов, медиабиблиотеки объёмом несколько ГБ) VPS с cPanel предоставляет прямой доступ к конфигурации PHP, параметрам настройки MySQL и управлению заданиями cron — всё это понадобится вам при масштабной миграции.

Установка WordPress через WP-CLI

cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.com

Установка в один клик через cPanel

Если ваш хостинг предоставляет cPanel, перейдите в Softaculous Apps Installer, выберите WordPress, заполните учётные данные базы данных и администратора и нажмите Установить. Процесс занимает менее двух минут.

После установки немедленно настройте следующие параметры PHP в php.ini или через .htaccess:

php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128M

Шаг 3: Установите и настройте плагин FG Drupal to WordPress

Плагин FG Drupal to WordPress (бесплатная версия доступна; для крупных сайтов рекомендуется Premium) выполняет миграцию узлов, терминов таксономии, пользователей и медиафайлов на уровне базы данных.

Установка

1. В административной панели WordPress перейдите в Плагины > Добавить новый
2. Найдите FG Drupal to WordPress
3. Нажмите Установить, затем Активировать

Либо установите через WP-CLI:

wp plugin install fg-drupal-to-wp --activate

Сравнение функций бесплатной и Premium-версий

Для любого рабочего сайта на Drupal 8 и выше Premium-версия стоит своих денег. Ручное восстановление контента на основе параграфов обходится значительно дороже по времени разработчика.

Шаг 4: Получите учётные данные базы данных Drupal

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

Поиск учётных данных в settings.php Drupal

grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.php

Вывод будет содержать блок следующего вида:

$databases['default']['default'] = [
  'database' => 'drupal_db_name',
  'username' => 'drupal_db_user',
  'password' => 'drupal_db_password',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
];

Особенности удалённого доступа к базе данных

Если WordPress и Drupal находятся на разных серверах, база данных Drupal должна принимать удалённые подключения. На сервере базы данных Drupal:

GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Также убедитесь, что порт 3306 открыт в брандмауэре только для IP-адреса сервера WordPress — никогда не открывайте MySQL для 0.0.0.0.

Если открыть прямой порт MySQL невозможно, используйте SSH-туннель:

ssh -L 3307:localhost:3306 user@drupal_server_ip -N -f

Затем укажите в настройках плагина хост базы данных 127.0.0.1 и порт 3307.

Шаг 5: Запустите импорт контента

Перейдите в Инструменты > Импорт в панели управления WordPress, прокрутите до раздела Drupal и нажмите Запустить импортёр.

Настройка параметров импортёра

Вкладка подключения к базе данных:

• Хост базы данных: localhost (или удалённый IP / адрес SSH-туннеля)
• Порт: 3306 (или ваш пользовательский порт)
• Имя базы данных: значение из settings.php
• Имя пользователя / Пароль: значения из settings.php
• URL файлов Drupal: публичный URL директории sites/default/files/ вашего Drupal — необходим для загрузки медиафайлов

Нажмите Проверить подключение перед тем, как продолжить. Неудачное подключение на этом этапе почти всегда вызвано одной из трёх причин: неверные учётные данные, брандмауэр блокирует порт MySQL, или пользователь базы данных Drupal не имеет прав SELECT на целевую базу данных.

Вкладка поведения — рекомендуемые настройки для большинства миграций:

• Импортировать записи: Да
• Импортировать страницы: Да
• Импортировать категории и теги: Да
• Загружать изображения и вложения: Да (необходимо для копирования медиафайлов в директорию загрузок WordPress)
• Удалить данные WordPress перед импортом: Да (только при чистой установке — это очищает wp_posts и связанные таблицы)

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

Нажмите Запустить / Возобновить импортёр. Плагин обрабатывает контент пакетами. Для крупных сайтов импорт может завершиться по тайм-ауту и потребовать нескольких циклов возобновления — это ожидаемое поведение, а не ошибка. Просто каждый раз нажимайте Возобновить.

Следите за журналом импорта, отображаемым на экране. Обращайте внимание на:

Error downloading file — указывает на неверный URL файлов Drupal или на то, что директория файлов недоступна публично
Ошибки Duplicate entry — как правило, безвредны и указывают на то, что плагин пропускает уже импортированные записи при возобновлении
MySQL server has gone away — указывает на то, что wait_timeout слишком мало на сервере MySQL; увеличьте его минимум до 600 секунд

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Шаг 6: Согласуйте структуру URL и настройте редиректы
Этот шаг большинство руководств недооценивают. Несоответствие структуры URL между Drupal и WordPress — главная причина падения SEO-позиций после миграции.
Шаблоны URL Drupal (распространённые)




Шаблон URL Drupal
Описание




/node/123
Путь узла по умолчанию (без псевдонима)


/about-us
Псевдоним пути (наиболее распространённый)


/taxonomy/term/5
Страница термина таксономии


/user/1
Профиль пользователя


/content/article-title
Псевдоним с префиксом типа контента




Настройка постоянных ссылок WordPress
Перейдите в Настройки > Постоянные ссылки и выберите структуру, максимально соответствующую псевдонимам путей Drupal. Для большинства сайтов Drupal, использующих чистые псевдонимы, правильным выбором является /%postname%/.
/%postname%/
Если ваш сайт Drupal использовал URL с префиксом категории, например /blog/article-title, используйте:
/%category%/%postname%/
Настройка 301-редиректов
Установите плагин Redirection (автор John Godley) для управления правилами редиректов. Для массовых редиректов экспортируйте псевдонимы путей Drupal из базы данных:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Затем импортируйте полученный CSV в плагин Redirection, сопоставив каждый псевдоним Drupal с его эквивалентом в WordPress. Для URL в формате /node/123, которые никогда не имели псевдонима, создайте редиректы на основе регулярных выражений:
/node/([0-9]+)$ → /?p=$1
Это сопоставляет ID узлов Drupal с ID записей WordPress — но работает только в том случае, если плагин FG сохранил исходные ID узлов как ID записей, что он делает по умолчанию.
Важно: Проверьте каждый редирект с помощью curl -I перед запуском:
curl -I https://yourdomain.com/old-drupal-path
Убедитесь, что ответ — HTTP/2 301 с правильным заголовком Location, а не 302 и не 200 с программным редиректом.
Шаг 7: Перенесите темы и восстановите дизайн
Темы Drupal (на основе Twig) не имеют прямого эквивалента в WordPress. Необходимо воссоздать визуальный дизайн, используя тему WordPress в качестве основы.
Стратегия выбора темы

Темы на основе блоков (FSE): Используйте редактор сайта WordPress для полного управления макетом без конструкторов страниц. Лучший вариант для разработчиков, знакомых с блочной разметкой.
Классические темы с конструктором страниц: Темы, такие как Astra или GeneratePress в паре с Elementor или Bricks Builder, предлагают ближайший эквивалент Layout Builder в Drupal.
Пользовательская дочерняя тема: Если ваш сайт Drupal имел сильно кастомизированный дизайн, создайте дочернюю тему на основе минималистичного родителя (Underscores, Blocksy) и воспроизведите CSS.

Восстановление навигационных меню
Меню Drupal не мигрируют автоматически. Восстановите их в разделе Внешний вид > Меню (классические темы) или в блоке навигации редактора сайта (темы FSE). Сверьтесь со структурой меню Drupal:
drush eval "print_r(menu_tree_all_data('main', NULL));"
Или выполните запрос к базе данных напрямую:
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Виджеты и блоки
Блоки Drupal приблизительно соответствуют виджетам WordPress и блокам Gutenberg. Восстановите боковые панели и области подвала в разделе Внешний вид > Виджеты или непосредственно в редакторе сайта. Пользовательские типы блоков Drupal с логикой PHP потребуется переработать в виде шорткодов WordPress или пользовательских блоков.
Шаг 8: Аудит контента после миграции
Не пропускайте этот этап. Автоматизированные инструменты миграции хорошо справляются со структурированным контентом, но молча дают сбой в граничных случаях.
Проверка целостности контента

Встроенные медиафайлы: Встроенные ссылки на файлы в Drupal используют пользовательский формат токенов ([file:123] или <drupal-media uuid="..."/>). Они не будут отображаться в WordPress. Выполните поиск этих токенов в базе данных:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';

Шорткоды и Views: Drupal Views не имеют эквивалента в WordPress. Любая страница, отображавшая View (например, отфильтрованный список контента), будет пустой. Восстановите их с помощью WP_Query, архивов пользовательских типов записей или плагина, такого как Posts Table Pro.


Пользовательские поля: Данные полей Drupal, мигрированные через Premium-плагин, попадают в wp_postmeta. Убедитесь, что значения полей присутствуют:

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;

Учётные записи пользователей: Если вы мигрировали пользователей, проверьте сопоставление ролей. Роль authenticated user в Drupal соответствует Subscriber в WordPress. Роль editor в Drupal соответствует Editor в WordPress. Роль administrator в Drupal соответствует Administrator в WordPress. Проверьте сопоставление и при необходимости скорректируйте.

Обнаружение неработающих ссылок
Установите Broken Link Checker или выполните сканирование с помощью Screaming Frog в вашей тестовой среде до переключения DNS. Исправьте все внутренние ошибки 404 до запуска — не полагайтесь на мониторинг после запуска для их обнаружения.
Шаг 9: Повышение производительности и безопасности
Только что мигрированный сайт WordPress требует усиления защиты перед переводом в рабочий режим.
Настройка кэширования
Установите LiteSpeed Cache (при использовании сервера LiteSpeed) или W3 Total Cache / WP Rocket для сред Apache/Nginx. Настройте:

Кэш страниц с TTL не менее 3600 секунд для статических страниц
Объектный кэш на основе Redis или Memcached
Заголовки кэша браузера через .htaccess или конфигурацию сервера

SSL/HTTPS
Убедитесь, что ваш сайт WordPress обслуживается исключительно по HTTPS. Если у вас ещё нет сертификата, SSL-сертификаты можно быстро получить и настроить с автоматическим обновлением. Обновите настройки URL сайта WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Принудительно включите HTTPS в .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Контрольный список по безопасности

Отключите XML-RPC, если он не нужен: добавьте add_filter('xmlrpc_enabled', '__return_false'); в functions.php

find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Шаг 10: Переключение DNS и запуск

Выполняйте переключение DNS в период наименьшего трафика. Сам процесс должен занять менее 15 минут реальной работы, а распространение займёт до 48 часов (обычно 1–4 часа для большинства резолверов).

Финальные проверки перед переключением

• Выполните полное сканирование тестового URL и убедитесь в отсутствии ошибок 404
• Убедитесь, что все 301-редиректы возвращают правильные заголовки Location
• Протестируйте контактные формы, функцию поиска и все процессы электронной коммерции
• Убедитесь, что Google Search Console верифицирована на новом сайте
• Сгенерируйте и отправьте актуальную XML-карту сайта через Yoast SEO или Rank Math

Процесс обновления DNS

Если вы зарегистрировали домен через регистрацию доменов, обновите A-запись непосредственно в панели управления DNS. Снизьте TTL до 300 секунд как минимум за 24 часа до переключения, чтобы минимизировать задержку распространения.

A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutover

Мониторинг после запуска

• Активируйте инструмент смены адреса в Google Search Console, если изменился сам домен
• Отслеживайте Core Web Vitals в Search Console в течение первых 30 дней — ожидайте временных колебаний позиций, пока Google повторно сканирует и индексирует сайт
• Настройте UptimeRobot или аналогичный инструмент для мониторинга доступности
• Ежедневно проверяйте журналы ошибок сервера в течение первой недели:

tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.log

Повторная отправка в поисковые системы

Отправьте обновлённую карту сайта в Google Search Console:

1. Перейдите в Search Console > Карты сайта
2. Введите sitemap.xml (или sitemap_index.xml для крупных сайтов)
3. Нажмите Отправить

Также отправьте сайт в Bing Webmaster Tools и выполните там независимую верификацию — индекс Bing используется несколькими AI-поисковиками, включая Copilot.

Рекомендации по хостинговой инфраструктуре

Производительность мигрированного сайта WordPress во многом зависит от базовой инфраструктуры. Миграция с Drupal на WordPress — идеальный момент для модернизации хостингового стека.

Для сайтов с умеренным трафиком (10 000–100 000 посещений в месяц) план VPS-хостинга с минимум 2 vCPU, 4 ГБ RAM и NVMe-хранилищем обеспечивает достаточный запас ресурсов для WordPress с полным кэшированием страниц. Для высоконагруженных или ресурсоёмких сайтов выделенные серверы полностью устраняют проблему «шумных соседей» и дают полный контроль над параметрами ядра, конфигурацией MySQL и настройкой сетевого стека.

Если вы управляете несколькими клиентскими сайтами или предпочитаете управление сервером через графический интерфейс, панели управления VPS предлагают широкий выбор вариантов, включая cPanel, Plesk и DirectAdmin — каждая из которых поддерживает управление несколькими сайтами WordPress, автоматическое резервное копирование и выпуск SSL-сертификатов из единого интерфейса.

Матрица технических решений: когда использовать каждый подход к миграции

Ключевые технические выводы

• Сначала создайте резервную копию. Сжатый SQL-дамп и архив tar директории sites/default/files/ — ваша страховочная сеть. Убедитесь, что оба файла полны и восстанавливаемы, прежде чем начинать.
• Проверьте подключение к базе данных перед запуском импортёра. Большинство неудачных миграций останавливаются на проверке подключения из-за правил брандмауэра или отсутствия прав SELECT.
• Контент Drupal на основе параграфов требует Premium-плагина. Бесплатная версия молча пропускает поля параграфов, оставляя контент неполным без каких-либо сообщений об ошибках.
• 301-редиректы обязательны. Каждый URL Drupal, имеющий внешние обратные ссылки или индексацию в поисковых системах, должен перенаправляться на свой эквивалент в WordPress с постоянным кодом 301. Отсутствующий редирект — это потерянный сигнал ранжирования.
• Снизьте DNS TTL за 24 часа до переключения. Установите значение 300 секунд, чтобы распространение завершилось за минуты, а не часы, когда вы измените A-запись.
• Проверьте wp_postmeta на наличие несопоставленных полей Drupal. Данные пользовательских полей попадают туда после импорта — убедитесь в их наличии и правильных ключах до вывода из эксплуатации экземпляра Drupal.
• Не выводите Drupal из эксплуатации немедленно. Держите среду Drupal запущенной (в режиме обслуживания, без публичного доступа) как минимум 30 дней после запуска в качестве справочника и варианта отката.
• Отправьте карту сайта в день запуска. Не ждите, пока Googlebot самостоятельно обнаружит новую структуру — активная отправка ускоряет повторное сканирование.

Часто задаваемые вопросы

Можно ли мигрировать мультисайтовую установку Drupal на WordPress?

Да, но каждый подсайт Drupal необходимо мигрировать отдельно. Плагин FG Drupal to WordPress не поддерживает нативную обработку мультисайта Drupal за один проход. Выполните отдельный импорт для каждого подсайта, нацелившись либо на сеть WordPress Multisite, либо на отдельные установки WordPress в зависимости от вашей архитектуры.

Перенесутся ли пароли пользователей Drupal в WordPress?

Нет. Drupal использует хеширование SHA-512 с солью (или bcrypt в более новых версиях), несовместимое с хешированием WordPress на основе phpass. Плагин FG Premium мигрирует учётные записи пользователей, но сбрасывает пароли, инициируя отправку письма для сброса пароля каждому пользователю. Заранее спланируйте коммуникацию с пользователями.

Как обрабатывать типы контента Drupal, не имеющие эквивалента в WordPress?

Зарегистрируйте эквивалентные пользовательские типы записей (CPT) в WordPress перед запуском импорта. Плагин FG Premium позволяет сопоставлять типы контента Drupal с CPT WordPress. Без этого сопоставления все узлы по умолчанию будут относиться к типу записи post, что разрушит таксономию вашего контента.

Что происходит с терминами таксономии Drupal при миграции?

Словари Drupal сопоставляются с таксономиями WordPress. Стандартное сопоставление преобразует tags Drupal в теги WordPress, а categories Drupal — в категории WordPress. Пользовательские словари требуют ручной регистрации таксономии в WordPress перед импортом, иначе они будут удалены.

Сколько времени занимает миграция крупного сайта Drupal?

Для сайта с 5000 узлами и 2 ГБ медиафайлов на хорошо оснащённом сервере ожидайте 2–4 часа времени импорта, плюс 4–8 часов на аудит контента после миграции и настройку редиректов. Само переключение DNS занимает менее 15 минут. Общее время от начала до запуска обычно составляет один-два рабочих дня при тщательной, качественной миграции.