Skip to content

Все для WordPress, веб-розробки — і не тільки

🔄 Як замінити старий домен на новий через phpMyAdmin: посібник для WordPress

🔄 Як замінити старий домен на новий через phpMyAdmin: посібник для WordPress

Перенесли сайт на новий домен, і він лежить. Або відкривається, але без стилів. Або адмінка не пускає. Кожен, хто руками переїжджав WordPress, проходив через цей момент: база даних досі пам’ятає старий URL, і сайт судомно намагається завантажити ресурси з адреси, якої більше немає.

Чотири SQL-запити в phpMyAdmin вирішують проблему за п’ять хвилин. Без плагінів, без WP-CLI, без паніки. Нижче, покрокова інструкція від пошуку поточного домену до фінальної перевірки. З поправкою на нестандартний префікс таблиць, HTTPS і серіалізовані дані.

💡 Швидкий огляд:

  • Знаходите поточний домен у таблиці wp_options: поля siteurl і home
  • Виконуєте чотири UPDATE-запити у вкладці SQL phpMyAdmin
  • Скидаєте пароль адміністратора через wp_users, якщо адмінка не пускає
  • Зберігаєте постійні посилання в налаштуваннях WordPress для повернення стилів
  • Для магазинів і мультисайтів використовуєте Better Search Replace або WP-CLI: звичайний REPLACE ламає серіалізовані масиви

З чого починати: дізнайтеся поточний домен у базі

Перед заміною переконайтеся, який домен прописаний у сайту зараз. Це зекономить час, якщо сайт переїжджав раніше і в базі міг залишитися третій, «проміжний» URL.

Відкрийте phpMyAdmin, виберіть базу даних сайту і знайдіть таблицю wp_options. У ній, два рядки: siteurl (адреса WordPress) і home (адреса сайту). Саме їхні значення ми змінюватимемо в першу чергу.

Таблиця wp_options зі значеннями siteurl і home у phpMyAdmin

Якщо префікс таблиць нестандартний, наприклад, mysite_ замість wp_, шукайте таблицю mysite_options. Префікс можна подивитися у файлі wp-config.php: змінна $table_prefix.

Чотири SQL-запити для повної заміни домену

Кожен запит виконуйте по черзі у вкладці «SQL» phpMyAdmin. Перед запуском обов’язково зробіть бекап бази: експорт через той самий phpMyAdmin займає хвилину і рятує від незворотних помилок.

Змінюйте http://www.oldurl на http://www.newurl в усіх запитах нижче. Якщо сайт працює за HTTPS, використовуйте https:// в обох адресах.

1. Оновлення HOME і SITEURL

Змінює дві ключові адреси в wp_options. Без цього кроку сайт просто не відкриється за новим доменом, WordPress намагатиметься редіректити на старий.

1UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

2. Оновлення GUID записів

Поле guid у wp_posts зберігає постійний ідентифікатор кожного запису. Для роботи сайту його заміна не критична, WordPress не використовує GUID для маршрутизації. Але якщо сайт читають через RSS-рідери, чистота GUID має значення: старі URL у стрічці вестимуть на биті посилання.

1UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl', 'http://www.newurl');

3. Оновлення вмісту записів

Найоб’ємніший запит. post_content містить текст усіх сторінок і постів, включно зі вставленими зображеннями та внутрішніми посиланнями. Після виконання всі картинки в контенті починають завантажуватися з нового домену.

1UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

4. Оновлення мета-полів

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

1UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.oldurl', 'http://www.newurl');

Після виконання всіх чотирьох відкрийте сайт за новим доменом. Якщо все зроблено правильно, проблем бути не повинно. Але трапляється інше: помилка «Error establishing a database connection» або сторінка відкривається без стилів.

Помилка підключення до бази даних після зміни домену WordPress

Перше, що потрібно в такій ситуації,, доступ до адмін-панелі.

Як потрапити в адмінку, якщо пароль втрачено або сайт не пускає

Замовник не залишив пароль. Або ви замкнули себе зміною домену і /wp-admin викидає в нескінченний редірект. Ось два способи отримати права адміністратора напряму через базу даних.

Скидання пароля адміністратора через phpMyAdmin

Відкрийте таблицю wp_users, у вас префікс може відрізнятися (mysite_users тощо). Знайдіть користувача з правами адміністратора і натисніть «Змінити»:

Таблиця wp_users у phpMyAdmin зі списком користувачів WordPress

У рядку user_pass виберіть у випадному списку функцію MD5 і введіть новий пароль у сусідньому полі. Натисніть «Вперед»:

Встановлення MD5-пароля для користувача WordPress через phpMyAdmin

Зверніть увагу: сучасний WordPress використовує phpass (bcrypt-хеші), а не MD5. Але під час введення пароля WordPress перевіряє хеш за ланцюжком: якщо bcrypt-перевірка не пройшла, він пробує MD5-фолбек і одразу перехешовує пароль в актуальний формат. Тому MD5 через phpMyAdmin працює як тимчасовий ключ.

Створення адміністратора через PHP

Альтернативний спосіб, додати нового користувача-адміністратора програмно. Код вставляється у functions.php активної теми або через MU-плагін.

Додайте у functions.php дочірньої теми:

1function sdstudio_add_admin_user() {
2 $userdata = array(
3 'user_login' => 'tempadmin',
4 'user_pass' => 'TempPass123!',
5 'user_email' => '[email protected]',
6 'role' => 'administrator',
7 );
8 wp_insert_user( $userdata );
9}
10add_action( 'init', 'sdstudio_add_admin_user' );

Функція wp_insert_user() створює користувача з переданими параметрами, а хук init спрацьовує під час кожного запиту до WordPress. Достатньо один раз відкрити будь-яку сторінку сайту, і користувача створено.

Після входу в адмінку обов'язково видаліть і функцію з functions.php, і створеного тимчасового користувача. Залишати tempadmin з паролем у відкритому вигляді — це діра в безпеці.

Виправлення зіпсованих зображень і стилів після заміни домену

Доступ до адмінки є, але зображення не завантажуються, а верстка попливла. У дев'яти випадках із десяти допомагає одна проста операція.

Перейдіть у «Налаштування» → «Постійні посилання»:

Сторінка налаштувань постійних посилань WordPress в адмін-панелі

Нічого не змінюйте, просто натисніть «Зберегти зміни»:

Кнопка збереження налаштувань постійних посилань у WordPress

WordPress перебудує структуру URL, оновить кеш правил перезапису та скине внутрішній кеш редіректів. Після цього зображення зазвичай повертаються на місце.

Не допомогло, отже, старий домен зашитий у серіалізованих масивах. Звичайний REPLACE в SQL їх ламає: довжина рядка в серіалізованому масиві жорстко прописана числом, і заміна «старого-довгого.ru» на «новий-короткий.io» змінює цю довжину, масив перестає читатися. Встановіть безплатний плагін Better Search Replace, він коректно обробляє серіалізацію і перед заміною показує, скільки збігів знайдено в кожній таблиці.

Для сайтів із WP-CLI ще простіше, одна команда:

1wp search-replace 'http://olddomain.ru' 'https://newdomain.io' --all-tables --dry-run

Прапорець --dry-run спочатку покаже, що буде замінено, не вносячи змін. Переконалися, запустіть без нього. WP-CLI search-replace теж уміє працювати із серіалізованими даними і робить це швидше за вебінтерфейс.

У відео нижче, наочна демонстрація всього процесу від входу в phpMyAdmin до перевірки сайту після заміни:

⁉️🤔 Часті запитання

Чи обов’язково використовувати phpMyAdmin для заміни домену?

Ні. Якщо сайт ще не перенесено, Duplicator або All-in-One WP Migration виконують заміну автоматично під час розгортання. Якщо сайт уже лежить на новому хостингу без доступу до адмінки, залишаються SQL-запити через phpMyAdmin, Adminer або WP-CLI. Для більшості вебмайстрів phpMyAdmin — це найпряміший і найконтрольованіший метод: ви бачите кожну операцію, а не довіряєтеся чорній скриньці плагіна.

Що робити, якщо префікс таблиць не wp_?

Подивіться у wp-config.php значення константи $table_prefix. Зазвичай це wp_, але хостери або плагіни безпеки на кшталт Solid Security (колишній iThemes Security) іноді змінюють його на випадковий. В усіх запитах вище замініть wp_ на ваш префікс, наприклад, xyz123_options замість wp_options.

Чому сайт відкривається без стилів після заміни?

Старий домен залишився в налаштуваннях теми, кеші або CDN. Скиньте постійні посилання (інструкція вище), очистіть кеш плагіна кешування. Якщо використовуєте Cloudflare або інший CDN, інвалідуйте кеш на стороні провайдера. Якщо не допомогло, запустіть Better Search Replace: найімовірніше, старий URL зашито в серіалізованому масиві theme_mods_*.

Сайт на HTTPS, а після переїзду сертифікат не працює, що робити?

Переконайтеся, що в усіх запитах ви використовували https://, а не http://. Перевірте, що в налаштуваннях WordPress після входу в адмінку обидві адреси починаються з https://. Сам SSL-сертифікат налаштовується на стороні хостингу, через панель керування або безкоштовний Let's Encrypt. Це окрема процедура, не пов’язана з базою даних.

Чи можна замінити домен без доступу до phpMyAdmin?

Так. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. Тільки FTP: додайте в wp-config.php рядки define('WP_HOME','http://newdomain'); та define('WP_SITEURL','http://newdomain');, це тимчасово перевизначить адреси й надасть доступ до адмінки. Після входу приберіть рядки та збережіть налаштування через інтерфейс.

Чи потрібно змінювати GUID у wp_posts, чи можна пропустити?

Для роботи сайту не потрібно. WordPress не використовує GUID для маршрутизації, лише для ідентифікації записів у RSS-стрічках. Якщо сайт активно читають через RSS, заміна має сенс. Якщо ні, третій запит із чотирьох можна пропустити без наслідків.

Після заміни домену через SQL злетіли налаштування деяких плагінів, чому?

Плагіни на кшталт WooCommerce, Advanced Custom Fields і слайдери зберігають URL у серіалізованих масивах wp_postmeta. Звичайний REPLACE не враховує лічильник довжини рядка в серіалізації та ламає структуру. Рішення: Better Search Replace або wp search-replace (вони десеріалізують масив, замінюють рядок і серіалізують назад). Якщо вже зламали, відновіть базу з бекапу та повторіть заміну правильним інструментом.

Що робити у складних випадках: магазини, мультисайти та великі бази

Заміна домену через SQL — це процедура на п’ять хвилин, якщо у вас є прямий доступ до phpMyAdmin і стандартний префікс таблиць. Але є ситуації, де ручна заміна через REPLACE справді небезпечна.

Інтернет-магазини на WooCommerce із сотнями тисяч замовлень. Мультисайтові мережі з десятками окремих таблиць під кожен підсайт. Сайти, де URL жорстко зашиті в серіалізовані масиви (налаштування тем, конструктори сторінок, слайдери). У таких випадках одиничний SQL REPLACE може пошкодити структуру даних, і відновлення бази з бекапу забере більше часу, ніж акуратна заміна з першого разу.

Better Search Replace або WP-CLI search-replace вміють працювати із серіалізацією, використовуйте їх. А якщо обсяг бази перевалює за гігабайт і ціна помилки висока, година роботи dev-спеціаліста обійдеться дешевше, ніж відновлення магазину, простій якого коштує грошей.

Тему перенесення сайту зі збереженням SEO і без втрати трафіку розбирали в окремому посібнику. А якщо зіткнулися з конкретною помилкою після заміни, пишіть у коментарях, допоможемо з діагностикою.