Переезд сайта на новый домен или сервер: технический чек-лист

Переезд сайта на новый домен или сервер выглядит простой задачей только до первой проверки. Файлы скопированы, база импортирована, главная открылась — но потом выясняется, что не работают формы, письма уходят в никуда, старые URL отдают 404, sitemap указывает на прежний домен, а cron остался на старом сервере.

Лучше идти по чек-листу и проверять не только страницу в браузере, но и технические связи вокруг сайта.

Перед переносом

Сначала нужно понять, что именно переносится: только сайт, сайт вместе с почтой, домен, база, файлы загрузок, cron, очереди, SSL, DNS. Неполный список почти всегда приводит к забытым деталям.

• сделать дамп базы;
• скопировать файлы проекта и uploads;
• зафиксировать версию PHP и расширения;
• сохранить текущие cron-задачи;
• сохранить конфиги nginx или Apache;
• проверить, где обслуживается почта домена.

php -v
php -m
crontab -l
mysqldump -u user -p database > backup.sql

База и конфиги

После импорта базы нужно проверить локальные конфиги. На Yii2-проектах это обычно db.php, params-local.php или отдельные env-файлы. Старые доступы к базе часто остаются в кэше или в локальном конфиге.

mysql -u user -p database < backup.sql
php yii migrate/history

Если проект использует Redis, очереди или внешние API, эти настройки тоже нужно перенести. Сайт может открываться, но фоновые функции при этом уже будут сломаны.

DNS и SSL

При смене сервера нужно заранее снизить TTL DNS-записей, если есть доступ. После переключения домена проверяют A-запись, AAAA-запись, CNAME и SSL-сертификат.

dig example.ru A
dig example.ru AAAA
curl -I https://example.ru/

Если используется www и домен без www, оба варианта должны вести предсказуемо. Обычно выбирают основной вариант и на второй ставят 301 редирект.

server {
    server_name www.example.ru;
    return 301 https://example.ru$request_uri;
}

Редиректы старых URL

Если меняется структура сайта или домен, старые адреса не должны просто исчезнуть. Для важных страниц нужны 301 редиректы на новые URL.

rewrite ^/old-page/$ /new-page/ permanent;

После настройки редиректов полезно проверить несколько старых адресов вручную:

curl -I https://example.ru/old-page/

Нормальная цепочка — один 301 и затем 200 на новой странице. Если получается несколько редиректов подряд, это стоит поправить.

robots.txt и sitemap.xml

После переезда часто забывают заменить домен в sitemap.xml или оставить запрет индексации от тестового стенда. Эти файлы нужно проверить отдельно.

curl https://example.ru/robots.txt
curl -I https://example.ru/sitemap.xml

В robots.txt должен быть актуальный путь к карте сайта:

User-agent: *
Disallow: /admin/

Sitemap: https://example.ru/sitemap.xml

В sitemap.xml не должно быть старого домена, тестового поддомена, http вместо https и страниц с 404.

Формы и почта

После переноса обязательно нужно отправить тестовую форму. Даже если код не менялся, SMTP может быть привязан к IP, домену, DNS или настройкам безопасности почтового сервиса.

• проверить SMTP host, port и encryption;
• проверить логин и пароль;
• проверить SPF, DKIM и DMARC;
• проверить папку “Спам”;
• убедиться, что useFileTransport выключен на production.

tail -n 100 runtime/logs/app.log

Cron и фоновые задачи

При переносе сайта cron легко забыть. Файлы и база уже на новом сервере, а задачи продолжают выполняться на старом или не выполняются вообще.

crontab -l
ps aux | grep yii

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

Проверка после запуска

1. Главная страница открывается по HTTPS.
2. www и не-www ведут на выбранный основной домен.
3. Старые важные URL отдают 301.
4. robots.txt и sitemap.xml открываются.
5. Форма отправляет письмо.
6. Админка открывается и сохраняет данные.
7. Файлы загружаются в нужную директорию.
8. Cron и очереди работают на новом сервере.
9. В логах нет свежих критических ошибок.

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