Если в админке WordPress часть страниц открывается нормально, а часть внезапно уходит в 404, проблема обычно не в самом редакторе. Чаще ломается маршрут: конфликт плагина, неверный rewrite, битый .htaccess, ограничения роли или ошибка в коде темы/му-плагина. Важно не лечить это вслепую: одинаковый симптом может быть у разных причин.
Как выглядит проблема и где её искать сначала
Типичный сценарий: вы заходите в список записей, страницы или в настройки плагина, а WordPress показывает 404, пустую страницу или редиректит не туда. При этом фронтенд может работать нормально. Это уже намекает, что сломана не вся установка, а конкретный маршрут в админке или в плагине.
Что проверить в первую очередь
- открывается ли
/wp-admin/и/wp-login.php; - ломается ли только один раздел или вся админка;
- есть ли недавно обновлённый плагин, тема или mu-plugin;
- не меняли ли вы
.htaccess, nginx-конфиг или правила безопасности; - не включён ли кэш для админки через сторонний плагин или прокси.
Если 404 появляется только на страницах конкретного плагина, почти всегда виноват его собственный роутинг или конфликт с другим плагином. Если 404 затрагивает и стандартные экраны WordPress, копайте в пермалинках, правилах сервера и фильтрах, которые вмешиваются в запрос.
Диагностика: как быстро сузить причину
Начинайте с самого дешёвого теста: откройте сайт в режиме инкогнито и отключите все плагины кроме тех, без которых админка не работает. Если проблема исчезла, включайте плагины по одному. Это банально, но именно так быстрее всего ловится конфликт.
Если отключать плагины на живом сайте нельзя, используйте временное переименование папки плагина по FTP или SSH. Для проверки маршрутов полезно посмотреть, что реально отдаёт сервер, а не только браузер.
curl -I https://example.com/wp-admin/admin.php?page=my-plugin-pageЕсли в ответе уже виден 404, проблема на уровне маршрута или сервера. Если сервер отдаёт 200, а в браузере вы видите 404-страницу темы, значит запрос перехватывает WordPress или плагин, а не веб-сервер.
Ещё один полезный шаг — включить логирование ошибок. В wp-config.php временно добавьте:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);После этого откройте проблемную страницу и посмотрите wp-content/debug.log. Если там есть ошибки вида Call to undefined function, Cannot modify header information или фатал в плагине, причина уже почти найдена.
Пошаговое решение: от простого к точному
1. Сбросьте правила постоянных ссылок
Если 404 затрагивает не только админку, но и часть внутренних страниц, сначала обновите правила пермалинков. В админке откройте Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это пересоздаёт rewrite rules.
Если доступа к админке нет, можно сделать это через код в временном плагине или в functions.php, но не держите такой код постоянно:
add_action('init', function () {
flush_rewrite_rules(false);
});Этот вариант годится только как разовая мера. После первого захода код нужно убрать, иначе вы будете сбрасывать правила на каждом запросе и получите лишнюю нагрузку.
2. Проверьте .htaccess или правила nginx
На Apache стандартный .htaccess для WordPress должен содержать базовые правила. Если файл повреждён или его перезаписал плагин безопасности, маршруты могут начать отдавать 404.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>На nginx аналогичная логика должна быть в конфигурации сайта. Если вы не уверены, что именно изменилось, сравните текущий конфиг с рабочей резервной копией. Для админки особенно критично, чтобы запросы к /wp-admin/ и /wp-login.php не переопределялись лишними правилами.
3. Найдите конфликтующий плагин или хук
Частая причина — плагин добавляет свой admin_menu, admin_init или собственный rewrite endpoint, но делает это с ошибкой. Если 404 появляется только на странице настроек конкретного плагина, отключите его и проверьте, исчезла ли проблема.
Если вы пишете свой код, не регистрируйте страницы админки без проверки прав и существования меню. Пример безопасной регистрации страницы:
add_action('admin_menu', function () {
add_menu_page(
'Мои настройки',
'Мои настройки',
'manage_options',
'my-settings',
'my_settings_render_page',
'dashicons-admin-generic'
);
});
function my_settings_render_page() {
if (!current_user_can('manage_options')) {
wp_die('Недостаточно прав');
}
echo '<div class="wrap"><h1>Мои настройки</h1></div>';
}Если страница есть в меню, но при переходе отдаёт 404, проверьте, не подменяет ли её другой плагин через редирект или фильтр admin_url.
4. Проверьте роли, capabilities и доступ по nonce
Иногда 404 — это не реальная ошибка маршрута, а намеренное скрытие страницы для пользователя без нужной роли. Некоторые плагины специально отдают 404 вместо 403, чтобы не светить существование раздела. Если проблема только у одного пользователя, проверьте его роль и права.
Для собственного кода не подменяйте отсутствие прав на 404 без необходимости. Лучше явно проверять capability и завершать запрос через wp_die() или стандартный экран отказа.
Сравнение подходов: что быстрее и безопаснее
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| Сброс пермалинков | После миграции, правок .htaccess, обновления rewrite | Быстро и без кода | Не помогает при конфликте плагинов |
| Отключение плагинов | Если 404 только в одном разделе | Точно находит источник | Нужно время и доступ к сайту |
| Логи и debug.log | Если есть фаталы или странные редиректы | Показывает конкретную ошибку | Требует аккуратности на проде |
Как проверить, что исправление сработало
После правки не ограничивайтесь визуальной проверкой одной страницы. Пройдитесь по короткому чек-листу:
- откройте проблемный раздел в обычном браузере и в инкогнито;
- проверьте ответ сервера через
curl -I; - посмотрите, нет ли новых ошибок в
debug.log; - обновите страницу с отключённым кэшем браузера;
- если это страница плагина, проверьте её под пользователем с нужной ролью.
Если после сброса пермалинков и отключения конфликтующего плагина 404 исчезает, не возвращайте старую конфигурацию сразу. Сначала включайте компоненты по одному и фиксируйте, на каком именно шаге проблема возвращается. Это экономит время при повторном инциденте.
Частые ошибки и как их исправить
Код сброса rewrite rules оставили навсегда
Это одна из самых дорогих ошибок по производительности. flush_rewrite_rules() нельзя вызывать на каждом запросе. Используйте его только разово, затем удаляйте код.
Проверяют только фронтенд, а админку не тестируют
После обновления темы или плагина фронтенд может работать, но админские маршруты уже сломаны. Проверяйте именно ту страницу, где был 404, а не только главную.
Путают 404 от WordPress и 404 от сервера
Если сервер возвращает 404 до загрузки WordPress, в логах CMS может не быть ничего полезного. Сначала определите, кто именно отдаёт ответ: nginx, Apache, WordPress или плагин.
Не учитывают кэш и защитные плагины
Плагины безопасности и reverse proxy иногда кэшируют ошибочный ответ. После исправления очистите кэш плагина, серверный кэш и CDN, иначе вы будете видеть старую 404-страницу.
Безопасность и производительность: что не стоит делать
Не отключайте проверки прав ради того, чтобы «страница просто открывалась». Если проблема в capability, исправляйте роль или код, а не убирайте защиту. Не держите WP_DEBUG включённым на проде с выводом ошибок в браузер. Для диагностики достаточно лог-файла.
Если вы часто ловите 404 после обновлений, имеет смысл вынести собственный код из темы в отдельный плагин или mu-plugin. Так вы не потеряете логику при смене темы и быстрее локализуете источник проблемы. Для сайтов, где важны чистка дублей, SEO и техническая гигиена, полезно держать под рукой инструменты вроде Clearfy Pro, но использовать их точечно, а не как замену нормальной диагностике.
Главная мысль простая: сначала определите, где именно ломается маршрут, потом исправляйте причину. В WordPress 404 в админке почти всегда лечится, если не смешивать сервер, rewrite, плагины и права в одну корзину.