Сайт не дає завантажити тему, файл занадто великий. Пошуковики індексують службові сторінки, яких у видачі бути не повинно. У логах сервера, спроби доступу до wp-config.php з чужих IP. Три проблеми, а рішення одне: файл .htaccess, який уже лежить у корені вашого WordPress-сайту.

Ви напевно бачили його, коли налаштовували ЧПУ-посилання. Але можливості .htaccess цим не обмежуються: він керує доступом, безпекою, переспрямуваннями та лімітами завантаження на рівні сервера. І, на відміну від плагінів безпеки, не додає навантаження на PHP.

Нижче, чотири практичні сценарії, з якими стикається кожен адміністратор WordPress. Кожен супроводжується готовим кодом, поясненням і вказівкою, куди саме його вставляти. Код переписано під Apache 2.4 (актуальна версія на 2026 рік), але кожен сніпет містить блок сумісності з Apache 2.2, щоб ви не гадали, чи запрацює він на вашому хостингу.

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

• Збільште ліміт завантаження файлів через .htaccess і .user.ini для PHP-FPM.
• Закрийте сайт від індексації пошуковиками на рівні сервера.
• Вимкніть перегляд директорій одним рядком.
• Захистіть wp-config.php від прямого доступу сучасним синтаксисом Apache 2.4.

1. Збільшуємо максимальний розмір файлів для завантаження

Намагаєтеся встановити тему або плагін, а WordPress видає помилку: «The uploaded file exceeds the upload_max_filesize directive in php.ini». Ліміт за замовчуванням у багатьох хостерів, 2 МБ або 8 МБ, і архів теми в нього не вміщується.

Редагувати php.ini на shared-хостингу не можна. Але якщо Apache працює з модулем mod_php, ліміт піднімається прямо з .htaccess. Відкрийте файл у корені сайту (через FTP або файловий менеджер хостингу) і додайте в кінець:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Перша директива задає максимальний обсяг POST-запиту, друга, максимальний розмір одного файлу для завантаження. Обидва значення повинні збігатися, або post_max_size має бути трохи більшим.

Перевірте результат: зайдіть в адмінку WordPress, Медіафайли → Додати новий. Знизу відобразиться актуальний ліміт.

Важливо: якщо хостинг переведено на PHP-FPM (а таких більшість у 2026 році), директиви php_value у .htaccess не спрацюють. Перевірте: Інструменти → Здоров'я сайту → Інформація → Сервер. У рядку «Server architecture» шукайте згадку FPM. Для такого хостингу ліміт змінюється через файл .user.ini у корені сайту:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Формат, як у php.ini, зі знаками рівності замість php_value. Зміни застосовуються миттєво, перезавантаження сервера не потрібне. Якщо файлу .user.ini у корені немає, створіть його.

2. Закриваємо сайт від індексації пошуковиками

Ситуація: тестовий сайт на піддомені, staging-копія або лендинг, який не повинен потрапити у видачу Google та Яндекса. Простий robots.txt з Disallow: / пошуковики можуть проігнорувати: це рекомендація, а не заборона.

Залізний спосіб, заблокувати роботів на рівні сервера. Класичний підхід через SetEnvIfNoCase працює в Apache 2.4 через модуль сумісності mod_access_compat, але він вважається застарілим. Сучасний метод, перенаправити ботів із порожнім User-Agent через mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Що тут відбувається: RewriteCond перевіряє User-Agent кожного запиту. При виявленні ключових слів bot, spider, crawler або scanner (регістр не важливий, прапорець [NC]) сервер повертає 403 Forbidden (прапорець [F]).

Чотирьох шаблонів достатньо, щоб перекрити всі основні пошукові системи: Googlebot, YandexBot, Bingbot, Yahoo Slurp і десятки менш відомих. Перелічувати кожного бота окремо безглуздо: тільки в Google кілька десятків варіантів User-Agent під різні сервіси (пошук, зображення, відео, AdsBot).

Хочете закрити сайт тільки від Яндекса, а Google залишити? Звужте шаблон:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Символ ^ означає «початок рядка». Без нього правило зачепить і тих ботів, у яких yandex зустрінеться в середині User-Agent.

Важливо: якщо WordPress уже використовує mod_rewrite для ЧПУ-посилань, блок RewriteEngine On уже є в .htaccess. Дублювати його не потрібно, просто додайте нові RewriteCond і RewriteRule після наявних правил WordPress, але до закривального тега </IfModule>.

Після змін перевірте .htaccess на помилки: одрук у директивах, і сайт ляже з помилкою 500. Синтаксис можна перевірити онлайн-валідатором або командою apachectl configtest (доступна не в усіх хостерів). Перед редагуванням обов'язково завантажте резервну копію поточного .htaccess.

3. Вимикаємо перегляд директорій

Зайдіть на свій сайт за адресою /wp-content/uploads/. Якщо замість 403-ї помилки ви бачите список файлів, у вас увімкнено перегляд директорій. Це діра: будь-хто може вивчити структуру папок, знайти вразливий плагін або прочитати завантажений PDF-документ.

Вимикається одним рядком у .htaccess:

1
Options -Indexes

Додайте його на початок файлу, до правил WordPress. Тепер при спробі відкрити директорію без індексного файлу сервер віддасть 403 Forbidden.

На більшості сучасних хостингів ця опція увімкнена за замовчуванням, але перевірте, особливо якщо сайт переїжджав між серверами або ви працюєте з VPS, де Apache налаштовували вручну.

4. Захищаємо wp-config.php від прямого доступу

wp-config.php, найважливіший файл WordPress. У ньому лежать ключі безпеки, префікс таблиць і доступ до бази даних: ім'я БД, користувач, пароль, хост.

Сам файл написаний на PHP і при прямому відкритті в браузері віддає порожню сторінку, рушій WordPress його не виконує. Але якщо на сервері тимчасово вимкнеться обробка PHP (збій конфігурації, оновлення модуля), вміст wp-config.php може віддатися як звичайний текст. Разом із паролем бази даних.

Закриваємо доступ через .htaccess. Більшість статей в інтернеті пропонують застарілий синтаксис Apache 2.2, який не працює в Apache 2.4.6 і вище. Ось сучасний варіант зі зворотною сумісністю:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

Блок IfModule перевіряє наявність модуля mod_authz_core (з'явився в Apache 2.4.6). Якщо модуля немає, застосовується синтаксис 2.2. Якщо є, сучасна директива Require all denied. Один код працює на обох версіях Apache.

Після додавання правил будь-яке звернення до wp-config.php через браузер отримає 403 Forbidden, навіть якщо PHP-обробник не працює. WordPress звертається до файлу напряму через файлову систему, тож на роботу сайту правило не впливає.

Той самий підхід застосовний до будь-якого конфіденційного файлу: замініть wp-config.php на ім'я потрібного, наприклад, phpinfo.php або .env.

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

Чи можна взагалі обійтися без.htaccess** у WordPress?**

Так, якщо сайт працює на Nginx, а не на Apache. Nginx не підтримує .htaccess, усі правила задаються в конфігурації сервера (nginx.conf або файл у sites-available/). На shared-хостингах майже завжди Apache, і .htaccess доступний. На VPS з Nginx правила переносяться в секцію server {}: синтаксис інший, але логіка та сама. Наприклад, аналог Options -Indexes в Nginx, autoindex off;.

Що робити, якщо після зміни.htaccess сайт упав із помилкою 500?

Негайно поверніть резервну копію .htaccess, яку ви зробили до редагування (ви ж її зробили?). Підключіться по FTP, видаліть змінений .htaccess і завантажте збережений оригінал. Сайт оживе миттєво. Помилка 500 після редагування .htaccess майже завжди спричинена одруком у директиві або конструкцією, яку не підтримує ваша версія Apache.

Чому php_value в.htaccess не працює на моєму хостингу?

Найімовірніше, хостинг використовує PHP-FPM замість mod_php. Перевірте: Інструменти → Здоров'я сайту → Інформація → Сервер. Якщо в рядку «Server architecture» вказано FPM, php_value у .htaccess ігнорується. Використовуйте файл .user.ini у корені сайту (див. розділ 1) або зверніться до підтримки хостингу. На VPS ліміти змінюються в пулі PHP-FPM (www.conf), але це потребує доступу до конфігурації сервера.

Як перевірити, що.htaccess дійсно працює?

Найпростіший тест, правило з розділу 3 (Options -Indexes). Зайдіть на /wp-content/uploads/ до і після додавання. Був список файлів, стала 403-тя помилка? Файл працює. Інший спосіб: додайте в .htaccess рядок із явною синтаксичною помилкою і відкрийте сайт. Помилка 500 підтвердить, що Apache читає .htaccess. Одразу після перевірки видаліть тестовий рядок.

Чи безпечно використовувати код зі статті на живому сайті?

Так, усі наведені сніпети протестовані на Apache 2.4 (актуальна версія на 2026 рік) і містять блоки сумісності з Apache 2.2. Єдина обов'язкова умова: перед будь-яким редагуванням .htaccess завантажте поточну версію файлу на комп'ютер. П'ятисекундна операція економить години відновлення в разі одруку. І не редагуйте .htaccess через плагіни, тільки FTP або файловий менеджер хостингу: плагін може додати екранування, яке зламає синтаксис.

Чим підхід до захисту wp-config.php у статті відрізняється від того, що пишуть на інших сайтах?

Більшість статей копіюють синтаксис Apache 2.2: Order allow,deny і Deny from all. Ці директиви належать модулю mod_access_compat, який оголошено застарілим в Apache 2.4 і може бути вимкнений на сучасних серверах. Наш сніпет використовує Require all denied з модуля mod_authz_core, це актуальний стандарт для Apache 2.4.6 і вище. При цьому блок <IfModule> зберігає працездатність на старих серверах.

Що ставити в конфігурацію.htaccess прямо зараз

Файл .htaccess, компактний, але потужний інструмент. Із чотирьох описаних прийомів два закривають уразливості з мінімальними зусиллями: вимкнення перегляду директорій і захист wp-config.php. Це один рядок і один блок коду, які можна додати прямо зараз, на роботу сайту вони не впливають.

Збільшення ліміту завантаження виручає щоразу, коли WordPress відмовляється завантажувати тему або плагін. А блокування індексації на рівні сервера, останній рубіж оборони для закритих і тестових сайтів.

Тримайте резервну копію .htaccess перед кожним редагуванням. Помилка в синтаксисі кладе сайт миттєво, і так само миттєво виправляється, якщо копія під рукою. З цим правилом .htaccess перетворюється зі страшного файлу на робочий інструмент.