Чекліст перевірки сайту після міграції на новий хостинг

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

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-параметри в момент самого перенесення. Повний функціональний чекліст одразу після міграції лишається потрібним незалежно від того, чи налаштований моніторинг — це різні рівні захисту.