Сайт не працює після перенесення на новий сервер, що перевірити

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

Проблема в тому, що сайт — це не лише файли на хостингу. Це домен, DNS-записи, база даних, SSL-сертифікат, налаштування сервера, версії PHP або Node.js, права доступу, кеш, пошта, API, CRM, платіжні системи, редиректи й технічна SEO-основа.

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

Чому сайт може зламатися після перенесення на новий сервер

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

На старому хостингу могли бути одні версії PHP, Node.js, MySQL, Apache або Nginx, а на новому — інші. Могли відрізнятися налаштування безпеки, шляхи до директорій, права на файли, ліміти пам’яті, правила редиректів або спосіб обробки пошти.

Найчастіше сайт після перенесення не працює через такі причини:

• домен ще не вказує на новий сервер;
• DNS-записи оновилися не повністю;
• SSL-сертифікат не встановлений або встановлений неправильно;
• база даних імпортована з помилками;
• у конфігурації залишилися старі доступи до бази;
• не перенесені .env-змінні або конфігураційні файли;
• відрізняється версія PHP, Node.js або MySQL;
• не налаштовані правила Apache/Nginx;
• внутрішні сторінки не відкриваються через rewrite-помилки;
• не працює пошта, форми, CRM або платіжні інтеграції;
• зламалися шляхи до зображень, CSS або JavaScript;
• старий кеш показує неактуальну версію сайту.

Головне — не сприймати це як одну загальну проблему “сайт впав”. У більшості випадків причина конкретна, її можна знайти через послідовну перевірку.

Спочатку визначте, як саме сайт не працює

Перед тим як виправляти сайт, потрібно зрозуміти симптом. Різні помилки вказують на різні рівні проблеми.

Що бачить користувачЙмовірна причинаСайт взагалі не відкриваєтьсяDNS, сервер, домен, firewallБраузер показує небезпечне з’єднанняSSL-сертифікат або HTTPS-редиректПомилка 500серверна помилка, код, база, версії, праваВідкривається головна, але не працюють сторінкиrewrite rules, маршрути, permalink, Nginx/ApacheСайт без стилів або фотонеправильні шляхи, mixed content, права на файлиНе працює адмінкасесії, cookies, права, база, конфігНе надходять заявкиSMTP, пошта, API, CRM, reCAPTCHAGoogle бачить 404 або 5xxнеправильні відповіді сервера, редиректи, robots.txt

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

DNS: домен ще не веде на новий сервер

Одна з найчастіших причин — домен після перенесення все ще веде на старий сервер або частина користувачів бачить стару версію сайту.

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

Що потрібно перевірити в DNS

Насамперед варто перевірити:

• чи правильно вказаний A-запис домену;
• чи правильно налаштований www;
• чи немає конфлікту між A-записом і CNAME;
• чи не залишилися старі NS-сервери;
• чи правильно працює Cloudflare, якщо він використовується;
• чи не веде піддомен на старий IP;
• чи не забули змінити DNS для мовних або технічних піддоменів.

Якщо сайт переноситься без зміни домену і структури URL, для SEO це зазвичай безпечніший сценарій, ніж повна зміна адрес. Але навіть у такому випадку важливо, щоб Googlebot мав доступ до нової інфраструктури, а сервер стабільно відповідав на запити.

SSL-сертифікат: сайт відкривається як небезпечний

Ще одна типова ситуація: після перенесення сайт відкривається, але браузер показує попередження про небезпечне з’єднання. Або сайт працює на http, але не працює на https.

Причини можуть бути різні:

• SSL-сертифікат не встановлений на новому сервері;
• сертифікат виписаний не для того домену;
• не додано www або потрібний піддомен;
• сертифікат встановлений, але сервер не віддає його правильно;
• налаштований неправильний редирект з HTTP на HTTPS;
• на сторінці залишилися ресурси через http, тому виникає mixed content.

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

Що перевірити після встановлення SSL

Після перенесення потрібно відкрити сайт у кількох варіантах:

• http://site.com
• https://site.com
• http://www.site.com
• https://www.site.com

Усі ці варіанти мають вести на одну основну версію сайту. Якщо частина відкривається, частина показує помилку, а частина створює циклічний редирект — SSL або правила редиректів налаштовані неправильно.

Помилка 500 після перенесення сайту

Помилка 500 означає, що сервер отримав запит, але не зміг його нормально обробити. Для користувача це виглядає просто: сайт не працює. Але для розробника це сигнал, що потрібно дивитися серверні логи.

Після перенесення помилка 500 часто виникає через несумісність нового середовища з кодом сайту.

Типові причини помилки 500

Найчастіше це:

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

Наприклад, WordPress-сайт може не працювати через відсутній PHP-модуль або неправильний шлях до директорії. Next.js або Node.js-проєкт може падати, якщо не запущений процес через PM2, не встановлені залежності або в .env залишилися старі дані.

У таких випадках найкраще не гадати, а перевіряти error logs. Вони часто одразу показують, який файл, модуль або підключення викликає помилку.

База даних перенесена неправильно або сайт не може до неї підключитися

Сайт може виглядати “живим”, але показувати порожні сторінки, старий контент або помилки в адмінці. Часто причина — база даних.

Після перенесення потрібно переконатися, що база:

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

Для CMS-сайтів проблема може бути в неправильних даних у wp-config.php, config.php або іншому конфігураційному файлі. Для проєктів на фреймворках — у .env, змінних середовища або підключенні до зовнішньої бази.

Окремо варто перевірити кодування. Якщо після перенесення текст став некоректним, з’явилися дивні символи або частина даних не відображається, проблема може бути не в шаблоні, а в експорті чи імпорті бази.

Внутрішні сторінки відкриваються з 404

Буває, що головна сторінка після перенесення працює, а всі внутрішні сторінки показують 404. Це класична проблема з rewrite rules або маршрутизацією.

Для WordPress це часто пов’язано з permalink-структурою або .htaccess. Для сайтів на Nginx — з неправильним location-конфігом. Для Next.js, Laravel, Nuxt, OpenCart або інших систем — із маршрутизацією, серверним проксі або правилами обробки запитів.

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

У такій ситуації варто окремо перевірити помилку 404, бо вона може забирати трафік поступово: спочатку користувачі потрапляють на неробочі сторінки, потім Google частіше бачить помилки, а далі сторінки можуть втрачати видимість.

Фото, стилі або скрипти не підвантажуються

Ще один сценарій: сайт відкривається, але виглядає зламаним. Немає стилів, не показуються фото, не працює меню, а частина блоків “розсипалася”.

Причина може бути в шляхах до файлів або правах доступу.

Після перенесення варто перевірити:

• чи перенесені всі папки з медіафайлами;
• чи правильні права на директорії;
• чи не змінився шлях до uploads, storage, public або static;
• чи немає посилань на старий домен або IP;
• чи не блокуються CSS/JS файли;
• чи не виникає mixed content через HTTP-ресурси на HTTPS-сайті;
• чи правильно працює CDN.

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

Не працюють форми, пошта, CRM або оплата

Після перенесення власник часто перевіряє тільки головну сторінку: відкривається — значить, усе добре. Але сайт може виглядати нормально і при цьому не приносити заявок.

Найчастіше після переїзду ламаються:

• форми зворотного зв’язку;
• відправка листів через SMTP;
• інтеграція з CRM;
• Telegram/Viber-сповіщення;
• онлайн-оплата;
• API доставки;
• reCAPTCHA;
• webhook-и;
• аналітика і події конверсій.

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

Тому після міграції потрібно тестувати не тільки сторінки, а весь шлях користувача: від відкриття сайту до відправки заявки, отримання листа, передачі даних у CRM і фіксації конверсії в аналітиці.

Кеш: чому сайт у всіх відкривається по-різному

Після перенесення може виникнути дивна ситуація: у власника сайт не працює, у програміста працює, у клієнта відкривається стара версія, а в мобільному інтернеті — нова.

Причина часто в кеші:

• DNS-кеш провайдера;
• кеш браузера;
• кеш CMS;
• серверний кеш;
• кеш CDN;
• кеш Cloudflare;
• кеш сторінок або статичних файлів.

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

Тому після міграції бажано очищати кеш на всіх рівнях: у CMS, на сервері, в CDN, у браузері. Але робити це потрібно обережно, щоб не створити додаткове навантаження або не приховати реальну причину помилки.

Як перенесення сайту на новий сервер впливає на SEO

Якщо сайт переноситься правильно, без зміни структури URL і без тривалого простою, SEO-ризики мінімальні. Але якщо після перенесення з’являються 404, 500, неправильні редиректи, закриття від індексації або проблеми зі швидкістю, позиції можуть просісти.

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

Що може зашкодити SEO після перенесення

Найбільші ризики:

• сайт довго недоступний;
• важливі сторінки віддають 404;
• сервер часто повертає 500;
• змінилася структура URL без редиректів;
• зникли meta title і description;
• canonical веде на старий домен або стару версію;
• robots.txt випадково закрив сайт від індексації;
• sitemap містить старі або неробочі URL;
• сторінки стали значно повільнішими;
• не працюють мовні версії або hreflang.

Після перенесення варто перевірити сайт у Google Search Console: індексацію, помилки сторінок, sitemap, сканування, мобільну зручність і важливі URL через інструмент перевірки сторінки.

Що робити, якщо сайт уже не працює після перенесення

Якщо сайт уже перенесли і він зламався, краще діяти послідовно.

1. Не видаляйте старий сервер одразу

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

Найгірша ситуація — коли старий хостинг уже видалили, backup неповний, а новий сайт не працює.

2. Перевірте домен і DNS

Потрібно переконатися, що домен веде на правильний IP, www працює коректно, NS-записи актуальні, а Cloudflare або інший CDN не створює конфлікт.

3. Перевірте SSL і редиректи

Сайт має відкриватися через HTTPS без попереджень, циклічних редиректів і конфлікту між www та non-www.

4. Перевірте серверні логи

Логи часто швидше показують причину, ніж ручне тестування. Там можна побачити помилки підключення до бази, відсутні файли, проблеми з правами, несумісні модулі або помилки коду.

5. Перевірте базу даних

Потрібно звірити, чи всі дані перенесені, чи правильні доступи, чи немає помилок імпорту, чи сайт підключається саме до нової бази.

6. Протестуйте ключові сценарії

Недостатньо просто відкрити головну сторінку. Потрібно перевірити:

• головну;
• послуги або категорії;
• картку товару;
• блог;
• форму заявки;
• кошик;
• оплату;
• адмінку;
• пошук;
• мобільну версію;
• аналітику;
• sitemap і robots.txt.

Якщо це комерційний сайт, кожна неперевірена функція може означати втрачені заявки.

Як правильно переносити сайт на новий сервер

Щоб сайт не впав після переїзду, міграцію краще готувати заздалегідь.

До перенесення

Перед стартом потрібно зробити повний backup файлів і бази, зафіксувати поточну структуру URL, перевірити доступи до домену, хостингу, CMS, бази, пошти, CDN і аналітики.

Також варто підготувати новий сервер: встановити потрібні версії ПЗ, налаштувати базу, SSL, пошту, права доступу, залежності, змінні середовища і тестовий запуск.

Під час перенесення

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

Краще спочатку стабільно перенести сайт, а вже потім поступово вносити зміни.

Після перенесення

Після запуску потрібно перевірити технічні відповіді сторінок, швидкість, форми, індексацію, редиректи, sitemap, robots.txt, аналітику та заявки.

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

Коли потрібен програміст або технічна підтримка

Якщо проблема обмежується DNS або SSL, її іноді можна вирішити швидко. Але якщо після перенесення з’явилися помилки 500, не працює база, падає адмінка, зламалися форми або сайт втрачає сторінки в Google — краще не експериментувати.

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

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

Висновок

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

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

Правильне перенесення сайту — це не просто “скопіювати файли”. Це технічна міграція, яка має зберегти стабільність, заявки, SEO, швидкість і довіру користувачів.

FAQ

Чому сайт не відкривається після перенесення на новий сервер?

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

Скільки часу оновлюються DNS після перенесення сайту?

Зазвичай зміни можуть застосуватися не миттєво. Частина користувачів може бачити новий сервер, а частина — старий, поки DNS-кеш не оновиться у провайдерів, браузерах і проміжних сервісах.

Чому головна сторінка працює, а внутрішні сторінки показують 404?

Це часто пов’язано з правилами маршрутизації: .htaccess, Nginx-конфігом, permalink-структурою, налаштуваннями CMS або фреймворку. Після перенесення сервер може не обробляти внутрішні URL так, як це було на старому хостингу.

Чому після перенесення сайт показує помилку 500?

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

Чому після перенесення не працюють форми заявки?

Форми можуть залежати від SMTP, поштового сервера, API, CRM, reCAPTCHA або webhook-ів. Після зміни сервера могли змінитися IP, токени, доступи, налаштування пошти або callback URL.

Чи може перенесення сайту нашкодити SEO?

Так, якщо після перенесення сайт довго недоступний, важливі сторінки віддають 404 або 500, змінилися URL без редиректів, зникли meta-теги, закрився robots.txt або sitemap містить неправильні адреси.

Чи потрібно змінювати URL під час перенесення на новий сервер?

Якщо мета — просто змінити сервер або хостинг, URL краще не змінювати. Так менше SEO-ризиків. Зміну структури URL краще робити окремим етапом із продуманими 301-редиректами.

Що перевірити після перенесення сайту в першу чергу?

Потрібно перевірити DNS, SSL, головну сторінку, внутрішні сторінки, адмінку, базу даних, форми, пошту, оплату, мобільну версію, sitemap, robots.txt, редиректи, швидкість і помилки в Search Console.