Не работает админка WordPress: как восстановить доступ к wp-admin

Если сайт открывается, а /wp-admin — нет, не спешите переустанавливать WordPress. Админка загружается через то же ядро, но дополнительно подключает административные файлы, плагины, права пользователя и авторизацию. Поэтому проблема часто локальная: сайт для посетителей ещё работает, а панель управления уже «ушла на обед».

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

Сначала определите, что именно происходит с wp-admin

Фраза «не работает админка WordPress» описывает сразу несколько разных проблем. Симптом важен: он подсказывает, где искать причину.

• Форма входа открывается, но снова возвращает на логин — проверяем cookies, URL сайта, кэш и редиректы.
• Ошибка 500 — в первую очередь нужны PHP/server logs, затем проверка плагинов и темы.
• Белый экран — вероятна PHP-ошибка или сбой компонента.
• 403 Forbidden — проверяем серверные правила, защитные плагины, WAF и права доступа.
• 404 на /wp-admin — смотрим URL, правила веб-сервера и изменения адреса входа.
• Админка открывается, но отдельная страница падает — ищем компонент, который выполняется именно на этом экране.

Быстрая проверка. Откройте сайт в приватном окне браузера и отдельно адрес ваш-домен.ru/wp-login.php. Если там всё работает, а в обычном браузере нет, начинать разбор сервера пока рано.

1. Очистите cookies и кэш браузера

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

Это особенно актуально, если форма входа принимает пароль, но снова показывает тот же экран или сообщение о cookies.

Проверьте вход в приватном окне. Если там авторизация проходит, удалите cookies именно для домена сайта. Сбрасывать весь браузер до заводских настроек не требуется — WordPress всё-таки сайт, а не непослушный роутер.

2. Проверьте адрес сайта и HTTPS

Циклический редирект при входе может появиться, если WordPress считает основным один URL, а браузер фактически открывает другой. Типичные пары: http и https, домен с www и без него.

Если проблема началась после подключения SSL, миграции или смены домена, проверьте значения WordPress Address и Site Address. Когда админка недоступна, их можно проверить через базу данных или конфигурацию — но на рабочем сайте не меняйте URL наугад.

Если видите бесконечные редиректы: сначала исключите конфликт HTTP/HTTPS и кэш/прокси, а уже потом разбирайте плагины.

3. Если wp-admin показывает ошибку 500 — откройте лог

HTTP 500 не сообщает причину. Он лишь говорит, что сервер не смог завершить запрос. Поэтому полезнее всего запись в PHP или server error log, сделанная в тот же момент.

Ищите PHP Fatal error, Allowed memory size exhausted, Uncaught TypeError, Parse error и путь к файлу плагина или темы.

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

Что это значит. Если в логе указан файл wp-content/plugins/название-плагина/..., у вас уже есть конкретный подозреваемый. Отключать подряд всё содержимое сайта не нужно.

4. Включите журнал WordPress, если server log ничего не объяснил

WordPress поддерживает встроенный журнал отладки. На рабочем сайте сообщения лучше записывать в файл и не показывать посетителям:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Настройки добавляют в wp-config.php до строки завершения редактирования. После повторения ошибки проверьте wp-content/debug.log.

WordPress прямо предупреждает: инструменты отладки предназначены прежде всего для development/staging. После диагностики на production их следует отключить.

Если вместо админки появляется сообщение о критической ошибке, посмотрите разбор критической ошибки WordPress. А если лог содержит именно Fatal Error — отдельная инструкция есть в статье «Fatal Error в WordPress: как найти причину».

5. Проверьте плагины — даже если в админку войти нельзя

Плагин может ломать только административную часть сайта. Например, его код выполняется на admin_init или конкретном экране wp-admin, поэтому фронтенд продолжает работать.

Если проблема появилась сразу после обновления конкретного плагина, начните с него. Через файловый менеджер хостинга или SFTP временно переименуйте каталог этого плагина внутри wp-content/plugins. WordPress перестанет его загружать.

Если виновник неизвестен, на резервной или staging-копии можно временно исключить обычные плагины и затем возвращать их по одному. Не забывайте про wp-content/mu-plugins: must-use плагины загружаются автоматически.

Не делайте так: не удаляйте каталоги плагинов «для проверки». Деактивация обратима, удаление — уже совсем другой жанр.

6. Исключите тему

Тема тоже выполняет PHP-код и может конфликтовать с текущей версией WordPress или PHP. Особенно подозрительна ситуация, когда проблема появилась после редактирования functions.php или обновления темы.

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

7. Проверьте версию PHP и память

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

Сообщение Allowed memory size exhausted означает, что PHP-процесс исчерпал доступную память. Но просто повышать лимит до бесконечности — не диагностика. Нужно понять, какой компонент потребляет память и какой лимит реально задан сервером.

Быстрая проверка: если wp-admin сломался сразу после смены PHP, верните последнюю заведомо рабочую поддерживаемую конфигурацию и проверьте совместимость компонентов перед новым переключением.

8. Если после входа снова выбрасывает на логин

Когда пароль принимается, но WordPress не удерживает сессию, проверьте cookies, домен и протокол. Также причиной могут быть правила кэширования или reverse proxy, которые не должны кэшировать авторизованную административную сессию.

Если используются CDN, серверный кэш или защитный сервис, убедитесь, что /wp-admin/ и страница входа обрабатываются корректно. Здесь важно не отключать защиту сайта целиком «на пять минут» на production. Лучше проверить правила точечно.

9. Что делать с 403 Forbidden

403 означает, что запрос понятен серверу, но доступ запрещён. В WordPress это может быть связано с WAF, защитным плагином, серверными правилами, IP-ограничениями или некорректными правами.

Смотрите журналы веб-сервера и системы безопасности. Если 403 появился после изменения правил защиты, откатите именно последнее изменение. Выставлять 777 на каталоги WordPress не нужно: это небезопасно и редко лечит настоящую причину.

10. Проверьте .htaccess только на Apache

Ошибочные директивы в .htaccess могут нарушить доступ к сайту или административной части на Apache. Сделайте копию файла перед изменениями.

Если сервер работает на Nginx, .htaccess вообще не участвует в обработке запросов. Искать его там — примерно как проверять масло у электрического чайника. Смотрите конфигурацию Nginx, PHP-FPM и логи.

11. Если проблема появилась после обновления WordPress

WordPress при загрузке wp-admin подключает ядро через wp-load.php, а административный bootstrap — через wp-admin/admin.php. Повреждённые или неполностью обновлённые системные файлы могут нарушить этот процесс.

Сначала исключите плагины, тему и PHP. Если есть основания подозревать неудачное обновление Core, сделайте резервную копию и проверьте целостность системных файлов. Не заменяйте wp-content и wp-config.php случайным архивом.

12. Проверьте версию WordPress: в августе 2026 это особенно важно

6 августа 2026 года WordPress опубликовал security advisory для уязвимости на экране входа, затрагивающей множество веток WordPress. Для ветки 7.0 исправление вошло в WordPress 7.0.3; исправления также были backport-нуты в поддерживаемые старые ветки.

Это не означает, что любая проблема с wp-admin вызвана уязвимостью. Но если сайт работает на версии ниже исправленной для своей ветки, откладывать security update не стоит. Перед обновлением рабочего проекта — резервная копия и проверка совместимости.

Когда пора остановиться

Самостоятельно безопасно проверить браузер, cookies, точный симптом, последние обновления и доступные логи. Но если для восстановления требуется менять базу данных, серверную конфигурацию, PHP-FPM, права владельца файлов или вручную восстанавливать Core на рабочем сайте, цена ошибки становится выше.

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

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

1. Откройте /wp-login.php в приватном окне.
2. Определите симптом: redirect, 500, 403, 404, белый экран или ошибка отдельной страницы.
3. Вспомните последнее изменение: плагин, тема, PHP, SSL, миграция.
4. При 500/белом экране сразу смотрите PHP/server log.
5. При необходимости включите WP_DEBUG_LOG без вывода ошибок посетителям.
6. Если лог указывает на плагин — временно отключите именно его.
7. Исключите тему и проверьте PHP.
8. Проверьте серверные правила только после того, как более простые причины исключены.

FAQ

Почему сайт работает, а wp-admin не открывается?

Административная часть выполняет дополнительный PHP-код и административные хуки. Поэтому плагин, тема или серверное правило могут ломать только wp-admin, не затрагивая публичные страницы.

Как отключить плагин, если нет доступа в админку?

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

Почему WordPress после входа снова показывает форму авторизации?

Частые причины — cookies, конфликт HTTP/HTTPS, различие домена с www и без www, а также некорректное кэширование страницы входа или административной сессии.

Нужно ли переустанавливать WordPress, если не работает админка?

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

Можно ли оставить WP_DEBUG включённым?

На production это нежелательно. Для диагностики лучше записывать ошибки в лог и не показывать их посетителям, а после завершения проверки отключить debug-режим.