Как Google автоматически определяет язык, страну и тип устройства по структуре URL и переранжирует выдачу под пользователя

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

Address Attribute (Атрибут Адреса)

Часть URL (Resource Locator), которая варьируется в соответствии с идентифицированным шаблоном. Например, в шаблоне <AA1>.example.com, Address Attribute — это поддомен (например, 'fr', 'de', 'm').

Alignment Score (Оценка Соответствия)

Метрика, вычисляемая во время обработки запроса. Отражает степень соответствия между атрибутами пользователя (User Attributes) и предполагаемыми атрибутами ресурса (на основе вычисленных Likelihoods).

Attribute Processing Engine (Механизм Обработки Атрибутов)

Компонент системы, который анализирует контент страниц, определяет их Resource Attributes и вычисляет Likelihoods путем сравнения с Address Attributes.

Likelihood (Вероятность)

Оценка вероятности того, что определенный Address Attribute (шаблон URL) указывает на конкретный Resource Attribute (характеристику контента). Например, вероятность того, что шаблон указывает на язык, а не на страну.

Resource Attribute (Атрибут Ресурса)

Характеристика контента ресурса. Примеры, указанные в патенте: язык ресурса, страна таргетинга, требуемый user-agent (тип устройства).

Resource Locator (Указатель Ресурса)

Строка символов, идентифицирующая ресурс, например, URL.

Search Results Adjusting Engine (Механизм Корректировки Результатов Поиска)

Компонент, который использует Likelihoods и User Attributes для вычисления Alignment Score и переранжирования результатов поиска (повышения и понижения).

Set of Similar Resource Locators (Набор Схожих Указателей Ресурсов)

Группа URL с одного домена, которые имеют одинаковый Address Attribute (шаблон). Например, fr.example.com/page1 и de.example.com/page1 принадлежат к одному набору.

User Attributes (Атрибуты Пользователя)

Характеристики пользователя, связанные с запросом. Могут быть явными (настройки аккаунта) или неявными (IP-адрес, язык браузера, история поиска, User-Agent). Примеры: язык, страна, тип устройства.

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

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

1. Система выбирает URL (resource locators), имеющие одно и то же доменное имя.
2. Для каждого URL определяются: (a) Атрибуты контента (resource attributes) и (b) Атрибуты адреса (address attributes) — части URL, которые варьируются по шаблону.
3. Определяется набор схожих URL (set of similar resource locators) — группа URL, соответствующих одному шаблону.
4. Система сравнивает атрибуты адреса с атрибутами контента внутри этого набора.
5. На основе сравнения определяется вероятность (likelihood), что атрибут адреса указывает на конкретный атрибут контента. Это основано на том, как контент меняется при изменении значения атрибута адреса.
6. Эти вероятности ассоциируются с соответствующими URL в поисковом индексе (resource index data store).

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

1. Система получает результаты поиска, ранжированные в исходном порядке.
2. Для каждого результата вычисляется оценка соответствия (alignment score). Эта оценка основана на атрибутах пользователя (user attributes) и вероятностях (likelihoods), связанных с URL результата.
3. Ранг результата с наивысшей оценкой соответствия (то есть того, чьи атрибуты лучше всего совпадают с атрибутами пользователя) повышается.

Claim 4 (Зависимый от 3): Уточняет механизм корректировки.

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

Claim 8 (Зависимый от 3): Определяет приоритеты при расчете соответствия.

При повышении ранга используется приоритет выравнивания (alignment priority), при котором языковое соответствие имеет приоритет над страновым соответствием, а страновое соответствие имеет приоритет над соответствием user-agent.

Claim 10 (Зависимый от 6 и 1): Детализирует метод расчета вероятностей для языка и страны.

1. Используются счетчики. Счетчик языка (language counter) увеличивается, если ресурс написан на языке, указанном кодом в URL. Счетчик страны (country counter) увеличивается, если ресурс таргетирован на страну, указанную кодом в URL.
2. Вероятность (Likelihood) для языка и страны определяется на основе значений этих счетчиков.

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

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

INDEXING – Индексирование и извлечение признаков
Основная работа механизма происходит на этом этапе (офлайн). Site Processing Engine анализирует структуру сайта и контент.

• Процесс: Анализ URL для выявления шаблонов (Address Attributes) и группировки URL. Анализ контента для определения Resource Attributes. Вычисление вероятностей (Likelihoods).
• Выходные данные: Likelihoods сохраняются в индексе (Attribute Data) и ассоциируются с соответствующими URL.

RERANKING – Переранжирование
Механизм активируется во время обработки запроса для корректировки финальной выдачи. Search Results Adjusting Engine выполняет эту функцию.

• Процесс: Получение исходного набора результатов и User Attributes. Вычисление Alignment Scores для результатов, принадлежащих к одному набору схожих URL. Переранжирование внутри этого набора: лучшая версия повышается, остальные понижаются.

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

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

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

• (Ранжирование): Скорректированный набор результатов поиска, где локализованные версии переупорядочены.

На что влияет

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

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

• Триггеры активации (Ранжирование): Механизм корректировки активируется, когда в результатах поиска идентифицировано несколько ресурсов, принадлежащих к одному и тому же Set of Similar Resource Locators (т.е. несколько версий одной страницы).
• Условия (Индексирование): Механизм анализа активируется, когда на сайте обнаруживаются URL, варьирующиеся по определенному шаблону (Address Attribute).
• Ограничения: В патенте упоминается (в описании), что повышение ранга может не произойти, если исходная оценка релевантности результата слишком низкая (например, не входит в Топ-N или значительно уступает лидеру).

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

Процесс А: Определение Вероятностей (Офлайн / Индексирование)

1. Выборка URL: Система выбирает URL, имеющие одинаковое доменное имя.
2. Определение Атрибутов Ресурсов: Для каждого URL система анализирует контент и определяет его характеристики (Resource Attributes) — язык, страна таргетинга, требования к user-agent.
3. Определение Атрибутов Адресов: Система анализирует структуру URL для выявления частей, которые варьируются по шаблону (Address Attributes).
4. Группировка URL: URL группируются в Sets of Similar Resource Locators на основе выявленных шаблонов.
5. Сравнение Атрибутов: Внутри каждой группы система сравнивает, как изменение атрибута адреса коррелирует с изменением атрибутов контента.
6. Вычисление Вероятностей (Likelihoods): Для каждого шаблона вычисляется вероятность того, что он указывает на определенный атрибут контента. Это может включать использование счетчиков и, опционально, априорных вероятностей (a priori probabilities).
7. Сохранение Данных: Вычисленные вероятности сохраняются в индексе и ассоциируются с соответствующими URL.

Процесс Б: Корректировка Ранжирования (Онлайн / Обработка Запроса)

1. Получение Результатов и Атрибутов: Система получает исходный набор результатов и определяет User Attributes (язык, страна, устройство).
2. Идентификация Групп: Система проверяет, есть ли в результатах поиска несколько URL, принадлежащих к одному Set of Similar Resource Locators.
3. Вычисление Оценки Соответствия (Alignment Score): Для каждого URL в идентифицированных группах вычисляется Alignment Score на основе сохраненных Likelihoods и User Attributes. При расчете могут учитываться приоритеты (Язык > Страна > Устройство).
4. Переранжирование (Повышение): Внутри каждой группы результат с наивысшим Alignment Score повышается в ранге (обычно выше всех остальных результатов группы).
5. Переранжирование (Понижение): Другие результаты из этой группы, имеющие более низкий Alignment Score, понижаются в ранге.
6. Финальная Выдача: Скорректированный набор результатов предоставляется пользователю.

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

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

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

• Структурные факторы (URL): Критически важные данные. Анализируются Resource Locators для выявления Address Attributes. Патент упоминает анализ хост-имен (поддоменов), путей (директорий), имен файлов, номеров портов и параметров запроса.
• Контентные факторы: Содержимое ресурсов анализируется для определения Resource Attributes (например, определение языка текста, признаков геотаргетинга).
• Пользовательские факторы: Используются во время ранжирования (User Attributes). Включают язык, страну (по IP или настройкам), тип устройства (User-Agent). Могут быть получены из настроек браузера, данных аккаунта (User Account Data) или истории поиска.
• Ссылочные факторы (Внутренние ссылки): Упоминается использование site linkage information для определения иерархических отношений между ресурсами и валидации атрибутов.
• Поведенческие факторы (Исторические данные): Упоминаются Historical Data (логи запросов и кликов). Могут использоваться для определения таргетинга (например, если на ресурс идет трафик преимущественно из одной страны) или анализа изменений запросов (query revisions).

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

• Likelihood (Вероятность): Вероятность того, что шаблон URL указывает на атрибут контента.

  Метод 1 (Счетчики) (Claim 10): Подсчитывается, сколько раз атрибут адреса (например, код 'fr') соответствовал атрибуту контента (например, французскому языку — Language Counter, или таргетингу на Францию — Country Counter). Вероятность рассчитывается как отношение соответствующего счетчика к общему числу URL в наборе.

  Метод 2 (С использованием априорных вероятностей) (Table 1 в описании): Учитывается a priori probability (на основе анализа всего интернета) и наблюдаемое распределение на конкретном сайте. Они комбинируются для получения оценки уверенности (Confidence). Итоговая Likelihood для шаблона рассчитывается как взвешенная сумма оценок уверенности для разных значений атрибута.

• Alignment Score (Оценка Соответствия): Метрика соответствия ресурса пользователю. Рассчитывается путем комбинирования User Attributes и Likelihoods ресурса. Например, это может быть скалярное произведение вектора атрибутов пользователя и вектора вероятностей ресурса. При расчете учитываются приоритеты атрибутов (Claim 8).

1. Автоматическое определение локализации и адаптации: Google активно пытается автоматически понять структуру интернационализации и адаптации сайта под устройства, анализируя шаблоны URL и сравнивая их с контентом. Система не полагается исключительно на явные сигналы.
2. Вероятностный подход к атрибутам URL: Система не делает жестких выводов, а вычисляет Likelihoods — вероятности того, что шаблон указывает на язык, страну или user-agent. Это позволяет обрабатывать неоднозначные случаи (например, код 'es' для Испании или испанского языка).
3. Приоритет соответствия пользователю (Alignment): Ключевым механизмом является Search Results Adjusting Engine. Он гарантирует, что если в выдаче есть несколько версий одного контента, версия, наиболее соответствующая атрибутам пользователя (Alignment Score), будет показана выше остальных.
4. Приоритеты атрибутов: При выборе лучшей версии система отдает предпочтение языковому соответствию перед страновым, а страновому — перед соответствием типу устройства (Claim 8).
5. Кластеризация и Демоушен: Система группирует похожие URL (Set of Similar Resource Locators) и обрабатывает их как кластер. После выбора лучшей версии остальные понижаются (демоушены), чтобы избежать дублирования в SERP.
6. Важность консистентности сигналов: Точность работы системы напрямую зависит от того, насколько последовательно структура URL отражает атрибуты контента. Противоречивые сигналы могут привести к низким значениям Likelihood и ошибкам в таргетинге.

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

• Использовать четкую, последовательную и логичную структуру URL: Это ключевая рекомендация. Структура URL должна последовательно отражать таргетинг контента (язык, страну и/или устройство). Это поможет системе правильно вычислить Likelihoods. Используйте стандартные коды (ISO 639 для языков, ISO 3166 для стран).
• Обеспечивать строгое соответствие контента и URL: Убедитесь, что контент на странице соответствует таргетингу, подразумеваемому URL. Если URL содержит /fr/, контент должен быть на французском языке. Несоответствие снизит точность определения Resource Attributes.
• Разделять язык и страну при необходимости: Если сайт таргетируется и на язык, и на страну, используйте структуру, которая явно разделяет эти атрибуты (например, /en-gb/, /en-us/). Это помогает избежать неоднозначности и позволяет системе точнее рассчитывать Alignment Score.
• Использовать явные сигналы таргетинга (Hreflang): Хотя патент описывает автоматическое определение, предоставление явных сигналов через hreflang остается лучшей практикой. Это устраняет необходимость для Google угадывать таргетинг и верифицирует автоматические выводы системы.
• Настраивать внутреннюю перелинковку между версиями: Используйте ссылки для переключения языка/страны. Патент упоминает использование site linkage information. Четкая перелинковка помогает системе идентифицировать Sets of Similar Resource Locators.

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

• Использовать неоднозначную или непоследовательную структуру URL: Смешивание разных подходов к локализации (например, использование поддоменов для одних языков и директорий для других) или использование нестандартных кодов затруднит для системы выявление Address Attributes.
• Противоречия между языком и страной: Использование кодов стран для обозначения языков (например, example.com/uk/ для английского языка вместо /en/) может привести к конфликтам при вычислении Likelihoods.
• Смешивание языков на одной странице или в одной структуре: Наличие значительных блоков текста на разных языках на одном URL или смешивание языков в одной директории усложняет определение основного Resource Attribute и снижает уверенность системы.
• Использование Cookies или параметров сессии для локализации без уникальных URL: Если локализация не отражена в основном URL (хост, путь), системе будет сложнее идентифицировать Address Attributes и сгруппировать схожие ресурсы (хотя анализ параметров запроса упомянут в патенте как возможный).

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

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

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

Сценарий 1: Разрешение неоднозначности Язык vs Страна

Ситуация: Сайт использует структуру <код>.example.com. Есть fr.example.com (Французский язык) и ca.example.com.

Проблема: Код 'ca' может означать Каталанский язык или Канаду.

Действия Google (согласно патенту):

1. Система анализирует контент на ca.example.com. Предположим, он на английском и французском языках и таргетирован на Канаду.
2. Система рассчитывает Likelihoods. Language Likelihood для каталанского будет близка к 0. Country Likelihood для Канады будет высокой.
3. Пользователь из Канады ищет информацию. Google вычислит высокий Alignment Score для ca.example.com по стране и продвинет этот результат.
4. Если бы пользователь искал на каталанском языке, Alignment Score для ca.example.com был бы низким.

Сценарий 2: Исправление непоследовательной структуры

Ситуация: Сайт использует example.com/de/. В 70% случаев контент на немецком языке, в 30% — на английском, но для Германии.

Действия Google: Система рассчитает Language Likelihood ≈ 0.7 и Country Likelihood ≈ 1.0 (если весь контент таргетирован на Германию). Уверенность в языковом таргетинге снижена.

SEO Рекомендация: Обеспечить 100% последовательность. Создать структуру example.com/de-de/ (немецкий для Германии) и example.com/en-de/ (английский для Германии). Это позволит системе рассчитать высокие Likelihoods для обеих структур и точно таргетировать контент на пользователей в зависимости от их языка и местоположения.