Файл .htaccess дозволяє налаштовувати Apache прямо в папці сайту без доступу до конфігурації сервера. Він знаходиться в public_html/.
301 редиректи
RewriteEngine On
# Зі старої сторінки на нову
Redirect 301 /old-page.html /new-page
# Редирект усієї папки
RedirectMatch 301 ^/old-section/(.*)$ /new-section/$1
www ↔ без www
RewriteEngine On
# Перенаправити ВСІ запити на www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
# Або навпаки — прибрати www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
HTTP → HTTPS редирект
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Захист папки паролем
# Створіть файл .htpasswd:
# htpasswd -c /home/user/.htpasswd adminuser
# У .htaccess папки:
AuthType Basic
AuthName "Protected Area"
AuthUserFile /home/user/.htpasswd
Require valid-user
Блокування IP-адрес
# Заблокувати конкретний IP
Deny from 203.0.113.42
# Дозволити тільки свій IP
Order deny,allow
Deny from all
Allow from 203.0.113.10
Кешування статичних файлів
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>
Порядок правил має значення
Якщо об'єднати редирект на HTTPS і додавання www в одному файлі бездумно, легко отримати подвійний редирект або зациклення — Apache застосовує правила по порядку зверху вниз і зупиняється лише на першому спрацьованому прапорці L.
# Правильний порядок: спершу HTTPS, потім www,
# щоб браузер не робив два окремих редиректи поспіль
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
Обидві умови ведуть на ту саму підсумкову адресу з www і HTTPS одночасно — так браузер отримує один редирект замість двох послідовних.
Безпечне тестування правил
Кожну серйозну зміну перевіряйте зі збереженою резервною копією поруч — правило можна відкотити миттєво, не чекаючи відновлення з панелі хостингу.
# Перед правкою зберегти робочу копію
cp .htaccess .htaccess.bak
# Якщо сайт впав з 500 після правки — повернути попередню версію однією командою
cp .htaccess.bak .htaccess
Типові помилки в .htaccess
| Симптом | Причина |
|---|---|
| 500 Internal Server Error одразу після збереження | Синтаксична помилка в директиві: пропущено пробіл між RewriteCond і шаблоном, зайва лапка або невірний прапорець на кшталт [R=301,L,X] |
| RewriteRule: bad flag delimiters | Прапорці у квадратних дужках записані без коми між ними або із зайвим пробілом усередині дужок |
| ERR_TOO_MANY_REDIRECTS у браузері | Правило www ↔ без www і HTTP → HTTPS конфліктують за порядком, особливо якщо на Cloudflare вже увімкнено Flexible SSL і повторне правило перенаправляє туди-сюди |
| Invalid command 'ExpiresActive' | Директива використовується без обгортки <IfModule mod_expires.c>, а модуль на акаунті вимкнений — Apache не розуміє команду і падає з 500 |
| Basic Auth не запитує пароль | Файл .htpasswd вказано невірним абсолютним шляхом або у нього немає прав на читання процесом Apache |
Коли .htaccess не підходить
- Сайт працює на Nginx — .htaccess читає лише Apache, для Nginx правила переписуються в конфіг віртуального хоста на боці провайдера
- Правил стає багато і вони лежать у підпапках — при AllowOverride All Apache сканує дерево директорій на кожен запит, що помітно сповільнює відповідь
- Потрібно змінити налаштування, не дозволені в AllowOverride (ліміти процесу, модулі ядра) — .htaccess перевизначає лише те, що явно відкрито хостингом
- Зміни треба застосувати одразу до сотень доменів — тримати ідентичний файл у кожній папці незручно, синхронізація легко розходиться
Перевірка результату
Після правки завжди перевіряйте реальну HTTP-відповідь, а не лише вигляд сторінки в браузері — код відповіді видно не завжди, особливо якщо спрацював кеш. Якщо правила редиректу пов'язані з переходом на HTTPS, див. також статтю про налаштування HTTPS-редиректу; при помилці 500 розбір причин — у статті про діагностику error_log.
# Перевірити код відповіді та адресу призначення редиректу
curl -I http://example.com/old-page.html
# Переконатися, що заголовки кешування застосувалися до статики
curl -I https://example.com/style.css | grep -i cache-control