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

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

Boost Factor (Коэффициент повышения/понижения)

Скалярное значение, используемое для искусственного повышения или понижения Priority Score URL. Например, для продвижения новостных сайтов или главных страниц крупных компаний.

Capacity Limits / Scheduler Limits (Лимиты мощности / Лимиты планировщика)

Ограничения, применяемые для управления нагрузкой. Примеры: максимальное количество URL на хост, на домен или определенного типа файлов (например, CGI файлы).

Content Checksum (Контрольная сумма контента)

Значение, рассчитанное на основе содержимого документа. Используется для определения, изменился ли документ между сканированиями.

History Logs (Журналы истории)

Записи о прошлых попытках сканирования URL, включая Timestamp, Crawl Status (статус сканирования), Content Checksum, Source ID (источник загрузки) и Page Importance на момент сканирования.

Page Importance (Важность страницы)

Метрика, определяющая значимость URL. В патенте прямо упоминается PageRank как пример Page Importance. Является основой для расчета Priority Score.

Priority Score (Оценка приоритета)

Итоговая оценка, используемая для сортировки URL в очереди на сканирование. Рассчитывается как произведение Page Importance и Boost Factor.

Reuse Server (Сервер повторного использования)

Компонент, который анализирует History Logs для определения, следует ли загружать документ из сети или использовать локальную копию.

Reuse Table (Таблица повторного использования)

Таблица с инструкциями для роботов (Googlebot) о том, как обрабатывать URL.

Reuse Type (Тип повторного использования)

Флаг в Reuse Table. Варианты: DOWNLOAD (загрузить), REUSE (использовать копию) или REUSE IF NOT MODIFIED SINCE (условная загрузка).

URL Schedulers (Планировщики URL)

Распределенные компоненты, отвечающие за выбор и приоритизацию URL для следующего цикла сканирования.

URL Status File (Файл статуса URL)

Хранилище данных о состоянии URL, содержащее информацию о предыдущих статусах сканирования (ошибки, недоступность).

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

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

1. Система хранит идентификаторы документов (URL) и данные о статусе (Status Data) из предыдущих сканирований.
2. Множество планировщиков выбирают подмножество URL для сканирования.
3. Планировщики рассчитывают Priority Scores и планируют сканирование на основе этих оценок И Status Data.
4. Ключевой аспект: Планирование включает удаление URL, которые были недоступны (unreachable) или имели ошибки загрузки (download errors) в нескольких последовательных предыдущих сканированиях (plurality of consecutive prior crawls).
5. Планировщики определяют URL, контент которых будет повторно использован (reused) на основе исторических данных.
6. Документы для повторного использования извлекаются из локального репозитория, а не с веб-хостов.

Claim 5 (Зависимый от 1): Детализирует расчет Priority Score.

Оценка приоритета рассчитывается с использованием функции: $Priority Score_i = Page\_Importance_i * Boost\_Factor_i$. Boost Factor используется для повышения или понижения приоритета.

Claim 8 (Зависимый от 6): Описывает применение ограничений.

После выбора приоритизированных URL, из этого списка удаляются URL в соответствии с одним или несколькими Scheduler Limits (например, лимиты мощности хоста или домена).

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

Изобретение является центральным компонентом этапа CRAWLING – Сканирование и Сбор данных. Оно определяет всю логику планирования работы краулера (Googlebot).

CRAWLING – Сканирование и Сбор данных
URL Schedulers определяют план сканирования (Crawl Scheduling) и управляют бюджетом (Crawl Budget Management). Они решают, что именно Robots будут загружать.

INDEXING – Индексирование и извлечение признаков
Система планирования использует данные, сгенерированные на этапе индексирования предыдущих циклов:

• Page Importance Scores (например, PageRank), рассчитанные Page Rankers.
• History Logs и URL Status Files, созданные Content Processing Servers.

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

• Списки URL из предыдущего цикла сканирования.
• URL Status Files (история ошибок и доступности).
• Page Importance scores (PageRank).
• History Logs (контрольные суммы контента, временные метки).
• Scheduler Limits (параметры мощности) и Boost Factors.

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

• Schedule Output File (приоритизированный список URL для сканирования).
• Reuse Table (инструкции по повторному использованию).
• Unscheduled URLs File (опционально, список URL, не попавших в расписание).

На что влияет

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

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

• Частота применения: Процесс планирования выполняется периодически, перед началом каждого цикла сканирования (epoch или crawl cycle).
• Триггеры и пороги: Система использует несколько пороговых значений:
  • Порог X: Количество последовательных неудачных сканирований (ошибки/недоступность) для удаления URL из расписания.
  • Пороги важности (Threshold 1 и 2): Определяют логику Reuse (всегда загружать vs условно загружать).
  • Порог Y: Максимальное количество последовательных повторных использований (Reuse) перед принудительной загрузкой.

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

Система состоит из двух основных процессов: Процесс А (Планирование URL) и Процесс Б (Определение повторного использования).

Процесс А: Планирование URL (URL Scheduler)

1. Получение исходного списка: Извлекается список URL, запланированных в предыдущем цикле.
2. Фильтрация ошибок: Удаляются URL, которые были недоступны или выдавали ошибки в течение последних X последовательных сканирований. Информация берется из URL Status File.
3. Применение исключений: Применяются дополнительные фильтры (Exception Filters), например, удаление спама.
4. Расчет приоритета: Для оставшихся URL рассчитывается Priority Score по формуле: $Page\_Importance * Boost\_Factor$.
5. Сортировка и Выбор Топ-N: URL сортируются по Priority Score, выбираются первые N URL (N резервирует часть мощности для новых ссылок).
6. Применение лимитов мощности: Применяются Scheduler Limits (например, не более K документов с одного хоста/домена).
7. Запись результата: Итоговый список записывается в Schedule Output File.

Процесс Б: Определение повторного использования (Reuse Server)

1. Анализ URL: Обработка списка URL с использованием History Logs.
2. Проверка Порога 1 (Высокая важность): Если Page Importance > Threshold 1.
   • Установить Reuse Type = DOWNLOAD.
3. Проверка Порога 2 (Средняя важность): Если Page Importance > Threshold 2.
   • Если последнее сканирование было из веба: Установить Reuse Type = REUSE UNLESS MODIFIED SINCE (условная загрузка).
   • Если последнее сканирование было из репозитория (Reuse): Установить Reuse Type = DOWNLOAD.
4. Проверка истории изменений: Если важность низкая. Анализируется история Content Checksum за определенный период (например, 45 дней).
   • Если контент менялся: Установить Reuse Type = DOWNLOAD.
5. Проверка частоты Reuse: Если контент не менялся. Проверяется, использовался ли URL повторно в последних Y сканированиях.
   • Если ДА (лимит достигнут): Установить Reuse Type = DOWNLOAD (принудительное обновление).
   • Если НЕТ: Установить Reuse Type = REUSE.
6. Сохранение результата: Запись URL и его Reuse Type в Reuse Table.

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

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

• Технические факторы:
  • URL (и их фингерпринты).
  • Данные хоста и домена (для применения Capacity Limits).
  • Статус предыдущего сканирования (Crawl Status): коды ошибок (HTTP 4xx), недоступность хоста (unreachable status).
  • Source ID: Источник предыдущей загрузки (Веб или Репозиторий).
• Ссылочные факторы:
  • Page Importance (PageRank). Критически важен для расчета Priority Score и определения логики Reuse.
• Временные факторы:
  • Timestamps сканирования, история изменений за период.
  • Даты модификации документа (для условной загрузки).
• Контентные факторы:
  • Content Checksum используется для отслеживания изменений контента между сканированиями.

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

• Page Importance: Внешняя метрика (например, PageRank).
• Priority Score: Основная метрика планировщика. Формула: $Page\_Importance * Boost\_Factor$.
• Reuse Type: Определяется Reuse Server. Значения: DOWNLOAD, REUSE, REUSE IF NOT MODIFIED SINCE.
• Пороговые значения:
  • Threshold 1 и 2: Пороги Page Importance для логики Reuse.
  • X: Порог последовательных ошибок/недоступности для удаления URL из расписания.
  • Y: Лимит последовательных Reuse перед принудительной загрузкой.
  • N: Количество URL, выбираемых после сортировки.

1. PageRank (Page Importance) — главный драйвер сканирования: Патент явно указывает, что Page Importance является основой для Priority Score. Чем выше PageRank, тем выше приоритет и чаще сканирование (и меньше вероятность Reuse).
2. Критичность технического SEO и стабильности: Система агрессивно удаляет из расписания URL, которые демонстрируют постоянные проблемы (ошибки 4xx или недоступность сервера) в течение нескольких последовательных попыток. Техническое здоровье критично для индексации.
3. Стратегическое повторное использование контента (Reuse): Google экономит ресурсы за счет Reuse. Логика зависит от важности и истории изменений: высоковажные страницы почти всегда загружаются заново; низковажные, статичные страницы часто используются повторно.
4. Управление Crawl Budget через лимиты: Система активно управляет нагрузкой с помощью Scheduler Limits (лимиты на хост/домен). Это объясняет, почему на крупных сайтах не все страницы сканируются одновременно, даже если они приоритетны.
5. Защита от "заморозки" контента: Существует механизм принудительного обновления даже для статичных страниц после Y циклов Reuse, что гарантирует периодическую проверку актуальности.
6. Boost Factors как инструмент корректировки: Система предусматривает возможность искусственной корректировки приоритета сканирования для определенных URL или сайтов (например, новостных), независимо от их Page Importance.

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

• Оптимизация внутренней перелинковки и получение внешних ссылок: Поскольку Page Importance (PageRank) напрямую влияет на Priority Score, необходимо стратегически распределять ссылочный вес на ключевые страницы. Это повысит их приоритет сканирования и частоту обновления в индексе.
• Обеспечение стабильности сервера и минимизация ошибок: Критически важно мониторить логи сервера и исправлять ошибки (4xx, 5xx). Постоянные ошибки приводят к удалению URL из расписания сканирования (Crawl Schedule) после достижения порога X.
• Корректная настройка условных ответов сервера (If-Modified-Since): Для страниц средней важности Google использует механизм REUSE IF NOT MODIFIED SINCE. Корректная настройка заголовков Last-Modified и ETag на сервере позволяет эффективно использовать этот механизм, экономя краулинговый бюджет и ускоряя обработку.
• Управление структурой сайта для оптимизации лимитов: Для крупных сайтов важно учитывать Capacity Limits. Избегайте генерации мусорных URL (например, неоптимизированной фасетной навигации), которые могут потреблять лимиты хоста до того, как будут просканированы важные страницы.
• Обновление контента для предотвращения нежелательного Reuse: Если страница имеет низкую Page Importance, но требует обновления в индексе, необходимо вносить значимые изменения в контент. Это изменит Content Checksum и заставит систему установить Reuse Type в DOWNLOAD.

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

• Игнорирование технических ошибок и нестабильный хостинг: Допущение большого количества ошибок 404 или частая недоступность сервера (5xx, таймауты) приведет к исключению URL из сканирования.
• Слабая внутренняя ссылочная структура: Создание глубокой архитектуры или страниц-сирот приведет к низкому Page Importance, низкому приоритету сканирования и частому использованию механизма Reuse.
• Некорректная отдача Last-Modified: Отдача неверных дат модификации (например, всегда текущая дата) или некорректная обработка условных запросов мешает работе механизма Reuse, приводя к избыточному сканированию или индексации устаревшего контента.
• Ожидание частого сканирования статичного, неважного контента: Если страница не важна (мало ссылок) и контент не меняется, система переключится в режим REUSE для экономии ресурсов.

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

Этот патент подтверждает фундаментальную связь между ссылочной авторитетностью (PageRank) и поведением краулера. PageRank используется не только для ранжирования, но и является основным сигналом для планирования сканирования. Для Senior SEO-специалистов это подчеркивает необходимость интеграции стратегий по управлению ссылочным весом с технической оптимизацией сайта для достижения максимальной эффективности индексации и управления краулинговым бюджетом.

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

Сценарий 1: Медленное обновление карточки товара в индексе (E-commerce)

1. Ситуация: Карточка товара имеет мало внутренних ссылок (низкий Page Importance). Цена изменилась, но в индексе Google старая информация.
2. Объяснение по патенту: Из-за низкого Page Importance и, возможно, незначительного изменения Content Checksum, Reuse Server установил Reuse Type = REUSE. Система экономит ресурсы.
3. Решение: Увеличить Page Importance страницы через улучшение внутренней перелинковки (блоки похожих товаров, ссылки из категорий). Это повысит Priority Score и увеличит вероятность перевода страницы в режим DOWNLOAD или Conditional Reuse.

Сценарий 2: Резкое снижение количества сканируемых страниц после сбоя сервера

1. Ситуация: После длительного сбоя, когда сервер отдавал ошибки 503, количество сканируемых страниц в день резко упало.
2. Объяснение по патенту: URL Scheduler зафиксировал несколько последовательных ошибок сканирования (превышен порог X) и исключил URL из активного расписания согласно Claim 1.
3. Решение: Немедленно стабилизировать работу сервера и устранить ошибки 503. Планировщик постепенно вернет URL в расписание, как только убедится в надежности хоста и счетчик последовательных ошибок сбросится.