Як перенести веб-сайт 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 Hosting з LiteSpeed, кешуванням об’єктів та NVMe-сховищем стабільно перевершуватиме роздуту інсталяцію Drupal на спільній інфраструктурі.

Основні причини міграції залежно від сценарію використання:

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

Drupal проти 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
Це зіставляє ідентифікатори вузлів Drupal з ідентифікаторами записів WordPress — але працює лише якщо плагін FG зберіг оригінальні ідентифікатори вузлів як ідентифікатори записів, що він робить за замовчуванням.
Важливо: Перевірте кожне перенаправлення за допомогою 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-sitemap через 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

Повторне подання до пошукових систем

Надішліть оновлений sitemap у Google Search Console:

1. Перейдіть до Search Console > Sitemaps
2. Введіть sitemap.xml (або sitemap_index.xml для великих сайтів)
3. Натисніть Надіслати

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

Рекомендації щодо хостингової інфраструктури

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

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

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

Матриця технічних рішень: коли використовувати кожен підхід до міграції

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

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

FAQ

Чи можна мігрувати мультисайтову інсталяцію 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?

Для сайту з 5 000 вузлів та 2 ГБ медіафайлів очікуйте 2–4 години часу імпорту на добре оснащеному сервері, плюс 4–8 годин на аудит вмісту після міграції та налаштування перенаправлень. Саме перемикання DNS займає менше 15 хвилин. Загальний час від початку до запуску зазвичай становить один-два робочі дні для ретельної, якісної міграції.