Ограничить доступ к wp-admin можно на двух уровнях: сервер будет пускать в админку только с заданных IP-адресов или WordPress будет показывать панель только выбранным пользователям. Первый способ надёжнее, если у вас постоянный IP и доступна настройка веб-сервера. Второй удобен, когда IP меняется, но он не заменяет проверку прав пользователей WordPress.
Перед изменениями убедитесь, что у вас есть доступ к панели хостинга или файлам сайта. Ошибка в серверном правиле может закрыть вход в админку; при ограничении по логину опечатка в имени пользователя может лишить доступа всех администраторов.
Ограничение по IP в Apache
Если сайт работает на Apache или совместимом с его правилами веб-сервере, можно разрешить доступ к каталогу wp-admin только с определённых адресов. Пример ниже предназначен для Apache 2.4. Создайте файл .htaccess в каталоге wp-admin либо аккуратно добавьте правила в уже существующий файл, не удаляя его содержимое:
<RequireAny>
Require ip 198.51.100.24
Require ip 2001:db8:1234::/48
</RequireAny>
<Files admin-ajax.php>
Require all granted
</Files>Замените примеры адресов на свой публичный IP или нужную сеть. Адреса в примере зарезервированы для документации и не дадут доступ к вашему сайту. Несколько директив Require ip внутри RequireAny означают, что подойдёт любой из перечисленных адресов. IPv6-сеть можно указать в формате CIDR, как в примере.
Исключение для admin-ajax.php оставляет доступными AJAX-запросы, которые могут использоваться публичными страницами сайта. Без него такие запросы с адресов посетителей тоже будут блокироваться. При этом остальные файлы в wp-admin, в том числе обработчики административных действий, останутся доступны только с разрешённых IP.
Этот вариант работает только там, где сервер поддерживает директивы Apache в .htaccess. Nginx такие файлы не читает; для него правило доступа настраивают в конфигурации виртуального хоста, а на управляемом хостинге — через панель или поддержку. Не вставляйте Apache-синтаксис в конфигурацию Nginx: это не сработает и может нарушить запуск сайта.
Что учесть перед IP-ограничением
Проверьте, что разрешённый адрес не меняется после переподключения роутера или перезагрузки модема. Если провайдер выдаёт динамический IP, правило может внезапно закрыть доступ вам самим. В этом случае можно разрешить адресный диапазон, если он известен и достаточно узок, либо выбрать ограничение по логину.
Если сайт работает за CDN, прокси или балансировщиком, сервер может видеть адрес прокси, а не ваш реальный IP. Тогда обычное правило для клиентского адреса не совпадёт с тем, что получает Apache. Не подменяйте IP вручную заголовком X-Forwarded-For: ему можно доверять только при корректно настроенной цепочке прокси. Уточните у хостинга, какой адрес сервер использует для правил доступа.
Ограничение каталога wp-admin само по себе не закрывает страницу входа wp-login.php: она находится в корне WordPress. Пользователь с другого IP может увидеть форму входа, но после авторизации не сможет открыть защищённые страницы админки. Если нужно ограничить и саму страницу входа, это отдельное серверное правило. Настраивайте его только после проверки основного доступа и с возможностью быстро вернуть исходные настройки.
Ограничение по логину через MU-плагин
Если IP непостоянный, можно разрешить работу в панели конкретным аккаунтам WordPress. Для этого подойдёт небольшой MU-плагин: такие плагины загружаются автоматически и не требуют активации в админке. Создайте каталог wp-content/mu-plugins, если его ещё нет, и добавьте туда файл, например limit-admin-by-login.php.
<?php
/**
* Plugin Name: Limit admin access by login
*/
add_action('admin_init', function () {
if (wp_doing_ajax()) {
return;
}
$allowed_logins = array('siteadmin');
$user = wp_get_current_user();
if (
! $user->exists()
|| ! in_array($user->user_login, $allowed_logins, true)
) {
wp_safe_redirect(home_url('/'));
exit;
}
});Замените siteadmin на точное значение поля «Логин» в профиле нужного пользователя. Чтобы разрешить нескольким людям доступ, перечислите их логины в массиве, например array('siteadmin', 'editor-login'). Проверьте написание: сравнение учитывает регистр.
Для пользователей, которых нет в списке, страницы админки будут перенаправляться на главную. Запросы к admin-ajax.php исключены, чтобы не ломать AJAX-функции сайта. Это ограничивает доступ к интерфейсу панели, но не заменяет штатную систему ролей и прав WordPress: выдавайте каждому аккаунту только те возможности, которые ему действительно нужны. Логин также не является секретом и сам по себе не защищает аккаунт от подбора пароля.
Если после установки доступ пропал, удалите файл MU-плагина через файловый менеджер или SFTP — это вернёт прежнее поведение. Не проверяйте такой код сразу на единственной доступной учётной записи без запасного способа восстановить файлы.
Как проверить настройку и выбрать подходящий способ
После настройки откройте сайт в приватном окне и проверьте вход с разрешённого и запрещённого адреса или аккаунта. Для IP-правила также убедитесь, что страницы сайта, использующие AJAX, работают как раньше. Если сервер отвечает ошибкой 500 после изменения .htaccess, восстановите предыдущую версию файла: вероятная причина — неподдерживаемая директива или ошибка синтаксиса.
Выбирайте IP-ограничение, когда админкой пользуются с постоянных адресов и вы контролируете серверную конфигурацию. Ограничение по логину подходит для меняющихся сетей и нескольких аккаунтов, но действует на уровне WordPress. В обоих случаях сохраните резервную копию изменяемого файла и оставьте себе проверенный путь восстановления доступа.
