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

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

Search related structured data (Структурированные данные, связанные с поиском)

Данные, относящиеся к документу, организованные в набор объектов с атрибутами. Упоминаемые форматы: PageMap, Microformats, RDFa, Microdata, meta tags.

Verified User / Authorized User (Верифицированный / Авторизованный пользователь)

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

Previously unscheduled update sequence (Ранее незапланированная последовательность обновлений)

Обновление индекса по требованию пользователя, происходящее вне стандартного графика сканирования (scheduled crawling). Обеспечивает быстрое обновление.

Web crawl data (Данные веб-сканирования)

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

Private URL access key (Приватный ключ доступа к URL)

Ключ, предоставляемый пользователем системе. Используется для доступа к специальной версии URL, содержащей структурированные данные, которые могут быть невидимы без ключа (Метод Pull).

Access Key (Ключ доступа - на уровне базы данных)

Метка, ассоциируемая со структурированными данными в базе данных. Доступ к этим данным возможен только при предъявлении соответствующего ключа (например, для Custom Search Engine).

Indexing quota (Квота на индексирование)

Ограничение на количество или частоту отправок структурированных данных для URL, домена или пользователя.

Structured Data Association Engine

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

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

Патент содержит два ключевых независимых пункта (Claim 1 и Claim 10), описывающих разные аспекты механизма.

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

1. Система получает пользовательский запрос на ассоциацию структурированных данных с URL.
2. Система получает эти данные от пользователя, причем данные принимаются без доступа к документу, на который указывает URL (т.е. без сканирования страницы).
3. Система ассоциирует эти данные с записью URL в поисковой базе данных.
4. Условие: по крайней мере часть данных дополняет (supplements) данные, полученные путем стандартного сканирования URL (web crawl data).

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

1. Система получает от пользователя инструкцию по обновлению (update instruction), идентифицирующую URL и предоставляющую доступ к данным.
2. Система получает данные аутентификации пользователя, подтверждающие его авторизацию.
3. На основании авторизации система модифицирует соответствующую запись в базе данных.
4. Условие: инструкция инициирует модификацию во время previously unscheduled update sequence (т.е. обновление по требованию).

Claim 6 и 13 (Зависимые): Уточняют возможность передачи приватных данных.

По крайней мере часть предоставленных пользователем структурированных данных недоступна (inaccessible) через стандартное сканирование URL.

Claim 16 и 17 (Зависимые от 10): Детализируют механизм извлечения (Pull).

URL может быть общедоступным URL, дополненным private access key. Данные, полученные через сканирование этого специального URL (с ключом), недоступны при сканировании общедоступного URL (без ключа).

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

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

CRAWLING – Сканирование и Сбор данных
Механизм позволяет обойти стандартное сканирование (при прямой загрузке - Push) или инициировать специализированное сканирование (при использовании private URL access key - Pull). Structured Data Association Engine выступает в роли приемника данных или специализированного краулера.

INDEXING – Индексирование и извлечение признаков
Основной этап применения. Structured Data Association Engine обрабатывает полученные данные и обновляет Content Database (поисковый индекс). На этом этапе происходит слияние: пользовательские данные могут дополнять (supplement) или заменять (supplant) существующие web crawl data. Также данным могут быть присвоены Access Keys для ограничения доступа.

RANKING / RERANKING – Ранжирование / Переранжирование
Поисковая система (Search Engine) использует эти обновленные структурированные данные для идентификации результатов, сортировки, фильтрации и формирования отображения результатов (например, Rich Snippets).

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

• Запрос на обновление (Update instruction).
• Идентификатор URL.
• Данные аутентификации пользователя.
• Структурированные данные (при методе Push) ИЛИ Private URL access key (при методе Pull).

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

• Обновленная запись URL в Content Database с актуальными структурированными данными.

На что влияет

• Конкретные ниши или тематики: Наибольшее влияние в E-commerce (цены, наличие), а также для сайтов с вакансиями (Jobs), событиями (Events) и рецептами. Влияет на ниши, где актуальность структурированных данных критична.
• Специфические типы данных: В патенте упоминаются атрибуты total number of reviews (общее количество отзывов) и total number of downloads (общее количество загрузок) как примеры данных, которые могут быть отправлены этим методом, даже если они отсутствуют на странице.
• Специализированный поиск: Влияет на Custom Search Engines (CSE), позволяя использовать приватные структурированные данные для улучшения поиска.

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

• Триггеры активации: Механизм активируется по явному запросу (user generated request или update instruction) от авторизованного пользователя.
• Временные рамки: Применяется по требованию (unscheduled update sequence). Ассоциация происходит в течение предопределенного периода времени (predefined time period); в патенте приведен пример «менее 6 часов».
• Условия и пороги: Применение ограничено квотами (indexing quota). Если квота превышена, запрос может быть отклонен или обработан с задержкой (например, первые запросы обрабатываются быстро, последующие медленнее).

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

Патент описывает два варианта реализации.

Вариант А: Прямая отправка данных (Push Model / Direct Submission)

1. Аутентификация и Запрос: Авторизованный пользователь инициирует запрос на ассоциацию структурированных данных с URL.
2. Передача данных: Пользователь отправляет структурированные данные (например, через HTTP POST) в Structured Data Association Engine. Система получает данные без сканирования целевого URL.
3. Проверка квот: Система проверяет соблюдение indexing quota.
4. Обработка и Ассоциация: Система обрабатывает данные и ассоциирует их с записью URL в Content Database в рамках unscheduled update sequence.
5. Слияние данных: Новые данные сливаются с существующими web crawl data (дополнение или замена).
6. (Опционально) Установка приватности: Если указан Access Key, данные помечаются для ограниченного доступа.

Вариант Б: Целевое извлечение (Pull Model / Private Key Crawl)

1. Аутентификация и Запрос: Авторизованный пользователь отправляет update instruction и предоставляет private URL access key.
2. Проверка квот: Система проверяет соблюдение indexing quota.
3. Специализированное сканирование: Structured Data Association Engine обращается к целевому URL, используя предоставленный ключ (например, как параметр запроса).
4. Получение данных: Сервер целевого URL, распознав ключ, отдает контент со структурированными данными (возможно, скрытыми от публичного доступа).
5. Извлечение и Ассоциация: Система извлекает данные и ассоциирует их с записью URL в Content Database в рамках unscheduled update sequence.
6. Слияние и Приватность: Данные сливаются с web crawl data и могут быть помечены Access Key.

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

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

Патент фокусируется на механизме передачи данных.

• Структурные факторы (Основной ввод): Система принимает search related structured data. Упоминаемые форматы: PageMap (основной пример в патенте), meta tags, Microformats, RDFa, Microdata. Примеры атрибутов: title, review, publication date.
• Пользовательские факторы (Аутентификация): Данные для верификации пользователя (user authentication data), например, токен аутентификации.
• Технические данные (Ключи доступа):
  • Private URL access key: Для доступа к специальной версии URL (Метод Pull).
  • Access Key: Для маркировки данных в индексе как приватных.

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

Патент не описывает метрики ранжирования, но упоминает операционные метрики:

• Indexing quota (Квота на индексирование): Предопределенное количество отправок за период времени. Система отслеживает использование квот для управления нагрузкой.
• Predefined time period (Предопределенный период времени): Гарантированное время обработки запроса (например, менее 6 часов).
• Уникальные атрибуты (Unique attribute type): Примеры данных, которые могут быть переданы этим методом и отсутствовать в web crawl data:
  • total number of reviews (общее количество отзывов).
  • total number of downloads (общее количество загрузок).

1. Индексирование по требованию (On-Demand Indexing): Google имеет инфраструктуру для приема структурированных данных напрямую от вебмастеров, позволяя обновлять индекс по требованию (unscheduled update sequence), минуя стандартное сканирование.
2. Приоритет скорости: Система спроектирована для быстрого обновления критически важных данных в течение предопределенного периода времени (например, часов, а не дней).
3. Поддержка приватных данных: Патент явно предусматривает индексацию структурированных данных, которые недоступны при публичном сканировании URL.
4. Два механизма передачи (Push и Pull): Данные могут быть загружены напрямую (Push) или извлечены системой с использованием private URL access key (Pull).
5. Контроль доступа в индексе: Индексированные данные могут быть защищены ключом (Access Key) на уровне базы данных, ограничивая их использование авторизованными системами (например, Custom Search Engines).
6. Авторизация и Квоты: Доступ к механизму имеют только авторизованные пользователи (verified user), и его использование ограничено квотами (indexing quota).
7. Слияние данных: Отправленные пользователем данные сливаются с web crawl data, при этом они могут как дополнять, так и заменять данные сканирования.

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

• Внедрение механизмов прямой отправки: Для контента, где актуальность структурированных данных критична (E-commerce, Jobs, Events), необходимо использовать доступные реализации этого патента: Google Merchant Center Feeds/Content API (для товаров) и Google Indexing API (для вакансий и трансляций). Это гарантирует быструю доставку актуальных данных в индекс.
• Автоматизация подачи данных: Настроить интеграцию CMS/PIM систем для автоматической отправки обновлений при изменении информации на сайте (например, изменение цены или статуса наличия).
• Поддержание точности данных: Поскольку отправленные данные могут заменять (supplant) данные сканирования, критически важно обеспечить их абсолютную точность перед отправкой.
• Мониторинг квот и ошибок: Отслеживать использование indexing quota и обрабатывать ответы API, чтобы гарантировать доставку данных и своевременно реагировать на проблемы с лимитами или аутентификацией.
• Использование приватных атрибутов для CSE (если применимо): Если используется Google Custom Search Engine, применять механизм отправки приватных структурированных данных (с Access Key) для добавления атрибутов, полезных для внутренней фильтрации (например, внутренняя классификация, рейтинг поставщика), которые не должны быть видны публично.

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

• Полагаться только на стандартный краулинг: Игнорировать возможности прямой отправки для time-sensitive информации. Это приводит к неактуальной информации в SERP (неверные цены, недоступные товары) и потере трафика.
• Отправка противоречивых данных: Отправлять через API данные, которые противоречат публичному контенту на странице. Хотя система технически позволяет это (Claim 1), это может подорвать доверие поисковой системы.
• Игнорирование стандартной разметки на сайте: Отказываться от размещения Schema.org на веб-страницах, полагаясь исключительно на прямую отправку. Прямая отправка предназначена для дополнения и быстрого обновления, а не полной замены.
• Спам обновлениями: Злоупотреблять механизмом для незначительных изменений, что может привести к исчерпанию indexing quota.

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

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

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

Сценарий 1: Быстрое обновление наличия товара (E-commerce)

1. Ситуация: На сайте интернет-магазина закончился товар. Стандартный краулер может не увидеть это изменение несколько дней.
2. Действие (на основе патента - Push): Авторизованная система магазина генерирует обновленные структурированные данные (статус наличия) и отправляет их напрямую в Google (на практике – через Merchant Center Feed или Content API).
3. Результат: Запись URL в индексе обновляется в течение короткого времени (unscheduled update sequence). Информация в Google Shopping и расширенных сниппетах актуализируется, предотвращая негативный опыт пользователей.

Сценарий 2: Индексация приватных данных для корпоративного поиска (CSE)

1. Ситуация: Компания использует Google CSE для поиска по каталогу. Необходимо добавить фильтр по атрибуту «Маржинальность», который не должен быть виден публично.
2. Действие (на основе патента - Push с Access Key): Компания настраивает отправку структурированных данных. Атрибут «Маржинальность» отправляется с указанием Access Key.
3. Результат: Атрибут индексируется, но доступ к нему ограничен. Корпоративная поисковая система (CSE), настроенная на использование этого Access Key, может применять фильтр по маржинальности. Публичный поиск Google не имеет доступа к этому атрибуту.