Идентификатор сессии

Это случайная последовательность символов, используемая для идентификации пользователя при его переходах по сайту. Обычно идентификатор делается достаточно длинным, чтобы он не повторялся на протяжении достаточно долгого времени. Например, в php изначально использовались идентификаторы в виде 32-значных шестнадцатиричных чисел. Если идентификация пользователя не связана с реквизитами авторизации (логином и паролем), идентификатор обычно генерируется на основе метки текущего времени (хеш md5, sha1 и т. п.), это обеспечивает его уникальность на много лет.

Идентификатор сессии обычно отсылается браузеру клиента в виде Cookie, но нередко есть вероятность, что браузер его не примет или вообще не получит. Для надежности идентификатор сессии автоматически добавляется ко всем «внутренним» ссылкам на странице в виде параметра с определенным именем (в php по умолчанию PHPSESSID, но это имя можно и переопределить). Такая технология получила название transparent SID («прозрачная» идентификация сессии).

Скрипт, использующий механизм сессий, выдает уникальный идентификатор каждому новому посетителю, не предъявившему его в Cookie и пришедшему по ссылке без идентификатора. Но поисковые боты не поддерживают Cookie. Нетрудно догадаться, что при каждом визите бота по ссылке без идентификатора ему будет выдана страница с новым идентификатором во всех ссылках. Формально ссылка с параметром PHPSESSID и без такого параметра — это две разные ссылки. Следовательно, при каждом обходе сайта бот будет получать новый набор уникальных ссылок на одни и те же страницы. Тупо индексируя эти находки, поисковик будет наполнять свою базу практически неограниченным числом страниц-дубликатов.

Как это отразится на положении сайта в поиске — нетрудно догадаться. Для тех, кто не догадался, подсказка: отразится очень плохо. Обнаружив в индексе большое количество страниц-дубликатов, поисковик оценит качество исполнения сайта как очень низкое, что неминуемо скажется на позициях в поиске. Но это еще не все. Поисковику совсем не нужно тратить свое дисковое пространство на ваши бесконечные дубли, поэтому он рано или поздно начнет чистить базу от этого мусора. Не рассчитывайте на разумный подход к чистке: поисковик — не человек, а тупая машина, думать он не умеет, соображать не обучен и интуиции ему не дано. Поэтому нечего удивляться, если он выметет из своей базы всё старьё (в том числе ссылки без идентификаторов), а оставит самое свежее и актуальное (ссылки с идентификаторами, которые собрал при последнем обходе сайта). Или выкинет страницу без идентификатора, а с идентификатором оставит, потому что Вася Пупкин дал на нее ссылку в своем блоге, а на страницу без идентификатора никаких ссылок нет. Значит, она менее важная.

Волшебных кнопок на все случаи жизни не бывает. Поэтому пути могут быть разными в зависимости от целей, которые вы ставите. Например, для форума и для интернет-магазина возможны принципиально разные решения.

Самый простой выход — вообще запретить механизм «прозрачной идентификации» сессий, оставив идентификацию только через Cookie. Так, например, построена работа форума SEO-board. В php для полного запрета достаточно изменить настройки, прописав в .htaccess вот такое заклинание:

php_value session.use_trans_sid 0
php_value session.use_only_cookies 1

Первая строка предписывает отключить механизм передачи идентификаторов в ссылках, вторая — использовать только Cookie для идентификации сессий.

Метод действенный и надежный, при его применении идентификаторы сессий в URL не появляются и не поддерживаются. Недостаток очевиден — если клиент не отдает Cookie (или не получил, поскольку не прошли через плохо настроенный прокси), то и идентифицировать такого клиента невозможно.
«Не поддерживаешь Cookie? Давай, до свидания». Авторизоваться на вашем сайте такой пользователь не сможет. А если у вас интернет-магазин — возможно, вы потеряли покупателя, поскольку он не сможет оформить заказ. Так что самые простые решения — не всегда самые лучшие.

Сравнительно новый метод, поисковиками он поддерживается не так давно. Реализуется программно, в секцию <head> страницы нужно внедрить тег канонизации:

<link rel="canonical" content="http://your-domain.tld/your-uri-without-session.html">

Тем самым сообщить, что истинным адресом этой страницы является тот URI, который указан в содержании тега, а если страница выдается по иному адресу — это технический дубликат и индексировать его не нужно.

Почти то же самое, что и с канонизацией. В случае, если в запросе клиента указан URI с идентификатором сессии, в секцию <head> вставляется мета-тег robots с запретом индексирования страницы. Например, вот так:

<meta name="robots" content="noindex, nofollow">

Или так (не рекомендуется):

<meta name="robots" content="noindex, follow">

Разница невелика: второй вариант разрешает боту следовать по ссылкам, обнаруженным на странице, но оба варианта запрещают индексирование страницы. Для защиты от дубликатов с сессиями второй вариант нежелателен: никаких нужных ссылок на этой странице поисковик все равно не найдет — все ссылки будут с идентификатором сессии.

Оба варианта защиты с тегами (канонизация и мета robots) имеют один явный недостаток: чтобы поисковик «узнал», что эту страницу нельзя брать в индекс, он должен сначала ее считать и разобрать. Поскольку обход страниц сайта роботы проводят не сразу, а небольшими порциями в порядке очереди, это отвлекает бота на сканирование и разбор ненужных страниц. А значит, новые попадут в индекс позднее, чем хотелось бы; сначала бот будет обходить ранее запланированные «дубли».

Чтобы избежать обработки в поисковиках страниц с идентификаторами в URL, есть два пути. Там, где сессия сопутствует авторизации пользователя, нужно открывать сессии только после логина. Там, где необходимо идентифицировать любого пользователя, нужно определять ботов (например, по полю User-agent в заголовке запроса) и сессию для них не открывать. А при запросе ботом URL с идентификатором сессии отдавать в заголовке статус «404 Not Found». Это позволяет избежать попадания в очередь на сканирование новых ссылок с идентификаторами, а те дубли, которые поисковик уже успел проиндексировать — удалить из индекса.