Не могу войти в админку WordPress: что проверить

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

Сначала: правильный адрес и кэш браузера

Штатный вход — https://ваш-домен.ru/wp-login.php или /wp-admin/ (редирект на login). Частые ошибки:

• закладка на старый домен после переезда (www ↔ без www, http вместо https);
• кастомный URL входа от плагина безопасности — вы забыли, куда перенесли (смена URL wp-login);
• мультисайт: вход может быть через /wp-admin/network/ для суперадмина;
• жёсткий кэш браузера — пробуйте инкognito или другой браузер.

Если форма логина вообще не рисуется — это уже не пароль, а ошибка PHP или блокировка на сервере (см. ниже).

Причина 1. Неверный пароль и блокировка после брутфорса

Limit Login Attempts, Wordfence, iThemes Security после серии неудачных попыток блокируют IP на 15–60 минут. Признак: «неверный пароль» даже с правильным — потому что форма не доходит до проверки.

Что сделать:

1. Сброс пароля через «Забыли пароль?» на wp-login.php?action=lostpassword — письмо должно уйти (если почта настроена, см. SMTP).
2. Если письма нет — сброс через phpMyAdmin: таблица wp_users, поле user_pass — хеш от MD5() только для экстренного входа, затем смените пароль в профиле на нормальный bcrypt.
3. Разблокировка IP — в панели плагина или удаление опции limit_login_lockouts в wp_options (осторожно, только если уверены в причине).

Если брутфорс шёл на известные логины — проверьте, не светятся ли они через REST: утечка /wp-json/wp/v2/users.

Причина 2. Cookie, HTTPS и зеркала домена

После входа WordPress ставит cookie авторизации. Если в «Настройки → Общие» адрес сайта — https://site.ru, а вы открываете http://www.site.ru, cookie не приклеятся: форма отправляется, снова login.

Чек-лист:

• Адрес WordPress и адрес сайта в настройках — одинаковые, с https://, тот же хост, что в браузере.
• 301 с http на https и с лишнего зеркала — одно правило на весь сайт.
• В DevTools → Application → Cookies после успешного логина есть wordpress_logged_in_*.
• Не тестируйте с включённым «блокировать cookie» в расширениях.

Тот же сценарий ломает корзину WooCommerce — см. пустая корзина.

Причина 3. Плагин безопасности или WAF режет wp-login

Wordfence «Learning Mode» выключен, правило WAF на хостинге, плагин «Hide Login» с опечаткой в URL — результат: 403, пустая страница или редирект на главную без формы.

Проверка: DevTools → Network → POST на wp-login.php. 403/503 — смотреть логи хостинга и WAF. Временно переименуйте wp-content/plugins/wordfence (или другой security) через FTP — если форма появилась, настраивайте исключения, а не отключайте защиту навсегда.

XML-RPC и перебор пачками — отдельная тема в REST и xmlrpc и проверке XML-RPC.

Причина 4. .htaccess и ограничение wp-admin по IP

После «усиления безопасности» в корневой .htaccess или в wp-admin/.htaccess часто остаётся:

<Files wp-login.php>
  Require ip 123.45.67.89
</Files>

Вы сменили провайдера или работаете из дома — доступ пропал. Решение: правка через FTP/SFTP или панель файлов хостинга. На Nginx аналог — allow/deny в конфиге, правит поддержка.

Лишние RewriteRule после миграции тоже режут вход — сравните с чистым .htaccess из codex WordPress.

Причина 5. Белый экран или critical error только в админке

Типичный сценарий: витрина открывается, /wp-admin/ — WSOD или «There has been a critical error». Плагин или код в functions.php падает только при is_admin().

Порядок:

1. Включить WP_DEBUG_LOG в wp-config.php, обновить админку, прочитать debug.log.
2. Переименовать wp-content/plugins → plugins_OFF — если админка ожила, включать плагины по одному.
3. Recovery Mode — ссылка из письма WordPress после critical error (разбор recovery).

Если и фронт, и админка белые — алгоритм из статьи про WSOD.

Причина 6. База данных и «Error establishing a database connection»

Если видите именно это сообщение — WordPress не подключается к MySQL. Подробный алгоритм — в статье про ошибку базы: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST в wp-config.php (после переезда DB_HOST часто не localhost, а имя из панели Beget/Timeweb).

Лимит соединений на shared-хостинге — реже, но бывает при тяжёлом cron + плагинах. Временно отключите object cache и проверьте статус MySQL в панели хостинга.

Причина 7. Взлом: новый админ, редирект с login

Незнакомый пользователь в «Пользователи», редирект с wp-login.php на сторонний сайт, подозрительные файлы wp-login.bak.php — не продолжайте перебирать пароли. План из «Взломали WordPress»: бэкап, смена всех паролей и ключей в wp-config.php, чистка, аудит безопасности.

Чек-лист за вечер

1. Правильный URL, инкognito, без VPN-блокировок.
2. Сброс пароля / проверка блокировки IP в security-плагине.
3. Сверка https и cookie после попытки входа.
4. Network: нет ли 403 на wp-login.php.
5. .htaccess — нет ли Deny/Require ip.
6. debug.log при белом экране только в админке.
7. Если признаки взлома — не «чинить пароль», а план восстановления.

Не получается снять блокировку за вечер — опишите проблему («крутится login», «403», «белый экран только админка») в контактах или через срочную починку; оценка за 20 минут.