Коротко: 403 Forbidden в WordPress обычно вызвана неверными правами доступа к файлам, повреждённым .htaccess, конфликтующим плагином безопасности или блокировкой на уровне хостинга. Начните с проверки CHMOD для папок (755) и файлов (644) и временного переименования .htaccess, чтобы отсечь самые частые причины. Если ошибка сохраняется, последовательно отключайте плагины и обращайтесь в логи сервера.
Ошибка 403 WordPress — это блокировка доступа к странице или всему сайту, с которой сталкиваются многие администраторы. Сервер понимает запрос, но отказывается его выполнять из-за настроек безопасности или повреждённых файлов. В отличие от ошибки 500, проблема не на стороне кода, а в правах и разрешениях, и её почти всегда можно решить без привлечения разработчика.
Как понять, что это именно ошибка 403
Ошибка 403 Forbidden — это HTTP-статус, при котором сервер отклоняет запрос, хотя клиент авторизован или страница существует. В браузере вы увидите белый экран с надписью «403 Forbidden», «Access Denied» или кастомное сообщение от хостинга. В WordPress ошибка может возникать при входе в админку, при открытии отдельных страниц или сразу на всём сайте.
Важно отличать 403 от 401 (требуется авторизация) и от 404 (страница не найдена). При 403 доступ запрещён именно по соображениям безопасности — это ключевой симптом для поиска причины в настройках прав, файлах и плагинах.
Важно: Иногда хостинг-провайдер заменяет стандартную страницу 403 на свою, поэтому текст сообщения может не содержать номера. Но поведение одинаковое: страница не открывается из-за ограничений доступа.
Права доступа к файлам и папкам (CHMOD)
Неправильные разрешения на файлах и директориях — одна из самых частых причин ошибки 403 в WordPress. Сервер Apache или Nginx проверяет, имеет ли пользователь, от имени которого работает веб-сервер, доступ на чтение и выполнение. Для большинства хостингов корректные значения: папки — 755 (rwxr-xr-x), файлы — 644 (rw-r—r—), а файл wp-config.php иногда рекомендуют ставить 600 или 640 для безопасности.
Если права слишком строгие (например, 700 на папке), сервер не сможет прочитать index.php и выдаст 403. Реже встречается ситуация, когда владельцем файлов становится root вместо пользователя хостинга — тогда поможет обращение в поддержку для смены owner’а.
- Папки: 755
- Файлы: 644
- Файл wp-config.php: 600 или 640
- Подключитесь к серверу через FTP или файловый менеджер хостинга.
- Перейдите в корневую директорию WordPress (обычно public_html или www).
- Выберите все папки и установите права 755, для всех файлов — 644.
- Отдельно проверьте права у файлов .htaccess, wp-config.php и папки wp-content — они должны соответствовать рекомендациям.
- Обновите страницу сайта и проверьте, исчезла ли ошибка.
Важно: На некоторых серверах Nginx права доступа не играют такой роли, как в Apache, но неверный CHMOD всё равно может блокировать чтение статики или выполнение PHP.
Повреждённый или некорректный файл .htaccess
Файл .htaccess в корне WordPress управляет перезаписью URL, редиректами и некоторыми правилами безопасности. Ошибочные директивы, лишние пробелы или неподдерживаемые инструкции могут заставить Apache вернуть 403. Чаще всего проблема возникает после сброса постоянных ссылок, установки плагина безопасности или ручной правки файла.
Решение — пересоздать .htaccess стандартным содержимым WordPress. Для этого достаточно войти в админку (если доступна) и пересохранить настройки постоянных ссылок. Если админка тоже под 403, файл нужно временно переименовать, а затем сгенерировать заново.
- Через FTP или файловый менеджер найдите файл .htaccess в корневой папке сайта.
- Переименуйте его, например в .htaccess_old, чтобы отключить все правила.
- Попробуйте открыть сайт. Если ошибка ушла — дело в содержимом .htaccess.
- Зайдите в админку WordPress, перейдите в «Настройки» → «Постоянные ссылки» и нажмите «Сохранить изменения» без внесения правок. WordPress создаст новый .htaccess с базовыми правилами.
- Если админка недоступна, создайте вручную пустой файл .htaccess и вставьте стандартный код WordPress:
- Перенесите обратно нужные вам кастомные правила из старого файла по одному, проверяя сайт после каждого добавления.
Важно: Если сайт работает на сервере Nginx, файл .htaccess не используется. Там маршрутизация задаётся в конфигурации сервера — при ошибке 403 стоит обратиться в поддержку хостинга.
Конфликтующие плагины и темы
Некоторые плагины безопасности (Wordfence, iThemes Security, All In One WP Security) или кеширования могут слишком агрессивно блокировать доступ. После установки такого плагина или изменения его настроек легко получить 403 на части страниц или на всей админке. Также темы с собственной системой прав доступа или функцией скрытия wp-admin иногда вызывают подобную ошибку.
- Плагины безопасности с функцией файрвола
- Плагины для скрытия админки
- Дочерние темы с кастомной логикой авторизации
- Через FTP переименуйте папку /wp-content/plugins/, добавив суффикс (например, plugins_disabled) — это отключит все плагины разом.
- Проверьте сайт. Если ошибка исчезла, один из плагинов является причиной.
- Переименуйте папку обратно, затем заходите через админку и отключайте плагины по одному, после каждого проверяя, возвращается ли ошибка.
- Аналогично можно временно переключиться на стандартную тему (Twenty Twenty-Three и т.п.), переименовав папку активной темы в /wp-content/themes/.
- Найдя виновный плагин или тему, обновите его до последней версии или замените альтернативой.
Важно: После массового отключения плагинов через FTP сайт может выглядеть сломанным — это нормально. Главное — понять, виноват ли плагин. Затем верните всё как было и отключайте точечно.
Блокировки на уровне хостинга и серверные ограничения
Иногда ошибка 403 возникает из-за правил безопасности хостинг-провайдера: модуль Apache mod_security, лимиты на выполнение скриптов, блокировка IP-адреса или страны. Mod_security — это файрвол приложений, который может посчитать безобидный запрос WordPress за атаку и заблокировать доступ. Также если вы превысили допустимую нагрузку на ресурсы, хостинг может временно закрыть доступ к аккаунту.
Для диагностики полезно зайти в панель управления хостингом и проверить наличие жалоб в логах безопасности, ошибок в разделе «Статистика» или «Ошибки». Поддержка хостинга обычно видит точную причину блокировки.
- Активированный mod_security или аналогичный WAF
- Блокировка IP из-за многократных неудачных входов
- Исчерпание ресурсов тарифного плана (CPU, память)
- Войдите в панель управления хостингом и найдите раздел с логами ошибок или журналом безопасности.
- Ищите записи со словом «blocked» или «forbidden» в день возникновения проблемы.
- Если видите упоминание mod_security, попробуйте временно отключить его (если провайдер разрешает) или попросить поддержку добавить ваше правило в исключения.
- Проверьте, не заблокирован ли ваш IP. При необходимости разблокируйте или добавьте в белый список.
- При превышении лимитов — дождитесь автоматического снятия ограничений или обновите тариф.
Важно: На shared-хостинге у вас может не быть права на изменение mod_security. В таком случае обязательно свяжитесь с техподдержкой — опишите, что вы можете получить 403 при выполнении обычных действий в WordPress, и попросите проверить логи серверного WAF.
Проблемы с индексным файлом и целостностью ядра
Отсутствие файла index.php в корневой папке или в директории темы приводит к 403, если сервер запрещает просмотр списка файлов. WordPress не может запуститься без index.php. Также ошибку могут спровоцировать повреждённые или злонамеренно изменённые файлы ядра — например, после взлома сайта или некорректного обновления.
- Отсутствует index.php в корне или в папке активной темы
- Повреждены системные файлы WordPress
- Вирус модифицировал wp-admin/index.php
- Проверьте через FTP наличие файла index.php в корне сайта и в папке /wp-content/themes/ваша_тема/. Если его нет — загрузите из свежей дистрибутивной версии WordPress.
- Сравните хеш-суммы или просто перезапишите файлы папок wp-admin и wp-includes оригинальными из официального архива wordpress.org той же версии (версия указана в файле wp-includes/version.php).
- После восстановления сбросьте кеш, если используете плагин кеширования.
Важно: При перезаписи ядра вы не теряете контент и настройки, но лучше предварительно сделать резервную копию.
Проверка результата
- Попробуйте открыть сайт с другого устройства или через мобильную сеть (смена IP) — если ошибка исчезла, вероятна блокировка вашего IP.
- Проверьте, воспроизводится ли ошибка на разных страницах или только на конкретной (например, только wp-admin). Это сузит круг поиска до плагинов безопасности или прав доступа к определённой директории.
- Загляните в корневую папку через FTP и убедитесь, что там есть файлы index.php и .htaccess.
- Временно переименуйте папку плагинов. Если ошибка уходит — причина точно в плагинах.
- Включите журнал ошибок WordPress (define('WP_DEBUG', true); в wp-config.php) или посмотрите логи ошибок PHP в панели хостинга — там могут быть подсказки.
Частые ошибки и нюансы
- Сразу начинать править файл .htaccess вручную, не попробовав просто пересохранить постоянные ссылки из админки.
- Использовать рекурсивную установку прав 777 на всю папку сайта в попытке быстро снять блокировку — это опасно и не устраняет первопричину.
- Забывать про кеш браузера и кеш плагинов — после исправлений стоит принудительно обновить страницу (Ctrl+F5) или сбросить кеш WordPress.
- Игнорировать логи сервера и ориентироваться только на поведение сайта — в логах часто прямо указано правило WAF или строка .htaccess, вызвавшая 403.
Проверить ошибку WordPress
Введите ошибку WordPress, PHP, плагина, темы, REST API или кратко опишите проблему сайта.
FAQ
Может ли ошибка 403 возникать из-за неправильных постоянных ссылок?
Да, если после изменения структуры ссылок файл .htaccess не обновился или оказался повреждён. В этом случае пересохранение постоянных ссылок из меню «Настройки» → «Постоянные ссылки» часто решает проблему.
Почему ошибка 403 появляется только в админке, а сайт работает?
Скорее всего, срабатывает плагин безопасности, ограничивающий доступ к wp-admin по IP, или в .htaccess добавлены правила для защиты админки. Также причиной может быть ограничение на уровне хостинга после частых попыток входа.
Как быстро проверить, виноват ли плагин?
Через FTP переименуйте папку /wp-content/plugins/. Если после этого сайт открывается без ошибки, проблема в одном из плагинов. Затем возвращайте название папки и отключайте их по очереди через админку для точного определения.
Что делать, если я не могу войти в админку, чтобы пересохранить постоянные ссылки?
Можно создать новый файл .htaccess вручную, скопировав в него стандартный код WordPress. Также можно на время переименовать старый .htaccess, чтобы обойти ограничение и зайти в админку.
Поможет ли смена темы?
Если активная тема содержит функции, ограничивающие доступ (например, скрытие admin bar или кастомные проверки прав), переключение на стандартную тему через FTP (переименованием папки темы) может убрать ошибку.
Может ли 403 возникать из-за кеширования на сервере?
Иногда да, особенно если вы используете серверный кеш вроде Varnish или Nginx FastCGI Cache, и кешированная страница отдаётся с неверными заголовками безопасности. Попробуйте сбросить серверный кеш в панели хостинга.
Итог
Ошибка 403 в WordPress — защитная реакция сервера, а не фатальный сбой. Методично исключая одну причину за другой, начиная с прав доступа и плагинов, вы с высокой вероятностью найдёте источник проблемы за считанные минуты. Ведите диагностику без паники и всегда держите под рукой резервную копию — так вы сможете быстро восстановить сайт даже при ошибке, возникшей после экспериментов с настройками.