Идентификатор сессии (Session ID) — уникальная строка символов, присваиваемая пользователю при начале сессии на веб-сайте. Сессия — это период взаимодействия пользователя с сайтом от входа до выхода или таймаута. Идентификатор сессии позволяет серверу «помнить» пользователя между отдельными HTTP-запросами (HTTP — протокол без состояния, он не запоминает предыдущие запросы).
Технически Session ID генерируется сервером при первом запросе пользователя и передаётся клиенту. Он может храниться в cookie (рекомендуемый способ), в скрытых полях форм или — что критично для SEO — в URL-параметре.
Session ID в URL: SEO-проблема
Когда Session ID передаётся через URL, адрес страницы выглядит так: https://example.com/catalog/?PHPSESSID=abc123xyz или https://example.com/catalog/&sessid=def456. Это создаёт серьёзные SEO-проблемы:
- Дублированный контент — одна и та же страница доступна по тысячам URL (у каждого пользователя свой Session ID). Поисковый бот видит бесконечное количество «уникальных» URL с идентичным содержимым.
- Краулинговый бюджет — бот тратит бюджет на обход тысяч дубликатов вместо уникального контента.
- Непредсказуемый canonical — поисковик затрудняется определить, какой из бесконечных URL является «основным».
- Утечка Session ID — если пользователь копирует URL и передаёт его другому, тот получает его сессию (угон сессии).
Как исправить проблему Session ID в URL
- Переключить на хранение в cookie — основное решение. В PHP:
session_set_cookie_params(). Большинство современных фреймворков используют cookie по умолчанию. - Директива Clean-param (Яндекс) — указать Яндексу игнорировать параметр сессии:
Clean-param: PHPSESSID&sessid /в robots.txt. - Canonical URL — на каждой странице указать canonical без Session ID.
- Нормализация URL через .htaccess — redirect правило, удаляющее Session ID из URL.
Session ID и безопасность
Session ID должен быть: случайным (криптографически стойкий генератор), достаточно длинным (минимум 128 бит), передаваться только по HTTPS, обновляться после аутентификации (защита от session fixation). Компрометация Session ID = захват сессии пользователя.
Часто задаваемые вопросы
Как проверить, есть ли Session ID в URL на сайте?
Способы: 1) Просмотреть URL в браузере при навигации по сайту — искать параметры типа PHPSESSID, sessid, SID, JSESSIONID. 2) Screaming Frog / Netpeak Spider — при краулинге покажут URL с параметрами. 3) Google Search Console → «Ссылки» → URL сайта — если видны URL с длинными параметрами. 4) Серверные логи — поискать повторяющийся параметр с изменяющимися значениями. Если Session ID обнаружен в URL — это приоритетная проблема технического SEO.
Могут ли поисковики сами «игнорировать» Session ID в URL?
Частично. Google умеет обнаруживать типичные параметры сессии (PHPSESSID, SID) и не всегда создаёт дубли для каждого значения. Но это поведение непредсказуемо и не гарантировано. Яндекс обрабатывает Session ID хуже. Директива Clean-param в robots.txt для Яндекса даёт явную инструкцию игнорировать параметр. Правильное техническое решение (cookie) всегда лучше надежды на «умность» поисковика.
Как устроено хранение Session ID в cookie с точки зрения безопасности?
Cookie с Session ID должен иметь атрибуты: HttpOnly — запрещает доступ к cookie через JavaScript (защита от XSS); Secure — передаётся только по HTTPS; SameSite=Strict или Lax — защита от CSRF-атак. В PHP: session_set_cookie_params(['httponly' => true, 'secure' => true, 'samesite' => 'Lax']). Срок жизни: достаточно короткий для безопасности (15–60 минут активности), с автопродлением при активных действиях.
Нужно ли закрывать URL с Session ID от индексации через robots.txt?
Да, как временная мера. В robots.txt: Disallow: /*?PHPSESSID= заблокирует краулинг URL с этим параметром. Но это не решение проблемы — это её маскировка. Правильное решение: убрать Session ID из URL, переключив хранение в cookie. После исправления сбросьте кеш старых URL с параметрами, используя инструмент «Удаление URL» в Search Console для ускорения очистки индекса.
