Холивар, кстати, довольно конструктивный, там участвует умный дядька богоносец и хитрый дядька 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:
- CMS вычисляет для страницы канонический URL
- Если $_SERVER['REQUEST_METHOD'] == 'HEAD', отдаем 301 Moved Permanently + Location: канонический_урл.
- Иначе отдаем 200 OK, показываем контент и добавляем rel=canonical для поисковиков, не делающих HEAD-запрос.
Если я не прав по поводу HEAD-запросов (например, краулер сразу спрашивает GET, но обрывает соединение, встретив не-200 статус в заголовках), наверное можно позволить себе использовать клоакинг и отдавать 301 редирект для поисковиков, ориентируясь на User-Agent. Кстати, по этому поводу сейчас напишу Платонам.
UPD: письмо Платонам улетело :)
У кого есть что сказать, полажуйста, не стесняйтесь :) Учитывая мое место работы, у нас есть реальный шанс получить первую массовую систему с нормальным алгоритмом обработки этой беды! :)
