Как Google определяет сайты, использующие Session ID в URL, для оптимизации краулинга и борьбы с дубликатами

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

Clean URL / Clean version of URL (Чистый URL)

Версия URL, из которой был извлечен идентификатор сессии. Используется для определения того, была ли страница уже просканирована.

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

Компонент краулера (Spider), отвечающий за загрузку контента по заданным URL.

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

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

In-host links / Local links (Внутренние ссылки)

Ссылки, обнаруженные на странице, которые указывают на другие ресурсы на том же самом веб-сайте (хосте).

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

Строка символов (часто случайная), встраиваемая веб-сайтом в URL для отслеживания действий пользователя в рамках одного посещения. В широком смысле, любая часть URL, которая не влияет на основное содержание страницы.

Session ID Locator (Локатор Session ID)

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

Session ID Rule Generator (Генератор правил Session ID)

Компонент, который анализирует ссылки с Session ID и генерирует правила, описывающие, как именно сайт вставляет эти идентификаторы.

Spider (Краулер, Паук)

Программа, которая автоматически обходит (сканирует) веб-документы, следуя по ссылкам.

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

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

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

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

1. Система получает URL и загружает как минимум две разные копии документа, связанного с этим URL.
2. Система определяет, использует ли веб-сайт, соответствующий URL, идентификаторы сессий.
3. Это определение основано на сравнении URL, находящихся внутри документа, которые меняются между разными копиями.
4. Условие срабатывания: веб-сайт определяется как использующий Session ID, если доля (portion) URL, которые изменились между копиями документа, превышает установленный порог (threshold).

Claim 11 (Независимый пункт): Описывает метод идентификации сайтов (вне контекста текущего краулинга).

1. Загрузка как минимум двух разных копий документа с веб-сайта.
2. Извлечение и сравнение URL из этих копий.
3. Определение того, что веб-сайт использует Session ID, если сравнение показывает, что по крайней мере часть URL изменилась между копиями.

Claim 3 (Зависимый от 1): Детализирует процесс обработки URL после идентификации.

1. Если установлено, что сайт использует Session ID, система извлекает идентификатор из URL для получения clean URL.
2. Система определяет, был ли URL уже просканирован, путем сравнения полученного clean URL с набором clean URLs, которые представляют ранее просканированные страницы.

Claim 14 (Зависимый от 11): Описывает генерацию правил.

1. Если определено, что сайт использует Session ID, система анализирует извлеченные URL для генерации как минимум одного правила.
2. Это правило определяет, каким образом Session ID встраиваются в URL на данном сайте.

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

Изобретение применяется на этапе CRAWLING – Сканирование и Сбор данных. Оно является критически важной частью инфраструктуры сканирования, направленной на повышение его эффективности и качества собираемых данных.

Взаимодействие компонентов:

• Session ID Locator: Работает проактивно или реактивно. Он загружает страницы, анализирует ссылки и классифицирует сайты.
• Session ID Rule Generator: Получает данные от Session ID Locator и генерирует правила для конкретных сайтов. В патенте упоминается, что этот компонент может быть реализован как автоматически (с использованием методов классификации паттернов), так и вручную операторами.
• URL Manager: Центральный компонент, использующий результаты работы предыдущих двух. Он обрабатывает кандидатные URL, применяет правила для создания clean URL, генерирует Fingerprint и принимает решение о необходимости сканирования, передавая задачу Fetch Bots.

INDEXING – Индексирование и извлечение признаков
Патент напрямую влияет на процессы каноникализации и дедупликации на этапе индексирования. Использование clean URL гарантирует, что в индекс не попадут дубликаты страниц с разными Session ID.

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

• Список сайтов, подозреваемых в использовании Session ID (опционально).
• Кандидатные URL, извлеченные из ранее просканированных документов.
• Содержимое веб-страниц (для анализа внутренних ссылок).

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

• Классификация веб-сайта (использует/не использует Session ID).
• Набор правил (Session ID Rules) для извлечения идентификаторов для конкретного сайта.
• Нормализованные clean URLs.

На что влияет

• Конкретные ниши или тематики: Наибольшее влияние оказывается на E-commerce, форумы, системы бронирования и любые другие типы сайтов, которые активно используют параметры URL для отслеживания состояния сессии пользователя.
• Техническое состояние сайтов: Влияет на сайты, использующие устаревшие или некорректно настроенные CMS, которые полагаются на URL-based Session ID вместо Cookies.

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

Алгоритм применяется в двух основных сценариях:

1. Идентификация (Определение использования Session ID):

• Триггеры активации: Сайт попадает в список подозрительных. Это может быть инициировано автоматически, если URL Manager обнаруживает исключительно большое количество "разных" ссылок для одного сайта.
• Пороговые значения: Доля внутренних ссылок (in-host links) на странице, которые изменились между двумя последовательными загрузками, должна превысить установленный порог (threshold).

2. Нормализация (Применение правил при краулинге):

• Условия: Каждый раз, когда URL Manager обрабатывает новый URL.
• Триггеры активации: Если хост обрабатываемого URL ранее был классифицирован как использующий Session ID.

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

Процесс разделен на две основные части: идентификация сайтов и применение знаний во время сканирования.

Процесс А: Идентификация сайтов, использующих Session ID (Session ID Locator)

1. Инициализация (Опционально): Получение списка сайтов, подозреваемых в использовании Session ID.
2. Загрузка копий: Для сайта из списка система дважды загружает одну и ту же страницу (например, главную).
3. Извлечение ссылок: Из обеих загруженных копий извлекаются локальные (in-host) ссылки.
4. Вычисление изменений: Система сравнивает два набора ссылок и вычисляет долю ссылок, которые изменились между двумя копиями.
5. Сравнение с порогом: Полученная доля сравнивается с предопределенным порогом.
6. Классификация: Если порог превышен, сайт помечается как использующий Session ID. (Альтернативный метод, упомянутый в патенте: проверка того, ведут ли изменившиеся ссылки на дублирующийся или почти дублирующийся контент).
7. Генерация правил: Если сайт использует Session ID, ссылки анализируются (с помощью Session ID Rule Generator) для определения правил, описывающих паттерн вставки идентификаторов (например, "вставить после имени хоста, отделить символами '/'").

Процесс Б: Обработка URL во время сканирования (URL Manager)

1. Получение кандидата: URL Manager получает кандидатный URL для сканирования из ранее обработанных документов.
2. Проверка хоста: Система проверяет, принадлежит ли URL сайту, который был идентифицирован как использующий Session ID.
3. Извлечение правил: Если да, система извлекает соответствующие правила (Session ID Rules) для этого сайта.
4. Нормализация: Система применяет правила для извлечения Session ID из кандидатного URL, получая clean URL.
5. Проверка дубликатов: URL Manager использует clean URL (часто через Fingerprint), чтобы определить, была ли эта страница уже просканирована ранее.
6. Планирование сканирования: Если страница не была просканирована, URL отправляется роботам (Fetch Bots) для загрузки.

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

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

Патент фокусируется на инфраструктуре краулинга и использует следующие данные:

• Технические факторы:
  • Структура URL: Анализируются паттерны в URL (путь, параметры) для обнаружения и извлечения Session ID.
• Контентные/Структурные факторы:
  • Содержимое веб-документов: Анализируется (HTML-код) для извлечения всех содержащихся в нем ссылок (URL).

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

• Доля изменившихся ссылок (Fraction of links that change): Метрика, рассчитываемая путем сравнения набора внутренних (in-host) ссылок из первой копии страницы с набором из второй копии. $Fraction = \frac{Количество\ изменившихся\ внутренних\ ссылок}{Общее\ количество\ внутренних\ ссылок}$.
• Порог (Threshold): Предопределенное значение. Если $Fraction > Threshold$, сайт классифицируется как использующий Session ID. Значение порога определяется эмпирически.
• Fingerprint: Результат применения хеш-функции к clean URL. Используется для эффективного и быстрого сравнения URL и обнаружения дубликатов.
• Near-duplicates (Почти дубликаты): Упоминается как альтернативный метод валидации. Если ссылки изменились, но ведут на контент, который является дубликатом или почти дубликатом, это подтверждает наличие Session ID.

1. Автоматическое обнаружение Session ID: Google обладает механизмом для автоматического определения сайтов, использующих Session ID в URL, без необходимости ручной настройки параметров. Это достигается путем двойной загрузки страницы и анализа изменчивости внутренних ссылок.
2. Нормализация URL критична для краулинга: Центральная идея патента — необходимость нормализации URL до "чистой" версии (clean URL) перед принятием решения о сканировании и индексировании.
3. Борьба с дубликатами и экономия ресурсов: Основная цель изобретения — предотвращение сканирования и индексирования одного и того же контента по разным URL. Это напрямую связано с оптимизацией краулингового бюджета (Crawl Budget).
4. Специфичные для сайта правила: Система не использует универсальный подход, а генерирует правила извлечения Session ID для каждого конкретного сайта (или группы сайтов) на основе анализа паттернов в его URL.
5. Использование Fingerprints для эффективности: Для быстрого обнаружения дубликатов используются отпечатки (Fingerprints) нормализованных URL, что является стандартной практикой в крупномасштабных системах сканирования.

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

• Избегать использования Session ID в URL: Это лучшая практика. Для отслеживания сессий следует использовать Cookies или методы Local Storage, которые не влияют на структуру URL, видимую поисковыми системами.
• Внедрение канонических ссылок: Если использование Session ID в URL неизбежно (например, из-за ограничений CMS), критически важно использовать атрибут rel="canonical" на всех страницах. Каноническая ссылка должна указывать на clean URL (версию без Session ID). Это служит страховкой на случай сбоя автоматических систем Google.
• Консистентность структуры URL: Убедитесь, что Session ID (если они используются) вставляются по четким и последовательным правилам. Это облегчит работу Session ID Rule Generator по автоматическому определению и применению правил очистки.
• Управление параметрами URL: Хотя патент описывает автоматический механизм, рекомендуется использовать доступные инструменты для вебмастеров (например, в Google Search Console), чтобы явно указать, какие параметры URL следует игнорировать при сканировании.

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

• Использование URL-based Session ID без контроля: Генерация большого количества уникальных URL для одного и того же контента из-за Session ID. Это гарантированно приведет к проблемам с дублированием контента и неэффективному расходованию краулингового бюджета.
• Отсутствие канонических URL: Полагаться только на то, что Google автоматически распознает и обработает Session ID (как описано в патенте), рискованно. Отсутствие rel="canonical" усложняет работу поисковой системы.
• Блокировка параметров в robots.txt: Попытка решить проблему путем блокировки URL с Session ID в robots.txt может привести к тому, что контент станет недоступен для сканирования (если краулер обнаруживает ссылки только в таком формате) или помешает консолидации сигналов.

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

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

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

Сценарий: Оптимизация E-commerce сайта, использующего Session ID

1. Ситуация: Сайт магазина использует параметр sid для отслеживания сессий. Карточка товара доступна по адресам: example.com/productA, example.com/productA?sid=12345, example.com/productA?sid=67890. Google тратит бюджет на сканирование всех вариантов.
2. Анализ (Как работает Google по патенту): Google скачивает главную страницу дважды. В первый раз видит ссылку /productA?sid=12345, во второй раз — /productA?sid=67890. Система замечает изменение и классифицирует сайт. Генерируется правило: "удалить параметр sid". Clean URL становится /productA.
3. Действия SEO-специалиста (Best Practice):
   • Приоритет 1: Поставить задачу разработчикам перенастроить CMS (например, Magento, Bitrix) для использования Cookies вместо параметра sid в URL.
   • Приоритет 2 (Если 1 невозможно): Убедиться, что на всех страницах с параметром sid элемент <link rel="canonical" href="https://example.com/productA"> указывает на версию без параметра.
4. Ожидаемый результат: Google консолидирует сигналы ранжирования на clean URL. Краулинговый бюджет перераспределяется на сканирование уникального контента, улучшается общая индексация сайта.