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

У правилах:% {QUERY_STRING} - позначає фрагмент URL-адреси після знака питання (завдання значень CGI-параметрів).

Спрацьовування того чи іншого правила для редиректу визначається тим, потрапляє URL-адресу сторінки під це правило чи ні.

Про значення тих чи інших позначень (^, $, NC і т.д.) см. Пам'ятку в кінці сторінки .

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

Краще розміщувати всі правила після двох рядків:

  Options + FollowSymLinks
 RewriteEngine On 

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

  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 

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

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

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

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

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

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

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

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

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

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

Як бути з доменами в зоні РФ?

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

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

  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] 

  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] 

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

  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] 

  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] 

  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] 

  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] 

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

  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] 

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

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

  RewriteCond% {THE_REQUEST} ^ [AZ] {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] 

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

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

  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 ();
 ?> 

Оптимально налаштовувати все редіректи відразу на кінцеву сторінку (без проміжних перенаправлень, в один крок) це покращує їх сприйняття з боку пошукових систем і користувачів.

  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] 

  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] 

  RewriteRule (. *) $ 1?  [R = 301, L]
 Розташовувати після: RewriteBase / 

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 

  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 

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

  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"); 

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

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

  <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> 

  <.cfheader Statuscode = "301" statustext = "Moved permanently">
 <.cfheader Name = "Location" value = "http://www.new-url.com"> 

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

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

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

  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] - замінює будь-яку цифру.

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

[AZ] - будь-яка буква від A до Z в верхньому регістрі.

[a-zA-Z] - будь-яка буква від a до Z в будь-якому регістрі.

[aZ] - те ж саме.

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

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 9: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 was not 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 will not 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 could not 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 not 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 can not 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 - ця стаття поки в стадії розробки.