Представьте: вы дописали пост, нажали «Опубликовать», а WordPress выдаёт красную плашку с ошибкой. Обновить страницу? Та же ошибка. Перезайти в админку? Без изменений. Пост висит в черновиках, а время поджимает.

Ошибка обновления (Updating Failed) или публикации (Publishing Failed), одна из тех проблем, которые ставят в тупик: сообщение не говорит, что именно сломалось. Но за годы работы с WordPress мы вывели чёткую последовательность диагностики. В большинстве случаев причина, на поверхности, а исправление занимает пару минут.

В этом материале, 7 проверенных способов: от самых простых (интернет и URL сайта) до точечной отладки через wp-config и работы с плагинами. Каждый шаг, с конкретными действиями и скриншотами из админки.

💡 Быстрый обзор:

• Проверить интернет-соединение и URL сайта в настройках
• Открыть «Инструменты → Состояние сайта» и проверить статус REST API
• Включить режим отладки через WP_DEBUG в wp-config.php
• Удалить временный файл .maintenance с сервера через FTP
• Деактивировать все плагины разом, и включать по одному, выявляя конфликт
• Временно заменить Gutenberg на Classic Editor, чтобы исключить конфликт с блочным редактором
• Если ничего не сработало, обратиться к хостеру или сообществу WordPress

1. Проверьте интернет-соединение и URL сайта

Самая простая, и потому часто упускаемая, причина: WordPress теряет связь с сервером посередине запроса.

Откройте соседнюю вкладку браузера и зайдите на любой сайт. Страница загрузилась? Интернет работает. Нет, восстановите соединение и попробуйте опубликовать пост заново.

Если интернет в порядке, следующий подозреваемый, настройки URL. За годы миграций, смены доменов и экспериментов с HTTPS адреса в «Настройки → Общие» иногда расходятся с реальностью. Перейдите туда и сверьте два поля: Адрес WordPress (URL) и Адрес сайта (URL). Они должны совпадать с фактическим адресом, по которому вы заходите в админку.

Если оба адреса верны, а ошибка не уходит, идём глубже.

2. Проверьте статус REST API

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

К счастью, в WordPress 5.2 и новее есть встроенный инструмент диагностики. Зайдите в Инструменты → Состояние сайта (Site Health). Пролистайте до секции «Рекомендуемые улучшения» и найдите строку «The REST API encountered an unexpected result», или аналогичную ошибку.

Если REST API показывает ошибку, раскройте отладочную информацию тут же, на вкладке «Информация» → «REST API». Вы увидите конкретный вызов, который не прошёл, и код ответа сервера. Чаще всего проблема кроется в:

• Плагине безопасности, блокирующем REST-запросы (Wordfence, iThemes/Solid Security с агрессивными настройками файрвола);
• Кастомном коде в functions.php, который случайно ломает REST-эндпоинты;
• Плагине кеширования, отдающем закешированный ответ REST API.

Отключите подозрительный плагин и перепроверьте состояние REST API на той же странице.

3. Включите режим отладки WordPress

Когда проблема не на поверхности, её нужно «подсветить», для этого в WordPress предусмотрен встроенный режим отладки.

Вам понадобится доступ к файлам сайта. Подойдёт FTP-клиент (FileZilla, WinSCP) или файловый менеджер в панели хостинга. Перед любыми правками файлов, сделайте бэкап. Ошибка в wp-config.php может положить сайт, а резервная копия вернёт всё за минуту.

Порядок действий:

• Подключитесь к серверу через FTP, найдите корневую папку WordPress (там же где лежат wp-content, wp-admin и wp-includes).
• Найдите файл wp-config.php и скачайте его на компьютер.
• Откройте файл в текстовом редакторе (Notepad++, Sublime Text, не Word и не Блокнот, которые ломают кодировку).
• В самый низ, перед строкой /* That's all, stop editing! Happy publishing. */, добавьте:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Первая строка включает отладку, вторая, пишет ошибки в файл wp-content/debug.log (не показывая посетителям), третья, скрывает ошибки с экрана сайта.

Сохраните файл и загрузите обратно на сервер с заменой. Теперь попробуйте опубликовать пост. Если ошибка ушла, причина была в предупреждении PHP, которое глушило REST-ответ. Откройте wp-content/debug.log через тот же FTP и найдите записи с PHP Notice или PHP Warning, они укажут на плагин-виновник.

Когда закончите, обязательно отключите WP_DEBUG, заменив true на false, иначе debug.log будет расти бесконечно.

Если ошибка осталась, идём дальше.

4. Удалите файл.maintenance

WordPress создаёт временный файл .maintenance в корне сайта во время обновлений ядра, плагинов и тем. Он переводит сайт в режим обслуживания, посетители видят сообщение «Технические работы, зайдите позже».

Иногда обновление завершается, а .maintenance остаётся. WordPress думает, что обслуживание ещё идёт, и блокирует публикацию.

Снова откройте FTP, зайдите в корневую папку и найдите файл .maintenance (с точкой в начале, он скрытый; в FileZilla включите показ скрытых файлов через «Сервер → Принудительно показывать скрытые файлы»).

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

5. Найдите конфликтный плагин

Самая частая причина ошибок публикации, конфликт плагинов. Один плагин ломает REST API, другой вмешивается в процесс сохранения, третий конфликтует с Gutenberg.

Быстрый способ найти виновного, массовая деактивация с последовательным включением:

• Перейдите в Плагины → Установленные плагины.
• Отметьте галочкой «Плагин» в шапке таблицы, выберутся все.
• В выпадающем списке «Действия» выберите «Деактивировать» и нажмите «Применить».

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

Что делать с проблемным плагином:

• Обновите его до последней версии (разработчик мог уже исправить баг).
• Напишите в поддержку плагина с деталями: версия WordPress, версия плагина, при каких действиях возникает ошибка.
• Временно замените аналогом, пока разработчик не выпустит фикс.

6. Временно замените Gutenberg на Classic Editor

Блочный редактор Gutenberg появился в WordPress 5.0 и с тех пор прошёл долгий путь. Но конфликты с отдельными плагинами и темами до сих пор случаются, особенно со старыми page builder'ами (WPBakery, старые версии Elementor) и плагинами, которые не адаптированы под REST API.

Классический редактор не использует REST API для сохранения, он работает по старому admin-ajax.php. Поэтому его установка, быстрый тест: если ошибка исчезает, проблема именно в связке Gutenberg + какой-то плагин.

Установите Classic Editor, официальный плагин от команды WordPress:

• Плагины → Добавить новый.
• В поиске наберите «Classic Editor».
• Нажмите «Установить», затем «Активировать».

После активации попробуйте опубликовать пост через классический редактор. Работает? Значит, конфликт на стороне Gutenberg.

Важно: это диагностический, а не постоянный шаг. Classic Editor отключает блочный редактор, вы теряете все возможности Gutenberg: блоки, шаблоны, встроенное форматирование. Когда найдёте плагин-виновник (методом из шага 5), удалите Classic Editor и вернитесь к Gutenberg, уже с исправленным окружением.

7. Обратитесь за помощью

Если пройдены все шесть шагов, а ошибка не уходит, проблема, скорее всего, лежит глубже: на уровне сервера, хостинга или редкого бага ядра WordPress.

Вот куда обращаться, по порядку эффективности:

Хостинг-провайдер. Напишите в техподдержку с деталями: версия WordPress, версия PHP, какие плагины активны, при каком действии возникает ошибка. У хостера есть доступ к серверным логам, часто они видят причину за минуту (закончилось дисковое пространство, PHP-модуль отключён, лимит памяти).

Форумы WordPress. Официальный форум поддержки WordPress.org, живое сообщество, где отвечают разработчики ядра и авторы плагинов. Откройте тему, приложите скриншоты и вывод debug.log.

После чтения этого материала у вас есть полная цепочка диагностики: от щелчка мыши до правки серверных файлов. В 9 случаях из 10 проблема решается на шагах 1-5, без FTP и wp-config.

Ниже, ответы на самые частые вопросы и видео для закрепления материала.

⁉️🤔 Частые вопросы

Почему ошибка возникает сразу после обновления WordPress?

Скорее всего, один из плагинов несовместим с новой версией ядра или новой версией PHP, которую хостинг активировал вместе с обновлением. Пройдите шаг 5 (массовая деактивация), вы быстро найдёте виновного.

Можно ли просто переустановить WordPress и не разбираться?

Переустановка ядра через «Обновления → Установить заново» безопасна и не трогает контент/плагины. Но если ошибка вызвана конфликтом плагинов, переустановка ядра не поможет. Лучше потратить 5 минут на диагностику по шагам выше, чем вслепую перебирать решения.

Почему ошибка появляется только на одном посте, а остальные публикуются нормально?

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

Нужно ли держать Classic Editor постоянно после фикса?

Нет. Classic Editor, временное диагностическое решение. Как только вы нашли и исправили конфликтный плагин, удалите Classic Editor и вернитесь к Gutenberg. Блочный редактор, стандарт WordPress, и отказываться от него без серьёзной причины не стоит.

Что делать, если нет доступа к FTP?

Используйте файловый менеджер в панели хостинга (cPanel → File Manager, ISPmanager → Файлы). Функционально он делает то же самое. Если и его нет, обратитесь в техподдержку хостинга, они помогут с доступом.

Какой из способов пробовать первым?

Универсальная формула: проверьте интернет (10 секунд) → загляните в Site Health (30 секунд) → массово деактивируйте плагины (1 минута). В большинстве случаев на этом этапе проблема уже решена.

Если ошибка возвращается после фикса, значит, найден не корень, а симптом. Включите WP_DEBUG_LOG (шаг 3) и соберите полный лог, он покажет точный файл и строку с ошибкой. С этим логом можно идти в поддержку плагина или на форум WordPress.

И главное: всегда держите свежий бэкап. Он превращает любой сбой из катастрофы в пятиминутную задержку.