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

Редирект для различных 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.mysite.ru

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

А проверить как Яндекс "реагирует на ваш robots.txt можно на этой страничке

Редирект для G o o g l e

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 дней.

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

Редирект для Yahoo Пока детально не исследовался и принимается таким, как описано на самом сайте Yahoo - 301/302 редирект глазами Yahoo

Послесловие

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

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

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