Миграция большого WordPress-сайта без простоя: рабочие приёмы

При переносе WordPress-магазина на новый сервер можно скопировать базу и файлы за час, а потом обнаружить, что заказы за это время остались на старой площадке. Чтобы переключить большой сайт без заметного простоя, нужно заранее решить, как синхронизировать изменения, проверить новый сервер на реальной копии и только потом направить на него трафик. Подход подходит для WordPress 6.x; конкретные команды и инструменты зависят от хостинга и способа переноса.

Сначала определите, что на сайте меняется

У WordPress две части: файлы и база данных. В файлах лежат ядро, темы, плагины и медиатека; в базе — записи, настройки, пользователи и данные плагинов. Для обычного блога короткая остановка записи может быть приемлема. Для магазина с заказами или сайта с активными комментариями — нет: новая запись после копирования базы не появится на целевом сервере сама собой.

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

• Зафиксируйте размер базы, объём wp-content/uploads и время полного копирования.
• Проверьте версии PHP, СУБД, WordPress и критичных плагинов на старом и новом серверах.
• Уточните у хостинга, доступны ли репликация базы, временный адрес и переключение DNS.
• Сделайте резервную копию и проверьте, что её можно восстановить, а не только создать.
• Снизьте TTL DNS заранее, если управляете зоной. Старое значение кэша может задержать переход части посетителей на новый IP.

Снижение TTL не переносит сайт и не гарантирует мгновенное обновление DNS у каждого провайдера. Оно лишь уменьшает время, в течение которого часть пользователей может обращаться к старому адресу.

Три способа переноса — и их цена

Универсально лучшего варианта нет. Репликация не решает автоматически вопрос с загруженными файлами, очередями задач и плагинами, которые отправляют письма или обращаются к внешним сервисам. Для многих проектов практичнее первый или второй подход: меньше движущихся частей, проще понять, где возникла ошибка.

Рабочий сценарий для большого сайта

1. Поднимите целевую копию

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

2. Проверьте домен и данные без публичного переключения

На временном адресе часть ссылок может вести на старый домен — это нормальный повод проверить замену адресов, а не просто считать перенос завершённым. В базе WordPress встречаются сериализованные значения: механическая замена текста может повредить данные, если меняется длина строки. Для поиска и замены используйте инструмент, учитывающий формат данных, например WP-CLI Search-Replace, и сначала прогоняйте операцию в режиме проверки без записи изменений.

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

3. Установите границу для изменений

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

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

4. Перенесите последние изменения и переключите трафик

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

Проверка: тестовая операция появляется на новом сервере, а логи не показывают массовых ошибок базы, PHP или веб-сервера. После этого снимите временные ограничения.

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

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

• Пропадают новые заказы. Финальную базу скопировали до переключения, а старый сайт продолжал принимать покупки. Нужна граница записи или синхронизация изменений.
• Изображения загружаются на старый сервер. Веб-сервер, CDN или плагин продолжает использовать прежнее хранилище. Проверьте путь загрузки и публичный URL медиатеки.
• Сайт зацикливается на редиректе или показывает старый адрес. Проверьте адрес сайта в настройках, правила веб-сервера, HTTPS и кэш. Не очищайте данные вслепую на рабочем сайте.
• Письма уходят дважды или не уходят. На старой и новой площадке одновременно работают cron-задачи или отправка через внешний сервис. Разведите роли и проверьте очередь писем.
• Часть пользователей видит старый сайт. DNS-кэш обновляется не одновременно. Не выключайте старый сервер сразу после смены записи: часть трафика ещё может приходить туда.

Сноска. Репликация — автоматическая передача изменений из одной базы данных в другую. Реплика может отставать от основной базы; перед переключением важно убедиться, что она догнала источник.

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

До миграции проведите репетицию на копии сайта и измерьте время каждого этапа: перенос базы, файлов, финальная синхронизация и проверка. Запишите критерии отката — например, какие ошибки или потеря функций означают, что трафик нужно вернуть. После переключения следите за заказами, ошибками PHP и веб-сервера, отправкой писем и доступностью сайта. Старую площадку сохраняйте до тех пор, пока не подтвердите целостность данных на новой.

Если выбираете WP-CLI для замены адресов, сверяйте синтаксис с документацией установленной версии: команда и параметры должны соответствовать вашему окружению. Инвалидация кэша и SEO-аудит после переноса — отдельные задачи; здесь важнее не потерять данные при смене сервера.