WordPress .htaccess: Повний технічний посібник з продуктивності, безпеки та SEO

Файл .htaccess (Hypertext Access) — це конфігураційний файл Apache на рівні директорії, який інструктує веб-сервер щодо обробки запитів до вашого сайту WordPress — без необхідності вносити зміни до глобального httpd.conf. Кожна директива, розміщена в .htaccess, рекурсивно застосовується до директорії, в якій вона знаходиться, та всіх піддиректорій нижче, що робить файл на кореневому рівні найпотужнішим інструментом, доступним адміністратору WordPress поза самим сервером.

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

Що насправді робить файл WordPress .htaccess

Apache обробляє .htaccess при кожному HTTP-запиті. Це означає, що кожна написана вами директива має вимірюваний вплив на затримку, стан безпеки та поведінку сканування. WordPress автоматично записує мінімальний блок перезапису до .htaccess при збереженні структури постійних посилань, але цей блок є лише відправною точкою. Файл здатний обробляти:

• Перезапис URL та перенаправлення через mod_rewrite
• Контроль доступу через mod_authz_host та mod_access_compat
• Впровадження HTTP-заголовків відповіді через mod_headers
• Стиснення виводу через mod_deflate
• Керування кешем браузера через mod_expires
• Шлюзи автентифікації через mod_auth_basic
• Власні документи помилок через директиву ErrorDocument

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

Де знаходиться файл .htaccess і як отримати до нього доступ

Основний файл .htaccess для інсталяції WordPress знаходиться в кореневій директорії документів — зазвичай /public_html/, /var/www/html/ або еквівалентному шляху, призначеному вашим хостинг-провайдером. Це та сама директорія, що містить wp-config.php, wp-login.php та папку wp-content/.

Оскільки ім’я файлу починається з крапки, більшість операційних систем та FTP-клієнтів приховують його за замовчуванням.

Щоб відобразити приховані файли у FileZilla:

Server menu > Force showing hidden files

Щоб відобразити приховані файли у cPanel File Manager:

Settings > Show Hidden Files (dotfiles)

У середовищі VPS Хостингу, де у вас є SSH-доступ, ви можете підтвердити існування файлу та перевірити його дозволи безпосередньо:

ls -la /var/www/html/ | grep htaccess

Файл повинен належати користувачу веб-сервера (зазвичай www-data або apache) та мати дозволи 644. Дозволи на запис для всіх (666 або 777) для .htaccess є серйозною вразливістю безпеки — будь-який процес на сервері може перезаписати ваші правила.

Пояснення стандартного блоку WordPress .htaccess

Коли ви переходите до Налаштування > Постійні посилання в панелі керування WordPress і зберігаєте, WordPress записує наступний блок:

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

Розбір рядок за рядком:

RewriteEngine On — активує рушій перезапису для цього контексту директорії.
RewriteBase / — встановлює базовий URL-шлях для відносних перезаписів. Для інсталяцій у піддиректорії змініть це на /subdirectory/.
RewriteRule ^index.php$ - [L] — якщо запит буквально стосується index.php, зупинити обробку та обслужити його безпосередньо.
RewriteCond %{REQUEST_FILENAME} !-f — продовжувати лише якщо запитуваний шлях не є існуючим файлом.
RewriteCond %{REQUEST_FILENAME} !-d — продовжувати лише якщо запитуваний шлях не є існуючою директорією.
RewriteRule . /index.php [L] — направляти все інше через фронт-контролер WordPress.

Критичне правило: Ніколи не редагуйте вручну нічого між маркерами # BEGIN WordPress та # END WordPress. WordPress автоматично регенерує цей блок і перезапише ваші зміни. Розміщуйте всі власні директиви вище коментаря # BEGIN WordPress або нижче коментаря # END WordPress.
Як створити файл .htaccess, якщо він відсутній
Відсутній файл .htaccess призводить до того, що всі URL WordPress, крім головної сторінки, повертають помилки 404, оскільки Apache не має інструкцій для маршрутизації запитів через index.php.
Метод 1: Регенерація через панель керування
Перейдіть до Налаштування > Постійні посилання та натисніть Зберегти зміни без внесення будь-яких змін. WordPress спробує автоматично записати файл, якщо директорія доступна для запису.
Метод 2: Створення вручну через SSH
nano /var/www/html/.htaccess
Вставте стандартний блок, показаний вище, збережіть за допомогою Ctrl+O та вийдіть за допомогою Ctrl+X. Потім встановіть правильні дозволи:
chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess
Метод 3: Створення через FTP
Створіть локально звичайний текстовий файл, назвіть його .htaccess (не .htaccess.txt — розширення має бути відсутнім), вставте стандартний блок та завантажте його до кореневої директорії документів у режимі передачі ASCII.
URL-перенаправлення: 301, 302 та правила перезапису
Постійні перенаправлення 301
Перенаправлення 301 сигналізує пошуковим системам, що URL переміщено назавжди. Google передає приблизно 90–99% посилальної ваги через 301. Використовуйте його при перейменуванні слага публікації, міграції з HTTP на HTTPS або консолідації дублікатів контенту.
# Redirect a single old page to a new URL
Redirect 301 /old-page/ https://yourdomain.com/new-page/

# Redirect an entire old directory
Redirect 301 /old-category/ https://yourdomain.com/new-category/
Тимчасові перенаправлення 302
Використовуйте 302 лише тоді, коли призначення справді тимчасове — наприклад, під час A/B-тестування або технічного обслуговування. Пошукові системи не передають посилальну вагу через 302.
Redirect 302 /sale/ https://yourdomain.com/promo-page/
Примусовий HTTPS за допомогою mod_rewrite
Це одне з найважливіших правил для будь-якого робочого сайту WordPress. Розміщення цього правила вище блоку WordPress гарантує, що весь HTTP-трафік буде постійно перенаправлено на HTTPS ще до того, як WordPress обробить запит:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Якщо ваш сайт знаходиться за балансувальником навантаження або CDN, який завершує SSL (поширено в хмарній інфраструктурі), використовуйте натомість X-Forwarded-Proto:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Поєднання цього з дійсним SSL-сертифікатом є обов’язковим як для безпеки, так і для сигналів ранжування Google.
Видалення кінцевого слеша з URL, що не є директоріями
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{THE_REQUEST} s(.+?)/+s
RewriteRule ^(.+)/$ /$1 [R=301,L]
</IfModule>
Видалення «category» з URL категорій
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^category/(.+)$ https://yourdomain.com/$1 [R=301,L]
</IfModule>
Увага: Це правило вимагає плагіна на кшталт WP No Category Base для оновлення внутрішньої маршрутизації WordPress, інакше ви створите петлі перенаправлення.
Посилення безпеки через .htaccess
Захист wp-config.php
wp-config.php містить облікові дані бази даних, ключі автентифікації та солі. Прямий доступ через браузер має бути заблокований безумовно:
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>
Захист самого .htaccess
Запобігайте читанню файлу .htaccess через запит браузера:
<Files .htaccess>
    Order Allow,Deny
    Deny from all
</Files>
Вимкнення перегляду директорій
Якщо директорія не містить index.php або index.html, Apache за замовчуванням відображатиме її вміст — розкриваючи структуру файлів зловмисникам:
Options -Indexes
Блокування зловживань XML-RPC
xmlrpc.php є частою ціллю для атак підсилення методом грубої сили. Якщо ви не використовуєте Jetpack, віддалену публікацію або пінгбеки, заблокуйте його повністю:
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>
Обмеження доступу до wp-login.php за конкретними IP-адресами
На VPS з cPanel або будь-якому виділеному середовищі, де ваша IP-адреса є статичною, це один із найефективніших заходів безпеки:
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.10
    Allow from 198.51.100.25
</Files>
Замініть IP-адреси своїми реальними статичними IP. Якщо ви працюєте з кількох місць або використовуєте динамічну IP-адресу, розгляньте замість цього VPN з фіксованим вихідним вузлом.
Блокування шкідливих User Agent
Скрепери, сканери вразливостей та спам-боти коментарів часто ідентифікують себе за впізнаваними рядками user agent:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|nikto|sqlmap) [NC]
RewriteRule .* - [F,L]
</IfModule>
Примітка: Блокування легітимних SEO-краулерів, таких як Ahrefs та SEMrush, не дозволить вам бачити власні дані зворотних посилань у цих інструментах. Оцініть цей компроміс відповідно до вашого випадку використання.
Блокування доступу за IP-адресою
<Limit GET POST HEAD>
    Order Allow,Deny
    Allow from all
    Deny from 192.0.2.50
    Deny from 198.51.100.0/24
</Limit>
Нотація CIDR (наприклад, /24) дозволяє блокувати цілі підмережі, що корисно при роботі з координованими атаками з одного діапазону IP.
Запобігання хотлінкінгу зображень
Хотлінкінг споживає вашу пропускну здатність без будь-якої вигоди для вас. Заблокуйте зовнішнім сайтам можливість вбудовувати ваші зображення безпосередньо:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,NC]
</IfModule>
Додавання заголовків безпеки через .htaccess
HTTP-заголовки безпеки — це часто ігнорований рівень захисту, який .htaccess може впроваджувати без будь-якого плагіна:
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>
Для Content Security Policy (CSP) значення заголовка має бути адаптоване до конкретних джерел ресурсів вашого сайту — загальний CSP порушить вбудовані скрипти та сторонні вставки.
Оптимізація продуктивності
Увімкнення стиснення Gzip за допомогою mod_deflate
Стиснення Gzip зменшує розмір відповідей HTML, CSS та JavaScript на 60–80%, безпосередньо покращуючи Time to First Byte (TTFB) та показники Core Web Vitals:
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml

    # Remove browser bugs for older clients
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    Header append Vary User-Agent
</IfModule>
Не стискайте вже стиснені формати: image/jpeg, image/png, image/gif, image/webp, application/zip, application/pdf. Спроба їх стиснення марно витрачає цикли CPU і може фактично збільшити розмір відповіді.
Кешування браузера за допомогою mod_expires
Кешування браузера інструктує браузери повторних відвідувачів обслуговувати статичні ресурси з локального кешу, а не повторно завантажувати їх з вашого сервера:
<IfModule mod_expires.c>
    ExpiresActive On

    # Images
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Fonts
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType application/font-woff "access plus 1 year"

    # CSS and JavaScript
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"

    # HTML and XML (short cache — content changes frequently)
    ExpiresByType text/html "access plus 1 hour"
    ExpiresByType application/xml "access plus 1 hour"
    ExpiresByType application/rss+xml "access plus 1 hour"

    # Default fallback
    ExpiresDefault "access plus 1 month"
</IfModule>
Щодо анулювання кешу: Тривалий термін кешування для CSS та JS означає, що браузери не отримають оновлення до закінчення терміну кешу. Використовуйте версійні імена файлів або рядки запиту (наприклад, style.css?ver=2.1) — функція wp_enqueue_style() WordPress обробляє це автоматично через параметр $ver.
Заголовки Cache-Control для детального керування
mod_expires встановлює заголовок Expires. Для відповідності сучасним HTTP/1.1 та HTTP/2 також явно встановіть Cache-Control:
<IfModule mod_headers.c>
    <FilesMatch ".(ico|jpg|jpeg|png|gif|webp|css|js|woff2|woff)$">
        Header set Cache-Control "max-age=31536000, public, immutable"
    </FilesMatch>
    <FilesMatch ".(html|php)$">
        Header set Cache-Control "max-age=3600, must-revalidate"
    </FilesMatch>
</IfModule>
Директива immutable повідомляє підтримуваним браузерам (Firefox, Chrome) не ревалідувати ресурс протягом його терміну дії, повністю усуваючи умовні GET-запити.
Увімкнення Keep-Alive
Постійні з’єднання зменшують накладні витрати на TCP-рукостискання для кількох ресурсів на одній сторінці:
<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>
Порівняння: .htaccess проти конфігурації на основі плагінів




Можливість
Директива .htaccess
Еквівалент плагіна WordPress
Вплив на продуктивність




Перезапис URL
Правила mod_rewrite
Yoast SEO, Redirection
.htaccess швидший (без накладних витрат PHP)


Стиснення Gzip
mod_deflate
WP Super Cache, W3 Total Cache
.htaccess швидший (на рівні Apache)


Кешування браузера
mod_expires
WP Rocket, LiteSpeed Cache
.htaccess швидший (на рівні Apache)


Блокування IP
Deny from
Wordfence, iThemes Security
.htaccess швидший (до PHP)


Заголовки безпеки
mod_headers
Плагін HTTP Headers
.htaccess швидший (на рівні Apache)


Захист wp-login.php
Блок <Files>
Limit Login Attempts Reloaded
.htaccess швидший (до PHP)


Content Security Policy
mod_headers
CSP-плагіни
Еквівалентно — обидва впроваджують заголовки


Перенаправлення на основі бази даних
Не застосовується
Плагін Redirection
Плагін виграє для великих наборів перенаправлень


Керування через GUI
Не застосовується
All In One WP Security
Плагін виграє для нетехнічних користувачів




Ключове архітектурне розуміння: Правила .htaccess виконуються на рівні модуля Apache, до виклику PHP. Це означає, що заблокований запит практично не витрачає ресурсів сервера. Блокування на основі плагіна повинно завантажити WordPress, завантажити плагін, а потім відхилити запит — споживаючи в 10–50 разів більше пам’яті та CPU на кожне заблоковане звернення. На сайтах з великим трафіком під атакою ботів ця різниця є межею між збереженням роботи та збоєм.
Захист чутливих директорій
Блокування директорії wp-includes
Директорія wp-includes ніколи не повинна обслуговувати PHP-файли безпосередньо браузерам:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-includes/[^/]+.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
Обмеження доступу до директорії Uploads
Директорія wp-content/uploads/ повинна обслуговувати медіафайли, але ніколи не виконувати PHP. PHP-файл, завантажений через вразливий плагін та виконаний з цієї директорії, є класичним вектором атаки веб-шелу:
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch ".php$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>
Якщо ви користуєтесь Спільним веб-хостингом і не можете використовувати блоки <Directory> у .htaccess, створіть окремий файл .htaccess всередині wp-content/uploads/ з таким вмістом:
<FilesMatch ".php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>
Власні сторінки помилок
Замініть стандартні сторінки помилок Apache на брендовані, зручні для користувача альтернативи:
ErrorDocument 400 /400.html
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
Для WordPress сторінка 404 зазвичай обробляється маршрутизацією index.php до шаблону 404.php теми — але наявність статичного резервного варіанту для помилок 500 є цінною, оскільки 500 означає, що сам PHP може бути зламаний.
Конфігурація .htaccess для WordPress Multisite
WordPress Multisite вимагає іншого блоку перезапису залежно від того, чи використовуєте ви структуру мережі на основі піддиректорій або піддоменів.
Multisite на основі піддиректорій:
# BEGIN WordPress Multisite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]

# Uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# Add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress Multisite
Multisite на основі піддоменів вимагає конфігурації підстановочного DNS на рівні реєстратора домену — одна лише зміна .htaccess є недостатньою. Якщо ви керуєте власним DNS, це обробляється через панель DNS вашого провайдера реєстрації доменів за допомогою підстановочного запису A (*.yourdomain.com).
Розширені техніки: обмеження швидкості та фільтрація запитів
Блокування поширених шаблонів атак у рядках запиту
<IfModule mod_rewrite.c>
RewriteEngine On

# Block SQL injection attempts
RewriteCond %{QUERY_STRING} (union.*select|select.*from|insert.*into|drop.*table) [NC]
RewriteRule .* - [F,L]

# Block script injection
RewriteCond %{QUERY_STRING} (<script|javascript:|vbscript:) [NC]
RewriteRule .* - [F,L]

# Block base64 encoded payloads in query strings
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC]
RewriteRule .* - [F,L]
</IfModule>
Важливе застереження: Ці шаблони regex є корисним першим рівнем, але не є заміною Web Application Firewall (WAF). Досвідчені зловмисники використовують варіації кодування, які обходять просте зіставлення рядків. Ставтеся до цих правил як до фільтра шуму, а не до комплексного захисту.
Обмеження методів запиту
WordPress потребує лише GET, POST та HEAD. Заблокуйте всі інші HTTP-методи:
<LimitExcept GET POST HEAD>
    Order Deny,Allow
    Deny from all
</LimitExcept>
Найкращі практики та операційна дисципліна
Перед кожним редагуванням:

Завантажте поточний .htaccess на свій локальний комп’ютер як датований резервний файл (наприклад, htaccess-backup-2025-01-15.txt).
Спочатку протестуйте зміну в тестовому середовищі, якщо воно доступне.
Вносьте одну логічну зміну за раз — ніколи не об’єднуйте кілька непов’язаних директив в одну сесію редагування.

Після кожного редагування:

Перезавантажте Apache, щоб підтвердити правильність синтаксису перед тестуванням у браузері:

apachectl configtest

Якщо configtest пройшов, виконайте плавне перезавантаження:

systemctl reload apache2

Протестуйте конкретну функціональність, яку ви змінили, а потім виконайте повну перевірку сайту за допомогою інструменту на кшталт curl -I https://yourdomain.com для перевірки заголовків відповіді.

Перевірка синтаксису без доступу до сервера:
apachectl -t -f /path/to/.htaccess
На Виділених серверах, де ви контролюєте конфігурацію Apache, розгляньте можливість переміщення критичних для продуктивності директив з .htaccess до конфігурації віртуального хоста (блок <VirtualHost> у httpd.conf або окремий конфігураційний файл сайту). Apache читає .htaccess при кожному запиті, коли увімкнено AllowOverride — переміщення директив до основної конфігурації повністю усуває ці накладні витрати на кожен запит.
Усунення поширених помилок .htaccess
Внутрішня помилка сервера 500
Найпоширенішою причиною є синтаксична помилка в .htaccess. Журнал помилок Apache міститиме точний номер рядка:
tail -n 50 /var/log/apache2/error.log
Поширені синтаксичні помилки:

Відсутній закриваючий тег </IfModule>

Петля перенаправлення

Петля перенаправлення (ERR_TOO_MANY_REDIRECTS) зазвичай виникає, коли:

• Ваше правило перенаправлення HTTPS не коректно визначає, що з’єднання вже є захищеним
• У вас є конфліктуючі правила перенаправлення в .htaccess та в налаштуваннях WordPress (Налаштування > Загальні URL)
• CDN або проксі видаляє змінну сервера HTTPS

Діагностика:

curl -I -L http://yourdomain.com 2>&1 | grep -E "HTTP|Location"

Правила перезапису не працюють

Якщо правила mod_rewrite здаються неефективними:

1. Підтвердіть, що mod_rewrite увімкнено: apache2ctl -M | grep rewrite
2. Підтвердіть, що AllowOverride All (або принаймні AllowOverride FileInfo) встановлено в конфігурації віртуального хоста для вашої кореневої директорії документів
3. Підтвердіть, що RewriteEngine On з’являється перед будь-якими RewriteRule в тому самому контексті

Сторінки повертають помилку 403 Forbidden після додавання обмежень IP

Якщо ви заблокували себе, додавши правило обмеження IP з помилкою у власній IP-адресі, отримайте доступ до файлу через File Manager панелі керування хостингом (який працює на рівні файлової системи, обходячи Apache) та виправте або видаліть правило.

Матриця рішень: коли використовувати .htaccess проти альтернатив

Контрольний список ключових технічних висновків

• Розміщуйте всі власні директиви поза маркерами # BEGIN WordPress / # END WordPress — вище або нижче, але ніколи всередині.
• Перевіряйте, що кожна обгортка <IfModule> відповідає модулю, який фактично завантажено на вашому сервері, перед розгортанням.
• Завжди встановлюйте дозволи файлу .htaccess на 644 — ніколи 666 або 777.
• Захищайте wp-config.php, сам .htaccess, xmlrpc.php та wp-includes/*.php явними правилами заборони.
• Використовуйте mod_deflate для стиснення та mod_expires з Cache-Control: immutable для статичних ресурсів — ці дві зміни самі по собі можуть суттєво покращити показники Core Web Vitals.
• Примусово застосовуйте HTTPS на рівні .htaccess, а не лише в налаштуваннях WordPress, щоб перехоплювати запити до завантаження PHP.
• На VPS або виділених середовищах переносьте стабільні директиви з .htaccess до конфігурації віртуального хоста, щоб усунути парсинг файлу при кожному запиті.
• Робіть резервну копію .htaccess з датованим іменем файлу перед кожною сесією редагування та перевіряйте синтаксис за допомогою apachectl configtest після кожної зміни.
• Створіть окремий .htaccess всередині wp-content/uploads/, який блокує виконання PHP — це єдине правило закриває критичний вектор атаки веб-шелу.
• Ставтеся до правил безпеки .htaccess як до рівня зменшення шуму, а не до повноцінного WAF — поєднуйте їх з інструментами на рівні сервера, такими як ModSecurity або WAF на основі CDN, для виробничих середовищ.

Часті запитання

Чи потрібно перезапускати Apache після редагування .htaccess?

Ні. Apache читає .htaccess при кожному HTTP-запиті, коли увімкнено AllowOverride, тому зміни набувають чинності негайно без перезапуску сервера. Однак настійно рекомендується запускати apachectl configtest до та після редагування, щоб виявити синтаксичні помилки до того, як вони спричинять помилку 500 у виробничому середовищі.

Чи будуть правила .htaccess працювати на серверах Nginx?

Ні. .htaccess є механізмом, специфічним для Apache. Nginx взагалі не читає файли .htaccess. Еквівалентні правила мають бути написані в блоках server {} або location {} в основному конфігураційному файлі Nginx. Багато керованих хостингів WordPress використовують Nginx та обробляють правила перезапису на рівні конфігурації сервера, що робить .htaccess нерелевантним на таких платформах.

Яка вартість продуктивності використання .htaccess?

Коли увімкнено AllowOverride, Apache перевіряє наявність файлу .htaccess в кожній директорії від кореневої директорії документів до запитуваного файлу при кожному запиті. На сайті з глибокою структурою директорій це може означати 4–6 зчитувань файлової системи на запит. На сайтах з великим трафіком переміщення директив до конфігурації віртуального хоста та встановлення AllowOverride None повністю усуває ці накладні витрати.

Чи можуть правила .htaccess конфліктувати з налаштуваннями постійних посилань WordPress?

Так. Найпоширеніший конфлікт виникає, коли власний RewriteRule заважає шаблону фронт-контролера WordPress. Завжди розміщуйте власні правила перезапису вище блоку # BEGIN WordPress, щоб вони оцінювалися першими, та тестуйте всі структури постійних посилань після додавання будь-якої нової логіки перезапису.

Як налагодити правило .htaccess, яке не працює так, як очікується?

Тимчасово увімкніть журналювання mod_rewrite Apache у конфігурації вашого віртуального хоста за допомогою LogLevel alert rewrite:trace3, потім відтворіть запит та перевірте /var/log/apache2/error.log. Вивід трасування показує точно, які умови були оцінені, які правила збіглися та яким був кінцевий перезаписаний URL. Негайно вимкніть журналювання трасування після налагодження — воно генерує надзвичайно детальний вивід та впливає на продуктивність.