Я вынес итоги в самое начало, если кому интересно могут читать всю простыню. Спасибо чатгпт 5 за некоторую помощь.)

Что делать SEO специалистам?

Описание патента

Техническая суть изобретения

• Какая задача решается
  • Проблема “неправильного распределения” поведенческих сигналов (user behavior data) в результатах поиска. Пользователь часто кликает по документу-агрегатору (вторичный источник), а затем переходит по его ссылке (anchor) к документу-первичному источнику. Если учитывать только клик и/или dwell time на агрегаторе, поведенческая ценность приписывается вторичному источнику, а не первичному. Патент предлагает механизм “заимствования/размазывания” (smearing/sharing/borrowing) поведенческих данных через релевантные анкоры от страницы-источника к странице-цели.
• Основные компоненты системы (см. Fig. 2–4)
  • Indexing engine 2020/3010: индексирование документов, в т.ч. извлечение анкоров (якорей) и связанной информации.
  • Scoring engine 3020: вычисляет IR-оценки на основе контентных и независимых от запроса факторов.
  • Ranking engine 2052/3030/4070: ранжирует документы по запросу (использует IR-оценки и дополнительный сигнал).
  • Rank modifier engine 2056/3070 (query results rank modifier 1010): модифицирует ранжирование, предоставляя “quality of result statistic” (QoR) по документам для конкретного запроса; реализует “smearing” через релевантные анкоры.
  • Results anchor analyzing component 3080: выявляет релевантные анкоры в документах из SERP.
  • Tracking component 3050 (клиент/сервер): собирает поведенческие логи (клики, dwell time и др.) в result selection logs 3060.
  • User behavior data repository 1018: хранилище поведенческих данных.
• Входные/выходные данные
  • Вход: запрос, список результатов, информация об анкорах результатов (ссылка, анкор-текст, околотекст, метаданные, медиаконтент/мультияковость), поведенческие логи (клики, длительность просмотра, прочие взаимодействия), доп. служебные атрибуты (язык, страна, домены, времена изменений/появления анкора и др.).
  • Выход: для отдельных документов — “quality of result statistic” по запросу, скорректированная с учётом “смазанных” поведенческих данных; далее — передача QoR в Ranking engine для доранжирования списка.
• Ключевые технические особенности
  • “Smearing” поведенческих данных от “первого документа” (показан в SERP и содержит анкор на “второй документ”) к “второму документу” при выполнении условий релевантности анкора запросу (Fig. 5–6).
  • QoR может базироваться на:
    • первом измерении предыдущих пользовательских выборов первого документа (клики/долгие клики и пр.) при показах по тому же запросу;
    • втором измерении предыдущих пользовательских выборов второго документа по тому же (или похожему) запросу;
    • опционально — данных об использовании конкретного анкора (anchor-level behavior).
  • Опционально источник может быть “урезан” (reduction): уменьшение поведенческой метрики у первого документа пропорционально переданному объёму (claims 9, 15, 20).
  • Условия релевантности анкора задаются как набор опциональных правил (Fig. 6B, 6054–6064), включая присутствие второго документа в SERP по тому же или похожему запросу, наличие достаточных поведенческих данных у обоих, междоменные ссылки, релевантность анкор-текста запросу, наличие anchor-level данных.
  • Анкоры могут быть в тексте, видео, изображениях (Fig. 1C), в т.ч. с метаданными (alt, caption, внутренние метки и т.п.).

---

2. Область применения и ограничения

2.1 На что направлен патент

• Типы контента
  • Веб-документы с анкорами: HTML-страницы, а также мультимедийные носители, поддерживающие “кликабельные” анкоры в видео/изображениях (Fig. 1C).
  • Вторичные источники (например, списки/каталоги/обзоры/блоги/новости/соцленты) и первичные источники (страницы-источники информации).
• Типы запросов
  • Общие поисковые запросы; примеры в описании: коммерческие/транзакционные и travel (“Hotel New York”), но архитектура не ограничена этими типами. Приводится идея негативного контента (для некоторых типов запросов, таких как продукт/путешествия) при оценке релевантности анкора (Fig. 1D).
• Форматы контента
  • Текстовые страницы, страницы с медиаконтентом (видео/изображения) с кликабельными анкорами.
• Ниши/тематики
  • Не ограничено тематикой; механизм общий для web search.
• Языки/география
  • Логи могут включать язык (L) и страну (C); механизм учитывает локальные атрибуты в данных. Ограничений по языкам/регионам не указано.

2.2 Условия применения

• Триггеры/необходимые условия (см. Fig. 5–6)
  • Наличие в SERP документов, содержащих анкоры на другие документы из того же (или похожего) запроса.
  • “Достаточное” количество поведенческих данных у первого и/или второго документов (пороговые значения не фиксированы в тексте).
  • Выполнение одного или нескольких условий релевантности анкора (опциональные проверки 6054–6064):
    • Второй документ также фигурирует в SERP по текущему запросу (6054) или по “похожему” запросу (6056).
    • У второго документа есть поведенческие данные по этому запросу/похожему запросу (6058).
    • Междоменная ссылка (6060).
    • Релевантность текста анкора и/или ближайшего контента запросу; учет синонимов/стемминга; возможный фильтр boilerplate; потенциальный фильтр негативной тональности (6062; также Fig. 1D).
    • Доступность anchor-level поведенческих данных (6064).
  • Во времени: могут учитываться тренды (изменение поведенческих данных до/после появления анкора) и свежесть обновлений документов, но периодичность/частота применения не нормирована.
• Частота применения
  • Не указана; схема применяется в процессе формирования ответа на запрос с использованием исторических данных.
• Исключения/особые случаи
  • Отбор условий — опционален. Любая комбинация правил 6054–6064 может применяться, вплоть до одного условия.

2.3 Что не покрывается

• Патент НЕ описывает:
  • Метрики качества контента как такового, E-E-A-T, PageRank или антиспам-алгоритмы (хотя упоминается проверка междоменности как признак “не самомотивации”).
  • Локальные/карточные/карты-результаты/изображения/видео-ранжирование как отдельные вертикали (речь о web search, хотя мультимедийные анкоры учитываются).
  • Конкретные численные пороги/веса/константы.
  • Вебмастерские сигналы типа nofollow (не упомянуты).
  • Частоту/расписание перерасчетов и системные SLA.

---

3. Как работает алгоритм (пошагово)

Процесс (сводно по Fig. 5, 6A–6B, 7A–7B)

1. Получение запроса и результатов поиска (Fig. 5: 5002).
2. Сбор информации об анкорах для каждого результата (5004).
3. Итерация по документам из SERP (5006):
   • Проверка: есть ли у выбранного документа достаточные поведенческие данные по запросу (5008).
   • Если да — выполнение процедуры “smearing” по его анкорам (5010 → Fig. 6A):
     • Перебор анкора (6002) и проверка условий релевантности (6004 → Fig. 6B: 6054–6064).
     • При выполнении условий — комбинация поведенческих данных первого и второго документов (6006; Fig. 7A/7B).
     • Переход к следующему анкору (6008).
4. После обработки результатов — вычисление/обновление QoR для документов с “смазанными” данными (5014).
5. Передача QoR в ранжирующий движок для доранжирования SERP (5016).

Комбинация/обновление данных (Fig. 7A–7B)

• Вариант A (агрегация, Fig. 7A):
  • Получить поведенческие данные для первого и второго документов (7002).
  • Агрегировать для получения скорректированного значения второго документа (7004).
• Вариант B (процентное смешивание, Fig. 7B):
  • Получить поведенческие данные (7052).
  • Определить “степень релевантности” анкора запросу (7054).
  • Комбинировать процент поведенческих данных первого документа с данными второго (7056).
  • Опционально — уменьшить данные первого документа на использованный процент (claims 9, 15, 20; текст: “can be decreased”).

Условия/пороги

• “Threshold amount” поведенческих данных — присутствует, численные значения не указаны.
• “Degree of relevance” анкора — определяется контентным совпадением/метаданными и др., конкретная формула не задана.

Временные аспекты

• Используются исторические логи (клики, dwell). Возможна оценка трендов (пример: совпадение появления анкора и изменения метрик). Частота перерасчетов в патенте не указана.

---

4. Что собирается/анализируется (детально)

4.1 Входные данные (сигналы/факторы)

• Контентные:
  • Анкор-текст; окружающий текст (предложение/абзац); метаданные для изображения/видео (например, alt/описание), указывающие на релевантность (“изображение отеля в Нью-Йорке”).
  • Терминологическое совпадение с запросом; допускается синонимия и стемминг.
  • Признаки boilerplate/фиксированных ссылок (менее релевантны).
  • Негативная тональность контента рядом с анкором — сигнал нерелевантности (примеры: “horrible/terrible”, Fig. 1D).
• Технические:
  • URL-структура анкора (href), домены первого/второго документов (междоменные vs внутридоменные).
  • Временная метка появления анкора; свежесть обновлений документа.
• Ссылочные:
  • Собственно факт существования анкора (в тексте/видео/изображении), указывающего со страницы-источника на страницу-цель.
  • Anchor-level поведенческие данные (если доступны): сколько раз выбирали конкретный анкор со страницы-источника при этом запросе (claims 7).
• Поведенческие:
  • Клики по результатам, “долгие/короткие” клики (dwell time). Примеры: long/short click; возможна категория medium.
  • Не-клик (показы без клика), позиции кликов, сессионные параметры (предыдущие и последующие действия), return-to-SERP момент.
  • IR-оценки показанных результатов, заголовки и сниппеты, показанные пользователю до клика.
  • Технические данные клиента: cookie, cookie age, IP, user agent (перечислены как варианты логирования).
  • Отдельно упомянуты: eye-tracking как возможный сигнал; purchase decision data (просмотры/покупки товаров) — как иной тип поведенческих данных.
• Временные:
  • Исторические записи <document, query, data>; тренды изменения кликов/долгих кликов до/после добавления анкора.
• Структурные:
  • Наличие анкоров в мультимедиа (интерактивное видео, image-map и т.п.).
• Гео/язык:
  • Язык L и страна C в логах.

Важно: Патент перечисляет эти данные как потенциально доступные/логируемые. Фактическое использование конкретных видов данных в расчёте QoR/смазке зависит от выбранной реализации (опционально).

4.2 Метрики и вычисления

• Quality of result statistic (QoR)
  • Определяется на основе поведенческих данных по паре (документ, запрос).
  • Пример: взвешенное среднее числа “долгих” кликов (описательно; без формулы и коэффициентов).
  • При “smearing” QoR второго документа основывается на:
    • первом измерении прошлых выборов первого документа (когда он показывался по тому же запросу);
    • втором измерении прошлых выборов второго документа (когда он показывался по тому же запросу);
    • опционально — “третьих данных” на уровне анкора (сколько раз выбирали ссылку внутри первого документа).
• Степень релевантности анкора запросу
  • Может учитывать: точное/частичное совпадение терминов (edit distance, синонимы, стемминг), релевантность околотекста/метаданных, негативную тональность, boilerplate.
  • Используется для определения процента смазывания (Fig. 7B: “combine a percentage”).
• Пороговые значения
  • “Threshold amount” поведенческих данных — без чисел.
• Весовые коэффициенты
  • Не зафиксированы; указано, что может быть процент от данных первого документа, зависящий от степени релевантности анкора.
• Нормализация/агрегация
  • Агрегация данных первого и второго документов (Fig. 7A/7B).
  • Опциональное уменьшение поведенческих данных первого документа на использованный процент (claims 9/15/20).

4.3 Способы обработки

• Текстовый анализ (NLP):
  • Матчинг запроса и анкор-текста/околотекста/метаданных; учет синонимов и стемминга; анализ негативной лексики.
  • Выявление boilerplate / sitewide ссылок.
• Статистика/эвристики:
  • Подсчёт кликов, категорий dwell-time; анализ трендов до/после появления анкора; оценка свежести обновлений.
• Классификация/кластеризация:
  • Определение “похожих” запросов (по сходству терминов, перекрытию множеств результатов или наборов документов с поведенческими данными).
• Машинное обучение:
  • В тексте не утверждается явное применение ML в смазывании; система допускает любое “подходящее” определение релевантности/сходства, но конкретные ML-модели не описаны.

---

5. Уровень архитектуры

• Нижний уровень (сбор сигналов):
  • Tracking component 3050/клиентский логгер, сбор кликов/dwell/позиций/не-кликов; извлечение анкора и контекстов при индексировании.
• Средний уровень (преобразование в оценки):
  • Rank modifier engine/Results anchor analyzing component: определение релевантности анкора, вычисление процента передачи, агрегация поведенческих данных, расчет QoR.
• Верхний уровень (финальные решения):
  • Ranking engine интегрирует IR-оценки и QoR (дополнительный сигнал) для окончательного порядка выдачи по запросу.

---

6. Практические выводы для SEO

Важная оговорка: патент описывает возможный внутренний процесс. Нет гарантии, что именно так реализовано в продакшене. Ниже — только выводы, которые непосредственно вытекают из описанной механики. Без натяжек.

6.1 Прямые выводы (если механизм используется)

• Цель — перераспределить поведенческие сигналы от “вторичных” страниц к “первичным”, на которые они ссылаются релевантными анкорами по конкретному запросу.
• Что можно делать:
  • Добиваться ссылок-анкоров с релевантных страниц, которые уже попадают в SERP по тем же (или похожим) запросам:
    • Анкор-текст и ближайший контент должны совпадать с формулировкой запроса или быть семантически близкими (учтите синонимы/стемминг).
    • Избегать boilerplate/шаблонных ссылок — такие анкоры менее релевантны.
    • По возможности — междоменные ссылки (off-domain) имеют больший вес как признак “не самомотивации”.
    • Для изображений/видео — обеспечить ассоциированные метаданные, явно указывающие на релевантность (alt/описание кадра и т.п.).
  • Если доступно влияние на анкор-уровневую кликабельность (на уровне источника): повышать вероятность выбора нужного анкора пользователями (в патенте указано, что при наличии таких данных они могут использоваться для определения доли передачи).
  • Для вторичных страниц (агрегатор/список): осознавать риск “перетока” части поведенческого сигнала к целевым страницам. Если ваша задача — ранжироваться как первичный источник, обеспечьте, чтобы на вас ссылались такие агрегаторы с релевантными анкорами.
  • Для запросов, где негативная тональность не релевантна (примеры в тексте — продукты/путешествия): избегать негативного контента вокруг анкора на целевую страницу — такие анкоры могут быть признаны нерелевантными и не передавать сигнал.
• Что НЕ следует ожидать:
  • Это не “передача PageRank”: описывается перераспределение поведенческих метрик в QoR, а не ссылочного веса.
  • Нет гарантий увеличения ранга без выполнения условий релевантности и порогов по поведенческим данным.

Конкретные практики, соответствующие механике

• Для страницы-”первичного источника” по запросу X:
  • Получите упоминания в списках/обзорах, которые уже ранжируются по X или похожим запросам.
  • Следите за формулировкой анкора/околотекста: используйте терминологию запроса, но без переоптимизации/шаблонности.
  • Стремитесь к внешним (off-domain) ссылкам от авторитетных вторичных источников.
  • В мультимедийных обзорах (видео/галереи) — просите добавить кликабельные ссылки и явные метаданные, описывающие релевантность вашему запросу.
• Для владельцев агрегаторов/списков:
  • Понимайте, что часть поведенческого сигнала может быть “справедливо” перераспределена к первоисточникам при релевантных ссылках. Чтобы сохранять собственную позицию, добавляйте уникальную ценность, а не только список ссылок (это за пределами патента, но логически следует из цели перераспределения поведенческого сигнала).

Ожидаемый результат

• При выполнении всех условий: повышение QoR целевой страницы по запросу, что может привести к её повышению в итоговом ранжировании для этого запроса (Fig. 1A, шаг 1030).

6.2 Косвенные выводы

• Приоритет Google (в терминах патента): отдавать сигнал релевантности “первичным” источникам, когда поведение пользователя указывает, что именно они удовлетворяют интент, даже если первый клик был по “вторичному” агрегатору.
• Значимость анкор-контекста:
  • Речь не только о тексте ссылки, но и о ближайшем контенте, метаданных, типе носителя (текст/изображение/видео), а также полярности текста.
• “Похожие запросы”:
  • Передача может срабатывать и между близкими запросами — важно покрывать кластеры формулировок (синонимы, варианты запроса), если это соответствует интенту.

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

• Сценарий 1 (из описания): запрос “Hotel New York”.
  • Страница A (список отелей Нью‑Йорка) часто кликается и имеет высокий dwell; она ссылается анкором “New York hotel …” на страницу C (конкретного отеля). Алгоритм, при соблюдении условий, может “смазать” поведенческие данные A к C, подняв QoR C и улучшив его позицию над страницей B, у которой таких связей/сигналов нет (Fig. 1A, таблицы 1020–1032).
• Сценарий 2 (негативная тональность):
  • Если анкор окружен выраженно негативным текстом (“этот отель ужасен”), такой анкор может считаться нерелевантным данному интенту (в ряде типов запросов), и передача сигнала не произойдет (Fig. 1D).
• Сценарий 3 (междоменные ссылки):
  • Если A и C имеют разные домены, это рассматривается как дополнительный критерий для смазывания (6060).

Если патент чисто технический (важно)

• Патент действительно описывает внутреннюю процедуру перераспределения поведенческих сигналов и их использования как входа в процесс ранжирования. Он не дает “прямых” вебмастерских инструкций. Практическая ценность для SEO — понимание того, какие свойства анкор-ссылок и поведенческих данных могут влиять на перераспределение QoR.

---

Критерии качества (проверка соответствия)

• Техническая точность: использованы только факты из патента — определения QoR, условия Fig. 6B, механизмы Fig. 5–7, типы данных из разделов про tracking/logs и иллюстраций Fig. 1B–1D.
• Практическая ценность: рекомендации привязаны к механизмам патента — релевантность анкора/контекста/метаданных, междоменные упоминания, покрытие похожих запросов, работа с агрегаторами.
• Профессиональный уровень: описана многоуровневая архитектура и конкретные операционные шаги/сигналы без домыслов.