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 страницу, считая его "временным", пока не "зазеркалит" оба сайта.
Другие варианты реализации Редиректа
Поскольку встречаются более сложные случаи, когда такое простое решение неприемлемо, приведем остальные известные примеры организации пересадресации:
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:
Размещение аналогично п.4.
Код по п.4. и 5. должен быть с самого начала страницы.
6. Редирект с помощью meta refresh::
где 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, будет индексировать ЭТУ страницу, недоступную Пользователю. На ней Дорвейщики размещают текст, напичканный "нужными" ключевыми словами.
Просто переадресовать на другую страницу - вставить после код на 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 старого сайта(страницы) на новый, может потребоваться несколько недель или месяцев, не уничтожайте старое доменное имя, сайт или страницу, пока это не произойдёт.
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 - эта статья пока в стадии разработки.
http://www.info.data-com.ru