Смена хостинга напоминает переезд в новую квартиру: адрес меняется, а вещи должны остаться целыми. Только в случае с сайтом потеря даже одного файла или часа простоя оборачивается сорванными заказами и пессимизацией в поиске. Хочется провернуть всё аккуратно, без паники и уложиться в один вечер. Такое вполне реально, если знать правильную последовательность и несколько неочевидных приёмов. Никакой магии — просто чёткий план, который не даст наломать дров.
Что проверяют до первого движения файлов
Спонтанный переезд без подготовки заканчивается одинаково: упавшим сайтом и нервным чтением логов. Лучше потратить полчаса на сбор информации. Со старого хостинга выгружают всё — не только файлы движка и базу данных, но и почтовые ящики, поддомены, cron-задачи и SSL-сертификаты. Многие забывают про папки с пользовательскими загрузками или резервные копии плагинов, а потом удивляются, почему перестали открываться картинки.
Параллельно уточняют технические характеристики нового тарифа: версию PHP, лимиты на выполнение скриптов, поддержку нужных модулей. Если старый сайт работал на PHP 7.2, а новый хостинг предлагает только 8.0 и выше, возможны несовместимости. Тестовый доступ к новому аккаунту желательно получить за день до переноса — это позволит заранее проверить, что FTP или SSH открываются без проблем.
Важно: перед любыми действиями создают полный бэкап сайта и базы данных. Лучше в двух местах — локально на компьютере и в облаке. Это страховочный трос, без которого даже смотреть в сторону нового хостинга не стоит.
Копирование файлов и базы без приключений
Самый муторный этап — перенос контента — можно пройти быстро, если не изобретать велосипед. Файлы сайта обычно копируют через FTP или, что гораздо быстрее, запаковывают в архив прямо на сервере по SSH и скачивают одной ссылкой. Для SSH-новичков: команда tar -czf site_backup.tar.gz public_html/ создаст сжатый архив всей директории, а скачать его можно через защищённый SCP-клиент вроде WinSCP. Если SSH недоступен, файловый менеджер хостинга тоже сжимает папки, но с большими объёмами этот способ тормозит.
База данных экспортируется дампом. В phpMyAdmin выбирают нужную БД, переходят на вкладку «Экспорт» и включают опцию «Добавить DROP TABLE / IF NOT EXISTS». Такая галочка сохранит структуру таблиц при импорте на новом месте. Крупные базы — от пары сотен мегабайт — архивируют через консоль: mysqldump -u user -p dbname | gzip > db_backup.sql.gz. Это исключает риск обрыва соединения в веб-интерфейсе. На новом хостинге заранее создают пустую базу и аккаунт с полными правами к ней — это нужно для импорта.
Настройка конфигурационных файлов
После загрузки файлов на новый сервер сайт ещё не заработает. Его нужно «познакомить» с новой средой. В популярных CMS — WordPress, Joomla, Drupal — есть конфигурационные файлы, где прописаны имя базы данных, пользователь и пароль. В WordPress это wp-config.php. Менять нужно только эти строки; сам код движка не трогают. У Joomla подобные параметры живут в configuration.php, у Drupal — в settings.php. Если сайт самописный, ищут файл с функциями подключения к БД, обычно это db.php или config.php.
Помимо базы, стоит внимательно глянуть в .htaccess. Там могут быть жёстко прописаны абсолютные пути старого хостинга или правила редиректов, завязанные на конкретный домен. Перенос без проверки .htaccess часто ломает внутренние ссылки. Если используется CDN или сторонний кэширующий плагин, его лучше временно отключить — ускорители любят запоминать старые пути и мешать тестированию.
Тестирование до того, как мир увидит новый хостинг
Настоящая магия миграции за один вечер случается на стадии предварительного просмотра. Не нужно сразу переключать домен — достаточно открыть сайт по техническому адресу, который даёт любой нормальный хостинг (что-то вроде http://ваш_логин.хостинг.com). Если такой адрес не предусмотрен, можно временно подменить DNS-запись локально, прописав IP нового сервера в файле hosts на своём компьютере. На Windows это C:WindowsSystem32driversetchosts, на macOS/Linux — /etc/hosts. Строчка выглядит как XXX.XXX.XXX.XXX вашсайт.ru. После такой правки браузер будет стучаться напрямую к новому серверу, а остальной интернет — пока ещё к старому.
Teсты нужно прогонять вдумчиво. Открывают главную страницу, пару внутренних, проверяют работу форм, корзины, если она есть, личного кабинета и админки. Не лишним будет прогнать сайт через сервис проверки битых ссылок — иногда абсолютные пути прописаны прямо в контенте. Если всё грузится как положено и скорость устраивает, значит, основная часть сделана.
Интересно: поисковые роботы в момент миграции ориентируются на код ответа 200. Если на новом хостинге страницы отдают такой код и содержимое идентично, позиции не просядут. Одинаковость контента критична, поэтому проверяют хотя бы десяток страниц выборочно.
Окончательное переключение и минимизация простоя
Последний шаг — обновление DNS-записей, чтобы мир узнал новый IP-адрес сайта. Если домен обслуживается на NS-серверах хостинг-провайдера, часто достаточно сменить их в панели регистратора. Но смена NS — не мгновенная процедура: обновление глобального кэша может занять от пары часов до суток. Чтобы сократить этот разрыв, опытные администраторы заранее уменьшают TTL (время жизни) A-записи у текущего провайдера до 300–600 секунд. Тогда при финальной правке IP адреса переключение произойдёт в течение нескольких минут.
В простом сценарии, когда старый и новый хостинг работают одновременно, делают так: понижают TTL за 12–24 часа до переноса, копируют всё на новое место, проверяют, а затем меняют A-запись. Пока DNS обновляется, какие-то посетители попадают на старый сервер, какие-то — на новый. Чтобы форма отправки не потеряла заявку, можно на старом сайте временно закрыть возможность добавления данных через формы, а на новом сразу включить. Через несколько часов, когда кэш провайдеров обновится, старую площадку останавливают.
Отдельного внимания требуют почтовые MX-записи и поддомены. Если почта привязана к хостингу, их переносят вместе с сайтом, заранее добавив на новом сервере соответствующие записи. SSL-сертификат перевыпускают или импортируют старый. Бесплатные Let’s Encrypt на новом хостинге активируются автоматически, коммерческие нужно перенести вручную: скопировать приватный ключ, сертификат и цепочку доверия.
Частые грабли и как их обойти
Миграция за один вечер перестаёт быть страшилкой, если помнить о типичных ошибках. Самая обидная — забыть снять сайт с кэширования на старом хостинге. Если на старом аккаунте включён кэш на уровне сервера, даже после смены A-записи часть посетителей может видеть устаревший контент. Кэш чистят сразу после финального теста, до обновления DNS.
- Не сравнивают версии PHP и расширения. Модуль для обработки картинок Imagick вроде бы есть у всех, но на дешёвых тарифах его может не быть, и галерея ляжет.
- Абсолютные пути в коде встречаются не только в конфигах, но и в плагинах, темах, скриптах отслеживания. Прямая замена старого пути на новый через поиск по файлам спасает массу нервов.
- Забывают про задания cron. Если старые кроны не воссоздать, перестанут работать отложенные публикации, рассылки, обновление курсов валют.
Важно: при переключении на новый хостинг сохраните старый аккаунт активным минимум на двое суток после смены DNS. Если что-то пойдёт не так, всегда можно откатить A-запись обратно и спокойно разобраться.
Переезд на другой хостинг перестаёт быть авантюрой, когда у тебя в руках выверенный порядок действий. Бэкап, копирование, тестирование, плавное обновление DNS — именно в такой последовательности сайт перебирается без потерь в один вечер. Неспешная подготовка и спокойное следование каждому пункту позволяют уже к утру видеть привычный ресурс на новом месте, только чуть быстрее и надёжнее прежнего.