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

Описание

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

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

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

Запатентована система (chain-store data extractor) для автоматического извлечения структурированных данных о филиалах. Система способна идентифицировать страницу поиска филиалов (store-locator webpage), систематически запрашивать ее, используя различные географические идентификаторы, и извлекать информацию. Ключевым элементом является способность обнаруживать repeating patterns (повторяющиеся шаблоны) в объектной модели документа (DOM) после полного рендеринга страницы.

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

Система работает в несколько этапов:

• Идентификация целей: Определяются сайты крупных сетей (на основе трафика/impressions и количества известных филиалов).
• Обнаружение локатора: Система сканирует сайт, ищет страницы с формами и ключевыми словами, затем «прощупывает» (probing) их географическими запросами, чтобы найти настоящий store locator.
• Систематический запрос: Идентифицированный локатор автоматически запрашивается с использованием списка географических зон (например, всех почтовых индексов страны).
• Рендеринг и Анализ DOM: Система полностью рендерит полученные страницы (включая выполнение JavaScript) и анализирует финальный DOM.
• Извлечение данных: Обнаруживаются repeating patterns, указывающие на список филиалов. Структурированные данные (адрес, телефон, часы работы) извлекаются из этих шаблонов.
• Хранение: Данные сохраняются в репозитории бизнес-листингов (business listing repository).

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

Высокая. Актуальные и точные локальные данные критически важны для Google Maps, Local Pack и локального поиска в целом. Описанные методы — анализ DOM, выполнение JavaScript для рендеринга контента, извлечение данных на основе структурных шаблонов — являются стандартными практиками в современных системах сбора данных, особенно при работе с динамическими сайтами.

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

Патент имеет значительное влияние (8/10) на Local SEO для мультилокационных бизнесов. Он не описывает алгоритмы ранжирования, но раскрывает механизм, с помощью которого Google получает «истинные данные» (ground truth) о физических местоположениях напрямую с сайта компании. Это подчеркивает критическую важность технической реализации раздела «Найти магазин» (Store Locator): он должен быть машиночитаемым и содержать консистентную структуру HTML для успешного извлечения данных.

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

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

Business listing repository (Репозиторий бизнес-листингов)

База данных, содержащая структурированные записи о локальных бизнесах (адреса, часы работы, телефоны и т.д.). Основа для Google Maps и Локального Поиска.

Chain-store data extractor (Извлекатель данных сетевых магазинов)

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

Document Object Model (DOM) (Объектная модель документа)

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

Impressions / Click-through data (Показы / Данные о кликах)

Данные поисковой системы о трафике на сайты. Используются для идентификации и приоритизации популярных сайтов сетевых магазинов.

Repeating pattern (Повторяющийся шаблон)

Ключевое понятие. Последовательность схожих по структуре поддеревьев в DOM, которая обычно соответствует списку однотипных объектов (в данном случае — списку филиалов).

Store-listing webpage (Страница со списком магазинов)

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

Store-locator webpage (Страница поиска магазина / Локатор)

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

Store-location probe (Зонд локации магазина)

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

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

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

1. Идентификация страницы поиска магазина (store-locator webpage).
2. Отправка запроса к этой странице для поиска магазинов в географической области.
3. Обнаружение повторяющегося шаблона (repeating pattern) в DOM ответной страницы.
4. Извлечение информации о локациях из этого шаблона.
5. Сохранение информации в business listing repository.

Claim 5 и 6 (Зависимые): Детализируют процесс идентификации сайтов для анализа.

Система приоритизирует сайты, отбирая те, которые превышают порог популярности (impressions), и подтверждая, что они являются сетевыми, проверяя количество уже известных филиалов в business listing repository.

Claim 7, 9, 10 (Зависимые): Описывают оптимизированный процесс поиска страницы локатора.

• Claim 7: Кандидаты на роль локатора определяются на основе ключевых слов в контенте/URL и данных о кликах пользователей.
• Claim 9: Система удаляет дубликаты страниц с идентичными веб-формами (сравнивая поля action), чтобы минимизировать количество запросов.
• Claim 10: Оставшиеся кандидаты проверяются (probing) путем отправки форм и анализа ответа на наличие списка магазинов.

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

Система может запрашивать мобильные версии страниц, устанавливая мобильный user-agent, даже если запрос исходит не от мобильного устройства. Мобильные версии часто имеют более простую структуру DOM, которую легче анализировать.

Claim 14 и 15 (Зависимые): Подчеркивают важность рендеринга и механизм анализа DOM.

• Claim 14: Система выполняет полный рендеринг страницы, включая выполнение скриптов (JavaScript/AJAX), и дожидается стабилизации DOM перед анализом.
• Claim 15: Repeating pattern обнаруживается путем сегментации DOM на поддеревья и сравнения их структуры на предмет совпадения элементов.

Claim 16 и 17 (Зависимые): Описывают глубокое извлечение и индексацию.

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

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

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

CRAWLING – Сканирование и Сбор данных (Crawling & Data Acquisition)
Это основная область применения. Описан не стандартный краулинг по ссылкам, а целенаправленный механизм сбора данных (chain-store data extractor). Он включает активное взаимодействие с веб-формами для доступа к контенту, недоступному при обычном сканировании (Deep Web). Система также выполняет полный рендеринг страниц.

INDEXING – Индексирование и извлечение признаков (Indexing & Feature Extraction)
На этом этапе происходит обработка собранных данных. Компонент store-entry extraction module анализирует DOM, идентифицирует repeating patterns и извлекает структурированные признаки (адрес, телефон, часы работы). Эти данные сохраняются в business listing repository (инфраструктура локального индекса, например, база Google Maps). Также патент упоминает добавление обнаруженных URL-адресов конкретных филиалов в основной поисковый индекс.

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

• Список URL сайтов сетевых компаний (приоритезированный по impressions).
• Список географических идентификаторов (почтовые индексы, города).
• HTML, CSS, JavaScript целевых страниц.

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

• Структурированные данные (NAP+H: Name, Address, Phone, Hours) для каждого филиала.
• Обновленные записи в business listing repository.
• Новые URL страниц филиалов для индексации.

На что влияет

• Конкретные типы контента и ниши: Влияет исключительно на Локальный Поиск (Local SEO) и данные Google Maps. Затрагивает все сетевые бизнесы с множеством физических локаций (ритейл, рестораны, банки и т.д.).
• Точность данных: Система направлена на повышение точности и актуальности данных о локациях в экосистеме Google, используя сайт бренда как источник истины.

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

• Условия применения: Алгоритм применяется к сайтам, идентифицированным как принадлежащие популярным (порог impressions) сетевым компаниям (порог количества известных локаций).
• Частота применения: Применяется периодически для обновления Business listing repository, отслеживания открытия/закрытия филиалов или изменения часов работы.

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

Процесс разделен на фазы: идентификация целей, поиск и верификация локатора, извлечение данных.

Фаза 1: Идентификация и приоритизация целей

1. Отбор сайтов по трафику: Идентификация популярных сайтов на основе impressions и click-through data из поисковой системы.
2. Фильтрация сетевых компаний: Проверка отобранных сайтов по Business listing repository. Если сайт ассоциирован с количеством филиалов выше порога, он передается на дальнейшую обработку.

Фаза 2: Поиск и верификация локатора

1. Сканирование сайта: Краулер обходит сайт для сбора страниц-кандидатов. Может использоваться режим мобильного user-agent.
2. Анализ (Store Listing Check): Проверка, является ли какая-либо страница статическим списком всех филиалов (store-listing webpage) путем поиска repeating patterns в DOM. Если найдена, переход к Фазе 3.
3. Анализ (Store Locator Candidates): Если список не найден, система ищет страницы с веб-формами и релевантными ключевыми словами («найти магазин», «адрес») в тексте или URL.
4. Дедупликация: Удаление дубликатов страниц с идентичными формами (по совпадению поля action) для минимизации нагрузки.
5. Зондирование (Probing): Автоматическая отправка формы на странице-кандидате с широким географическим запросом (например, вся страна).
6. Верификация ответа: Рендеринг ответной страницы и анализ DOM. Если repeating pattern найден, страница помечается как store-locator webpage.

Фаза 3: Извлечение данных

1. Итеративный запрос данных: Система циклически отправляет запросы к верифицированному локатору, перебирая список географических идентификаторов (например, все почтовые индексы), чтобы получить полный список филиалов.
2. Рендеринг и анализ DOM: Для каждой ответной страницы выполняется полный рендеринг (включая скрипты) до стабилизации DOM. Обнаруживаются repeating patterns путем сравнения структур поддеревьев.
3. Извлечение атрибутов: Внутри каждого цикла шаблона система извлекает структурированные данные, используя регулярные выражения или анализ структуры/классов элементов DOM.
4. Глубокое извлечение: Если в шаблоне найдена ссылка на индивидуальную страницу филиала, система переходит по ней для извлечения дополнительной информации и добавляет этот URL в индекс.
5. Обновление репозитория: Извлеченные данные сравниваются с Business listing repository. Записи обновляются, добавляются или помечаются для удаления.

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

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

• Технические факторы: Основные данные для анализа — HTML, CSS и JavaScript. Система анализирует структуру DOM, веб-формы (поля ввода, атрибут action), атрибуты элементов и CSS-классы. Используются HTTP-заголовки для манипуляции user-agent.
• Контентные факторы: Текст на странице и в URL. Используются ключевые слова для идентификации страниц локаторов и регулярные выражения для извлечения данных (адресов, телефонов).
• Поведенческие факторы (Системные данные): Агрегированные данные о трафике (Impressions и Click-through data) используются для приоритизации сайтов.
• Географические факторы: Списки географических идентификаторов (почтовые индексы, города) используются для систематического запроса store locator.

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

• Пороги популярности и сетевого статуса: Минимальное количество impressions и минимальное число известных локаций для включения сайта в анализ.
• Метрики схожести DOM (DOM Similarity): Используются для обнаружения repeating pattern. Система проверяет, имеет ли узел DOM несколько дочерних узлов (например, более пяти) с одинаковой или очень похожей структурой (одинаковое количество дочерних элементов, типы элементов, классы).
• Регулярные выражения (Regular Expressions): Используются для идентификации и извлечения специфических форматов данных из текста внутри DOM (телефоны, индексы, адреса).

Выводы

1. Google активно извлекает данные из «Глубокой сети» (Deep Web): Система специально разработана для доступа к информации, скрытой за веб-формами (Store Locators), путем программного взаимодействия с ними, имитируя действия пользователя.
2. Сайт бренда как источник истины (Ground Truth): Google стремится получать данные о локациях напрямую с официального сайта компании для обновления своего business listing repository, верифицируя или дополняя данные из Google Business Profile.
3. Критичность рендеринга JavaScript: Патент подтверждает (Claim 14), что система выполняет полный рендеринг страниц, включая JS/AJAX, и ждет стабилизации DOM перед анализом. Это необходимо для работы с динамическими сайтами.
4. Структура DOM и шаблонное извлечение: Основной механизм извлечения — это обнаружение repeating patterns в DOM. Консистентность HTML-структуры списка филиалов критически важна для успешного парсинга.
5. Использование мобильных версий для анализа: Google может предпочитать анализировать мобильные версии сайтов (Claim 8), так как они часто имеют более простую и чистую структуру DOM, что упрощает извлечение данных.
6. Индексация страниц филиалов: Система может обнаруживать и добавлять в индекс URL-адреса конкретных филиалов, даже если они доступны только через поиск в локаторе и на них нет прямых ссылок.

Практика

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

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

• Обеспечьте консистентную и семантическую структуру HTML в локаторе: Убедитесь, что каждый филиал в результатах поиска локатора представлен в DOM с использованием строго одинаковой структуры и классов HTML-элементов. Это критически важно для надежной идентификации repeating pattern.
• Используйте чистый код и микроразметку: Применяйте понятные названия классов (например, store-address). Внедрение микроразметки (Schema.org/LocalBusiness) является лучшей практикой, предоставляя альтернативный, более надежный способ получения структурированных данных.
• Обеспечьте быстрый и корректный рендеринг JavaScript: Если локатор использует JS/AJAX, убедитесь, что он рендерится быстро и корректно для автоматизированных браузеров. Система должна иметь возможность дождаться финального состояния DOM (Claim 14).
• Оптимизируйте мобильную версию локатора: Убедитесь, что мобильная версия функциональна, содержит полные данные и имеет чистую структуру. Google может использовать ее для парсинга (Claim 8).
• Создавайте индивидуальные страницы филиалов: Рекомендуется иметь уникальный URL для каждого филиала. Патент указывает, что система может переходить по этим ссылкам для извлечения дополнительных данных и индексировать эти URL.
• Поддерживайте точность данных на сайте: Регулярно проверяйте актуальность адресов, телефонов и часов работы. Эта система будет использовать эти данные для обновления информации в Google.

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

• Использование неконсистентной структуры HTML: Разная верстка для разных магазинов в одном списке (например, разный порядок элементов, разные классы) затруднит обнаружение repeating pattern и извлечение данных.
• Представление данных в виде изображений: Адреса и телефоны должны быть представлены в виде текста. Данные в нетекстовых форматах не будут извлечены.
• Медленная загрузка и выполнение AJAX-запросов: Если динамические элементы загружаются слишком долго, система может не дождаться финального состояния DOM и извлечь неполные данные.
• Блокировка автоматизированного доступа: Агрессивная блокировка ботов или слишком строгий rate limiting на странице локатора может помешать Google систематически обновлять информацию о ваших локациях.
• Сложные и нестандартные интерфейсы локатора: Использование многошаговых форм или сложных интерактивных карт без текстового списка результатов может затруднить автоматическое взаимодействие.

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

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

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

Сценарий: Оптимизация Store Locator для надежного извлечения данных (Repeating Pattern)

Задача: Убедиться, что система Google может корректно извлечь данные о филиалах из результатов поиска локатора.

Анализ: Система ищет консистентный repeating pattern в DOM.

Хороший пример реализации (Консистентный HTML):

<div class="store-results-list">
  <!-- Repeating Pattern Start -->
  <div class="store-entry">
    <h3>Store Name 1</h3>
    <p class="address">123 Main St, New York, NY 10001</p>
    <p class="phone">212-555-0101</p>
    <a href="/stores/store1">View Details</a>
  </div>
  <!-- Repeating Pattern End -->

  <!-- Repeating Pattern Start -->
  <div class="store-entry">
    <h3>Store Name 2</h3>
    <p class="address">456 Broadway, New York, NY 10001</p>
    <p class="phone">212-555-0102</p>
    <a href="/stores/store2">View Details</a>
  </div>
  <!-- Repeating Pattern End -->
</div>

Ожидаемый результат: Система легко идентифицирует <div class=»store-entry»> как repeating pattern, так как структура блоков идентична. Она извлекает данные из классов address и phone, и переходит по ссылкам для глубокого анализа.

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