Как Google автоматически обнаруживает и удаляет идентификаторы сессий из URL для оптимизации сканирования и предотвращения дублирования

Термины и определения

Clean URL (Чистый URL)

Нормализованная версия URL, из которой удален идентификатор сессии. Используется системой для дедупликации и каноникализации контента.

Content Manager (Менеджер контента)

Компонент системы сканирования, который обрабатывает загруженный контент, извлекает из него URL и анализирует их на наличие идентификаторов сессий.

Fetch Bot / Spider (Робот-загрузчик / Паук)

Программа (краулер), которая загружает веб-документы по заданным URL.

Fingerprint (Отпечаток)

Уникальный идентификатор (например, результат хэш-функции), рассчитанный на основе Clean URL. Используется для быстрого и эффективного сравнения URL и дедупликации.

Measure of Randomness (Мера случайности)

Эвристическая метрика, используемая для оценки того, насколько подстрока похожа на случайно сгенерированный идентификатор, а не на часть контента или структуры сайта.

Session Identifier (Идентификатор сессии)

Строка символов, встроенная в URL, используемая веб-сайтом для отслеживания сессии пользователя. Эта строка не влияет на основной контент, возвращаемый по URL.

URL Manager (Менеджер URL)

Компонент, который управляет очередью сканирования, отслеживает обработанные URL и генерирует Fingerprints.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной метод обработки URL во время сканирования.

1. Извлечение набора URL из одного или нескольких документов, загруженных с веб-сайта.
2. Идентификация подстроки в наборе URL как Session Identifier. Эта идентификация основана на: (а) применении набора правил И (б) множественных вхождениях (multiple occurrences) этой подстроки в разных URL набора.
3. Генерация набора Clean URLs путем удаления идентифицированного Session Identifier.
4. Определение того, были ли другие URL уже сканированы, путем сравнения их чистых версий с уже сгенерированными Clean URLs.

Claims 7, 11, 17, 20 (Зависимые): Детализируют правила идентификации (упомянутые в Claim 1). Ключевым фактором является то, что подстрока должна демонстрировать по крайней мере определенную «меру случайности» (measure of randomness).

Claim 6 (Зависимый от 1): Описывает стратегию хранения и доступа (Adaptive Crawling).

Система хранит информацию на основе Clean URLs для целей дедупликации. Одновременно она сохраняет исходный набор URL (включая встроенные идентификаторы сессий) для использования при последующем доступе к этим URL, если ID необходим для корректной работы сайта.

Claim 2 (Зависимый от 1): Уточняет метод сравнения.

Сравнение чистых URL основано на вычислении и сравнении Fingerprint значений, полученных из этих чистых URL.

Где и как применяется

Изобретение является частью инфраструктуры сканирования и индексирования Google.

CRAWLING – Сканирование и Сбор данных
Это основной этап применения. Fetch Bots загружают контент. Content Manager извлекает URL. Система анализа URL (часть Content Manager и URL Manager) анализирует извлеченные URL на лету для обнаружения Session Identifiers. URL Manager использует Clean URL для дедупликации и планирования очереди сканирования.

INDEXING – Индексирование и извлечение признаков
На этапе индексирования происходит процесс каноникализации. Система использует Clean URL, сгенерированный во время сканирования, как предпочтительный (канонический) адрес для индексируемого контента. Это предотвращает попадание множества дубликатов одной и той же страницы в индекс.

Входные данные:

• Набор URL-адресов, извлеченных из сканируемых документов (обычно группируемых по хосту/веб-сайту).

Выходные данные:

• Clean URLs для каждого обработанного адреса.
• Fingerprints этих Clean URLs для хранения в базе данных URL Manager.
• Список уникальных URL, запланированных для последующего сканирования.

На что влияет

• Конкретные ниши и типы сайтов: Наибольшее влияние оказывается на сайты, которые динамически генерируют URL для отслеживания пользователей. Это часто встречается в E-commerce (состояние корзины, история просмотра), на форумах, в системах бронирования и на любых сайтах, использующих устаревшие методы управления сессиями (параметры URL или перезапись пути вместо cookies).
• Эффективность сканирования (Crawl Budget): Система напрямую влияет на оптимизацию краулингового бюджета, позволяя избежать сканирования дубликатов.

Когда применяется

• Условия работы: Алгоритм применяется непрерывно во время процесса сканирования, когда краулер обрабатывает документы с определенного хоста и извлекает новые URL.
• Триггеры активации: Обнаружение подстрок в URL, которые соответствуют эвристическим правилам для Session Identifiers. Критично сочетание двух факторов:
  1. Структурные характеристики: Достаточная длина (например, 8+ символов) и высокая measure of randomness.
  2. Повторение: Одна и та же строка повторяется в нескольких разных URL на сайте.

Пошаговый алгоритм

1. Сканирование документа: Fetch Bot загружает контент документа по заданному URL.
2. Извлечение URL: Content Manager парсит документ и извлекает все найденные в нем URL.
3. Анализ и Поиск Кандидатов: Извлеченные URL (анализируемые в контексте одного хоста) проверяются на наличие подстрок, которые могут быть Session Identifiers. Кандидаты должны соответствовать минимальной длине и показывать высокую measure of randomness.
4. Классификация и Идентификация: Кандидаты классифицируются как Session Identifiers, если они встречаются многократно в разных URL в пределах анализируемого набора.
5. Нормализация (Генерация Clean URL): Идентифицированные Session Identifiers удаляются из соответствующих URL для создания Clean URL.
6. Расчет Fingerprint: Для полученного Clean URL рассчитывается уникальный Fingerprint.
7. Дедупликация: URL Manager сравнивает новый Fingerprint с базой данных уже обработанных URL.
8. Планирование сканирования (Adaptive Crawling): Если URL уникален, он добавляется в очередь. URL Manager принимает решение о формате URL для сканирования: использовать исходный URL (с ID), Clean URL, или Clean URL с новым сгенерированным ID, в зависимости от того, как сайт реагирует на запросы без идентификатора.

Какие данные и как использует

Данные на входе

• Технические факторы: Единственными входными данными, описанными в патенте, являются сами URL-адреса (структура URL), извлеченные из сканируемых страниц. Анализируются подстроки внутри этих URL.

Какие метрики используются и как они считаются

Система использует несколько эвристик и метрик для классификации подстрок:

• Frequency of Occurrence (Частота встречаемости): Подсчет количества различных URL с одного сайта, в которых встречается одна и та же подстрока-кандидат. Высокая частота является сильным сигналом Session Identifier.
• Minimum Length (Минимальная длина): Устанавливается пороговое значение длины подстроки (в патенте упоминается пример 8 символов).
• Measure of Randomness (Мера случайности): Критическая метрика для отличия ID от контента. Патент предлагает конкретные методы расчета:
  • Сравнение со словарем: Если подстрока отсутствует в словаре, она считается более случайной.
  • Чередование типов символов (Alternations): Подсчет количества переключений между цифрами (0-9), строчными буквами (a-z) и заглавными буквами (A-Z). Например, строка "3uSS4A" имеет 4 таких чередования, что указывает на высокую степень случайности.
• Fingerprint Calculation: Применение хэш-функции к Clean URL для создания уникального отпечатка.

1. Автоматическое обнаружение Session ID без известных паттернов: Google разработал эвристический механизм для определения идентификаторов сессий, который не полагается только на стандартные имена параметров (вроде sid или phpsessid). Система анализирует структуру URL и характеристики подстрок.
2. Ключевые индикаторы – Случайность и Повторение: Для идентификации Session Identifier система ищет комбинацию двух факторов: подстрока должна выглядеть случайной (высокая measure of randomness) и она должна повторяться в разных URL на одном и том же сайте.
3. Нормализация как основа каноникализации: Основная цель процесса — создать стабильный Clean URL. Это позволяет Google эффективно бороться с массовым дублированием контента и значительно экономить краулинговый бюджет.
4. Адаптивное сканирование (Adaptive Crawling): Система учитывает, что некоторые сайты требуют наличия Session Identifier для отдачи контента. Патент предусматривает возможность сохранения исходных ID или генерации новых для обеспечения доступа к контенту (Claim 6), при этом для индексации и дедупликации используется Clean URL.
5. Важность чистой архитектуры URL: Патент демонстрирует технические сложности, которые создают устаревшие методы управления сессиями, и подчеркивает важность предоставления поисковым системам чистых и стабильных URL.

Best practices (это мы делаем)

• Использовать чистые, стабильные и человекопонятные URL: Это ключевая рекомендация. Избегайте использования любых идентификаторов сессий или переменных состояния в URL, если они не изменяют основной контент страницы.
• Управление сессиями через Cookies: Для отслеживания состояния пользователя и управления сессиями используйте Cookies или localStorage, а не параметры в URL или перезапись пути (path rewriting). Это стандарт современной веб-разработки.
• Применять явную каноникализацию (rel="canonical"): Несмотря на то, что Google может автоматически определять Clean URLs, полагаться на это не стоит. Всегда используйте rel="canonical", чтобы явно указать предпочтительную версию страницы, особенно если CMS генерирует URL с параметрами.
• Мониторинг параметров URL в GSC: Регулярно проверяйте отчеты Google Search Console (Crawl Stats и Index Coverage) на предмет сканирования большого количества URL с параметрами. Это может указывать на проблемы с идентификацией сессий или фасетной навигацией.

Worst practices (это делать не надо)

• Встраивание Session ID в URL: Это устаревшая практика, которая гарантированно создает проблемы с дублированием контента и неэффективно расходует краулинговый бюджет, заставляя Google активировать сложные механизмы нормализации.
• Использование случайных строк для идентификации контента: Если структура URL для реального контента выглядит слишком случайной (например, использует длинные хэши вместо слагов), существует риск, что Google может ошибочно классифицировать часть URL как Session Identifier и некорректно нормализовать адрес.
• Требование валидного Session ID для доступа к контенту: Создание сайтов, которые не отдают контент (например, возвращают ошибку или редирект), если в URL отсутствует валидный идентификатор сессии. Это значительно усложняет сканирование.

Стратегическое значение

Патент подтверждает фундаментальную важность технического SEO и информационной архитектуры. Чистая, логичная и стабильная структура URL является основой для эффективного сканирования и индексации. Google инвестирует значительные ресурсы в нормализацию данных. Стратегическая задача Senior SEO-специалиста — предоставить поисковой системе максимально чистые и однозначные данные на входе, чтобы минимизировать вероятность ошибок при автоматической обработке и направить краулинговый бюджет на полезный контент.

Практические примеры

Сценарий: Оптимизация краулингового бюджета на устаревшем E-commerce сайте

1. Ситуация: Интернет-магазин на устаревшей платформе генерирует URL для карточек товаров вида: http://example.com/shop/SESSID_a19f77b2/product/123.html.
2. Проблема: В логах сервера видно, что Googlebot сканирует тысячи URL для одного и того же товара с разными SESSID, тратя краулинговый бюджет.
3. Как работает Google (согласно патенту): Googlebot сканирует сайт. Система анализа URL видит, что подстрока SESSID_a19f77b2 имеет высокую measure of randomness (чередование символов) и повторяется в разных URL (например, в /product/123.html и /product/456.html). Она классифицирует ее как Session Identifier.
4. Нормализация: Система нормализует URL до http://example.com/shop/product/123.html для индексации и учета.
5. Действия SEO-специалиста:
   • Приоритет 1 (Стратегическое решение): Поставить задачу разработчикам на переход от управления сессиями через URL к использованию Cookies.
   • Приоритет 2 (Тактическое решение): Убедиться, что на всех страницах настроен тег rel="canonical", указывающий на чистую версию URL (без SESSID). Это поможет Google быстрее и точнее выбирать каноническую версию.