Как Google агрегирует социальные сигналы (лайки, +1) с канонических URL и верифицированных социальных профилей на авторитетную страницу

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

Authority Page (Авторитетная страница)

Веб-страница на внешнем сайте (например, официальная домашняя страница компании), которая определяется как основной ресурс для сущности. Она может иметь канонические URL и быть связана с профилем в социальной сети.

Endorsement (Одобрение)

Действие пользователя в отношении веб-документа (страницы сайта или профиля в соцсети), указывающее на интерес или одобрение. Примеры включают лайки, +1, шейры, комментарии, отзывы. Эти действия могут быть видны контактам пользователя.

Primary Count (Первичный счетчик)

Количество одобрений, полученных непосредственно на конкретном URL (веб-странице или социальном профиле).

Secondary Count / Total Sum (Вторичный счетчик / Общая сумма)

Агрегированный счетчик одобрений. Представляет собой сумму первичных счетчиков (Primary Counts) всех связанных страниц в группе (Авторитетная страница + её канонические URL + верифицированная Социальная страница). Именно этот показатель обычно отображается пользователям.

Social Networking Page/Profile (Страница/профиль в социальной сети)

Страница или профиль в социальной сети, представляющий ту же сущность, что и Authority Page.

Two-way relationship (Двухсторонняя связь)

Механизм верификации связи между Social Networking Page и Authority Page. Требует наличия взаимных ссылок: социальный профиль должен указывать на авторитетную страницу, а авторитетная страница должна подтверждать связь с социальным профилем.

URL Normalization / Canonicalization (Нормализация / Канонизация URL)

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

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

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

1. Система получает индикацию одобрения (endorsement) на первой веб-странице, которая является профилем или страницей в социальной сети.
2. Система определяет, связана ли эта первая веб-страница с авторитетной/канонической страницей (Authority Page / Canonical Webpage) вне социальной сети.
3. Ключевое условие: связь определяется только тогда, когда существует двухсторонняя связь (two-way relationship) между ними.
4. Авторитетная страница имеет несколько адресов (канонических URL), которые резолвятся в один базовый канонический адрес.
5. Если связь подтверждена, система определяет количество одобрений для каждого из связанных адресов.
6. В ответ на получение индикации одобрения (и при наличии двухсторонней связи), система инкрементирует:
   • Первичный счетчик (first endorsement count) первой веб-страницы.
   • Общую сумму (second endorsement count / total sum), которая основана на сумме счетчиков первой веб-страницы и всех связанных канонических адресов авторитетной страницы.
7. Система предоставляет первичный счетчик и общую сумму для отображения вместе на первой веб-странице (социальном профиле).

Claim 14 (Независимый пункт - Система): Описывает систему, реализующую метод.

1. Система получает запрос на ассоциацию первой веб-страницы (в социальной сети) с авторитетной страницей (вне социальной сети).
2. Авторитетная страница имеет первый адрес и один или несколько вторых адресов, которые находятся в канонических отношениях (резолвятся в один базовый адрес).
3. Система определяет, существует ли двухсторонняя связь (two-way relationship).
4. Если двухсторонняя связь существует:
   • Определяется первый счетчик одобрений первой веб-страницы и счетчики для всех адресов авторитетной страницы.
   • Генерируется общий итог одобрений (endorsement total) как сумма всех этих счетчиков.
   • Эта сумма предоставляется для отображения вместе с первым счетчиком на первой веб-странице и на авторитетной странице.

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

Изобретение затрагивает этапы индексирования и отображения данных, но не описывает прямое применение в ранжировании.

CRAWLING – Сканирование и Сбор данных
На этом этапе система должна обнаружить и отслеживать ссылки между веб-страницами и социальными профилями для верификации two-way relationship. Также краулеры должны обнаруживать индикаторы одобрений на страницах.

INDEXING – Индексирование и извлечение признаков
Основной этап применения патента:

• Каноникализация: Система должна определить канонические отношения между разными URL (URL Normalization).
• Верификация связей: Система проверяет и сохраняет статус two-way relationship между Authority Page и Social Networking Page.
• Учет одобрений: Система индексирует и хранит Primary Counts для каждого URL.
• Агрегация: Система вычисляет и хранит Secondary Counts для групп связанных страниц. Это может происходить как в момент индексации, так и в реальном времени при получении нового одобрения.

RANKING – Ранжирование
Патент не указывает, что агрегированные счетчики (Secondary Counts) используются как фактор ранжирования. Он фокусируется на подсчете и отображении.

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

• Индикация нового одобрения (Endorsement) на конкретном URL.
• Данные о канонических связях между URL.
• Данные о ссылках между Authority Page и Social Networking Page (для верификации).
• Существующие Primary Counts.

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

• Обновленные Primary Counts для конкретного URL.
• Обновленные Secondary Counts для всей группы связанных страниц.
• Данные для отображения счетчика на страницах.

На что влияет

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

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

• Триггеры активации (Агрегация Web+Social): Агрегация счетчиков между сайтом и социальной сетью происходит ТОЛЬКО при наличии верифицированной двухсторонней связи (two-way relationship).
• Триггеры активации (Агрегация Канонических URL): Происходит всегда, когда система идентифицирует канонические отношения между URL.
• Временные рамки: Применяется в двух случаях: 1) В момент получения нового одобрения (для обновления счетчиков). 2) В момент загрузки страницы пользователем (для отображения актуального Secondary Count).

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

Процесс А: Установление связи между Социальной страницей и Авторитетной страницей

1. Получение запроса: Система получает запрос на ассоциацию Social Networking Page с Authority Page.
2. Верификация связи: Система проверяет наличие two-way relationship (взаимные ссылки).
   • Если НЕТ: Процесс завершается, агрегация не производится.
   • Если ДА: Перейти к шагу 3.
3. Определение первичного счетчика Социальной страницы: Система определяет текущий Primary Count для Social Networking Page.
4. Определение счетчика Авторитетной страницы: Система определяет счетчик одобрений для Authority Page. Этот счетчик может уже включать сумму Primary Counts самой страницы и всех её канонических URL.
5. Расчет Вторичного счетчика: Система вычисляет Secondary Count как сумму счетчика Социальной страницы и счетчика Авторитетной страницы.
6. Присвоение и отображение: Secondary Count присваивается всем страницам в группе (Социальная страница, Авторитетная страница и её канонические URL) и предоставляется для отображения.

Процесс Б: Обработка нового одобрения

1. Получение индикации: Система получает сигнал об одобрении на Первой странице (может быть сайтом или соцсетью).
2. Обновление Первичного счетчика: Система инкрементирует Primary Count Первой страницы.
3. Проверка ассоциаций: Система определяет, связана ли Первая страница с другими страницами (канонические URL или верифицированная связь Web/Social).
   • Если НЕТ: Отобразить Primary Count. Процесс завершен.
   • Если ДА: Перейти к шагу 4.
4. Идентификация связанных страниц: Система идентифицирует все страницы в группе.
5. Обновление Вторичного счетчика: Система инкрементирует общий Secondary Count для всей группы.
6. Отображение: Обновленный Secondary Count предоставляется для отображения на всех страницах группы.

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

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

• Поведенческие / Социальные факторы: Основные данные — это индикации одобрений (endorsements), такие как клики по кнопкам социального взаимодействия (лайки, +1, шейры).
• Технические факторы: URL страниц. Данные, используемые для нормализации и канонизации URL (например, теги rel="canonical", редиректы, структура URL).
• Структурные / Ссылочные факторы: Наличие ссылок между Social Networking Page и Authority Page. Эти ссылки критически важны для верификации two-way relationship.

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

• Primary Count: Вычисляется путем подсчета прямых одобрений на конкретном URL.
• Secondary Count: Вычисляется как сумма Primary Counts всех страниц, входящих в верифицированную группу. $Secondary Count = Primary(SocialPage) + Primary(AuthorityPage) + \sum Primary(CanonicalURLs)$
• Verification Status: Булево значение (True/False), определяющее наличие two-way relationship.

1. Консолидация сигналов как цель: Google стремится агрегировать сигналы вовлеченности (endorsements), чтобы получить единое представление о популярности контента, независимо от того, где произошло взаимодействие (на сайте, на его дубликате или в социальной сети).
2. Критичность каноникализации: Правильная техническая реализация канонизации является фундаментом для этого механизма. Одобрения, полученные на неканонических URL, автоматически переносятся на авторитетную страницу.
3. Верификация обязательна для кросс-платформенной агрегации: Сигналы с внешнего сайта и из социальной сети объединяются ТОЛЬКО при условии подтвержденной двухсторонней связи (two-way relationship). Это предотвращает несанкционированное присвоение чужих социальных сигналов.
4. Фокус на измерении, а не на ранжировании: Патент описывает точный учет и отображение социальных сигналов (Secondary Count). Он не содержит информации о том, как эти агрегированные данные используются в алгоритмах ранжирования.
5. Поддержка целостности данных: Использование Primary Counts позволяет системе корректно пересчитать Secondary Counts, если ассоциации между страницами изменяются (например, если компания меняет свой официальный профиль в социальной сети).

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

• Обеспечение идеальной каноникализации: Необходимо убедиться, что все дубликаты страниц (например, версии с www и без, с параметрами отслеживания, HTTP/HTTPS) корректно указывают на единый канонический URL с помощью rel="canonical", редиректов и настроек в Search Console. Это гарантирует, что все социальные сигналы, полученные на дубликатах, будут агрегированы на основной странице.
• Верификация связи между сайтом и социальными профилями: Необходимо реализовать two-way relationship. Основные социальные профили должны содержать ссылку на официальный сайт (Authority Page), а сайт должен ссылаться на эти профили. Хотя патент просто упоминает "ссылки", на практике это реализуется через микроразметку (Schema.org/Organization с атрибутом sameAs) и инструменты верификации конкретных социальных платформ.
• Консолидация социальных виджетов: При размещении кнопок социального одобрения (Like, Share) на сайте убедитесь, что они ссылаются на канонический URL страницы, а не на текущий адрес в браузере (если он может содержать параметры).

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

• Игнорирование проблем каноникализации: Наличие доступных для индексации дубликатов страниц приводит к фрагментации социальных сигналов. Система может не распознать связь между ними, и общий Secondary Count будет ниже реального.
• Отсутствие связи между сайтом и соцсетями: Если сайт не ссылается на свои официальные социальные профили (и наоборот), система не сможет верифицировать two-way relationship. В результате одобрения, полученные на сайте, и одобрения, полученные в социальной сети, не будут объединены.
• Использование разных URL в социальных кампаниях: Распространение неканонических URL (например, с избыточными UTM-метками) в социальных сетях может привести к тому, что одобрения будут "прилипать" к этим временным URL, а не к основному контенту, если каноникализация настроена некорректно.

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

Патент подтверждает важность концепции "Entity Cohesion" (Целостность Сущности) в глазах Google. Система стремится понять, что веб-сайт и различные социальные профили представляют одну и ту же организацию или человека. Техническая реализация этой связи (каноникализация и двухсторонние ссылки) позволяет системе корректно агрегировать данные. Хотя прямое влияние на ранжирование не описано, точное измерение вовлеченности и демонстрация сильного социального доказательства важны для пользовательского опыта и конверсии.

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

Сценарий: Агрегация сигналов интернет-магазина

1. Существующие страницы:
   • https://example.com/product1 (Authority Page)
   • http://www.example.com/product1?ref=fb (Canonical URL)
   • Страница компании в Facebook (Social Networking Page)
2. Действия SEO-специалиста:
   • Настроить 301 редирект и rel="canonical" с Canonical URL на Authority Page.
   • Разместить ссылку на страницу Facebook на сайте example.com (например, в футере и через Schema.org sameAs).
   • Разместить ссылку на example.com в профиле Facebook.
3. Результат работы системы:
   • Google верифицирует канонизацию и two-way relationship.
   • Пользователь лайкает товар по ссылке http://www.example.com/product1?ref=fb. Система инкрементирует Primary Count этого URL и общий Secondary Count группы.
   • Другой пользователь лайкает страницу в Facebook. Система инкрементирует Primary Count страницы Facebook и общий Secondary Count группы.
   • При заходе на https://example.com/product1 отображается Secondary Count, включающий лайки со всех трех источников.