Ошибка 403 Forbidden в WordPress: причины и способы исправления

Ошибка 403 Forbidden в WordPress означает, что сервер получил запрос, но отказался предоставить доступ к запрошенному ресурсу. При этом сам сайт может продолжать работать частично: например, главная страница открывается, но /wp-admin/ возвращает 403, либо ошибка появляется только при загрузке изображения, установке плагина или отправке формы.

На практике 403 Forbidden — это не одна конкретная проблема, а результат отказа на одном из уровней сайта: WordPress, веб-сервера, файловой системы, WAF/CDN, плагина безопасности или хостинга.

Хорошая новость заключается в том, что в большинстве случаев причину можно найти без переустановки WordPress.

Краткий ответ: если WordPress показывает 403 Forbidden, сначала проверьте, возникает ли ошибка у всех посетителей или только у вас. Затем проверьте .htaccess , права файлов и каталогов, плагины безопасности, блокировки IP, CDN/WAF и серверные логи. Если ошибка появилась после изменения сайта — первым делом верните последнее изменение или восстановите резервную копию.

Что означает ошибка 403 Forbidden

Код HTTP 403 Forbidden относится к классу ошибок 4xx. Сервер доступен и понимает запрос, но по каким-либо правилам не разрешает получить запрошенный ресурс.

Пользователь может увидеть сообщения:

• 403 Forbidden
• HTTP Error 403 – Forbidden
• Forbidden
• Access Denied
• You don't have permission to access this resource
• 403 Forbidden: Access Denied
• Forbidden by Rule
• Error 403
• 403 Forbidden – IP Address Blocked

Точная формулировка зависит от веб-сервера, хостинга, CDN или системы безопасности.

Например, Nginx может сам вернуть 403 из-за настроек allow/deny, а отдельный модуль авторизации способен вернуть 403, если проверка доступа не прошла. (nginx.org)

Важно: 403 — не обязательно ошибка WordPress

Это один из главных моментов при диагностике.

Если сервер заблокировал запрос до запуска WordPress, изменение темы,

functions.php

или настроек WordPress ничего не даст.

Условно цепочка выглядит так:

Посетитель → DNS → CDN/WAF → веб-сервер → PHP → WordPress → плагин/тема

403 может появиться практически на любом из этих этапов.

Почему возникает 403 Forbidden в WordPress

Наиболее распространенные причины:

1. неправильные права доступа к файлам и каталогам;
2. поврежденный или неправильно настроенный .htaccess;
3. правило deny в конфигурации Apache или Nginx;
4. плагин безопасности заблокировал IP;
5. Web Application Firewall (WAF) считает запрос подозрительным;
6. CDN блокирует запрос;
7. IP-адрес попал в blacklist;
8. установленное обновление изменило конфигурацию;
9. конфликт плагина или темы;
10. неправильный владелец файлов;
11. отсутствует или недоступен index.php;
12. серверная конфигурация запрещает доступ к каталогу;
13. сработала Hotlink Protection;
14. сайт заражен вредоносным кодом;
15. проблема возникла после миграции сайта;
16. хостинг изменил настройки безопасности.

Поэтому пытаться сразу менять права на все файлы или удалять .htaccess — не лучшая стратегия.

Гораздо эффективнее сначала определить где именно возникает блокировка.

Как быстро определить источник ошибки 403

Перед исправлением выполните небольшой тест.

Откройте:

https://example.com/

затем:

https://example.com/wp-login.php

и:

https://example.com/wp-admin/

После этого проверьте конкретный проблемный URL.Например:

https://example.com/wp-content/uploads/2026/08/image.jpg

Возможные результаты

Это значительно сокращает область поиска.

1. Сначала очистите кэш

Это самое простое действие, которое стоит выполнить до серьезного вмешательства в сайт.

Очистите:

• кэш браузера;
• cookies сайта;
• WordPress-кэш;
• кэш серверного уровня;
• CDN-кэш;
• кэш плагина оптимизации.

После этого откройте сайт в режиме инкогнито.

Еще лучше — попробуйте открыть проблемную страницу с другого интернет-соединения.

Например:

• Wi-Fi;
• мобильный интернет;
• VPN.

Почему это важно?

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

2. Проверьте, возникает ли ошибка только с вашего IP

Некоторые системы безопасности автоматически блокируют IP после серии неудачных входов, подозрительных запросов или слишком большого количества обращений.

Это могут делать:

• Wordfence;
• другие security plugins;
• ModSecurity;
• серверный firewall;
• CDN/WAF;
• хостинг.

Nginx, например, позволяет задавать правила allow и deny, ограничивая доступ определенным IP-адресам или сетям. (nginx.org)

Быстрый тест

Попробуйте:

1. открыть сайт с мобильного интернета;
2. открыть сайт в VPN;
3. попросить другого пользователя открыть тот же URL.

Если у другого пользователя сайт работает, а у вас появляется 403, ищите блокировку IP.

3. Проверьте файл .htaccess

Для сайтов на Apache файл .htaccess — один из наиболее важных элементов конфигурации.

WordPress использует его, в частности, для работы красивых постоянных ссылок. Поврежденный или измененный плагином .htaccess способен привести к 403. (WordPress Developer Resources)

Файл обычно находится в корневом каталоге WordPress:

public_html/.htaccess

или:

www/.htaccess

Перед изменением обязательно сделайте копию

Например:

.htaccess

переименуйте в:

.htaccess-backup

Важный момент

Не удаляйте

.htaccess

без резервной копии.

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

Как восстановить стандартный htaccess для WordPress

Для обычной установки WordPress базовый вариант выглядит примерно так:

# BEGIN WordPress
Module 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

После восстановления правил проверьте сайт.

Если доступ к админке есть, WordPress также может заново сформировать правила через:

Настройки → Постоянные ссылки → Сохранить изменения

WordPress официально описывает htaccess как конфигурационный файл Apache, который используется для управления правилами на уровне каталогов. (WordPress Developer Resources)

4. Проверьте права доступа к файлам и папкам

Это одна из самых распространенных причин 403.

Для типичной установки WordPress часто используются:

Папки: 755
Файлы: 644

Официальная документация WordPress показывает именно такой распространенный вариант для каталогов и файлов. (WordPress Developer Resources)

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

Типичная структура

public_html/     755
wp-admin/             755
wp-content/           755
wp-includes/          755
index.php             644
wp-config.php         640/644*
.htaccess             644/640*

* Точные права зависят от конфигурации сервера.

Как исправить права через SSH

Если у вас есть SSH-доступ, для стандартной установки можно проверить каталоги:

find /path/to/wordpress/ -type d -exec chmod 755 {} \;

и файлы:

find /path/to/wordpress/ -type f -exec chmod 644 {} \;

Такие команды приведены и в документации WordPress по hardening. (WordPress Developer Resources)

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

5. Проверьте владельца файлов

Иногда права выглядят правильно, но сервер все равно получает Permission denied.

Причина может быть в неправильном owner/group.

Это особенно часто встречается после:

• миграции сайта;
• восстановления backup;
• ручной загрузки файлов через SSH;
• распаковки архива от имени root;
• переноса WordPress между серверами.

Например, файлы могут принадлежать: root:root вместо пользователя, от имени которого работает сайт.

В результате PHP или веб-сервер не может получить к ним необходимый доступ.

Что делать?

Если проблема появилась после миграции или восстановления сайта, попросите хостинг проверить:

• владельца файлов;
• группу;
• права;
• пользователя PHP-FPM;
• пользователя веб-сервера.

6. Временно отключите плагины

Если 403 появился после:

• установки плагина;
• обновления плагина;
• изменения настроек безопасности;
• обновления WordPress,

проверьте плагины.

Если WordPress Dashboard недоступен, переименуйте:

wp-content/plugins

например в:

wp-content/plugins-disabled

WordPress перестанет загружать плагины.

Что покажет результат?

Если после этого 403 исчез:

проблема почти наверняка связана с одним из плагинов.

Верните каталогу первоначальное имя: plugins затем включайте плагины по одному.

Так можно найти виновника.

7. Особое внимание уделите security-плагинам

Security plugins имеют расширенные возможности блокировки.

Они могут реагировать на:

• слишком большое количество запросов;
• подозрительный User-Agent;
• определенные параметры URL;
• POST-запросы;
• XML-RPC;
• REST API;
• попытки входа;
• IP-адрес;
• географию;
• подозрительные SQL-подобные строки.

Поэтому если:

Главная → работает
wp-admin → 403

а особенно если проблема появилась после изменения настроек безопасности, проверяйте security plugin одним из первых.

На WordPress.org также рекомендуют при подобных ситуациях проверить security plugins и серверный WAF. (WordPress.org)

8. Проверьте ModSecurity и WAF

Это особенно важно, если:

• WordPress работает на Apache;
• используется cPanel;
• сайт находится на shared hosting;
• 403 появляется при отправке формы;
• ошибка возникает только при определенных запросах.

ModSecurity может заблокировать запрос, если он соответствует правилу Web Application Firewall.

В таком случае WordPress может вообще не узнать о запросе.

То есть схема будет выглядеть так:

Браузер
   ↓
ModSecurity / WAF
   ↓
403
   ↓
WordPress не запускается

Поэтому бессмысленно менять

functions.php, если запрос блокируется еще до PHP.

Что написать хостингу?

Можно отправить:

На сайте возникает HTTP 403 Forbidden при обращении к URL /...

Проверьте, пожалуйста, серверные error logs и WAF/ModSecurity rules. Не блокируется ли данный запрос или мой IP на уровне сервера?

Это значительно эффективнее сообщения «сайт выдает 403, помогите».

9. Проверьте конфигурацию Nginx

Если сайт работает на Nginx, htaccessздесь вообще не является главным источником правил — Nginx использует собственную конфигурацию.

Например, правило:

deny all;

может полностью запретить доступ к определенному ресурсу.

Также 403 может быть результатом:

allow ... deny ...

или других правил внутри

server/location

Nginx официально поддерживает ограничения доступа на основе IP через директивы allow и deny. (nginx.org)

В некоторых конфигурациях Nginx также может возвращать 403 непосредственно через правило:

return 403;

Поэтому для Nginx проверяйте:

• nginx.config

• конфигурацию конкретного сайта;

• server;

• location;

• allow;

• deny;

• return 403;

• настройки авторизации;
• WAF.

10. Проверьте CDN и Cloudflare

Если сайт использует CDN, запрос может вообще не доходить до вашего сервера.

Например:

Посетитель
     ↓
Cloudflare
     ↓
WAF
     ↓
Origin Server
     ↓
WordPress

Если Cloudflare заблокировал запрос, исправление htaccess ничего не даст.

Быстрый тест

Временно отключите проксирование CDN или проверьте сайт непосредственно через origin.

Если без CDN ошибка исчезает — ищите проблему в:

• WAF;
• Firewall Rules;
• Rate Limiting;
• Bot Fight Mode;
• IP Access Rules;
• security rules.

11. Проверьте Hotlink Protection

Если 403 появляется только при загрузке изображений, проблема может быть связана с Hotlink Protection.

Например:

https://example.com/wp-content/uploads/photo.jpg

не открывается напрямую, но изображения на самом сайте показываются или наоборот.

Hotlink Protection может запрещать загрузку файлов, если запрос приходит с определенного Referer.

Проверяйте:

• настройки CDN;
• настройки хостинга;

• htaccess;

• правила Nginx;
• плагины защиты.

12. Проверьте наличие index.php

Если ошибка появляется при открытии каталога, например:

https://example.com/test/ сервер может быть настроен так, чтобы запрещать просмотр содержимого каталога.

Если в каталоге нет разрешенного index-файла, сервер может вернуть 403 вместо списка файлов.

Для WordPress в корне обычно присутствует:

index.php

Проверьте, что файл:

• существует;
• не пустой;
• доступен серверу;
• имеет правильного владельца;
• не содержит вредоносных изменений.

13. Проверьте серверные логи — это самый полезный шаг

Если предыдущие методы не помогли, перестаньте гадать.

Посмотрите error log.

Именно он часто дает ответ, почему сервер вернул 403.

Ищите записи вроде:

Permission denied
client denied by server configuration
access forbidden
ModSecurity: Access denied
directory index forbidden
deny rule
access forbidden by rule

Для Apache

Часто используется:

/var/log/apache2/error.log

Для Nginx

Часто:

/var/log/nginx/error.log

Конкретный путь зависит от сервера и хостинга.

14. Как найти 403 в логах через SSH

Для Apache:

grep "403" /var/log/apache2/error.log

Для Nginx:

grep "403" /var/log/nginx/error.log

Для просмотра последних строк:

tail -100 /var/log/nginx/error.log

или:

tail -100 /var/log/apache2/error.log

Что искать в первую очередь?

Например:

permission denied

→ проверяем права и владельца.

client denied by server configuration

→ проверяем правила сервера.

ModSecurity

→ проверяем WAF.

access forbidden by rule

→ ищем правило блокировки.

directory index forbidden

→ проверяем index-файл и DirectoryIndex.

15. Включите логирование WordPress

Если сервер пропускает запрос до WordPress, полезно включить встроенное логирование.

В wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После этого WordPress будет записывать ошибки в

wp-content/debug.log

.WordPress рекомендует использовать WP_DEBUG_LOG именно для сохранения ошибок в лог, а

WP_DEBUG_DISPLAY можно отключить, чтобы сообщения не показывались посетителям. (Важно

На рабочем сайте не стоит оставлять debug-режим включенным постоянно. После диагностики верните:

define( 'WP_DEBUG', false );

Также не оставляйте публично доступным

debug.log

: документация WordPress отдельно предупреждает, что открытые логи могут представлять угрозу безопасности. (WordPress Developer Resources).

16. Проверьте, не заражен ли сайт

Если 403:

• появился внезапно;
• возвращается после исправления;
• htaccess сам изменяется;
• появляются неизвестные PHP-файлы;
• создаются новые администраторы;
• файлы постоянно перезаписываются,

нельзя исключать malware.

Особенно подозрительная ситуация:

вы исправляете htaccess, а через несколько секунд вредоносный код возвращает старую версию.

В таком случае простая замена htaccess проблему не решит.

Что проверять

• неизвестные PHP-файлы;
• wp-content/uploads;
• wp-content/mu-plugins;
• liwp-config.php;
• htaccess;
• cron-задачи;
• пользователей WordPress;
• недавно измененные файлы;
• подозрительные admin accounts.

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

17. Восстановите сайт из резервной копии

Если вы точно знаете, что: вчера сайт работал, а сегодня появился 403 и между этими событиями были изменения, восстановление последней рабочей версии может быть самым быстрым способом вернуть сайт онлайн.

Но перед восстановлением желательно понять причину.

Иначе после восстановления вы можете снова установить тот же плагин или применить ту же конфигурацию — и 403 вернется.

Cloudways также рекомендует использовать backup/rollback как один из вариантов восстановления после появления ошибки. (Cloudways)

18. Проверьте DNS и домен

Иногда кажется, что WordPress сломан, хотя домен указывает не на тот сервер.

Проверьте:

A record
AAAA record
CNAME

Особенно после:

• миграции;
• смены хостинга;
• изменения DNS;
• подключения Cloudflare;
• изменения IP сервера.

Например:

example.com → старый сервер
www.example.com → новый сервер

может привести к совершенно разным результатам при открытии сайта.

19. Если 403 появился после миграции WordPress

Это отдельный сценарий.

Проверяйте в следующем порядке:

Шаг 1

Владелец файлов.

Шаг 2

Права каталогов.

Шаг 3

Права файлов.

Шаг 4

.htaccess.

Шаг 5

PHP-FPM / веб-сервер.

Шаг 6

Nginx/Apache configuration.

Шаг 7

Security plugin.

Шаг 8

WAF/ModSecurity.

Шаг 9

CDN.

Очень часто после миграции проблема находится не в WordPress, а в различии конфигураций старого и нового сервера.

20. Что делать, если 403 возникает только в WordPress Admin

Допустим:

Главная — работает
Статьи — работают
/wp-login.php — работает
/wp-admin/ — 403

Проверьте:

1. security plugin;
2. IP-блокировку;
3. htaccess;
4. отдельный htaccess внутри wp-admin;
5. WAF;
6. ModSecurity;
7. серверные правила доступа;
8. права каталога wp-admin.

Особенно обратите внимание на наличие дополнительных конфигурационных файлов внутри wp-admin.

WordPress сам по себе не создает отдельный htaccess внутри wp-admin;

такой файл может появиться вследствие действий security-инструментов или серверной конфигурации. (WordPress.org)

21. Что делать, если 403 появляется при сохранении записи

Очень характерный сценарий:

Админка открывается, запись создается, но при нажатии «Обновить» появляется 403.

Здесь проблема часто находится не в файловых разрешениях.

Проверяйте:

• ModSecurity;
• WAF;
• security plugin;
• REST API;
• AJAX;
• firewall;
• правила CDN.

Например, WAF может воспринимать содержимое редактора как подозрительный запрос.

Особенно это бывает при добавлении:

HTML
JavaScript
iframe
SQL-подобных строк
JSON
внешних URL

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

22. Не путайте 403 с 401, 404 и 500

Это важно для правильной диагностики.

Если вы неправильно определили код ошибки, можно потратить часы на поиск не той причины.

Быстрый алгоритм исправления 403 Forbidden

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

Первые 5 минут

1. Откройте сайт в режиме инкогнито.

2. Проверьте другой URL.

3. Проверьте сайт с другого IP.

4. Очистите кэш.

5. Посмотрите, работает ли /wp-login.php.

Следующие 10 минут

6. Сделайте backup.

7. Проверьте htaccess.

8. Проверьте права файлов и каталогов.

9. Проверьте владельца файлов.

10. Отключите плагины.

Затем

11. Проверьте security plugin.

12. Проверьте Cloudflare/CDN/WAF.

13. Проверьте ModSecurity.

14. Посмотрите Apache/Nginx error log.

15. Проверьте сайт на malware.

Диагностическая таблица 403

Когда обращаться в поддержку хостинга

Обращайтесь в поддержку, если:

• нет SSH/root-доступа;
• нет доступа к серверным логам;
• ModSecurity блокирует запрос;
• WAF работает на стороне хостинга;
• неправильный owner файлов;
• Nginx/Apache configuration недоступна;
• сайт работает на shared hosting;
• 403 возникает после изменения серверной конфигурации;
• проблема сохраняется после отключения плагинов;
• есть подозрение на malware.

Как правильно сформулировать запрос

Не пишите:

«У меня WordPress выдает 403, исправьте».

Лучше предоставить:

URL:
https://example.com/...

HTTP-код:
403

Когда появилась проблема:
30.08.2026 примерно в 11:30

Работает ли сайт:
главная — да
wp-admin — нет

Другие пользователи:
получают / не получают 403

После отключения plugins:
ошибка сохраняется

.htaccess:
проверен

Права:
проверены

Просьба:
проверьте error log, WAF/ModSecurity и блокировку IP.

Так техническая поддержка сможет намного быстрее найти причину.

Что не стоит делать при ошибке 403

Есть несколько распространенных ошибок.

❌ Не устанавливайте права

777
на весь WordPress

Это не является нормальным универсальным решением и может создать серьезную проблему безопасности.

❌ Не удаляйте

htaccess

без backup

Сначала сохраните оригинал.

❌ Не переустанавливайте WordPress сразу

В большинстве случаев 403 не требует переустановки ядра.

❌ Не отключайте всю безопасность навсегда

Если security plugin является причиной ошибки, найдите конкретное правило, а не оставляйте сайт без защиты.

❌ Не включайте вывод PHP-ошибок на рабочем сайте

Для диагностики лучше использовать логирование.

❌ Не меняйте одновременно десять настроек

Иначе вы не узнаете, какое именно изменение решило проблему.

Как предотвратить появление 403 в будущем

Профилактика значительно проще восстановления сайта после блокировки.

Делайте регулярные backup

Храните хотя бы несколько последних рабочих копий.

Используйте staging

Перед обновлением:

• WordPress;
• темы;
• плагинов;
• security tools

тестируйте изменения на staging.

Контролируйте права

Не устанавливайте случайные права на файлы только потому, что они «решили проблему».

Следите за логами

Если 403 появляется периодически, логи могут показать закономерность раньше, чем проблема станет критической.

Не устанавливайте неизвестные плагины

Особенно опасны плагины, давно не обновлявшиеся или скачанные с сомнительных сайтов.

Не забывайте о WAF

Современная защита сайта состоит не только из WordPress-плагинов. Блокировка может происходить на CDN или серверном уровне.

FAQ: часто задаваемые вопросы об ошибке 403 в WordPress

Итог

403 Forbidden в WordPress — это не самостоятельная «ошибка WordPress», а сообщение о том, что доступ к ресурсу был запрещен.

Поэтому правильная диагностика начинается не с переустановки WordPress, а с определения уровня, на котором произошла блокировка.

Оптимальная последовательность выглядит так:

Проверить URL
      ↓
Проверить другой IP
      ↓
Очистить кэш
      ↓
Проверить .htaccess
      ↓
Проверить permissions
      ↓
Проверить owner
      ↓
Отключить плагины
      ↓
Проверить security plugin
      ↓
Проверить CDN/WAF/ModSecurity
      ↓
Проверить Apache/Nginx
      ↓
Посмотреть error logs
      ↓
Проверить malware

Если следовать этой последовательности, большинство случаев 403 Forbidden можно локализовать без переустановки WordPress и без потери данных.

Главное правило: не пытайтесь исправить всё сразу. Сначала определите, кто именно вернул код 403 — WordPress, плагин, веб-сервер, WAF, CDN или файловая система.

Источники

1. Cloudways — How to Fix WordPress 403 Forbidden Error — исходный материал, использованный как тематическая основа.
2. WordPress Developer Resources — Hardening WordPress — официальная документация WordPress по безопасности и правам файлов.
3. WordPress Developer Resources — Apache HTTPD / .htaccess — официальная документация WordPress по htaccess и Apache.
4. WordPress Developer Resources — Debugging in WordPress — официальная документация по WP_DEBUG, WP_DEBUG_LOG и диагностике.
5. WordPress Developer Resources — Editing Files — рекомендации WordPress по работе с файлами и резервным копированием.
6. Nginx — ngx_http_access_module — официальная документация Nginx поallow/deny.
7. Nginx — ngx_http_rewrite_module — официальная документация Nginx по правилам, способным возвращать HTTP 403.
8. WordPress Support — 403 Forbidden при работе с WordPress — практические примеры диагностики security plugins, WAF и.htaccess.

Алексей Шевченко

редактор wpcafe

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующийся на создании сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/