Сначала определите причину

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

Войдите в кабинеты регистратора и хостинга через известные адреса сервисов. Проверьте состояние услуг и уведомления. Если не получается войти, используйте официальный процесс восстановления доступа и подтверждения владения. Доступ к CMS, хостингу и домену — разные доступы; восстановление одного не восстанавливает остальные автоматически.

Запишите время последней нормальной работы, последние изменения и точный текст ошибки. Это поможет поддержке найти нужный период. Не отправляйте пароли в открытый чат и не передавайте полный архив незнакомому «восстановителю».

Что делать до любых изменений

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

Обратитесь к хостеру и уточните даты копий, состав, условия восстановления и срок хранения. Наличие автоматических бэкапов зависит от тарифа и правил провайдера. Нельзя рассчитывать, что копия обязательно существует или хранится месяцами после прекращения оплаты.

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

Как выбрать резервную копию

Ищите не просто самую свежую, а последнюю заведомо рабочую копию до сбоя. Сопоставьте дату с моментом обновления, удаления или появления подозрительных изменений. Проверьте, что архив открывается и содержит именно нужный проект, а не только отдельный каталог.

Для типичного WordPress нужны и файлы, и база — это прямо описано в официальном руководстве по резервным копиям. Скачивание папки сайта обычно не является резервным копированием базы данных.

Как восстановить сайт из бэкапа

По возможности разверните копию в отдельном тестовом окружении, закрытом от посторонних. Для магазина заранее отключите реальные платежи, рассылки и автоматические уведомления: проверка старой базы не должна отправлять повторные сообщения покупателям.

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

В WordPress параметры подключения находятся в wp-config.php. Не переносите советы по этому файлу на другую CMS. При смене домена также может потребоваться корректировка адресов в данных; простая массовая замена текста подходит не для всех форматов хранения.

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

Если резервной копии нет

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

Веб-архив может помочь восстановить публичные тексты и внешний вид отдельных страниц, если они были сохранены. Но это не полноценная копия приложения: закрытые разделы, база заказов, серверный код и часть изображений могут отсутствовать. Не обещайте себе восстановление интернет-магазина «одной кнопкой» из снимка страницы.

Если исходные данные утрачены, составьте перечень того, что можно восстановить точно, а что придётся создать заново. Сохраните известные URL там, где это возможно; изменение адресов требует отдельного плана перенаправлений. Возврат контента и возврат прежних позиций в поиске — разные задачи.

Что проверить после восстановления

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

Проверьте HTTPS, коды ответов, canonical и настройки индексации. Тестовое окружение должно оставаться закрытым, а на опубликованном сайте не должны случайно остаться запреты, поставленные на время ремонта. Посмотрите журнал ошибок после первых обращений.

Завершите работу новой резервной копией и проверкой её восстановления. Храните копии отдельно от единственного рабочего сервера и назначьте ответственного за контроль. Расписание зависит от того, какой объём свежих изменений вы готовы потерять, а не от наличия кнопки «бэкап» в панели.