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

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

Authorship Identification Engine (Механизм идентификации авторства)

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

Content Data (Данные контента)

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

Content Submission Form (Форма отправки контента)

Веб-форма на странице (например, редактор CMS, поле комментария, интерфейс вики), позволяющая пользователю отправить контент для публикации.

Content Token (Токен контента)

Уникальный идентификатор контента (например, хэш или случайное число), который может быть внедрен в отправляемый контент и использован позже для верификации вместо сравнения полного текста.

Destination Address (Адрес назначения)

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

Form Submission Handler (Обработчик отправки формы)

Скрипт (например, JavaScript, часто внедряемый через плагин браузера), который перехватывает событие отправки формы для сбора и передачи данных верификации.

Publication Address (Адрес публикации)

URL, по которому будет доступен опубликованный контент после его обработки сервером.

User Identification Data (Идентификационные данные пользователя)

Данные, идентифицирующие автора в момент отправки контента (например, ID пользователя в сервисе, логин, cookie, IP-адрес).

Verification Address (Адрес верификации)

URL сервера (например, принадлежащего Google), на который Form Submission Handler отправляет данные для подтверждения авторства. Он отличается от Destination Address.

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

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

1. Система идентифицирует Content Submission Form на веб-странице, предназначенную для отправки контента на Destination Address для последующей публикации на Publication Address.
2. Идентифицируются Publication Address Data (где контент появится) и User Identification Data пользователя.
3. Form Submission Handler распознает отправку контента пользователем.
4. В ответ на отправку система передает данные верификации (Publication Address Data, User Identification Data и Content Data) на Verification Address (отличный от адреса публикации).
5. При этом Form Submission Handler (тот же или второй) также обеспечивает отправку контента на Publication Address (т.е. нормальная публикация не блокируется).

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

Claim 2 (Зависимый от 1): Уточняет реализацию.

Form Submission Handler может быть инициализирован через плагин браузера (browser plug-in). Это указывает, что система требует установки агента на стороне клиента или интеграции в сам браузер.

Claim 5 (Зависимый от 1): Добавляет временной аспект.

Система также может передавать временную метку (time stamp data), указывающую время отправки контента. Это важно для разрешения споров об авторстве.

Claim 6 (Зависимый от 1): Описывает следующий этап.

Система верифицирует пользователя как автора контента на основе полученных данных.

Claim 10, 11, 12 (Зависимые): Описывают использование токенов как альтернативу передаче полного контента.

1. Content Data могут включать Content Token (Claim 10).
2. Система внедряет этот Content Token в контент, отправляемый на Publication Address (Claim 11).
3. Верификация авторства происходит путем проверки наличия этого Content Token в опубликованном контенте (Claim 12).

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

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

Действия пользователя (Вне стандартных фаз поиска)
Основной механизм активируется на клиентском устройстве пользователя в момент создания контента. Form Submission Handler перехватывает данные и отправляет их в Google.

CRAWLING – Сканирование и Сбор данных
Механизм использует краулер для проверки публикации. После получения данных верификации система планирует сканирование указанного Publication Address. Патент упоминает, что сканирование может быть инициировано в ответ на передачу данных для верификации авторства.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сравнение Content Data (присланных из браузера) с контентом, полученным краулером. В случае успеха система сохраняет в индексе ассоциацию между документом и верифицированным автором.

RANKING – Ранжирование
Сгенерированный сигнал (верифицированное авторство) используется на этом этапе. Патент прямо указывает, что идентификация авторства может использоваться для влияния на релевантность и ranking score документа (например, повышать ранг, если автор является экспертом).

Входные данные (для агента в браузере):

• Событие отправки веб-формы.
• Контент, введенный пользователем.
• User Identification Data (из сессии браузера/логина).

Выходные данные (от агента к Google):

• Пакет верификационных данных (User ID, Content Data/Token, Publication Address, Time Stamp).

На что влияет

• Типы контента: Наибольшее влияние оказывается на контент, создаваемый через веб-интерфейсы: статьи в CMS, посты в блогах, комментарии на форумах, правки в вики-системах.
• Конкретные ниши: Критически важно для YMYL-тематик (здоровье, финансы), где идентификация экспертности автора имеет первостепенное значение для оценки достоверности контента.

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

• Условия работы алгоритма: Алгоритм требует наличия активного агента (плагина, расширения) в браузере пользователя или интеграции этой функциональности в сам браузер (например, Chrome).
• Триггеры активации: Активируется в момент, когда пользователь отправляет контент через распознанную Content Submission Form на веб-странице.

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

Процесс разделен на две фазы: клиентскую (в момент публикации) и серверную (верификация).

Фаза 1: Клиентская сторона (Браузер пользователя)

1. Идентификация формы: Агент (плагин) анализирует веб-страницу на наличие Content Submission Form (например, ищет теги <form>, <textarea>, ключевые слова типа "Post", "Edit").
2. Идентификация адреса публикации: Определяется Publication Address Data – где контент будет опубликован (на основе текущего URL, адреса назначения формы или URL перенаправления после отправки).
3. Идентификация пользователя: Определяются User Identification Data (например, на основе логина в связанный сервис).
4. Установка обработчика: Агент устанавливает Form Submission Handler (например, обработчик onsubmit()) на форму.
5. Перехват отправки: При попытке пользователя отправить форму обработчик активируется.
6. Сбор данных контента: Фиксируется отправляемый контент. Опционально генерируется и внедряется Content Token.
7. Передача данных верификации: Обработчик отправляет пакет данных на Verification Address (сервер Google). Это может происходить через AJAX, iframe или img tag.
8. Публикация контента: Обработчик (или стандартный механизм браузера) отправляет контент на Destination Address для публикации на сайте.

Фаза 2: Серверная сторона (Google)

1. Прием данных: Authorship Identification Engine получает пакет верификационных данных.
2. Планирование сканирования: Система планирует сканирование Publication Address (это может быть немедленное сканирование по запросу или добавление в очередь).
3. Сканирование: Краулер загружает контент по указанному адресу.
4. Сравнение: Система сравнивает опубликованный контент с Content Data. Сравнение может быть точным, по порогу схожести (например, с использованием расстояния Левенштейна) или путем поиска внедренного Content Token.
5. Разрешение конфликтов: Анализируется Time Stamp, чтобы убедиться, что контент не был скопирован из ранее существовавшего источника.
6. Ассоциация: При успешном сравнении система ассоциирует автора (User ID) с опубликованным контентом (или его частью) и сохраняет эту связь в индексе.

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

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

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

• Контентные факторы: Основные данные – это сам отправляемый контент (текст, код, файлы), фиксируемый как Content Data.
• Технические факторы: Используются URL-адреса: Publication Address (где искать контент) и Destination Address (куда он отправляется формой). Анализируется HTML-код для идентификации форм.
• Пользовательские факторы: Критически важные данные – User Identification Data. Патент упоминает использование логина в сервисе (социальная сеть, почта, сервис верификации авторства), а также возможность использования IP-адреса, MAC-адреса или cookies для идентификации автора.
• Временные факторы: Time Stamp (время отправки контента) используется для разрешения споров об авторстве и определения первичности контента.

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

• Сравнение контента (Content Matching): Система сравнивает Content Data (присланные из браузера) и опубликованный контент (полученный краулером). Патент упоминает несколько методов:
  • Точное совпадение (Exact Match).
  • Порог схожести (Similarity Threshold): Используются метрики схожести, такие как расстояние Левенштейна (Levenshtein edit distance), расстояние Яро-Винклера (Jaro-Winkle), индекс Жаккара (Jaccard index).
  • Проверка токена (Content Token Verification): Поиск точного совпадения уникального токена (хэша или случайного числа), внедренного в контент. Токен может быть внедрен в отображаемые или скрытые данные (метаданные, image tags).
• Анализ времени (Time Stamp Analysis): Сравнение времени отправки контента с временем публикации другого похожего контента для определения первоисточника.

1. Приоритет верифицированного авторства: Патент демонстрирует стремление Google создать надежный механизм идентификации авторов, который не зависит от декларативных заявлений владельцев сайтов (например, разметки Schema или подписей).
2. Фокус на моменте создания контента: Ключевая идея – зафиксировать авторство непосредственно в момент отправки контента с устройства автора, что является сильным доказательством подлинности.
3. Зависимость от клиентских технологий: Реализация описанного механизма требует наличия агента на стороне клиента. Патент прямо указывает на использование плагинов браузера (browser plug-ins) или интеграции в браузер для перехвата событий отправки форм (Form Submission Handler).
4. Инфраструктурный характер: Это патент на инфраструктуру сбора данных и генерации сигналов, а не на алгоритм ранжирования. Он описывает, как получить сигнал "Верифицированный Автор", который затем используется другими системами (например, для оценки E-E-A-T).
5. Авторство как фактор ранжирования: Патент явно подтверждает, что верифицированное авторство и свойства автора (например, его экспертиза) предназначены для использования в качестве сигналов ранжирования и могут влиять на ranking score документа.
6. Ограниченность применения: Эффективность системы зависит от степени ее внедрения (установка плагинов пользователями). Отсутствие широкого принятия, вероятно, стало причиной отказа от этого конкретного механизма в пользу пассивного анализа сущностей.

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

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

• Построение авторитетности авторов (E-E-A-T): Продолжайте фокусироваться на развитии авторов как признанных сущностей (Entities). Патент подтверждает, что надежная связь между контентом и автором критически важна для Google. Необходимо использовать все доступные пассивные сигналы: четкие подписи, биографии, разметку Schema.org/Person, связи с профилями в Knowledge Graph.
• Консистентность представления автора: Убедитесь, что информация об авторе консистентна как на вашем сайте, так и на внешних авторитетных площадках. Это помогает системам Google (даже без механизма из патента) надежно ассоциировать контент с сущностью автора.
• Обеспечение чистоты контента при публикации: Убедитесь, что системы публикации (CMS) не вносят значительных изменений в контент автора при публикации (например, не вырезают код или разметку), так как это теоретически может помешать сравнению текста или обнаружению Content Token, если бы подобная система использовалась.

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

• Ложное присвоение авторства: Попытки приписать контент авторитетным авторам, которые его не создавали. Описанный механизм направлен на борьбу с такими манипуляциями путем верификации в момент создания.
• Анонимный контент в YMYL: Публикация контента на чувствительные темы без указания авторства и квалификации автора. Google стремится идентифицировать авторов для оценки качества такого контента.
• Присвоение авторства (Плагиат): Попытки заявить авторство контента, написанного другими. Описанный механизм использует Time Stamp Data для определения реального момента создания контента и борьбы с такими манипуляциями.

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

Патент подтверждает долгосрочную стратегию Google по переходу от анализа ключевых слов и ссылок к анализу сущностей и их авторитетности (E-E-A-T). Он показывает, насколько важна для Google задача точной идентификации авторов. Также он иллюстрирует готовность Google использовать данные, собираемые через свои продукты (браузеры, плагины), для улучшения качества поиска. Для SEO это означает, что построение реальной авторитетности и узнаваемости авторов является фундаментальной частью долгосрочной стратегии.

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

Поскольку механизм работает на стороне клиента (в браузере автора), SEO-специалист не может напрямую инициировать его работу.

Сценарий: Верификация авторства экспертной статьи (Гипотетическое применение патента)

1. Ситуация: Эксперт пишет статью для своего блога на WordPress.
2. Действие (Гипотетическое): Эксперт использует браузер (например, Chrome) с активированной функцией верификации авторства (или установленным плагином, описанным в патенте) и залогинен в свой аккаунт Google.
3. Публикация: Эксперт вставляет текст в CMS и нажимает "Опубликовать".
4. Перехват: Form Submission Handler перехватывает отправку, фиксирует текст, User ID эксперта и URL будущей статьи. Эти данные отправляются в Google (Verification Address).
5. Верификация: Google сканирует блог, находит статью и подтверждает совпадение текста с перехваченными данными.
6. Результат: Google надежно связывает эту статью с сущностью эксперта, усиливая его E-E-A-T и потенциально улучшая ранжирование статьи.