Файл .htaccess: что это, как настроить и какие задачи он решает

Где лежит файл и как он работает

Где находится .htaccess? Обычно файл лежит в корне сайта – тогда его правила работают на всем ресурсе. Положите его в подпапку – и директивы сработают только для нее и вложенных каталогов.

Несколько важных моментов про расположение:

• имя начинается с точки, поэтому файл скрытый – в FTP-клиенте включите показ скрытых файлов, иначе его не видно;
• файлов может быть несколько – каждый в своей папке;
• при конфликте правил ближний к странице файл перекрывает дальний, поэтому причину странного поведения ищут снизу вверх;
• если файла нет, создайте его обычным текстовым редактором – лучше Notepad++, а не Word, который добавляет лишние символы.

Работает это так: на каждый запрос Apache ищет .htaccess по пути к запрошенному файлу и применяет найденные директивы. На большинстве виртуальных хостингов использование .htaccess разрешено, хотя набор доступных директив зависит от настроек AllowOverride.

Есть и нюанс производительности. .htaccess сервер перечитывает на каждый запрос, поэтому на крупных проектах тяжелые правила выгоднее держать в основном конфиге, а файл оставлять под точечные задачи. На обычном сайте эта разница незаметна.

Синтаксис и комментарии

Структура простая: каждая директива пишется с новой строки, а многие группируются в блоки <IfModule …>, которые срабатывают, только если на сервере подключен нужный модуль. Комментарии начинаются с решетки – строки с # сервер игнорирует, и это удобно, чтобы подписывать, за что отвечает каждый кусок.

# редирект старой страницы на новую
Redirect 301 /old-page/ /new-page/

# строка ниже закрыта комментарием и не выполняется
# Redirect 301 /test/ /
    

Регистр в значениях важен, а лишние пробелы и пустые строки – нет. Главное правило: без необходимости файл лучше не трогать. Одна ошибка в синтаксисе может привести весь сайт в ошибку 500, поэтому перед любой правкой сохраняйте копию рабочего файла.

Длинный файл удобно делить на блоки по задачам и подписывать комментариями – через полгода это экономит время, когда приходится вспоминать, зачем нужна та или иная строка.

Редиректы и переадресация

Это самая частая задача, ради которой используют .htaccess, поэтому с того, как настроить редиректы, и начнем.

Редирект нужен, чтобы при смене адреса страницы, переезде на новый домен или переходе на защищенный протокол не потерять трафик и позиции. Поисковику важно понять, что страница не исчезла, а переехала, – для этого ставят 301 редирект, постоянную переадресацию.

Простой редирект с одной страницы на другую делается директивой Redirect из модуля mod_alias – она читается легче всего:

Redirect 301 /old-page/ https://site.ru/new-page/
    

Для гибких сценариев подключают mod_rewrite. Он включается директивой RewriteEngine On, а правила задаются парами «условие – действие». Классический пример – перевод всего сайта с http на https:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    

Здесь %{REQUEST_URI} – часть адреса после домена, которую сервер подставляет сам, чтобы пользователь попал на ту же страницу, только по https. Похоже склеивают зеркала сайта – например, убирают www, чтобы не плодить дубли:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
    

А при переезде на новый домен перенаправляют сайт целиком, сохраняя адреса всех страниц:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-site\.ru$ [NC]
RewriteRule ^(.*)$ https://new-site.ru/$1 [R=301,L]
    

Флаги в квадратных скобках уточняют правило: R=301 – это постоянная переадресация, а L – команда остановить обработку на этом правиле.

О чем еще стоит помнить при настройке редиректов:

• для постоянного переезда ставьте 301: он передает новому адресу накопленный вес ссылок, и позиции в поиске не обнуляются. Для временного перенаправления используют 302.
• не плодите цепочки: редирект на редирект замедляет загрузку и размывает эффект для SEO.
• проверяйте результат: откройте старые адреса вручную или прогоните список через инструмент проверки ответов сервера и убедитесь, что отдается именно 301.
• для условных правил используйте RewriteCond, например «срабатывать, только если запрос пришел по http».

И не дублируйте вручную то, что уже делает CMS: некоторые системы сами приводят адреса к единому виду, и лишнее правило только мешает.

Управление доступом к сайту и папкам

Через .htaccess удобно решать, кто вообще попадет на сайт или в конкретную папку.

Типичный случай – закрыть доступ к сайту на время разработки, оставив его только себе. Тут есть нюанс с версией Apache: в 2.4 (он сейчас почти везде) работает директива Require, а в старой 2.2 – связка Order и deny from all. Чтобы код работал на любом сервере, оба варианта оборачивают в проверку модуля:

<IfModule mod_authz_core.c>   # Apache 2.4
    Require all denied
</IfModule>
<IfModule !mod_authz_core.c>  # Apache 2.2
    Order Allow,Deny
    Deny from all
</IfModule>
    

Чаще нужно не закрыть все наглухо, а оставить доступ по IP – скажем, только из офиса:

<IfModule mod_authz_core.c> # Apache 2.4
    Require ip 203.0.113.10
</IfModule>
<IfModule !mod_authz_core.c> # Apache 2.2
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.10
</IfModule>
    

Всем, чьего IP нет в списке, сервер вернет ответ 403 – «доступ запрещен». Если же пускать нужно по логину, а не по адресу, настраивают доступ по паролю. Пароли хранят в отдельном файле .htpasswd, а в .htaccess указывают, где он лежит:

AuthType Basic
AuthName "Закрытая зона"
AuthUserFile /home/user/site/.htpasswd
Require valid-user
    

Сам .htpasswd с парами логин-пароль генерируют онлайн-сервисом или утилитой htpasswd и кладут вне публичной папки, чтобы его нельзя было скачать. Так удобно закрывать админку, стейджинг или раздел, который пока не готов к показу.

Те же правила работают и точечно. Чтобы закрыть не весь сайт, а конкретный файл, директивы оборачивают в блок <Files>, а для отдельной папки кладут свой .htaccess прямо в нее:

<Files "config.php">
    Require all denied
</Files>
    

Тем же способом отсекают назойливых ботов по User-Agent – нежелательный запрос отклоняется прямо на входе, а флаг [F] возвращает ответ 403:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} BadBot [NC]
RewriteRule ^ - [F]
    

Кэширование, страницы ошибок и другие возможности

Редиректами и доступом дело не ограничивается. Через .htaccess управляют и тем, как браузер хранит файлы сайта. Чаще кэш включают, чтобы ускорить загрузку: браузер запоминает картинки, стили и скрипты и не качает их заново при каждом заходе – это ускоряет повторные открытия страниц и косвенно улучшает поведенческие метрики. Отвечает за это модуль mod_expires:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 7 days"
    ExpiresByType text/css "access plus 7 days"
    ExpiresByType application/javascript "access plus 7 days"
</IfModule>
    

Бывает и обратная задача – запрет кэширования: например, пока идет разработка и важно сразу видеть свежую версию. Тогда браузеру явно указывают не хранить файлы:

<IfModule mod_headers.c>
    Header set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>
    

Что еще обычно настраивают в файле:

• свои страницы ошибок: директива ErrorDocument 404 /404.php отдает аккуратную страницу вместо стандартной;
• работу mod_rewrite и переходы по ссылкам – за это отвечает Options +FollowSymLinks;
• параметры PHP: php_value и php_flag меняют настройки для каталога, но работают только с модулем mod_php, а на PHP-FPM игнорируются;
• защиту служебных файлов и запрет листинга папок через Options -Indexes.

Список шире – сжатие, кодировки, защита картинок от хотлинка. Но 80% реальных задач это редиректы, доступ и страницы ошибок, остальное подключают по необходимости. Полезно прятать и сам .htaccess, чтобы его содержимое не утекло, – многие готовые конфиги делают это первым же блоком.

Файл .htaccess в Bitrix

На сайтах Bitrix .htaccess по умолчанию уже лежит в корне и не пустой. В нем зашит блок mod_rewrite, который отвечает за человекопонятные адреса (ЧПУ): все запросы, не ведущие на реальный файл или папку, он передает обработчику /bitrix/urlrewrite.php. Выглядит это примерно так:

Options -Indexes
ErrorDocument 404 /404.php


<IfModule mod_rewrite.c>
    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-l
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
    RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
</IfModule>
    

Помимо ЧПУ дефолтный файл включает кэширование статики через mod_expires и пару настроек PHP. Так что .htaccess для Bitrix пишут не с нуля – аккуратно дополняют готовый, не дублируя то, что система уже делает сама.

Если нужен редирект с www или склейка по https, его дописывают отдельным блоком выше строк ЧПУ – тогда Bitrix сначала приведет домен к нужному виду, а потом займется адресами.

Частые ошибки и как не уронить сайт

Файл мощный, но требует аккуратности. Вот что чаще всего приводит к проблемам:

• правка без бэкапа: любая опечатка в директиве дает ошибку 500 на всем сайте, а откатиться будет нечем;
• неверный порядок правил: редиректы и условия читаются сверху вниз, и общее правило может перехватить запрос раньше частного;
• копирование чужого кода под другой Apache: синтаксис доступа в 2.2 и 2.4 разный, и сниппет из старой статьи может не сработать;
• расчет на эффект там, где сервер на Nginx: файл просто не читается, и менять надо конфиг сервера.

Рабочая привычка простая: сохранили копию, внесли одно изменение, проверили сайт, и только потом следующее. Так любую ошибку видно сразу, и понятно, какая строка ее вызвала. И держите в уме площадку: то, что годами работает на одном хостинге, на другом ведет себя иначе из-за версии Apache и набора модулей.

Коротко о главном

.htaccess закрывает большую часть задач по поведению сайта на стороне сервера:

• редиректы при смене домена;
• защиту разделов;
• свои страницы ошибок;
• тонкую настройку кэша.

Большинство решается готовыми примерами, которые достаточно подставить под свои адреса. Главное – помнить про бэкап, версию Apache и то, что на Nginx файл не работает. Если правка касается боевого сайта и уверенности нет, безопаснее отдать ее разработчику. А начинать проще с малого: один редирект, одна проверка – и постепенно файл превращается в понятный набор правил под ваш проект. И держите под рукой главную страховку – свежий бэкап: с ним почти любая ошибка превращается в пятиминутный откат.