Переезд WordPress на другой хостинг: что проверить заранее

Результат, к которому идём: сайт целиком работает на новом хостинге, старый остаётся живым как кнопка отката, а посетители видят недоступность в пределах 5-15 минут. На всю работу руками уходит от двух до шести часов — зависит от объёма медиафайлов и размера базы. Больше всего сюрпризов даёт не копирование файлов, а несовпадение версий PHP и MySQL между старым и новым сервером. Поэтому начинаем не с бэкапа, а с инвентаризации.

Что нужно иметь до начала

• Доступ по SSH к обоим серверам. Если на старом хостинге только FTP и phpMyAdmin — переезд возможен, но копирование 20 ГБ медиа по FTP займёт часы вместо минут.
• Доступ в панель управления DNS — у регистратора домена или у того, чьи NS-серверы прописаны. Это отдельный доступ, он часто теряется: проверьте его заранее, а не в момент переключения.
• Данные новой базы: имя, пользователь, пароль, хост. Хост не всегда localhost — на части хостингов это отдельный сервер или сокет.
• Версии на обоих серверах: PHP, MySQL или MariaDB, WordPress. Выпишите их на бумагу. WordPress 6.x работает с PHP 7.2 и выше, рекомендованная версия — 7.4+; актуальные требования сверяйте на странице требований wordpress.org, они меняются с релизами.
• Размер сайта: вес каталога с файлами и вес базы. Нужно убедиться, что на новом тарифе хватит места и что импорт дампа не упрётся в лимит max_allowed_packet.
• Список премиум-плагинов и тем с лицензиями. Часть лицензий привязана к домену или к числу активаций — после переезда их придётся переактивировать.
• Техническое окно: время, когда трафика меньше всего. Переключать DNS в пятницу вечером — плохая идея, поддержка хостинга отвечает медленнее.

Четыре вещи, из-за которых переезд ломается

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

Несовпадение MySQL и MariaDB

Дамп из MySQL 8 несёт в себе кодировку utf8mb4_0900_ai_ci, которой нет в MariaDB. Импорт упадёт на первой же таблице. Обратная ситуация тоже бывает. Лечится заменой кодировки в дампе — ниже покажу, как.

Drop-in-файлы кеша

Если на старом хостинге стоял Redis или Memcached, в wp-content лежит object-cache.php, а иногда и advanced-cache.php. На новом сервере Redis может быть не поднят — сайт отдаст белый экран ещё до того, как вы дойдёте до проверки темы. Эти файлы удаляют до переноса.

Адрес сайта в базе

Адрес хранится в таблице wp_options (поля siteurl и home) и дополнительно рассыпан по контенту в сериализованных массивах настроек плагинов. Массовая замена через SQL-запрос REPLACE ломает сериализацию: длины строк в ней указаны числом. Если домен не меняется, трогать ничего не нужно. Если вы проверяете сайт на временном домене хостера — замену делают только через WP-CLI.

Кеш DNS

Часть посетителей после переключения ещё несколько часов будет попадать на старый сервер. Заказы и комментарии, оставленные там, на новый сайт не попадут. Снижение TTL¹ за сутки до переезда сокращает это окно до минут.

Старый хостинг не отключают сразу. Пока он жив, у вас есть откат: вернуть прежнюю A-запись дешевле, чем восстанавливать базу из дампа на падающем сайте.

Порядок действий

1. За сутки: снизьте TTL. В панели DNS выставьте для A-записи домена значение 300 секунд. Проверка:

   dig example.com A +noall +answer

   В выводе перед типом записи стоит TTL — он должен стать 300 или меньше.

2. Соберите инвентарь. На старом сервере:

   php -v
   mysql --version
   wp core version
   du -sh ~/public_html
   du -sh ~/public_html/wp-content/uploads

   То же самое — на новом (кроме wp core version). Проверка: у вас есть две строки версий PHP и две строки версий СУБД, и они либо совпадают, либо вы знаете, в чём разница. Команды WP-CLI здесь и дальше — для версии 2.x.

3. Отключите кеш и удалите drop-in-файлы. В админке деактивируйте плагины кеширования, затем на сервере:

   cd ~/public_html/wp-content
   rm -f object-cache.php advanced-cache.php
   ls -la | grep -E 'object-cache|advanced-cache'

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

4. Сделайте бэкап файлов и базы. Это не формальность: дамп базы вам сейчас понадобится для переноса.

   # база; подставьте своего пользователя и имя базы из wp-config.php
   mysqldump --single-transaction --default-character-set=utf8mb4 \
     -u db_user -p old_wp_db > ~/old_wp_db.sql
   
   # файлы
   cd ~/public_html
   tar -czf ~/wp-files.tar.gz .
   
   # проверка целостности архива и размера дампа
   tar -tzf ~/wp-files.tar.gz > /dev/null && echo 'архив читается'
   ls -lh ~/old_wp_db.sql ~/wp-files.tar.gz

   Проверка: в выводе есть строка «архив читается», а размер дампа — не ноль и не пара килобайт.

5. Скопируйте всё на новый сервер. Если SSH есть с обеих сторон:

   rsync -avz --progress ~/wp-files.tar.gz ~/old_wp_db.sql \
     user@new-host:/home/user/

   Если старый хостинг без SSH — скачайте оба файла себе и загрузите на новый по SFTP. Проверка: на новом сервере ls -lh показывает те же размеры файлов.

6. Распакуйте файлы и импортируйте базу. На новом сервере:

   mkdir -p /var/www/example.com
   tar -xzf ~/wp-files.tar.gz -C /var/www/example.com
   
   mysql -u new_db_user -p new_wp_db < ~/old_wp_db.sql

   Если импорт упал с ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' — почините кодировку в дампе и повторите:

   sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' ~/old_wp_db.sql
   mysql -u new_db_user -p new_wp_db < ~/old_wp_db.sql

   Проверка: mysql -u new_db_user -p -e 'SHOW TABLES' new_wp_db выводит список таблиц WordPress с вашим префиксом.

7. Поправьте wp-config.php. Что именно менять — в таблице ниже. Проверка: из каталога сайта выполните wp db check, ответ должен быть без ошибок подключения.

8. Проверьте сайт до переключения DNS. Добавьте на своём компьютере в файл hosts строку с IP нового сервера и вашим доменом (в Linux и macOS это /etc/hosts, в Windows — C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10 example.com www.example.com

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

9. Переключите DNS и выпустите сертификат. Поменяйте A-запись (и AAAA, если есть) на IP нового сервера. Сертификат Let's Encrypt выпускается только после того, как домен начал указывать на новый сервер. Проверка:

   dig example.com A +short
   curl -I https://example.com

   В первом выводе — новый IP, во втором — HTTP/2 200 без предупреждений о сертификате.

10. Доделайте хвосты. В админке зайдите в настройки постоянных ссылок и нажмите «Сохранить» — это перезапишет правила. Через WP-CLI то же самое: wp rewrite flush --hard. Включите обратно плагины кеширования. Отправьте тестовое письмо через форму на сайте. Проверка: внутренняя страница открывается без 404, письмо дошло.

Что вписать в wp-config.php

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

Если не получилось

• «Error establishing a database connection». Неверные данные в wp-config.php или пользователю не выданы права на базу. Проверьте подключение напрямую: mysql -u new_db_user -p new_wp_db. Если напрямую не пускает — дело не в WordPress, идите в панель хостинга выдавать права.
• Белый экран, в debug.log строка PHP Fatal error: Uncaught Error: Call to undefined function .... На новом сервере другая версия PHP или не хватает расширения. Сравните php -m на обоих серверах — чаще всего не хватает mbstring, intl, imagick или zip.
• Белый экран сразу после распаковки файлов. Остался object-ache.php или advanced-cache.php, который стучится в несуществующий Redis. Удалите drop-in-файлы и обновите страницу — шаг 3 закрывает эту проблему заранее, но при переносе готовым бэкапом из плагина они возвращаются.
• Главная работает, внутренние страницы отдают 404. Не перенёсся .htaccess (он начинается с точки, многие FTP-клиенты его скрывают) или на новом сервере Nginx без правил для постоянных ссылок. Пересохраните настройки ссылок, а на Nginx попросите поддержку добавить обработку try_files для WordPress.
• Сайт редиректит на старый адрес или на домен хостера. В базе остались прежние siteurl и home. Посмотрите текущее значение: wp option get siteurl. Если проверяли сайт на временном домене и теперь нужно вернуть основной, меняйте адреса только через WP-CLI, с предварительным прогоном:

  wp search-replace 'https://temp.hosting-domain.ru' 'https://example.com' \
    --all-tables --precise --skip-columns=guid --dry-run

  Убедитесь, что число замен выглядит разумно, затем запустите ту же команду без --dry-run. Браузер может помнить 301-редирект — проверяйте в приватном окне.
• «The uploaded file could not be moved to wp-content/uploads». После rsync или распаковки архива от root файлы принадлежат не тому пользователю, под которым работает PHP. Выясните этого пользователя у хостера и смените владельца каталога сайта.

Что делать дальше

Старый хостинг держите оплаченным минимум две недели. За это время разойдётся кеш DNS, а вы успеете заметить то, что не проверили: редкие формы, интеграции по API с внешними сервисами, выгрузки в маркетплейсы, которые ходят на сайт по IP.

Дальше по списку: вернуть WP_DEBUG в false, настроить бэкапы на новом месте и один раз проверить, что из них восстанавливается база, подключить SMTP вместо серверной почты (письма с нового IP чаще попадают в спам), посмотреть в Search Console динамику ошибок сканирования за неделю после переезда. Если на старом сервере стоял серверный cron с вызовом wp-cron.php — его придётся пересоздать вручную, в файлах сайта он не лежит. Перенос почты с домена и переезд на другую версию PHP — отдельные задачи, здесь мы их не затрагивали.

¹ TTL (time to live) — время в секундах, в течение которого провайдеры и браузеры хранят в кеше DNS-ответ. При TTL 86400 посетитель может ещё сутки после переключения попадать на старый сервер, при TTL 300 — пять минут.

² Drop-in — файл особого типа в WordPress, который подхватывается ядром по имени, без активации в списке плагинов. Самые частые: object-cache.php и advanced-cache.php, их создают плагины кеширования.