Помилка 403 Forbidden означає, що сервер отримав запит до сторінки або файлу, але відмовив у доступі. У WordPress вона може з’явитися під час відкриття головної сторінки, окремого розділу, /wp-admin/, /wp-login.php або після встановлення плагіна. Іноді сайт працює для одних користувачів, але недоступний для інших — наприклад, через блокування IP-адреси.
Причина не завжди пов’язана безпосередньо з WordPress. Доступ може обмежувати вебсервер, хостингова система захисту, правила у файлі .htaccess, права доступу до файлів і папок, CDN або плагін безпеки. Перед змінами бажано створити резервну копію файлів і бази даних. Якщо доступу до панелі WordPress немає, копію можна зробити через панель хостингу, FTP або SSH, якщо ці способи доступні.
Що означає помилка 403
Код 403 повідомляє не про відсутність сторінки, а про заборону її перегляду. Це відрізняє його від помилки 404, за якої ресурс не знайдено. При 403 потрібний файл або маршрут може існувати, але сервер не дозволяє до нього звертатися.
Варто визначити масштаб проблеми:
- 403 виникає на всьому сайті чи лише на окремій сторінці;
- помилка з’являється тільки в адмінці або також на фронтенді;
- сайт недоступний усім користувачам чи лише з певної мережі;
- проблема почалася після оновлення WordPress, плагіна, теми, зміни хостингу або налаштування SSL;
- у повідомленні згадується вебсервер Apache, Nginx, WAF, ModSecurity або плагін безпеки.
Для початкової перевірки можна відкрити сайт в іншому браузері, у приватному режимі та через мобільний інтернет. Це не усуває причину, але допомагає зрозуміти, чи пов’язана вона з локальним кешем або конкретною IP-адресою. Для власників сайту також може бути корисною інструкція Як повернути доступ до адмінки WordPress.
Права файлів і папок
Неправильні права доступу — одна з поширених причин 403 після перенесення сайту, відновлення резервної копії або ручної зміни файлів. Вебсервер повинен мати можливість читати файли WordPress, але надмірно відкриті права створюють ризик несанкціонованих змін.
Зазвичай для файлів використовують права на рівні 644, а для папок — 755. Однак це не універсальне правило: конкретні значення залежать від конфігурації хостингу, користувача вебсервера та способу запуску PHP. Файл wp-config.php часто захищають суворіше, але надмірне обмеження також може порушити роботу сайту.
Перевірку виконують через файловий менеджер хостингу, FTP або SSH. Не варто бездумно змінювати права рекурсивно для всього сайту: це може відкрити службові файли для запису, зламати роботу оновлень або приховати справжню причину помилки. Важливо також перевірити власника файлів після перенесення — права можуть бути правильними, але вебсервер усе одно не матиме доступу через невірного власника або групу.
Правила безпеки та .htaccess
Файл .htaccess використовується на серверах Apache для керування перенаправленнями, доступом до каталогів, кешуванням і правилами безпеки. Помилка в його синтаксисі або надто суворе правило може заблокувати весь сайт, адмінку чи окремі URL.
Перед редагуванням потрібно завантажити поточний .htaccess і зберегти його копію. Якщо файл змінювали нещодавно, безпечним способом перевірки може бути тимчасове перейменування, наприклад на .htaccess.backup, а потім тестове відкриття сайту. Робити це слід обережно: зникнення файлу може вплинути на постійні посилання та правила перенаправлення.
Якщо після перейменування сайт відкривається, причину потрібно шукати в одному з правил. Не слід просто вставляти випадковий шаблон з інтернету: він може конфліктувати з конфігурацією хостингу або містити небезпечні дозволи. Після відновлення доступу правила WordPress можна оновити через налаштування постійних посилань, але перед цим варто перевірити, що файл не був змінений вірусом.
Окремо перевіряють правила, які забороняють доступ до wp-admin, wp-login.php, службових каталогів або певних User-Agent. Якщо 403 з’явився після встановлення плагіна безпеки, його конфігурація могла залишитися активною навіть за відсутності доступу до адмінпанелі.
Блокування IP
Сайт може повертати 403 лише для однієї IP-адреси через правила хостингу, WAF, CDN, плагін захисту або автоматичний захист від підозрілих запитів. Блокування часто спрацьовує після великої кількості невдалих входів, сканування вразливостей, частих запитів до API або помилкового визначення звичайної дії як атаки.
Для перевірки порівняйте доступ із мобільної мережі та іншого інтернет-підключення. Якщо з іншої мережі сайт працює, перевірте журнал блокувань у панелі хостингу, Cloudflare або іншого сервісу захисту. IP-адресу можна додати до списку дозволених лише після перевірки, що вона належить вам і не використовується спільно з небезпечними пристроями.
Не варто без аналізу вимикати WAF, антибот-захист або плагін безпеки на постійній основі. Тимчасове послаблення захисту допустиме лише для діагностики, бажано з резервною копією та фіксацією внесених змін. Якщо блокування повторюється, потрібно перевірити журнали, парольні атаки, зараження сайту та некоректні інтеграції.
Безпечне повернення доступу
Оптимальна послідовність дій починається з фіксації помилки та створення резервної копії. Далі перевіряють, чи відтворюється 403 з інших мереж, аналізують журнали сервера, права файлів і папок, файл .htaccess, правила WAF та налаштування плагінів безпеки. Після кожної зміни потрібно повторно перевіряти сайт, щоб розуміти, яка саме дія вплинула на результат.
- Збережіть копію файлів і бази даних, не перезаписуючи єдину наявну резервну копію.
- Визначте, які URL повертають 403 і чи залежить результат від IP-адреси.
- Перевірте журнали помилок вебсервера та журнал блокувань системи захисту.
- Порівняйте права доступу й власника файлів із робочою конфігурацією хостингу.
- Перевірте зміни в
.htaccess, конфігурації CDN і плагінах безпеки. - Після відновлення доступу оновіть WordPress, тему та плагіни з офіційних джерел і змініть підозрілі паролі.
Якщо одночасно з 403 з’явилися невідомі файли, перенаправлення, нові облікові записи або зміни в коді, спочатку потрібно розглядати ризик зараження. У такій ситуації не варто просто видаляти окремі файли чи перевстановлювати плагіни: можна втратити докази та пошкодити дані. Спеціаліст потрібен також тоді, коли немає доступу до хостингу, сайт працює на Nginx із нетиповою конфігурацією, резервна копія відсутня або після стандартних перевірок причина залишається невідомою.