Dubrowsky
Хроники одного дупла
Блогово  →  SEO  → 

CMS и борьба с дублями страниц в индексе

10 Апреля 2013 года

Меня тут коллеги из NetCat попросили поучаствовать в топике на серче. Топик был о другом, но свелось все (как оно часто случается) к холивару по поводу дублей страниц в поисковых индексах и о том, как CMS должны с этим бороться.

Холивар, кстати, довольно конструктивный, там участвует умный дядька богоносец и хитрый дядька burunduk (Алексей Жуков). Ознакомьтесь. Итак, проблема дублей - простая и очень вездесущая.

Заключается она в том, что практически любой сервер одинаково ответит на запросы http://site.ru/ и http://site.ru/?ololo (если get-параметр ololo специально не обрабатывается в скриптах). При этом любой поисковик сочтет это разными страницами, если специально не поколдовать. В итоге - дубли в индексе, замедление обхода сайта краулером и траблы из серии "Яндекс выбрал не ту морду".

Вот некоторые мои мысли о самой проблеме и путях ее решения на уровне CMS.

1. Есть ли проблема дублей?

Сейчас, насколько мне известно, ни один распространенный движок не предлагает готового решения по борьбе с "неожиданными" параметрами в URL. Таким образом под угрозу попадает абсолютное большинство сайтов в сети.

Поэтому (идеологически) поисковики должны стремиться сами решить эту проблему, то есть сделать так, чтобы это перестало быть проблемой. Они заинтересованы в чистоте индексов и в том, чтобы пользователю отдавался наиболее релевантный ответ.

На практике, как водится, это не совсем так. Об этом можно судить, с одной стороны, по наличию веб-мастеров, столкнувшихся с неправильным определением "правильной" страницы, с другой стороны - по наличию специализированных инструметов, которые поисковики предлагают вебмастеру для управления выбором "правильных" страниц (у Яндекса - инструкция Clean-param для robots.txt, у Гугла - управление параметрами через панель вебмастера, у обоих - rel=canonical). То есть поисковики перекладывают ответственность за эту проблему на плечи вебмастеров, значит сами не вполне справляются и проблема существует.

2. Способы решения: как не должно быть?

Для начала, нужно определиться, что должен отдавать сайт в ответ на запрос http://site.ru/?ololo - для меня это не очевидно. И вот еще: пусть параметр называется не ololo (который может появиться только по ошибке или по злому умыслу), а utm_source - и его добавил маркетолог к рекламной кампании.

Первое, что приходит на ум - отдавать 404 заголовок, если обработка параметра в скриптах не предусмотрена. При этом можно либо показать обычный контент страницы, либо вывести сообщение об ошибке. Кстати, на этом блоге реализован именно последний вариант :)

Мои опыт и интуиция, посовещавшись, пришли к выводу: если юзер видит в браузере нормальный контент, перед ним должен прилететь 200 OK заголовок. Если прилетает 4xx заголовок, юзер должен увидеть сообщение об ошибке. 

Во-первых, мы не знаем, как поведет себя некий юзер-агент, получив 4xx-заголовок. Вместо нашего красивого контента, он вполне может вернуть свою некрасивую заглушку (например, если он - мобильный клиент и пытается экономить трафик). И пользователь (за которого мы отвалили 10 центов адвордзу) будет потерян.

Во-вторых, если пользователь все-таки увидит нормальный контент, и контент ему понравится, он может скопировать URL из адресной строки и сослаться на нас со своего хомпейджа (с PR8 непременно!). И будем мы, как дебилы, иметь ссылку с PR8, ведующую на 404 страницу.

Если же мы будем серверно редиректить юзера на правильную страницу (очистив URL от неизвестных нам параметров), клиентский счетчик статистики не получит своих меток и маркетолог будет горько-горько плакать. Представьте продвигает он букмекерскую контору (Компания Фон бет - это букмекерская контора live в Москве.), смотрит в статсы, а там болт :(((((

3. А как должно быть?

Я считаю, что наиболее правильный способ работы в такой ситуации - отдавать в заголовках 200 OK, показывать страницу, но добавлять rel="canonical". Таким образом мы не теряем ссылочный вес (насколько я понял из доков и обсуждений, дубли по rel="canonical" склеиваются аналогично страницам с 301 редиректом). С другой стороны, мы не теряем и параметры, которые могут оказаться нужны кому-то, о ком мы не заранее знаем (например, счетчику статистики).

Умный юзер богоносец справедливо отмечает, что в этом случае все равно тратится лимит на число скачиваний документа с сервера, соответственно замедляется общая скорость индексации полезных документов. Если предположить, что поисковики сперва делают head-запрос и проверяют статус, можно предложить следующий workaround:

  1. CMS вычисляет для страницы канонический URL
  2. Если $_SERVER['REQUEST_METHOD'] == 'HEAD', отдаем 301 Moved Permanently + Location: канонический_урл.
  3. Иначе отдаем 200 OK, показываем контент и добавляем rel=canonical для поисковиков, не делающих HEAD-запрос.

Если я не прав по поводу HEAD-запросов (например, краулер сразу спрашивает GET, но обрывает соединение, встретив не-200 статус в заголовках), наверное можно позволить себе использовать клоакинг и отдавать 301 редирект для поисковиков, ориентируясь на User-Agent. Кстати, по этому поводу сейчас напишу Платонам.

UPD: письмо Платонам улетело :)

У кого есть что сказать, полажуйста, не стесняйтесь :) Учитывая мое место работы, у нас есть реальный шанс получить первую массовую систему с нормальным алгоритмом обработки этой беды! :)

Камменты

DrJeans23.08.2013, 13:40#
Клоачить не бро! Для сайта в 100 страниц лимиты пох, пишем канонический урл и всё, странно, что НетКат этого не сделал до сих пор по дефолту.
Дуброн самый23.08.2013, 17:10#
Серег, Платоны не видят нарушений в клоакинге, есличо :)

Про НетКат: могу только предположить, что возможная ошибка при вычислении canonical может привести к удалению реального контента из индекса. Ошибка может произойти, если в конкретном пользовательском решении используется параметр, про который система ничего не знает. Вред от такой ошибки выше, чем потенциальная польза. Сугубо ИМХО =)
DrJeans23.08.2013, 17:20#
Каким образом это может произойти? Если прогер криворукий и позволил образоваться полезному контенту по урлу ?par=bla&par2=blabla

Это проблемы криворукости прогера, а не системы! Весь полезный контент всегда лежит под ЧПУ!

Написать коммент: памятка постеру

 

Крутые посты wtf??? →

15.03.2012 · 21 каммент · рейтинг 6.01
08.02.2008 · 25 камментов · рейтинг 5.63
05.02.2008 · 18 камментов · рейтинг 4.77
02.03.2012 · 12 камментов · рейтинг 4.53
24.08.2007 · 13 камментов · рейтинг 4

Последне камменты

16.05.2023  8DC0WIM www.yandex.ruРеклама паблика вконтакте, как меня модерировали: 8DC0WIM www.yandex.ru
16.05.2023  EWDOLQG7E28H www.yandex.ruНакрутка сердечек и групп вконтакте через V-Like.ru: EWDOLQG7E28H www.yandex.ru

Статсы