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

Описание

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

Патент решает проблему точной и стабильной идентификации физических хостинг-сущностей (Internet Hosting Entities), таких как веб-серверы или фермы серверов, для эффективного управления процессом сканирования. Полагаться только на текущий IP-адрес недостаточно, так как IP часто меняются (из-за балансировки нагрузки, DHCP, обслуживания или миграции). Изобретение позволяет точно планировать сканирование (Crawl Scheduling) и управлять нагрузкой (Crawl Load), чтобы избежать перегрузки отдельных серверов.

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

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

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

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

• Отслеживание истории: Система ведет IP Address History для каждого хостнейма, периодически опрашивая DNS.
• Кластеризация и Ядро (Kernel): Хостнеймы группируются на основе схожести их историй IP. Для каждой группы вычисляется Kernel — репрезентативная история IP-адресов (например, наиболее частый IP в каждый момент времени).
• Динамическая корректировка:
• Splitting (Разделение): Если история IP хостнейма отклоняется от Kernel группы больше порогового значения (threshold distance), хостнейм исключается (например, при миграции).
• Merging (Слияние): Если Kernels двух разных групп становятся достаточно близки, группы объединяются.
• Обработка сложности: Система учитывает Equivalent IP Addresses (для CDN/балансировки), CNAME и Wildcard Domains для повышения точности.
• Применение: Идентифицированные группы передаются краулеру для создания независимых очередей сканирования и управления нагрузкой на каждую хостинг-сущность.

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

Высокая. Эффективное управление сканированием и Crawl Budget остается критически важной задачей для Google, особенно в условиях сложных современных инфраструктур (CDN, облачный хостинг, балансировщики нагрузки). Описанные принципы являются фундаментальными для планирования сканирования и обеспечения стабильности веб-ресурсов.

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

Патент имеет значительное влияние на техническое SEO (7/10). Он не описывает факторы ранжирования, но напрямую влияет на то, как Google воспринимает хостинговую инфраструктуру и управляет Crawl Budget и Crawl Rate. Точная идентификация хостинга позволяет Google оптимизировать частоту запросов к серверу. Понимание этого механизма критично для диагностики проблем сканирования, планирования миграций и управления сайтами на общем хостинге.

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

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

Cluster/Group (Кластер/Группа)

Набор хостнеймов, которые, по предположению системы, размещены на одной и той же хостинг-сущности.

CNAME (Canonical Name)

Каноническое имя хостнейма. Хостнеймы с одинаковым CNAME могут агрегироваться. Система отслеживает и сглаживает историю CNAME.

Distance (Расстояние)

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

Equivalent IP Addresses (Эквивалентные IP-адреса)

Несколько IP-адресов, идентифицированных как взаимозаменяемые (например, IP, возвращенные одним DNS-запросом, или IP в ротации балансировщика нагрузки).

Internet Hosting Entity (Сущность интернет-хостинга)

Физический ресурс, который сканируется краулером (например, веб-сервер, ферма серверов).

IP Address History (История IP-адресов)

Временной ряд IP-адресов, связанных с определенным хостнеймом.

Kernel (Ядро)

Репрезентативная история IP-адресов для группы. Обычно это центр или мода (наиболее частый IP) историй участников группы в каждый момент времени.

Merging (Слияние)

Процесс объединения групп, когда их истории IP-адресов (ядра) сходятся.

Sitename (Имя сайта)

Нормализованная часть хостнейма (например, «example1» из «cs.example1.com»). Большое количество уникальных Sitenames в группе указывает на виртуальный хостинг.

Splitting (Разделение)

Процесс удаления хостнейма из группы, когда его история IP-адресов расходится с ядром группы.

Star Topology (Звездообразная топология)

Граф связей между группами-кандидатами на слияние. Используется для определения приоритета слияния.

Wildcard Domain (Подстановочный домен)

Домен, в котором субдомены используют общий IP или семейство IP (например, *.exampleblog.com). Система может выявлять исключения.

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

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

1. Система поддерживает IP address history для хостнеймов, организованных в группы. Каждая группа имеет Kernel, и участники находятся в пределах threshold distance от него.
2. Данные предоставляются краулеру для планирования.
3. Система получает обновления истории IP для хостнеймов в первой и второй группах.
4. Kernels обеих групп пересчитываются.
5. Система определяет, что пересчитанные Kernels теперь находятся в пределах threshold distance друг от друга.
6. В результате первая и вторая группы объединяются (merging).

Claim 2 (Зависимый от 1): Детализирует управление расписанием сканирования (очередями) после слияния.

После слияния система выбирает расписание сканирования (crawling schedule) одной из исходных групп для объединенной группы. Выбор делается так, чтобы минимизировать общее количество URL-адресов, которые будут перемещены на новое расписание. Это оптимизирует внутренние ресурсы Google.

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

Система использует star topology для определения приоритета. Группа, которая имеет наибольшее количество связей (edges) с другими группами-кандидатами на слияние, объединяется в первую очередь.

Claims 5, 6, 7 (Зависимые от 1): Описывают адаптацию к разным типам хостинга.

• (Claim 5) Динамические IP: Если IP динамические, для сравнения Kernels анализируется более длинный участок истории.
• (Claim 6) Статические IP: Если IP статические, слияние выполняется после предопределенной задержки (predetermined delay) для обеспечения стабильности.
• (Claim 7) Виртуальный хостинг: Если группа содержит много sitenames (виртуальный хостинг), объединение выполняется без задержки.

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

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

Его основная цель — управление планированием и нагрузкой при сканировании (Crawl Scheduling и Crawl Load Management).

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

• Cluster System (Система кластеризации) взаимодействует с Domain Name System (DNS) для получения актуальных IP и CNAME.
• Данные обрабатываются и сохраняются в Host Cluster Information.
• Crawler System (Система сканирования) использует данные о группах хостов для формирования независимых очередей сканирования и регулирования частоты запросов (Crawl Rate) к каждой хостинг-сущности.

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

• Ответы DNS (IP-адреса, CNAME) с течением времени.
• Список хостнеймов и данные о предыдущих группировках.
• Количество URL, связанных с каждым хостнеймом (используется при назначении идентификаторов).

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

• Коллекция групп (кластеров), где каждая группа представляет отдельную Internet Hosting Entity.
• Идентификаторы групп для управления очередями сканирования.

На что влияет

• Инфраструктура хостинга: Алгоритм критически важен для корректной обработки сложных сред: балансировщиков нагрузки, CDN, виртуального (shared) хостинга, крупных платформ с Wildcard Domains.
• Crawl Budget и Crawl Rate: Напрямую влияет на то, как Google распределяет ресурсы сканирования и какую нагрузку оказывает на сервер.
• Миграции сайтов: Определяет, как быстро Google адаптирует расписание сканирования после переезда сайта на новый хостинг.

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

Процесс работает непрерывно или периодически для обновления карты хостинга.

• Триггеры активации: Изменение IP-адресов или CNAME хостнеймов при опросе DNS.
• Частота применения: Система итеративно пересчитывает группы (Splitting и Merging) до достижения стабильного состояния (steady state).
• Пороговые значения и задержки: Применяется threshold distance для принятия решений. Используются временные задержки (predetermined delay) для статических IP, чтобы игнорировать временные флуктуации.

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

Процесс идентификации хостинг-сущностей (соответствует FIG. 8):

1. Сбор данных и обновление: Система загружает предыдущие группы и истории IP. Получает свежие данные из DNS, обновляя IP Address Histories.
2. Агрегация и Предварительная обработка (Cluster Aggregator):
   • Идентифицируются Equivalent IP Addresses (например, пул IP балансировщика).
   • Агрегируются истории IP для хостнеймов с одинаковым CNAME (после сглаживания истории CNAME) или принадлежащих одному Wildcard Domain (выявляя и исключая хостнеймы с отличающимися историями).
   • Выполняется интерполяция пропущенных данных, если паттерн известен.
3. Расчет Ядер (Kernel Calculation): Для каждой группы вычисляется Kernel (например, наиболее частый IP в каждый момент времени).
4. Разделение (Cluster Splitter): История IP каждого хостнейма сравнивается с Kernel его группы. Если расстояние (возможно, взвешенное в пользу недавних данных) превышает порог, хостнейм удаляется из группы.
5. Слияние (Cluster Merger):
   • Kernels разных групп сравниваются. Идентифицируются кандидаты на слияние (расстояние ниже порога).
   • Строится Star Topology связей. Группа с наибольшим количеством связей объединяется со своими кандидатами в первую очередь.
   • Применяются правила задержек: задержка для статических IP; без задержки для виртуального хостинга (много sitenames); анализ более длинной истории для динамических IP.
6. Назначение идентификаторов (Cluster Identifier): После изменений система назначает идентификаторы (и очереди сканирования) новым группам. Используется алгоритм (например, минимальное взвешенное максимальное соответствие в двудольном графе) для минимизации количества URL, перемещаемых между очередями.
7. Вывод данных: Обновленные группы предоставляются краулеру.

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

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

Патент использует исключительно инфраструктурные данные, связанные с DNS и организацией сайтов.

• Технические факторы:
  • IP-адреса: Основные данные, собираемые в виде временных рядов (IP Address History).
  • CNAME (Канонические имена): Используются для агрегации хостнеймов. История CNAME также отслеживается.
  • Ответы DNS: Информация о том, какие IP возвращаются в одном ответе (для определения эквивалентности).
• Структурные факторы:
  • Hostnames: Анализируются для определения Sitenames и принадлежности к Wildcard Domains.
• Системные данные:
  • Количество URL: Количество URL, связанных с хостнеймами/группами. Используется для оптимизации назначения идентификаторов при слияниях/разделениях.

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

• Kernel (Ядро): Вычисляется как центр (например, мода) историй IP-адресов участников группы в каждый момент времени.
• Distance Metric (Метрика расстояния): Измеряет разницу между временными рядами. Может учитывать количество несовпадений во времени. Метрика может быть взвешенной (больший вес у недавних данных).
• Threshold Distance (Пороговое расстояние): Максимально допустимое расхождение для Splitting или Merging.
• Predetermined Delay (Предопределенная задержка): Временной порог, применяемый к изменениям статических IP для обеспечения стабильности.
• Sitename Count (Количество имен сайтов): Количество уникальных sitenames в группе. Используется для идентификации виртуального хостинга и изменения логики задержек.

Выводы

1. История IP важнее текущего значения: Google определяет инфраструктуру хостинга, анализируя историю изменения IP-адресов, а не только текущий IP. Это обеспечивает стабильность системы сканирования.
2. Цель — управление Crawl Budget на уровне хостинга: Основная задача системы — идентифицировать физический хостинг (Hosting Entity) и регулировать общую нагрузку на него, а не на отдельные домены.
3. Устойчивость к временным изменениям и балансировке: Система спроектирована так, чтобы игнорировать временные изменения IP. Использование Equivalent IP Addresses позволяет корректно обрабатывать CDN и балансировщики нагрузки. Задержки (Predetermined Delay) для статических IP предотвращают реакцию на временные сбои.
4. Динамическая адаптация к миграциям: Механизмы Splitting и Merging позволяют системе обнаруживать реальные миграции сайтов на новый хостинг и корректировать расписание сканирования.
5. Использование вспомогательных DNS-сигналов: Помимо IP, система использует CNAMEs и Wildcard Domains для уточнения и агрегации данных о хостинге.
6. Дифференцированный подход к хостингу: Система адаптирует логику (задержки, длину анализируемой истории) в зависимости от типа хостинга: статический, динамический или виртуальный (определяется по количеству sitenames).

Практика

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

• Обеспечение стабильности и консистентности DNS: Убедитесь, что DNS-записи точны, стабильны и время ответа сервера минимально. Стабильная история DNS помогает Google точно идентифицировать вашу хостинг-сущность и эффективно планировать сканирование.
• Плавная миграция хостинга (Важно!): При смене IP-адресов обеспечьте период перекрытия. Не отключайте старую инфраструктуру сразу после смены DNS. Система использует задержки (predetermined delay) для подтверждения миграции. Плавный переход дает время для корректного выполнения Splitting и Merging и адаптации очереди сканирования.
• Мониторинг Crawl Stats при изменениях инфраструктуры: Отслеживайте частоту запросов Googlebot в GSC (Crawl Stats) после смены хостинга, IP или подключения CDN. Изменения в поведении краулера могут быть отложенными, пока система не стабилизирует новые кластеры.
• Консистентность для CDN и балансировщиков: Убедитесь, что диапазоны IP, используемые CDN или балансировщиком, относительно стабильны. Это поможет системе идентифицировать их как Equivalent IP Addresses и не разделять хостнеймы, использующие разные IP одного пула.
• Осознанный выбор общего хостинга (Shared Hosting): Помните, что сайты на общем хостинге идентифицируются как одна сущность и делят общий Crawl Budget. Проблемы с производительностью сервера (даже вызванные «соседями») снизят скорость сканирования вашего сайта.

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

• Частые и хаотичные изменения DNS («Флаппинг»): Постоянное изменение IP-адресов или CNAME затрудняет расчет стабильного Kernel и может привести к неэффективному сканированию и проблемам с Crawl Budget.
• Высокий уровень ошибок DNS или сервера: Если DNS недоступен, это создает пробелы в IP Address History. Если сервер часто отвечает ошибками (5xx), краулер снизит скорость запросов ко всей идентифицированной группе (кластеру).
• Резкая смена хостинга без перекрытия: Быстрое отключение старого сервера при миграции может привести к временному выпадению сайта из очереди сканирования или ошибкам сканирования, пока система не адаптируется к новой конфигурации.

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

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

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

Сценарий 1: Миграция сайта на новый выделенный сервер

1. Исходное состояние: Сайт (Site A) находится в Группе 1 на Хостинге X (IP=1.1.1.1). IP статический.
2. Действие: DNS обновляется на Хостинг Y (IP=2.2.2.2). Обеспечено перекрытие.
3. Реакция системы (Задержка): Система видит изменение IP, но поскольку IP был статическим, активируется predetermined delay (например, несколько дней), чтобы убедиться, что это не временный сбой.
4. Реакция системы (Splitting): После задержки история IP сайта A значительно расходится с Kernel Группы 1. Сайт A исключается из Группы 1.
5. Реакция системы (Merging/Новая группа): Сайт A формирует новую Группу 2 на IP=2.2.2.2.
6. Результат: Сканирование Сайта A продолжается по новому расписанию, соответствующему мощности Хостинга Y. Переход занимает время из-за задержки.

Сценарий 2: Использование CDN с динамическими IP

1. Ситуация: Сайт подключает CDN, который ротирует IP-адреса из пула (IP-C, IP-D, IP-E).
2. Реакция системы: Google видит частые изменения в IP Address History.
3. Анализ: Система идентифицирует, что хостнейм циклически использует фиксированный набор IP.
4. Обработка: Система помечает IP-C, IP-D, IP-E как Equivalent IP Addresses. При сравнении с Kernel совпадение с любым из этих IP считается нормой.
5. Результат: Несмотря на постоянную смену IP, идентификация хостинга (CDN) остается стабильной, и сайт не меняет свою группу краулинга.

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