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 и без потери трафика разбирали в отдельном руководстве. А если столкнулись с конкретной ошибкой после замены, пишите в комментариях, поможем с диагностикой.