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

Міграція сайту на новий хостинг або сервер не завершується моментом, коли файли скопійовано, а домен почав відкриватися. Після перенесення можуть змінитися налаштування DNS, шляхи до файлів, параметри бази даних, права доступу, SSL-сертифікат і робота зовнішніх сервісів.

Щоб не пропустити приховані проблеми, перевіряйте сайт послідовно. Якщо перенесення ще тільки планується, корисно заздалегідь ознайомитися з рекомендаціями щодо Перенесення сайту на новий хостинг без втрати даних. Перед будь-якими змінами обов’язково збережіть копії файлів і бази даних зі старого та нового середовища.

Коди відповідей і редиректи

Спочатку перевірте, чи всі основні сторінки сайту відкриваються з коректним HTTP-кодом. Для доступної сторінки зазвичай має повертатися код 200. Помилки 404, 403, 500 або 502 можуть свідчити про відсутні файли, неправильні права доступу, помилки конфігурації сервера чи проблеми зі з’єднанням із базою даних.

• відкрийте головну сторінку, категорії, картки товарів або послуг;
• перевірте кілька старих URL, які могли бути проіндексовані пошуковими системами;
• переконайтеся, що HTTP-версія перенаправляє на HTTPS;
• перевірте варіанти домену з www і без нього;
• переконайтеся, що редиректи не утворюють циклів або довгих ланцюжків;
• перевірте, чи не залишилися тимчасові редиректи 302 там, де потрібен постійний 301.

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

Форми та інтеграції

Форми зворотного зв’язку, замовлення, авторизації та підписки потрібно перевіряти не лише візуально. Надішліть тестову заявку й переконайтеся, що вона доходить до адміністратора, записується в базу даних або CRM, а користувач бачить коректне повідомлення.

• перевірте контактні форми та відправлення електронної пошти;
• переконайтеся, що листи не потрапляють у спам і надходять із правильної адреси домену;
• протестуйте авторизацію, відновлення пароля та вихід із кабінету;
• перевірте кошик, оформлення замовлення, оплату й повідомлення про статус операції;
• переконайтеся, що працюють CRM, телефонія, чати, webhook-запити та API;
• перевірте завантаження файлів, якщо така функція передбачена.

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

Для інтернет-магазину тестове замовлення краще проводити за повним сценарієм, але без реального списання коштів або з використанням тестового режиму платіжної системи. Не видаляйте робочі дані під час перевірки, якщо немає актуальної резервної копії.

SSL і змішаний контент

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

Змішаний контент виникає, коли захищена HTTPS-сторінка завантажує зображення, стилі, скрипти або шрифти через HTTP. Частина таких ресурсів може блокуватися браузером, через що ламається оформлення, меню, слайдери або платіжні компоненти.

• відкрийте консоль браузера та перевірте повідомлення про mixed content;
• знайдіть у коді та базі даних старі посилання з http://;
• перевірте URL зображень, CSS, JavaScript, шрифтів і зовнішніх бібліотек;
• переконайтеся, що канонічні адреси сторінок також використовують HTTPS;
• перевірте, чи не залишилися старі адреси в налаштуваннях WordPress і плагінів.

Перед масовою заміною URL у базі даних зробіть її копію. Некоректна заміна може пошкодити серіалізовані дані WordPress або налаштування плагінів. Якщо після ввімкнення HTTPS з’явилися циклічні перенаправлення, причиною може бути одночасна примусова переадресація на рівні CDN, хостингу, WordPress і вебсервера.

Аналітика й індексація

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

• перевірте Google Analytics або іншу систему статистики;
• переконайтеся, що код встановлено лише один раз;
• перевірте налаштування цілей, конверсій і подій;
• відкрийте файл robots.txt і переконайтеся, що сайт не заблоковано випадковим правилом;
• перевірте наявність і доступність sitemap.xml;
• переконайтеся, що в налаштуваннях сайту не залишився режим заборони індексації;
• перевірте канонічні URL, метатег noindex і правильність основного домену.

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

Не оцінюйте результат міграції за миттєвою зміною позицій у пошуку. Спочатку усуньте технічні помилки, переконайтеся в доступності сторінок і правильності сигналів для пошукових систем. Для точного аналізу варто порівняти дані до та після перенесення.

Резервна копія нового стану

Коли основні перевірки завершено, створіть резервну копію вже працездатного сайту на новому сервері. Вона має містити файли сайту, базу даних, конфігураційні файли та, за можливості, інформацію про версії PHP, вебсервера й важливих розширень.

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

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

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