Перенесли сайт на хостинг, і плагіни перестали встановлюватися. Або медіафайли не завантажуються через адмінку. Або оновлення ядра злітає з помилкою «Could not create directory». Знайомо?

Причина майже завжди одна, неправильні права доступу на файли та папки. Локальний сервер (OpenServer, MAMP) працює від імені поточного користувача Windows/macOS і пробачає все. Бойовий хостинг на Linux, ні. У кожного файлу й каталогу є власник і три рівні дозволів, і якщо вебсервер не може писати в потрібну папку, сайт ламається мовчки або з незрозумілою помилкою.

Нижче, що таке 755 і 644 насправді, як виставити їх один раз через FileZilla для всього сайту, і які файли потребують особливого підходу.

💡 Швидкий огляд:

• Що означають цифри 755 і 644 та чому 777 — це діра в безпеці
• Як масово виставити права через FileZilla за 2 заходи: спершу папки, потім файли
• Які дозволи потрібні wp-config.php,.htaccess і папці wp-content
• Як зробити те саме через SSH однією командою за 5 секунд

Що означають права доступу і чому 777 — це катастрофа

Кожен файл і папка на Linux-сервері зберігають три набори дозволів: для власника, для групи та для всіх інших. Цифра — це сума бітів: 4 (читання) + 2 (запис) + 1 (виконання для папок = вхід усередину).

755 для папок розшифровується так: власник може все (7), група та інші, читати й входити (5). Папка доступна вебсерверу для сканування, створення всередині файлів і підпапок, але ніхто сторонній не може її видалити чи перейменувати.

644 для файлів: власник читає й пише (6), інші, тільки читають (4). PHP-файли виконуються інтерпретатором, а не системою, біт виконання їм не потрібен.

777 (власник+група+інші = все) — це відкриті двері. Будь-який процес на сервері, включно зі скриптами сусідніх сайтів на shared-хостингу, може читати, змінювати й видаляти ваші файли. За даними WPScan за 2025, некоректні дозволи входять до п'ятірки найчастіших векторів зламу WordPress на shared-хостингах. Ніколи не ставте 777, якщо плагін чи тема вимагають таких прав — це червоний прапорець.

Які права WordPress вважає правильними

Офіційна документація WordPress визначає рекомендовані дозволи так:

На більшості хостингів власник файлової системи збігається з користувачем, від якого працює PHP (налаштування suPHP/FastCGI + suEXEC). У такій конфігурації прав 755/644 достатньо: WordPress може писати в wp-content/uploads, оновлювати ядро й плагіни, встановлювати теми без ескалації до 777.

Перевірте, чи підходить це вашому хостеру: зайдіть в адмінку → спробуйте встановити будь-який безкоштовний плагін. Встановився без запиту FTP-доступу, отже, схема 755/644 працює і права вже правильні.

Як виставити права через FileZilla: покроково

FileZilla, безкоштовний FTP-клієнт, який уміє масово рекурсивно змінювати права. Завантажте з офіційного сайту, якщо ще немає.

Крок 1: під'єднуємося й заходимо в корінь WordPress

Під'єднайтеся до хостингу через FTP (логін/пароль, ті самі, що й від хостинг-акаунту, порт 21). На правій панелі перейдіть у кореневу папку сайту. Туди, де лежать wp-config.php, wp-content, wp-admin і wp-includes.

Крок 2: виставляємо 755 на всі папки

Виділіть усі файли й папки в корені (Ctrl+A). Правий клік → «Права доступу до файлу».

У вікні, що відкрилося, в полі «Числове значення» введіть 755. Позначте чекбокс «Перенаправити у вкладені каталоги». Перемикач поставте в положення «Застосувати тільки до каталогів». Натисніть OK.

FileZilla пройде по кожній папці й підпапці сайту та виставить 755. Процес триває від кількох секунд до пари хвилин залежно від розміру сайту.

Крок 3: виставляємо 644 на всі файли

Знову виділіть усе в корені (Ctrl+A), знову правий клік → «Права доступу до файлу».

Тепер введіть 644. Позначте «Перенаправити у вкладені каталоги». Перемикач, «Застосувати тільки до файлів». OK.

Готово. Два заходи, папки й файли, і весь сайт приведено до стандарту.

Швидкий спосіб через SSH: команда find

Якщо у вас є SSH-доступ до сервера, та сама операція робиться двома командами за п'ять секунд:

1
find /path/to/wordpress -type d -exec chmod 755 {} \;
2
find /path/to/wordpress -type f -exec chmod 644 {} \;

Перша проходить по всіх папках (-type d) і ставить 755. Друга, по всіх файлах (-type f) і ставить 644. Замініть /path/to/wordpress на реальний шлях до кореня сайту (зазвичай /home/username/public_html).

Після цього окремо посильте wp-config.php:

1
chmod 600 /path/to/wordpress/wp-config.php

І .htaccess, якщо він у вас є (Apache-сервер):

1
chmod 644 /path/to/wordpress/.htaccess

Якщо сайт на Nginx, файлу .htaccess немає, цей крок пропустіть.

Що робити, якщо права збиваються знову

Ситуація: ви виставили 755/644, усе працювало, а через тиждень, та сама помилка. Причина найчастіше в процесі, який працює від іншого користувача.

Типові винуватці:

• Cron-задачі хостингу. Деякі хостери запускають обслуговуючі скрипти від root, і вони створюють файли з правами, які вебсервер потім не може перезаписати. Рішення: попросіть техпідтримку налаштувати cron від імені вашого користувача.
• Сторонній плагін резервного копіювання. Пише дампи й архіви в wp-content від імені того користувача, під яким запущений. Перевірте логи плагіна, якщо він створює файли не від імені власника сайту, замініть на альтернативу.
• Кешувальний плагін. Створює папки кешу з невірними правами. Зайдіть у налаштування плагіна й знайдіть кнопку «Очистити кеш» або «Reset permissions».

Універсальний швидкий фікс, повторити процедуру з розділу вище (FileZilla за 2 заходи або дві find-команди). Це не вирішить першопричину, але поверне сайт у робочий стан.

⁉️🤔 Часті запитання

Що робити, якщо після зміни прав сайт упав у «білий екран смерті»?

Білий екран (WSOD) після масової зміни прав, вкрай рідкісна ситуація, але можлива. Перше: увімкніть WP_DEBUG у wp-config.php, так ви побачите текст помилки замість білого екрана. Друге: перевірте, чи не виставили ви 644 на папки (папкам потрібен біт виконання, тобто 5 у кінці). Виправте однією find-командою: find /path -type d -exec chmod 755 {} \;, цього достатньо в більшості випадків. Якщо сайт не запрацював, відновіть бекап і змінюйте права поступово: спочатку на wp-content, потім на корінь, спостерігаючи за реакцією.

Чи можна виставити права через вбудований файловий менеджер хостингу?

Так, але тільки для окремих файлів і папок. cPanel-хостинги дають File Manager із пунктом «Change Permissions» у контекстному меню. Однак рекурсивно виставити права на сотні й тисячі файлів через вебінтерфейс практично неможливо, для масової операції беріть FileZilla або SSH.

Які права повинні бути в папки wp-content/uploads?

Стандартні 755, як і в усіх інших папок. Якщо плагін чи тема створюють підпапки всередині uploads і мають проблеми, перевірте власника процесу (повинен збігатися з власником папки), а не підіймайте права до 777. Іноді проблема вирішується додаванням define('FS_METHOD', 'direct'); у wp-config.php.

Чи потрібно виставляти права на файли всередині wp-admin і wp-includes?

Так, стандартні 644 для файлів, 755 для папок, як і для всього іншого сайту. Процедура з FileZilla (виділити все в корені) обробляє їх автоматично.

Хостер вимагає 777 на якісь папки — це нормально?

Ні. Вимога 777, ознака того, що PHP на сервері працює від користувача, відмінного від власника файлів (наприклад, mod_php без suEXEC). За такої конфігурації WordPress не може писати в папки без «загального» доступу. Варіанти: змінити хостера на того, хто використовує suPHP/FastCGI (більшість сучасних), або додати define('FS_METHOD', 'direct'); у wp-config.php, у частині випадків цього достатньо.

Правильні права, фундамент, а не опція

Виставили 755 на папки й 644 на файли, закрили найчастіший канал «незрозумілих» помилок під час перенесення сайту. Дві хвилини в FileZilla або дві команди в SSH економлять години ворожіння над логами.

Якщо сайт на хорошому хостингу з suPHP/FastCGI, цих прав достатньо на все: встановлення плагінів, завантаження медіа, автооновлення ядра. Не підіймайте права до 777, навіть якщо про це просить інструкція до старого плагіна. І додайте wp-config.php окремим рядком: chmod 600, у ньому пароль бази даних, доступ стороннім туди не потрібен.