Модуль Apache mod_rewrite в приложении к SEO

В настоящее время одним из факторов, определяющих дружественность сайта поисковым системам, является использование так называемых псевдостатичных URL, а в идеале - ещё более узкого понятия, ЧПУ, т.е. человеко-понятных URL. В общих чертах, суть можно объяснить в одном абзаце.

Многие web-движки используют URL следующего вида:

www.site.com/index.php?param1=value1&param2=value2

т.е. фактически используется одна web-страница с различными GET-параметрами. Для целей поискового продвижения наиболее предпочтительным является вариант сайта с большим количеством страниц и с URL, соответственно, вида:

www.site.com/param1-value1/param2-value2/

(здесь, безусловно, могут быть различные варианты). Как говорилось выше, идеальным вариантом псевдастатичных URL являются ЧПУ. То есть, если сайт занимается продажей автомобилей, то оптимальными будут URL вида:

www.site.com/autos/audi/a8/black/

Такие пути хороши для SEO, и пользователь не заблудится: вся структура сайта проста и понятна.

Как правило, для создания псевдостатичных URL используется модуль Apache mod_rewrite. Для IIS также есть аналогичные механизмы, однако далее мы будем говорить о связке Apache+PHP.

Помимо всего прочего, mod_rewrite делает, по сути, очень простую вещь: он отрабатывает после того, как сервер получил HTTP-запрос и до того, как выполнится соответствующий серверный скрипт. Суть работы mod_rewrite - это изменение запрошенного URL по определённому правилу.

Как правило, директивы mod_rewrite прописываются в файле .htaccess, но могут быть внесены и в httpd.conf. Впрочем, если у Вас не выделенный сервер, ни один хостер не разрешит править httpd.conf.

Если движок сайта строится с нуля, то ситуация достаточно простая. Достаточно частый случай, когда весь вывод контента осуществляется одним и тем же скриптом index.php, которому методом GET передаются определённые параметры:

www.site.com/index.php?par1=val1&par2=var2

Для дальнейшей простоты обработки рекомендуется, чтобы все URL содержали одни и те же параметры в одном и том же порядке, а значения параметров были регистро-независимыми и, оптимально, содержали символы из достаточно ограниченного набора (например, только цифры и строчные буквы латинского алфавита). Далее, алгоритм движка строится таким образом, чтобы все внутренние URL формировались как

www.site.com/val1/val2/

И заключительный этап: в корневую директорию сайта помещается файл .htaccess (либо редактируется существующий) со следующим содержимым:

 Options +FollowSymLinks
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteEngine On
 RewriteRule ^([^/]+)/([^/]+)/?$ /index.php?par1=&par2= [QSA,L]

Вуаля. Теперь сервер, получив запрос

www.site.com/val1/val2/

, передаст эту строку mod_rewrite. Тот, в свою очередь, произведёт разбор строки согласно указанному регулярному выражению и передаст видоизменённый запрос на дальнейшую обработку. Также использован флаг QSA (Query String Attachment): если вдруг вместе в переданном URL будут указаны какие-либо GET-параметры, то mod_rewrite передаст их обработчику без изменения. В примере описан общий случай, который не позволяет экономить вычислительные ресурсы: регулярные выражения довольно требовательны. Именно поэтому и предлагаются ограничения на параметры: вместо квантификатора [^/]+ можно указать [a-z0-9]+. Данная статья не ставит своей целью описание синтаксиса .htaccess, директив Apache и регулярных выражений: на эту тему существует достаточно хорошей документации, ссылки на которую можно найти в конце статьи.

Однако оптимизатору достаточно часто приходится сталкиваться с ситауцией, когда сайт уже сделан, отлажен и работает на уже существующем движке: быть может, очень хорошем, но для нужд поисковой оптимизации малоприемлемым. И очень часто принципы формирования URL не соответствуют описанным выше: параметры могут следовать в произвольном порядке, их количество может меняться, и т.п. Эти проблемы, в принципе, хорошо разрешаются соответствующим усложнением регулярного выражения. Однако если движок жёстко требует регистрозависимые значения параметров и при нарушении этого отказывается работать, описанным выше методом обойтись нельзя: дело в том, что по какой-то причине в mod_rewrite передача символов через переменные регулярных выражений (, и т.п.) происходит с выравниванием регистра. Иными словами, если будет запрошен адрес вида

www.site.com/Value1/vAlUe2/

, то строка запроса будет преобразована в

www.site.com/index.php?par1=value1&par2=value2

. Для многих движков это является критичным.

К сожалению, причины вышеописанного лично мне неясны. Заставить mod_rewrite сохранять регистр у меня так и не получилось, поэтому на помощь пришлось призвать PHP. В .htaccess было прописано перенаправление любого пути на index.php:

RewriteRule ^(.*)$ /index.php [QSA]

Методика формирования URL была изменена на следующую:

www.site.com/par1.val1/par2.val2/

В принципе, вместо точки можно брать любой символ, который гарантированно не будет встречаться в названиях и значениях параметров. Далее, в самое начало index.php был добавлен фрагмент кода, подобный вот такому:

 
$arr = explode('/',$_SERVER['REQUEST_URI']);
 foreach ($arr as $pair) {
   if ($pair!="") {
     $unpair = explode('.',$pair);
     $_GET[$unpair[0]] = $unpair[1];
   }
 }
 extract($_GET); 

Вышеприведённый фрагмент разбирает по разделителям GET-строку, формируя пары обычных GET-параметров.

Этот же приём можно использовать, когда код движка слишком сложен для правки, количество и названия параметров могут с течением времени изменяться - в общем, в крайних случаях. Плюс этого метода в его универсальности, минус - в том, что URL становятся псевдостатичными, но не человекопонятными.

Конечно, при переводе на псевдостатичные URL уже проиндексированного сайта, следует соблюдать правила хорошего тона. В частности, очень хорошим шагом будет настройка сервера на переадресацию клиента, пришедшего по ставрому адресу (с GET-параметрами) на аналогичную страницу с псевдостатичным адресом, причём переадресацию лучше всего делать по коду 301 (Moved Permanently). Это позволит поисковым системам быстрее внести коррективы в свои индексы.

Вообще же при работе с mod_rewrite следует чётко понимать, как работает то или иное регулярное выражение: неправильно составленные правила могут повлечь за собой множество неприятностей, от бесполезной траты вычислительных мощностей сервера до зацикливания некоторых запросов и отказа в обслуживании. И следует помнить о безопасности: каждый новый используемый модуль - это потенциальная уязвимость. В частности, на момент написания статьи мне известна как минимум одна такая проблема.


Ссылки на материалы, имеющие отношение к теме статьи:

Дмитрий Кожемяченко

При перепечатке статьи ссылка на seobility.by обязательна.

Наши Клиенты
  • www.belbohemia.com
    www.belbohemia.com
  • www.tut.by
    www.tut.by
  • www.hoster.by
    www.hoster.by
  • www.mtbank.by
    www.mtbank.by
  • www.sity.by
    www.sity.by
  • www.opel.by
    www.opel.by
  • www.volna.by
    www.volna.by
  • www.daroo.by
    www.daroo.by
  • www.dewpoint.by
    www.dewpoint.by
  • www.bulbash.com
    www.bulbash.com
  • www.schneider-electric.by
    www.schneider-electric.by
  • www.uruchie.by
    www.uruchie.by
  • reebok.tam.by
    reebok.tam.by
  • www.minsk-lada.by
    www.minsk-lada.by
  • www.keramin.by
    www.keramin.by
  • www.adidas-zamok.tam.by
    www.adidas-zamok.tam.by
  • www.svyaznoy.by
    www.svyaznoy.by
  • fizcult.by
    fizcult.by
  • www.priorbank.by
    www.priorbank.by
  • jobs.tut.by
    jobs.tut.by
  • www.nissan-belarus.by
    www.nissan-belarus.by
  • www.irr.by
    www.irr.by
  • www.eshko.by
    www.eshko.by
  • www.rcmtrucks.by
    www.rcmtrucks.by
  • www.ehu.lt
    www.ehu.lt
  • www.argument.by
    www.argument.by
  • www.ssangyong.by
    www.ssangyong.by
  • www.megatron.by
    www.megatron.by
  • www.mitso.by
    www.mitso.by