special

  1. HOME
  2. Для Сайта
  3. Редиректы в htaccess и в скриптах (301/302)

Редиректы в htaccess и сриптах (301/302)

Редиректы в htaccess (301/302)

301-ая ошибка (301 Permament Redirect), возвращаемая при обращении к определенному адресу страницы, означает, что сайт был на постоянной основе перенесен на новый адрес, также указанный в HTTP заголовке. Как пользователи, так и поисковые боты, зашедшие через браузер, будут перенаправляться по новому адресу, при этом, для поисковиков все свойства старого адреса (страницы) будут переданы новому URL.

Редирект 301 (moved permanently) это наилучший способ сохранить рейтинг сайта в поисковых системах при переносе его на новый домен или смене системы управления контентом. При 301 редиректе произойдет склейка старого и нового адресов: параметры вроде PageRank и тИЦ, а также вес страницы и ссылочный вес старого адреса будет передан новому URL.

Ниже даны наиболее используемые правила настройки файла .htaccess для 301 редиректа.

Внимание В правилах: %{QUERY_STRING} — обозначает фрагмент URL-адреса после знака вопроса (задания значений CGI-параметров).

Внимание Срабатывание того или иного правила для редиректа определяется тем, попадает URL-адрес страницы под это правило или нет.

Внимание О значении тех или иных обозначений (^, $, NC и т.д.) см. памятку в конце страницы.

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

Внимание Лучше размещать все правила после двух строк:

Options +FollowSymLinks
RewriteEngine On

301 редирект с домена без WWW на домен с WWW префиксом (главное зеркало – домен с www)

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

С домена с WWW префиксом на без (главное зеркало – домен без www)

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

Стандартная переадресация с одной статической страницы на другую

Redirect 301 /was.php http://www.site.ru/new.php

При этом, новый адрес указывать необходимо полностью с http и доменным именем.

В ряде случаев полезна переадресация через RewriteRule

RewriteRule ^dir /dir-new/$1 [R=301,L]

301 редирект для страницы с GET параметрами

Скажем, адрес страницы имеет вид: http://www.site.ru/dir/index.php?IBLOCK_ID=1&SECTION_ID=111 тогда для настройки 301 переадресации на новый адрес, необходимо использовать следующее правило:

RewriteCond %{QUERY_STRING} ^IBLOCK_ID=1&SECTION_ID=111$ [NC]
RewriteRule ^dir/index\.php$ /new/sef/? [R=301,L]

Если один (или несколько) из GET параметров не задан(ы) или может иметь произвольное значение (в нашем примере это SECTION_ID), можно использовать следующий код:

RewriteCond %{QUERY_STRING} ^IBLOCK_ID=1&SECTION_ID=(.*)$ [NC]
RewriteRule ^dir/index\.php$ /new/sef/? [R=301,L]

301 редирект только адреса site.ru/index.php (без GET параметров) на основное зеркало site.ru

RewriteCond %{REQUEST_URI} /index.php
RewriteCond %{QUERY_STRING} ^\z
RewriteRule ^(.*)$ http://site.ru/? [R=301,L]

301 редирект всех адресов с index.php и GET параметрами на страницы только с GET параметрами (вырезать в url index.php)

Пример: типа site.ru/index.php?n=1 на site.ru/?n=1

RewriteCond %{REQUEST_URI} /index.php
RewriteRule ^(.*)$ http://site.ru/ [R=301,L]

301 редирект url с GET параметрами (динамический URL) на статический

1 вариант (простой адрес с GET параметром)

RewriteCond %{QUERY_STRING} ^id=229
RewriteRule ^.*$ /supermodel/? [R=301,L]

2 вариант (со страницы и GET параметром)

RewriteCond %{REQUEST_URI} /test/
RewriteCond %{QUERY_STRING} ^id=229
RewriteRule ^.*$ /supermodel/? [R=301,L]

301 редирект для конкретного файла, а не целой папки

Если требуется настроить переадресацию только для адреса http://www.site.ru/dir/, но при этом чтобы страница http://www.site.ru/dir/index.php?IBLOCK_ID=1 открывалась по старому адресу, необходимо использовать спецсимвол $ в правиле.

RewriteRule ^dir/$ http://www.site.ru/new-dir/ [R=301,L]

Все страницы одного домена на главную страницу другого домена

RewriteCond %{REQUEST_URI} (.*)
RewriteRule ^(.*)$ http://site.ru/ [L,R=301]

Каждая страница одного домена на такой же адрес другого url

RewriteCond %{REQUEST_URI} (.*)
RewriteRule ^(.*)$ http://site.ru/$1 [L,R=301]

Как быть с доменами в зоне РФ?

Для доменов в зоне РФ действуют все те же правила, но только все кириллические символы необходимо заменить на альтернативный код (он на латинице). В частности, сама зона .рф преобразуется в .xn--p1ai.

301 редирект с домена на домен

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

301 редирект для домена в зоне РФ

RewriteCond %{HTTP_HOST} ^xn-...\.xn--p1ai$ [NC]
RewriteRule ^(.*)$ http://www.site.ru/$1 [R=301,L]

Настройка переадресации на папки со слешем в конце / (добавляем слеш в конце)

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\..{1,10}$
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://www.site.ru/$1/ [L,R=301]

301 редирект со страниц со слешем на без слеша (весь сайт)

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} ![^\/]$
RewriteRule ^(.*)\/$ /$1 [R=301,L]

Настройка переадресации на папки без слеша (убираем слеш в конце)

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^(.+)/$
RewriteRule ^(.+)/$ http://www.site.ru/$1 [R=301,L]

301 редирект со страниц без слеша на слеш (часто в CMS системах устанавливается автоматически)

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteRule ^(.*[^\/])$ /$1/ [R=301,L]

Один (а не два последовательных!) 301 редирект на без www и с слешем на конце адреса страницы

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

Один (а не два последовательных!) 301 редирект на c www и со слешем на конце адреса страницы

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

Один (а не два последовательных!) 301 редирект на c www и без слеша на конце адреса страницы

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

Один (а не два последовательных!) 301 редирект на без www и без слеша на конце адреса страницы

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

301 редирект с домена на папку на другом домене

RewriteCond %{HTTP_HOST} ^si-te\.ru$ [NC]
RewriteRule ^(.*)$ http://www.site.ru/si-te/ [R=301,L]

Редирект со всех файлов домена, кроме папки администратора bitrix

RewriteRule ^bitrix/ /bitrix/admin/ [L,R=301]
RewriteRule ^(.*)$ http://www.newsite.ru/new/ [L,R=301]

Редирект всех файлов в папке на заданный файл

RewriteRule ^dir(.*)$ /new-file.php [L,R=301]

Редирект файлов из заданной папки кроме, определенного файла

RewriteRule ^dir/no-file.html /no-file-new.html [L,R=301]
RewriteRule ^dir(.*)$ /all.php [L,R=301]

Смена страниц с html расширения на php расширение

RedirectMatch 301 (.*)\.html$ http://www.new-site.ru$1.php

Задание типа индексной страницы (php, html, htm и другие)

Указывается порядок загрузки типов индексного файла, лежащих в корне каталога.

DirectoryIndex index.html index.php index.htm index.shtml

Редирект с индексной страницы php на саму папку (корень)

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://www.site.ru/ [R=301,L]

Редирект с поддомена на основной домен второго уровня

RewriteCond %{HTTP_HOST} ^test.site.ru$ [NC]
RewriteRule ^(.*)$ http://site.ru%{REQUEST_URI} [R=301,NC,L,QSA]

Редирект для заданного файла в различных директориях (папках)

Код позволяет поставить 301-редирект со всех папок вида http://site.ru/***/uniqe-file.html на один файл в корне /unique-file.html. Бывает полезен при переделке сайта и изменении ссылок.

RewriteRule [^abc]/unique-file.html /unique-file.html [R=301,L]

Если требуется создать ЧПУ-копию какой-либо динамической страницы, то это можно также реализовать с помощью .htaccess

Код позволяет создать копию страницы с относительным адресом /studio/news/detail.php?ID=230354&PAGEN_2=11 по адресу /testovyi/test/.

RewriteRule ^testovyi/test/?$ /studio/news/detail.php?ID=230354&PAGEN_2=11 [NC,L]

Указание пути к файлу 404 ошибки с помощью .htaccess

Внимание, важно чтобы код ответа сервера для 404 ошибки был именно 404. Путь к файлу указывается с помощью следующей строчки:

ErrorDocument 404 /404-for-me.php

Редиректы на сервере Apache

Внимание Для сайтов, на которых используется не сервер Apache, аналогичные 301 редиректы легко настраиваются с помощью PHP.

<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.site.ru/dir/");
exit();
?>

Внимание Оптимально настраивать все редиректы сразу на конечную страницу (без промежуточных перенаправлений, в один шаг) это улучшает их восприятие со стороны поисковых систем и пользователей.

Если требуется настроить редирект только для некоторых USER_AGENT'ов, а не для всех пользователей

RewriteCond %{HTTP_USER_AGENT} (iPad|ipad|iphone|iPhone|ipod|iPod|android|midp|j2me|symbian|series\ 60|symbos|windows\ mobile|windows\ ce|ppc|smartphone|blackberry|mtk|bada|windows\ phone) [NC]
RewriteRule (.*) http://mobile.site.ru/ [L,R=301]

Если требуется настроить редирект для всех поисковых роботов (представлен список их USER_AGENT'ов)

RewriteCond %{HTTP_USER_AGENT} !(accoona|ia_archiver|antabot|ask\ jeeves|baidu|dcpbot |eltaindexer|feedfetcher|gamespy|gigabot|googlebot |gsa-crawler|grub-client|gulper|slurp|mihalism|msnbot|worldindexer |ooyyo|pagebull|scooter|w3c_validator|jigsaw|webalta|yahoofeedseeker |yahoo!\ slurp|mmcrawler|yandexbot|yandeximages |yandexvideo|yandexmedia|yandexblogs|yandexaddurl|yandexfavicons |yandexdirect|yandexmetrika|yandexcatalog|yandexnews |yandeximageresizer) [NC]
RewriteRule (.*) http://no-search.site.ru/ [L,R=301]

Несколько простых примеров

Переадресация с www.site.ru/component/content/?view=featured на www.site.ru/
RewriteCond %{QUERY_STRING} ^view=featured$ [NC]
RewriteRule ^component/content/?$ /? [R=301,L]
Переадресация с www.site.ru/index.php?idc=4&marea=6 на www.site.ru/
RewriteCond %{QUERY_STRING} ^idc=4&marea=6$ [NC]
RewriteRule ^index\.php$ /? [R=301,L]

Убираем все GET-параметры после знака вопроса (?)

RewriteRule (.*) $1? [R=301,L]
Располагать после: RewriteBase /

У главной страницы сайта site.ru всегда присутствует полный ее дубль по адресу site.ru/index.php

Redirect 301 /index.php http://site.ru/

Или

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://site.ru/ [R=301,L]

Если у вашего сайта несколько имен, но вы хотите, чтобы пользователи всегда видели в адресной строке основное имя сайта, используйте следующие строки сразу после RewriteEngine On:

RewriteCond %{HTTP_HOST} !^site.ru$
RewriteRule ^(.*) http://site.ru/$1 [R=301,L]

301 редирект на окончание .html (для тех у кого включен этот суффикс), перенаправит со страниц site.ru/article и site.ru/article/ на страницу site.ru/article.html

RewriteCond %{REQUEST_URI} (.*/[^/.]+)($|\?)
RewriteRule .* %1.html [R=301,L]
RewriteRule ^(.*)/$ /$1.html [R=301,L]

Или

REDIRECTMATCH 301 (.*/[^/.]+)($|\?)$ http://site.ru$1.html

Редирект с .html на без .html, т.е. с site.ru/article.html на site.ru/article (для тех кто сначала включил .html, а потом решил избавиться от него)

RewriteBase /
RewriteRule (.*)\.html$ $1 [R=301,L]

Или

REDIRECTMATCH 301 (.*)\.html$ http://site.ru$1

Редирект для страниц с параметрами, например со страницы site.ru/blog?limitstart=0 на site.ru/blog

RewriteCond %{QUERY_STRING} ^limitstart=0
RewriteRule ^blog http://site.ru/blog? [R=301,L]

Чтобы все страницы старого раздела перенаправлялись на те же страницы только нового раздела, например site.ru/blog/raznoe/article на site.ru/blog/article

RewriteRule ^blog/raznoe/(.*)$ http://site.ru/blog/$1 [R=permanent,L]

301 редирект с адреса без слеша на слеш, то есть с site.ru/article на site.ru/article/

RewriteCond %{REQUEST_URI} (.*/[^/.]+)($|\?)
RewriteRule .* %1/ [R=301,L]

Редирект со слеша на без слеша в конце, т.е. с site.ru/article/ на site.ru/article

RewriteRule ^(.*)/$ /$1 [R=301,L]

Еще вариант как избавиться от завершающего слеша на конце

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [R=301,L]

Вариант избавления от слэша для страниц с параметрами, на примере страниц с пагинацией site.ru/categoriya?start=5/

RewriteCond %{QUERY_STRING} ^start=(\d+)/
RewriteRule ^(.*) /$1?start=%1 [R=301,L]

Сначала забыли включить SEO в глобальных настройках, а потом включили, как итог - в индексе много документов с /index.php в адресе.

По такому же принципу можно избавиться от какой либо вложенности, например редиректить с site.ru/ru/catalog на site.ru/catalog (/ru/ убирается).

RewriteRule ^index.php/(.*)$ http://mysite.ru/$1 [R=permanent,L]

Запрет доступа для плохих ботов

SetEnvIfNoCase User-Agent "^Baiduspider" bad_bot
SetEnvIfNoCase User-Agent "^MSNBot" bad_bot
SetEnvIfNoCase User-Agent "^Baiduspider" bad_bot
SetEnvIfNoCase User-Agent "^Ezooms" bad_bot
# продолжите список сами, указывайте юзер-агент плохих ботов
Order Allow,Deny
Allow from all
Deny from env=bad_bot

Или robots.txt отдаёт, на остальное 404 (для юзер агент - Baiduspider и Ezooms )

RewriteCond %{HTTP_USER_AGENT} \b(Baiduspider|Ezooms)\b [NC]
RewriteCond %{REQUEST_URI} !^/robots\.txt [NC]
RewriteRule .* - [R=404]

Различные другие способы редиректа

Ниже даны аналогичные различные правила настроек для 301 редиректа.

Редирект с помощью скрипта (отправки заголовков)

Редирект запросов можно осуществлять также с помощью скриптов, отправляя клиенту необходимые заголовки.

HTTP/1.1 301 Moved Permanently
Location: http://www.newdomain.ru/newdir/newpage.htm

JavaScript редирект

Вот уж где нет предела творчеству и возможности "по изголяться". Варианты переадресации на JavaScript чаще реализуются с использованием функции setTimeout('функция', задержка).

Например, автоматически сделать Click на кнопке "Submit" формы "searchform" через 0.1 сек после загрузки кода:

setTimeout('document.forms["searchform"].Submit.click()', 100);

На кнопку "Submit" можно повесить любое действие, например, открыть новый url в этом окне. Кстати такое редиректы чаще встречаются при организации Дорвеев(DorWay) - броузер Пользователя будет переадресован на другую страницу, а поисковый робот, который "не понимает" JavaScript, будет индексировать ЭТУ страницу, недоступную Пользователю. На ней Дорвейщики размещают текст, напичканный "нужными" ключевыми словами.

Просто переадресовать на другую страницу - вставить после <body> код на JavaScript:

location="http://www.new.domain.ru";

или

document.location.href="http://www.new.domain.ru";

или

window.location.reload("http://www.new.domain.ru");

или

document.location.replace("http://www.new.domain.ru");

В последнем случае уже нельзя будет вернуться на страницу выполнившую переадресацию, т.к. адрес страницы стирается из history (что часто и требуется).

Если нужна задержка по времени, можно оформить location="http://www.new.domain.ru"; в виде функции и вставить её в setTimeout('функция()', задержка_в_милисек);.

Как разные поисковые системы могут отнестись к такому редиректу, остаётся на их «совести», поэтому для описываемых здесь целей лучше их не применять. Большинство броузеров отработает такую переадресацию как положено, при этом пользователю можно показать дополнительную информацию почему его перемещают по другому адресу.

Поскольку для переноса PR старого сайта(страницы) на новый, может потребоваться несколько недель или месяцев, не уничтожайте старое доменное имя, сайт или страницу, пока это не произойдёт.

PHP редирект

<?php
header(“HTTP/1.1 301 Moved Permanently”);
header(“Location: http://www.newdomain.ru/newdir/newpage.htm”);
exit();
?>

ASP редирект

<%@ Language=VBScript %>
<% 
Response.Status=“301 Moved Permanently”
Response.AddHeader “Location”, “http://www.new-url.com”
response.end
%>

ASP.NET редирект

<script runat=“server”>
private void Page_Load(object sender, System.EventArgs e)
{
Response.Status = “301 Moved Permanently”;
Response.AddHeader(“Location”,“http://www.new-url.com”);
}
</script>

ColdFusion редирект

<.cfheader statuscode=“301” statustext=“Moved permanently”>
<.cfheader name=“Location” value=“http://www.new-url.com”>

JSP (Java) редирект

<%
response.setStatus(301);
response.setHeader( “Location”, “http://www.new-url.com/” );
response.setHeader( “Connection”, “close” );
%>

CGI PERL

$q = new CGI;
print $q->redirect(“http://www.new-url.com/”);

Ruby on Rails

def old_action
headers[“Status”] = “301 Moved Permanently”
redirect_to “http://www.new-url.com/”
end

Осуществление редиректа в nginx

if ($host = ‘www.domain.com’ ) {
rewrite ^(.*)$ http://domain.com$1 permanent;
}

Памятка по используемым символам и обозначениям

Строчка RewriteCond — условие выполнения правила RewriteRule. Если условие выполняется, то срабатывает редирект.

Правила могут задаваться с помощью регулярных выражений.

Спецсимволы, используемые в правилах и их значения.

  • ^ — спецсимвол начала строки;
  • $ — спецсимвол конца строки;
  • ! — спецсимвол отрицания;
  • . — точка, заменяет любой символ, но только один;
  • () — группировка;
  • \ — «экранирующий» слеш, следующий символ после него считается обычным, а не спецсимволом.

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

  • ? — символ повторяется 0 или 1 раз;
  • + — повторяется от 1 до 65536 раз;
  • * — повторяется от 0 до 65536 раз.

Флаги, задают доп. опции для используемого правила. Перечисляются в квадратных скобках через запятую, скажем [NC] или [R=301,L].

  • NC — флаг NoCase, отключающий проверку регистра символов при срабатывании правила.
  • R — флаг Redirect, производит процесс остановки изменения URL-адреса и возвращает результат. Чаще всего используется значение R=301, но возможны и другие для временных перенаправлений (302, MOVED TEMPORARY).
  • L — флаг Last, останавливает формирования URL-адреса и строка считается окончательной.

Синтаксис для регулярных выражений

. — Точка заменяет произвольный символ.

[abc] — обозначает перечень символов, совпадающих с буквами a, b, или с.

[^abc] — перечень символов, которые не входят в указанных диапазон. Совпадёт с любым символом, кроме a, b, или с.

* — означает, что предшествующий символ может повторяться (0 или более раз).

[abc]* — команда найдёт идущие подряд символы из заданного набора.

[^abc]* — с точностью до наоборот.

 

.* — заменяет абсолютно любой набор символов. ".*" — найдёт все подстроки между кавычками.

^ — начало строки (в том случае, если используется в начале выражения).

$ — обозначает конец строки.

 

\w — буква, цифра или подчёркивание _.

\d — заменяет любую цифру.

\D — заменяет любой символ, но не цифру.

[0-9] — заменяет любую цифру.

[a-z] — любая буква от a до z (весь латинский набор символов) в нижнем регистре.

[A-Z] — любая буква от A до Z в ВЕРХНЕМ регистре.

[a-zA-Z] — любая буква от a до Z в любом регистре.

[a-Z] — то же самое.

Всё о редиректе

Disclaimer: Материалы для данной статьи были взяты из необъятных просторов Интернета (РУнета и БУРЖУнета) и личного опыта. Кое-какие моменты кажутся спорными и сейчас проверяются на практике, поэтому информация статьи будет дополняться и уточняться.
** В связи с участившимися сообщениями о Google 302 Pagejacking, используйте Redirect 301, а не 302 - эта тема пока в разработке.

Откуда взялся этот www?

В Интернете можно найти массу рекомендаций как «объединить» domain.ru и www.domain.ru. Но кроме как это сделать, было бы полезно немного понять также и почему. Это могло бы помочь выбрать соответствующее решение из предлагаемого разнообразия.

Сначала, важно понять, что www.domain.ru - технически то же, что и sub.domain.ru, хотя такое положение вещей существует по совсем другой причине.

Десять или двенадцать лет назад, World Wide Web был только одной маленькой частью Интернета, и самый быстрый PC был основан на 386 чипах. Они были не очень быстры и не могли обрабатывать большую часть загрузки, таким образом, была необходимость размещать различные «части» Интернета на отдельных машинах.

Например, сервер Apache размещался на одном компьютере, почтовый сервер на другом, и сервер FTP на еще одном. Каждый из компьютеров отзывался на различный адрес IP, но на то же самое имя домена. Внутри этого доменного имени компьютеры дифференцировались по предоставляемому сервису (что назвалось тогда, "именем машины"). Таким образом, имена серверов в Интернет начинались с «имени машины» по предоставляемому ей сервису: www.domain.ru, mail.domain.ru, и ftp.domain.ru. («Старожилы» Интернета, наверное помнят ещё и такой архаичный сервис, как gopher.domain.ru, в настройках IE он еще остался).

Сегодняшние компьютеры, конечно, намного более мощны, и мы можем поместить все различные "части" наших услуг Internet в той же самой «коробке» (принцип Head&Sholders - «два в одном флаконе» был применён задолго до массового появления «перхоти» в России:).

Действительно, мы часто устанавливаем несколько сотен доменов, каждый с его собственным набором сервисов (http, ftp, mail…), на тот же самый сервер. Поэтому в настоящее время приставка www является «антиквариатом» и может игнорироваться. Неприятность в том, что, множество программного обеспечения и больших каталогов (например, Yahoo), автоматически подставляют www.domain.ru, даже если Вы набираете domain.ru, плюс к этому мы имеем несколько миллиардов человек, которые автоматически печатают www перед любым именем домена.

Этот экскурс в Историю, по крайней мере, для меня, представляется интересным, но единственная важная вещь из него - то, что технически www.domain.ru - точно так же как sub.domain.ru - считаются полностью различными объектами относительно domain.ru, но по причинам, изложенным выше, обычно www.domain.ru и domain.ru обычно должны показывать одну и ту же страницу, в отличие от sub.domain.ru.

Пользователь(Surfer) или поисковая система(spider), при запросе страницы получат тот же самый код ответа 200 OK и будут не в состоянии дифференцировать домены с www и без такового.

Создание псевдонима (alias) для www

Если кто-то кричит "Юрий!" в переполненной комнате, он, вероятно собирается получить мое внимание. Если кто-то кричит "Савилов!" в той же самой комнате, я собираюсь отвечать на это также. Потому что эти два названия, хотя полностью различны, вообще указывают на того же самого человека. Упрощая немного, мы можем сказать, что «Юрий» - по существу псевдоним (alias) для «Савилов» . Если кто-то в той комнате приближается и называет меня как «Олег» , я вероятно буду озираться, находить «Олега» , и указывать его как то, что этот кто-то ищет (если этот кто-то, не настолько симпатичная особа, чтобы я мог солгать:). «Юрий» и «Олег» - два различных названия, которые указывают на двух различных людей, таким образом я должен переадресовать запрос человека туда, где ему ответят соответственно его запросу. На 99.9% всех конфигураций сервера, domain.ru и www.domain.ru указывают на точно то же самое место на диске. Каждый - только псевдоним для другого. Использование переадресации для обозначения одного и того места на диске имеет такой же смыл, как когда кто-то обращается ко мне «Юрий» и я отвечаю: "нет, Вам нужен «Савилов», это Я" .

Псевдонимы(alias) и Переадресация(Redirect), не являются одним и тем же, хотя зачастую возможна замена одного другим. Создание псевдонима вообще достигается на двух уровнях. На уровне доменной системы имен(DNS), мы всегда должны создавать вход для каждого, обычно CNAME для каждого, или возможно CNAME для предварительных выборов и вход для вторичного. Если рассматриваемый домен находится на статическом адресе IP, это - все, что мы должны сделать, чтобы создать псевдоним. Большинство из нас, однако, совместно использует адрес IP с другими доменами, таким образом мы должны двигаться вне уровня доменной системы имен(DNS) на уровень сервера сети, чтобы закончить конфигурацию псевдонима. Используя Apache, например, создать точку входа в конфигурационном файле hpptd.conf

ServerName domain.ru
DocumentRoot /home/domain/www
ServerAlias www.domain.ru

Естественно, предварительно надо связать не www-версию с www-версией через запись в DNS-сервере подобно:

Для домена верхнего уровня:

IN A 192.xxx.xxx.xxx
www IN A 192.xxx.xxx.xxx

Для поддомена info в домене верхнего уровня:

info IN A 192.xxx.xxx.xxx
www.info CNAME info

Это - всё, что необходимо сделать. Surfer или Spider, идя или в domain.ru или в www.domain.ru получат точно те же самые страницы. Наша проблема, однако, состоит в том, что запрашиваемый URL не изменяется, и запрашиваемая страница ответит 200 OK, независимо от того, обращаемся мы к домену с www или без такового. Если для Surfer-а это, в общем, безразлично, то это нельзя сказать по отношению к поисковому серверу (Spider), который должен, по крайней мере первоначально, обработать и domain.ru и www.domain.ru как отдельные объекты, даже при том, что мы знаем, что они - псевдонимы. Google - первый поисковый сервер, который стал применять сложные двойные фильтры и логику, необходимую, чтобы в конечном итоге «слить» domain.ru и www.domain.ru в единый объект. К сожалению, есть некоторый маленький акцент в том предложении на слове "в конечном счете". Если Вы будете использовать псевдонимы доменной системы имен(DNS) или ServerAlias, то Google в конечном счете признает domain.ru и www.domain.ru единым объектом и будет показывать только один сайт в SERP-е. К сожалению, это обычно занимает несколько месяцев, а если Вы часто меняете содержание сайта, то поскольку Spider индексирует domain.ru/page.htm и www.domain.ru/page.htm в разное время – он будет получать различное содержание страниц с www и без). Тогда эти несколько месяцев могут растянуться на год и более.

Зачем нужно "объединять" domain.ru и www.domain.ru?

Многие «серьёзные» сайты используют только домен с префиксом www (как например, большинство сайтов с PR 10. Если Вы попробуете обратиться к w3.org или adobe.com, то Вы увидите, что ваш браузер немедленно будет переадресован к сайту с www. Это не просто псевдоним, потому что местоположения вашей навигации фактически изменяется на новый домен с www. Полагаю, что Google нормально относится к этому, не только потому, что так поступают «серьёзные» сайты, но и сам Google делает это (если не верите - наберите google.com в броузере). Интересно то, что большинство «серьёзных» сайтов использует переадресацию(Redirect) 302. Лишь немногие, как w3.org, возвращают 301 код состояния. По-видимому, Google одинаково обрабатывает Redirect 301 и 302.

Единственно, Google почему-то считает, что сайт должен быть с префиксом www: можно сравнить в Google запрос поиска "морды" сайта narod.ru - разница будет ощутимой - без префикса www, Google включит в результат выдачи все субдомены. Но, поскольку есть преценденты, когда сайт без www имеет PR выше, чем сайт без www, значит Google не во всём дискриминирует таковые.

Поэтому, вместо того, чтобы полагаться на псевдонимы и фильтры поисковых систем(Spiders), кто-то придумал блестящую идею переадресовать один псевдоним к другому псевдониму, который является по существу переадресацией к самому себе. Это - одна из тех вещей, которая сделана в основном ПОТОМУ, ЧТО поисковые серверы существуют и должно, таким образом, помочь избежать раскалывания Обратных Ссылок(backlinks). Однако, могут быть ещё причины, требующие обязательной переадресации: поскольку технически http://mysite.ru/ и http://www.mysite.ru/ являются РАЗЛИЧНЫМИ сайтами, сессии PHP не могут передаваться от одного к другому. Это ещё одна причина для переписывания URL в броузере путём редиректа на псевдоним (alias), особенно если у Вас есть только один сертификат SSL для домена www.mysite.ru...

Технические варианты Редиректа

Теперь попробуем ответить на вопрос, почему в рекомендациях по редиректу чаще предлагаются mod_rewrite и RedirectMatch в файле .htaccess (требующие определённые ресурсы машины на их выполнение), и реже - более простое решение. Почему мы не можем устранить все сложные Регулярные Выражения и просто добавить в наш .htaccess строку «Redirect 301 / http://www.domain.ru» (для варианта hpptd.conf выше)? Так как domain.ru и www.domain.ru - псевдонимы и указывают на тот же самый каталог, любые .htaccess директивы в этом каталоге будут применяться к ОБОИМ доменам. Простая Переадресация, на некоторых серверных платформах приведёт в «замкнутому кругу» и, в конечном счете – краху. Попробуем немного изменить конфигурацию сервера:

ServerName domain.ru
DocumentRoot /home/domain/www
ServerName www.domain.ru
DocumentRoot /home/wwwdomain/www

Заметьте: в этой конфигурации, domain.ru, и www.domain.ru указывают на различные папки на сервере и поэтому не псевдонимы. Мы можем теперь поместить .htaccess файл в папку /home/wwwdomain/www, не затрагивая ничто в папке /home/domain/www и использовать для достижения цели более простую команду Redirect. Проблема решена, но, к сожалению, мы тратим впустую немного дискового пространства, поэтому Вы не очень часто встретите эту конфигурацию. Однако такая конфигурация предоставляет Вам другую возможность:

ServerName domain.ru
DocumentRoot /home/domain/www
ServerName www.domain.ru
Redirect 301 / http://domain.ru/

Мы все еще конфигурируем domain.ru и www.domain.ru как отдельные объекты (не псевдонимы), но вместо того, чтобы определить DocumentRoot для второго объекта, мы вставляем простую переадресацию. Мы избегаем противоречий попытки переадресовать псевдоним, не создавая его. Недостаток этого метода - то, что он требует большего количества работы для администратора хоста. Надо определить два блока записей вместо одного, но что еще более важно, надо поддерживать оба блока «в унисоне». Преимущество – в том, что каждый отдельный запрос страницы, сделанный к вашему домену приводит к операции чтения для .htaccess и парсинга файла. Теперь добавьте все те регулярные выражения, которые будут применяться для каждого отдельного запроса страницы, и затем умножьте все это 200 - 500 других доменов, живущих на сервере.

Переадресация, помещенная в httpd.conf, не требует никаких RegExp и что еще более важно читается и парсится только ОДИН раз при запуске сервера Apache. Это, на мой взгляд, наиболее изящное решение, т.к. позволяет избежать создания псевдонимов и максимально снижает нагрузку на сервер.

Осталось прояснить вопрос: что же грамотнее Redirect 301 или 302? Как отмечено выше многие «серьёзные» сайты спокойно используют Redirect 302, чтобы "объединить" домен с www и без и Google так же спокойно принимает это. Но не факт, что так поступят и остальные поисковики. Всё-таки, RFC никто не отменял: код "301" означает, что страница перемещена навсегда - «moved permanently», код "302" – временное перемещение «moved temporary», поэтому использование кода должно зависеть от целей перемещения страницы. Следует также понимать, что многие броузеры, получая ответ «301 - moved permanently», могут автоматически перенастраивать закладки на новую страницу. Аналогично, не факт, что, тот же Google, будет своевременно передавать PR на перемещённую по редиректу 302 страницу, считая его "временным", пока не "зазеркалит" оба сайта.

Редирект для различных SE (Search Engines):

В целом, редирект по разному воспринимается различными поисковыми машинами. Если Вы хотите испорльзовать редирект для "объединения" www-версии сайта с не-www версией, надо иметь ввиду следующие замечания.

Если на Ваш сайт часть ссылок установлена как на www, а часть как на без-www, то Вас наверняка интересует "объединение" веса ссылок на обе версии сайта в плане тИЦ/PR и ссылочного ранжирования.

Редирект для Яndex

Дело в том, что Яндекс объединяет ссылки для сайтов, которые он считает зеркалами, а редирект с site.ru на www.site.ru исключит доступ Яндекса к site.ru и, следовательно он не будет считаться зеркалом со всеми вытекающими последствиями. Для склейки Яндексом надо, чтобы оба имени сайта были доступны (отвечали "200 OK") и имели одинаковый контент.

Дополнительно, надо определить главное зеркало сайта директивой Host в файле Robots.txt, например:

User-agent: *
Disallow:

User-agent: 
Yandex
Disallow:
Host: 
www.info.data-com.ru

* Грамотнее вынести директивы Host в отдельную секцию только для робота Яндекса (есть информация, что Google либо игнорирует секцию, в которой втречаются непонятные ему директивы, либо отрабатывает её некорректно);
** По стандарту robots.txt, в каждой секции "User-agent:" должна присутствовать хотя бы одна директива "Disallow:", поэтому в примере стоит "пустая" директива, не запрещающая ничего. Для вашего случая пропишите собственные ограничения, если они есть.

Редирект для Google

Google нормально понимает Redirect, по крайней мере об этом можно судить по недавней заметке Ванессы Фокс в официальном блоге Google Sitemaps. Дабы не потерять этот интересный текст, привожу его полностью:

Inside Google Sitemaps: More about changing domain names Your source for product news and developments
More about changing domain names
1/27/2006 09:27:00 AM
Posted by Vanessa Fox, Google Engineering

Recently, someone asked me about moving from one domain to another. He had read that Google recommends using a 301 redirect
to let Googlebot know about the move, but he wasn't sure if he should do that. He wondered if Googlebot would follow
the 301 to the new site, see that it contained the same content as the pages already indexed from the old site, and
think it was duplicate content (and therefore not index it). He wondered if a 302 redirect would be a better option.

I told him that a 301 redirect was exactly what he should do. A 302 redirect tells Googlebot that the move is temporary
and that Google should continue to index the old domain. A 301 redirect tells Googlebot that the move is permanent and that
Google should start indexing the new domain instead. Googlebot won't see the new site as duplicate content, but as moved
content. And that's exactly what someone who is changing domains wants.

He also wondered how long it would take for the new site to show up in Google search results. He thought that a new site
could take longer to index than new pages of an existing site. I told him that if he noticed that it took a while for a new
site to be indexed, it was generally because it took Googlebot a while to learn about the new site. Googlebot learns about
new pages to crawl by following links from other pages and from Sitemaps. If Googlebot already knows about a site,
it generally finds out about new pages on that site quickly, since the site links to the new pages.

I told him that by using a 301 to redirect Googlebot from the old domain to the new one and by submitting a Sitemap for
the new domain, Googlebot could much more quickly learn about the new domain than it might otherwise. He
could also let other sites that link to him know about the domain change so they could update their links.

The crawling and indexing processes are completely automated, so I couldn't tell him exactly when the domain would start
showing up in results. But letting Googlebot know about the site (using a 301 redirect and a Sitemap) is an important first
step in that process.

Вот перевод наиболее значимых частей этого текста:

Недавно, кто - то спрашивал меня о перемещении c одного домена на другой. Он прочитал, что Google рекомендует использовать Redirect 301, чтобы сообщить Гуглеботу о перемещении, но он не был уверен, должен ли он сделать это.

Я сказала ему, что Redirect 301, именно что он должен сделать. Redirect 302 говорит Гуглеботу, что перемещение является временным и что Google должен продолжить индексировать старый домен. Redirect 301 говорит Гуглебот, что перемещение является постоянным и что Google должен начать индексировать новый домен. Гуглебот будет рассамтривать новый домен не как дублированный контент, а как перемещенный контент.
. . .
Гуглебот узнает о новых страницах для индексации по ссылкам с других страниц и от Sitemaps.
. . .

Вот другой фрагмент из "Центра помощи Google" на тему Redirect 301:

My URL changed, so how can I get Google to index my new site?

While we can't manually change your URL in our search results, there are steps you can take to make sure your transition
is smooth.
First, you can redirect individuals to your new site. If your old URLs redirect to your new site using HTTP 301 (permanent)
redirects, our crawler will discover the new URLs.
. . .
Google listings are based in part on our ability to find you from links on other sites. To preserve your rank, you'll want
to tell others who link to you of your change of address. One way to find a sampling of sites that link to yours is to
perform a link search.

Вот перевод этого фрагмента: -

"В то время как мы не можем вручную изменить ваш URL в наших результатах поиска, есть шаги, которые Вы можете предпринять, чтобы ваш переход гладким. Сначала, Вы можете переадресовать людей к вашему новому домену. Если ваши старые URL переадресовывают к вашему новому домену, используя HTTP 301, наш паук обнаружит новый URLs";

- "Списки выдачи Google частично базируются на способности найти сайт по ссылкам с других сайтов. Чтобы сохранять ваш рейтинг, Вы будете хотеть сказать тем, кто ссылается на Вас об изменении вашего адреса".

И, наконец, ещё один важный фрагмент из "Центра помощи Google" на эту тему:

Why does my site have two different listings in Google: http://site.com and http://www.site.com?

If your site is appearing as two different listings in our search results, we suggest consolidating these listings so we can
more accurately determine your site's PageRank. The easiest way to do so is to redirect your http URL to your www URL using
a 301 redirect. This should resolve the situation after our crawler discovers the change.
. . .
Please note: using a robots.txt file and our automatic URL removal system to remove just the http or www version of your
site will not work. This will remove both versions for 180 days, and we cannot manually add your site back to our index.

из которого следует, что Google должен объединять PR сайтов по редирект 301.

Обратите внимание на примечание к последнему фрагменту. Вы не сможете удалить отдельно не-www версию или www-версию из индекса Google - Вы удалите сразу обе версии на 180 дней.

Послесловие

Для проверки склейки сайта Яндексом и "объединения" тИЦ применён другой метод (он запущен на этом сайте с марта 2006г). Сайт откликается на имя с www и без www. Страницы сайта проверяют HTTP_USER_AGENT запросившего страницу, и если это робот Яндекса - то на оба варианта обращения по имени сайта (с www и без) ему дается ответ "200 OK" и сама страница. Для всех остальных, сайт доступен только как www.info.data-com.ru, при обращении к info.data-com.ru делается Redirect 301 на www.info.data-com.ru. На такой же технологии построен метод клоакинга - когда поисковикам показывают одно содержимове страницы, а пользователям - другое. Клоакинг наказывается поисковиками исключением сайта из их индекса и как следствие - из выдачи.

Для проверки объединения Google PR по Redirect 301, таковой установлен на этом сайте с февраля 2006г., и если RP www.info.data-com.ru и info.data-com.ru выравняются - этот факт можно юудет считать подтверждёным. (ссылки на www.info.data-com.ru и info.data-com.ru проставляются примерно 50 на 50).

** Если Вы решились использовать редирект для своего сайта - делайте Redirect 301, а не 302. По крайней мере, пока на прояснится ситуация с Google 302 Pagejacking - эта статья пока в стадии разработки.


Created/Updated: 25.05.2018

☕ Якщо ви вважаєте ці поради українською корисними, можете підтримати автора і, звичайно, отримуйте задоволення!

PayPal Donate

📩 Шановні, якщо хочете додати або відредагувати, надішліть повідомлення через форму контакту.

';