Чеклист проверки сайта после миграции на новый хостинг

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

1. Основная доступность

># Проверить HTTP/HTTPS ответ
curl -I https://example.com
# Ожидаемый ответ: HTTP/2 200

# Проверить редирект HTTP → HTTPS
curl -I http://example.com
# Ожидаемый ответ: 301 Moved Permanently → https://example.com

# Проверить www → non-www (или наоборот)
curl -I https://www.example.com
# Должен редиректить на основной домен

2. SSL-сертификат

># Срок действия и цепочка доверия
openssl s_client -connect example.com:443 -servername example.com   < /dev/null 2>&1 | grep -E "subject|issuer|notAfter"

# Онлайн: https://www.ssllabs.com/ssltest/
# Ожидаемая оценка: A или A+

3. Полный функциональный чеклист

Что проверить	Инструмент/метод	OK?
Главная страница открывается	Браузер
Подстраницы (категории, статьи)	Браузер
Изображения отображаются	Браузер + DevTools
CSS/JS загружаются (нет 404)	DevTools → Network
Форма обратной связи	Отправить тестовое сообщение
Письмо отправляется и доходит	Проверить почту получателя
Авторизация/регистрация	Создать тестового пользователя
Поиск по сайту	Поисковая форма
Корзина/оформление заказа	Тестовый заказ
Мобильная версия	Chrome DevTools → Mobile

4. SEO-проверка

># Robots.txt доступен
curl https://example.com/robots.txt

# Sitemap.xml доступен и актуален
curl https://example.com/sitemap.xml | head -20

# Canonical теги корректны
curl -s https://example.com | grep canonical

# Мета-теги title и description
curl -s https://example.com | grep -E "<title>|meta name="description""

5. Скорость загрузки

># Время ответа сервера
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}
Total: %{time_total}
"   https://example.com

# Онлайн-инструменты:
# https://pagespeed.web.dev/
# https://gtmetrix.com/

6. Настройка мониторинга

># Бесплатный мониторинг uptime
# UptimeRobot (uptimerobot.com) — проверка каждые 5 минут

# Или простой скрипт мониторинга
cat > /usr/local/bin/check-site.sh <<'SCRIPT'
#!/bin/bash
STATUS=$(curl -o /dev/null -s -w "%{http_code}" https://example.com)
if [ "$STATUS" != "200" ]; then
  echo "ALERT: Site returned $STATUS" | mail -s "Site Down!" admin@example.com
fi
SCRIPT
chmod +x /usr/local/bin/check-site.sh
echo "*/5 * * * * /usr/local/bin/check-site.sh" | crontab -

7. План отката (Rollback Plan)

Держите старый хостинг активным минимум 72 часа после успешной миграции. При критической проблеме можно быстро вернуть DNS на старый сервер — пользователи вернутся к работающей версии сайта за 5–15 минут (при TTL 300).

># Быстрый откат DNS (если что-то пошло не так)
# В DNS-панели: вернуть A-запись на IP старого сервера
# Проверить через dig
dig @8.8.8.8 example.com A +short
# После верификации — разобраться с проблемой спокойно

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

Частые вопросы

Как долго нужно держать старый хостинг активным после миграции?

Старый хостинг стоит держать работающим ещё некоторое время после переноса — это позволяет быстро откатить DNS назад при обнаружении критической проблемы, пока новый сервер не прошёл полную проверку. Отключать старую площадку раньше срока рискованно: без неё аварийное восстановление данных из бэкапов занимает заметно больше времени, чем простой возврат DNS-записи.

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

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

Почему SSL-сертификат нужно проверять отдельно, а не просто смотреть, открывается ли страница?

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

Заменяет ли мониторинг доступности сайта разовую проверку сразу после миграции?

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