Как Google использует данные о сбоях доступа пользователей для определения доступности сайтов и изменения поисковой выдачи

Описание

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

Патент решает проблему определения рабочего состояния сетевых ресурсов (например, веб-сайтов) в децентрализованной сети, такой как Интернет. Он позволяет системе понять, является ли неудачная попытка доступа локальной проблемой пользователя или глобальной проблемой ресурса (сайт «упал») или сети (проблемы в регионе). Это улучшает пользовательский опыт, информируя пользователей о статусе ресурса, и повышает качество поиска, предоставляя актуальные данные о доступности сайтов поисковой системе.

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

Запатентована система, которая определяет операционный статус сетевых ресурсов путем агрегации и анализа сообщений об ошибках (error messages), полученных от множества устройств пользователей при неудачных попытках доступа. Система анализирует количество сбоев для определенного хоста (hostname) за период времени и сравнивает его с пороговым значением. На основе этого определяется статус ресурса (operational state), который сохраняется в базе данных (Status Database) и может использоваться для информирования пользователей, администраторов сайтов и модификации результатов поиска.

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

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

• Сбор данных: Устройства пользователей (например, через браузер или тулбар) отправляют error messages при неудачной попытке доступа к ресурсу. Сообщение содержит hostname, тип ошибки, время и источник (origin).
• Анализ и агрегация: System Engine анализирует поток ошибок. Для каждого hostname подсчитывается количество ошибок за определенный период.
• Определение статуса: Количество ошибок сравнивается с динамическим порогом (threshold number). Если порог превышен, ресурс помечается как not fully operational.
• Географический анализ: Анализ данных origin позволяет определить, является ли проблема глобальной или региональной.
• Верификация (Опционально): При превышении порога система может инициировать сканирование (web crawl) ресурса для подтверждения его статуса.
• Применение: Статус используется для: (1) Отправки ответа пользователю, объясняющего причину сбоя; (2) Уведомления администратора сайта; (3) Интеграции с Search Engine для изменения SERP (например, показ кэша, изменение ранжирования).

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

Высокая. Мониторинг доступности и скорости работы сайтов критически важен для Google. Использование реальных пользовательских данных (RUM — Real User Monitoring, хотя этот термин в патенте не используется) для определения состояния инфраструктуры Интернета является стандартной практикой. Интеграция этих данных в поиск для управления кэшем и потенциального влияния на ранжирование остается актуальной задачей, особенно в контексте Core Web Vitals и Page Experience.

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

Патент имеет высокое значение для технического SEO (8/10). Он описывает конкретный механизм, как Google может обнаруживать проблемы с доступностью сайта на основе реальных пользовательских данных, независимо от данных краулера. Если сайт часто недоступен для пользователей, система может изменить его отображение в SERP (ссылка на кэш вместо сайта), аннотировать результаты или понизить его в ранжировании. Это подчеркивает важность надежного хостинга, CDN и мониторинга доступности сайта из разных регионов.

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

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

Error Database (База данных ошибок)

Хранилище, содержащее множество сообщений об ошибках (error messages), полученных от коммуникационных устройств пользователей.

Error Message (Сообщение об ошибке)

Данные, отправляемые устройством пользователя в систему при неудачной попытке доступа к сетевому ресурсу. Включает hostname, error type, timestamp и origin.

Hostname (Имя хоста)

Идентификатор сетевого ресурса (например, FQDN — www.example.com, или IP-адрес).

Network Resource (Сетевой ресурс)

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

Operational State (Рабочее состояние)

Оценка доступности сетевого ресурса. Может быть бинарной (operational / not fully operational) или градиентной (например, 75% operational).

Origin (Источник)

Информация об устройстве, отправившем сообщение об ошибке. Может включать сетевой адрес, информацию о сети провайдера или географическое положение.

Search Engine (Поисковая система)

Система, которая может использовать данные о статусе ресурсов для генерации, ранжирования, отображения или форматирования результатов поиска.

Status Database (База данных статусов)

Хранилище, содержащее актуальные данные о статусе (status data) для множества hostnames.

Status Data (Данные о статусе)

Информация, связанная с hostname. Включает Status Identifier и может включать geographic accessibility information.

Status Identifier (Идентификатор статуса)

Метка, указывающая на текущее Operational State ресурса.

System Engine (Системный движок)

Компонент, отвечающий за анализ Error Database и определение Status Data.

Threshold Number (Пороговое значение)

Количество сообщений об ошибках за определенный период времени, при превышении которого статус ресурса может быть изменен. Порог может быть динамическим.

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

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

1. Система получает множество сообщений об ошибках от разных устройств. Каждое сообщение содержит hostname ресурса, к которому не удалось получить доступ.
2. Система ассоциирует status data с этими hostnames. Эта ассоциация основана на количестве полученных сообщений об ошибках для данного hostname за определенный период времени. Status data включает идентификатор рабочего состояния.
3. Status data сохраняется в базе данных.
4. Система получает *дополнительное* сообщение об ошибке от устройства (новая неудачная попытка доступа).
5. Система извлекает из базы актуальные status data для hostname из этого нового сообщения.
6. Система отправляет status message (сообщение о статусе) в ответ на это дополнительное сообщение об ошибке, используя извлеченные status data.

Ядро изобретения (Claim 1) заключается в использовании агрегированных данных о сбоях от множества пользователей для определения статуса сайта и последующего информирования конкретного пользователя о том, является ли его проблема локальной или глобальной.

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

1. Определяется количество сообщений об ошибках для hostname за период времени.
2. Это количество сравнивается с threshold number.
3. Если количество меньше порога: ассоциируется первый идентификатор статуса (ресурс доступен – operational).
4. Если количество больше или равно порогу: ассоциируется второй идентификатор статуса (ресурс недоступен – not fully operational).

Claim 7 (Зависимый от 1): Описывает активную верификацию статуса.

Если количество ошибок превышает или равно threshold number, система инициирует web crawl (сканирование) данного сетевого ресурса.

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

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

Шаги 1-3 аналогичны Claim 1 (Сбор ошибок, Определение статуса на основе количества ошибок, Сохранение в БД).

4. Система получает запрос от Search Engine. Запрос содержит один или несколько hostnames.
5. Система извлекает status data для этих hostnames из базы данных.
6. Система отправляет status data поисковой системе в ответ на запрос.

Это ключевой механизм, позволяющий поисковой выдаче адаптироваться к доступности сайтов в реальном времени.

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

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

CRAWLING – Сканирование и Сбор данных

• Сбор данных об ошибках: Основной механизм сбора данных в этом патенте происходит не через Googlebot, а через пользовательские устройства (браузеры, тулбары). Это форма краудсорсинга состояния сети.
• Триггер для сканирования: Если система обнаруживает превышение порога ошибок, она может инициировать внеочередное сканирование (web crawl) для верификации статуса ресурса (Claim 7). Это может влиять на планирование сканирования (Crawl Scheduling).

INDEXING – Индексирование
На этом этапе система обрабатывает и хранит данные о доступности. Status Database и Error Database являются частью инфраструктуры, обеспечивающей хранение этих сигналов доступности, которые ассоциируются с hostnames.

RANKING / RERANKING – Ранжирование и Переранжирование
Поисковая система может использовать полученные status data для влияния на ранжирование. В патенте прямо указано, что поисковая система может быть настроена на ранжирование результатов, связанных с рабочими веб-сайтами, выше, чем результатов, связанных с менее чем полностью рабочими веб-сайтами.

METASEARCH – Метапоиск и Смешивание (Формирование SERP)
Это основной этап применения данных для пользователя. Поисковая система запрашивает Status Database (Claim 9) и использует данные для модификации SERP:

• Форматирование ссылок: Если сайт недоступен, ссылка в выдаче может вести на кэшированную версию (cached version) вместо живого сайта (Claim 11).
• Аннотирование результатов: Отображение предупреждений или индикаторов о том, что сайт может быть недоступен (Claim 10).
• Исключение результатов: В некоторых реализациях система может исключить недоступные сайты из выдачи.

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

• Поток Error Messages от пользовательских устройств (включая hostname, error type, timestamp, origin).
• Threshold numbers для разных hostnames и временных периодов.
• Запросы от Search Engine, содержащие hostnames.
• Результаты активного web crawl для верификации.

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

• Status Data (Status Identifier, Geographic accessibility information), сохраненные в Status Database.
• Status messages, отправляемые пользователям и администраторам сайтов.
• Ответы поисковой системе с данными о доступности.

На что влияет

• Техническое состояние сайтов: Влияет на все типы контента и сайтов, у которых есть проблемы с доступностью, надежностью хостинга, конфигурацией сети или защитой от DDoS.
• Географические факторы: Система способна различать глобальные и региональные проблемы доступности, что влияет на отображение сайта в SERP для пользователей из разных регионов.

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

• Триггеры активации (Определение статуса): Алгоритм анализа активируется постоянно при получении новых error messages. Изменение статуса происходит, когда количество ошибок превышает threshold number за определенный период времени.
• Триггеры активации (Интеграция с поиском): Активируется в момент формирования SERP, когда поисковая система запрашивает статус для отображаемых результатов.
• Триггеры активации (Уведомления): Активируется в реальном времени, когда пользователь сталкивается с ошибкой доступа (Claim 1), или когда статус сайта меняется на not fully operational (для уведомления администратора).

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

Процесс А: Определение и обновление статуса ресурса

1. Получение данных: Непрерывное получение error messages от множества коммуникационных устройств.
2. Хранение: Сохранение сообщений в Error Database с метками времени и источника.
3. Анализ агрегированных данных: Периодический анализ данных для конкретного hostname за определенный временной интервал (например, каждые 4 минуты, как показано на FIG. 2 в патенте).
4. Подсчет ошибок: Определение общего количества ошибок и количества ошибок по регионам.
5. Сравнение с порогом: Сравнение количества ошибок с соответствующим threshold number (который может зависеть от времени суток, истории ошибок и региона).
6. Принятие решения о статусе:
   • Если количество ошибок < порога: Установить статус operational.
   • Если количество ошибок >= порога: Установить статус not fully operational.
7. Анализ географии (Параллельно шагу 6): Определение, основанное на анализе origin information, вызвана ли проблема недоступностью самого ресурса или сетевой проблемой в определенном регионе. Формирование geographic accessibility information.
8. Активная верификация (Опционально, при превышении порога): Инициация web crawl для подтверждения статуса ресурса. Корректировка статуса по результатам сканирования.
9. Обновление базы данных: Сохранение нового Status Identifier и geographic accessibility information в Status Database.
10. Уведомление администратора (Опционально): Отправка уведомления администратору сайта при изменении статуса на not fully operational.

Процесс Б: Обработка ошибки пользователя в реальном времени

1. Получение ошибки: Получение нового error message от пользователя.
2. Запрос статуса: Извлечение актуальных status data для данного hostname из Status Database.
3. Ответ пользователю: Отправка status message пользователю (например, отображение информации на странице ошибки браузера), информирующего о текущем состоянии ресурса (например, «сайт недоступен для всех» или «проблемы в вашем регионе»).

Процесс В: Интеграция с поисковой системой

1. Формирование SERP: Поисковая система генерирует набор результатов поиска.
2. Запрос статусов: Поисковая система отправляет запрос в System Engine, содержащий hostnames результатов.
3. Получение статусов: Система возвращает status data для запрошенных hostnames.
4. Модификация SERP: Поисковая система использует status data для модификации выдачи: изменение ранжирования, аннотирование результатов, перенаправление ссылок на кэш.

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

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

Патент фокусируется на данных о сбоях доступа и не детализирует стандартные факторы ранжирования.

• Технические факторы / Данные о сбоях:
  • Error type: Тип ошибки, помешавший доступу (например, DNS error, connection error).
  • HTTP request data: Информация, полученная устройством в ответ на HTTP-запрос (если применимо).
• Временные факторы:
  • Timestamp: Дата и время неудачной попытки доступа (используется для анализа частоты ошибок во времени).
• Географические и Пользовательские факторы:
  • Origin: Информация об источнике ошибки (сетевой адрес устройства, информация о сети провайдера, географическое положение устройства). Используется для определения масштаба проблемы (глобальная vs региональная).

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

• Количество сообщений об ошибках (Number of error messages): Подсчет количества неудачных попыток доступа к определенному hostname за defined time period (определенный период времени).
• Threshold Number (Пороговое значение): Эталонное значение для сравнения. В патенте указано, что порог может основываться на:
  • Времени суток (Time of day).
  • Исторических уровнях ошибок (Historical error rates).
  • Количестве ошибок в предыдущем периоде (Number of errors in a previous time period).
  • Ожидаемом количестве ошибок для региона (Expected number of errors from a geographic region).
• Status Identifier (Идентификатор статуса): Вычисляется путем сравнения текущего количества ошибок с порогом. Если Count >= Threshold, статус меняется на not fully operational.
• Geographic Accessibility Information (Информация о географической доступности): Определяется путем анализа распределения origin в потоке ошибок. Если ошибки поступают из разных мест, проблема скорее всего в ресурсе. Если ошибки сконцентрированы в одном регионе, проблема скорее всего в сети этого региона.

Выводы

1. Google использует данные реальных пользователей для мониторинга доступности сайтов: Система агрегирует информацию о сбоях доступа непосредственно с устройств пользователей (например, браузеров). Это позволяет Google видеть проблемы доступности, которые могут быть не видны стандартному краулеру Googlebot.
2. Доступность сайта является фактором ранжирования и отображения в SERP: Патент прямо указывает, что данные о доступности передаются в Search Engine, который может использовать их для понижения ранжирования недоступных сайтов, а также для изменения отображения результатов (аннотации, ссылка на кэш).
3. Определение статуса основано на сравнении с порогом: Система не реагирует на единичные сбои. Статус сайта меняется на not fully operational только тогда, когда количество сбоев за период времени превышает определенный threshold number. Этот порог динамический и зависит от времени и истории сайта.
4. Географическая локализация проблем: Система способна различать глобальную недоступность сайта и региональные сетевые проблемы, анализируя источник ошибок (origin). Это позволяет более точно адаптировать SERP для разных регионов.
5. Активная верификация краулером: При обнаружении проблем на основе пользовательских данных, Google может инициировать внеочередное сканирование (web crawl) для подтверждения статуса. Это связывает данные RUM с данными Googlebot.
6. Информирование пользователей о причинах сбоя: Запатентован механизм обратной связи, позволяющий сообщить пользователю, столкнувшемуся с ошибкой, что проблема, вероятно, на стороне сайта, а не у него.

Практика

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

• Обеспечение максимального Uptime и надежности хостинга: Это критически важно. Поскольку Google отслеживает сбои на основе реальных пользовательских сессий, необходимо минимизировать любые простои, ошибки сервера (5xx) и проблемы с подключением.
• Использование глобально распределенных CDN: Использование CDN помогает снизить вероятность региональных проблем с доступностью и улучшить скорость соединения, что снижает вероятность отправки connection errors пользователями.
• Мониторинг доступности из разных регионов (RUM): Необходимо использовать собственные системы Real User Monitoring и синтетический мониторинг из разных географических точек, чтобы оперативно обнаруживать и устранять проблемы доступности, которые видит Google.
• Оптимизация скорости загрузки и таймаутов: Медленная работа сервера или слишком долгие ответы могут приводить к ошибкам подключения у пользователей (timeouts), которые будут зарегистрированы системой. Необходимо следить за временем ответа сервера (TTFB).
• Проверка корректности работы DNS: Ошибки DNS (DNS error) также отслеживаются системой. Необходимо обеспечить стабильную работу и быстрый ответ DNS-серверов.

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

• Использование дешевого и нестабильного хостинга: Экономия на хостинге приведет к частым сбоям доступа у пользователей, что будет зафиксировано Google и может негативно повлиять на ранжирование и отображение сайта в SERP.
• Игнорирование региональных проблем доступности: Блокировка доступа к сайту из определенных стран или проблемы с маршрутизацией в конкретных регионах будут интерпретированы системой как проблемы доступности (geographic accessibility information) и могут привести к потере трафика из этих регионов.
• Длительные технические работы без корректной обработки: Проведение работ, делающих сайт недоступным без отдачи кода 503 (Service Unavailable), приведет к всплеску ошибок у пользователей и изменению статуса на not fully operational.
• Частая смена IP-адресов без прогрева или нестабильная конфигурация DNS: Может привести к временной недоступности сайта для части пользователей из-за кэширования DNS, что увеличит количество отчетов об ошибках.

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

Этот патент подтверждает важность технической стабильности и пользовательского опыта (Page Experience) как факторов успеха в SEO. Google активно развивает методы сбора данных о реальном взаимодействии пользователей с сайтами (например, Core Web Vitals через CrUX) и использует эти данные для оценки качества ресурсов. Стратегия SEO должна включать надежную техническую инфраструктуру и постоянный мониторинг доступности сайта не только для поисковых роботов, но и для реальных пользователей по всему миру.

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

Сценарий: Влияние нестабильного хостинга на отображение в SERP

1. Ситуация: Интернет-магазин использует хостинг, который часто «падает» на 5-10 минут в часы пик из-за перегрузки.
2. Действие системы: В моменты простоя пользователи получают ошибки соединения. Их браузеры отправляют error messages в Google.
3. Анализ: System Engine фиксирует, что количество ошибок для hostname магазина превысило threshold number в этот период времени. Статус меняется на not fully operational. Система также может инициировать web crawl для проверки.
4. Интеграция с поиском: Search Engine получает обновленный статус.
5. Результат для SEO: В течение некоторого времени после инцидента (пока статус не обновится обратно на operational), поисковая система может: (а) Незначительно понизить сайт в ранжировании по сравнению с конкурентами со стабильным хостингом; (б) В результатах поиска ссылка на сайт может быть заменена ссылкой на кэшированную версию страницы.

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