This page has been robot translated, sorry for typos if any. Original content here.

Редіректи в 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 параметрами

Скажімо, адреса сторінки має вигляд: h ttp: //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} ^ [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] 

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

Код дозволяє поставити 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} ^ [AZ] {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] - замінює будь-яку цифру.

[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 - ця стаття поки в стадії розробки.