Что разработчику учитывать при переносе сайта на новый хостинг

Перенос сайта — это как переезд в новую квартиру: кажется, что достаточно перевезти вещи, но на деле нужно проверить проводку, воду, документы и соседей. Если подойти к миграции как к обычному деплою, вы рискуете получить простой, потерю почты, битые ссылки и просадку в поиске — а это прямые убытки. Как аналитик, привыкший считать каждую копейку при покупке недвижимости, я смотрю на хостинг-миграцию через призму окупаемости и рисков. Ниже — практический разбор того, что именно проверить разработчику перед миграцией, во время переноса и после запуска, чтобы не потерять деньги и позиции.

Когда перенос действительно нужен

Переезд на новый хостинг обычно делают, когда:

текущий сервер не тянет нагрузку — как квартира, в которой семья выросла, а метраж остался прежним;
выросли требования к PHP, БД, RAM или диску — аналог необходимости в более просторном и функциональном жилье;
нужен более удобный стек, SSH-доступ, бэкапы, staging — это как переезд из «коммуналки» (shared-хостинга) в собственную квартиру (VPS) с возможностью сделать ремонт под себя;
у хостера нестабильные аптайм и поддержка — когда «соседи» постоянно шумят, а управляющая компания не реагирует;
проект переезжает с shared-хостинга на VPS или облако — масштабирование, похожее на переход от аренды однушки к покупке трёшки с перспективой расширения;
требуется перенести сайт без потери позиций и минимальным простоем — как при продаже старой квартиры и покупке новой «в цепочке», где каждая минута простоя стоит денег.

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

Прежде чем принимать решение, посчитайте совокупную стоимость владения (TCO) текущего и нового хостинга с учётом времени на поддержку, стоимости миграции и потенциальных потерь от простоя. Например, если сайт приносит 5000 рублей в день, а простой при неудачном переезде составит 4 часа, вы потеряете около 833 рублей. Сопоставьте это с ежемесячной экономией на тарифе — возможно, овчинка выделки не стоит.

Что нужно выяснить до начала

Перед любыми действиями соберите технический чек-лист — это как due diligence перед покупкой квартиры: проверяете документы, обременения, состояние коммуникаций. Чем больше проект, тем важнее не полагаться на память.

Минимум, который надо зафиксировать

версия PHP;
версия и тип базы данных;
список доменов и поддоменов;
структура сайта: один сайт или несколько виртуальных хостов;
где хранятся файлы загрузок, кеш, логи;
есть ли cron-задачи;
используются ли почтовые ящики на этом же хостинге;
есть ли CDN, reverse proxy, WAF;
какие SSL-сертификаты используются;
какие внешние интеграции завязаны на IP сервера.

Что часто забывают

задачи cron и системные таймеры — как автоматическое включение отопления, про которое вспоминают только зимой;
правила редиректов — аналог «навигации» в новом доме: без них посетители заблудятся;
.htaccess или nginx-конфиг — фундамент, на котором держится логика работы;
переменные окружения — скрытые коммуникации, без которых всё встанет;
права на файлы и папки — замки на дверях, которые должны быть правильно настроены;
пути в настройках CMS;
параметры подключения к Redis, Memcached, очередям;
лицензии, привязанные к IP — как прописка, которую нужно перерегистрировать;
доменную почту и DKIM/SPF/DMARC — чтобы письма не попадали в спам, как неправильно оформленная корреспонденция.

Что копировать на новый хостинг

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

Компонент	Что переносить	На что обратить внимание
Файлы сайта	Код, темы, плагины, uploads, шаблоны	Не забыть скрытые файлы и симлинки — это как потайные комнаты, которые легко упустить при осмотре
База данных	Dump MySQL/PostgreSQL	Кодировка, collation, размер, права пользователя — несоответствие здесь равносильно перепутанным ключам от квартиры
Конфиги	`.env`, `wp-config.php`, nginx/apache config	Не хранить секреты в публичном доступе — как не оставлять ключи под ковриком
Почта	Ящики, пересылки, MX-записи	Часто почта ломается при переносе первой — это как забыть переадресовать корреспонденцию при переезде
Cron	Планировщик задач	Проверить часовой пояс и пути к скриптам — иначе автоматика сработает не вовремя
SSL	Сертификаты или способ выпуска новых	Убедиться, что работает HTTPS до переключения — как проверить замки до того, как заселиться
Кеш	Redis, Memcached, файловый кеш	Очистить и пересоздать после миграции — старый кеш на новом месте только мешает

Как подготовиться к переносу без сюрпризов

1. Сделайте полную резервную копию

Нужны минимум две копии:

архив файлов сайта;
дамп базы данных;
копия конфигов;
экспорт DNS-зоны, если есть.

Лучше хранить бэкап в двух местах: локально и в облаке. Идеально — проверить, что архив реально открывается и база импортируется. Это как страховка на случай неудачной сделки: вы должны быть уверены, что сможете вернуться в исходное состояние без потерь.

2. Снизьте TTL заранее

Если домен уже делегирован на старые NS, уменьшите TTL у критичных DNS-записей заранее. Это позволит быстрее переключить трафик на новый сервер. Обычно TTL снижают за 24–48 часов до переезда. Представьте, что вы заранее предупреждаете почтовую службу о смене адреса, чтобы письма не терялись в пути.

3. Поднимите сайт на новом сервере до смены DNS

Правильная схема такая:

развернуть файлы;
импортировать базу;
настроить виртуальный хост;
проверить сайт по hosts или через временный домен;
только потом менять DNS.

Это снижает риск простоя и дает возможность спокойно найти ошибки до боевого запуска. По сути, вы проводите «технический осмотр» новой квартиры до того, как перевезти туда семью.

4. Подготовьте почту отдельно

Если сайт использует доменную почту, не переносите её «по остаточному принципу». Почта часто ломается из-за:

неверных MX-записей;
отсутствия SPF/DKIM;
старых пересылок;
несоответствия hostname;
не созданных ящиков на новом хостинге.

Это как забыть переключить домофон и почтовый ящик при переезде — важные уведомления просто не дойдут.

Пошаговый перенос сайта

Шаг 1. Зафиксируйте состояние проекта

Перед переездом остановите фоновые изменения:

приостановите массовые импорт/экспорт операции;
предупредите команду;
заморозьте релизы;
при необходимости включите maintenance mode.

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

Шаг 2. Перенесите файлы

Скопируйте весь корень сайта, включая:

публичные каталоги;
upload-папки;
скрытые файлы;
конфиги;
логи, если они нужны для диагностики.

После копирования проверьте:

совпадает ли структура директорий;
не потерялись ли права;
нет ли пустых каталогов;
не побились ли файлы при архивировании.

Это как сверить опись имущества при переезде — любая недостача может аукнуться неработающей функцией.

Шаг 3. Перенесите базу данных

Экспортируйте базу и импортируйте на новом сервере.

Типовые ошибки здесь:

импорт в неправильную кодировку;
забыли создать пользователя БД;
у пользователя нет прав;
не совпадает charset/collation;
дамп слишком большой для стандартного импорта через панель.

Если база объемная, лучше использовать CLI-импорт, а не только веб-интерфейс — это как нанять профессиональных грузчиков вместо того, чтобы таскать тяжести самому. Один неудачный импорт через веб-морду может растянуться на часы и оборваться на середине.

Шаг 4. Обновите настройки приложения

После переноса проверьте:

host, имя БД, логин, пароль;
пути к временным папкам;
URL сайта;
настройки кеша;
SMTP-параметры;
секретные ключи;
настройки мультисайта, если он есть.

Для WordPress, Laravel, Bitrix, OpenCart, Django и других CMS это выглядит по-разному, но логика одна: приложение должно знать новый сервер и корректно работать в новой среде. Это как обновить адрес в паспорте и всех учётных записях после переезда.

Шаг 5. Настройте DNS

Обычно меняют:

A-запись на IP нового сервера;
AAAA-запись, если используется IPv6;
MX, если переезжает почта;
TXT-записи для SPF, DKIM, DMARC;
CNAME для служебных поддоменов.

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

Шаг 6. Проверьте SSL

После переключения домена сайт должен открываться по HTTPS без предупреждений. Проверьте:

валидность сертификата;
цепочку;
редирект с HTTP на HTTPS;
отсутствие mixed content;
корректность сертификата на www и без www.

Незакрытый замок в браузере — как незапертая входная дверь: пользователи уйдут, не доверяя.

Шаг 7. Прогоните тесты после запуска

После переключения проверьте:

главную страницу;
формы;
авторизацию;
корзину и оплату;
загрузку файлов;
письма из форм;
cron;
ответы API;
sitemap.xml и robots.txt;
404/301-редиректы.

Это как пройтись по всем комнатам новой квартиры и проверить, работают ли розетки, краны и замки.

Как не потерять SEO при миграции

Если URL не меняются, задача упрощается. Но даже в этом случае сайт может временно просесть из-за ошибок на новом сервере. Потеря позиций — это как снижение рыночной стоимости квартиры после неудачной перепланировки: лучше потратить время на проверку, чем потом восстанавливать.

Что важно для поисковиков

не менять структуру URL без необходимости;
сохранить редиректы;
не допустить длительного простоя;
проверить robots.txt;
убедиться, что сайт отдает 200 на нужных страницах;
контролировать 5xx и 404;
следить за скоростью ответа сервера.

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

Ошибка, которая бьет по позициям

Самая частая проблема — сайт на новом хостинге формально «открывается», но:

часть страниц отдает 500;
слетают canonical;
ломается кеш;
меняются адреса медиафайлов;
появляются дубли с www и без www;
редиректный цепочки становятся длиннее.

Это как если бы вы переехали, но часть комнат осталась запертой, а навигация по дому запутана — поисковики просто не смогут правильно проиндексировать сайт.

Чек-лист перед переключением DNS

[ ] Файлы загружены полностью
[ ] База данных импортирована без ошибок
[ ] Конфигурация сайта обновлена
[ ] Домен добавлен на новом хостинге
[ ] SSL выпущен и работает
[ ] Почта проверена
[ ] Cron-задачи настроены
[ ] Редиректы проверены
[ ] robots.txt и sitemap.xml доступны
[ ] Сайт протестирован по временной ссылке или hosts
[ ] TTL снижен заранее
[ ] Есть план отката

Типовые ошибки при переносе

1. Перенесли файлы, но забыли базу

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

2. Не перенесли почту

Письма уходят в никуда, пропадают уведомления о заказах и заявки с форм. Один клиент после миграции не проверил MX-записи и потерял несколько лидов на сумму потенциального контракта в 200 тысяч рублей — пока спохватились, заказчик ушёл к конкуренту.

3. Не проверили версию PHP

На старом сервере работало на PHP 7.4, на новом включили 8.2 — и часть кода перестала работать. Это как въехать в квартиру с напряжением 380V, когда вся техника рассчитана на 220V.

4. Не настроили права доступа

Загрузки не сохраняются, кеш не создается, логи не пишутся. Мелочь, которая ломает функционал.

5. Забыли про cron

Обновления прайсов, рассылки, очистка кеша и синхронизация с CRM перестают запускаться. Автоматика встаёт, и вы узнаёте об этом только когда клиенты начинают жаловаться.

6. Сменили DNS, не дождавшись готовности сервера

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

Как понять, что переезд прошел успешно

Сайт можно считать перенесенным корректно, если:

домен открывается на новом сервере;
все ключевые страницы отдаются без ошибок;
формы и личный кабинет работают;
письма отправляются и принимаются;
база данных соответствует старой версии;
нет визуальных и функциональных отличий;
лог ошибок чистый или содержит только ожидаемые предупреждения;
Search Console и аналитика не показывают резких аномалий.

Если всё это выполнено, можно выдохнуть — вы только что успешно «переехали» без потерь.

Когда лучше делать перенос

Оптимально переносить сайт:

ночью или в период низкой посещаемости;
вне распродаж, релизов и рекламных кампаний;
после снижения TTL;
когда есть время на откат и дополнительную проверку.

Если проект большой, перенос лучше разбить на этапы: сначала стенд, потом частичный запуск, потом полное переключение. Это как поэтапный переезд: сначала перевозим самое ценное, потом остальное, минимизируя хаос.

Короткий вывод

Разработчик при переносе сайта на новый хостинг должен думать не о «перекинуть файлы», а о полной миграции среды: код, база, почта, DNS, SSL, cron, кеш и SEO-сигналы. Чем тщательнее подготовка до переключения домена, тем меньше простой, меньше ошибок и выше шанс пройти переезд без потерь. В мире недвижимости говорят: «семь раз отмерь — один раз отрежь». Здесь тот же принцип: лучше потратить лишний час на проверку, чем потом неделями исправлять последствия.

FAQ

Нужно ли переносить сайт вручную, если хостер обещает бесплатную миграцию?

Да, даже при автоматическом переносе нужно проверить код, базу, почту, DNS и SSL. Ответственность за корректность проекта все равно остается на владельце и разработчике. Как при покупке квартиры с «гарантией от застройщика» — вы всё равно нанимаете независимого эксперта для приёмки.

Можно ли менять хостинг без простоя?

Да, если заранее развернуть сайт на новом сервере, снизить TTL, протестировать через hosts и только потом переключить DNS. Это как подготовить новую квартиру к заселению, пока вы ещё живёте в старой.

Что важнее всего проверить после переезда?

Главные риски — база данных, формы, авторизация, почта, SSL и редиректы. Именно там чаще всего всплывают ошибки. Пропустите одну мелочь — и весь «ремонт» пойдёт насмарку.

Нужно ли менять IP в Google Search Console?

Обычно достаточно корректно переключить DNS и убедиться, что сайт доступен. Если меняется только хостинг, а URL не меняются, критичнее стабильность ответа сервера и отсутствие ошибок. Это как сообщить почтовой службе новый адрес, а не переписывать все документы.

Что делать, если после переноса сайт медленно открывается?

Проверить PHP-версию, настройки БД, кеш, DNS, производительность диска и логи ошибок. Часто проблема не в домене, а в новой конфигурации сервера. Как если бы вы переехали в квартиру с плохой звукоизоляцией — вроде всё на месте, но жить некомфортно.