22 декабря 2015
7 февраля 2011
29
Зеркала и редиректы
В продолжение темы про URL`ы страниц, угодные для SEO, обязательно нужно обсудить и начало всех путей — домены. Тема, кстати, пикантная: чего стоит один префикс www (удлиняющий домены до третьего уровня), имеющий как ярых сторонников, так и радикальных противников.
Но кроме проблем идеологических, есть и организационные. В полной мере они проявляются, когда домен посещаемого сайта приходится менять, чего конечно не бывает при разработке, но случается в процессе эксплуатации и поддержки проекта. И гораздо сложнее этот процесс осуществить не нарушив гармонии с родным Яндексом.
Впрочем, надеюсь, что читателям в любом случае пригодятся знания о специфике поисковых систем и готовые сниппеты для настройки постоянных редиректов в веб-серверах Apache и nginx.
Начнём с принципиальных отличий в отношениях к доменам Яндекса и Google. Мировой гигант не наделяет домен какими-то исключительными качествами по сравнению с остальной частью URL`а, поэтому в выдаче Google вполне могут встречаться разные домены в сниппетах для страниц с одного и того же сайта.
Однако, если владелец сайта хочет однозначности, то достичь её несложно.
Официальная цитата Google:
Если вы хотите изменить URL-адрес страницы, отображаемый в результатах поиска, рекомендуем использовать переадресацию 301, выполняемую сервером. Это самый лучший способ обеспечить переход пользователей и поисковых систем на нужную страницу.
Соответственно, установить такие редиректы следует для всех страниц.
В панели «Инструментов для веб-мастеров» от Google есть дополнительное средство для задания основного домена (главного зеркала) сайта:
А дальше надо будет дождаться очередной переиндексации и обновления выдачи.
www против non-www
Пока сайт новый у него единственный домен, но зато почти обязательно в придачу имеется поддомен с www вначале.
Какой из доменов сделать основным: второго или третьего уровня — решать вам (или заказчику), но я склоняюсь к варианту без префикса. Просто потому, что он короче, а, значит, оставит больше места в блоке поисковой выдачи для остальной части адреса страницы или поместится целиком в твиттер без сокращателя ссылок. Если вам известны иные объективные преимущества того или другого варианта — расскажите о них, пожалуйста, в комментариях.
При этом работать должны обязательно оба домена (как с префиксом, так и без).
Пользователя набравшего неосновной домен можно прозрачно перенаправляться на главное зеркало. Надо эту возможность задействовать, по крайней мере для того, чтобы ссылка, добавленная посетителем в закладки или скопированная в личный блог — была сразу с желаемым доменом.
Редирект на основное зеркало силами веб-сервера
Поскольку война за главное зеркало обычно случается между www и non-www вариантами, то напомню конфиги для организации постоянных (301-ых) редиректов силами популярных веб-серверов.
Apache
Итак, начнём с Apache. Перенаправить с www на non-www можно добавив следующий блок в начало файла .htaccess из корневой директории сайта:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^$ [NC]
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
</IfModule>
Перенаправить с non-www на www:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^$ [NC]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteRule ^(.*)$ "http://www.%1/$1" [L,R=301]
</IfModule>
Это заработает, если включен модуль mod_rewrite и разрешено переопределение соответствующих директив в .htaccess. На виртуальном хостинге — так оно, как правило, и бывает, а на сервере под собственным контролем нужно самостоятельно активировать модуль и для корневой директории в описании виртуального хоста добавить как минимум AllowOverride FileInfo Options, а если хост не боевой, то можно разрешить переопределять всё подряд AllowOverride All.
Проверено на Apache/2.2.16 под Ubuntu Server 10.10.
nginx
Любителям скоростного отечественного фронт-энда nginx повезло с лаконичным синтаксисом. Для перенаправления с www на non-www достаточно добавить в начало блока server:
if ($host ~* www\.(.*)) {
set $non_www $1;
rewrite ^(.*)$ http://$non_www$1 permanent;
}
А чтобы перенаправить с non-www на www:
if ($host !~* ^www\.) {
rewrite ^(.*)$ http://www.$host$1 permanent;
}
Необходимый модуль включен по умолчанию, проверено на nginx/0.7.67 под Ubuntu Server 10.10.
Представленные выше сниппеты удобны тем, что конкретные названия доменов в них не используются, т.е. одинаково хорошо такие редиректы будут работать как на серверах для разработки, так и на боевых хостах.
Первое знакомство домена с Яндексом
Но разобравшись с универсальными редиректами, придётся признать страшное: для Яндекса перенаправлений недостаточно.
Более того, Яндекс не показывает URL`ы с разными доменами для одного и того же сайта, всегда выбирая для вывода в сниппет главное зеркало. И вот как оно определяется…
Официальная цитата Яндекса:
В общем случае наш робот выберет главное зеркало в соответствии со своим алгоритмом.
Ощутили разницу в подходах? Тем не менее, если вы имеете дело с новым сайтом и новым доменом (когда оба — ранее не проиндексированы), то подсказать роботу главное зеркало можно вполне однозначно.
Достаточно следовать таким правилам:
-
Установить 301-й редирект со всех альясов на предполагаемое главное зеркало. Редирект надо делать с заменой домена, но сохраняя остальной путь (адрес страницы). Например, подойдут варианты, описанные выше.
-
Установить директиву Host в robots.txt для блока User-agent: Yandex (чтобы не пугать пауков Google незнакомой командой), указав там желаемый домен.
-
Позаботиться о том, чтобы все (или хотя бы почти все) внутренние ссылки на сайте, использующие абсолютную адресацию, начинались именно с главного зеркала.
-
Раскидать по интернету несколько внешних ссылок, содержащих главное зеркало в качестве домена, или добавить заявку на индексацию сайта через форму http://webmaster.yandex.ru/addurl.xml, указав туда тоже главное зеркало.
Что решил Яндекс?
Конечно можно изучить поисковую выдачу, обращая внимание на то, какой домен показывается там, но есть способ попроще: через упомянутую выше форму можно повторно добавить на индексацию один из альясов (притом любой). Если вы указали неглавное зеркало, то Яндекс сообщит об этом:
Переезд по версии Яндекса
Если главное зеркало по каким-то причинам захочется сменить, то придётся решать нетривиальный квест.
Официальная цитата Яндекса:
Существует два независимых метода для смены главного зеркала:
- С помощью директивы Host.
- С помощью серверного редиректа со страниц старого домена на соответствующие им страницы нового. Этот способ рекомендуется использовать в том случае, если новый домен не является неглавным зеркалом.
Последний тезис способен испугать даже экспертов по формальной логике. Поэтому прокомментирую ситуацию.
С точки зрения Яндекса может существовать 4 типа связи между двумя и более доменами:
Единственный известный Яндексу домен (он же обязательно является главным зеркалом)
Простейший пример: представим сайт, откликающийся по одному единственному домену — example.com, и не доступный даже по поддомену www.example.com (вот не настроил владелец альяс по принципиальным соображениям). Всё однозначно, домен единственный — он же и основной.
Дополнительный известный Яндексу домен (неглавное зеркало сайта)
Представим, как полгода назад владелец сайта понял, что теряет аудиторию из-за своей принципиальности, ведь некоторые неопытные пользователи сети так и норовят приписывать www ко всему, что вводится в адресную строку. Владелец одумался и добавил поддомен www как альяс, а те же новички за пару месяцев насорили в интернете ссылками с префиксом www — так Яндекс и узнал о втором домене, но по ряду факторов (идентичные контент и структура) догадался, что это зеркало сайта. Теперь Яндекс оставит давно известный ему example.com главным зеркалом, а www.example.com — сделает неглавным зеркалом.
Разница проявится в том, что URL`ы в сниппетах поисковой выдачи Яндекса буду начинаться именно с главного зеркала (с example.com без www).
Если владелец сайта изменит принципам снова и захочет, чтобы основным зеркалом теперь стал домен www.example.com (а example.com, соответственно, дополнительным), то проводить рокировку рекомендуется с использованием директивы Host в файле robots.txt (а не с помощью редиректа).
Два независимых ранее известных домена
Есть rambler.ru и есть google.com — и между ними пропасть, тут и говорить не о чем — разные сайты. Но если пофантазировать и предположить, что все запросы вида http://nova.rambler.ru/search?query=text неведомая сила вдруг перенаправит с 301-ым редиректом на http://www.google.ru/search?q=text, то Яндекс покраснеет через какое-то время согласится с тем, что nova.rambler.ru — это всего лишь неосновное зеркало google.com.
В случае подобного переезда редирект — это рекомендуемое Яндексом решение. В итоге произойдёт так называемая «склейка» прежде независимых доменов. Неосновное зеркало получит, в частности, тот же ТИЦ, что был у главного зеркала, на чём и основан известный развод: мошенники продают бывший в употребление домен с большим ТИЦем доверчивам ребятам, а после «расклейки» (за счёт нового уникального контента) ТИЦ на домене обнуляется. Прошу прощения за то, что вспомнил про ТИЦ.
Новый (ранее не проиндексированный) домен
Неизвестный прежде Яндексу домен можно сделать чьим-то дополнительным зеркалом за счёт одного лишь 301-го редиректа с нового домена на основное зеркало.
Вместо итога
Проще, конечно же, определиться с главным зеркалом ещё до запуска сайта. Указать нужный домен в директиве Host для Яндекса и настроить редиректы с прочих альясов.
Но всякое бывает (захотели добавить или убрать префикс, отхватили домен по-красивее, сменили бренд или юридическое лицо), в таком случае сменить главное зеркало — вполне возможно, в чём, надеюсь, помогут представленные выше советы.
>вам (или заказчику), но я склоняюсь к варианту без префикса. Просто
>потому, что он короче, а, значит, оставит больше места в сниппете
>поисковой выдачи для остальной части адреса страницы или поместится
>целиком в твиттер без сокращателя ссылок. Если вам известны иные
>объективные преимущества того или другого варианта — расскажите о них,
>пожалуйста, в комментариях.
Не вопрос. Достаточно взглянуть на сами поисковики, пользуются ли они префиксом www.
Также автору стоит обратить внимание, что в сниппете адрес сайта НЕ участвует - сниппет отдельное поле.
Третий момент, что несмотря на то, что в приведенной выше ссылке на Яндекс адреса (анкоры) всех доменов отображаются без "www.", фактически префикс в ссылке есть (пояснение для невнимательных).
Ну и наконец, 'вэвэвэ' прочно ассоциируется в уме рядового человека с адресом сайта, который нужно вводить в адресную строку. То есть так привычнее.
Боюсь, тут разница в терминах: вы под сниппетом понимаете описание, в идеале взятое из мета-дескрипшена. Я под сниппетом, в данном случае, имел в виду весь блок выдачи, посвященный конкретному сайту (ссылку-заголовок, описание, url и пр.).
> Достаточно взглянуть на сами поисковики
И тут появляется интересное расхождение. Сравните ваш вариант с этим. Поди теперь разберись, какой у Яндекса основной домен: с www или без (чуть ниже станет ясно откуда разночтения). Но объективный способ — посмотреть на редиректы и понять, каким свой домен хотят видеть поисковики в строке адреса у пользователей. Так вот у Яндекса с этим каша: главная страница у них редиректит на www, а результаты выдачи направляются на non-www. У Гугла — всё с www.
> в приведенной выше ссылке на Яндекс адреса (анкоры) всех доменов отображаются без "www."
Верно, и кое-где (см. пример в этом комментарии) www в выдаче ещё показываются (на момент этого комментария, по крайней мере), хотя, возможно, скоро пропадёт отовсюду. Яндекс буквально недавно поменял вывод url`а, а именно срезал www и разделил домен и остальную часть пути значком «>», из-за того, что значок окружён пробелами, места для вывода url в целом не прибавилось, но зато теперь можно сразу переходить на главную страницу сайта, клика по домену — это удобно и в целом показывает, что оптимизацией url`а в интерфейсе выдачи занялись и сами поисковики.
>Я под сниппетом, в данном случае, имел в виду весь блок выдачи,
>посвященный конкретному сайту (ссылку-заголовок, описание, url и пр.).
Свое видение это, конечно, хорошо, но есть официальное определение. Еще раз повторюсь, что независимо от длинны урла - в сниппет больше знаков не влезет, чем положено.
Что творится с редиректами у Яндекса - это их личное дело. Достаточно видеть то, что для внешних поисковиков, и Яндекс и Гугл, и другие крупные сайты предпочитают выводиться с префиксом www.
>Яндекс буквально недавно поменял вывод url`а, а именно срезал www и
>разделил домен и остальную часть пути значком «>», из-за того, что
>значок окружён пробелами, места для вывода url в целом не прибавилось,
>но зато теперь можно сразу переходить на главную страницу сайта
Значки «>», о которых вы говорите, в Яндексе называются навигационными цепочками, вроде уже полгода им, если не больше.
Цитата с http://help.yandex.ru/search/?id=1111317: «В последних строчках некоторых сниппетов можно увидеть навигационные цепочки». Получается, что «другие» официальные источники как раз включают в сниппет сам url.
А вы как бы предложили называть весь кусок выдачи, посвящённый одному сайту?
> вроде уже полгода им
Вы безусловно правы в том, что навигационные цепочки не новы, но вот резать www начали, насколько я заметил, совсем недавно. Конкретной даты, к сожалению, не назову, но в тех же скриншотах помощи пользователям и веб-мастерам — ещё не резали.
Без разницы, как назвать, пусть будет "описание сайта".
Тут важно то, о чем я говорил с самого начала: длинна url на длинну описания сайта из сниппета никак не влияет. Поэтому совет в вашей статье убирать префикс www для увеличения текста в сниппете - не работает.
Но с учётом последних нововведений, по длине урла вердикт получается такой (можно считать значимым дополнением к статье):
1. Яндекс отрезает теперь www при выводе. Это случилось недавно, менее недели назад, в процессе подготовки этой и уже после публикации моей предыдущей статьи (см. скриншоты оттуда). Встречаются аномалии, пример я показывал выше, но в итоге, думаю, везде отрежут, поэтому от наличия или отсутствия www — длина выводимого в выдаче урла перестала зависеть. Это касается только вывода, реально ссылка с того же заголовка блока выдачи может вести на домен с префиксом. И это, в частности, означает, что визуальный анализ выдачи теперь не позволит определить главное зеркало. Надо смотреть куда реально ведут ссылки с заголовка (в исходном коде страницы выдачи или хотя бы наводя курсор на заголовок и глядя в статус-бар браузера) или пользоваться методом, описанным в статье.
2. Для Гугла аргумент про экономию символов в видимой части урла за счёт www — остаётся актуальным.
3. «С www привычнее» — важный аргумент, поэтому, как минимум, должны работать и приводить на сайт оба альяса (с и без www), а вот какой выбрать основным (куда редиректить) решает уже каждый владелец/создатель сайта, исходя из приоритета всех перечисленных аргументов для него лично.
www.site.ru/index.php
на www.site.ru
есть условие, что многие категории типа www.site.ru/catalog/ откликаются на www.site.ru/catalog/index.php
описать все категории возможности нет - да и как то криво.
Т.е. хотелось бы одно выражение
Сейчас пыталась использовать
RewriteCond %{REQUEST_URI} ^/index.php$
RewriteRule ^.*$ http://%{HTTP_HOST}/ [R=301,L]
Но не работает.
Было бы неплохо дополнить статью организацией постоянного редиректа силами, скажем php, так как не всегда есть возможность подключить mod_rewrite. Если нужно, могу помочь в этом вопросе.
У меня схожий вопрос, не буду дублировать, выкладываю сслыку на форум, может кто из вас подскажет?
http://webmasters.ru/forum/f74/kak-postavit%60-ssylku-na-opredelennoi-stranice-wp-v-arhive-11393/#post129404
Заранее благодарен!
С www на non-www:
Если вы хотите перенаправить на новую страницу со старой, то это делается так:
Все эти сниппеты должны находиться в PHP-коде строго до тех пор, пока что-либо отправляется на вывод.
Но рациональнее все редиректы делать силами веб-сервера — это быстрее, чем отправлять запрос аж до самого PHP.
Как организовать структуру сайтов? Папки сайтов будут совпадать это понятно. Но у меня сайты статический html и возникает потребность как то так присваивать ссылки что бы в зависимости от того на какое имя сайта зашел пользователь то имя ему бы и отображалось бы в ссылке.
То есть есть папка Articles со статьями, а в каждой статье есть ссылка на голову сайта и на страничку с перечнем всех статей. Поскольку сайты сейчас у разных хостеров, то сложности нет, но стоит перевести все к одному возникнет проблема как сделать так что бы отображалась правильная ссылка на голову и правильная ссылка на каталог статей.
Но если я на верном пути в интерпретации написанного, то совет вам такой: либо пользуйтесь относительными ссылками, либо везде в абсолютных ссылках указывайте тот домен, который принят Яндексом за главное зеркало.
Побывал так:
RewriteEngine ON
RewriteCond %{HTTP_HOST} ^domail1.ru$ [NC]
RewriteRule ^.*$ http://domail2.ru/ [R=301,L]
Но остается мусор, например:
http://domail1.ru/index.php?id=12312321&s=sadkfgawefc
редиректит на
http://domail2.ru/?id=12312321&s=sadkfgawefc
Как избавится от ?id=12312321&s=sadkfgawefc ?
Помогите пожалуйста.
читаю, перечитываю, перечитываю... понять не могу... прям зациклился в этом месте хехех :)
Скажите как все-таки "позитивно" или "негативно" будет влиять создание нескольких алиасов на рейтинг сайта? Поисковики сами склеют и проигнорируют алиасы?
Никакого вреда вы от существования альясов не получите. Пользы, впрочем, тоже.
Некоторый профит для основного домена можно получить, если на его поддоменах висят не зеркала одного и того же сайта, а независимые сайты с уникальным контентом.
http://www.armstrongsecurity.co.uk/construction-security-tunbridge-wells.html
http://www.armstrongsecurity.co.uk/construction-security-wadhurst.html
http://www.armstrongsecurity.co.uk/construction-security-crowborough.html
http://www.armstrongsecurity.co.uk/construction-security-hartfield.html
http://www.armstrongsecurity.co.uk/construction-security-edenbridge.html
http://www.armstrongsecurity.co.uk/construction-security-tonbridge.html
http://www.armstrongsecurity.co.uk/construction-security-sevenoaks.html
http://www.armstrongsecurity.co.uk/construction-security-westerham.html
http://www.armstrongsecurity.co.uk/construction-security-cranbrook.html
http://www.armstrongsecurity.co.uk/construction-security-etchingham.html
http://www.armstrongsecurity.co.uk/construction-security-mayfield.html
http://www.armstrongsecurity.co.uk/construction-security-heathfield.html
http://www.armstrongsecurity.co.uk/construction-security-uckfield.html
http://www.armstrongsecurity.co.uk/construction-security-ashford.html
http://www.armstrongsecurity.co.uk/construction-security-new-romney.html
http://www.armstrongsecurity.co.uk/construction-security-romney-marsh.html
http://www.armstrongsecurity.co.uk/construction-security-tenterden.html
http://www.armstrongsecurity.co.uk/construction-security-rye.html
http://www.armstrongsecurity.co.uk/construction-security-robertsbridge.html
http://www.armstrongsecurity.co.uk/construction-security-battle.html
http://www.armstrongsecurity.co.uk/construction-security-hastings.html
http://www.armstrongsecurity.co.uk/construction-security-winchelsea.html
http://www.armstrongsecurity.co.uk/construction-security-st-leonards-on-sea.html
http://www.armstrongsecurity.co.uk/construction-security-bexhill-on-sea.html
http://www.armstrongsecurity.co.uk/construction-security-torquay.html
http://www.armstrongsecurity.co.uk/construction-security-paignton.html
http://www.armstrongsecurity.co.uk/construction-security-brixham.html
http://www.armstrongsecurity.co.uk/construction-security-dartmouth.html
http://www.armstrongsecurity.co.uk/construction-security-kingsbridge.html
http://www.armstrongsecurity.co.uk/construction-security-salcombe.html
http://www.armstrongsecurity.co.uk/construction-security-totnes.html
http://www.armstrongsecurity.co.uk/construction-security-south-brent.html
http://www.armstrongsecurity.co.uk/construction-security-buckfastleigh.html
http://www.armstrongsecurity.co.uk/construction-security-newton-abbot.html
http://www.armstrongsecurity.co.uk/construction-security-teignmouth.html
http://www.armstrongsecurity.co.uk/construction-security-truro.html
http://www.armstrongsecurity.co.uk/construction-security-st-agnes.html
http://www.armstrongsecurity.co.uk/construction-security-perranporth.html
http://www.armstrongsecurity.co.uk/construction-security-newquay.html
http://www.armstrongsecurity.co.uk/construction-security-st-columb.html
http://www.armstrongsecurity.co.uk/construction-security-penryn.html
http://www.armstrongsecurity.co.uk/construction-security-falmouth.html
http://www.armstrongsecurity.co.uk/construction-security-helston.html
http://www.armstrongsecurity.co.uk/construction-security-camborne.html
http://www.armstrongsecurity.co.uk/construction-security-redruth.html
http://www.armstrongsecurity.co.uk/construction-security-marazion.html
http://www.armstrongsecurity.co.uk/construction-security-penzance.html
http://www.armstrongsecurity.co.uk/construction-security-isles-of-scilly.html
http://www.armstrongsecurity.co.uk/construction-security-hayle.html
http://www.armstrongsecurity.co.uk/construction-security-middlesbrough.html
http://www.armstrongsecurity.co.uk/construction-security-redcar.html
http://www.armstrongsecurity.co.uk/construction-security-saltburn-by-the-sea.html
http://www.armstrongsecurity.co.uk/construction-security-guisborough.html
http://www.armstrongsecurity.co.uk/construction-security-yarm.html
http://www.armstrongsecurity.co.uk/construction-security-stockton-on-tees.html
http://www.armstrongsecurity.co.uk/construction-security-billingham.html
http://www.armstrongsecurity.co.uk/construction-security-hartlepool.html
http://www.armstrongsecurity.co.uk/construction-security-wingate.html
http://www.armstrongsecurity.co.uk/construction-security-trimdon-station.html
http://www.armstrongsecurity.co.uk/construction-security-twickenham.html
http://www.armstrongsecurity.co.uk/construction-security-hounslow.html
http://www.armstrongsecurity.co.uk/construction-security-isleworth.html
http://www.armstrongsecurity.co.uk/construction-security-brentford.html
http://www.armstrongsecurity.co.uk/construction-security-teddington.html
http://www.armstrongsecurity.co.uk/construction-security-hampton.html
http://www.armstrongsecurity.co.uk/construction-security-feltham.html
http://www.armstrongsecurity.co.uk/construction-security-sunbury-on-thames.html
http://www.armstrongsecurity.co.uk/construction-security-shepperton.html
http://www.armstrongsecurity.co.uk/construction-security-staines-upon-thames.html
http://www.armstrongsecurity.co.uk/construction-security-egham.html
http://www.armstrongsecurity.co.uk/construction-security-southall.html
http://www.armstrongsecurity.co.uk/construction-security-hayes.html
http://www.armstrongsecurity.co.uk/construction-security-northolt.html
http://www.armstrongsecurity.co.uk/construction-security-greenford.html
http://www.armstrongsecurity.co.uk/construction-security-west-drayton.html
http://www.armstrongsecurity.co.uk/construction-security-uxbridge.html
http://www.armstrongsecurity.co.uk/construction-security-warrington.html
http://www.armstrongsecurity.co.uk/construction-security-frodsham.html
http://www.armstrongsecurity.co.uk/construction-security-runcorn.html
http://www.armstrongsecurity.co.uk/construction-security-widnes.html
best tethering app for iphone
Можно вопрос? (может быть не в тему):
К примеру, есть страница _http://www.site.ru/page.html,
а внешняя ссылка указывает на страницу _http://site.ru/page.html
Главное зеркало - с префиксом www
Даёт ли такая ссылка какой-либо эффект в плане продвижения страницы, или она бесполезна?
Заранее благодарю.