Это даже не статья. А подборка статей из разных источников, собранная для личного пользования, но похоже довольно востребованная по вопросам. Поэтому и выкладываем здесь.
Технически www.domain.ru - точно так же как sub.domain.ru - считаются полностью различными объектами относительно domain.ru, но обычно www.domain.ru и domain.ru обычно должны показывать одну и ту же страницу, в отличие от sub.domain.ru.
Псевдонимы(alias) и Переадресация(Redirect), не являются одним и тем же, хотя зачастую возможна замена одного другим. Создание псевдонима вообще достигается на двух уровнях. На уровне доменной системы имен(DNS), мы всегда должны создавать вход для каждого, обычно CNAME для каждого, или возможно CNAME для предварительных выборов и вход для вторичного. Если рассматриваемый домен находится на статическом адресе IP, это - все, что мы должны сделать, чтобы создать псевдоним. Большинство из нас, однако, совместно использует адрес IP с другими доменами, таким образом мы должны двигаться вне уровня доменной системы имен(DNS) на уровень сервера сети, чтобы закончить конфигурацию псевдонима.
Используя Apache, например, создать точку входа в конфигурационном файле hpptd.conf:
Естественно, предварительно надо связать не 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 и без). Тогда эти несколько месяцев могут растянуться на год и более.
Поэтому, вместо того, чтобы полагаться на псевдонимы и фильтры поисковых систем(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 директивы в этом каталоге будут применяться к ОБОИМ доменам. Простая Переадресация, на некоторых серверных платформах приведёт в «замкнутому кругу» и, в конечном счете – краху. Попробуем немного изменить конфигурацию сервера:
Заметьте: в этой конфигурации, domain.ru, и www.domain.ru указывают на различные папки на сервере и поэтому не псевдонимы. Мы можем теперь поместить .htaccess файл в папку /home/wwwdomain/www, не затрагивая ничто в папке /home/domain/www и использовать для достижения цели более простую команду Redirect. Проблема решена, но, к сожалению, мы тратим впустую немного дискового пространства, поэтому Вы не очень часто встретите эту конфигурацию. Однако такая конфигурация предоставляет Вам другую возможность:
Мы все еще конфигурируем 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 старой страницы, можно сделать так:
(.*) RedirectMatch фактически соответствует регулярным образцам выражения после доменного имени. Таким образом, нельзя выполнить соответствие образца на ^/yourdomain.ru. Однако, можно преобразовать страницы с использованием .html расширения к файлам того же самого названия, но с .php расширением:
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, которые не поддерживают виртуальный хостинг)
7. Редирект с помощью JavaScript:
Вот уж где нет предела творчеству и возможности "по изголяться". Варианты переадресации на JavaScript чаще реализуются с использованием функции setTimeout("функция", задержка).
Например, автоматически сделать Click на кнопке "Submit" формы "searchform" через 0.1 сек после загрузки кода:
На кнопку "Submit" можно повесить любое действие, например, открыть новый url в этом окне. Кстати такое редиректы чаще встречаются при организации Дорвеев(DorWay) - броузер Пользователя будет переадресован на другую страницу, а поисковый робот, который "не понимает" JavaScript, будет индексировать ЭТУ страницу, недоступную Пользователю. На ней Дорвейщики размещают текст, напичканный "нужными" ключевыми словами.
Просто переадресовать на другую страницу - вставить после код на JavaScript:
location="http://www.new.domain.ru"; или document.location.href="http://www.new.domain.ru" mce_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 старого сайта(страницы) на новый, может потребоваться несколько недель или месяцев, не уничтожайте старое доменное имя, сайт или страницу, пока это не произойдёт.
7. Редирект для различных SE: В целом, редирект по разному воспринимается различными поисковыми машинами (Search Engines). Если Вы хотите испорльзовать редирект для "объединения" www-версии сайта с не-www версией, надо иметь ввиду следующие замечания.
Если на Ваш сайт часть ссылок установлена как на www, а часть как на без-www, то Вас наверняка интересует "объединение" веса ссылок на обе версии сайта в плане тИЦ/PR и ссылочного ранжирования.
Редирект для Яndex Дело в том, что Яндекс объединяет ссылки для сайтов, которые он считает зеркалами, а редирект с site.ru на www.site.ru исключит доступ Яндекса к site.ru и, следовательно он не будет считаться зеркалом со всеми вытекающими последствиями. Для склейки Яндексом надо, чтобы оба имени сайта были доступны (отвечали "200 OK") и имели одинаковый контент.
Дополнительно, надо определить главное зеркало сайта директивой Host в файле Robots.txt, например:
* Грамотнее вынести директивы Host в отдельную секцию только для робота Яндекса (есть информация, что Google либо игнорирует секцию, в которой втречаются непонятные ему директивы, либо отрабатывает её некорректно); ** По стандарту robots.txt, в каждой секции "User-agent:" должна присутствовать хотя бы одна директива "Disallow:", поэтому в примере стоит "пустая" директива, не запрещающая ничего. Для вашего случая пропишите собственные ограничения, если они есть.
Редирект для Google. Google нормально понимает редирекы.
** Если Вы решились использовать редирект для своего сайта - делайте редирект 301, а не 302.
301 редирект (перенаправление через mod_rewrite) Дело в том, что фактически http://www.имясайта.ru и имясайта.ru (без www) – это разные сайты. Во-первых, это дублирование содержимого (информация воспринимается, как одинаковая, расположенная на разных сайтах). Во-вторых, делится PageRank для страниц сайтов http://www.имясайта.ru и имясайта.ru (без www) (невозможно контролировать внешние ссылки на сайт – кто-то ставит ссылки с www, а кто-то - без). Редирект 301 (Moved Permanently) позволяет решить эти проблемы. Синтаксис файла .htaccess для настройки веб-сервера Apache приведен ниже:
