«Сайт ненадолго закрыт на техническое обслуживание» (Briefly unavailable for scheduled maintenance): как быстро вернуть WordPress онлайн

Надпись «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту.» (в английской версии WordPress — «Briefly unavailable for scheduled maintenance. Check back in a minute.») появляется, пока обновляются ядро, тема или плагин, и остаётся, если обновление прервалось: в корне сайта остался служебный файл .maintenance. Подождите до 10 минут, а если надпись не исчезла, удалите этот файл через файловый менеджер хостинга или по FTP — сайт, как правило, сразу снова открывается. Тексты, фото и страницы при этом не теряются.

Обычно всё начинается одинаково: вы нажали «Обновить», закрыли вкладку или на секунду потеряли связь — и теперь вместо сайта одна строка, а админка тоже не открывается. Кажется, что вы всё сломали, но почти всегда это не так: сообщение — не ошибка, а защитный механизм WordPress, который после прерванного обновления остался включённым. Ниже — что именно произошло, как разблокировать сайт по шагам и как не допустить повторения.

Коротко: что делать прямо сейчас

• Обновление запущено только что? Подождите. WordPress сам перестаёт учитывать файл .maintenance через 10 минут после начала обновления.
• Прошло больше 10 минут? Удалите файл .maintenance из корня сайта — из папки, где лежат wp-admin, wp-content и wp-includes.
• Обновите страницу без кеша и очистите кеш сайта: плагин кеширования, кеш хостинга, CDN.
• Повторите обновление, которое оборвалось, и на этот раз дождитесь сообщения «Все обновления завершены.»

Почему появляется сообщение (файл .maintenance)

Перед тем как заменить файлы ядра WordPress, активной темы или активного плагина, система создаёт в корневой папке сайта скрытый файл .maintenance. Пока файл лежит на сервере (но не дольше 10 минут — об этом ниже), каждый посетитель видит страницу обслуживания, а сервер отвечает кодом 503 («сервис временно недоступен») и просит повторить попытку позже. Так никто не увидит сайт «наполовину обновлённым», пока копируются новые файлы.

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

• вы закрыли вкладку или ушли со страницы до конца обновления;
• скрипту не хватило времени выполнения или памяти на хостинге;
• на хостинге закончилось место на диске;
• сервер ответил слишком медленно или на секунду пропала связь;
• вы обновляли сразу много плагинов, и на одном из них процесс «застрял»;
• новая версия плагина или темы конфликтует с вашей версией WordPress или PHP.

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

То есть ваш контент не сломан — это просто забытый на двери замок.

Сначала подождите 10 минут

В коде WordPress заложено простое правило: если с момента, записанного в файле .maintenance, прошло 10 минут или больше, режим обслуживания считается завершённым и сайт открывается, даже если файл остался на сервере. Поэтому, если обновление началось пару минут назад, ничего не трогайте: удалить файл посреди работающего обновления — значит показать посетителям полуобновлённый сайт.

Если надпись держится дольше 10 минут, ждать больше нет смысла. Как правило, причина в одном из трёх:

• файл создал не стандартный механизм обновлений WordPress, а плагин, скрипт хостинга или человек вручную, и вместо фиксированного времени в нём записано, например, $upgrading = time(); — такой файл сам не «истекает»;
• вы видите сохранённую копию страницы из кеша браузера, плагина, хостинга или CDN;
• это вовсе не служебная страница WordPress, а плагин режима обслуживания (см. таблицу ниже).

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

Как удалить файл .maintenance: пошагово

Понадобится доступ к файлам сайта: файловый менеджер в панели хостинга (cPanel, Plesk, ISPmanager или собственная панель хостера), FTP/SFTP-клиент вроде FileZilla или SSH.

• Откройте корневую папку сайта — ту, где видны wp-admin, wp-content и wp-includes. У многих хостеров это public_html или папка с именем домена. Если WordPress установлен в подпапку, файл лежит именно там.
• Включите показ скрытых файлов: имя .maintenance начинается с точки, поэтому по умолчанию файл не виден. В cPanel: кнопка Settings → галочка «Show Hidden Files (dotfiles)» → Save. В FileZilla: меню «Сервер» → «Принудительно отображать скрытые файлы» (в английской версии — Force showing hidden files). В других панелях ищите похожую настройку в параметрах файлового менеджера.
• Удалите только файл .maintenance. Не путайте его с .htaccess — это тоже скрытый файл, и без него могут перестать открываться страницы сайта. Файл maintenance.php в папке wp-content трогать тоже не нужно: это необязательный шаблон страницы обслуживания, сайт закрытым он не держит.
• Если у вас есть SSH, достаточно выполнить в корне сайта команду rm .maintenance.
• Откройте сайт в режиме инкогнито или обновите страницу без кеша: Ctrl+F5 в Windows, Cmd+Shift+R в Chrome и Firefox на Mac.

В большинстве случаев сайт сразу возвращается. Если у вас стоит плагин кеширования или CDN, очистите и их кеш, чтобы посетители не получали старую копию страницы.

Что видно на экране и что это значит

Если сайт открылся, но что-то сломано

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

• Войдите в админку (/wp-admin) и откройте «Консоль → Обновления». Если WordPress, тема или плагин всё ещё числятся как требующие обновления, запустите обновление снова и не закрывайте вкладку, пока не увидите «Все обновления завершены.»
• Если видите «На сайте возникла критическая ошибка», проверьте почту администратора сайта. WordPress присылает туда письмо со ссылкой на режим восстановления: по ней вы попадаете в админку, где проблемный плагин или тема приостановлены, и можете их отключить.
• Белый экран или админка не открывается — временно отключите плагин, который обновлялся: переименуйте его папку в wp-content/plugins (например, plugin-x → plugin-x-off). Затем откройте в админке страницу «Плагины»: WordPress не найдёт плагин и деактивирует его. После этого верните папке прежнее имя, обновите или переустановите плагин и снова активируйте его. Подробно этот сценарий мы разобрали в статье про белый экран смерти в WordPress.
• Не знаете, какой плагин виноват? Временно переименуйте всю папку wp-content/plugins, например в plugins-off. Если сайт ожил, откройте в админке страницу «Плагины» (WordPress отключит все плагины, которые не нашёл), затем верните папке имя plugins и включайте плагины по одному, проверяя сайт после каждого.
• Чтобы увидеть конкретную ошибку, включите журнал: в wp-config.php задайте define( 'WP_DEBUG', true ), define( 'WP_DEBUG_LOG', true ) и define( 'WP_DEBUG_DISPLAY', false ). Записи появятся в файле wp-content/debug.log. Это инструмент для диагностики, а не для постоянной работы на живом сайте, поэтому после исправления отключите его (документация WordPress).
• Очистите кеш: плагин кеширования, кеш хостинга и CDN.

Если у вас есть резервная копия, сделанная до обновления, её восстановление — самый надёжный способ вернуться в рабочее состояние.

Совет, который лучше не применять: правка wp-activate.php

В некоторых русскоязычных инструкциях советуют открыть wp-activate.php и заменить в строке define( 'WP_INSTALLING', true ) значение true на false. Не делайте этого. Этот файл отвечает только за активацию новых пользователей и сайтов в мультисайте (на обычном сайте он просто перенаправляет на страницу регистрации), а строка с WP_INSTALLING — штатная часть ядра. К файлу .maintenance она отношения не имеет, а при следующем обновлении WordPress этот файл всё равно будет перезаписан.

Как не допустить повторения

Застрявший режим обслуживания почти всегда — следствие прерванного обновления. Несколько простых привычек это предотвращают:

• Не закрывайте вкладку и не уходите со страницы, пока не увидите «Все обновления завершены.» На медленном хостинге обновление может занять больше времени, чем кажется.
• Обновляйте по одному, а не десятки плагинов сразу. Если что-то зависнет, вы будете точно знать причину.
• Перед обновлением проверьте, что новая версия плагина или темы поддерживает ваши версии WordPress и PHP.
• Следите за ресурсами хостинга: свободное место на диске, лимиты памяти и времени выполнения PHP. Когда их не хватает, обновления могут обрываться на середине.
• Делайте резервную копию перед крупными обновлениями: ядро WordPress, тема, конструктор страниц. Многие хостинги делают бэкапы автоматически — заранее узнайте, где они хранятся и как восстанавливаются.
• В идеале проверяйте обновления на тестовой копии сайта (staging). Как это устроить, мы описали в статье как обновить WordPress и не сломать сайт.

Нормальный хостинг плюс обновления с умом — это разница между «пятью минутами испуга» и «потерянным днём».

Когда стоит попросить помощи

Если вы удалили файл, а сайт всё равно не возвращается, или видите ошибки базы данных либо белый экран и не уверены, что именно задели, — пора остановиться: каждая попытка наугад может всё усложнить. Тот, кто уже сталкивался с этим, обычно быстро выводит сайт из обслуживания и чинит прерванное обновление, не теряя контент.

В MPO Web Studio мы работаем полностью удалённо, поэтому неважно, где вы находитесь: пришлите доступ, мы посмотрим и честно скажем, что произошло и сколько займёт работа. Если помощь нужна прямо сейчас, напишите нам в WhatsApp с коротким описанием и скриншотом сообщения — мы быстро отвечаем и прямо говорим, дело это пяти минут или чего-то более серьёзного.