Как Яндекс идентифицирует элементы страницы (логотипы, баннеры, карты) на основе их кода и внешнего вида после рендеринга

Описание

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

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

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

Запатентован метод идентификации целевого объекта (Target Object) на веб-странице. Суть изобретения заключается в гибридной верификации кандидата как на уровне кода, так и на уровне отрендеренной версии страницы. Система использует предопределенные наборы правил (Predetermined Rules), которые сочетают анализ визуальных характеристик объекта после рендеринга (Rendered Object Characteristics) и анализ особенностей его исходного кода (Code Features).

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

Система (например, краулер с функцией рендеринга или браузер) получает инструкции рендеринга (HTML, CSS, JS). На этапе парсинга определяются потенциальные кандидаты (Target Object Candidate) на основе их типа (например, изображение, ссылка, объект). Затем страница полностью рендерится. После этого запускается процесс верификации: к кандидату применяется специализированный поднабор правил, соответствующий его типу. Правила проверяют как визуальные аспекты (размер, позиция, порядок отрисовки), так и аспекты кода (наличие специфических тегов, атрибутов, скриптов). На основе результатов валидации правил, с помощью алгоритма машинного обучения, присваивается оценка вероятности (Likelihood Parameter), что кандидат является искомым объектом.

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

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

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

Влияние на SEO умеренное (6/10). Этот патент не описывает алгоритм ранжирования, но имеет важное значение для понимания того, как Яндекс анализирует макет страницы, рекламную нагрузку и ключевые сущности (E-E-A-T сигналы, такие как логотипы и карты). Если система ошибочно классифицирует основной контент как рекламу или не сможет идентифицировать логотип компании, это может косвенно повлиять на оценку качества страницы (например, через алгоритмы Proxima или Anti-Quality) и авторитетность ресурса.

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

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

Code Features (Характеристики кода)

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

Likelihood Parameter (Параметр вероятности)

Оценка, указывающая на вероятность того, что кандидат является целевым объектом. Присваивается на основе результатов валидации предопределенных правил.

Potential Types (Потенциальные типы)

Возможные технические реализации целевого объекта. Например, логотип может быть реализован как изображение (Image type), ссылка (Link type) или объект (Object type).

Predetermined Rules (Предопределенные правила)

Набор правил, используемых для верификации кандидата. Правила предопределяются (например, человеком-асессором) на основе анализа типичных характеристик кода и визуальных характеристик целевого объекта. Могут включать «мягкие правила» (Soft rules).

Rendered Object Characteristics (Визуальные характеристики объекта)

Характеристики веб-элемента, которые система «знает» после рендеринга страницы. Включают размер (width/height), позицию (coordinates), стили (styles), иерархию (hierarchy) и порядок отрисовки (drawing order).

Rendering Instructions (Инструкции рендеринга)

Данные, необходимые для отображения веб-страницы браузером. Включают HTML-код, CSS-инструкции и скрипты (например, JavaScript).

Target Object (Целевой объект)

Тип объекта на веб-странице, который система стремится идентифицировать. Примеры: логотип (Logo entity), карта (Map entity), баннер (Banner entity), реклама (Advertisement entity), форма ввода (Input form entity).

Target Object Candidate (Кандидат в целевые объекты)

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

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

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

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

1. Система получает инструкции рендеринга.
2. Парсинг инструкций для идентификации кандидатов. При этом определяется тип кандидата (например, изображение, ссылка, объект), который является одним из потенциальных типов целевого объекта.
3. Рендеринг веб-страницы на экране.
4. Выполнение процесса верификации для подтверждения того, что кандидат является целевым объектом. Верификация выполняется как на отрендеренной версии, так и на инструкциях рендеринга.
5. Процесс верификации включает применение набора предопределенных правил. Эти правила основаны на:
   • (A) Визуальных характеристиках (Rendered Object Characteristics) целевого объекта.
   • (B) Характеристиках кода (Code Features), связанных с потенциальными типами объекта (оцененными человеком-асессором).
6. Система обрабатывает множество кандидатов, которые могут быть разных типов (например, первый кандидат типа A, второй кандидат типа B).
7. Набор правил состоит из поднаборов (sub-sets). Каждый поднабор специфичен для одного потенциального типа (например, поднабор для типа A, поднабор для типа B).
8. Каждый поднабор правил сочетает общие визуальные характеристики целевого объекта и специфические характеристики кода для данного типа.
9. Применение правил включает определение визуальных характеристик кандидата и значений характеристик его кода, с последующей валидацией правил.
10. Присвоение параметра вероятности (Likelihood Parameter) на основе результатов валидации всех правил (визуальных и кодовых).

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

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

CRAWLING – Сканирование и Сбор данных
Метод используется сложными краулерами, способными выполнять рендеринг (например, на базе headless browser). Во время обхода система не просто загружает HTML, но и рендерит страницу для последующего анализа.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит анализ отрендеренной страницы. Система применяет описанный метод для точной идентификации ключевых элементов.

• Входные данные: Инструкции рендеринга (HTML, CSS, JS).
• Процесс: Система выступает в роли браузера: строит DOM-дерево, применяет стили, выполняет скрипты, строит Render Tree и выполняет отрисовку (Layout/Painting). После этого она анализирует финальное состояние объектов.
• Выходные данные: Идентифицированные объекты с метками (например, «Элемент X является Логотипом с вероятностью 90%») и извлеченные данные, связанные с этими объектами.

Эта информация может использоваться другими компонентами системы, например, для оценки качества страницы (обнаружение рекламы для Anti-Quality или Proxima), извлечения фактов для Графа Знаний или улучшения сниппетов.

На что влияет

• Идентификация рекламы (Banners, Advertisements): Критически важно для алгоритмов, оценивающих макет страницы и пессимизирующих за избыточную или навязчивую рекламу. Метод позволяет точно идентифицировать рекламу, даже если она обфусцирована в коде.
• Идентификация логотипов (Logos): Важно для распознавания бренда, что является сигналом авторитетности (E-E-A-T) и может использоваться для отображения фавиконок в выдаче.
• Идентификация карт (Maps): Важно для локального поиска и понимания географической привязки контента.
• Идентификация форм (Input Forms): Помогает понять назначение страницы и возможности взаимодействия.
• Типы контента и ниши: Влияет на все типы сайтов, но особенно значимо для страниц со сложной визуальной структурой, динамическим контентом (JS) и коммерческих сайтов с обилием рекламы и интерактивных элементов.

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

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

• Условия применения: Наличие в инструкциях рендеринга элементов, которые могут быть классифицированы как потенциальные кандидаты для искомых целевых объектов.
• Триггеры: Идентификация потенциального типа объекта во время парсинга запускает процесс верификации после рендеринга.

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

Процесс работы системы по идентификации целевого объекта (например, Логотипа):

1. Получение данных: Система получает инструкции рендеринга (HTML, CSS, JS) для веб-страницы.
2. Парсинг и Идентификация Кандидатов: Система парсит HTML и идентифицирует все элементы, которые потенциально могут быть Логотипом (например, элементы типа <img>, <a>, <object>). Для каждого кандидата фиксируется его тип.
3. Рендеринг: Система выполняет полный рендеринг страницы, применяя стили и выполняя скрипты.
4. Верификация (повторяется для каждого кандидата):
   1. Выбор поднабора правил: Система выбирает поднабор предопределенных правил (Sub-set of Predetermined Rules), соответствующий типу кандидата (например, правила для Логотипа-Изображения).
   2. Извлечение характеристик: Система определяет:
      • Визуальные характеристики (Rendered Object Characteristics) отрендеренного кандидата: размер, позиция на экране, стиль, видимость.
      • Характеристики кода (Code Features) кандидата из исходных инструкций: наличие определенных атрибутов, структура URL, специфические теги или скрипты.
   3. Валидация правил: Система проверяет, соответствуют ли извлеченные характеристики правилам из выбранного поднабора. Правила могут быть мягкими (Soft Rules), например, «ширина не более 400 пикселей». Некоторые правила могут быть «штрафующими» (detrimental effect), снижая вероятность при их выполнении.
   4. Расчет вероятности: На основе результатов валидации (вектора выполненных/невыполненных правил) система (используя Machine Learned Algorithm) присваивает кандидату параметр вероятности (Likelihood Parameter).
5. Принятие решения: Кандидаты, чей параметр вероятности превышает предопределенный порог (например, 80%), помечаются как Целевой Объект (Логотип). Система может идентифицировать несколько объектов одного типа на странице.
6. Сбор данных (Опционально): Система может собирать данные (включая инструкции рендеринга) для всех идентифицированных целевых объектов.

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

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

Система использует широкий спектр данных, получаемых как из исходного кода (Code Features), так и в результате рендеринга (Rendered Object Characteristics).

• Структурные и Контентные факторы (Code Features): Извлекаются из исходного кода. В патенте приводятся примеры для идентификации карт:
  • HTML-теги: <map>, <area>, <lat> (широта), <lng> (долгота).
  • Атрибуты элементов: Содержимое атрибута src внешнего скрипта (например, наличие строки «map»); наличие атрибута адреса.
  • Содержимое скриптов и тегов: Наличие строки «geocode»; конкретные строки скриптов, например, вызовы API карт (http://api-maps.yandex.ru/…).
• Технические факторы (Rendering Instructions):
  • CSS-инструкции (определяющие стили и макет).
  • Скрипты (упомянуты JavaScript и ActionScript), определяющие динамическое поведение.
• Визуальные факторы (Rendered Object Characteristics): Рассчитываются после рендеринга. В патенте приводятся примеры для идентификации баннеров:
  • Размер (Size): Ширина (например, не более 500 пикселей) и высота (например, не более 150 пикселей).
  • Позиция (Position): Координаты на экране (например, расположен справа или по центру).
  • Стили (Styles): Рамка (например, не более 5 пикселей), затенение рамки (например, менее 50%).
  • Иерархия и Порядок Отрисовки (Hierarchy/Drawing Order): Видимость элемента, пересечение с другими элементами, скрыт ли элемент из-за порядка отрисовки.

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

• Валидация правил (Rule Validation): Система сравнивает значения извлеченных признаков с предопределенными правилами. Правила могут быть жесткими или мягкими (Soft Rules), допускающими интервалы значений (например, ширина от 0 до 400 пикселей).
• Отрицательные Правила: Валидация некоторых правил может иметь «пагубный эффект» (detrimental effect) на вероятность. Например, если высота объекта менее 10 пикселей, это может уменьшить вероятность того, что он является баннером.
• Likelihood Parameter: Рассчитывается на основе вектора результатов валидации правил.
• Алгоритм Машинного Обучения (Machine Learned Algorithm): Используется для агрегации результатов валидации всех правил (как визуальных, так и кодовых) в итоговый Likelihood Parameter.
• Роль Асессоров: Патент упоминает, что правила и значимость характеристик кода определяются на основе оценки человеком-асессором (human assessor), который изучает типичные реализации целевых объектов. ML-алгоритм обучается на этих данных.

Выводы

1. Анализ после рендеринга критичен: Яндекс не полагается только на исходный HTML для понимания страницы. Система анализирует финальное визуальное представление элементов (размер, позиция, видимость), чтобы точно определить их назначение (например, отличить контент от рекламы).
2. Гибридная верификация: Ключевой механизм идентификации объекта — это сочетание анализа его визуальных характеристик (Rendered Object Characteristics) и характеристик его кода (Code Features). Это позволяет добиться высокой точности и устойчивости к обфускации.
3. Учет вариативности реализации: Система явно разработана для обработки ситуаций, когда один и тот же объект (например, логотип) может быть реализован разными способами (изображение, ссылка, объект). Для этого используются специализированные поднаборы правил для каждого типа.
4. Роль машинного обучения и асессоров: Правила для идентификации формируются при участии асессоров, а финальная оценка вероятности рассчитывается с помощью ML-моделей, обученных на основе этих правил, что позволяет системе адаптироваться к стандартам веб-разработки.
5. Цель — точное извлечение информации: Этот патент описывает инфраструктуру для Information Extraction. Точная идентификация рекламы, логотипов, карт и форм необходима для работы вышестоящих алгоритмов, включая оценку качества страницы (Proxima, Anti-Quality) и E-E-A-T.

Практика

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

• Обеспечение чистого и семантичного кода для ключевых элементов: Используйте стандартные и семантически верные способы реализации логотипов, карт и форм. Это гарантирует, что Code Features будут соответствовать ожиданиям системы и правилам, определенным асессорами. (Например, для логотипа использовать <img> с понятным alt и микроразметку Schema.org/Logo).
• Визуальная иерархия и соблюдение конвенций: Проектируйте макет так, чтобы ключевые элементы были визуально различимы и занимали ожидаемые позиции. Rendered Object Characteristics (размер, позиция) используются для идентификации. Логотип должен выглядеть как логотип и находиться в шапке сайта.
• Оптимизация рендеринга: Убедитесь, что страница рендерится быстро и корректно, и что робот Яндекса имеет доступ ко всем необходимым CSS и JS файлам. Анализ происходит только после завершения рендеринга.
• Четкое разделение контента и рекламы: Убедитесь, что основной контент визуально и структурно не похож на рекламу. Если система ошибочно классифицирует контент как баннер (на основе визуальных правил и правил кода), это может негативно сказаться на оценке качества страницы.

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

• Нестандартная реализация элементов: Использование обфусцированного кода или нестандартных способов реализации (например, логотип, отрисованный через Canvas без fallback) может помешать системе правильно идентифицировать элемент по его Code Features.
• Маскировка рекламы под контент (и наоборот): Попытки обмануть систему путем визуальной мимикрии становятся менее эффективными, так как система анализирует комбинацию визуальных признаков и кода.
• Layout Shifts (CLS) и перекрытие элементов: Значительные сдвиги макета или элементы, перекрывающие друг друга (например, агрессивная реклама), могут быть обнаружены при анализе порядка отрисовки и пересечений, что может негативно повлиять на оценку UX.
• Блокировка ресурсов для рендеринга: Закрытие CSS или JS файлов в robots.txt не позволит системе корректно отрендерить страницу и провести анализ визуальных характеристик.

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

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

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

Сценарий 1: Обеспечение корректной идентификации логотипа (E-E-A-T)

1. Задача: Убедиться, что Яндекс правильно идентифицирует логотип компании на сайте.
2. Действия (на основе патента):
   • Code Features: Реализовать логотип стандартным способом (например, <img> внутри <a href=»/»>). Указать атрибут alt с названием компании. Добавить микроразметку Schema.org/Organization с полем logo.
   • Rendered Object Characteristics: Разместить логотип на видном месте в шапке сайта. Убедиться, что его размер соответствует типичным размерам логотипов и он не перекрывается другими элементами после рендеринга.
3. Результат: Система применяет поднабор правил для Логотипа-Изображения. Правила по коду и визуальные правила успешно валидируются. Кандидат получает высокий Likelihood Parameter и классифицируется как логотип.

Сценарий 2: Анализ рекламной нагрузки (Anti-Quality)

1. Задача: Проверить, не считает ли Яндекс блок «Похожие товары» навязчивой рекламой.
2. Анализ (на основе патента): Система будет анализировать этот блок, применяя правила для идентификации Рекламы.
   • Code Features: Являются ли ссылки внутренними или ведут на внешние рекламные сети? Используются ли скрипты, типичные для загрузки рекламы?
   • Rendered Object Characteristics: Имеет ли блок стандартные размеры баннера (например, 728×90)? Расположен ли он в месте, типичном для рекламы? Перекрывает ли он основной контент?
3. Действия: Если блок визуально похож на рекламу (яркий, стандартного размера) и использует сложную JS-загрузку, риск идентификации как рекламы возрастает. Необходимо сделать дизайн блока более нативным и убедиться, что он не нарушает гайдлайны по качественным сайтам.
4. Результат: Снижение риска ошибочной классификации полезного блока как рекламы и избежание потенциальной пессимизации за избыток рекламы.

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