Перенос сайта на новый хостинг редко сводится к копированию файлов. Нужно перенести базу данных, сохранить настройки, проверить версии PHP и расширения, подготовить SSL, не потерять заявки и только потом переключить DNS. Если менять всё одновременно, после переезда трудно понять, где появилась ошибка.
Надёжный перенос похож на короткий проект: сначала инвентаризация и резервная копия, затем тестовая копия на новом сервере, после этого переключение и контроль. Такой порядок снижает простой и оставляет возможность быстро вернуться к старой площадке.
Важно! Не отключайте старый хостинг сразу после смены DNS. Оставьте его доступным на время проверки и убедитесь, что новые заявки не продолжают приходить только в старую базу.
Шаг 1. Составьте карту сайта
Запишите домены и поддомены, тип сайта, CMS, версию PHP, подключённые сервисы, почтовые ящики, cron-задачи, сертификаты и внешние интеграции. Отдельно отметьте формы, оплату, вебхуки и места, куда отправляются заявки. Такой список помогает не забыть маленький, но важный компонент.
| Что проверить | Зачем это нужно |
|---|---|
| Файлы и каталоги | Понять объём и скрытые папки конфигурации |
| База данных | Сохранить контент, пользователей и настройки |
| Почта и SMTP | Не потерять уведомления и ответы с форм |
| DNS-записи | Понимать, какие записи переключатся |
| SSL и редиректы | Сохранить HTTPS и канонический адрес |
Если сайт работает на WordPress, проверьте размер базы, папку uploads, конфигурацию подключения и задания cron. Для самописного проекта добавьте список переменных окружения и ключей интеграций. Секреты переносите через защищённый канал, а не в открытом файле.
Шаг 2. Сделайте и проверьте резервную копию
Сохраните архив файлов и отдельный дамп базы данных. После создания проверьте размер архива, дату, возможность распаковать его и наличие нескольких последних записей. Для большого сайта полезно сделать пробное восстановление на локальной или временной площадке.
Резервная копия, которая лежит на том же сервере и никогда не проверялась, не даёт полноценной защиты. Минимальный план отката должен отвечать на вопросы: кто принимает решение, откуда берётся архив, сколько занимает восстановление и как сообщить команде о возврате.
Шаг 3. Подготовьте окружение на новом хостинге
Создайте сайт, базу данных и пользователя с нужными правами. Сверьте версию PHP, модули, лимиты загрузки, кодировку базы, права на каталоги и работу cron. Не обновляйте CMS и плагины в тот же момент, если это не часть отдельного плана: перенос должен менять одну переменную за раз.
Разверните копию на техническом адресе или через временную запись hosts. Проверьте главную страницу, внутренние URL, поиск, формы, личный кабинет, загрузку изображений и отправку почты. Не открывайте тестовую копию для индексации: закройте её паролем или настройкой noindex.
Шаг 4. Перенесите файлы и базу
Скопируйте файлы в сохранённой структуре, импортируйте базу и проверьте подключение. Если меняется домен, отдельно обработайте абсолютные URL в базе и конфигурации. Делайте это инструментом, который учитывает сериализованные данные, иначе можно повредить настройки и виджеты.
Перед переключением сравните количество записей, последние публикации и размер папки uploads. Для сайта с активными заявками выберите короткое окно заморозки изменений или временно отключите запись в старую базу, чтобы не получить расхождение.
Шаг 5. Переключите DNS и SSL
Уменьшение TTL заранее ускоряет обновление, но не делает его мгновенным для всех пользователей. Часть посетителей ещё некоторое время будет попадать на старый сервер. Поэтому новый и старый сайт должны быть готовы работать параллельно.
После изменения A-записи или CNAME дождитесь ответа на нескольких сетях и устройствах. Выпустите сертификат, проверьте цепочку HTTPS, редирект с http на https и адрес с www или без www. Если меняется URL-структура, используйте постоянные редиректы и обновите sitemap и canonical. Общая логика переноса и проверки URL описана в руководстве Google для site move.
Проверка после переключения
| Зона | Что сделать | Признак успеха |
|---|---|---|
| Страницы | Открыть главную, разделы и случайные URL | Нет неожиданных 500 и редирект-цепочек |
| Формы | Отправить тестовую заявку | Письмо и запись в CRM приходят один раз |
| Медиа | Проверить изображения и загрузки | Нет битых путей и ошибок прав |
| Поиск | Проверить robots.txt и sitemap | Тестовая копия закрыта, рабочая доступна |
| Мониторинг | Посмотреть логи и ошибки | Нет нового массового типа ошибок |
Совет! Составьте список из десяти важных пользовательских действий и пройдите его сразу после переключения. Проверка по памяти часто пропускает оплату, загрузку файла или письмо менеджеру.
Когда нужен откат
Возвращайтесь к старому серверу, если новый сайт теряет данные, не отправляет заявки, работает нестабильно или критичные разделы недоступны. Зафиксируйте время и причину, восстановите DNS и только потом исправляйте проблему на тестовой копии.
Откат не отменяет перенос: он даёт время разобраться без давления. После исправления снова пройдите контрольный список и повторите переключение в более спокойное окно.
Чек-лист
- Составлена карта файлов, базы, почты и интеграций.
- Архив и дамп проверены распаковкой.
- Новое окружение соответствует требованиям CMS.
- Тестовая копия закрыта от индексации.
- DNS, SSL, редиректы и sitemap подготовлены.
- Формы и заявки проверены после переключения.
- Старый хостинг оставлен до завершения контроля.
Перенос сайта проходит спокойно, когда его разбивают на проверяемые шаги. Подготовьте копию, протестируйте новый сервер, переключите DNS в выбранное окно и заранее решите, как вернуться. Это проще, чем искать единственную причину сбоя после поспешного переезда.
Как сохранить данные, которые меняются во время переноса
Если сайт принимает заявки, заказы или комментарии, заранее определите период, когда запись будет приостановлена. Можно временно перевести формы в режим уведомления, а затем перенести новые записи вручную по журналу. Для интернет-магазина отдельно сверяют заказы, остатки и статусы оплаты.
Перед переключением сделайте финальный дамп базы. Не полагайтесь на архив, созданный несколько дней назад: за это время могли появиться новые клиенты, публикации и настройки.
Проверка SEO после миграции
| Проверка | Что сравнить со старым сайтом |
|---|---|
| URL | Ответы страниц и редиректы |
| Индексация | robots.txt, sitemap и доступ поисковым роботам |
| Метаданные | Title, description, canonical и заголовки |
| Аналитика | Счётчики, цели и источники переходов |
После переноса следите за логами и статистикой несколько дней. Резкое падение заявок может быть связано с формой, почтой или редиректом, а не с самим доменом. Чем раньше замечена проблема, тем проще использовать план отката.
Отдельно проверьте, что резервные копии и тестовая площадка не публикуются в поиске. После завершения работ удалите временные доступы и обновите ключи, которые могли использоваться во время миграции.
Передача проекта команде
Сохраните в проекте дату переключения, доступы к новому серверу, путь к резервной копии и контакт ответственного. После переноса передайте этот лист тому, кто будет сопровождать сайт: через месяц детали уже не восстановить по памяти.