Помилка 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
• Помилка HTTP 403 – заборонено
• Заборонений
• Доступ заборонено
• Ви не можете отримати доступ до цього ресурсу
• 403 Forbidden: Access Denied
• Forbidden by Rule
• Помилка 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;

• місцезнаходження;

• allow;

• deny;

• 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.

Шукайте записи на кшталт:

Дозвіл відхилено
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 працює на стороні хостингу;
• неправильний власник файлів;
• 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: WAF/ModSecurity та блокування IP.

Так, технічна підтримка зможе набагато швидше знайти причину.

Що не варто робити при помилці 403

Є кілька найпоширеніших помилок.

❌ Не встановлюйте права

777 на весь WordPress

Це не є нормальним універсальним рішенням і може спричинити серйозну проблему безпеки.

❌ Не видаляйте

.htaccess

без backup

Спершу збережіть оригінал.

❌ Не встановлюйте WordPress відразу

Найчастіше 403 не вимагає переустановки ядра.

❌ Не відключайте всю безпеку назавжди

Якщо security plugin спричиняє помилку, знайдіть конкретне правило, а не залишайте сайт без захисту.

❌ Не включайте виведення PHP-помилок на робочому сайті

Для діагностики найкраще використовувати логування.

❌ Не змінюйте одночасно десять налаштувань

Інакше ви не дізнаєтесь, яка саме зміна вирішила проблему.

Як запобігти появі 403 у майбутньому

Профілактика значно простіша за відновлення сайту після блокування.

Робіть регулярні backup

Зберігайте хоч кілька останніх робочих копій.

Використовуйте staging

Перед оновленням:

• Вордпрес;
• теми;
• плагінів;
• засоби безпеки

тестуйте зміни на 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 log

Якщо слідувати цій послідовності, більшість випадків 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/