Перенос WordPress на другой хостинг без простоя делаю по одной и той же схеме уже несколько лет: сначала поднимаю копию сайта на новом сервере, проверяю её вручную через файл hosts, и только потом переключаю DNS. Ниже разберу весь процесс по шагам, с конкретными командами и цифрами по времени, которые получались у меня на реальных проектах, включая интернет-магазины на WooCommerce с приёмом платежей через Т‑Банк и доставкой от СДЭК.
С чего начинается перенос WordPress на другой хостинг
Первое, что я делаю перед переездом, это фиксирую версию PHP, MySQL и список установленных модулей на старом сервере. WordPress не капризен сам по себе, но плагины вроде WooCommerce, Yoast SEO или кастомные модули эквайринга часто требуют конкретную версию PHP - 8.1 или 8.2, и если на новом хостинге стоит 7.4, сайт после переноса выдаст белый экран.
Дальше смотрю на объём сайта: сколько весит база данных и папка wp-content/uploads. Для интернет-магазина с каталогом на 3-5 тысяч товаров база обычно занимает 200-500 МБ, а медиафайлы - от 2 до 15 ГБ. Это напрямую влияет на способ переноса: через плагин, через SSH и wp-cli, или через панель хостинга с прямой миграцией между серверами.
Подготовка сайта к переезду без простоя
Простой при переносе возникает не из-за копирования файлов, а из-за DNS - домен продолжает указывать на старый сервер, пока запись не обновится везде. Чтобы избежать разрыва, действую так:
- За сутки-двое до переноса снижаю TTL у DNS-записи A до 300 секунд (5 минут). Обычно TTL стоит на 3600-14400 секунд, и если не снизить его заранее, домен может «залипнуть» на старом IP на несколько часов после смены.
- Поднимаю сайт на новом хостинге на технический поддомен или по IP-адресу, чтобы протестировать его до переключения DNS.
- Прописываю новый IP в файле hosts на своём компьютере - это позволяет открыть сайт с боевым доменом, но фактически смотреть версию на новом сервере, пока остальные пользователи видят старую.
На Windows файл hosts лежит по пути C:WindowsSystem32driversetchosts, на macOS и Linux - /etc/hosts. Строка добавляется в формате:
195.201.XX.XX example.ru
195.201.XX.XX www.example.ruПосле проверки строку из hosts обязательно удаляю, иначе через пару дней забуду про неё и буду недоумевать, почему сайт у меня открывается не так, как у всех.
Перенос базы данных и файлов
Для небольших сайтов на 1-2 ГБ пользуюсь плагином All-in-One WP Migration - он архивирует базу, файлы и настройки в один файл и разворачивает всё на новом хостинге за 10-20 минут. Ограничение бесплатной версии - экспорт до 512 МБ, для сайтов побольше нужен либо платный модуль расширения лимита, либо перенос вручную через SSH.
Вручную процесс выглядит так: делаю дамп базы через mysqldump, переношу его вместе с папкой wp-content по SFTP или rsync, затем разворачиваю базу на новом сервере и правлю wp-config.php с новыми данными подключения. Если домен на новом сервере отличается от старого (например, тестовый поддомен), обязательно меняю адреса через wp-cli, а не через обычный SQL-запрос UPDATE - в базе WordPress куча сериализованных данных (настройки виджетов, метаданные товаров WooCommerce), и прямая замена строки поиском-заменой в PHPMyAdmin ломает их формат.
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --all-tablesЭта команда учитывает сериализацию и проходит по всем таблицам, включая метаполя товаров и заказов - для магазина на WooCommerce это критично, иначе после переезда изображения товаров и ссылки в письмах об заказе будут вести на старый сервер.
Таблица сравнения способов переноса, которыми я пользуюсь чаще всего:
| Способ | Когда подходит | Время на перенос |
|---|---|---|
| All-in-One WP Migration | Сайт до 500 МБ, нет доступа по SSH | 15-30 минут |
| Ручной перенос через SSH и wp-cli | Большие каталоги, интернет-магазины, кастомные интеграции | 1-3 часа |
| Миграция средствами хостинга (cPanel to cPanel и подобные) | Переезд между хостингами одного провайдера или партнёров | 30-60 минут |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
DNS и TTL: как избежать простоя при смене хостинга
Когда копия сайта на новом сервере проверена и работает корректно, обновляю A‑запись домена у регистратора или в DNS-панели (Cloudflare, Timeweb, REG.RU - принцип везде одинаковый). Поскольку TTL заранее снижен до 300 секунд, большинство резолверов подхватывают новый IP за 5-15 минут. Полное распространение по всем DNS-серверам мира теоретически может занять до 24-48 часов, но на практике за 3-5 лет переносов я ни разу не видел растягивания больше 2-3 часов, а обычно всё стабилизируется за первый час.
Пока часть посетителей ещё видит старый сервер, а часть - новый, важно держать оба варианта рабочими и синхронизированными. Если сайт принимает заказы (форма, корзина, оплата), в это переходное окно возможна ситуация, когда заказ уйдёт на старую базу, которая через час станет неактуальной. Поэтому для магазинов с реальными продажами я стараюсь либо выбирать окно с минимальным трафиком (ночь, будни), либо на время перехода включать на старом сервере уведомление и временно ограничивать оформление заказов через баннер.
После снижения TTL и переключения записи ставлю SSL-сертификат на новом сервере заранее - через Let’s Encrypt это делается за пару минут командой certbot, но сертификат должен быть выпущен до того, как на домен пойдёт реальный трафик, иначе часть посетителей увидит предупреждение о недоверенном соединении.
WooCommerce, эквайринг и СДЭК: нюансы после переезда
С интернет-магазинами перенос не заканчивается на копировании файлов и базы. У меня был случай с магазином на WooCommerce, где после переезда на новый VPS перестали приходить уведомления об оплате от Т‑Банка - оказалось, что в личном кабинете эквайринга был прописан webhook на конкретный IP-адрес старого сервера как дополнительная защита, и после смены хостинга нужно было обновить его на новый.
То же самое касается интеграции с СДЭК: если API-запросы на расчёт доставки или создание заказа шли с IP старого сервера и он был внесён в белый список, после переезда доставка может просто перестать считаться, без явной ошибки в интерфейсе - запрос будет уходить в никуда. Проверяю такие вещи сразу после переключения DNS: делаю тестовый заказ с реальной оплатой на минимальную сумму и смотрю, что вебхук дошёл, статус заказа обновился, а письмо с накладной СДЭК ушло клиенту.
Если у проекта много таких внешних интеграций и разбираться с ними самостоятельно рискованно, для сложных случаев обычно выгоднее заказать сопровождение переноса, чем потом восстанавливать потерянные заказы - у меня есть услуга переноса и настройки сайтов на WordPress именно под такие сценарии, где нужно свести миграцию сервера с работающими платежами и доставкой без потерь.
Также не забываю про cron-задачи WordPress (wp-cron) - если на старом хостинге были настроены реальные cron-задания через панель, а не встроенный псевдо-крон WordPress, их нужно продублировать на новом сервере вручную, иначе перестанут работать плановые публикации, синхронизация остатков и рассылки писем брошенной корзины.
Типичные ошибки при миграции WordPress
За практику накопился список того, что чаще всего идёт не так:
- Забывают поменять URL сайта в базе через сериализацию-безопасный инструмент, из-за чего часть страниц или изображений после переезда ведёт на старый домен.
- Не проверяют версию PHP на новом хостинге заранее - сайт падает с белым экраном, а разбираться приходится уже при живом трафике.
- Оставляют старый хостинг сразу после переключения DNS, хотя часть пользователей ещё может обращаться к старому IP несколько часов - лучше держать старую версию активной минимум 3-5 дней.
- Не переносят файл .htaccess с правилами редиректов и обработкой ЧПУ - после переезда все внутренние ссылки начинают отдавать 404.
- Забывают про SSL-сертификат на новом сервере и включают домен без него, что бьёт по доверию посетителей и по позициям в поиске.
Из этого списка чаще всего встречается именно проблема с sql-заменой URL вручную - разработчики без опыта миграций делают это через обычный SQL UPDATE и получают битые настройки виджетов, слайдеров и метаполей товаров, которые потом приходится восстанавливать из бэкапа.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько по времени занимает перенос WordPress на другой хостинг
Для обычного сайта-визитки с базой до 500 МБ перенос вместе с проверкой занимает 2-4 часа, включая ожидание распространения DNS. Для интернет-магазина с крупным каталогом и внешними интеграциями (эквайринг, СДЭК, CRM) закладываю 1-2 дня с учётом тестирования всех сценариев заказа на новом сервере.
Можно ли перенести сайт вообще без даунтайма
Полностью без единой секунды простоя перенести сайт нельзя, потому что момент переключения DNS всегда есть, но за счёт снижения TTL заранее и предварительной проверки копии на новом сервере реальный простой сводится к нескольким минутам или вообще незаметен для посетителей, если старый сервер остаётся активным во время распространения DNS.
Что делать, если после переезда сайт открывается с ошибками подключения к базе
В 90% случаев причина в неверных данных в wp-config.php - имя базы, пользователь, пароль или хост базы данных на новом сервере отличаются от старых. Проверяю эти четыре параметра в первую очередь, и только если они верны, смотрю права доступа пользователя базы или блокировку по IP на стороне хостинга.
Нужно ли менять хостинг, если сайт просто медленно работает
Не всегда - иногда причина в неоптимизированных плагинах, отсутствии кеширования или тяжёлых изображениях без сжатия, и перенос на другой сервер даст временный эффект, а через полгода проблема вернётся. Перед переездом стоит сначала прогнать сайт через профилировщик вроде Query Monitor, чтобы понять, действительно ли дело в ресурсах хостинга.