Що перевірити після зміни хостингу: пошта, SSL, редиректи й форми
Оновлено 6 хв читанняКоманда DNSPeek
Одразу після зміни хостингу переконайтеся, що DNS усюди вказує на новий сервер, що встановлено дійсний сертифікат і що редиректи, як і раніше, ведуть з HTTP на HTTPS і на одне канонічне імʼя хоста. Потім перевірте доставку пошти (MX, SPF, DKIM і DMARC), контактні форми, заплановані завдання і налаштування для пошукових систем. Більшість проблем після перенесення належить до однієї з цих груп і швидко виправляється, щойно їх знайдено.
DNS: чи всі вже на новому сервері?
Перевірте, що домен і www резолвляться в новий IP через публічні резолвери по всьому світу, за допомогою перевірки поширення DNS, і що сайт справді там відповідає, за допомогою інструмента Чи перемкнувся мій домен?. Старий AAAA-запис (IPv6) — класичний залишок: відвідувачі з IPv6 і далі потрапляють на старий хостинг і бачать застарілий вміст.
Якщо ви перенесли DNS до іншого провайдера, порівняйте стару й нову зони за допомогою Порівняння DNS. Відсутній TXT- чи CNAME-запис тихо ламає речі: підтвердження домену для Google чи Microsoft, підпис пошти або піддомен, який використовує сторонній сервіс.
SSL-сертифікат
Багато хостингів випускають сертифікат лише після того, як домен спрямовано на них, тож перевіряйте його, коли DNS уже перемкнуто. Перевірка SSL показує видавця, дату закінчення терміну дії, імена, які охоплює сертифікат, і чи довіряють браузери ланцюжку. Переконайтеся, що він охоплює і example.com, і www.example.com, а також усі інші імена хостів, які ви обслуговуєте.
Якщо ви перевіряли сайт через посилання-превʼю DNSPeek у режимі Пропускати перевірку, після переїзду перемкніть його на Перевіряти: тоді превʼю видасть помилку за будь-якої проблеми із сертифікатом, і це швидке підтвердження. Див. Режими SSL.
Редиректи й заголовки
Конфігурація сервера не завжди переїжджає разом із файлами. Правила .htaccess не працюють на nginx, а новий хостинг може інакше обробляти www. Запустіть перевірку редиректів для свого домену: http:// має доходити до фінальної сторінки https:// за один-два кроки, з постійними (301 або 308) редиректами і без циклу.
Потім запустіть перевірку заголовків безпеки. HSTS, Content-Security-Policy та подібні заголовки встановлює сервер чи CDN, і їх легко втратити під час переїзду. Порівняйте оцінку з тією, що була раніше.
Пошта: MX, SPF, DKIM і DMARC
Саме з поштою переїзди йдуть шкереберть найтихіше: сайт виглядає нормально, а те, що листи повертаються чи потрапляють у спам, днями ніхто не помічає.
| Запис | Що перевірити | Інструмент |
|---|---|---|
| MX | Вказує на поштового провайдера, яким ви справді користуєтеся; пошта не переїхала випадково разом із сайтом | Перевірка MX-записів |
| SPF (TXT) | Містить кожен сервер, що надсилає пошту від імені домену, зокрема новий вебсервер, якщо форми надсилають листи напряму; лише один SPF-запис; не більше 10 DNS-запитів | Перевірка SPF-запису |
| DKIM (TXT або CNAME) | Записи ключів підпису вашого поштового провайдера є в поточній зоні | Адмінпанель вашого поштового провайдера |
| DMARC (TXT) | Запис _dmarc існує і має потрібну вам політику | Перевірка DMARC-запису |
Потім зробіть справжню перевірку: напишіть на скриньку в домені із зовнішньої адреси й дайте відповідь. Якщо пошта зберігалася на старому сервері, переконайтеся, що листи, отримані під час перемикання, скопійовано.
Форми й транзакційні листи
Контактні форми, скидання пароля і підтвердження замовлень часто надсилають листи безпосередньо з вебсервера. На новому сервері функцію PHP mail() може бути вимкнено, порт 25 може бути заблоковано (часто на хмарних VPS), або нового IP може не бути в SPF. Надішліть кожну форму і запустіть скидання пароля. Якщо листи не надходять, надсилайте їх через SMTP-сервіс з автентифікацією замість локальної пошти сервера.
Застосунок, cron-завдання та інтеграції
- Cron-завдання і заплановані задачі: резервні копії, фіди, прогрівання кешу й черги розсилок. Відтворіть їх на новому сервері й перевірте, що старий сервер їх більше не запускає, інакше вони виконуватимуться двічі.
- Списки дозволених IP: платіжні шлюзи, API, файрволи й віддалені бази даних, які приймають лише IP старого сервера.
- Вебхуки: сервіси, що звертаються до вашого сайту, як-от платіжні провайдери, продовжують працювати через DNS, але перевірте їхні журнали доставки на помилки довкола перемикання.
- Права доступу до файлів і завантаження: завантажте зображення або файл через CMS.
- Кешування: очистьте кеш сторінок і кеш CDN, щоб відвідувачі не отримували сторінки, згенеровані на старому сервері.
Пошукові системи й аналітика
Перенесене налаштування staging може приховати весь сайт від пошуку. Шукайте метатег robots noindex або заголовок X-Robots-Tag, файл robots.txt, що забороняє все, і канонічні URL, які вказують на тимчасовий хост. Перевірте, що тег аналітики досі спрацьовує, а sitemap доступний. QA-звіт DNSPeek позначає такі залишки для пошукових систем разом із битими сторінками, відсутніми файлами і змішаним вмістом.
Нехай перевірки запускаються самі
Якщо до перемикання ви перевіряли новий сервер через посилання-превʼю DNSPeek, увімкніть для нього сповіщення про поширення DNS (на платних тарифах). Коли поширення для домену завершиться, DNSPeek повторно запустить QA-звіт на робочому домені й порівняє його з останнім звітом до перемикання: які сторінки зламалися, ведуть деінде або втратили заголовок. Див. Після перемикання DNS.
Порядок дій після переїзду
Крок 1: Переконайтеся, що DNS перемкнуто
Перевірте домен і www через публічні резолвери й переконайтеся, що сайт відповідає з нового IP.
Крок 2: Перевірте сертифікат
Перевірте видавця, термін дії й охоплення імен хостів за допомогою перевірки SSL.
Крок 3: Перевірте редиректи й заголовки
Простежте шлях від
http://до фінальної сторінки за допомогою перевірки редиректів і порівняйте заголовки безпеки зі старою конфігурацією.Крок 4: Перевірте поштові записи й надішліть тестовий лист
Перевірте MX, SPF і DMARC, підтвердьте DKIM у поштового провайдера, а потім надішліть і отримайте тестовий лист.
Крок 5: Надішліть кожну форму
Надішліть кожну контактну форму й запит на скидання пароля і переконайтеся, що листи надходять і не позначаються як спам.
Крок 6: Перевірте заплановані завдання та інтеграції
Відтворіть cron-завдання, оновіть списки дозволених IP, перевірте журнали вебхуків і очистьте кеші.
Крок 7: Перевірте налаштування для пошуку й ненадовго збережіть старий хостинг
Приберіть правила noindex зі staging, перевірте robots.txt і sitemap і збережіть старий хостинг, доки в його журналах не перестануть зʼявлятися відвідувачі.
Чекліст після перенесення
Після переїзду
- Домен і www резолвляться в новий IP по всьому світу
- Старий AAAA-запис оновлено або видалено
- Усі записи є в новій DNS-зоні
- Дійсний сертифікат для кожного імені хоста
- http → https і обробка www за один-два постійні редиректи
- Заголовки безпеки такі самі, як раніше, або кращі
- MX правильний, тестовий лист надіслано й отримано
- SPF містить кожен сервер-відправник, один запис, не більше 10 запитів
- Записи DKIM і DMARC присутні
- Листи з кожної форми і скидання пароля доставлено
- Cron-завдання відтворено; на старому сервері нічого не запускається
- Списки дозволених IP оновлено для нового сервера
- Немає noindex, robots.txt дозволяє сканування, канонічні URL правильні
- Кеші очищено, аналітика спрацьовує
- Резервне копіювання налаштовано на новому хостингу
Поширені запитання
Чому пошта перестала працювати після зміни хостингу?
Зазвичай MX-записи вказували на старий хостинг або DNS-зону перенесли без них. Спершу перевірте MX, потім SPF, DKIM і DMARC. Якщо пошта зберігалася на старому сервері, листи, що прийшли під час перемикання, можуть досі бути там.
Чому листи з контактної форми після переїзду потрапляють у спам?
Новий сервер надсилає пошту з IP, якого немає у вашому SPF-записі, без підпису DKIM або з хмарного IP з поганою репутацією. Надсилайте листи з форм через SMTP-сервіс з автентифікацією і додайте його до SPF.
Як скоро після переїзду має запрацювати SSL-сертифікат?
На більшості хостингів з автоматичними сертифікатами — за кілька хвилин після того, як DNS почне вказувати на новий сервер. Якщо за годину-дві сертифіката немає, перевірте, що кожне імʼя хоста вказує на новий сервер, і попросіть хостинг його випустити.
Чи переїжджають редиректи разом із файлами сайту?
Лише якщо вони зберігаються у файлах, які читає новий сервер. Правила в .htaccess працюють на Apache і LiteSpeed, але не на nginx, а редиректи, налаштовані в панелі старого хостингу чи в CDN, залишаються позаду. Перевірте їх за допомогою перевірки редиректів після переїзду.
Коли можна скасувати старий хостинг?
Коли поширення DNS завершено, журнали доступу старого сервера більше не показують реальних відвідувачів, пошта туди не надходить і у вас є фінальна резервна копія. Зачекати кілька днів після перемикання — безпечний варіант за замовчуванням.