Как Google идентифицирует и игнорирует навигацию, футеры и рекламу на странице для понимания основного контента

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

Anchor Block (Блок ссылок)

Тип boilerplate content. Прямоугольная область страницы, включающая множество ссылок, например, навигационные панели, рекламные блоки или блоки связанных статей.

Anchor List (Список ссылок)

Тип boilerplate content. Серия последовательных ссылок, которые появляются внутри другого элемента, например, внутри основного контента.

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

Контент ресурса, который повторяется на нескольких или всех ресурсах определенного веб-сайта, или части ресурса, которые не релевантны основному содержанию (Main Content). Примеры: навигация, футеры, реклама, дисклеймеры.

Client Device (Клиентское устройство)

Устройство пользователя (компьютер, смартфон), на котором выполняется браузер и происходит анализ DOM.

DOM Tree (Document Object Model Tree)

Структурированная объектная модель ресурса (например, HTML документа), представленная в виде иерархии узлов (nodes). Используется браузером для рендеринга страницы.

Footer (Футер / Подвал)

Тип boilerplate content. Одна или несколько строк текста внизу страницы, часто содержащие копирайт или дисклеймер.

Layout Engine (Движок рендеринга)

Компонент веб-браузера, который строит DOM tree и рассчитывает визуальное представление страницы (например, Trident/MSHTML).

Likelihood Score (Оценка вероятности)

Числовая оценка, рассчитываемая для узла DOM, указывающая на вероятность того, что данный узел содержит boilerplate content. Рассчитывается на основе Predefined Traits.

Predefined Traits (Предопределенные признаки)

Набор характеристик (размер, форма, иерархия, расположение, атрибуты), используемых для идентификации boilerplate content.

Query Recommendation Engine (Система рекомендаций запросов)

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

Time Slicing (Квантование времени)

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

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

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

1. Система получает ресурс с сервера.
2. Выбираются один или несколько узлов DOM tree этого ресурса.
3. Определяется, что выбранные узлы демонстрируют один или более predefined traits, характерных для boilerplate content (контента, повторяющегося на нескольких ресурсах сайта).
4. Оценка (boilerplate content score), связанная с выбранными узлами, корректируется в ответ на обнаружение этих признаков.
5. Информация предоставляется Query Recommendation Engine. Эта информация включает текстовый контент узлов и идентифицирует скорректированную оценку (adjusted boilerplate content score).

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

Корректировка boilerplate content score включает увеличение или уменьшение оценки на основании определения того, что узлы демонстрируют predefined traits.

Claim 4 (Зависимый от 1): Описывает использование порогового значения.

1. Определяется, удовлетворяет ли boilerplate content score предопределенному порогу.
2. Если ДА, информация предоставляется Query Recommendation Engine, идентифицируя текстовый контент как boilerplate content.

Claims 5-10 (Зависимые): Детализируют признаки для идентификации Anchor Block.

Признаки включают: связь с блочным элементом (division-type, table-type, list-type) (Claim 6); размер области меньше предопределенного количества пикселей (Claim 7); соотношение высоты к ширине (или наоборот) больше предопределенного значения (Claim 8); наличие как минимум предопределенного количества дочерних элементов (Claim 9); процент текста, находящегося внутри элементов ссылок, превышает предопределенный порог (Claim 10).

Claims 11-13 (Зависимые): Детализируют признаки для идентификации Anchor List.

Признаки включают: наличие как минимум предопределенного количества дочерних объектов-ссылок (Claim 12); два или более объекта-ссылки выровнены по левому краю друг относительно друга (Claim 13).

Claims 14-16 (Зависимые): Детализируют признаки для идентификации Footer.

Признаки включают: область расположена в месте, обычно соответствующем низу веб-страницы (Claim 15); родительским узлом является элемент BODY (Claim 16).

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

Система копирует различные части DOM tree в течение двух или более временных интервалов (time slices), пока не будет получена полная копия. Выбор узлов для анализа происходит из этой копии с использованием фонового потока (background thread).

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

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

INDEXING – Индексирование и извлечение признаков (Indexing & Feature Extraction)

Хотя патент описывает реализацию на стороне клиента (Client-side implementation) для целей Query Recommendations, описанная технология обнаружения boilerplate content по структурным признакам является ключевой частью этапа индексирования в поисковой системе.

• Рендеринг и Анализ Структуры: Система (будь то клиентское приложение по патенту или Googlebot) должна отрендерить страницу и построить DOM tree.
• Feature Extraction (Извлечение Признаков): Происходит анализ DOM tree для классификации различных частей контента. Система идентифицирует boilerplate content (навигацию, футеры, рекламу) и отделяет его от основного содержания (Main Content).

Специфика патента (Client-Side):

Патент описывает выполнение этого процесса на Client Device (например, в браузере пользователя с установленным тулбаром или плагином). Это позволяет генерировать релевантные рекомендации на лету, не полагаясь на серверный анализ.

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

• Ресурс (HTML/XML документ), полученный с сервера.
• DOM tree, построенное движком рендеринга (Layout Engine).
• Набор Predefined Traits для разных типов boilerplate.

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

• Текстовый контент узлов DOM.
• Скорректированные оценки (Adjusted boilerplate content score / Likelihood Score) для этих узлов.
• (Опционально) Явная идентификация контента как boilerplate, если оценка превысила порог.

На что влияет

• Конкретные типы контента: Влияет на все типы страниц, использующие шаблоны. Особенно сильно влияет на страницы с обширной навигацией, большими футерами или большим количеством рекламных блоков (например, новостные сайты, блоги, форумы).
• Структурные элементы: Напрямую влияет на то, как интерпретируется контент и ссылки, расположенные в навигационных меню (Anchor Blocks), списках ссылок (Anchor Lists), футерах (Footers) и рекламных блоках (Ads).

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

• Триггеры активации: Процесс активируется на клиентском устройстве, когда пользователь или приложение инициирует процесс генерации Query Recommendation для текущей просматриваемой страницы.
• Условия работы: Требуется возможность доступа и анализа DOM tree страницы.

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

Алгоритм состоит из двух основных фаз: подготовка данных (копирование DOM) и анализ данных (обнаружение boilerplate).

Фаза 1: Подготовка данных (DOM Tree Analysis/Copying) (Выполняется в основном потоке UI с квантованием времени)

1. Инициализация копирования: Запуск процесса копирования DOM tree, созданного Layout Engine.
2. Квантование времени (Time Slicing): В течение отведенного временного интервала копируется часть узлов DOM (например, дюжина).
3. Приостановка: По истечении интервала копирование приостанавливается, чтобы основной поток мог обработать другие события пользовательского интерфейса.
4. Возобновление: Процесс повторяет шаги 2-3 до тех пор, пока не будет создана полная копия DOM tree.

Фаза 2: Анализ данных (Boilerplate Detection) (Выполняется в фоновом потоке)

1. Обход дерева: Система итеративно обходит копию DOM tree (например, в глубину или в ширину).
2. Выбор узлов: Выбирается узел или группа узлов (например, узел и его дочерние элементы) для анализа.
3. Применение тестов (Detection Tests): К выбранным узлам применяется набор тестов для разных типов boilerplate (Anchor Block, Anchor List, Footer, Ad). Каждый тест проверяет наличие специфических Predefined Traits.
4. Расчет оценки (Score Calculation): Для каждого типа boilerplate рассчитывается Likelihood Score. Оценка увеличивается в зависимости от степени соответствия признакам.
   • Пример для Anchor Block: +20 за блочный элемент, +20 за соотношение сторон > 3:1, +20 за >5 дочерних элементов, +20 за >80% текста в ссылках.
5. Определение типа (Classification): (Опционально) Если Likelihood Score превышает порог (например, 80), контент классифицируется как boilerplate. Может быть выбран тип с наивысшей оценкой.
6. Корректировка оценки (Score Adjustment): Финальная оценка узла корректируется (повышается как оценка шаблонности).
7. Предоставление информации: Текст узла и его скорректированная оценка передаются в Query Recommendation Engine.

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

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

Система анализирует исключительно структурные, иерархические и визуальные (геометрические) данные, доступные через DOM. Она не анализирует семантику текста.

• Структурные факторы (DOM):
  • Типы элементов (DIV, TABLE, LIST, A, BODY).
  • Атрибуты элементов (например, ALIGN, SHAPE, COORDS, CHILDNODE).
• Иерархические факторы (DOM Hierarchy):
  • Наличие и количество дочерних узлов (Child nodes).
  • Типы дочерних узлов (например, наличие дочерних ссылок).
  • Родительские узлы (например, является ли родителем BODY).
• Визуальные/Геометрические факторы (Layout Data):
  • Размер области (количество пикселей, например, < 400x400px).
  • Форма области (соотношение высоты к ширине, например, > 3:1).
  • Расположение на странице (например, в самом низу страницы).
  • Выравнивание элементов (например, выравнивание ссылок по левому краю).
• Ссылочные факторы (Link characteristics):
  • Процент текста в узле, который является текстом ссылки.
  • (Для рекламы): Целевые хосты ссылок (Target host name).
  • (Для рекламы): Наличие встроенных URL (Embedded URL).
  • (Для рекламы): Ссылки на внешние домены (out-of-domain resources).
  • (Для рекламы): Соответствие URL известным рекламным паттернам (например, Google AdSense).

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

• Likelihood Score (Boilerplate Content Score): Основная метрика. Рассчитывается путем суммирования баллов за соответствие различным Predefined Traits.
• Пороги (Thresholds): Используются для финальной классификации. Если Likelihood Score превышает порог, контент считается шаблонным.
• Метрики признаков: Конкретные числовые значения, используемые в тестах, например:
  • Соотношение сторон (Ratio): > 3:1.
  • Количество дочерних элементов: > 2 (для блоков) или > 3 (для списков).
  • Процент текста в ссылках: > 80%.
  • Размер в пикселях: < 400x400.

1. Структурный анализ для понимания контента: Патент подтверждает, что Google активно использует анализ DOM tree для сегментации страницы. Система способна идентифицировать назначение блоков (навигация, футер, реклама, основной контент) на основе их структуры, иерархии и визуальных характеристик, а не только содержания.
2. Идентификация Boilerplate без сравнения страниц: Описан метод, позволяющий идентифицировать шаблонный контент на одной странице путем анализа её внутренних признаков (Predefined Traits), таких как форма блока, плотность ссылок в нем, его расположение. Это отличается от методов, требующих сравнения множества страниц сайта.
3. Детальная классификация шаблонов: Система не просто ищет boilerplate, она классифицирует его по типам: Anchor Blocks (навигация), Anchor Lists (списки ссылок), Footers, Ads. Каждый тип имеет свой набор диагностических признаков.
4. Цель обнаружения — фильтрация шума: Основная цель, описанная в патенте, — это предотвращение использования boilerplate content для генерации Query Recommendations. Это подразумевает, что контент, классифицированный как boilerplate, значительно понижается в весе или полностью игнорируется при определении основной тематики страницы.
5. Технические аспекты рендеринга: Патент учитывает производительность рендеринга на стороне клиента, предлагая техники Time Slicing и фоновой обработки для анализа DOM без блокировки интерфейса. Это подчеркивает важность скорости и отзывчивости интерфейса.

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

• Используйте чистую и семантическую верстку: Применяйте соответствующие HTML5 теги (<nav>, <header>, <main>, <article>, <footer>, <aside>). Хотя система использует эвристики (Predefined Traits), семантическая верстка помогает четко разграничить блоки, уменьшая вероятность ошибки классификации основного контента как boilerplate.
• Структурируйте навигацию стандартным образом: Навигационные меню должны выглядеть и вести себя как навигация (блочный элемент, высокая плотность ссылок). Это поможет системе корректно идентифицировать их как Anchor Blocks и не учитывать их текст как основной контент страницы.
• Отделяйте основной контент от сквозных блоков: Убедитесь, что блоки с основным контентом имеют достаточно уникального текста и не состоят преимущественно из ссылок. Это защитит основной контент от классификации как Anchor Block или Anchor List.
• Оптимизируйте производительность фронтенда: Учитывая упоминание Time Slicing для анализа DOM, важность быстрой загрузки и рендеринга страницы остается высокой. Сложный и медленный DOM может затруднить анализ структуры.

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

• Использование нестандартной верстки для ключевых элементов: Использование DIV-структур или таблиц для основного контента без четкой семантики увеличивает риск того, что система не сможет корректно отделить Main Content от boilerplate.
• Насыщение основного контента списками сквозных ссылок: Если основной контент содержит длинные списки ссылок, выровненные по левому краю (например, перелинковка, похожая на карту сайта), эти блоки могут быть классифицированы как Anchor Lists и проигнорированы.
• Манипуляции с расположением футера: Попытки скрыть футер или разместить ключевой контент в области, которая структурно и визуально выглядит как футер (в самом низу, родитель BODY), приведет к игнорированию этого контента.
• Избыточная перелинковка в шаблонных блоках: Размещение огромного количества ссылок в навигации или футере в надежде передать вес. Патент показывает, что Google имеет точные механизмы для идентификации таких блоков и, как следствие, может игнорировать или девальвировать ссылки в них.

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

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

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

Сценарий: Оптимизация шаблона новостной статьи для корректного определения Main Content

1. Анализ текущего шаблона: В шаблоне статьи блок "Читайте также" реализован как длинный список из 15 ссылок, выровненных по левому краю, сразу после основного текста статьи.
2. Идентификация риска (по патенту): Этот блок соответствует признакам Anchor List (более 3 ссылок, выравнивание по левому краю). Есть риск, что система классифицирует его как boilerplate и проигнорирует эти ссылки или понизит их вес.
3. Применение Best Practice: Чтобы гарантировать, что перелинковка учитывается, но не мешает определению основного контента:
   • Ограничить количество ссылок в блоке (например, до 5).
   • Использовать более визуально богатый формат (например, карточки с изображениями и сниппетами), чтобы блок не выглядел как простой список ссылок.
   • Разместить блок внутри семантического тега <aside> или четко отделить его от <article>.
4. Ожидаемый результат: Система корректно идентифицирует основной текст статьи, а блок перелинковки не классифицируется как низкокачественный boilerplate.