telegram

Что такое RewriteRule: примеры, синтаксис модуля Apache Mod Rewrite

RewriteRule

RewriteRule — это директива модуля Apache Mod Rewrite, которая позволяет на лету переписывать URL-адреса согласно заданным правилам, а сам mod_rewrite работает через файл .htaccess и даёт вебмастеру полный контроль над тем, как сервер обрабатывает запросы посетителей.

За 20 лет в продвижении сайтов я вывел сотни ресурсов в топ Яндекса и Google, и могу сказать с уверенностью: без понимания синтаксиса RewriteRule и примеров RewriteRule серьёзная работа с ЧПУ, редиректами и защитой просто невозможна.

Разберёмся в теме подробно, без воды, с реальными рабочими инструкциями.

Содержимое:

Что такое Apache Mod Rewrite и зачем он нужен

Apache Mod Rewrite — это один из самых мощных модулей веб-сервера Apache. Он включён по умолчанию почти на всех хостингах, но по умолчанию ничего не делает. Чтобы он заработал, нужно написать правила в файле .htaccess (или в конфигурации виртуального хоста).

Зачем вообще нужен mod_rewrite:

  • Создание красивых ЧПУ (человекопонятных URL) вместо index.php?id=15&cat=3
  • Настройка 301-редиректов со старых страниц на новые
  • Объединение дублей с www и без www, с http и https
  • Скрытие реальных путей к файлам и скриптам
  • Защита от хотлинкинга изображений
  • Блокировка ботов, парсеров и вредоносных запросов
  • Перенаправление на страницу 404 при некорректных URL

Важный нюанс: если ваш сайт работает на Nginx, а не на Apache, то mod_rewrite там не используется — вместо него применяются директивы rewrite и location в конфиге Nginx. Синтаксис другой, логика похожая. Узнайте: DeepSeek R2: что это за модель ИИ, как она работает и что дает.

Синтаксис RewriteRule: разбираем по косточкам

Базовая конструкция правила выглядит так:

RewriteRule шаблон подстановка [флаги]

Разберём каждую часть.

Шаблон (pattern)

Это регулярное выражение, которое применяется к части URL после доменного имени. Сервер сравнивает запрошенный путь с шаблоном и, если есть совпадение, выполняет подстановку.

Примеры шаблонов:

  • ^old-page\.html$ — точное совпадение со строкой old-page.html
  • ^products/([0-9]+)$ — захватывает число после products/
  • ^blog/(.*)$ — захватывает всё, что идёт после blog/

Специальные символы в регулярках:

Символ Значение
^ Начало строки
$ Конец строки
. Любой символ
\. Точка как literal
() Группировка и захват
[] Набор символов
+ Одно и более повторений
* Ноль и более повторений
? Ноль или одно повторение

Подстановка (substitution)

То, во что превратится URL после обработки. Здесь можно использовать захваченные группы из шаблона через $1, $2 и так далее.

Пример:

RewriteRule ^products/([0-9]+)$ /product.php?id=$1 [L]

Запрос site.com/products/42 превратится в site.com/product.php?id=42, но в адресной строке пользователь увидит красивый URL.

Флаги

Флаги пишутся в квадратных скобках через запятую и меняют поведение правила. Самые важные:

  • [L] (Last) — последнее правило, дальше обработка не идёт. Почти всегда нужен.
  • [R=301] — постоянный редирект. Для SEO это основной флаг.
  • [R=302] — временный редирект. Используйте осторожно.
  • [NC] (No Case) — игнорировать регистр.
  • [QSA] (Query String Append) — добавить существующие GET-параметры к новому URL.
  • [NE] (No Escape) — не экранировать спецсимволы.
  • [F] (Forbidden) — вернуть код 403.
  • [G] (Gone) — вернуть код 410 (страница удалена навсегда).
  • [PT] (Pass Through) — передать обработанный URL дальше.

Apache Mod Rewrite

Условия RewriteCond: логика «если»

Часто одного шаблона мало — нужно учитывать дополнительные условия: существует ли файл, какой домен запрошен, с какого сайта пришёл пользователь. Для этого используется RewriteCond.

Синтаксис:

RewriteCond строка_для_проверки условие
RewriteRule ...

Условие применяется к правилу, которое идёт сразу после него. Можно писать несколько условий подряд — они связываются логическим «И» (по умолчанию) или «ИЛИ» (с флагом [OR]).

Примеры условий:

  • %{REQUEST_FILENAME} !-f — файл не существует
  • %{REQUEST_FILENAME} !-d — директория не существует
  • %{HTTP_HOST} ^www\.(.*)$ [NC] — запрошен домен с www
  • %{HTTPS} !on — соединение не защищённое
  • %{HTTP_REFERER} !^https://(www\.)?mysite\.com — запрос не с нашего сайта

Переменные, которые часто используются:

  • %{REQUEST_URI} — запрошенный путь
  • %{QUERY_STRING} — GET-параметры
  • %{HTTP_HOST} — домен
  • %{HTTP_USER_AGENT} — браузер пользователя
  • %{REMOTE_ADDR} — IP-адрес посетителя
  • %{HTTPS} — статус SSL

Практические примеры RewriteRule для реальных задач

Перейдём к конкретике. Ниже — рабочие примеры, которые я использую на проектах.

1. Редирект с www на без-www (или наоборот)

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

Обратный вариант (добавить www):

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

Совет: выберите один вариант и придерживайтесь его везде. Смешанные редиректы создают петли.

2. Принудительный HTTPS

RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Если хостинг работает через прокси (Cloudflare, например), используйте:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

3. ЧПУ для каталога товаров

RewriteRule ^catalog/([a-z0-9-]+)/?$ /catalog.php?category=$1 [L,QSA]
RewriteRule ^catalog/([a-z0-9-]+)/page-([0-9]+)/?$ /catalog.php?category=$1&page=$2 [L,QSA]

Теперь site.com/catalog/shoes/ и site.com/catalog/shoes/page-2/ работают красиво.

4. Редирект со старой страницы на новую

RewriteRule ^old-article\.html$ /new-article/ [R=301,L]

Массовый редирект целой директории:

RewriteRule ^blog/old-category/(.*)$ /blog/new-category/$1 [R=301,L]

5. Защита от хотлинкинга картинок

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?mysite\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

Вместо F можно подставить свою картинку-заглушку:

RewriteRule \.(jpg|jpeg|png|gif|webp)$ /images/no-hotlink.png [L]

6. Блокировка плохих ботов

RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|MJ12bot|DotBot) [NC]
RewriteRule ^ - [F,L]

Будьте аккуратны: некоторые боты приносят трафик. Блокируйте только тех, кто реально грузит сервер.

7. Запрет доступа к служебным файлам

RewriteRule ^\.htaccess$ - [F]
RewriteRule ^\.git - [F]
RewriteRule ^(wp-config\.php|xmlrpc\.php) - [F]

8. Красивый URL для статьи по slug

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([a-z0-9-]+)/?$ /article.php?slug=$1 [L,QSA]

Условия !-f и !-d гарантируют, что правило не сломает существующие файлы и папки.

9. Удаление .php из URL

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php [L]

Теперь site.com/about откроет about.php.

10. Обработка 404 через PHP

ErrorDocument 404 /404.php

Или через RewriteRule:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ /404.php [L]
Что такое RewriteRule

Типичные ошибки при работе с RewriteRule

За годы практики я видел сотни сломанных сайтов из-за неправильных правил. Вот самые частые грабли.

Ошибка 1. Бесконечный цикл редиректов.

Симптом: браузер выдаёт ERR_TOO_MANY_REDIRECTS. Причина — правило редиректа срабатывает на уже перенаправленный URL.

Решение: добавляйте условие, проверяющее, что редирект ещё не сделан:

RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Ошибка 2. Забытый флаг [L].

Без него сервер продолжит применять следующие правила, что приводит к непредсказуемым результатам. Почти всегда ставьте [L].

Ошибка 3. Неэкранированные точки в шаблоне.

^old-page.html$ — точка здесь означает «любой символ». Нужно писать ^old-page\.html$.

Ошибка 4. Конфликт с физическими файлами.

Если у вас есть папка /images/, а правило переписывает всё в /index.php, папка перестанет работать. Всегда добавляйте RewriteCond %{REQUEST_FILENAME} !-f и !-d.

Ошибка 5. Использование 302 вместо 301.

Для SEO критичен именно 301-й редирект. 302-й говорит поисковикам «это временно», и они не переносят вес страницы.

Ошибка 6. Потеря GET-параметров.

Если в исходном URL были параметры (?utm_source=...), без флага [QSA] они потеряются.

Как правильно тестировать правила

Никогда не пишите правила сразу на рабочем сайте. Последовательность такая:

  1. Локальный сервер. Разверните Apache локально (OpenServer, Denwer, Docker) и тестируйте на копии.
  2. Резервная копия .htaccess. Перед правками скачайте текущий файл.
  3. Проверка регулярных выражений. Используйте онлайн-тестеры вроде regex101.com — выбирайте flavor PCRE.
  4. Кэш браузера. После изменения 301-го редиректа браузер запоминает его надолго. Тестируйте в режиме инкогнито или очищайте кэш.
  5. Кэш CDN и прокси. Если сайт за Cloudflare — purge cache после изменений.
  6. Проверка кодов ответа. Используйте curl: curl -I https://site.com/old-url — смотрите HTTP/1.1 301 Moved Permanently.

Производительность: не злоупотребляйте

mod_rewrite — тяжёлый модуль. Каждое правило — это проверка регулярного выражения на каждый запрос. Десяток правил — нормально. Сотня — уже проблема.

Советы по оптимизации:

  • Используйте [L] — сервер не будет гонять URL по оставшимся правилам.
  • Объединяйте похожие правила в одно через (a|b|c).
  • Выносите статические правила (редиректы конкретных URL) в начало файла.
  • Для массовых редиректов лучше использовать RewriteMap — механизм, который подгружает таблицу соответствий из внешнего файла.

Пример с RewriteMap:

RewriteMap redirects txt:/var/www/redirects.txt
RewriteCond ${redirects:$1} ^(.+)$
RewriteRule ^(.*)$ %1 [R=301,L]

В файле redirects.txt просто список:

old-page /new-page
another-old /another-new

Это работает в разы быстрее, чем сотни отдельных RewriteRule.

RewriteRule в CMS: WordPress, Bitrix, OpenCart

В популярных CMS файл .htaccess уже содержит базовые правила. Вот типичные блоки.

WordPress:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Никогда не правьте этот блок вручную — WordPress его перезапишет. Свои правила добавляйте до # BEGIN WordPress.

1С-Битрикс:

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]

Здесь логика похожа, но используется urlrewrite.php, а настройки ЧПУ лежат в админке.

OpenCart:

RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
Синтаксис модуля Apache Mod Rewrite

Безопасность: что нельзя делать

Некоторые правила выглядят безобидно, но открывают дыры.

Никогда не пишите:

RewriteRule ^(.*)$ /index.php?path=$1 [L,QSA]

Без проверки вы передаёте в скрипт что угодно, включая ../../etc/passwd.

Всегда валидируйте входные данные на уровне PHP, а не только в .htaccess.

Ограничьте доступ к админке по IP:

RewriteCond %{REMOTE_ADDR} !^123\.45\.67\.89$
RewriteRule ^admin/ - [F,L]

Чек-лист перед выкладкой правил на продакшен

Перед тем как залить изменённый .htaccess на рабочий сайт, пройдите по пунктам:

  • Есть резервная копия предыдущего файла
  • Правила протестированы локально
  • Проверены коды ответа через curl или сервисы типа httpstatus.io
  • Нет циклических редиректов
  • Для SEO-редиректов используется [R=301,L]
  • Статические файлы (css, js, картинки) не ломаются
  • Админка CMS доступна
  • Формы на сайте отправляются (CSRF-токены, сессии)
  • Проверена работа в разных браузерах
  • Очистлен кэш CDN

Альтернативы и нюансы

Не все задачи стоит решать через mod_rewrite. Если у вас Nginx — используйте его нативный rewrite. Если сайт на PHP и правила сложные — иногда проще обрабатывать роутинг в самом приложении (через $_SERVER['REQUEST_URI']).

Кроме того, есть мнение, что излишнее увлечение .htaccess замедляет сервер. Это правда, но для большинства проектов с десятком правил разница незаметна. Проблемы начинаются, когда в файле сотни строк.

Ещё один момент: на shared-хостингах вы не всегда можете менять основной конфиг Apache. Иногда AllowOverride стоит в None, и .htaccess просто игнорируется. В таком случае просите хостера включить AllowOverride All для вашей директории. Узнайте что такое поисковый запрос.

Итоги и практические выводы

RewriteRule — это рабочий инструмент, а не магия. Поняв синтаксис, регулярные выражения и логику mod_rewrite, вы сможете решать 90% задач по управлению URL без привлечения программистов.

Главные мысли, которые стоит запомнить:

  • mod_rewrite работает через .htaccess или конфиг Apache
  • Синтаксис: RewriteRule шаблон подстановка [флаги]
  • Условия пишутся через RewriteCond до правила
  • Для SEO-редиректов всегда используйте [R=301,L]
  • Не забывайте про [QSA], если в URL могут быть GET-параметры
  • Тестируйте локально, а не на живом сайте
  • Не злоупотребляйте количеством правил

Apache Mod Rewrite остаётся актуальным инструментом даже в эпоху Nginx и современных фреймворков — там, где нужен гибкий контроль на уровне веб-сервера, ему нет равных. Начните с простых редиректов, постепенно усложняйте правила, и через пару недель вы будете писать их так же уверенно, как обычные CSS-селекторы.

Также по теме: