Перенос WordPress на другой хостинг: ошибки новичков

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

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

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

• Доступ к старому хостингу: SSH или FTP к файлам и phpMyAdmin (либо SSH-доступ к MySQL). Только панели управления сайтом недостаточно.
• Доступ к новому хостингу: панель для создания базы, FTP/SSH, права на создание домена или поддомена.
• Доступ к DNS — там, где прописаны NS-записи домена: у регистратора или у текущего хостера. Это отдельный логин, его часто не помнят.
• Версии PHP и MySQL на обеих сторонах. Запишите их. Переезд с PHP 7.4 на 8.2 — это отдельная история с обновлением плагинов, а не просто копирование файлов.
• Версия WordPress — в админке на странице «Обзор». Инструкция рассчитана на WordPress 6.x; для 4.x и 5.x порядок тот же, но старые плагины на новом PHP могут отвалиться.
• Место на диске локально или на новом сервере под архив и дамп базы.
• Текущий лимит загрузки дампа в phpMyAdmin нового хостера (обычно 50–100 МБ). Если база больше, переносить её придётся через консоль.

Перенос по шагам

1. Сбейте TTL и соберите цифры. В панели DNS уменьшите TTL A-записи домена до 300 секунд и подождите столько, сколько было прописано до этого (часто 4 или 24 часа). Тогда в момент переключения провайдеры подхватят новый адрес за минуты, а не за сутки. Параллельно посмотрите размер папки сайта и размер базы.

   du -sh ~/public_html
   wp db size --tables --human-readable

   Проверка: в панели DNS у A-записи стоит TTL 300, а вы знаете два числа — вес файлов и вес базы.

2. Снимите дамп базы. Если есть SSH и WP-CLI (версия 2.x):

   cd ~/public_html
   wp db export dump.sql --default-character-set=utf8mb4

   Без WP-CLI — напрямую через mysqldump, подставив имя базы и пользователя из wp-config.php:

   mysqldump --single-transaction --default-character-set=utf8mb4 \
     -u DB_USER -p DB_NAME > dump.sql

   Проверка: файл не нулевого размера, а в последних строках есть -- Dump completed. Команда tail -n 3 dump.sql покажет это за секунду. Обрыв дампа на середине — самая дорогая ошибка переезда, потому что обнаруживается она уже после импорта.

3. Упакуйте файлы вместе со скрытыми. Точка в конце команды важна: без неё в архив не попадёт .htaccess, и все внутренние страницы на новом сервере будут отдавать 404.

   cd ~/public_html
   tar -czf ../site-files.tar.gz .

   Проверка: tar -tzf ../site-files.tar.gz | grep htaccess выводит строку с файлом. Если переносите файлы через FTP-клиент, включите показ скрытых файлов в настройках клиента, иначе та же проблема вернётся.

4. Создайте базу на новом хостинге и залейте файлы. В панели нового хостера создайте базу, пользователя и выдайте ему все права на эту базу. Кодировку выбирайте utf8mb4. Файлы удобнее гнать rsync прямо между серверами, минуя свой компьютер:

   rsync -avz -e ssh --exclude 'wp-content/cache' \
     ~/public_html/ user@new-host:/var/www/example.com/public_html/

   Проверка: на новом сервере в корне лежат wp-config.php, wp-load.php, папки wp-content и wp-admin, а ls -la показывает .htaccess.

5. Перепишите wp-config.php. Правьте файл уже на новом сервере. Значения берите из панели нового хостинга, а не из старого конфига: совпадать может разве что префикс таблиц.

6. Импортируйте базу. С WP-CLI — одна команда из корня сайта:

   wp db import dump.sql

   Или напрямую, если WP-CLI на новом хостинге нет:

   mysql -u DB_USER -p DB_NAME < dump.sql

   Проверка: wp option get home и wp option get siteurl возвращают адрес вашего сайта. Через phpMyAdmin то же самое видно в таблице wp_options в строках home и siteurl.

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

   203.0.113.25 example.com www.example.com

   Проверка: в вашем браузере сайт открывается с нового сервера, у остальных — со старого. Пройдите по главной, одной записи, одной странице категории, карточке товара, форме обратной связи и админке. Загрузите тестовую картинку в медиабиблиотеку — так проверяются права на запись в wp-content/uploads.

8. Переключите DNS и выпустите сертификат. Поменяйте A-запись на IP нового сервера. Сразу после этого выпустите SSL на новом хостинге (у большинства это кнопка «Let's Encrypt» в панели) и сбросьте правила ссылок:

   wp rewrite flush --hard
   wp cache flush

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

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

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

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

«Error establishing a database connection»

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

«Unknown collation: 'utf8mb4_0900_ai_ci'» при импорте

Дамп снят с MySQL 8, а новый хостинг работает на MariaDB или MySQL 5.7, где такого сравнения нет. Поправьте дамп до импорта и повторите:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' dump.sql

Все внутренние страницы отдают 404, главная работает

Почти всегда потерян .htaccess — FTP-клиент не показал скрытые файлы. Залейте его отдельно, затем зайдите в «Настройки — Постоянные ссылки» и нажмите «Сохранить» или выполните wp rewrite flush --hard. Если новый хостинг на Nginx без Apache, .htaccess не читается вовсе: правила для постоянных ссылок задаются в конфигурации сервера, точный вид блока уточните в документации хостера.

«There has been a critical error on this website» или белый экран

Фатальная ошибка PHP. Добавьте в wp-config.php выше строки с require_once:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Обновите страницу и откройте wp-content/debug.log. Два типичных виновника. Первый — скачок версии PHP: старый плагин или тема не работают на 8.x, в логе будет имя файла внутри конкретной папки плагина. Второй — осиротевшие drop-in файлы wp-content/object-cache.php и wp-content/advanced-cache.php: они остались от Redis или кеширующего плагина, которых на новом сервере нет. Переименуйте такой файл и проверьте снова. Отладочные константы после разбора уберите, иначе лог вырастет и станет публично читаемым.

Картинки и ссылки ведут на старый адрес

Так бывает, когда вместе с хостингом меняется домен или сайт переезжает с http на https. Не правьте базу запросом UPDATE ... REPLACE через phpMyAdmin: это ломает сериализованные данные в настройках темы и конструкторов страниц. Используйте WP-CLI, сначала вхолостую:

# сухой прогон: покажет, сколько замен будет сделано, но не изменит базу
wp search-replace 'http://old-domain.ru' 'https://new-domain.ru' \
  --all-tables --precise --skip-columns=guid --dry-run

# если числа выглядят разумно, запускаем без --dry-run
wp search-replace 'http://old-domain.ru' 'https://new-domain.ru' \
  --all-tables --precise --skip-columns=guid

Перед запуском сделайте копию базы на новом сервере: wp db export before-replace.sql.

Сериализованные данные — способ, которым WordPress хранит массивы настроек в одном текстовом поле базы. В такой строке перед каждым значением записана его длина: s:21:"http://old-domain.ru/". Простая замена текста меняет адрес, но не меняет число 21, и WordPress перестаёт читать весь блок настроек. Отсюда пропавшие виджеты, сброшенные настройки темы и пустые блоки конструктора. wp search-replace пересчитывает длины и потому безопасен.

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

• Не удаляйте старый хостинг минимум две недели. Оплатите лишний месяц: это дешевле, чем восстанавливать сайт из воздуха, если через неделю обнаружится потерянная папка загрузок.
• Проверьте отправку писем. Новый IP-адрес для почтовых систем незнаком, и письма от формы заявки или о заказе уходят в спам. Настройте отправку через SMTP вместо PHP mail().
• Проверьте, как переехала почта на домене. Если ящики жили у старого хостера, MX-записи нужно оставить или перенести отдельно — они не связаны с A-записью сайта.
• Включите резервные копии на новом хостинге. Расписание бэкапов со старого сервера не переезжает вместе с файлами.
• Неделю смотрите в логи сервера на 404 и 500 и загляните в отчёт по индексированию в Search Console. Одиночные 404 после переезда обычно означают файл, не попавший в архив.