Как Google адаптивно управляет краулинговым бюджетом и скоростью сканирования на основе производительности сервера

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

Buckets (Корзины)

Структура данных, используемая URL Server для группировки хостов. Хосты группируются по количеству URL, оставшихся для сканирования на этом хосте (например, Корзина 10 содержит все хосты, на которых осталось 10 URL).

Crawlers (Краулеры)

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

Link Managers / URL Managers (Менеджеры ссылок)

Распределенные компоненты, которые хранят информацию о состоянии ссылок и их приоритетах (например, PageRank). Они предоставляют списки высокоприоритетных ссылок для URL Server.

Load Factor (Коэффициент нагрузки)

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

Retrieval Time (Время извлечения / Время ответа сервера)

Фактическое время, затраченное краулером на загрузку документа с хоста. Используется для динамической корректировки Stall Time.

Stall Time (Время ожидания)

Временная метка, присваиваемая хосту. Указывает самое раннее время, когда можно отправить следующий запрос на сканирование этого хоста. Ключевой механизм для предотвращения перегрузки сервера (Rate Limiting).

URL Server (Сервер URL-адресов)

Центральный компонент системы планирования. Он управляет глобальной очередью сканирования, организует URL по хостам и Buckets, управляет Stall Time и выдает URL краулерам.

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

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

1. Получение списка ссылок, выбранных Link Manager на основе приоритета.
2. Группировка ссылок по хостам.
3. Группировка хостов в Buckets в зависимости от количества документов, которые нужно просканировать на каждом хосте.
4. Сортировка хостов внутри каждого Bucket на основе их Stall Time.
5. Выбор следующего хоста для сканирования из одного из Buckets в соответствии с его Stall Time.
6. Сканирование документа с выбранного хоста.
7. Определение времени извлечения (Retrieval Time) для этого документа.
8. Корректировка последующего Stall Time для выбранного хоста на основе измеренного Retrieval Time.

Ядром изобретения является использование комбинации Buckets (приоритизация по объему работы) и сортировки по Stall Time (контроль нагрузки) для планирования, а также динамическая адаптация Stall Time к фактической скорости ответа сервера.

Claim 4 (Зависимый от 1): Уточняет логику выбора хоста для эффективности.

Система проверяет Buckets в порядке убывания количества документов (начиная с самой полной корзины) до тех пор, пока не будет найден хост, чей Stall Time раньше текущего времени. Это гарантирует, что система предпочитает хосты с большим объемом несканированного контента, но только если они технически готовы.

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

1. Хранение пула ссылок для сканирования (в URL Server).
2. Определение потребности в дополнительных ссылках (когда пул истощается).
3. Отправка запросов нескольким распределенным Link Managers.
4. Получение дополнительных ссылок.
5. Выбор хоста для сканирования на основе Stall Time.
6. Сканирование, определение Retrieval Time и корректировка Stall Time.

Этот пункт защищает масштабируемую архитектуру, где глобальное планирование и контроль нагрузки (URL Server) отделены от хранения и приоритизации ссылок (Link Managers).

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

Изобретение применяется исключительно на этапе CRAWLING – Сканирование и Сбор данных.

Это ядро системы планирования сканирования (Crawl Scheduling) и управления краулинговым бюджетом (Crawl Budget Management).

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

1. Link Managers хранят ссылки и их приоритеты.
2. URL Server запрашивает у них высокоприоритетные ссылки.
3. URL Server организует очередь, используя Buckets и Stall Time.
4. Crawlers запрашивают у URL Server следующий URL для сканирования.
5. Crawlers выполняют загрузку и сообщают о результатах (включая Retrieval Time).

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

• Списки приоритетных URL от Link Managers.
• Текущее время.
• Конфигурация Load Factor для хостов.
• Измеренные Retrieval Time от краулеров.

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

• URL, выданный краулеру для немедленного сканирования.
• Обновленный Stall Time для хоста, с которого был загружен документ.

На что влияет

• Все типы контента и сайты: Механизм применяется ко всем ресурсам, которые сканирует Google.
• Крупные сайты: Особенно критично для крупных проектов (e-commerce, порталы, новостные сайты), где эффективное управление краулинговым бюджетом и скоростью индексации имеет решающее значение.
• Сайты с нестабильной производительностью: Система адаптивно реагирует на изменения в скорости ответа сервера. Медленные сайты будут сканироваться реже.

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

Алгоритм применяется непрерывно в процессе сканирования интернета.

• Условия работы: Наличие URL в очереди сканирования.
• Триггеры активации: Для конкретного хоста триггером является истечение его Stall Time (Текущее время > Stall Time). Корректировка Stall Time происходит после каждого акта сканирования.

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

Процесс А: Управление очередью в URL Server (Планирование)

1. Организация (Асинхронно): Хосты организованы в Buckets по количеству ожидающих URL (N). Хосты внутри Buckets отсортированы по Stall Time.
2. Выбор хоста (Основной цикл): Система итерирует по Buckets, начиная с самой полной (максимальное N).
3. Проверка готовности: Внутри Bucket проверяется первый хост.
   • Если его Stall Time меньше текущего времени, этот хост выбирается.
   • Если нет, то весь Bucket пропускается (так как остальные хосты в нем имеют еще больший Stall Time) и система переходит к следующему Bucket (N-1).
4. Выдача URL и Перемещение: URL с выбранного хоста выдается краулеру. Хост перемещается в Bucket с меньшим количеством оставшихся URL.

Процесс Б: Сканирование и Адаптация (Обратная связь)

1. Сканирование и Измерение: Краулер выполняет запрос и фиксирует фактическое время извлечения (Retrieval Time).
2. Расчет нового Stall Time: Система рассчитывает новый Stall Time для хоста. Расчет основан на Retrieval Time и Load Factor. Например, если Load Factor = 0.1 (10%) и Retrieval Time = 3 секунды, интервал до следующего запроса составит 3 / 0.1 = 30 секунд. Новый Stall Time = Текущее время + 30 секунд.
3. Обновление очереди: Хост вставляется в свою новую Bucket (из Процесса А) в соответствии с новым Stall Time для поддержания сортировки.

Процесс В: Пополнение пула (Фоновый процесс)

1. Триггер: Если количество ссылок в пуле URL Server падает ниже порога.
2. Запрос: Отправить запросы к Link Managers для получения новых высокоприоритетных ссылок.
3. Интеграция: Полученные ссылки интегрируются в структуру Buckets.

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

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

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

• Технические факторы (Производительность):
  • Retrieval Time (Время ответа сервера): Измеренное время, необходимое для загрузки ресурса. Критически важный входной сигнал для адаптивного сканирования.
  • URL и Хост/IP: Используются для группировки и идентификации серверов.
• Системные данные:
  • Link Priority (Приоритет ссылки): Например, PageRank. Используется Link Managers для выбора ссылок, отправляемых в URL Server.
  • Load Factor (Коэффициент нагрузки): Заранее сконфигурированный параметр, определяющий желаемую интенсивность нагрузки на хост. Может варьироваться для разных хостов.
  • Link State (Состояние ссылки): (Не просканировано, в процессе, просканировано и т.д.).

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

• Stall Time (Время ожидания): Ключевая метрика для планирования. Рассчитывается адаптивно.
• Retrieval Time: Измерение производительности сервера при загрузке конкретного URL.
• Количество URL на хосте: Метрика, используемая для определения, в какой Bucket поместить хост (Bucket Categorization).
• Формулы расчета: Интервал сканирования (время между запросами) рассчитывается как функция от Retrieval Time и Load Factor. В патенте приводится пример, который интерпретируется как:
  Расчет интервала ожидания (Delay): $\text{Интервал} = \frac{\text{Retrieval Time}}{\text{Load Factor}}$.
  Новый Stall Time: $\text{Новый Stall Time} = \text{Текущее время} + \text{Интервал}$.

1. Адаптивное сканирование — ключевой механизм Crawl Budget: Частота сканирования напрямую и динамически зависит от производительности сервера. Если время ответа сервера (Retrieval Time) увеличивается, Google автоматически замедляет сканирование этого хоста, увеличивая Stall Time.
2. Скорость сервера критична для эффективности сканирования: Более быстрое Retrieval Time приводит к более коротким Stall Time, что позволяет Google сканировать больше страниц за тот же период времени (увеличение Crawl Rate).
3. Баланс между приоритетом и доступностью: Приоритет сканирования определяется не только важностью ссылки (Crawl Demand), но и технической способностью хоста отдавать контент (Crawl Rate Limit). Важная страница на медленном сервере может быть просканирована позже.
4. Stall Time как механизм Rate Limiting: Stall Time является основным механизмом для предотвращения перегрузки серверов (Crawl Politeness). Он определяет максимальную частоту запросов к хосту.
5. Приоритизация по объему и готовности: Система Buckets показывает, что Google стремится в первую очередь сканировать хосты с большим количеством известных, но еще не просканированных URL, но только при условии их технической готовности (истекший Stall Time).

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

• Максимизация скорости ответа сервера (TTFB и общее время загрузки): Это критически важно. Быстрый Retrieval Time напрямую уменьшает интервал между запросами (сокращает Stall Time). Это позволяет Googlebot сканировать больше страниц за единицу времени, увеличивая эффективность использования краулингового бюджета.
• Обеспечение стабильности и высокой пропускной способности хостинга: Сервер должен выдерживать нагрузку Googlebot без деградации производительности. Ошибки (5xx), таймауты и замедление ответа увеличивают Retrieval Time и, как следствие, Stall Time, замедляя индексацию.
• Мониторинг логов сервера и Google Search Console: Анализируйте среднее время ответа в отчете "Статистика сканирования" GSC. Эти данные напрямую коррелируют с Retrieval Time и показывают, как система оценивает производительность вашего сервера и какой интервал (Stall Time) она применяет.
• Обеспечение доступности всех важных URL: Система Buckets отдает приоритет хостам с большим количеством ожидающих URL. Убедитесь, что у Google есть большой бэклог для сканирования (через эффективную перелинковку и Sitemap), чтобы сайт попадал в более приоритетные Buckets.

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

• Использование медленного или нестабильного хостинга: Это фундаментальная ошибка. Медленный Retrieval Time напрямую ведет к увеличению Stall Time и неэффективному расходованию краулингового бюджета.
• Искусственное ограничение скорости ответа для Googlebot (Throttling): Если сервер способен отвечать быстрее, но искусственно замедляется для Googlebot, система воспримет это как медленный ответ и увеличит Stall Time, замедляя сканирование и индексацию (если только это не временная мера при реальной аварийной перегрузке).
• Игнорирование проблем производительности во время пиковых нагрузок: Если сайт замедляется во время высокого трафика и Googlebot попадает в эти окна, система скорректирует Stall Time в сторону увеличения, предполагая, что сервер перегружен.

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

Патент подтверждает, что техническая оптимизация и производительность сервера являются фундаментом SEO. Краулинговый бюджет (Crawl Budget) — это не фиксированная величина, а динамический параметр, который является функцией как важности контента (Crawl Demand), так и способности сервера этот контент отдавать (Crawl Rate Limit). Стратегия SEO должна включать постоянную работу над улучшением инфраструктуры, так как невозможно добиться хорошей видимости, если сайт невозможно быстро просканировать.

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

Сценарий: Ускорение индексации за счет оптимизации производительности сервера

1. Ситуация: Крупный E-commerce сайт запускает новый раздел, но страницы индексируются медленно. В GSC среднее время ответа сервера высокое (например, 1200 мс или 1.2 сек).
2. Анализ по патенту: Высокий Retrieval Time (1.2 сек) приводит к большому Stall Time. Если условный Load Factor = 0.1 (10%), то интервал между запросами составляет 1.2 сек / 0.1 = 12 секунд. Googlebot сканирует медленно.
3. Действия: Проводится оптимизация бэкенда, запросов к базе данных и настраивается эффективное кэширование. Сайт переносится на более производительный хостинг.
4. Результат: Среднее время ответа сервера снижается до 200 мс (0.2 сек). Googlebot обнаруживает это изменение (Retrieval Time уменьшился).
5. Адаптация Googlebot: Система динамически пересчитывает Stall Time. Новый интервал: 0.2 сек / 0.1 = 2 секунды.
6. Итог: Частота сканирования увеличивается в 6 раз. Новый раздел сканируется и индексируется значительно быстрее.