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

Автор: Артем Захаров | Опубликовано: 20.08.2026

Если после смены домена, перехода на HTTPS или правки siteurl и home админка WordPress начинает отдавать 404, проблема обычно не в самой странице входа. Чаще ломается связка из URL сайта, редиректов, кеша и правил веб-сервера. В такой ситуации важно не «перебирать плагины», а быстро понять, на каком уровне происходит сбой: WordPress, база данных, .htaccess/nginx или внешний кеш.

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

Сценарий обычно один из трех:

/wp-admin/ открывается как 404 после смены домена;
/wp-login.php редиректит на старый адрес или на главную;
страница входа открывается, но после авторизации снова уводит в 404 или на неправильный хост.

Если сайт работает на фронтенде, а админка нет, это сильный сигнал, что проблема в URL-логике или кешировании, а не в «поломке WordPress целиком».

Диагностика проблемы: где искать причину

Проверьте значения home и siteurl

Начните с базы данных. Для админки критичны две опции: home и siteurl. Они должны указывать на актуальный домен и протокол.

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

Если там остался старый домен, WordPress может строить ссылки на несуществующий адрес и уводить в 404. Важно проверять именно актуальную схему: https://example.com и https://www.example.com — это разные адреса.

Посмотрите, не мешает ли кеш

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

плагин кеширования;
object cache, если он используется;
CDN-правила на уровне прокси;
правила редиректа HTTP→HTTPS и non-www→www, если они задвоены.

Если у вас включен Cloudflare или другой прокси, проверьте, не кэшируется ли ответ на /wp-admin/ по ошибке. Админка и страница входа не должны обслуживаться как обычный публичный HTML.

Проверьте правила веб-сервера

На Apache часто проблема в некорректном .htaccess. На Nginx — в неправильном try_files или конфликте location-блоков. Если после переноса сайта менялся конфиг, убедитесь, что запросы к WordPress действительно попадают в index.php, а не отдаются как 404 на уровне сервера.

Для Apache базовый блок 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>

Для Nginx обычно нужен рабочий шаблон вида:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Пошаговое решение без лишних рисков

1. Зафиксируйте правильный адрес сайта

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

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

После этого WordPress будет использовать эти значения вместо записей в базе. Это не финальное решение, но хороший способ быстро вернуть доступ и проверить, что проблема действительно в URL.

2. Обновите адреса в базе данных

Когда доступ восстановлен, перенесите корректные значения в базу и уберите временные константы из wp-config.php, если они больше не нужны. Иначе позже можно получить путаницу: в админке одно значение, в базе другое, а в плагинах — третье.

Если менялся не только домен, но и протокол, проверьте сериализованные данные в опциях и контенте. Для этого безопаснее использовать WP-CLI или проверенный search-replace, а не ручной SQL по всему сайту.

Пример с WP-CLI:

wp search-replace 'http://old-domain.ru' 'https://example.com' --all-tables --precise --skip-columns=guid

Команда полезна после миграции, но запускать ее нужно только с актуальными значениями и резервной копией. --skip-columns=guid обычно оставляют, чтобы не переписывать идентификаторы записей без необходимости.

3. Сбросьте правила постоянных ссылок

Иногда 404 в админке маскирует более общую проблему с rewrite rules. После исправления URL зайдите в Настройки → Постоянные ссылки и просто сохраните их без изменений. Это пересоберет правила маршрутизации.

Если доступа в админку нет, можно временно удалить старый .htaccess и создать новый по стандартному шаблону WordPress. На Nginx пересборка делается через конфиг, а не через интерфейс CMS.

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

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

кеш плагина;
серверный кеш;
CDN-кеш;
браузерный кеш;
cookies для домена.

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

Когда помогает только код

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

add_action('init', function () {
    if (defined('WP_CLI') && WP_CLI) {
        return;
    }

    if (isset($_SERVER['HTTP_HOST']) && $_SERVER['HTTP_HOST'] !== 'example.com') {
        wp_redirect('https://example.com' . $_SERVER['REQUEST_URI'], 301);
        exit;
    }
}, 1);

Такой код уместен только как временная мера на этапе диагностики. Если оставить его надолго, можно получить циклические редиректы или проблемы с поддоменами и staging-средами.

Сравнение подходов: что выбрать в реальной ситуации

Подход	Когда использовать	Минус
WP_HOME / WP_SITEURL в `wp-config.php`	Нужно срочно вернуть доступ к админке	Это временный обход, а не финальная настройка
Правка значений в базе	После миграции домена или HTTPS	Нужна аккуратность с сериализованными данными
Сброс rewrite rules	После смены структуры ссылок или конфигов сервера	Не решает ошибочный домен в опциях

Как проверить, что решение сработало

Проверка должна быть не только визуальной. После исправления откройте и проверьте:

/wp-admin/ — должен открываться без 404;
/wp-login.php — должен вести на правильный домен и протокол;
после входа вы должны попасть в консоль, а не на старый адрес;
в исходном коде и ссылках админки не должно быть старого домена;
в таблице wp_options значения home и siteurl совпадают с фактическим адресом сайта.

Дополнительно проверьте заголовки ответа через DevTools или curl -I. Если сервер продолжает отдавать 301/302 на старый адрес, значит проблема еще не закрыта на уровне редиректов или прокси.

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

Старый домен остался в одной из опций

Часто меняют только home, а siteurl забывают. Для WordPress это разные значения, и несоответствие легко ломает админку.

Смешаны HTTP и HTTPS

Если сайт уже работает по HTTPS, но WordPress думает, что адрес HTTP, возможны редиректы туда-сюда и 404 после входа. Проверьте и CMS, и правила веб-сервера, и прокси.

Кеширует не тот слой

Иногда очищают плагин кеша, но забывают про CDN или reverse proxy. В результате старый ответ продолжает отдаваться пользователю, хотя на сервере все уже исправлено.

Неправильный конфиг Nginx или .htaccess

Если после смены домена 404 есть только на внутренних URL, а главная страница открывается, проблема может быть в rewrite rules. В этом случае правка URL в базе не поможет, пока сервер не начнет передавать запросы в WordPress корректно.

Что сделать после восстановления доступа

Когда админка снова открывается, не ограничивайтесь одной правкой URL. Проверьте:

постоянные ссылки и структуру URL;
редиректы с www/non-www и HTTP/HTTPS;
настройки кеша для админки и страницы входа;
актуальность siteurl после миграции;
нет ли в плагинах жестко прописанного старого домена.

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