301/302 редирект

Использование материалов сайта разрешается при условии ссылки (для сайтов - гиперссылки) ФОРУМ [Вставка мультимедиа] [Таблица тэгов] [Таблица атрибутов] [Работа с формами] [Работа с фреймами] [От идеи до результата] [Проектирование] [Анализ страниц сайта] [Риски] [Поисковые машины] [Базы каталогов ] [HTML] [Работа с текстом] [Построение таблиц] [Работа с ссылками] [Работа с изображениями] [CSS] [Форматирование текста] [Форматирование элементов] [Позиционирование] [Таблица параметров] [CMS - управление сайтом] [PHP] [JavaScript] [JavaScript FAQ] [CGI] [Список элементов HTML] [CMS] [IPB WIKI] [Google SiteMap] [ FAQ Web Design] [Всё о RSS] [Возможности HTML] [Сhmod] [mod_rewrite ч.1] [mod_rewrite ч.2] [mod_rewrite ч.3] [mod_rewrite ч.4] [mod_rewrite ч.4] [301/302 редирект] [Словарь по HTML] [Типичные приёмы HTML] [Использование Java Script] [Обработка ошибки 404] [Выпадающее меню] [Создание и вёрстка] [Прозрачная анимация] [Xara WebStyle 3] [3D лого в photoshop] [Apache (комманды)] [Массив $_SERVER] [Бесплатный домен ORG.UA] [Раскрути сайт] [Тесты скорости] [Пользователи бесплатно] [Программы для раскрутки] [Как стать #1?: Обзор] [Накрутка и посетители!] [Прячем внешние ссылки] [Повысить ИЦ!] [Основные Каталоги] [Убойная посещаемость] [Регистрация в DMOZ] [Раскрутка сайта на 1ps.ru] [Превратить трафик в $] [Заработать на ссылках] [AdSense $5000 в месяц] [Полезные сервисы] [Стоимость домена] [Правильная WEB страница] [Продвижение сайта] [Правила контента] [Правила баннера] [Список каталогов] [Список хостингов] [Список почтовиков] [Синонимайзер Online] [Скрипты BUX] [Скрипт статистики online] [Срипты PHP CGI PERL] [Примеры JavaScript] [Скрипты на 3225$] [Скрипты магазинов] [Скрипты галерей] [Скрипты PHP, ASP] [Скрипты каталогов] [Скритпы форумов] [Новости и статьи] [Линкообменники] [Прочие скрипты на php] [ASP скрипты] [Компаненты для joomla] [JavaKeyboard (tutorial)] [Скрипт анализа online] [Генератор Метатегов] [JS Скрытое меню] [Slide Show Script] [Java Scripts (скрипты)] [Кодировать информацию] [Оценка качества сайта] [Ucoz Граббер 1.0v] [HTML] [PERL] [CSS]

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

Вкратце остановлюсь на некоторых основных моментах:

1. Самое простое — редирект с одной страницы на другую:
в .htaccess строчим:

Redirect 301 /old-file.html http://myserver.com/new-file.html

2. Более мудреный вариация, в какое время сайт переносится, скажем, с одного домена на другой, также при этом сохраняется структура УРЛов:

RewriteEngine ON
RewriteRule (.*)$ http://mynewdomain.com/$1 [R=301,L]

Таким образом, ежели кто-то запрашивает страницу http://domain.com/asdf.html, его станет редиректить (301) на http://mynewdomain.com/asdf.html

3. Если бла бла сайт, к образцу, переносится, однако структура УРЛов меняется, то кушать смысл использовать последующий метод:

RewriteEngine ON
RewriteRule /.* http://mynewdomain.com/ [R=301,L]

При этом все запросы со старого домена будут вести на главную страницу нового.

4. Еще один занимательный момент, ежели вы хотите изменить разрешение файлов (например, с html на htm):

RedirectMatch 301 (.*)\.htm$ http://myserver.com$1.html

PS: возможно, мы местами ошибся, т.к. никак не являюсь специалистом в этих делах, поэтому ежели что, пожалуйста, дайте знать.

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:

<VirtualHost 192.xxx.xxx.xxx>
ServerName domain.ru
DocumentRoot /home/domain/www
ServerAlias www.domain.ru
</VirtualHost>

Естественно, предварительно надобно связать никак не 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 директивы в этом каталоге будут применяться к ОБОИМ доменам. Простая Переадресация, на некоторых серверных платформах приведёт в «замкнутому кругу» а также, в конечном счете – краху. Попробуем мало изменить конфигурацию сервера:

<VirtualHost 192.xxx.xxx.xxx>
ServerName domain.ru
DocumentRoot /home/domain/www
</VirtualHost>

<VirtualHost 192.xxx.xxx.xxx>
ServerName www.domain.ru
DocumentRoot /home/wwwdomain/www
</VirtualHost>

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

<VirtualHost 192.xxx.xxx.xxx>
ServerName domain.ru
DocumentRoot /home/domain/www
</VirtualHost>

<VirtualHost 192.xxx.xxx.xxx>
ServerName www.domain.ru
Redirect 301 / http://domain.ru/
</VirtualHost>

Мы все еще конфигурируем 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 страницу, считая его "мимолетным", пока что никак не "зазеркалит" оба сайта.

Другие варианты реализации Редиректа

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

1. Бесхитростный редирект:

Redirect 301 / http://www.domainname.ru/

Ставится в файле .htaccess либо httpd.conf для Apache, как описано выше. Первый "/" означает, что всё с верхнего уровня сайта, включая все подкаталоги, станет переадресовано (не забывайте поставить завершительный "/").

Если Вы хотите переадресовать только страницу, сохранив PR старой страницы, разрешено сделать так:

Redirect 301 /old/old.htm http://www.you.ru/new.htm

где:

/old/old.htm - маршрут также имя старой страницы
http://www.you.com/new.htm - новоиспеченный маршрут также новое имя перемещенной страницы

2. Использование mod_rewrite:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} yourdomain\.ru
RewriteRule (.*)$ http://www.yourdomain.ru/$1 [R=permanent,L]Прописывается в файле .htaccess.

3. Редирект с регулярным выражением:

RedirectMatch 301 (.*) http://www.yourdomain.ru$1

Прописывается в файле .htaccess.

(.*) RedirectMatch фактически соответствует регулярным образцам выражения позже доменного имени. Таким образом, невозможно выполнить соотношение образца на /yourdomain.ru. Однако, разрешено преобразовать страницы с использованием .html расширения к файлам того бла бла самого названия, но с .php расширением:

RdirectMatch 301 (.*)\.html$ http://www.yourdomain.ru$1.php

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

RedirectMatch Permanent /html/resources.html$ http://www.newdomain.com/resources.php
RedirectMatch Permanent /html/other_page.html$ http://www.newdomain.com/other_page.php
RedirectMatch Permanent /(.*)$ http://www.newdomain.com/"

RedirectMatch Permanent" - это эквивалент "RedirectMatch 301", строска с "*(Wildcard)" должна существовать последней в этом списке.

4. Редирект на PHP:

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

Естественно, надобно создать страницу, при обращении к которой также станет проистекать Редирект, также разместить её на сервере. И лучше укажите HTTP/1.1 (а никак не HTTP/1.0 либо HTTP/0.9, которые никак не поддерживают виртуальный хостинг)

5. Редирект на ASP:

<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.newdomain.ru/newdir/newpage.asp"
response.end
%>

Размещение схоже п.4.
Код по п.4. также 5. вынужден существовать с самого истока страницы.

6. Редирект с помощью meta refresh::

<meta http-equiv='refresh' content='0; url=http://new.domain.ru'>

где 0 – задержка переадресации в секундах, new.domain.ru –страница, куда переадресуем. Некоторые броузеры никак не поддерживают META REFRESH.

7. Редирект с помощью 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="/click?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 старого сайта(страницы) на новый, может потребоваться несколько недель либо месяцев, никак не уничтожайте старое доменное имя, сайт либо страницу, пока что это никак не произойдёт.

7. Редирект для различных 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 - эта статья пока что в стадии разработки.