Автор: Сергей Людкевич - независимый консультант, супермодератор форума о поисковых системах Searchengines.Guru.
Сфера профессиональных интересов - исследование алгоритмов ранжирования поисковых машин, разработка методик поискового продвижения сайтов.
Нередки ситуации, когда поисковые системы индексируют на сайте большое количество страниц, не несущих с их точки зрения полезной информации – четкие или нечеткие дубликаты страниц, технический мусор, служебные страницы и т.п. Эти страницы могут стать препятствием для своевременной переиндексации и корректного ранжирования сайта, поэтому очень желательно минимизировать их количество в индексе. Сделать это можно разными способами, которые можно разбить на две большие группы: запрет к индексации и склейка с другими страницами сайта. Рассмотрим особенности каждого из способов и предпочтительные варианты их применения.
Основное различие запрета и склейки заключается в том, что в случае склейки, нетекстовые характеристики подклеиваемой страницы (назовем ее неканонической), такие как значения ссылочных, поведенческих и временных факторов, будут суммированы со значениями соответствующих факторов целевой страницы (назовем ее канонической). В случае же запрета индексации, вся эта информация будет просто потеряна. Поэтому запрещать к индексации в первую очередь имеет смысл те страницы, которые не имеют сколько-либо значимых значений нетекстовых характеристик, например, отсутствуют ссылки, ведущие на них, а количество трафика на этих страницах совершенно незначительно. Как правило, это служебные страницы, например, rss-лента, личные кабинеты пользователей или результаты поиска по сайту.
Запрет индексации страницы можно осуществить следующими способами: - С помощью директивы Disallow в секции для соответствующего юзер-агента поисковика файла robots.txt
- С помощью значения noindex директивы content мета тега robots
В первом случае не будет расходоваться краулинговый бюджет, выделенный на переиндексацию страниц сайта, имеющих отклик 200 OK, т.к. индексирующий робот просто не будет обращаться к запрещенным в файле robots.txt страницам. Поэтому этот способ в общем случае более предпочтителен. Во втором случае робот будет скачивать страницы, и только после их скачки будет обнаружена запрещающая индексацию директива. Таким образом, краулинговый бюджет сайта будет частично расходоваться на постоянную переиндексацию подобных страниц.
Частично эту проблему можно решить с помощью корректной настройки обработки запроса If-Modified-Since (подробнее см. в моей статье «Заголовки Last-Modified и If-Modified-Since»). Более того, во втором случае запрещенные к индексации страницы на некоторое время могут попадать в индекс. Причем это время может быть и не таким уж их краткосрочным, имеют место случаи, когда счет идет даже не на дни, а на месяцы. Поэтому второй способ целесообразно использовать только в следующих случаях: - Если число таких страниц достаточно велико, а особенности их URL таковы, что не представляется возможным достаточно компактно перечислить их в директивах файла robots.txt с помощью правил стандарта исключений для роботов и поддерживаемых поисковиками его расширений (например, см. соответствующую документацию для Яндекса и Google). Так, Яндекс имеет ограничение на размер файла robots.txt в 32 кб, а Google - в 500 кб.
- Если запрещаемые к индексации страницы в силу каких-либо причин являются единственным источником внутренних ссылок на те страницы сайта, которые должны находиться в поисковом индексе. В этом случае директива content мета тега robots кроме значения noindex должна иметь также значение follow, разрешающее поисковому роботу переходить по ссылкам на странице.
Как уже было сказано выше, склейка страниц, в отличие от запрета к индексации, позволяет суммировать значения нетекстовых факторов подклеиваемой (неканонической) страницы с соответствующими значениями целевой (канонической) страницей. Склейку можно осуществить следующими способами: - С помощью редиректа с откликом 301 Moved Permanently
- С помощью директивы Clean-param в файле robots.txt (только для специальных случаев URL с динамическими параметрами)
- С помощью атрибута rel=”canonical” тега link
301-й редирект применим в тех случаях, когда содержимое неканонической страницы полностью идентично содержимому канонической, поэтому в этом случае пользователя можно просто перенаправить с одного URL на другой. В этом случае при обращении к неканоническому URL не происходит расхода краулингового бюджета, так как он имеет отклик, отличный от 200. Следует иметь ввиду, что в случае использования редиректа с откликом 302, склейки не произойдет.
Этот способ целесообразно применять, к примеру, при смене структуры URL сайта или для склейки дублей URL со слэшом на конце и без него. Если же по неканоническому URL необходимо отдавать пользователю содержимое, т.е. он должен иметь отклик 200, то в этом случае необходимо использовать два других способа склейки.
Использование директивы Clean-param в файле robots.txt ограничивается только страницами, имеющими в URL динамические параметры. Это могут быть как параметры, не влияющие на содержимое (например, идентификаторы сессий или рефереры), так и влияющие (например, режимы сортировки). Неканонический URL подклеивается к каноническому, который образован путем удаления указанных в директиве параметров. Естественно, что такой канонический URL должен иметь отклик 200, иначе никакой склейки не произойдет. Данный способ также не приводит к расходу краулингового бюджета, т.к. в этом случае поисковый робот просто не будет скачивать неканонический URL. Однако, надо иметь в виду, что по этой же причине поисковику будут неизвестны ссылки, находящиеся на неканоническом URL. Поэтому целесообразно применять этот способ в случаях, когда «обрезаемые» параметры не влияют на содержимое страницы либо значений этих параметров может быть достаточно много, чтоб оказать заметное влияние на расход краулингового бюджета (например, результаты поиска по сайту).
И наконец, третий вариант, который мне представляется во многих случаях наиболее предпочтительным - это использование атрибута canonical тега link. К плюсам этого метода относится то, что, как и при любой склейке, происходит суммирование нетекстовых факторов неканонической и канонической страниц (что, кстати, непосредственно подтверждено сотрудником Яндекса Александром Смирновым на Шестой Вебмастерской) плюс происходит учет ссылок, находящихся на неканонической странице (что также было непосредственно подтверждено в блоге собирательного образа службы поддержки Яндекса Платона Щукина).
Единственный минус этого метода - это то, что неканонические страницы в силу того, что они имеют отклик 200, так же, как и в случае с noindex в мета-теге robots, будут выбирать краулинговый бюджет. И так же неканоническая страница может довольно продолжительное время находится в индексе до того момента, как будет склеена с канонической.
Тем не менее данный способ отлично подходит, например, для склейки страниц пагинации, различных вариантов сортировки, результатов применения фильтров к спискам и т.п., а также «обрезания» динамических параметров URL. Кстати, что касается пагинации, то сотрудники Google рекомендуют использовать атрибуты rel="next" и rel="prev" тега link. Однако Яндекс не поддерживает эти директивы. Поэтому я все-таки рекомендую использовать rel=”canonical” для обоих поисковиков, тем более, что практика показывает, что эта директива прекрасно работает и в Google. Есть различие между Яндексом и Google и непосредственно в обработке директивы rel=”canonical” - Яндекс, в отличие от Google, не поддерживает кросс-доменность этой директивы, то есть нельзя склеить страницы, находящиеся на различных поддоменах.
И в заключение хотелось бы отметить, что следует избегать многократного последовательного применения директив склейки. Например, цепочек редиректов или указания в качестве канонической страницы, которая сама содержит директиву rel=”canonical” на с указанием третью страницу. Равно как и последовательно комбинировать различные методы склейки.
Например, когда URL, получающийся в результате «обрезания» параметров с помощью директивы Clean-param, в свою очередь является неканоническим. В подобных случаях поисковик может просто проигнорировать директивы. |
Комментариев нет:
Отправить комментарий