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

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

Boilerplate Content (Шаблонный контент)

Неосновной, повторяющийся контент на страницах сайта (например, меню, хедеры, футеры, навигационные панели, реклама). Удаляется перед сравнением контента для верификации пар URL.

Mobile URL (Мобильный URL)

URL, ведущий на версию страницы, оптимизированную для мобильных устройств (например, начинающийся с m.).

Non-mobile URL (Немобильный URL) / Desktop URL

URL, ведущий на стандартную десктопную версию страницы (например, начинающийся с www.).

Placeholders (Плейсхолдеры)

Абстрактные переменные (например, const_1), используемые для представления совпадающих строк (токенов) при анализе паттернов трансформации URL.

Regular Expression (Regex, Регулярное выражение)

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

Selective URL Tokens (Селективные токены URL)

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

Shingling (Шинглирование)

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

URL Tokens (Токены URL)

Сегменты URL, полученные путем его парсинга по стандартным разделителям (например, “/”, “&”, “?”, “#”).

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

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

1. Система идентифицирует первую пару URL (мобильный и немобильный), соответствующих одной и той же веб-странице.
2. Определяются совпадающие символьные строки (matching character strings) между двумя URL, которые содержат общую подстроку определенной минимальной длины.
3. Для каждой совпадающей строки определяется паттерн (pattern), специфицирующий эту строку.
4. На основе этих паттернов определяется правило (rule) для генерации мобильного URL из входного немобильного URL.
5. Это правило применяется ко второму немобильному URL для генерации второго мобильного URL.
6. Система верифицирует (verifying), что веб-страница, связанная со сгенерированным вторым мобильным URL, соответствует веб-странице второго немобильного URL.

Claim 2 (Зависимый от 1): Уточняет метод определения совпадающих строк. Он включает разделение URL на токены на основе разделителей URL и сравнение этих токенов.

Claim 3 (Зависимый от 1): Уточняет, что паттерны (patterns) представлены в виде регулярных выражений (regular expressions).

Claim 4 (Зависимый от 1): Уточняет метод верификации. Он включает сравнение контента веб-страниц, связанных с немобильным и сгенерированным мобильным URL.

Claim 5 (Зависимый от 1): Описывает применение изобретения в индексации. Второй немобильный URL берется из индекса поисковой службы, и после генерации и верификации соответствующий мобильный URL добавляется в индекс.

Claim 6 и 7 (Зависимые от 1): Описывают применение в ранжировании. Генерация мобильного URL происходит в ответ на поисковый запрос. Сгенерированный мобильный URL включается в набор результатов поиска и может быть приоритизирован (повышен) при отображении.

Claim 8 (Зависимый от 1): Описывает применение на стороне клиента (мобильного устройства). Система перехватывает запрос на десктопную страницу, генерирует мобильный URL с помощью правила и отправляет запрос уже на мобильную версию.

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

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

CRAWLING – Сканирование и Сбор данных

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

INDEXING – Индексирование и извлечение признаков

• Анализ и Верификация пар: Основная часть алгоритма (анализ URL Tokens, сравнение контента методом shingling) выполняется на этапе индексации для установления соответствия между страницами.
• Генерация правил: Генерация Regular Expressions для трансформации URL происходит офлайн на основе проиндексированных данных.
• Каноникализация и Консолидация сигналов: Установление подтвержденных пар позволяет Google корректно консолидировать сигналы ранжирования (например, ссылки) между мобильной и десктопной версиями и выбрать канонический URL.

RANKING / RERANKING – Ранжирование и Переранжирование

• Выбор версии для показа: Как указано в Claims 6 и 7, система может использовать правила в реальном времени для определения мобильного URL и его приоритизации (бустинга) в выдаче для мобильных пользователей.

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

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

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

• Подтвержденные пары мобильных и десктопных URL.
• Набор правил (Regular Expressions) для трансформации URL в рамках домена.
• Дополнительные мобильные URL, добавленные в индекс.

На что влияет

• Конфигурации сайтов: Влияет исключительно на сайты, использующие раздельные URL для мобильной и десктопной версий (m-dot конфигурации). Не влияет на сайты с адаптивным дизайном (Responsive Design) или динамическим показом (Dynamic Serving), использующие единый URL.
• Технические аспекты: Влияет на процессы краулинга, индексации, каноникализации и консолидации сигналов для затронутых сайтов.

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

• Условия работы алгоритма: Применяется, когда система обрабатывает домен, содержащий как мобильные, так и немобильные URL. Идентификация типа URL может происходить по паттернам (например, замена "www" на "m", добавление пути "/m", параметра ?mobile=1) или через анализ контента (например, наличие тега viewport).
• Частота применения: Обнаружение пар и генерация правил происходят периодически в процессе индексации. Применение правил для краулинга или ранжирования происходит постоянно.

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

Алгоритм состоит из двух основных процессов: А) Обнаружение соответствующих пар URL и Б) Генерация правил трансформации.

Процесс А: Обнаружение пар URL (Finding Pairs)

1. Идентификация типа URL: Определение, является ли данный URL мобильным или десктопным (на основе паттернов URL или анализа контента/рендеринга).
2. Извлечение токенов URL: Парсинг мобильных и десктопных URL на токены с использованием стандартных разделителей.
3. Определение селективности токенов: Идентификация Selective URL Tokens — токенов, которые не встречаются слишком часто в домене и являются значимыми для идентификации конкретной страницы. Удаление неселективных токенов.
4. Поиск кандидатов: Для данного десктопного URL определяется набор потенциальных мобильных URL, которые имеют достаточное количество общих селективных токенов.
5. Сравнение контента (Верификация):
   1. Удаление Boilerplate Content (шаблонных элементов) из обеих страниц.
   2. Применение техники Shingling или статистического анализа вероятности совпадения токенов для оценки схожести основного контента.
6. Выбор лучшей пары: Мобильный URL, чей контент наиболее близок к контенту десктопного URL (и превышает порог схожести), назначается соответствующей парой.

Процесс Б: Генерация правил трансформации (Rule Generation)

1. Выборка подтвержденных пар: Система использует набор пар URL, найденных в Процессе А.
2. Идентификация совпадающих строк: Внутри каждой пары определяются строки (токены), которые присутствуют в обоих URL.
3. Введение плейсхолдеров: Совпадающие строки заменяются абстрактными плейсхолдерами (например, const_1). Например, www.site.com/news/123 и m.site.com/mobile/123 преобразуются в www.const_1/news/const_2 и m.const_1/mobile/const_2.
4. Группировка по характеристикам: Пары URL, имеющие одинаковую структуру плейсхолдеров (т.е. одинаковый паттерн трансформации), группируются вместе.
5. Генерация регулярных выражений: Для каждого плейсхолдера в группе определяется Regular Expression, который описывает все возможные значения этого плейсхолдера (например, const_2 может соответствовать \d{3} — любым трем цифрам).
6. Формирование правила: Определяется финальное правило маппинга для группы, использующее сгенерированные Regular Expressions. Например: Если десктопный URL соответствует паттерну X, то мобильный URL соответствует паттерну Y.

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

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

Система использует следующие типы данных:

• Технические факторы:
  • Структура URL: Абсолютные URL мобильных и десктопных страниц.
  • Разделители URL: Символы “/”, “&”, “?”, “#”, используемые для парсинга URL на токены.
  • HTML теги: Специфические теги (например, viewport) могут использоваться для идентификации мобильных страниц.
• Контентные факторы:
  • Полный контент страницы: Текст страниц используется для верификации соответствия пар.
  • Контентные токены: Слова или группы слов (шинглы), извлеченные из контента для анализа схожести.

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

• Частота токенов URL (URL Token Frequency): Подсчет количества появлений каждого токена URL в пределах домена. Используется для определения Selective URL Tokens (токены с низкой частотой).
• Количество общих токенов (Shared Tokens Count): Метрика для выбора кандидатов в пары. Может требовать определенного процента совпадения или наличия хотя бы одного общего селективного токена.
• Оценка схожести контента (Content Similarity Score):
  • Shingle Overlap: Процент общих шинглов (последовательностей слов) между двумя страницами после удаления boilerplate.
  • Статистическая вероятность: Оценка вероятности случайного совпадения контентных токенов в двух документах. Низкая вероятность случайного совпадения указывает на высокую схожесть.
• Пороги схожести: Минимальный уровень схожести контента (например, 51% Shingle Overlap), необходимый для подтверждения пары URL.

1. Автоматизация обработки мобильных конфигураций: Google разработал сложные автоматизированные методы для обработки сайтов с раздельными URL, позволяющие системе самостоятельно находить соответствия даже при отсутствии явных сигналов от вебмастера (rel=alternate/canonical). Это функционирует как система подстраховки.
2. Двухфакторная верификация пар: Система не полагается только на структуру URL. Ключевым этапом является верификация через анализ контента (shingling, удаление boilerplate). Это означает, что паритет основного контента между мобильной и десктопной версиями критически важен.
3. Важность селективных токенов: Для первичного поиска кандидатов система фокусируется на значимых (selective) частях URL, игнорируя общие элементы. Это подчеркивает важность наличия уникальных идентификаторов или ключевых слов в URL.
4. Генерализация правил через Regex: Использование Regular Expressions позволяет масштабировать найденные паттерны на весь сайт. Это означает, что консистентность структуры URL значительно облегчает работу системы.
5. Цели применения — Индексация и Ранжирование: Основные цели изобретения — улучшение обнаружения и индексации мобильного контента (Crawl Discovery) и обеспечение показа корректной версии URL пользователю в результатах поиска (Serving).

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

Рекомендации актуальны для сайтов, использующих конфигурацию с раздельными URL (Separate URLs / m-dot).

• Обеспечение полного паритета основного контента: Убедитесь, что основной контент (текст, изображения, ключевые данные) на мобильной и десктопной версиях идентичен. Поскольку система использует shingling для верификации пар, расхождения в основном контенте могут помешать корректному сопоставлению.
• Использование консистентной структуры URL: Придерживайтесь четких и последовательных правил формирования URL для мобильной и десктопной версий. Чем проще и консистентнее паттерн трансформации, тем легче системе сгенерировать корректные Regular Expressions и применить их ко всему сайту.
• Включение значимых идентификаторов в URL: Убедитесь, что URL содержат Selective URL Tokens (например, ID продукта, уникальные слаги). Это помогает системе на этапе первичного поиска кандидатов для сопоставления.
• Внедрение явных сигналов (Приоритет): Хотя Google может определить пары автоматически, лучшей практикой остается явное указание связей с помощью rel=alternate на десктопной странице и rel=canonical на мобильной. Это устраняет неоднозначность и снижает зависимость от автоматических алгоритмов.
• Мониторинг мобильных страниц в индексе: Используйте Google Search Console для мониторинга статуса индексации мобильных страниц. Если мобильные страницы неправильно каноникализируются, проверьте паритет контента и консистентность URL.

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

• Значительные различия в основном контенте (Content Discrepancy): Предоставление урезанного контента на мобильной версии. Это может быть воспринято как разный контент при анализе методом shingling, что приведет к тому, что страницы не будут связаны.
• Неконсистентные или сложные правила URL: Использование разных паттернов URL для разных разделов сайта (например, в блоге один способ формирования мобильных URL, а в каталоге — другой). Это затрудняет генерацию универсальных правил трансформации.
• Использование неинформативных URL: Формирование URL только из неселективных токенов (например, /category/page1, /category/page2), что затрудняет первичное сопоставление на основе структуры URL.
• Блокировка ресурсов на мобильной версии: Блокировка CSS/JS или основного контента, которая мешает Google корректно проанализировать страницу для сравнения контента или определить ее как мобильную.

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

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

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

Сценарий 1: Оптимизация структуры URL интернет-магазина (m-dot)

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

Плохая реализация:

• Десктоп: www.shop.com/catalog/shoes/nike-air-max-id12345.html
• Мобильная: m.shop.com/product.php?id=12345

Анализ: Трансформация сложная. Общий Selective URL Token только один (12345). Система может связать эти страницы, но генерация общего правила для всего сайта будет затруднена из-за сильного изменения структуры пути и имен файлов.

Оптимизированная реализация:

• Десктоп: www.shop.com/p/nike-air-max/12345/
• Мобильная: m.shop.com/p/nike-air-max/12345/

Анализ: Идеальная консистентность. Паттерн трансформации прост: замена "www" на "m". Система легко сгенерирует правило: www.(.*) -> m.$1. Это гарантирует быстрое и точное сопоставление всех страниц.

Сценарий 2: Проверка паритета контента новостного сайта

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

Проблема: На мобильной версии отображается только первые три абзаца статьи, а остальное скрыто под кнопкой "Читать далее" и не доступно в исходном коде при загрузке.

Анализ: Когда система применяет shingling для сравнения десктопной (полной) и мобильной (урезанной) версий, оценка схожести контента может оказаться ниже порогового значения. Страницы не будут признаны парой.

Решение: Обеспечить доступность всего основного текста статьи в исходном коде мобильной страницы при первой загрузке. Это позволит алгоритму shingling подтвердить идентичность контента.