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

Идентификатор сессии (session ID) – это уникальная строка, которую сервер выдаёт посетителю, чтобы узнавать его на следующих запросах: помнить корзину, вход в личный кабинет, выбранный город. Обычно он хранится в cookie, реже передаётся прямо в адресе страницы.

Протокол HTTP ничего не помнит: каждый запрос для сервера новый. Человек положил товар в корзину, перешёл на другую страницу, и без идентификатора сервер не узнал бы его. Пока ID живёт в cookie, его никто не видит. Проблемы для SEO начинаются, когда он попадает в URL.

Как сервер узнаёт посетителя по идентификатору

1. При первом заходе сервер создаёт сессию: запись, где будут храниться данные посетителя.
2. Сервер отправляет браузеру её номер. В PHP cookie по умолчанию называется PHPSESSID, в Java JSESSIONID, в ASP.NET ASP.NET_SessionId.
3. Браузер прикладывает этот номер к каждому следующему запросу, и сервер находит по нему корзину и авторизацию.

Не путайте с сессией в веб-аналитике. Там так называют визит, серию просмотров одного человека, которую считает Метрика или Google Analytics, и к серверному идентификатору она отношения не имеет.

Как PHPSESSID в адресе плодит дубли

Если cookie отключены или сайт настроен по старинке, сервер дописывает ID к каждой ссылке. Адреса выглядят так (условный пример):

/catalog/smesiteli/?PHPSESSID=8f3a1c07d2
/catalog/smesiteli/?PHPSESSID=b72e90a4f1
/catalog/smesiteli/;jsessionid=5C1F0A9E

Поисковый робот обычно не хранит cookie между визитами, поэтому при каждом обходе получает новый идентификатор и новый набор адресов с тем же содержимым.

Чаще всего такое встречается на старых магазинах и форумах на самописных движках, на Java-платформах с хвостом ;jsessionid и в корзине, сравнении и личном кабинете. Похожим образом адреса размножают метки UTM и сортировки, и лечатся они теми же способами.

Чем это оборачивается для SEO:

• Появляется дублированный контент: одна страница под множеством адресов.
• Робот тратит краулинговый бюджет на копии и позже доходит до новых страниц.
• Ссылки, которыми делятся люди, ведут на разные адреса, и сигналы распыляются.
• В выдачу попадает адрес с чужим идентификатором.

Google в рекомендациях по структуре URL прямо называет такие идентификаторы источником лишних дублей и советует держать их в cookie.

Как найти адреса с сессией и убрать её из URL

Прогоните сайт краулером и отфильтруйте URL с параметрами sid, sessid, PHPSESSID, jsessionid. В Яндекс Вебмастере посмотрите исключённые страницы и дубли, в Search Console отчёт об индексировании с причинами вроде «Страница является копией». По логам сервера, если они доступны, видно, сколько обходов робота уходит на такие адреса впустую.

Вручную это видно так: отключите cookie в браузере и пройдите по цепочке каталог, товар, корзина. Появился в адресной строке параметр с длинной случайной строкой, значит, идентификатор идёт через URL. Заодно посмотрите исходный код: иногда ID вшит прямо в ссылки меню и виден только там.

Когда адреса найдены, порядок такой:

1. Хранить идентификатор только в cookie. В PHP за это отвечают настройки session.use_only_cookies и session.use_trans_sid: первая должна быть включена, вторая выключена. В современных версиях это значения по умолчанию, но старые конфигурации их иногда меняют.
2. Для адресов с ID, которые уже попали в индекс, настроить 301 редирект на адрес без параметра или указать canonical на чистую версию.
3. Для Яндекса добавить в robots.txt директиву Clean-param: робот будет считать адреса с разными значениями параметра одной страницей.

User-agent: Yandex
Clean-param: PHPSESSID&sid

Google директиву Clean-param не поддерживает, а инструмент параметров URL в Search Console он отключил в 2022 году. Для Google опора на редиректы и canonical. Закрывать такие адреса через Disallow хуже: робот не сможет зайти на страницу и не увидит canonical.

Чем идентификатор в ссылке опасен для аккаунтов

ID в адресе легко утекает: через пересланную ссылку, скриншот, заголовок Referer при переходе на другой сайт. Тот, кто получил идентификатор, может оказаться в чужой сессии. Поэтому сессию защищают: передают ID только в cookie с флагами HttpOnly, Secure и SameSite, выдают новый идентификатор после входа в аккаунт и не принимают ID, которые сервер не создавал. Чинит это разработчик, а замечает проблему часто SEO-специалист по выгрузке адресов.

jsessionid, срок жизни сессии и Clean-param

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

Документация Яндекса, Google и PHP о параметрах сессий

• Справка Яндекс Вебмастера: директива Clean-param
• Google Search Central: рекомендации по структуре URL
• Документация PHP: настройки сессий session.use_only_cookies и session.use_trans_sid

См. также: Robots.txt, Дублированный контент, Динамический URL, Файлы cookies.