Практическое руководство по миграции сайта: 7 шагов

Практическое руководство по миграции сайта начинается с аудита

Сначала определите, что именно вы переносите. Одной папки public_html часто недостаточно. WordPress, Joomla, Laravel и другие платформы хранят важные данные в базе данных, а отдельно управляемые сервисы могут включать электронную почту, поддомены, задания cron, SSL-сертификаты, редиректы и DNS-записи.

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

На этом этапе не стоит предполагать, что «новый сервер точно мощнее». Например, новый VPS может предоставить больше ресурсов, но потребовать знаний в области управления сервером. Shared Linux hosting может быть удобнее для сайта с предсказуемой посещаемостью, которому не нужен root-доступ. Выбор зависит не только от скорости, но и от того, кто будет отвечать за обновления, резервные копии и безопасность.

1. Создайте независимую резервную копию и проверьте её

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

Не ограничивайтесь уведомлением «backup completed». В тестовой среде откройте экспорт базы данных, проверьте файлы архива и убедитесь, что у вас есть необходимые пароли для восстановления. Самое неподходящее время обнаружить повреждённую резервную копию — после изменения DNS.

2. Подготовьте новый хостинг до переноса

На новом сервисе создайте домен, базу данных, необходимых пользователей и соответствующие настройки PHP. Если сайту требуются специальные расширения, например ionCube, Imagick или определённые модули PHP, проверьте их заранее. Для проектов Laravel учитывайте файл environment, обработку очередей, scheduler и каталоги, для которых требуется разрешение на запись.

Также создайте необходимые почтовые ящики, но не спешите менять MX-записи. Так вы сможете сначала убедиться, что новая почтовая среда готова, не прерывая текущую переписку. Если вы используете Google Workspace или другой внешний почтовый сервис, во время миграции особенно внимательно сохраните записи MX, SPF, DKIM и DMARC.

3. Уменьшите DNS TTL и скопируйте данные

За 24–48 часов до изменения DNS уменьшите TTL, например до 300 или 600 секунд. Это означает, что после изменения кэши интернет-провайдеров обычно обновятся быстрее. Уменьшение TTL не даёт мгновенного результата, поскольку прежнее высокое значение ещё может сохраняться у некоторых резолверов. Поэтому это следует сделать заранее, а не в момент переноса.

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

Если URL-адреса меняются, например сайт переносится с временного адреса на основной домен, выполните контролируемый поиск и замену в базе данных. В WordPress простая текстовая замена может повредить сериализованные данные, поэтому используйте инструмент, подходящий для данной платформы, или обратитесь за помощью к опытному специалисту.

4. Протестируйте сайт без изменения публичного DNS

До того как направлять посетителей на новый сервер, проверьте сайт через файл hosts или временный адрес, предоставленный хостингом. Это позволяет открыть домен с нового IP на вашем компьютере, пока остальные пользователи продолжают видеть работающий сайт.

Тестирование должно включать не только главную страницу. Откройте внутренние страницы, заполните контактную форму, протестируйте поиск, войдите в панель администратора, проверьте загрузку изображений и просмотрите error log. Если сайт осуществляет продажи, пройдите весь путь тестового заказа — от корзины до страницы оплаты и письма с заказом.

Особое внимание уделите этим четырём пунктам:

• SSL-сертификат HTTPS и его автоматическое продление
• 301-редиректы и основной вариант с www или без www
• Доставку писем, отправляемых из контактных форм
• Скорость сайта на мобильных устройствах и компьютерах

Если вы используете Cloudflare или другой CDN, не забывайте, что кэш может скрыть реальную проблему. Во время тестирования временно очистите кэш или убедитесь, что проверяете ответ нового origin-сервера.

5. Запланируйте финальную синхронизацию

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

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

6. Измените DNS-записи и оставьте старый сервер доступным

Только после финальной синхронизации измените A- или CNAME-записи, направив их на новый хостинг. Если домен, хостинг и управление DNS находятся у разных поставщиков, заранее убедитесь, что у вас есть доступ ко всем аккаунтам и определён ответственный за изменения. Заниматься восстановлением паролей в день миграции — значит терять время и увеличивать вероятность ошибки.

Не отключайте старый хостинг сразу. Оставьте его активным как минимум на 48–72 часа, а для сложных сайтов или сайтов с международной аудиторией — дольше. Распространение DNS в разных регионах может занимать разное время, и в этот период старый сервер защитит посетителей, у которых кэш ещё не обновился.

7. Контролируйте сайт в первые 72 часа

После изменения DNS проверяйте сайт из разных сетей и с разных устройств. Отслеживайте uptime, ошибки сервера, PHP log, использование CPU и памяти, а также доставку писем. Если на сайте установлена система аналитики, сравните трафик, заказы и заполнения форм с данными предыдущих дней. Резкое падение показателей не всегда является SEO-проблемой: иногда причина просто в неработающей форме или неправильном redirect.

Чтобы защитить SEO-видимость, сохраните адреса страниц, title, canonical-теги и sitemap. Если структура URL неизбежно изменилась, настройте соответствующий 301-редирект для каждого ценного старого адреса. Перенаправить все старые страницы на главную — простое решение, но для пользователя и поисковой системы это часто является неправильным сигналом.

Управление доменом, хостингом, SSL и DNS в одном месте, как в Internet.am, может уменьшить путаницу между системами во время миграции, особенно если за всё отвечает небольшая команда. Однако даже при одном поставщике нельзя пропускать этапы тестирования и резервного копирования.

Миграция успешна не тогда, когда открывается новый сервер, а тогда, когда клиент продолжает видеть быстрый, безопасный и работающий сайт, а ваша команда знает, как восстановить его в любой непредвиденной ситуации.