Как Google адаптивно регулирует скорость сканирования сайтов, чтобы не перегружать серверы (Crawl Budget Management)

Описание

Какую задачу решает

Патент решает задачу эффективного и масштабного сканирования интернета при соблюдении «политики вежливости» (politeness) по отношению к веб-серверам (hosts). Основная проблема — как сбалансировать необходимость быстро сканировать высокоприоритетные страницы и необходимость не перегружать отдельные хосты слишком частыми запросами. Если система всегда выбирает самый приоритетный URL, она может отправить множество запросов подряд на один и тот же сервер, вызвав его перегрузку.

Что запатентовано

Запатентована система и метод распределенного сканирования, который группирует URL-адреса по хостам и управляет частотой обращений к каждому хосту с помощью Stall Time (времени простоя). Stall Time определяет самое раннее время, когда можно снова сканировать данный хост. Система организует хосты в «корзины» (Buckets) в зависимости от количества оставшихся для сканирования URL. Ключевой особенностью является адаптивная корректировка Stall Time на основе фактического времени ответа сервера (Retrieval Time) и желаемой нагрузки (Load Factor).

Как это работает

Система работает следующим образом:

• Сбор и Группировка: Центральный URL Server получает списки приоритетных URL от распределенных URL Managers и группирует их по хостам.
• Организация по корзинам (Buckets): Хосты распределяются по корзинам в зависимости от того, сколько URL на них осталось просканировать (например, Корзина 10 содержит хосты с 10 URL).
• Stall Time: Каждому хосту назначается Stall Time — время, до которого его нельзя сканировать.
• Выбор следующего URL: Когда краулер запрашивает URL, URL Server ищет хост, у которого Stall Time уже прошло. Поиск начинается с корзин с наибольшим количеством URL.
• Адаптация: После сканирования система измеряет фактическое время ответа сервера (Retrieval Time) и использует его вместе с коэффициентом нагрузки (Load Factor) для расчета нового Stall Time. Если сервер отвечает медленно, Stall Time увеличивается.
• Перемещение: Хост перемещается в следующую корзину (например, из Корзины 10 в Корзину 9).

Актуальность для SEO

Высокая. Управление бюджетом сканирования (Crawl Budget) и скоростью сканирования (Crawl Rate Limit) остается критически важной задачей для Google. Описанные механизмы адаптивного сканирования и «вежливости» к хостам являются фундаментальными для работы Googlebot. Изобретатели (включая Jeff Dean и Sanjay Ghemawat) являются ключевыми архитекторами инфраструктуры Google.

Важность для SEO

Патент имеет высокое значение для технического SEO (7.5/10), особенно для крупных сайтов. Он раскрывает конкретный механизм того, как Google управляет бюджетом сканирования. Ключевой вывод: скорость ответа сервера напрямую и линейно влияет на частоту сканирования. Медленные серверы будут сканироваться реже из-за адаптивного увеличения Stall Time. Это подчеркивает критическую важность оптимизации производительности сервера для обеспечения эффективного индексирования контента.

Детальный разбор

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

Stall Time (Время простоя)

Ключевая метрика планирования. Метка времени, связанная с хостом, указывающая самое раннее время, когда можно снова обратиться к этому хосту для сканирования. Используется для ограничения скорости (rate limiting).

Bucket (Корзина)

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

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

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

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

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

URL Server (или Link Server)

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

URL Managers (или Link Managers)

Распределенные компоненты, которые отслеживают состояние (status) каждого URL в системе (например, «not crawled», «in flight», «crawled») и предоставляют списки высокоприоритетных URL для URL Server.

Crawlers (Краулеры)

Компоненты системы, отвечающие за фактическую загрузку документов с серверов. Запрашивают URL у URL Server.

Host (Хост)

Веб-сервер, на котором размещены документы. Может быть идентифицирован по доменному имени или IP-адресу.

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

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

1. Система получает множество ссылок для сканирования.
2. Ссылки группируются по хостам.
3. Хосты группируются в корзины (buckets) в соответствии с количеством (quantities) ссылок, которые нужно просканировать на этих хостах.
4. Выбирается конкретный хост из первой корзины для следующего сканирования путем прохода по корзинам, пока не будет найдена корзина, включающая хост, удовлетворяющий определенному условию (particular condition).
5. Сканируется ссылка с выбранного хоста.
6. Хост перемещается из первой корзины во вторую корзину, которая содержит хосты с меньшим количеством ссылок для сканирования (N-1).

Ядро изобретения — это метод организации очереди, где хосты динамически перемещаются между корзинами в зависимости от объема оставшейся работы. «Определенное условие» (как уточняется в зависимых пунктах) — это проверка Stall Time.

Claim 2 (Зависимый от 1): Уточняет организацию внутри корзин.

Хосты в первой корзине хранятся в порядке, основанном на их Stall Times.

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

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

1. Определяется время извлечения (Retrieval Time) документа с выбранного хоста.
2. Stall Time для этого хоста корректируется на основе определенного Retrieval Time.
3. Следующая ссылка с этого хоста сканируется на основе скорректированного Stall Time.

Это механизм адаптации скорости сканирования к производительности сервера. Если сервер замедляется, Retrieval Time увеличивается, что приводит к увеличению Stall Time и снижению частоты сканирования.

Claims 5, 6, 7 (Зависимые): Детализируют расчет Stall Time.

Корректировка Stall Time основывается на Load Factor, связанном с хостом, и текущем времени. Расчет включает деление оценочного (Claim 6) или фактического (Claim 7) Retrieval Time на Load Factor и прибавление результата к текущему времени.

Формула: Новый Stall Time = Текущее время + (Retrieval Time / Load Factor).

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

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

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

Компоненты и взаимодействие:

• URL Managers: Работают распределенно. Отслеживают приоритеты URL (упоминаются PageRank Processes) и передают списки в URL Server.
• URL Server: Центральный оркестратор очереди. Отвечает за группировку по хостам/корзинам и управление Stall Time. Выдает задания Crawlers.
• Crawlers: Запрашивают URL у URL Server, выполняют загрузку, измеряют Retrieval Time и передают контент далее в систему.

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

• Списки высокоприоритетных URL от URL Managers.
• Параметры конфигурации хостов (например, Load Factor).
• Фактическое Retrieval Time после завершения сканирования.

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

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

На что влияет

• Технические факторы (Скорость сервера): Наибольшее влияние оказывается на сайты с медленной скоростью ответа сервера. Механизм адаптивного Stall Time напрямую наказывает медленные хосты снижением частоты сканирования.
• Размер сайта: Критически влияет на крупные сайты (e-commerce, порталы). Организация по Buckets гарантирует, что система приоритизирует сайты с большим количеством контента в очереди, но скорость обработки этой очереди будет зависеть от производительности серверов.
• Специфические хосты: Патент упоминает возможность установки индивидуальных Load Factor. Высокопроизводительные хосты могут получить Load Factor > 1, что позволяет параллельное сканирование.

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

• Условия работы: Алгоритм работает непрерывно в процессе сканирования интернета.
• Триггеры активации: Активируется каждый раз, когда краулер запрашивает следующий URL для сканирования у URL Server.
• Адаптация: Механизм корректировки Stall Time активируется после каждого сканирования URL на основе измеренного Retrieval Time.

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

Процесс А: Подготовка очереди (URL Server)

1. Запрос списков: URL Server определяет, что запасы URL заканчиваются, и запрашивает данные у URL Managers.
2. Группировка по хостам: Полученные URL группируются по хостам.
3. Распределение по корзинам: Хосты помещаются в Buckets в зависимости от количества URL, которые нужно просканировать (например, хост с 50 URL попадает в Bucket 50).
4. Сортировка в корзинах: Внутри каждой корзины хосты сортируются по их текущему Stall Time (самые ранние в начале).

Процесс Б: Выдача URL и Адаптация (URL Server и Crawler)

1. Запрос от краулера: Краулер запрашивает у URL Server следующий URL.
2. Поиск подходящего хоста: URL Server начинает поиск с корзины с наибольшим номером и движется вниз.
3. Проверка Stall Time: В каждой корзине проверяется первый хост. Если его Stall Time позже текущего времени, вся корзина пропускается (так как остальные хосты в ней имеют еще более позднее Stall Time из-за сортировки).
4. Выбор хоста: Поиск продолжается, пока не будет найден хост, чей Stall Time раньше текущего времени.
5. Выдача URL и Сканирование: Один URL с этого хоста выдается краулеру. Краулер сканирует URL и определяет фактическое время ответа (Retrieval Time).
6. Расчет нового Stall Time (Адаптация): Система рассчитывает новый Stall Time. Формула: Новый Stall Time = Текущее время + (Retrieval Time / Load Factor).
7. Обновление и перемещение: Хосту назначается новый Stall Time, и он перемещается в корзину с меньшим номером (N-1) и вставляется в нее с сохранением сортировки по Stall Time.

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

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

• Технические факторы:
  • Время загрузки (Retrieval Time): Измеряется в реальном времени при каждом сканировании. Является ключевым фактором для адаптивной настройки скорости сканирования.
  • Идентификатор Хоста (Host ID): Используется для группировки URL и применения правил Stall Time на уровне сервера.
  • Код ответа сервера: Используется URL Managers для определения статуса URL (например, «crawled», «server error», «unreachable»).
• Ссылочные факторы (косвенно):
  • Приоритет/PageRank: Упоминается в патенте. Используется URL Managers для определения того, какие URL отправить в URL Server в первую очередь. Определяет Crawl Demand.
• Системные данные:
  • Load Factor: Предопределенный или скорректированный коэффициент нагрузки для хоста.

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

• Stall Time (Время простоя): Рассчитывается для ограничения частоты запросов к хосту (Crawl Rate Limit). Формула (на основе Claims 6, 7): Stall Time = Текущее время + Интервал.
• Интервал между запросами: Рассчитывается для достижения желаемой нагрузки. Формула: Интервал = Retrieval Time / Load Factor.
• Пример расчета: Если Retrieval Time = 3 секунды, а Load Factor = 0.1 (10% нагрузки), то интервал = 3 / 0.1 = 30 секунд.
• Количество непросканированных URL на хосте: Используется для определения того, в какую Bucket поместить хост.

Выводы

1. Адаптивное сканирование на основе производительности: Патент описывает четкий механизм, посредством которого Google адаптирует скорость сканирования к возможностям сервера. Система измеряет фактическое время ответа (Retrieval Time) и использует его для расчета времени простоя (Stall Time). Медленные серверы получают более длительные паузы между запросами.
2. Прямое влияние скорости сервера на Crawl Budget: Производительность сервера является критическим элементом технического SEO, напрямую влияющим на то, как часто и полно Googlebot сможет сканировать сайт (Crawl Rate Limit).
3. Механизм «Вежливости» (Politeness): Stall Time является основным инструментом для предотвращения перегрузки хостов. Система гарантирует соблюдение интервалов между запросами к одному хосту.
4. Баланс приоритета и вежливости: Система стремится сканировать высокоприоритетные URL (Crawl Demand, определяемый URL Managers), но фильтрует эту очередь через механизм Stall Time. Организация по Buckets помогает приоритизировать хосты с большим количеством задач, но только если они технически доступны.
5. Настраиваемая агрессивность сканирования: Load Factor позволяет регулировать агрессивность. Для высокопроизводительных сайтов он может быть выше 1, что позволяет параллельное сканирование.

Практика

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

• Оптимизация скорости ответа сервера (TTFB и Retrieval Time): Это критически важно. Необходимо минимизировать время ответа сервера, так как оно напрямую используется для расчета Stall Time. Чем быстрее сервер, тем короче паузы Googlebot делает между запросами, и тем больше страниц будет просканировано.
• Инвестиции в надежный и производительный хостинг: Использование качественного хостинга, CDN и современной инфраструктуры обеспечивает стабильно низкий Retrieval Time. Это позволяет Googlebot эффективнее расходовать бюджет сканирования и потенциально может привести к увеличению Load Factor.
• Мониторинг логов сервера и отчетов Google Search Console: Анализируйте логи на предмет времени ответа для Googlebot и следите за статистикой сканирования в GSC. Резкое увеличение «Среднего времени ответа» является сигналом к немедленной оптимизации, так как это увеличивает Stall Time.
• Повышение авторитетности сайта (PageRank): Хотя патент фокусируется на скорости сканирования, он упоминает, что в очередь попадают высокоприоритетные URL. Необходимо работать над ссылочным профилем, чтобы увеличить Crawl Demand и гарантировать попадание важных страниц в очередь URL Server.

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

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

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

Патент подтверждает фундаментальные принципы управления Crawl Budget. Он дает четкое понимание, что бюджет сканирования динамичен и напрямую зависит от технических возможностей сервера. Стратегически, техническое SEO должно уделять первостепенное внимание производительности и стабильности серверной инфраструктуры. Для Senior SEO-специалистов это означает необходимость тесного взаимодействия с DevOps и инфраструктурными командами для обеспечения оптимальных условий работы Googlebot.

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

Сценарий: Влияние скорости сервера на частоту сканирования (Crawl Rate)

Сайт А и Сайт Б имеют одинаковый размер и приоритет. Google использует стандартный Load Factor 0.1 (пауза в 10 раз дольше времени ответа).

1. Сайт А (Оптимизированный):
   • Средний Retrieval Time: 0.3 секунды (300 мс).
   • Расчетный интервал (влияет на Stall Time): 0.3 / 0.1 = 3 секунды.
   • Частота сканирования: Googlebot может сканировать страницу каждые 3 секунды.
2. Сайт Б (Медленный):
   • Средний Retrieval Time: 2.5 секунды (2500 мс).
   • Расчетный интервал (влияет на Stall Time): 2.5 / 0.1 = 25 секунд.
   • Частота сканирования: Googlebot может сканировать страницу только каждые 25 секунд.
3. Результат: Сайт А будет просканирован более чем в 8 раз быстрее, чем Сайт Б, исключительно из-за разницы в производительности сервера. Новый контент на Сайте А попадет в индекс значительно быстрее.

Вопросы и ответы