Сценарий типичный: сайт уже перевели на HTTPS, включили кеш на сервере или в плагине, а после этого /wp-login.php внезапно начал отдавать 404. Иногда вместо ошибки открывается пустая страница, иногда редирект уходит на главную, а иногда проблема проявляется только в одном браузере или только для части пользователей.
Здесь важно не лечить симптом наугад. 404 на странице входа обычно означает не поломку авторизации как таковой, а конфликт между SSL-настройками, правилами кеширования, редиректами и иногда — кастомными правилами в .htaccess или конфигурации nginx.
Что именно ломается и как это выглядит
Перед правками проверьте, где возникает ошибка: на самом wp-login.php, на /wp-admin/ или только после отправки формы. Это разные проблемы.
- 404 на
/wp-login.php— чаще всего неверный редирект, правило сервера или кеш, который отдает не тот ответ. - 404 после отправки формы входа — нередко конфликт cookie, домена, HTTPS и настроек прокси/CDN.
- 404 только у части пользователей — часто виноват кеш страницы или edge-cache у CDN.
Быстрая диагностика
Сначала проверьте ответ сервера без браузерного кеша. Удобнее всего через curl:
curl -I https://example.com/wp-login.phpСмотрите на три вещи: код ответа, цепочку редиректов и заголовки кеша. Если вместо 200/302 вы видите 404, а в заголовках есть признаки кеша вроде cache-control, x-cache или cf-cache-status, проблема может быть не в WordPress, а на уровне прокси или CDN.
Полезно также проверить, не подменяется ли адрес входа плагином безопасности. Если раньше вы меняли URL входа, убедитесь, что статья уже не про это: здесь речь именно о стандартном wp-login.php.
Пошаговое решение: от простого к точному
1. Очистите все уровни кеша
Начинайте с очевидного: кеш плагина, серверный кеш, CDN и кеш браузера. Если используется Cloudflare или аналогичный сервис, временно обойдите его или поставьте правило исключения для /wp-login.php и /wp-admin/*.
Для плагинов кеширования обычно нужно исключить:
/wp-login.php/wp-admin/*/wp-admin/admin-ajax.php
Если этого не сделать, кеш может отдавать старую страницу или ошибочный редирект даже после исправления настроек.
2. Проверьте редирект с HTTP на HTTPS
После перевода сайта на SSL часто остаются дублирующие правила: одно в панели хостинга, второе в .htaccess, третье — в плагине. В результате запрос к wp-login.php может уходить по кругу или попадать в несуществующий маршрут.
В wp-config.php должны быть корректно заданы адреса сайта, если вы меняли домен или схему вручную:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Если эти константы уже используются, убедитесь, что они совпадают с реальным HTTPS-адресом. Ошибка в одной букве домена или в схеме http/https легко приводит к странным 404 на входе.
3. Исключите wp-login.php из кеша и оптимизации
Некоторые плагины оптимизации пытаются «ускорить всё» и случайно затрагивают служебные URL. Для страницы входа это лишнее: её не нужно минифицировать, объединять и кешировать как обычную публичную страницу.
Если у вас есть доступ к настройкам плагина кеша, отключите для страницы входа:
- page cache;
- browser cache для этой страницы;
- HTML minify, если плагин умеет применять его выборочно;
- lazy load и прочие фронтенд-оптимизации, если они почему-то цепляются к форме входа.
4. Проверьте правила сервера
Если сайт на Apache, посмотрите .htaccess. Если на nginx — конфигурацию виртуального хоста. Частая ошибка: правило, которое принудительно отправляет все запросы на главную или на кастомный роут, не исключая wp-login.php.
Пример безопасного исключения для nginx, если у вас есть общий редирект или кеширующий слой:
location = /wp-login.php {
try_files $uri $uri/ /index.php?$args;
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
}
location ^~ /wp-admin/ {
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
}Это не универсальный шаблон для любой конфигурации, но логика здесь правильная: служебные страницы не должны попадать под агрессивный кеш.
5. Проверьте, не вмешивается ли плагин безопасности
Иногда 404 — это не настоящая ошибка, а маскировка доступа. Некоторые плагины безопасности специально отдают 404 вместо 403, чтобы скрыть наличие административной точки входа. Если вы недавно включали защиту, временно отключите её и повторите проверку.
Если после отключения плагина вход заработал, ищите в его настройках:
- скрытие
wp-login.php; - блокировку по стране или IP;
- ограничение по User-Agent;
- защиту от ботов, которая срабатывает на форму входа.
Сравнение подходов: что быстрее и что надежнее
| Подход | Когда подходит | Минус |
|---|---|---|
Очистка кеша и исключение wp-login.php | Если ошибка появилась после включения кеша или CDN | Не решает проблему, если сломаны редиректы |
Проверка WP_HOME и WP_SITEURL | Если меняли домен, SSL или переносили сайт | Требует аккуратности, особенно на живом сайте |
| Правка правил nginx/.htaccess | Если 404 идет от сервера | Нужно понимать текущую схему редиректов |
Проверка результата после внедрения
После каждого изменения проверяйте не только саму страницу входа, но и поведение после авторизации. Рабочий сценарий выглядит так:
/wp-login.phpоткрывается по HTTPS без 404.- Форма отправляется без ошибки.
- После входа открывается
/wp-admin/, а не главная с ошибкой. - В приватном окне браузера результат такой же, как в обычном.
Дополнительно проверьте заголовки ответа:
curl -I https://example.com/wp-login.php
curl -I https://example.com/wp-admin/Если видите 404 только в браузере, а через curl ответ нормальный, почти наверняка виноват локальный кеш, расширение браузера или сервис на уровне CDN.
Частые ошибки и как их исправить
Смешали несколько редиректов на HTTPS
Когда HTTPS включают одновременно в панели хостинга, в плагине и в .htaccess, правила начинают конфликтовать. Оставьте один источник истины. Если редирект уже настроен на уровне сервера, не дублируйте его в WordPress без необходимости.
Кешируют страницу входа как обычную
Это одна из самых частых причин. Страница входа должна быть исключена из page cache и CDN cache. Иначе один пользователь может получить ответ другого, а другой — старую форму или 404.
Меняют адрес сайта, но не чистят старые cookies
После переезда на HTTPS старые cookies иногда мешают корректному входу. Проверьте сайт в приватном окне и очистите cookies для домена. Если проблема исчезла, значит дело было не в WordPress, а в клиентском состоянии браузера.
Ставят защитный плагин и забывают про исключения
Если плагин безопасности скрывает страницу входа, он может вернуть 404 даже при правильном URL. Это нормально только если так и задумано. Для админов и техподдержки должны быть понятные исключения и документированный способ доступа.
Практические советы по безопасности и производительности
Не отключайте кеш для всего сайта из-за проблем с входом. Достаточно точечного исключения служебных URL. Это сохраняет производительность и не ломает авторизацию.
Если вы регулярно работаете с SEO и технической чисткой сайта, удобно держать под контролем дубли, лишние редиректы и служебные страницы через инструменты вроде Clearfy Pro: он помогает убирать часть технического шума, который часто мешает диагностике. Но даже с плагином ключевые проверки лучше делать вручную: через заголовки, логи и тестовый вход.
Для безопасной отладки полезно временно включить логирование ошибок WordPress в staging-окружении, а не на боевом сайте. Так вы увидите, не падает ли какой-то плагин на этапе инициализации входа.
Мини-чек-лист перед повторной проверкой
- очищен кеш плагина, сервера и CDN;
/wp-login.phpисключен из кеширования;- проверены
WP_HOMEиWP_SITEURL; - нет дублирующих HTTPS-редиректов;
- временно отключены плагины безопасности, если они могут маскировать вход;
- вход проверен в приватном окне и через
curl.
Если после этого /wp-login.php все еще отдает 404, смотрите серверные логи: там обычно быстрее видно, кто именно формирует ответ — WordPress, nginx, Apache, CDN или защитный модуль хостинга.