Яндекс патентует метод идентификации объектов на веб-странице (таких как реклама, логотипы, карты) путем анализа их характеристик после рендеринга (размер, положение, стиль) и особенностей исходного кода. Система использует машинное обучение для оценки вероятности того, что элемент является целевым объектом, комбинируя визуальные признаки и анализ кода.
Описание
Какую задачу решает
Патент решает задачу точной идентификации специфических объектов на веб-странице (например, рекламы, баннеров, логотипов, карт, форм ввода), когда анализа только исходного кода (HTML/DOM) недостаточно или он ненадежен из-за сложности верстки, обфускации или динамического контента. Метод позволяет системе понять назначение элемента на основе того, как он выглядит и где расположен после финального рендеринга браузером.
Что запатентовано
Запатентована система идентификации Целевых Объектов (Target Objects), которая выполняется в среде, способной рендерить веб-страницы (браузер или краулер). Суть изобретения заключается в гибридном подходе: применении набора предопределенных правил (Predetermined Rules) к Визуальным Характеристикам (Rendered Object Characteristics) (размер, положение, стиль) и, опционально, к Особенностям Кода (Code Features) элемента-кандидата после рендеринга.
Как это работает
Система сначала парсит инструкции рендеринга (HTML, CSS, JS) и определяет потенциальных кандидатов. Затем страница рендерится. После рендеринга запускается процесс верификации: система измеряет визуальные характеристики кандидата (например, ширина < 500px, расположен справа) и проверяет особенности кода (например, наличие строки «map» в атрибуте src). На основе результатов проверки правил, часто с помощью Алгоритма Машинного Обучения (Machine Learned Algorithm), рассчитывается Параметр Вероятности (Likelihood Parameter). Если вероятность превышает порог, объект идентифицируется.
Актуальность для SEO
Средне-высокая. Анализ рендеринга страниц (Visual Parsing) критически важен для поисковых систем для понимания структуры контента, оценки UX и выявления навязчивой рекламы. Описанный гибридный метод, комбинирующий анализ кода и визуального представления с использованием машинного обучения, остается надежным и актуальным подходом.
Важность для SEO
Влияние на SEO умеренное (4/10). Патент не описывает алгоритм ранжирования. Он описывает технологию извлечения данных и понимания структуры страницы на этапе CRAWLING или INDEXING. Однако эта технология критически важна для сбора данных, которые используются алгоритмами оценки качества страницы (например, Proxima, Anti-Quality) для точного определения количества и расположения рекламы, что косвенно влияет на SEO.
Детальный разбор
Термины и определения
- Code Features (Особенности кода)
- Данные, теги, атрибуты, скрипты или детали, включенные в инструкции рендеринга веб-элемента. Любая информация, которая может быть извлечена из исходного кода (например, наличие тега <map>, атрибута src со строкой «map»).
- Likelihood Parameter (Параметр вероятности)
- Метрика (например, в процентах), указывающая вероятность того, что кандидат является целевым объектом. Рассчитывается на основе результатов проверки правил.
- Machine Learned Algorithm (Алгоритм машинного обучения)
- Алгоритм, используемый в процессе верификации для расчета Likelihood Parameter на основе результатов проверки правил. Должен быть предварительно обучен для конкретного типа целевого объекта.
- Predetermined Rules (Предопределенные правила)
- Набор правил, заранее определенных (например, человеком-асессором) на основе типичных визуальных характеристик и/или особенностей кода искомого целевого объекта. Могут включать «мягкие правила» (Soft Rules) с интервалами значений.
- Rendered Object Characteristics (Визуальные характеристики объекта)
- Характеристики веб-элемента после рендеринга страницы. Включают размер, положение, стили, иерархию и порядок отрисовки (Drawing Order).
- Target Object (Целевой объект)
- Конкретный тип объекта на странице, который система пытается идентифицировать (например, логотип, карта, баннер, реклама, форма ввода).
- Verification Process (Процесс верификации)
- Процесс, выполняемый после рендеринга страницы для подтверждения того, что кандидат является целевым объектом, путем применения предопределенных правил.
Ключевые утверждения (Анализ Claims)
Патент защищает метод идентификации объектов, который использует характеристики объекта ПОСЛЕ его рендеринга, опционально дополненный анализом кода.
Claim 1 (Независимый пункт): Описывает базовый метод идентификации, фокусируясь на визуальном анализе после рендеринга.
- Получение инструкций рендеринга.
- Парсинг инструкций для определения кандидата.
- Рендеринг веб-страницы (на экране или в памяти).
- Выполнение процесса верификации на отрисованной версии страницы.
- Верификация включает применение набора правил, основанных на Rendered Object Characteristics (визуальных характеристиках) целевого объекта.
- Система определяет фактические визуальные характеристики кандидата и валидирует правила.
- Присвоение Likelihood Parameter (параметра вероятности) на основе результатов валидации.
Claim 3 (Зависимый от 1): Описывает гибридный подход, добавляющий анализ исходного кода.
- Парсинг включает определение типа кандидата.
- Процесс верификации также выполняется над инструкциями рендеринга (исходным кодом).
- Применяются дополнительные правила, основанные на Code Features (особенностях кода), связанных с потенциальными типами целевого объекта.
- Likelihood Parameter рассчитывается с учетом как визуальных характеристик, так и особенностей кода.
Claim 8 (Зависимый от 7): Описывает обработку множественных кандидатов разных типов.
Если существуют кандидаты разных типов (например, логотип как изображение и логотип как ссылка), набор правил состоит из подмножеств (sub-sets). Каждое подмножество специфично для конкретного типа и включает правила, основанные как на Rendered Object Characteristics, так и на Code Features.
Claim 10 (Зависимый от 1): Уточняет, что процесс верификации может выполняться с помощью Machine Learned Algorithm.
Где и как применяется
Эта технология применяется на этапах сбора и анализа данных для разметки структуры страницы. Она может быть реализована как в браузере пользователя (например, Яндекс.Браузер для блокировки рекламы), так и в инфраструктуре поисковой системы.
CRAWLING – Сканирование и Сбор данных
Краулер (например, компонент Scraper, отвечающий за рендеринг) загружает страницу и выполняет ее отрисовку (Headless Browser). После рендеринга запускается описанный алгоритм для идентификации ключевых элементов (рекламы, основного контента, навигации).
INDEXING – Индексирование и извлечение признаков
Идентифицированные объекты и их характеристики сохраняются в индексе как метаданные документа (признаки). Например, информация о расположении рекламы и основного контента.
QUALITY & GOVERNANCE LAYER (Косвенно)
Данные, полученные с помощью этого метода (например, точное расположение и объем рекламы), служат входными сигналами для алгоритмов оценки качества (Proxima, Anti-Quality).
- Входные данные: Инструкции рендеринга (HTML, CSS, JavaScript).
- Выходные данные: Идентификация целевых объектов на странице и их Likelihood Parameter.
На что влияет
- Реклама и баннеры: Система может точно идентифицировать рекламные блоки на основе их типичных размеров, расположения и кода, даже если они маскируются под обычный контент.
- Структурные элементы: Идентификация логотипов (для фавиконок), карт, форм ввода.
- Анализ макета (Layout Analysis): Позволяет системе лучше понимать визуальную структуру страницы – где находится основной контент, а где навигация или реклама.
Когда применяется
- Алгоритм применяется во время фазы рендеринга при сканировании и индексировании веб-страницы (или при просмотре в браузере).
- Он активируется после того, как страница полностью отрендерена.
Пошаговый алгоритм
- Получение инструкций: Система получает инструкции рендеринга (HTML, CSS, JS).
- Парсинг и выбор кандидатов: Инструкции парсятся. Определяются кандидаты в целевые объекты и их типы (например, все <img>, если ищется логотип).
- Рендеринг: Система выполняет рендеринг страницы, определяя финальное визуальное представление всех элементов.
- Верификация (для каждого кандидата):
- Выбор правил: Выбирается набор (или поднабор) правил, соответствующий искомому объекту и типу кандидата.
- Измерение характеристик: Система определяет Rendered Object Characteristics (размер, позиция, стиль, порядок отрисовки) кандидата. Опционально, извлекаются Code Features (теги, атрибуты, скрипты).
- Валидация правил: Система проверяет, соответствуют ли характеристики кандидата правилам (например, ширина < 500px – Да/Нет). Могут использоваться Soft Rules.
- Расчет вероятности (ML): Результаты валидации правил подаются на вход Machine Learned Algorithm, который рассчитывает Likelihood Parameter.
- Идентификация: Если параметр вероятности превышает заранее определенный порог (например, 80%), кандидат идентифицируется как целевой объект.
Какие данные и как использует
Данные на входе
Система использует два основных типа данных:
- Структурные и Контентные факторы (Code Features): Извлекаются из инструкций рендеринга.
- HTML теги (например, <img>, <map>, <area>; специфичные теги <lat>, <lng> для карт).
- Атрибуты тегов (например, анализ атрибута src на наличие строк «map», «ad»).
- Скрипты и их содержимое.
- Визуальные и Технические факторы (Rendered Object Characteristics): Извлекаются после рендеринга.
- Размер: Ширина и высота в пикселях.
- Позиция: Координаты на экране, расположение (справа, по центру и т.д.).
- Стили: Визуальные характеристики (ширина рамки, тень).
- Порядок отрисовки (Drawing Order): Видимость элемента, скрыт ли он, пересекается ли с другими элементами.
Какие метрики используются и как они считаются
- Валидация правил: Проверка соответствия извлеченных признаков предопределенным правилам. В патенте упоминаются примеры правил:
- Для баннера: Ширина ≤ 500px, Высота ≤ 150px, Расположен справа, Центрирован, Скрыт из-за порядка отрисовки, Рамка ≤ 5px.
- Для карты (Code Features): Содержит тег <lat> или <lng>, Атрибут src содержит «map», Наличие строки «geocode».
- Likelihood Parameter: Финальная метрика вероятности.
- Машинное обучение: Патент указывает на использование Machine Learned Algorithm для расчета Likelihood Parameter. Входными данными для MLA является исход валидации правил (вектор признаков). Некоторые правила могут иметь отрицательный эффект (detrimental effect) на вероятность.
Выводы
- Анализ после рендеринга (Visual Parsing): Яндекс не полагается только на исходный код. Система анализирует финальное визуальное представление страницы после выполнения всех инструкций рендеринга (CSS, JS), что позволяет обходить обфускацию кода и понимать реальный макет.
- Гибридный подход к идентификации: Для точной идентификации объектов (реклама, контент, навигация) используется комбинация визуальных характеристик (Rendered Object Characteristics) и анализа исходного кода (Code Features).
- Машинное обучение для анализа макета: Идентификация является вероятностной и использует обученные модели (Machine Learned Algorithm) для взвешивания различных признаков, а не только жесткие правила.
- Фундамент для оценки качества (Page Quality): Эта технология является критически важным инструментом для сбора данных, используемых алгоритмами оценки качества (Proxima, Anti-Quality). Точное определение расположения, объема и навязчивости рекламы напрямую влияет на оценку качества страницы.
- Борьба с визуальными манипуляциями: Анализ порядка отрисовки и видимости позволяет выявлять попытки скрыть контент или рекламу с помощью CSS/JS.
Практика
Best practices (это мы делаем)
- Соблюдение стандартов верстки и UX (Page Layout): Убедитесь, что основной контент (MC) визуально выделяется и занимает центральное место. Избегайте макетов, где контент смешивается с рекламой или вспомогательными элементами. Стандартный дизайн помогает системе корректно идентифицировать элементы, так как правила основаны на типичных характеристиках.
- Контроль над размещением рекламы: Размещайте рекламные блоки в стандартных местах с четкими границами. Избегайте агрессивной рекламы, которая перекрывает контент или имитирует его. Система может точно идентифицировать такие блоки, что может послужить сигналом для алгоритмов Anti-Quality.
- Семантическая разметка и чистый код: Используйте подходящие HTML-теги и микроразметку для ключевых объектов (логотипы, карты). Наличие четких Code Features (например, использование Schema.org для логотипа или стандартных API для карт) упрощает идентификацию и снижает риск ошибки классификации.
- Тестирование рендеринга: Проверяйте, как ваша страница рендерится в различных условиях. Убедитесь, что ключевые элементы не скрываются и не смещаются непреднамеренно, так как система анализирует финальное визуальное состояние (Rendered Object Characteristics).
Worst practices (это делать не надо)
- Маскировка рекламы под контент (Мимикрия) или Клоакинг: Попытки сделать рекламные блоки визуально неотличимыми от контента или скрыть их в коде при визуальном отображении неэффективны. Система анализирует типичные размеры, расположение и финальный рендеринг для их идентификации.
- Скрытие контента с помощью CSS/JS: Использование техник вроде перекрытия элементами с высоким z-index или вывод текста за пределы экрана. Анализ Rendered Object Characteristics (включая порядок отрисовки и видимость) позволяет системе понять, что элемент скрыт.
- Навязчивые макеты рекламы: Использование всплывающих окон и избыточного количества рекламы над основным контентом. Эта технология позволяет Яндексу точно измерять визуальное воздействие рекламы для применения санкций.
Стратегическое значение
Патент подтверждает наличие у Яндекса сложных возможностей рендеринга и визуального анализа страниц. Это подчеркивает важность пользовательского опыта (UX) и дизайна макета для SEO. Визуальное представление и размещение рекламы становятся измеримыми факторами, влияющими на оценку качества сайта. Стратегия SEO должна учитывать не только семантику контента, но и семантику верстки и визуального дизайна.
Практические примеры
Сценарий 1: Обнаружение навязчивой рекламы (Intrusive Ads)
- Ситуация: Сайт использует сложный JavaScript для загрузки рекламного баннера, который визуально перекрывает основной контент. Структура HTML обфусцирована.
- Работа системы: Яндекс рендерит страницу. Система анализирует Rendered Object Characteristics: размер (большой), позиция (центр экрана), порядок отрисовки (поверх контента).
- Результат: MLA идентифицирует этот блок как рекламный баннер с высокой вероятностью, несмотря на обфускацию кода. Эти данные используются алгоритмами ранжирования (например, Anti-Quality) для пессимизации страницы.
Сценарий 2: Идентификация логотипа для сниппета/фавиконки
- Ситуация: Яндексу нужно определить официальный логотип сайта. На странице много изображений.
- Работа системы: Система идентифицирует все изображения как кандидатов. После рендеринга она применяет правила для логотипов. Кандидат в шапке имеет Rendered Object Characteristics (позиция вверху слева, малый размер) и Code Features (класс «logo»).
- Результат: MLA присваивает этому кандидату высокий Likelihood Parameter. Яндекс использует это изображение для своих сервисов (например, как фавиконку в сниппетах).
Вопросы и ответы
Что такое «Rendered Object Characteristics» и почему они важны?
Rendered Object Characteristics – это визуальные характеристики элемента после того, как браузер (или краулер) отрисовал страницу (применил HTML, CSS и JS). К ним относятся фактический размер в пикселях, положение на странице, стиль (цвет, рамки), а также видимость и порядок отрисовки. Они важны, потому что позволяют системе понять, как страница выглядит на самом деле для пользователя, что невозможно сделать, анализируя только исходный код.
Чем «Code Features» отличаются от «Rendered Object Characteristics»?
Code Features извлекаются непосредственно из исходного кода (HTML, JS) – это теги, атрибуты или строки в скриптах. Rendered Object Characteristics — это результат интерпретации этого кода браузером (визуальный вывод). Система Яндекса использует гибридный подход, комбинируя оба типа данных для более точной идентификации объекта.
Означает ли этот патент, что Яндекс использует визуальный анализ для ранжирования?
Патент не описывает алгоритм ранжирования. Однако он описывает технологию точной идентификации элементов на странице (например, рекламы и контента). Эта информация используется как входные данные для алгоритмов оценки качества страницы (таких как Proxima или Anti-Quality), которые влияют на ранжирование. Например, сайт с чрезмерным количеством идентифицированной рекламы может быть понижен.
Может ли эта система обнаружить скрытый текст или ссылки?
Да, потенциально может. Поскольку система анализирует финальное состояние после рендеринга, включая порядок отрисовки и видимость элементов, она может идентифицировать контент, который присутствует в коде, но фактически скрыт от пользователя с помощью CSS или JavaScript (например, перекрыт другими элементами). В патенте прямо упоминается правило «Скрыт из-за порядка отрисовки».
Как система определяет, является ли блок рекламой?
Система использует комбинацию визуальных характеристик и особенностей кода. Для рекламы правила могут включать проверку типичных размеров баннеров (например, не более 500×150 пикселей, как указано в патенте), стандартного расположения (сверху, справа), а также наличие в коде признаков рекламных сетей. Машинное обучение взвешивает эти факторы.
Используется ли в этом патенте машинное обучение?
Да, патент явно упоминает использование алгоритма машинного обучения (Machine Learned Algorithm) на этапе верификации. ML-модель принимает результаты проверки всех правил (визуальных и кодовых) и рассчитывает итоговую вероятность (Likelihood Parameter) того, что элемент является искомым объектом.
Что такое «мягкие правила» (soft rules), упомянутые в патенте?
Мягкие правила — это критерии, которые валидируются, если значение признака попадает в определенный диапазон, в отличие от жестких правил, требующих точного совпадения. Например, правило: «высота не более 400px». Это делает систему более гибкой и устойчивой к небольшим вариациям в дизайне и верстке.
Может ли система ошибочно принять мой полезный контент за рекламу?
Теоретически это возможно, так как система использует вероятностный подход. Если блок полезного контента имеет визуальные характеристики, очень похожие на типичный рекламный баннер (стандартный размер, расположение сбоку), риск ложного срабатывания существует. Рекомендуется избегать оформления основного контента в стиле рекламных блоков.
Как этот патент связан с Core Web Vitals?
Напрямую не связан, но использует ту же базовую технологию – анализ рендеринга страницы. Core Web Vitals измеряют скорость и стабильность рендеринга, а технология из патента анализирует результат рендеринга (что и где отрисовано). Это показывает, что Яндекс глубоко анализирует процесс рендеринга для сбора различных типов данных о странице.
Нужно ли мне беспокоиться о том, как выглядит моя страница для робота Яндекса?
Да, абсолютно. Этот патент подтверждает, что робот Яндекса «видит» вашу страницу почти так же, как пользователь в браузере (Visual Parsing). Необходимо убедиться, что робот может корректно загрузить и отрендерить все ресурсы (CSS, JS), и что финальный вид страницы соответствует ожиданиям: контент доступен, реклама не мешает, нет скрытых элементов или манипуляций с макетом.