Смена хостинга часто откладывается не потому, что старый провайдер устраивает, а потому, что страшно трогать работающий сайт. Вдруг пропадут изображения, перестанет открываться база данных, собьется почта, домен уйдет не туда или поисковые системы увидят вместо страниц ошибки.
На самом деле перенос сайта не является чем-то экзотическим. Если сначала скопировать проект, проверить его на новой площадке и только потом переключить домен, большую часть рисков можно убрать еще до того, как посетители заметят изменения.
Главная ошибка при переезде выглядит наоборот: сначала отключить старый хостинг, а уже потом начинать разбираться, как восстановить сайт на новом.
Нормальный перенос строится по другому принципу. Старый сайт продолжает работать, пока рядом готовится его копия.
Сначала разберитесь, что именно нужно перенести
Сайт редко состоит только из папки с HTML-файлами. Современный проект может включать файлы движка, изображения, базу данных, задания cron, настройки PHP, SSL, почтовые ящики, DNS-записи, поддомены и дополнительные сервисы.
Поэтому перед переносом полезно открыть панель старого хостинга и составить список.
Сколько доменов привязано к аккаунту? Есть ли поддомены? Какие базы данных используются? Созданы ли почтовые ящики вида info@вашдомен.ru? Есть ли переадресации почты? Используются ли задания cron? Какая версия PHP включена? Есть ли нестандартные расширения или настройки?
Для WordPress стоит отдельно посмотреть размер каталога uploads, список активных плагинов и тему. Для интернет-магазина нужно учитывать не только файлы, но и постоянно изменяющуюся базу с заказами, пользователями и остатками.
Если на хостинге находится несколько сайтов, не стоит автоматически переносить весь аккаунт. Возможно, часть проектов давно не используется. Переезд является хорошим моментом для небольшой инвентаризации.
Не начинайте без полной резервной копии
Даже если новый хостинг обещает бесплатно перенести сайт силами своей поддержки, резервную копию лучше иметь самостоятельно.
Нужны как минимум файлы сайта и дамп базы данных. Если почта хранится на сервере и ее тоже предстоит переносить, сохраните важные сообщения или убедитесь, что существует отдельная копия почтовых данных.
Архив лучше скачать за пределы старого хостинга. Копия, которая лежит в соседней папке того же аккаунта, мало помогает при блокировке или потере доступа.
После создания архива проверьте хотя бы очевидные вещи: файл действительно скачался, его размер выглядит правдоподобно, архив открывается, а дамп базы не имеет нулевой размер.
Для важного коммерческого сайта желательно не ограничиваться одной копией.
Если в магазине продолжают появляться заказы, между созданием резервной копии и фактическим переключением домена база меняется. Значит, потребуется либо короткое окно обслуживания, либо финальная синхронизация данных непосредственно перед переездом.
Новый хостинг лучше подготовить до смены DNS
К этому моменту старый сайт все еще должен быть доступен посетителям.
На новом хостинге добавьте домен, создайте базу данных и пользователя, выберите подходящую версию PHP, настройте необходимые расширения и загрузите файлы.
Если сайт использует конфигурационный файл с реквизитами базы, укажите новые имя базы, пользователя, пароль и сервер базы данных.
Для WordPress эти параметры находятся в wp-config.php. У других систем расположение настроек отличается.
Затем импортируйте базу.
Именно на этом этапе часто обнаруживаются различия между площадками. Например, на старом сервере использовалась одна версия PHP, а новый аккаунт автоматически включил другую. Какой-то старый плагин может оказаться несовместим с новой версией. Может отсутствовать необходимое расширение PHP или действовать другой лимит памяти.
Такие проблемы намного приятнее исправлять, пока посетители по-прежнему видят старый рабочий сайт.
Как проверить сайт до переключения домена
Это ключевой этап, который слишком часто пропускают.
Если просто загрузить файлы на новый сервер и сразу изменить DNS, первая настоящая проверка произойдет уже на посетителях. Лучше увидеть ошибки самостоятельно.
Некоторые хостинги предоставляют технический адрес для предварительного просмотра. Но он подходит не всегда: система управления сайтом может жестко использовать основной домен, а HTTPS и часть внешних интеграций на временном адресе работают иначе.
Более надежный способ для технически подготовленного пользователя заключается во временном изменении файла hosts на своем компьютере. В нем можно указать, что конкретный домен должен открываться с IP нового сервера.
Для всего остального интернета ничего не изменится. Посетители продолжат попадать на старый хостинг, а ваш компьютер будет открывать уже новую копию.
После этого пройдите сайт так, будто вы обычный пользователь.
Откройте главную страницу, несколько внутренних страниц, изображения, форму обратной связи и поиск. Авторизуйтесь в административной панели. Если есть личный кабинет, проверьте вход. У интернет-магазина добавьте товар в корзину и пройдите оформление заказа настолько далеко, насколько это можно безопасно сделать в тестовом режиме.
Не ограничивайтесь внешним видом. Страница может выглядеть идеально, но форма отправляет письма на старом сервере, cron не запускается, а загрузка новых изображений завершается ошибкой из-за прав доступа.
Перед переключением проверьте DNS целиком, а не только сайт
DNS определяет, куда направляются запросы для домена. При переносе сайта обычно меняется IP-адрес сервера или серверы имен.
Но в DNS могут находиться записи не только для сайта.
Например, MX указывает почтовую инфраструктуру. TXT может использоваться для SPF, DKIM, подтверждения владения доменом и внешних сервисов. CNAME связывает поддомены с другими адресами. Отдельные A и AAAA записи могут вести на разные серверы.
Если при переезде бездумно заменить серверы имен и не перенести существующую DNS-зону, сайт заработает, а корпоративная почта внезапно перестанет получать письма.
Поэтому сохраните текущие записи заранее.
Если DNS остается у регистратора или стороннего сервиса и вы меняете только A-запись сайта, риск меньше. Если DNS обслуживал старый хостинг и после отказа от него зона исчезнет, все необходимые записи нужно заранее создать в новом месте.
Что делать с TTL
TTL определяет, как долго DNS-ответ может храниться в кэше. Если вы заранее уменьшите TTL для записи, которую предстоит изменить, обновление после переключения обычно будет распространяться быстрее.
Но уменьшать TTL за пять минут до переноса почти бессмысленно. Старое значение уже могло попасть в кэши.
Если переезд планируется заранее, TTL можно уменьшить заблаговременно, дождаться прохождения прежнего периода и только потом менять IP.
После завершения переноса значение можно вернуть к обычному.
При этом не стоит обещать себе или клиенту, что DNS «обновится ровно за N минут». Кэширование происходит на разных уровнях, и часть пользователей некоторое время может попадать на старый сервер.
Именно поэтому старый хостинг нельзя выключать сразу после изменения записи.
Особая проблема интернет-магазина заключается в двух работающих копиях
Для информационного сайта короткий период, когда часть пользователей попадает на старый сервер, а часть уже на новый, обычно не вызывает серьезных последствий. Контент практически не меняется.
Для интернет-магазина все иначе.
Покупатель, попавший на старый сервер, может оформить заказ. Другой пользователь в тот же момент оформит заказ уже на новом. В результате появляются две базы данных, каждая из которых считает себя актуальной.
Поэтому для динамического коммерческого проекта нужно заранее продумать финальное переключение.
Один из простых подходов состоит в коротком режиме обслуживания. На время финальной синхронизации оформление новых заказов останавливается, актуальная база переносится на новый сервер, после чего переключается трафик.
Для проектов, где простой недопустим, используются более сложные схемы репликации и миграции. Но это уже задача системных администраторов и разработчиков, а не обычный перенос через панель хостинга.
Главное правило простое: чем чаще изменяются данные, тем опаснее переносить сайт из резервной копии, сделанной несколько часов назад, без финальной синхронизации.
Не забудьте про почту на собственном домене
Если адреса вида office@домен.ru обслуживаются старым хостингом, вместе с сайтом может потребоваться перенос почты.
Сначала создайте нужные ящики на новой площадке. Настройте пароли и проверьте доступ.
Если нужно сохранить старые письма, перенесите их подходящим способом. Для IMAP существуют инструменты синхронизации между серверами, а почтовые программы могут хранить локальные копии, но конкретный вариант зависит от сервиса.
Затем проверьте MX-записи домена и связанные с отправкой почты SPF, DKIM и DMARC.
Особенно внимательно отнеситесь к DKIM. После смены почтового сервиса ключ и DNS-запись могут измениться.
Отправьте тестовые письма в обе стороны. Проверьте не только получение, но и отправку на несколько внешних почтовых сервисов.
Если почта изначально обслуживается отдельным поставщиком и DNS-записи сохраняются без изменений, перенос веб-сайта вообще не должен ее затронуть. Это еще одна причина не менять DNS-зону целиком без необходимости.
SSL на новом сервере нужно выпускать отдельно
Сертификат, который автоматически работал на старом хостинге, не обязательно появится на новом сам по себе.
Многие современные панели умеют бесплатно выпускать сертификаты Let’s Encrypt после того, как домен направлен на сервер. В других случаях сертификат можно подготовить заранее через DNS-проверку или перенести существующий сертификат, если это допускает используемая схема и у вас есть необходимые ключи.
После переключения откройте сайт именно по HTTPS.
Проверьте, что сертификат действителен для нужных имен, например domain.ru и www.domain.ru, если используются оба варианта.
Убедитесь, что HTTP корректно перенаправляется на HTTPS.
Посмотрите, нет ли смешанного содержимого, когда защищенная страница загружает изображения или скрипты по HTTP. Иногда такие проблемы появляются после старых настроек или неудачной замены адресов в базе.
Как не потерять позиции в Яндексе и других поисковых системах
Сама по себе смена хостинга не должна менять адреса страниц.
Если раньше статья находилась по адресу example.ru/blog/hosting, после переноса она должна остаться там же. Не нужно одновременно с переездом менять структуру URL, домен, систему управления сайтом и дизайн, если для этого нет отдельного плана.
Чем меньше переменных меняется за один раз, тем легче понять причину проблемы.
Для поисковой системы важно, чтобы сайт оставался доступным, страницы возвращали правильные HTTP-коды, внутренние ссылки работали, а robots.txt и sitemap.xml не были случайно заменены тестовыми версиями.
Очень неприятная ошибка возникает, когда на тестовой копии разработчик закрывает индексацию, а затем переносит этот robots.txt или настройку WordPress в рабочую версию.
После переезда обязательно откройте robots.txt и несколько ключевых страниц.
Проверьте canonical. Убедитесь, что он не указывает на временный технический домен.
Посмотрите sitemap.xml и убедитесь, что карта сайта доступна.
В Яндекс Вебмастере после переноса полезно следить за диагностикой сайта, доступностью страниц и сообщениями о проблемах. Если доменное имя и URL не меняются, специальная процедура «переезда» домена для простой смены хостинга не нужна.
Не стоит паниковать из-за кратковременных колебаний показателей сразу после технических работ. Гораздо важнее быстро обнаружить реальные ошибки: массовые 5xx, недоступные страницы, неправильные редиректы или случайный запрет индексации.
Переключили DNS и все заработало, но старый хостинг пока не отключаем
После изменения DNS начинается самый спокойный и одновременно самый коварный этап.
На вашем компьютере сайт уже открывается с нового сервера. Кажется, что перенос завершен.
Но часть пользователей еще может получать закэшированный старый адрес.
Оставьте прежний хостинг работающим хотя бы на период, достаточный для распространения DNS-изменений и проверки новой площадки. Для важного проекта разумный запас времени полезнее экономии нескольких часов оплаченного тарифа.
Следите за логами нового сервера и системой мониторинга. Проверяйте ошибки приложения.
Если это магазин, контролируйте поступление заказов. Если сайт получает заявки через формы, убедитесь, что письма действительно доходят.
Проверьте фоновые задания. Cron мог остаться настроенным только на старой площадке.
Через некоторое время сравните базы и убедитесь, что на старом сервере больше не появляются новые данные.
Когда можно удалить старую копию
Не в тот же вечер.
Сначала убедитесь, что DNS стабильно указывает на новую площадку, сайт работает без ошибок, почта приходит, SSL продлевается или настроен на автоматическое продление, резервное копирование включено, а фоновые задания выполняются.
Затем создайте уже на новом хостинге свежую резервную копию.
Старый архив, сделанный перед переносом, тоже не нужно сразу удалять. Некоторое время он может пригодиться для восстановления отдельного файла или сравнения настроек.
Только после этого можно отключать прежний тариф.
Если домен был зарегистрирован у старого хостинг-провайдера, отказываться от хостинга не обязательно означает переносить домен. Его можно оставить у того же регистратора и продолжать продлевать отдельно, если условия устраивают.
Когда лучше поручить перенос новому хостингу
Многие провайдеры помогают переносить сайты новых клиентов бесплатно или за отдельную плату. Для владельца обычного WordPress-сайта это часто самый простой путь.
Но даже в таком случае не отдавайте процесс полностью «в черный ящик».
Передайте специалисту информацию о сайтах, базах, почте и нестандартных настройках. Сделайте собственную резервную копию. После сообщения «готово» самостоятельно проверьте основные страницы и функции.
Поддержка хостинга хорошо знает свою инфраструктуру, но она не обязана знать бизнес-логику вашего проекта.
Специалист может увидеть, что WordPress открывается и не выдает ошибку. Только владелец магазина знает, что после заказа должен запуститься особый обмен с учетной системой, сформироваться документ и уйти уведомление менеджеру.
Чем сложнее сайт, тем важнее финальное пользовательское тестирование.
Самые частые ошибки при смене хостинга
Первая — отключить старый тариф до завершения переноса.
Вторая — скопировать файлы и забыть базу данных.
Третья — перенести сайт, но потерять DNS-записи корпоративной почты.
Четвертая — не проверить версию PHP и необходимые расширения.
Пятая — сразу переключить домен, не открыв новую копию заранее.
Шестая — забыть cron и фоновые задания.
Седьмая — считать, что резервная копия автоматически означает актуальную базу интернет-магазина.
Восьмая — оставить на рабочем сайте тестовый robots.txt, canonical или адрес временного домена.
Девятая — удалить старый сервер сразу после изменения DNS.
И десятая — одновременно со сменой хостинга менять движок, структуру URL, дизайн и домен. Иногда это необходимо, но тогда речь идет уже не о простом переносе, а о полноценной миграции проекта с гораздо большим количеством рисков.
Самый безопасный переезд выглядит довольно скучно. Создали резервную копию. Подготовили новую площадку. Загрузили сайт. Проверили его до переключения. Сохранили DNS и почтовые настройки. Синхронизировали актуальные данные. Переключили домен. Еще раз все проверили. И только потом отключили старый сервер.
Именно эта скучная последовательность обычно и позволяет перенести сайт так, что большинство посетителей вообще не узнает о переезде.
