Не заходит в админку WordPress: разбор всех типовых причин

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

Сайт открывается, клиенты его видят, реклама крутится, а панель управления перестала пускать хозяина. То пароль внезапно неверный, то после нажатия кнопки страница молча возвращает на форму входа, то вместо панели белый лист. Ситуация «не заходит в админку WordPress» выглядит одинаково снаружи, но внутри за ней стоят шесть-семь совершенно разных поломок, и лечатся они по-разному. Разберу их по симптомам: как сбросить пароль через базу и через WP-CLI, как отключить виновный плагин, не имея доступа к панели, где искать блокировку по IP и как понять, что перед вами не сбой, а взлом.

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

Сначала симптом, потом лечение

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

Что видите	Вероятная причина	Где чинить
Ошибка про неверный пароль	пароль сменили, испорчена таблица пользователей	база, WP-CLI
Форма перезагружается, ошибки нет	куки, кэш, адреса сайта, разъезд http и https	wp-config, база, кэш
Белый экран после входа	фатальная ошибка PHP в плагине или теме	файлы, лог ошибок
Кидает на главную страницу сайта	плагин смены адреса входа, правило в htaccess	файлы, база
403 Forbidden на адресе панели	фаервол хостинга, ограничение по IP	htaccess, панель хостинга
Ошибка соединения с базой данных	доступы в wp-config, лимиты хостинга	wp-config, хостинг
Просит код подтверждения, телефона нет	плагин двухфакторной аутентификации	база, WP-CLI
Вход прошёл, но меню пустое	слетела роль администратора	таблица usermeta

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

Что подготовить до починки

Для всего, что описано ниже, нужен доступ либо к файлам сайта (FTP, SFTP, файловый менеджер панели хостинга), либо к базе через phpMyAdmin, либо SSH с установленным WP-CLI. Если ничего этого нет, чинить нечем, и первая задача превращается в восстановление доступа к хостингу.

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

# копия файлов и базы перед вмешательством
cd /home/user/site
tar czf ~/backup-$(date +%F).tar.gz public_html
mysqldump -u db_user -p db_name > ~/db-$(date +%F).sql

Имя базы, пользователя и пароль лежат в wp-config.php в константах DB_NAME, DB_USER, DB_PASSWORD. Там же смотрите $table_prefix: стандартный префикс wp_, но на многих сайтах он свой, и все запросы ниже надо переписать под него. Если в базе таблицы вида xy7k_options, то и в SQL пишите xy7k_options.

Не принимает пароль

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

Дальше есть три способа сбросить пароль, от самого удобного к самому грубому.

Через WP-CLI

Если на хостинге есть SSH и WP-CLI, это дело одной минуты. Сначала посмотрите, какие администраторы вообще есть на сайте.

wp user list --role=administrator --fields=ID,user_login,user_email
wp user update 5 --user_pass='Dlinnyy-Parol-2026-Kotoryy-Ne-Podberut'
# если нужного пользователя в списке нет, создаём запасного
wp user create rescue rescue@example.ru --role=administrator --user_pass='...'

Команда wp user update сразу пишет корректный хэш, никаких дополнительных действий не нужно.

Через базу данных

Вариант для тех, у кого есть только phpMyAdmin. Открываете таблицу wp_users, находите нужную строку и выполняете запрос.

UPDATE wp_users
SET user_pass = MD5('Vremennyy-Parol-2026')
WHERE user_login = 'admin';

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

Если пароль после этого всё равно не принимается, посмотрите в wp_users поле user_status (должно быть 0) и убедитесь, что вы правите ту базу, к которой реально подключён сайт. Второе случается чаще, чем кажется: на хостинге лежат две базы от старого и нового сайта, а правки уходят в неиспользуемую.

Через временный mu-plugin

Способ на случай, когда доступ к базе закрыт, а к файлам есть. Создайте файл wp-content/mu-plugins/rescue.php (папку mu-plugins при необходимости создайте сами).

<?php
add_action('init', function () {
    $user = get_user_by('login', 'admin');
    if ($user) {
        wp_set_password('Vremennyy-Parol-2026', $user->ID);
    }
});

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

Письмо со сбросом не приходит

Штатная ссылка «Забыли пароль» отправляет письмо функцией mail(). На дешёвом shared-хостинге она либо отключена, либо письма улетают в спам, либо адрес отправителя не проходит проверку домена. Проверьте папку «Спам», а потом отправку в принципе:

wp eval 'var_dump(wp_mail("vy@example.ru", "test", "proverka"));'

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

Форма входа перезагружается по кругу

Вводите верные данные, страница моргает и снова показывает форму. Ошибки нет. Это почти всегда куки, и причин у него несколько.

Первая и самая частая: адрес сайта в базе не совпадает с тем, по которому вы заходите. Сайт живёт на https://example.ru, а в настройках прописано http://example.ru или https://www.example.ru. Кука ставится на один домен, проверяется на другом, вход не закрепляется. Смотрим, что в базе:

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Быстрое лечение делается в wp-config.php, оно перекрывает базу и не требует доступа к панели:

define('WP_HOME', 'https://example.ru');
define('WP_SITEURL', 'https://example.ru');
define('FORCE_SSL_ADMIN', true);

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

Вторая причина: кэш. Плагин кэширования или кэш на стороне сервера сохранил страницу /wp-login.php и отдаёт её всем подряд вместе с чужим токеном формы. Проверяется просто: откройте вход в приватном окне другого браузера. Если там всё нормально, чистите кэш и добавляйте страницу входа в исключения.

Третья причина встречается редко, но выносит мозг капитально: ушли часы на сервере. Кука с истёкшим сроком отбрасывается браузером мгновенно. Проверьте date в консоли и сравните с реальным временем.

Четвёртая: в wp-config.php кто-то прописал COOKIE_DOMAIN вручную при переезде, и там остался старый домен. Ищите строку и удаляйте.

Белый экран вместо панели

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

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Лог появится в wp-content/debug.log. Последние строки укажут файл и номер строки, а по пути файла сразу видно виновника: wp-content/plugins/имя-плагина/ или wp-content/themes/имя-темы/. Подробный разбор всех вариантов белого экрана, включая нехватку памяти и падение по версии PHP, есть в отдельной статье про белый экран смерти WordPress.

Отключить плагины без доступа к панели можно тремя способами. Через WP-CLI:

wp plugin deactivate --all
wp theme activate twentytwentyfour

Через файлы (грубо, но работает всегда):

mv wp-content/plugins wp-content/plugins-off
mkdir wp-content/plugins

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

Через базу, если файлы недоступны, а phpMyAdmin есть:

-- сначала СКОПИРУЙТЕ текущее значение себе в блокнот
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

Значение сериализованное, поэтому вернуть его можно только целиком тем текстом, что вы скопировали. Именно поэтому копируем до, а не после.

Кидает на главную страницу

Вы открываете адрес панели, а вас перебрасывает на главную сайта, будто вы и не пытались войти. Три сценария.

Первый: на сайте стоит плагин смены адреса входа (WPS Hide Login и его аналоги), а новый адрес забыт. Плагин работает ровно так: закрывает стандартный /wp-login.php редиректом на главную. Найти адрес можно в базе или консолью:

wp option get whl_page
grep -rn "whl_page|rename_wp_login" wp-content/plugins --include=*.php | head

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

Второй: правило в .htaccess. Откройте файл в корне сайта и посмотрите, нет ли там строк с RewriteRule или Redirect, задевающих wp-admin и wp-login. Файл иногда правят плагины безопасности и оставляют мусор после удаления.

Третий, самый неприятный: редирект уводит не на главную, а на посторонний домен или на страницу с рекламой. Это уже не поломка доступа, а следствие взлома, и починка пароля тут ничего не решит. Что смотреть и в каком порядке, я разбирал в материале про признаки взлома сайта.

Ошибка 403 и блокировка по IP

Если панель отдаёт 403 Forbidden ещё до формы входа, вас блокирует что-то, стоящее перед WordPress. Быстрая проверка занимает минуту: откройте сайт с мобильного интернета, отключив Wi-Fi. Если с телефона панель открывается, а с офисного адреса нет, значит забанен именно ваш IP.

Кто это делает:

• плагины безопасности (Wordfence, Solid Security, Limit Login Attempts) после серии неудачных попыток входа,
• фаервол хостинга и ModSecurity, которые считают ваши действия подозрительными,
• ручное правило deny from в .htaccess, оставленное прошлым подрядчиком,
• динамический IP провайдера: вчера он был белый, сегодня достался вам с чужим баном в истории.

Снять блокировку плагина без доступа к панели можно из базы. Названия таблиц зависят от плагина, посмотрите список таблиц и ищите по слову lockout или block:

SHOW TABLES LIKE '%lock%';
DELETE FROM wp_itsec_lockouts;

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

Вошли, но панель пустая

Редкий, но узнаваемый случай: логин и пароль приняты, а в меню только «Профиль», ни настроек, ни плагинов. Значит, у пользователя пропала роль администратора. Права WordPress хранит в таблице wp_usermeta в поле с именем <префикс>capabilities.

SELECT user_id, meta_key, meta_value FROM wp_usermeta
WHERE meta_key LIKE '%capabilities';

Классика жанра: при переносе сайта поменяли префикс таблиц, а мету не переименовали. Тогда в базе лежит oldpre_capabilities, а WordPress ищет wp_capabilities и не находит ничего. Лечится переименованием ключа или командой:

wp user add-role 5 administrator

Второй вариант той же беды: плагин управления ролями снёс возможности при обновлении. Тогда роль на месте, а прав нет, и восстанавливать надо через тот же плагин или через wp role reset administrator.

Двухфакторка без телефона

Если сайт просит одноразовый код, а приложение-генератор осталось на утопленном телефоне, вход открывается только отключением плагина 2FA. Порядок тот же: переименовать папку плагина в wp-content/plugins/, войти, настроить заново и сохранить резервные коды в менеджер паролей. Резервные коды генерируются при подключении и существуют ровно для этого случая, но их почти никто не сохраняет.

Что сделать после того, как доступ вернулся

Отдельный вопрос, который я задаю всегда: а почему, собственно, вход сломался? Если никто не обновлял плагины и не переносил сайт, а пароль вдруг перестал подходить, это подозрительно само по себе. Смена пароля администратора без ведома владельца это стандартный шаг после захвата сайта.

Чек-лист на полчаса:

1. Посмотреть список всех пользователей и дату их регистрации. Лишние администраторы, созданные недавно, это диагноз: wp user list --fields=ID,user_login,user_email,roles,user_registered.
2. Сменить пароли всем администраторам и редакторам, а не только себе.
3. Обновить соли в wp-config.php, чтобы разлогинить все чужие сессии: wp config shuffle-salts.
4. Проверить доступы к FTP и базе и сменить их тоже, если сайт вели несколько подрядчиков.
5. Обновить ядро, плагины и тему, предварительно сняв копию.
6. Проверить папку wp-content/uploads на наличие php-файлов: там их быть не должно совсем.
7. Посмотреть access.log за сутки до момента, когда всё сломалось, и найти успешный POST на wp-login.php с незнакомого адреса.
8. Убрать все временные костыли: mu-plugin со сбросом пароля, отладку в wp-config, переименованные папки.
9. Записать восстановленные доступы туда, где их не потеряют. Про варианты хранения и почему таблица в облаке это плохая идея, есть отдельный разбор: где хранить пароли от админки.

Пункт 7 обычно расставляет всё по местам. Если успешного входа с чужого IP нет, а есть тысячи неудачных, значит вас просто перебирали ботами и по дороге забанил собственный плагин безопасности. Это неприятно, но не страшно.

Сколько времени это занимает

Ориентиры из практики, чтобы понимать, во что вы ввязываетесь и когда пора звать человека со стороны.

Ситуация	Время при наличии доступа к хостингу
Сброс пароля через WP-CLI или базу	5-15 минут
Разъезд адресов, куки, кэш	15-30 минут
Поиск плагина, ломающего вход	30-60 минут
Снятие блокировки хостинга	зависит от скорости поддержки
Восстановление роли администратора	20-40 минут
Разбор после взлома с чисткой	от 4 часов и дальше

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

Если ничего из списка не помогло

Соберите перед обращением к специалисту пять вещей: точный текст ошибки (скриншотом), адрес сайта, что менялось на сайте за последние семь дней, есть ли доступ к панели хостинга и есть ли бэкап. С этим набором диагностика занимает минуты, без него первый час уходит на выяснение, кто и когда что трогал.

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

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

Частые вопросы

Что делать, если не заходит в админку WordPress

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

Как сбросить пароль без доступа к почте

Через базу данных или через консоль. В базе меняют хэш пароля у нужного пользователя, через консоль пароль ставится одной командой. Занимает 5-15 минут при наличии доступа к хостингу.

Почему форма входа перезагружается по кругу

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

Что делать при белом экране вместо панели

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