Как исправить 404 в админке и на странице входа WordPress после смены Site URL

Автор: Юлия Лебедева | Опубликовано: 27.08.2026

Если после переноса сайта, смены домена или правки адресов в настройках WordPress админка и страница входа начинают отдавать 404, проблема обычно не в самом wp-login.php. Чаще ломается связка из home, siteurl, правил веб-сервера, кеша или некорректной правки wp-config.php.

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

Что именно ломается и как это выглядит

Типичный сценарий: главная страница открывается, но /wp-admin/ или /wp-login.php дают 404, либо ведут на старый домен. Иногда ошибка появляется только после включения SSL, переноса на другой хостинг или установки плагина кеширования.

Важно различать несколько вариантов:

404 от веб-сервера — файл или правило маршрутизации не найдено;
редирект на старый домен — в базе остались старые значения home и siteurl;
страница открывается, но стили и скрипты не грузятся — смешанный контент или неверный URL в теме/плагинах;
админка доступна только через прямой путь, но не через обычный вход — конфликт правил перезаписи или кеша.

Диагностика: с чего начать

Сначала проверьте, что именно возвращает сервер. Если есть доступ к консоли, выполните запросы к проблемным адресам и посмотрите заголовки ответа:

curl -I https://example.com/wp-login.php
curl -I https://example.com/wp-admin/

Если в ответе сразу 404 Not Found, это чаще проблема маршрутизации, а не авторизации. Если идет редирект на другой адрес, ищите старые URL в настройках WordPress или в конфиге.

Полезно проверить текущие значения в базе данных:

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

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

Что проверить в первую очередь

адреса home и siteurl в базе;
нет ли жестко заданных WP_HOME и WP_SITEURL в wp-config.php;
существует ли файл wp-login.php в корне WordPress;
работают ли правила .htaccess или конфигурация Nginx;
не отдает ли кеш старую версию страницы;
не включен ли плагин, который меняет поведение входа или админки.

Пошаговое решение

1. Исправьте адреса сайта в базе

Если домен менялся, сначала приведите home и siteurl к актуальному адресу. Это можно сделать через SQL:

UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name IN ('home', 'siteurl');

После этого очистите кеш браузера и попробуйте открыть /wp-admin/ заново. Если сайт работает на HTTPS, указывайте именно HTTPS, а не старый HTTP-адрес.

2. Проверьте `wp-config.php`

Если в конфиге прописаны константы WP_HOME и WP_SITEURL, они перекрывают значения из базы. Это удобно для миграций, но часто становится причиной 404 после переезда, когда константы забывают обновить.

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

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

3. Сбросьте правила перезаписи

Для сайтов на Apache проверьте, что в корне есть рабочий .htaccess с типовыми правилами WordPress. После переноса файл иногда пустой, поврежденный или не читается из-за прав доступа.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

На Nginx аналогичная проблема решается не .htaccess, а конфигурацией location. Если /wp-admin/ и /wp-login.php отдают 404 только на Nginx, проверьте, что запросы на PHP действительно передаются в обработчик php-fpm.

4. Очистите кеш на всех уровнях

После смены URL старый кеш может продолжать отдавать несуществующие пути. Очистите:

плагин кеширования;
серверный кеш, если он есть;
CDN;
кеш браузера;
object cache, если используется Redis или Memcached.

Если у вас включен плагин оптимизации вроде Clearfy Pro, проверьте, не включена ли там агрессивная очистка дублей и редиректов, которая может мешать диагностике. На время проверки лучше оставить только базовую конфигурацию и убрать лишние правила.

5. Проверьте плагины, которые вмешиваются во вход

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

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

Когда нужен код, а не ручная правка

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

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

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

Если нужно быстро проверить, не подменяет ли что-то адреса в рантайме, можно вывести значения в отдельный mu-plugin или временный сниппет:

<?php
add_action('admin_notices', function () {
    if (!current_user_can('manage_options')) {
        return;
    }

    echo '<div class="notice notice-info"><p>home: ' . esc_html(home_url()) . '<br>siteurl: ' . esc_html(site_url()) . '</p></div>';
});

Это не исправление, а способ быстро увидеть, какие адреса WordPress считает актуальными.

Проверка результата после внедрения

После правок не ограничивайтесь открытием главной страницы. Проверьте именно те точки, которые ломались:

/wp-login.php открывается без 404;
/wp-admin/ редиректит на форму входа или открывается после авторизации;
адрес в строке браузера совпадает с новым доменом;
в консоли браузера нет массовых 404 на CSS и JS;
в curl -I нет старых редиректов на прежний домен.

Если используется HTTPS, отдельно проверьте, что сертификат валиден и нет цепочки редиректов вида HTTP → старый домен → новый домен → /wp-login.php. Такие цепочки часто ломают авторизацию и создают ложное ощущение, что проблема в WordPress.

Частые ошибки и как их исправить

Оставили старый домен в базе

Самая частая причина — home и siteurl обновили не везде. Иногда меняют только один параметр, а второй остается старым. В итоге админка ведет на другой адрес или отдает 404.

Задали неверный протокол

Если сайт работает по HTTPS, а в настройках остался HTTP, браузер может уходить в редиректы или блокировать часть ресурсов. Исправляйте адрес сразу с правильным протоколом.

Сломали правила перезаписи

После миграции часто забывают восстановить .htaccess или правила Nginx. Тогда WordPress физически существует, но сервер не знает, как обработать запросы к внутренним маршрутам.

Кеш продолжает отдавать старую страницу

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

Плагин безопасности скрывает старый путь входа

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

Практические советы по безопасности и производительности

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

Для производительных сайтов полезно отдельно проверить:

нет ли лишних редиректов между HTTP и HTTPS;
не кешируется ли страница входа на уровне CDN;
не создают ли плагины безопасности конфликт с серверными правилами;
не дублируются ли адреса сайта в базе и в wp-config.php без необходимости.

Если вам нужно регулярно чистить дубли, следить за техническими настройками и не держать сайт в захламленном состоянии, такие задачи удобно закрывать инструментами класса Clearfy Pro: он не чинит 404 сам по себе, но помогает убрать часть мусорных настроек и конфликтов, из-за которых подобные проблемы всплывают после миграций. Смотрите описание здесь: https://wpshop.ru/plugins/clearfy.

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