-
Подготовка
Копии, доступы и зависимости
-
Репетиция
Проверка на новой площадке
-
Переключение
DNS и синхронизация данных
-
Контроль
Формы, почта и фоновые задачи
При переносе сайта на другой хостинг без смены домена задача — сохранить адреса, данные и рабочие сценарии, изменив площадку обслуживания. SEO-риск возникает не от названия нового провайдера, а от недоступности страниц, потерянного содержимого, ошибочных редиректов и случайных запретов индексации. Переключать DNS стоит после проверки новой копии и плана возврата.
Главное до старта: назначить ответственного, сохранить исходное состояние, проверить восстановление базы и файлов, согласовать работу с новыми заказами во время переноса. Инструкция относится к смене хостинга; переезд на другой домен или CMS требует дополнительных решений.
Составьте карту того, что переносится
В список входят приложение, база, загруженные файлы, фоновые задания, сертификаты, переменные окружения, почтовая отправка и внешние интеграции. Укажите владельца каждого доступа и способ проверить работу. Отдельно выясните, где находятся DNS и корпоративная почта: они могут вообще не зависеть от старого хостинга.
Секреты передавайте через согласованный защищённый канал, не вставляйте их в публичную задачу или Git. До отключения старого сервера убедитесь, что архив реально восстанавливается. Наличие файла с названием backup не подтверждает полноту базы и работоспособность приложения.
Проверьте новую площадку до смены DNS
Разверните копию в изолированном контуре. Проверяйте нужное доменное имя способом, согласованным с разработчиком, например локальным сопоставлением адреса. Не оставляйте общедоступный тестовый дубль для индексации. Парольная защита стенда решает и вопрос нежелательного доступа; один robots.txt не защищает конфиденциальную информацию.
| Проверка | Что должно совпасть | Частая проблема |
|---|---|---|
| Важные URL | Коды ответа, контент и canonical | Редирект на тестовый домен |
| Загруженные файлы | Документы, изображения, доступ | Перенесли базу, но забыли media |
| Заявки | Сохранение и доставка адресату | Письма не уходят с нового сервера |
| Фоновые задачи | Расписание и результат | Задача работает на двух площадках |
| HTTPS | Сертификат и правильный хост | Проверили только прямой IP |
Проверка должна включать внутренние страницы, а не только главную. Сохраните список адресов из sitemap и образцы разных шаблонов. Для магазина выполните тестовый заказ и сверку с системой учёта; для сайта услуг найдите тестовую заявку в том канале, которым пользуется менеджер.
Как подготовить переключение DNS
DNS связывает имя с инфраструктурой. Изменение записи не означает, что все посетители немедленно начнут обращаться на новый сервер: резолверы кешируют ответы. Проверьте TTL, существующие записи и сохранность почтовых настроек. Снижение TTL заранее может быть частью плана, но не отменяет уже сохранённые ответы.
При переносе без смены URL Google рекомендует подготовить новую инфраструктуру, начать перенос и затем контролировать обход и трафик. Практический порядок приведён в документации по смене хостинга. В своём плане запишите, кто меняет DNS, когда это происходит и по каким признакам переключение считается успешным.
Не потеряйте новые заказы между двумя копиями
Самый сложный момент динамического сайта — изменение данных после создания резервной копии. Пока посетители попадают на старую площадку, там могут появляться заявки, платежи и файлы. Если просто включить вчерашний архив на новом сервере, эти записи не появятся в нём автоматически.
Выберите подходящий способ синхронизации с разработчиком: короткое согласованное окно ограничений, перенос финального набора изменений или другая проверенная схема. Не допускайте независимой обработки одного платежа двумя фоновыми процессами. Для вебхуков и очередей заранее предусмотрите повторную доставку и защиту от дублей.
План отката тоже должен учитывать данные. Обратная смена DNS после появления заказов на новой площадке не объединяет базы. Запишите, какие операции надо остановить, какие записи перенести и кто подтверждает целостность. Обсуждать это после аварии значительно труднее.
Что проверить сразу после переключения
- Проверить разрешение домена и HTTPS из нескольких сетей.
- Открыть важные страницы, изображения и документы по прежним адресам.
- Сравнить robots.txt, sitemap, canonical и HTTP-заголовки с планом.
- Выполнить тест формы, уведомления, заказа и фоновой операции.
- Посмотреть журналы ошибок и запросы роботов, затем данные поисковых панелей.
Старую площадку не выключают по одному успешному открытию главной. Срок сохранения резервного контура выбирают с учётом DNS, синхронизации и бизнес-процесса. Все изменения фиксируйте в журнале переноса. Для проверки поисковых обращений используйте логи сервера.
Частые вопросы о смене хостинга
Нужны ли новые редиректы для всех страниц?
Если домен и пути не меняются, массовая таблица новых адресов не нужна. Нужно сохранить действующие правила нормализации. Редирект становится отдельной задачей, когда действительно меняется URL или устраняется старый дубль.
Можно ли переезжать во время сбоя?
Да, если есть проверенные копии и аварийный план. Но спешка не отменяет проверки целостности. Сначала выясните, какие данные доступны и какие операции ещё выполняются на исходной площадке.
Как принять работу
Попросите передать список перенесённых компонентов, результаты проверок, схему резервного копирования и порядок отката. Заказчик должен понимать, кто отвечает за домен, сервер, обновления и мониторинг. В рамках поддержки сайта такой переезд можно организовать как отдельную задачу с проверяемыми условиями приёмки.
Как согласовать окно переключения
Назначьте одного ответственного за решение о запуске и одного за проверку заказов. Заранее договоритесь, при каких ошибках переключение отменяют: не записывается заявка, не проходит авторизация, расходятся данные каталога или не работает платёжная интеграция. Эти условия полезнее общего требования «проверить всё».
В журнале переноса фиксируйте время последней синхронизации базы, изменения DNS и первого подтверждённого заказа на новой площадке. Если оба сервера временно принимают записи, заранее определите способ их объединения: простой возврат DNS не переносит новые заказы обратно. Не удаляйте старую площадку сразу после открытия главной. Сначала подтвердите работу согласованных сценариев, резервного копирования, фоновых задач и исходящей почты, затем согласуйте отключение прежней инфраструктуры.
