Перенос WordPress на другой домен: техническая часть по шагам

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

Перенос WordPress на другой домен обычно начинается со слов «да там же просто скопировать файлы». Копируют, открывают новый адрес и видят либо редирект обратно на старый домен, либо белый экран, либо главную без стилей и картинок. Причина одна: адрес сайта зашит не в конфиге, а в сотнях мест базы данных, и часть из них лежит внутри сериализованных строк, которые обычная замена ломает насмерть. Ниже техническая часть по шагам: что копировать, чем менять адреса, где чинить, если админка уже недоступна, и как проверить результат, чтобы не узнать про поломку от клиента через неделю.

Речь именно про смену домена: файлы могут остаться на том же хостинге или уехать на новый, принципиально это ничего не меняет. Если у вас переезд между серверами без смены адреса, это другая задача, она разобрана в статье про перенос сайта на новый хостинг. А про позиции, склейку в Яндексе и поведение трафика после смены адреса есть отдельный разбор: переезд на новый домен без потери позиций. Здесь только руки и консоль.

Что реально переезжает вместе с сайтом

Список того, что придётся тронуть, всегда длиннее, чем кажется на старте. Вот полный перечень для типового корпоративного сайта на WordPress.

Что	Где лежит	Ломается при забывчивости
Файлы ядра, темы, плагины	каталог сайта на хостинге	сайт не поднимется
Загрузки медиатеки	wp-content/uploads/	битые картинки во всех статьях
База данных	MySQL/MariaDB	вообще всё
wp-config.php	корень сайта	доступ к базе
Почта на домене	MX-записи и почтовые ящики	письма с форм и от клиентов
Крон	wp-cron.php или системный cron	отложенные публикации, рассылки
SSL-сертификат	панель хостинга или certbot	браузер ругается на небезопасный сайт
DNS	регистратор или панель	сайт открывается со старого сервера
Счётчики и вебмастеры	Метрика, Вебмастер, Search Console	статистика обрывается
Внешние интеграции	CRM, эквайринг, боты	заявки перестают доходить

По времени типовой сайт-визитка на 300 МБ занимает у меня час чистой работы плюс от получаса до суток на распространение DNS. Магазин на WooCommerce с несколькими гигабайтами загрузок и десятками плагинов растягивается на 3-5 часов, потому что половину времени съедает проверка интеграций.

Сколько будет простоя

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

Опасный момент один: если сайт принимает заказы, между снятием дампа базы и переключением домена могут прийти новые заявки, они останутся на старой копии. Поэтому финальный дамп снимается в момент минимального трафика, а форма на старом сайте на 10-15 минут закрывается заглушкой. Ночь с воскресенья на понедельник для малого бизнеса подходит почти всегда.

Подготовка, без которой не начинаем

Первое: бэкап. Не «у хостера же есть», а свой, скачанный на локальную машину, с проверенной распаковкой. Хостерские снапшоты живут по 7-14 дней и восстанавливаются целиком, а вам может понадобиться вытащить одну таблицу. Минимальный комплект: архив всех файлов сайта, дамп базы, отдельно сохранённый wp-config.php со старыми доступами.

Второе: понизить TTL у DNS-записей за сутки до переезда. Если у A-записи стоит 86400 секунд, то часть посетителей будет ходить на старый IP ещё сутки после переключения. Ставим 300 и ждём, пока протухнет старое значение.

Третье: инвентаризация. Выпишите на бумагу все места, где фигурирует старый домен за пределами сайта:

• личные кабинеты платёжных систем и эквайринга,
• вебхуки CRM и Telegram-ботов,
• SMTP-сервис для писем (SendPulse, Unisender, свой релей),
• Яндекс Метрика и Вебмастер,
• карточка организации в Яндекс Бизнесе,
• подписи в почте, визитки, реклама.

Каждая забытая позиция всплывёт через неделю в виде «а почему заявки не приходят».

Копирование файлов и базы

Тут вариантов немного. Если есть SSH на обоих концах, всё делается одной строкой без промежуточного скачивания на свою машину.

# на старом сервере: архив файлов без мусора
cd ~/old-domain.ru/public_html
tar czf ~/site-files.tar.gz --exclude='wp-content/cache' 
    --exclude='wp-content/backups' --exclude='.git' .

# дамп базы
wp db export ~/site-db.sql --add-drop-table

# передача на новый сервер
scp ~/site-files.tar.gz ~/site-db.sql user@new-server:~/

# на новом сервере: распаковка и заливка
cd ~/new-domain.ru/public_html
tar xzf ~/site-files.tar.gz
wp db create
wp db import ~/site-db.sql

Если SSH нет и есть только FTP с phpMyAdmin, схема та же, но руками: архив собирается плагином вроде Duplicator или All-in-One WP Migration, дамп выгружается через phpMyAdmin с галкой «Добавить DROP TABLE». Учтите лимит на импорт: shared-хостинги часто режут загрузку на 50 МБ, а дамп магазина спокойно весит 300. Тогда либо просите поддержку залить дамп из консоли, либо режете его на части.

После заливки правим wp-config.php под новую базу:

define( 'DB_NAME', 'cr43080_newdb' );
define( 'DB_USER', 'cr43080_newuser' );
define( 'DB_PASSWORD', 'пароль_из_панели' );
define( 'DB_HOST', 'localhost' );

Соль и ключи авторизации оставляйте старые, если не хотите разлогинить всех пользователей. Меняйте их, если сайт до этого взламывали.

Почему обычный поиск и замена ломает сайт

Вот здесь и происходит большинство катастроф. Логика «сделаю sed по дампу, поменяю old-domain.ru на new-domain.ru» выглядит безупречно и работает ровно до первого сериализованного значения.

WordPress хранит массивы настроек в виде PHP-сериализации. Строка внутри такого массива записана вместе со своей длиной:

s:26:"https://old-domain.ru/logo";

Число 26 это количество байт в строке. Когда вы механически заменяете old-domain.ru на new-domain.ru длиной в один символ больше, значение становится 27-байтным, а заявленная длина остаётся 26. PHP при чтении такого значения просто отдаёт false, и настройка пропадает.

Что от этого отваливается на практике: настройки виджетов, галереи и слайдеры, конфигурация форм Contact Form 7 и WPForms, кэш-плагины, настройки темы в кастомайзере, ACF-поля с повторителями. Особенно весело, когда домен новый короче старого: значения не пропадают, а обрезаются посередине, и вы получаете мусор вместо адресов картинок.

Отсюда правило: замену адресов делаем только инструментом, который умеет распаковывать сериализацию, менять содержимое и заново упаковывать с правильной длиной.

Правильная замена через WP-CLI

WP-CLI это штатная консольная утилита WordPress, стоит почти на всех нормальных хостингах. Команда search-replace разбирает сериализованные значения корректно.

# сначала всегда сухой прогон, ничего не меняем
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' 
    --all-tables --precise --recurse-objects --dry-run --report-changed-only

# если отчёт выглядит вменяемо, повторяем без --dry-run
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' 
    --all-tables --precise --recurse-objects --report-changed-only

# добиваем варианты без схемы и с www
wp search-replace '//old-domain.ru' '//new-domain.ru' --all-tables --precise
wp search-replace 'old-domain.ru' 'new-domain.ru' --all-tables --precise

Что делают ключи:

• --all-tables захватывает таблицы без стандартного префикса, их любят создавать плагины,
• --precise отключает быстрый путь через MySQL и гоняет данные через PHP, медленнее, но корректно с сериализацией,
• --recurse-objects заходит внутрь вложенных объектов, а не только массивов первого уровня,
• --dry-run показывает, сколько замен будет сделано, ничего не трогая,
• --report-changed-only убирает из вывода полсотни таблиц с нулями.

Порядок замен важен. Сначала полный адрес со схемой, потом протокол-относительный вариант, и только в конце голый домен. Если начать с голого домена, вы заодно поменяете его внутри email-адресов и в тексте статей там, где он упомянут осознанно.

Отдельно про экранированные адреса. В Gutenberg-блоках и в JSON-настройках слэши экранированы, и адрес выглядит как https://old-domain.ru. WP-CLI такие вхождения сам не ловит, добавляйте ещё один прогон:

wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --all-tables --precise

После всех замен проверьте, что старого домена в базе не осталось:

wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%old-domain.ru%';"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%old-domain.ru%';"

Если WP-CLI на хостинге нет, есть работающая альтернатива: скрипт Search Replace DB от interconnect/it. Кладёте папку в корень сайта, открываете в браузере, делаете замену, сразу удаляете папку. Скрипт даёт полный доступ к базе без авторизации, оставить его на боевом сайте это подарок первому же сканеру.

Плагин Better Search Replace тоже подходит, но им нельзя пользоваться в сценарии, когда админка уже не открывается. А она обычно уже не открывается, потому что до замены адресов сайт живёт по старому домену.

siteurl и home, когда админка недоступна

Классическая петля: залили базу на новый домен, открываете new-domain.ru, вас редиректит на old-domain.ru. Причина в двух опциях таблицы wp_options, где записан адрес сайта. WordPress видит несовпадение и отправляет вас туда, где, по его мнению, сайт живёт.

Три способа развязать эту петлю.

Через WP-CLI, самый быстрый:

wp option update home 'https://new-domain.ru'
wp option update siteurl 'https://new-domain.ru'

Через SQL в phpMyAdmin, если консоли нет:

UPDATE wp_options SET option_value = 'https://new-domain.ru'
  WHERE option_name IN ('home', 'siteurl');

Через wp-config.php, если доступа к базе тоже нет. Добавьте две строки выше комментария о прекращении редактирования:

define( 'WP_HOME', 'https://new-domain.ru' );
define( 'WP_SITEURL', 'https://new-domain.ru' );

Константы в конфиге сильнее записей в базе и не дают их редактировать через админку. Это удобно на время переезда, но потом лучше убрать: забытые константы через год превращаются в загадку «почему поле адреса в настройках серое».

Отдельная мина: у мультисайта адреса лежат ещё и в таблицах wp_blogs, wp_site и wp_sitemeta. Обычный search-replace их зацепит только с ключом --network, иначе сеть останется наполовину на старом домене.

Сертификат и https на новом домене

Новый домен требует нового сертификата, старый на него не распространяется. Порядок такой: сначала А-запись домена указывает на сервер, потом выпускается сертификат, и только потом включается принудительный https. Если поставить редирект на https раньше сертификата, посетители будут упираться в предупреждение браузера.

На большинстве российских хостингов Let’s Encrypt выпускается кнопкой в панели и обновляется автоматически. На своём VPS это certbot:

certbot --nginx -d new-domain.ru -d www.new-domain.ru
certbot renew --dry-run

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

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

После включения https проверьте смешанный контент. Быстрый способ найти остатки:

curl -s https://new-domain.ru/ | grep -o 'http://[^"'"'"']*' | sort -u

Если в выводе есть ссылки на свой же домен по http, значит какие-то адреса в базе остались непеределанными.

Редиректы со старого домена

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

Правильно: постраничный 301 с сохранением пути. Для Apache это .htaccess в корне старого домена:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?old-domain.ru$ [NC]
RewriteRule ^(.*)$ https://new-domain.ru/$1 [R=301,L]

Для nginx отдельный серверный блок:

server {
    listen 443 ssl;
    server_name old-domain.ru www.old-domain.ru;
    ssl_certificate     /etc/letsencrypt/live/old-domain.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old-domain.ru/privkey.pem;
    return 301 https://new-domain.ru$request_uri;
}

Если структура URL меняется вместе с доменом, а так бывает при одновременной смене CMS или перестройке разделов, постраничный редирект собирается картой соответствия. Выгрузите список страниц старого сайта из sitemap.xml, сопоставьте с новыми адресами в таблице и оформите правилами. Пятьдесят строк редиректов писать скучно, зато трафик не проседает.

Держать редиректы нужно минимум год. Я обычно советую не отпускать старый домен три года: продление стоит порядка 200-400 рублей в год для зоны .ru, а внешние ссылки на него живут гораздо дольше, чем кажется.

Чем нельзя заменять 301: маскировкой домена у регистратора (это фрейм, поисковик его не понимает), редиректом 302 (временный, склейка не произойдёт), мета-обновлением в html (медленно и не всегда учитывается).

Проверка после переезда

Это чек-лист, по которому я иду после каждого переезда. Занимает минут двадцать и экономит недели разбирательств.

• Главная и три-четыре внутренние страницы открываются по https без предупреждений.
• Постоянные ссылки работают: зайдите в Настройки, Постоянные ссылки и нажмите «Сохранить» даже без изменений, это пересобирает правила.
• Картинки в старых статьях грузятся, а не отдают 404. Прогоните сайт краулером Screaming Frog в бесплатном режиме до 500 URL.
• Форма обратной связи реально отправляет письмо и заявку в Telegram. Проверяйте с настоящего адреса, а не глядя на зелёную плашку.
• Письма с сайта не улетают в спам: на новом домене нужны свои SPF, DKIM и DMARC-записи.
• Счётчик Метрики стоит на страницах, в интерфейсе Метрики адрес сайта изменён на новый.
• Robots.txt на новом домене не запрещает индексацию (частая мина: с тестового поддомена приезжает Disallow: /).
• Sitemap.xml перегенерирован и содержит новые адреса, старых в нём нет.
• Файл подтверждения прав Яндекс Вебмастера лежит в корне нового домена.
• Крон работает: проверьте wp cron event list, отложенные публикации и рассылки.
• Внешние интеграции переключены на новый адрес по списку из подготовки.

Отдельным шагом идёт заявка на переезд в Яндекс Вебмастере: там есть инструмент «Переезд сайта», который сообщает роботу о смене адреса явно. Оба домена должны быть подтверждены в панели, редирект должен уже работать. Если Вебмастер для вас тёмный лес, начните с разбора Яндекс Вебмастера для новичков.

Потом две недели держите открытым отчёт по 404 в Метрике и раздел «Диагностика» в Вебмастере. Всё, что забыли, всплывёт именно там.

Что чаще всего ломается

За шесть лет практики набор повторяется почти без вариаций.

Битые сериализованные настройки после неаккуратной замены. Симптом: слайдер пропал, настройки формы обнулились, кастомайзер показывает дефолты. Лечится только откатом на бэкап и повторной заменой по-человечески.

Пути к загрузкам с абсолютным адресом. Часть плагинов пишет в базу полный URL картинки, часть относительный. После переезда одни картинки живы, другие нет. Ищите остатки запросом по wp_postmeta, там любят прятаться превью и галереи.

Кэш, который переехал вместе с сайтом. Файлы в wp-content/cache содержат сгенерированную разметку со старым доменом. Чистите каталог руками, не надейтесь на кнопку в плагине.

Смешанный контент из-за жёстко прописанных в теме адресов. Если тема писалась подрядчиком в спешке, в шаблонах могут быть строки вида полного URL логотипа. Замена в базе их не тронет, ищите в файлах темы grep-ом.

Почта, оставшаяся на старом домене. MX-записи переносятся отдельно от сайта, и это самая обидная потеря: заявки уходят в никуда сутками, потому что никто не проверяет ящик.

Сколько это стоит и когда звать человека

Если у вас визитка на десяток страниц, стандартная тема и три плагина, переезд реально сделать самому за вечер. Инструкции выше самодостаточны.

Звать специалиста разумно, когда есть хотя бы одно из: интернет-магазин с историей заказов, мультисайт, самописные плагины, интеграции с 1С или CRM, платёжный шлюз, больше 500 страниц в индексе. Цена переноса домена на рынке в 2026 году держится в районе 6 000-15 000 рублей за визитку и 20 000-45 000 за магазин с интеграциями и картой редиректов. Для сравнения: сайт с нуля стоит порядка 150 000, поэтому аккуратно перевезти существующий почти всегда дешевле, чем городить новый.

У меня перенос домена обычно входит в проектные работы, а если сайт уже на обслуживании, то в рамках месячного лимита часов. Что входит в тарифы и как считаются часы, смотрите в разделе тарифы. Не входит в такую работу разработка с нуля и редизайн: переезд это перенос того, что есть, один в один.

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

Частые вопросы

Как перенести WordPress на другой домен

Скопировать файлы и базу, поменять адрес сайта корректной заменой по базе, обновить конфигурацию, выпустить сертификат на новый домен и настроить редиректы со старого.

Почему обычная замена ломает сайт

Потому что часть настроек хранится сериализованной строкой, где записана её длина. Прямая замена текста меняет длину, а число остаётся старым, и значение перестаёт читаться.

Что делать, если админка недоступна после переноса

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

Сколько занимает перенос

Визитка на несколько сотен мегабайт около часа. Магазин с большим объёмом загрузок и десятками плагинов 3-5 часов, потому что основное время уходит на проверку, а не на копирование.