Текст был переведен с помощью
сервиса переводов в режиме онлайн — PerevodBy\.ru
Всякий раз при внесении изменений на веб-сайте необходимо рассмотреть один из важнейших вопросов — как использовать редиректы (переадресацию), чтобы оповестить поисковые системы об изменениях и избежать негативного воздействия на позиции сайта в поисковых системах. Меняете ли вы расположение страниц, переходите ли на другую CMS (систему управления сайтом), или просто хотите избежать дублирования контента и понижения PageRank страниц, — в любом случае возникнет желание использовать редиректы, чтобы не растерять потенциал страниц, выраженный в ссылочном весе (PageRank) и накопленный вашим сайтом. Существует множество видов переадресации, или редиректа, и важно их использовать правильно, если вы хотите оптимизировать сайт под поисковые системы и не рисковать нарушением их руководства для вебмастеров (как в случае с «условными редиректами»).
Программисты и системные администраторы, которые не слишком смыслят в оптимизации поисковых систем, любят использовать по умолчанию «временный редирект», также известный как «редирект 302». К несчастью, при использовании этого редиректа поисковая машина не передает ссылочный вес с переадресованной ссылки на целевую. Не то чтобы это было нарочитой халатностью программистов. Это тот случай, когда нельзя помнить о том, чего ты не знал.
Просто стоит им мягко намекнуть, что на самом деле стоит использовать «постоянный редирект», или «редирект 301». Если они спросят почему, ответьте, потому что так сказал консультант по поисковой оптимизации.
Какими могут быть случаи применения, или «юзкейсы», редиректа 301? Некоторые из них я упоминал во введении, но давайте изучим несколько сценариев более подробно... Вообще говоря, если вы собираетесь менять какие-либо ссылки, следует использовать 301 редирект, так же как и в случае изменения доменных имен (старыйнудныйдомен.com на новыйдомен.com). Или если проект переводится на другую CMS, что приведет к изменению ссылок на все страницы вашего сайта.
Можно использовать 301 редирект даже в случае «удаления» определенных страниц в архив (например, «Каталог рождественских подарков» по окончании периода праздничных закупок — хотя я допускаю тот случай, что вы захотите сохранить эту страницу навсегда по ссылке без даты, позволите ссылочному весу накапливаться по этой ссылке для использования в следующем году, и НЕ будете пользоваться редиректом вообще).
Потом, иногда возникают ситуации, когда желательно уменьшить число 301-х редиректов, например, когда множество ссылок ведут на одну и ту же страницу, что создает множественные копии этой страницы в поисковых системах. Дублированный контент — это достаточно плохо, но гораздо бОльшая проблема — это «размывание PageRank страницы» («PageRank dilution») при котором ссылки распределяются между различными версиями, вместо того чтобы сосредоточиться на единой, определенной, «канонической» ссылке. Это может случиться при добавлении к ссылке кода слежения (например, «?source=SMXad»). Такой пример дублирующихся страниц с добавленными к ссылке кодами слежения, проиндексированных поисковиком Google , можно найти здесь — забавно, но это собственный сайт компании Google (да, такое случается с каждым из нас, даже с Google!). Или когда основные параметры не всегда задаются последовательным образом (например, «?subsection=5§ion=2» versus «?section=2&subsection=5»).
Или когда заданы определенные параметры поиска, но их изменение особо не меняет контент (например, «?photos=ON» против «?photos=OFF»).
Или когда множество доменов или субдоменов соответствуют запросу, имея одинаковый контент при отсутствии редиректа (например,v «jcpenney.com/jcp/default.aspx» и «www1.jcpenney.com/jcp/default.asp» и «jcp.com/jcp/default.asp» и «jcpenny.com/jcp/default.asp» и «www.jcpenney.com/jcp/default.asp»). Во всех вышеперечисленных случаях, редирект 301 с переадресацией на «канонический» URL станет спасением.
Как правило, для борьбы с большим количеством ссылок используется «правило единого редиректа» . Оно связано с «сопоставлением с образцом», и позволяет использовать групповые символы (такие как звездочка), чтобы зафиксировать часть запрошенного URL в памяти и позже утилизировать его с помощью редиректа. Это возможно, если вы пользуетесь Apache или Microsoft IIS Server в качестве веб-сервера.
Давайте рассмотрим некоторые из приведенных выше примеров и принципы работы с ними с помощью модуля mod_rewrite, который используется в Apache:
# Изменение доменных имен
RewriteCond %{HTTP_HOST} tiredoldbrand.com$ [NC]
RewriteRule ^(.*)$ http://www.newbrand.com/$1 [R=301,QSA,L]
# Удаление параметра слежения (но отслеживаемый URL остается зарегистрированным в анализе). Другие параметры не учитываются.
RewriteCond %{QUERY_STRING} ^source=
RewriteRule ^(.*)$ $1 [R=301,L]
# Перестановка параметров
RewriteCond %{QUERY_STRING} ^subsection=([0-9]+)§ion=([0-9]+)$
RewriteRule ^(.*)$ $1?section=%2&subsection=%1 [R=301,L]
# Переадресация с домена без www на домен с www
RewriteCond %{HTTP_HOST} ^example.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,QSA,L]
Приведенные выше примеры следует задавать немного иным образом при использовании веб-сервера Microsoft IIS Server. К примеру, при использовании плагина ISAPI_Rewrite для IIS Server, используйте «RP» вместо «R=301.»
В некоторых случаях сопоставление с образцом невозможно и требуется таблица соответствия. Это легко решается с помощью создания текстового файла, к которому будут происходить обращения с помощью директивы «RewriteMap».
Можно даже использовать для обращения скрипт, который будет выполнять некоторые действия «найти-и-заменить», вместо текстового файла, например вот такой:
# Найти и заменить по цепочке запросов часть URL, с использованием моего собственного Perl-скрипта
RewriteMap scriptmap prg:/usr/local/bin/searchandreplacescript
RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^(.+)$ $1?${scriptmap:%1} [R=301,L]
Вас заинтриговала эта гиковская заумь и вы хотите больше узнать о сопоставлении с эталоном и правилах подстановки? Тогда вам стоит изучить мою презентацию Unraveling URLs, озвученную на SMX West (Search Marketing Expo — популярная западная конференция по интернет-маркетингу).
Существует еще один тип редиректа, который стоит упомянуть — это «условный редирект». Стоит предупредить: он может создать вам большие проблемы с Google. Мэтт Катс (Matt Cutts), глава подразделения Google Webspam, советовал в своем докладе на SMX Advanced: ребята, не используйте условные редиректы, это чревато наказаниями или бана со стороны Google. Для тех, кто не знаком с этим термином, поясню: при условном редиректе избирательно используется редирект 301 для поисковых роботов типа Googlebot.
Очевидно, когда вы начинаете предоставлять людям контент, отличный от того, что вы предоставляете поисковым роботам (и да, сюда же относятся отличные друг от друга редиректы), вы вступаете на опасный путь с точки зрения поисковых систем. Вы можете быть хорошим парнем с наилучшими намерениями, но риск все равно остается.
Рассмотрим упомянутый выше случай на примере двух URL на страницы с приблизительно одинаковым контентом: один содержит строку «photos=OFF», второй «photos=ON», и оба получают какое-то количество ссылок. Вы можете привести следующий веский аргумент: чтобы избежать дублирования контента и понижения PageRank, обе версии следует объединить в одну, но только для Googlebot. В конце концов, если поставить редирект на ВСЕ запросы, пользователи с узким каналом связи могут не каждый раз дождаться загрузки изображений конечного продукта. Однако это неверный выбор.
На самом деле, вам не нужен редирект вообще, не говоря уже об условном. Вам стоит добавить параметр rel=nofollow ко всем ссылкам, ведущим на photos=OFF, чтобы не тратить ссылочный вес на этот вариант. Затем сделайте photos=ON загружаемым по умолчанию, когда параметры не определены, и удалите photos=ON из ссылок, если они есть, и из всех внутренних ссылок.
Или рассмотрим случай необходимости накопления параметров слежения на протяжении сессии пользователя. При использовании условного редиректа роботы, запрашивающие отслеживаемый URL, могут быть перенаправлены вместо этого на «канонический» URL (а именно URL минус параметр слежения) — это улучшает целостность вашей системы отслеживания пользователей, но без необходимости слежки за поисковыми роботами или создания многочисленных копий страниц в поисковых системах.
И опять, я готов спорить, что можно найти другой способ справиться с этой проблемой без использования условных редиректов. Например, можно сохранять параметры запроса в файлах cookie одновременно с безусловным редиректом на «канонический» URL, по мере поступления запроса для отслеживаемого URL.
Несомненно, условные редиректы могут помочь в решении сложных проблем легального бизнеса. Как бы там ни было, один из крупнейших интернет-магазинов в мире использует условные редиректы, в чем я убедился перед SMX Advanced. Интернет-магазин перенаправляет поисковых роботов, запрашивающих URL ее аффилиатов, на основной, «канонический» URL продукта, что позволяет захватывать ссылочный вес сайтов-партнеров. Для их сферы деятельности это остроумное решение. Но подход рискованный.
Вместо этого интернет-магазин мог бы перенаправлять ВСЕХ посетителей — людей и поисковых роботов — на «канонический» URL без ID аффилиатов. Это может вызывать раздражение некоторых партнеров, поскольку они заметят, что теперь интернет-магазин отбирает PageRank у них. Но знаете что? Филиалу вполне под силу не отдавать вес; они могут просто добавить параметр «nofollow» в ссылки. Таким образом, вопрос переходит в область общественных отношений и касается методов управления интернет-магазина своими аффилиатами, с помощью перехода на безусловный редирект 301 и напоминания партнерам о праве использовать «nofollow» в ссылках.
Другой сценарий, с которым я познакомился совсем недавно, используется крупным собственником медиа-порталом. При этом условные редиректы применяются в двух типах ссылок. Первый тип ссылок снабжен параметрами слежения, позволяющими дифференцировать переходы по ссылкам, ведущим на такой же контент. Использование условного редиректа позволяет им избегать дубликатов и накапливать PageRank. Но угадайте что дальше? Если бы редирект был безусловным, клики все равно могли быть дифференцированными, поскольку URL, на который был совершен переход, все еще регистрировался бы в логах.
То же самое справедливо и в случае когда параметры слежения используются для различения маркетинговых программ/источников трафика. Когда запрос приходит по ссылке, содержащей, например, «?source=blog,» нет необходимости посылать посетителей-людей в другое место. Даже если источник трафика должен быть определен во время сессии пользователя и затем включен как скрытое поле в форму запроса «Связаться с нами» (Contact Us) на сайте, этого можно достичь используя cookies и сохраняя источник информации в переменной сеанса. Условный редирект не требуется.
Другой тип ссылок, в которых эта компания использует условный редирект, ведет на сайты компаний-партнеров. Как мы и предполагали, контент по большей части дублируется. Этот вопрос не решается простым переходом на безусловный редирект, поскольку доля прибыли партнера от рекламы рассчитывается с учетом числа посетителей отдельного субдомена. Если будет использоваться безусловный редирект на «канонический» URL главного субдомена, каждая сессия сократится с нескольких просмотров страницы до одного единственного. Прибыль партнера значительно упадет, и между партнерами могут возникнуть разногласия. Можно использовать сookies для слежения за сессией полностью — немаловажно, что для этого на них надо переключиться — но даже при применении Cookies надо учитывать: значительное число посетителей используют Norton Internet Security или аналогичные утилиты, которые мешают партнеру получить потенциальную прибыль от переходов по ссылкам. Это серьезное затруднение. Как обойти эту проблему, я еще не вычислил.
Еще один сценарий, при котором могут использоваться условные редиректы — это когда ссылки сайта заменяются дружественными для поисковых роботов. Это может стать серьезным начинанием, которое займет месяцы, а то и годы, с целью раскрутить большой и сложный вебсайт. Одна компания, занимающаяся продажами принадлежностей для отдыха, потратила на перезапись ссылок более двух лет и более1000 человеко-часов и все еще ее не закончила. Не всегда реально перезаписать все ссылки или убрать все ссылки, недружественные к поисковым роботам. Чем больше сайт и чем менее гибка CMS, тем больше будет головной боли. В такой ситуации условный редирект поможет устранить дублирующийся контент и перенаправлять PageRank на дружественную к поисковым роботам версию каждой ссылки до тех пор, пока все недружественные ссылки на сайте не будут заменены. Альтернативный вариант: дубликатов можно избежать с помощью запрета robots.txt или noindex всех неружественных к поисковикам ссылок, но это может быть невыполнимо, если перезапись ссылок еще не закончена, и это не позволит перенаправить PageRank на перезаписанную версию ссылки.
Я могу показать вам один обходной маневр, который позволяет отказаться от использования редиректов вообще — включая условные. Особенно он полезен для слежения, и включает в себя добавление кода слежения к ссылке таким образом, что отслеживаемый URL автоматически сжимается поисковиком. Нет, это не требует использования JavaScript. Любопытно, но я даже не слышал, чтобы этот метод кем-либо обсуждался. Метод основан на использовании символа # (также известного как «решетка»), который обычно используется для направления посетителей на «заякорную» часть страницы. Просто добавьте # к ссылке, после чего последует код слежения или ID.
Например: www.example.com/widgets.php#partner42. Поисковые роботы проигнорируют символ # и все, что за ним следует, таким образом PageRank накапливается, а дублирования контента не происходит.
Надеюсь, это поможет вам критично подумать об использовании редиректов — временных, постоянных и условных — и последствиях их использования для оптимизации сайта под поисковые системы. Перейдите на постоянные редиректы (301) с временных (302), если хотите перенести ссылочный вес. Использования условных редиректов следует избегать, при высоком риске пенализации. Я уверен, что если вы придирчивым взглядом окинете все случаи, в которых «необходимо» использовать условные редиректы, вы поймете, что не нуждаетесь в них вообще.
Стефан Спенсер (Stephan Spencer) — основатель и президент Netconcepts