Переезд сайта похож на смену квартиры: если заранее собрать коробки, придумать маршрут и не забыть кота, всё проходит гладко. Пошаговая инструкция: как перенести сайт WordPress на новый хостинг без потерь, помогает именно в такие моменты, когда цена ошибки — часы простоя и потерянные письма. Ниже — выверенный маршрут, по которому я не раз переводил проекты, от блогов до магазинов.
Договоримся о главном: действуем спокойно, делаем полный бэкап, проверяем всё на техническом адресе, а уж потом переключаем трафик. Этот порядок и даёт ту самую уверенность, когда кнопка «изменить DNS» перестаёт пугать.
Подготовка: фиксируем текущее состояние
Сначала посмотрите на версию PHP и MySQL у нового провайдера, список расширений и лимиты. Сравните с тем, что требует ваша тема и плагины. Если сайт живой и принимает заказы, включите режим обслуживания или договоритесь о «окне тишины», чтобы не потерять новые записи.
За сутки снизьте TTL у домена хотя бы до 300 секунд. Это ускорит последующее переключение. Сделайте два бэкапа: файлов по SFTP и базы данных через phpMyAdmin или консоль. Храните их в безопасном месте, не на том же сервере.
Файлы и база: забираем всё до байта
Скачайте весь корень сайта, не только wp-content. Часто забывают про .htaccess, wp-config.php и скрытые файлы — а потом удивляются редиректам и 404. Удобно упаковать содержимое в архив на сервере и скачать одним файлом, это быстрее.
Экспортируйте базу с корректной кодировкой utf8mb4 и нужной сортировкой. В консоли подойдёт mysqldump, в WP-CLI — команда wp db export. Если база большая, включите сжатие, чтобы не упереться в лимиты загрузки на новом хостинге.
Разворачиваем на новом хостинге
Создайте пустую базу, пользователя и выдайте ему все привилегии. Залейте файлы, проверьте права: для каталогов 755, для файлов 644, владелец — системный пользователь веб-сервера. Это убережёт от капризов при загрузке медиа.
В wp-config.php пропишите новые DB_NAME, DB_USER, DB_PASSWORD и DB_HOST, не меняйте префикс таблиц. Импортируйте базу. Если меняется домен или включаете https, запустите замену ссылок: в WP-CLI это wp search-replace 'http://старый-домен' 'https://новый-домен' --all-tables. Затем в админке откройте «Постоянные ссылки» и просто сохраните — структура перепишется и исчезнут 404.
Тестирование на техническом домене
Не спешите с DNS. Поднимите сайт на временном поддомене или пропишите новый сервер в файле hosts локально. Проверьте вход в админку, загрузку картинки, оформление заказа, отправку форм, работу кэша и минификации.
Сразу подключите SSL от Let’s Encrypt и включите принудительный https. Если кэш-плагин был выключен на время переноса, включите обратно и очистите кэш, заодно проверьте gzip и HTTP/2 у хостера.
Переключаем трафик аккуратно
Когда всё работает, меняйте A и AAAA-записи у домена на новый IP. За счёт сниженного TTL пользователи переключатся быстро, но в течение пары часов держите старую копию наготове. Если почта обслуживается у старого хостера, не трогайте записи MX или перенесите ящики заранее.
На время распространения DNS не вносите контент на старом сервере. Как только трафик стабильно идёт на новый, очистите кэши, проверьте логи ошибок, верните TTL к прежнему значению и отключите старую копию, чтобы не плодить путаницу.
Распространенные ошибки и как их лечить
Даже при аккуратном переезде всплывают мелочи. Ниже — короткая памятка, которая экономит часы.
| Симптом | Что сделать |
|---|---|
| Белый экран | Включить WP_DEBUG, временно переименовать папку plugins, проверить лимит памяти и ошибки PHP |
| Крякозябры в тексте | Проверить кодировку дампа и параметры соединения, убедиться в utf8mb4 |
| Бесконечные редиректы | Сверить siteurl и home, настройки https, правила в .htaccess или конфиг Nginx |
| Не открываются вложения | Права на wp-content/uploads, правильный путь загрузки в настройках |
| Выкидывает из админки | Обновить salts, проверить домен куки и время на сервере |
Полезно настроить реальный cron на сервере и отключить псевдо WP-Cron, чтобы задачи не зависели от посещаемости.
Короткий чек-лист
Если нервничаете, пробегитесь глазами по пунктам и отметьте сделанное.
- Снизить TTL у домена за сутки до переноса
- Сделать полный бэкап файлов и базы
- Скопировать файлы на новый хост, развернуть базу
- Выполнить search-replace домена и http→https
- Проверить сайт на техническом адресе
- Подключить SSL, сохранить «Постоянные ссылки», включить кэш
- Переключить DNS и наблюдать логи
- Вернуть TTL и убрать старую копию
Отдельным пунктом держите под рукой доступы: SFTP, панель, база, реестр домена. Когда всё собрано, процесс идёт как по нотам.
Личный штрих
Однажды переносил крупный журнал в ночь на понедельник, и именно запись в hosts спасла от спешки: мы вылизали правки на «сером» домене и только потом щёлкнули DNS. Читатели ничего не заметили, а редакция утром увидела быстрый сайт и спокойно начала выпуск.
Этот маршрут не про хитрости, а про дисциплину. Делайте бэкап, тестируйте на черновом адресе, не торопите DNS — и переезд превращается в рабочую рутину, после которой сайт дышит легче.