Что делать, если сайт перестал открываться после смены хостинга

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

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

Проверьте домен и DNS-записи

Сначала убедитесь, что домен направлен на новый хостинг. В панели регистратора должны быть указаны актуальные NS-серверы либо A-запись с IP-адресом нового сервера. Если остались данные прежнего провайдера, посетители будут попадать на старую площадку или видеть сообщение об ошибке.

После изменения DNS требуется время для обновления информации у разных интернет-провайдеров. Обычно это занимает от нескольких минут до 24–48 часов. Проверить результат можно через сервисы диагностики DNS, сравнив IP-адрес домена из разных регионов.

Также стоит проверить записи для поддомена www. Нередко основной адрес уже работает, а версия с www — нет. Для обеих версий должны быть настроены корректные A- или CNAME-записи, а в конфигурации сайта желательно задать единый основной адрес.

Убедитесь, что файлы размещены правильно

При переносе файлы должны находиться в корневой директории, которую использует сервер: например, public_html, www или htdocs. Если архив распакован во вложенную папку, хостинг не найдёт файл index.php или index.html, и вместо сайта появится список каталогов либо ошибка 403.

Проверьте, что перенесены скрытые файлы, включая .htaccess, а также папки с изображениями, стилями, скриптами и загрузками. Потеря .htaccess часто приводит к неработающим ЧПУ-адресам: главная страница открывается, а внутренние разделы возвращают 404.

Права доступа тоже имеют значение. Обычно для папок устанавливают значение 755, а для файлов — 644, если требования CMS не предусматривают иные параметры. Слишком строгие права блокируют чтение ресурсов, а чрезмерно открытые создают угрозу безопасности.

Восстановите базу данных и настройки CMS

Сайт на WordPress, Joomla, Drupal или самописной системе может не запускаться, если база данных не была перенесена или подключена с неверными параметрами. В панели нового хостинга создайте базу и пользователя, импортируйте резервную копию через phpMyAdmin или другой доступный инструмент.

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

Симптом	Вероятная причина	Что проверить
Ошибка подключения к базе данных	Неверные реквизиты или база не импортирована	Конфигурационный файл и список баз
Белый экран	Ошибка PHP или несовместимая версия	Версию PHP и журналы ошибок
404 на внутренних страницах	Не перенесён .htaccess или отключены правила URL	Файл правил и настройки CMS
Предупреждение SSL	Сертификат не установлен для домена	Сертификат, цепочку и редирект HTTPS
Сайт открывается у одних пользователей	DNS ещё обновляется	A-записи и кэш DNS

Настройте версию PHP и серверное окружение

После смены хостинга сайт может попасть на другую версию PHP, MySQL или веб-сервера. Старые плагины и шаблоны иногда несовместимы с PHP 8.1 или 8.2, тогда как прежняя площадка работала на PHP 7.4. Результатом становятся критические ошибки, пустая страница или циклическая загрузка.

В панели управления выберите версию PHP, рекомендованную CMS и её расширениями. Проверьте наличие модулей mbstring, curl, mysqli, gd, zip и других зависимостей, необходимых конкретному проекту. После изменения параметров очистите кэш приложения и серверный кэш.

Точную причину часто показывает журнал ошибок PHP или лог веб-сервера. В нём можно увидеть имя проблемного файла, отсутствующий модуль или ошибку синтаксиса. На рабочем сайте вывод технических ошибок для посетителей лучше отключить, оставив запись данных в журнал.

Проверьте HTTPS, редиректы и почту

Если домен открывается по HTTP, но не загружается по HTTPS, установите SSL-сертификат для основного домена и поддомена www. Важно проверить срок действия сертификата, правильность цепочки доверия и соответствие имени домена. После установки настройте перенаправление с HTTP на HTTPS.

Ошибочный редирект может создать бесконечный цикл: сервер переводит запрос на HTTPS, а CMS считает, что соединение остаётся обычным HTTP. Такая ситуация возникает из-за неверной настройки прокси, CDN или параметров сайта. Проверьте адрес WordPress и URL-адрес публикации, а также правила в .htaccess или конфигурации Nginx.

При переезде нередко перестаёт работать корпоративная почта. Для её сохранения нужно перенести MX-записи, а также записи SPF, DKIM и DMARC. Если почта обслуживается отдельно от сайта, смена веб-хостинга не должна автоматически менять почтовые параметры домена.

Проведите проверку после восстановления

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

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

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