Как Google использует мобильные Sitemaps для выбора правильного краулера и оптимизации сканирования

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

Agent / Crawler Persona (Агент / Персона Краулера)

Конфигурация краулера, позволяющая ему имитировать определенное устройство или браузер (например, через User-Agent). Используется для получения контента, предназначенного для этого устройства.

Change Frequency (ChangeFreq) (Частота изменений)

Метаданные в Sitemap, указывающие краулеру, как часто предположительно меняется контент по URL. Используется как подсказка для планирования сканирования.

Differential Sitemap (Дифференциальная карта сайта)

Sitemap, содержащий только те URL, которые были добавлены или изменены с момента генерации предыдущего Sitemap.

Document Format Indicator (Индикатор формата документа)

Информация, связанная с Sitemap (переданная при сабмите или указанная внутри файла), которая определяет формат контента (например, XHTML, WML, iMode, PDAHTML).

Format Selector (Селектор формата)

Компонент краулера, который выбирает подходящую персону (Agent) на основе Document Format Indicator.

Last Modification Date (LastMod) (Дата последнего изменения)

Метаданные в Sitemap, указывающие дату/время последнего изменения документа. Используется краулером для определения необходимости повторного сканирования.

Metadata Document / Sitemap (Документ метаданных / Карта сайта)

Файл (часто XML), содержащий список URL сайта и метаданные о них (формат, приоритет, частота обновления).

Per-Site Information (Информация о сайте)

Общие инструкции для краулера, которые могут быть включены в Sitemap Index. Например, предпочтительная скорость сканирования (Crawl Rate) в разное время суток, географическая или языковая принадлежность сайта.

Priority (Приоритет)

Метаданные в Sitemap, указывающие относительную важность URL. Используется краулером для определения очередности сканирования и может влиять на расчет важности страницы (Page Importance Score).

Sitemap Generator (Генератор карты сайта)

Программное обеспечение на стороне веб-сервера, которое автоматически создает Sitemaps путем анализа файловой системы, логов доступа или данных CMS.

Sitemap Index (Индекс карты сайта)

Документ, который содержит ссылки на несколько файлов Sitemap и может содержать Per-Site Information.

URL Scheduler (Планировщик URL)

Компонент поисковой системы, который определяет, какие URL и когда будут сканироваться, используя данные из Sitemaps и внутренние метрики (например, PageRank).

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

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

1. Система получает уведомление о доступности документа метаданных (Sitemap).
2. Система получает индикатор формата документа (document format indicator), связанный с этим Sitemap, который указывает формат хранения контента.
3. Используя этот индикатор, система выбирает краулер, имеющий режим работы (operating mode), способный получить доступ к контенту в указанном формате.
4. Выбранный краулер используется для сканирования документов, перечисленных в Sitemap.

Claim 5 и 6 (Зависимые): Уточняют типы форматов.

Индикатор формата указывает на один или несколько мобильных форматов, таких как XHTML, WML, iMode или HTML.

Claim 7 и 8 (Зависимые): Описывают использование просканированных данных.

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

Claim 9 (Зависимый): Уточняет структуру Sitemap.

Документ метаданных может являться индексом (Sitemap Index), ссылающимся на несколько списков документов (Sitemaps).

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

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

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

Основной этап применения.

1. Обнаружение (Discovery): Система получает уведомления о Sitemaps (Sitemap Notifications) и загружает их с помощью SiteMap Crawler.
2. Выбор Краулера: Format Selector анализирует Document Format Indicator и выбирает нужный Agent (персону краулера) для сканирования URL из этого Sitemap.
3. Планирование (Scheduling): URL Scheduler использует метаданные из Sitemap (Priority, ChangeFreq, LastMod) и внутренние сигналы (PageRank) для определения приоритета и частоты сканирования.
4. Управление нагрузкой: Система может использовать Per-Site Information (например, Crawl Rate) для регулирования скорости запросов к серверу.

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

На этом этапе обрабатывается контент, полученный специализированным краулером.

1. Система может классифицировать контент как мобильный на основе использованного краулера или индикатора формата.
2. Контент может быть помещен в специализированный мобильный индекс или помечен соответствующим образом в общем индексе.
3. Метаданные из Sitemap (например, Priority) могут влиять на расчет важности страницы (Page Importance Score).

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

• Уведомление о Sitemap (URL).
• Document Format Indicator (тип мобильного контента).
• Содержимое файла Sitemap (URL, LastMod, Priority, ChangeFreq).
• Внутренние данные системы (PageRank, история сканирования).

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

• Список приоритизированных URL для сканирования (Sorted & Filtered List of Candidate URLs).
• Просканированный мобильный контент, готовый к индексированию.
• Обновленные данные в индексе с корректной классификацией формата.

На что влияет

• Конкретные типы контента: В первую очередь влияет на контент, специально отформатированный для мобильных устройств (на момент патента: WML, XHTML Mobile Profile, iMode). Это критично для сайтов, использующих отдельные мобильные URL (m-dot) или динамический показ, зависящий от User-Agent.
• Эффективность сканирования: Влияет на распределение краулингового бюджета. Использование LastMod позволяет избегать повторного сканирования неизмененного контента. Использование Priority позволяет фокусировать ресурсы краулера на более важных страницах.

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

• Триггеры активации: Получение уведомления (ping) о новом или обновленном Sitemap. Также система может периодически проверять Sitemaps на основе хранимой информации о частоте обновлений (update rate information).
• Условие выбора краулера: Активируется, когда Sitemap идентифицирован как мобильный (Mobile Sitemap) и указан специфический формат контента, требующий особого краулера (Agent).

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

Процесс А: Обработка и планирование сканирования на основе Sitemap

1. Получение уведомлений: Система принимает и логирует уведомления о Sitemap.
2. Выбор Sitemap для обработки: Система выбирает Sitemap для обработки либо на основе полученного уведомления, либо по расписанию (на основе хранимых данных об обновлении).
3. Загрузка Sitemap: Выбранный Sitemap загружается с веб-сервера.
4. Обновление базы данных: Новая информация из Sitemap (включая метаданные и Per-Site Information) сохраняется в SiteMap Database.
5. Идентификация кандидатов на сканирование: Для каждого URL в Sitemap система определяет, является ли он кандидатом на сканирование. Это делается путем проверки LastMod и истории сканирования (URL Status Information) — проверяется, был ли документ обновлен или вероятно ли его обновление.
6. Расчет оценки (Scoring): Каждому URL-кандидату присваивается оценка. Эта оценка базируется на комбинации PageRank и значения Priority, указанного в Sitemap.
7. Фильтрация (Опционально): Список URL-кандидатов фильтруется на основе бюджетов сканирования (Crawl Budget) и ограничений сайта (Site Constraints, например, максимальное количество запросов в период времени).
8. Планирование загрузки: Отсортированный и отфильтрованный список URL передается в планировщик для последующего сканирования.

Процесс Б: Выбор краулера для мобильного контента

1. Получение индикатора формата: При обработке Sitemap (Процесс А, шаг 4) система идентифицирует Document Format Indicator (например, тег <format>).
2. Выбор агента: Format Selector использует этот индикатор для выбора подходящей персоны краулера (Agent) из репозитория.
3. Сканирование: Когда URL из этого Sitemap выбирается для сканирования (Процесс А, шаг 8), система использует выбранный Agent для выполнения запроса к веб-серверу.

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

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

Патент фокусируется на использовании метаданных из Sitemaps и конфигурационных данных для управления сканированием.

• Контентные/Структурные факторы (Метаданные Sitemap):
  • Формат (<format>): Указывает тип мобильного контента (XHTML, WML). Критичен для выбора краулера.
  • URL (<loc>): Адрес документа.
  • Дата последнего изменения (<lastmod>): Используется для определения новизны контента.
  • Частота изменений (<changefreq>): Подсказка о том, как часто обновляется страница.
  • Приоритет (<priority>): Относительная важность страницы.
  • Заголовок (<title>) и Автор (<author>): Упоминаются как возможные метаданные.
• Технические факторы (Per-Site Information):
  • Crawl Rate (Скорость сканирования): Предпочтительная скорость и время сканирования сайта, указанные вебмастером.
• Поведенческие факторы (Логи доступа): Access Logs могут использоваться генератором Sitemap на стороне сервера для определения популярности документов (popularity information), которая может служить дополнительной подсказкой для приоритизации сканирования.
• Системные данные:
  • PageRank: Внутренняя метрика важности страницы, используется в комбинации с Priority для расчета оценки сканирования.
  • URL Status Information: История сканирования (когда URL последний раз сканировался).

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

• Оценка кандидата на сканирование (Candidate URL Score): Рассчитывается для определения приоритета сканирования. Патент явно указывает, что оценка базируется на PageRank и значении Priority из Sitemap.
• Критерий новизны: Сравнение LastMod из Sitemap с датой последнего сканирования из URL Status Information. Если LastMod новее, документ планируется к сканированию.
• Критерий частоты обновления: Сравнение текущего времени с датой последнего сканирования и ожидаемой частотой обновления (ChangeFreq). Документ планируется, если прошло больше времени, чем указано в ChangeFreq.
• Crawl Budget (Бюджет сканирования): Максимальное количество документов, которое краулер может просканировать за сессию для данного сайта. Используется для фильтрации списка кандидатов.

1. Sitemaps как механизм управления краулером: Патент демонстрирует, что Sitemaps — это не просто список URL, а канал для передачи инструкций краулеру, включая выбор его персоны (User-Agent) и управление приоритетами сканирования.
2. Адаптивное сканирование мобильного контента: Ключевое изобретение — возможность указать формат мобильного контента (Document Format Indicator) и заставить поисковую систему использовать соответствующий краулер (Agent). Это было критично для корректного индексирования не-HTML мобильных форматов и сайтов, использующих User-Agent Sniffing.
3. Приоритизация сканирования (Scoring): Патент явно подтверждает, что приоритет сканирования определяется комбинацией внутренних сигналов (PageRank) и метаданных, предоставленных вебмастером (Priority в Sitemap).
4. Эффективность сканирования и LastMod: Система активно использует LastMod для повышения эффективности, избегая повторного сканирования неизмененного контента. Достоверность LastMod критична.
5. Управление нагрузкой через Sitemap Index: Вебмастера могут предоставлять предпочтения по скорости и времени сканирования (Crawl Rate) через Per-Site Information в Sitemap Index.
6. Инфраструктура обработки: Описана сложная система (URL Scheduler, SiteMap Processing Module), которая обрабатывает Sitemaps, фильтрует URL на основе метаданных, бюджетов и ограничений, прежде чем отправить их на сканирование.

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

• Обеспечение точности LastMod: Критически важно поддерживать актуальность и достоверность даты <lastmod> в Sitemaps. Согласно патенту, это основной механизм для определения необходимости повторного сканирования и экономии краулингового бюджета.
• Использование Sitemap Index для крупных сайтов: Используйте Sitemap Index для структурирования нескольких Sitemaps. Патент также предполагает, что через Sitemap Index можно передавать общие инструкции по сканированию (Per-Site Information).
• Сегментация Sitemaps: Разделяйте контент на разные Sitemaps (например, по типу контента или частоте обновления). Это позволяет более гранулярно управлять метаданными и упрощает мониторинг индексации.
• Сигнализация об обновлениях (Pinging): Используйте механизм уведомлений (ping) при обновлении Sitemaps. Патент описывает инфраструктуру для приема и логирования этих уведомлений для оперативной обработки.
• Корректная настройка мобильных конфигураций (Актуально для раздельных URL): Если используются отдельные мобильные URL (m-dot), необходимо убедиться, что сервер корректно отдает мобильный контент при запросе соответствующим мобильным краулером (User-Agent), как описано в механизме патента.
• Рассмотрение использования Priority (Осторожно): Патент подтверждает, что <priority> используется для расчета оценки сканирования вместе с PageRank. Хотя влияние этого параметра часто оспаривается, патент указывает на его техническое использование в планировщике. Можно использовать его для указания относительной важности страниц внутри сайта.

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

• Манипуляция LastMod: Указание ложной даты <lastmod> (например, установка текущей даты для всех страниц, даже если они не менялись) неэффективно. Хотя это может вызвать сканирование, это тратит краулинговый бюджет впустую и может привести к игнорированию сигнала в будущем.
• Игнорирование ошибок в Sitemaps: Необходимо отслеживать статус обработки Sitemaps (как показано на схемах патента, статус может быть 'Parsing error'). Ошибки могут препятствовать использованию метаданных и обнаружению URL.
• Установка максимального Priority для всех страниц: Установка <priority> 1.0 для всех URL не дает системе информации об относительной важности. Патент упоминает, что краулер может игнорировать или модифицировать значения Priority, если они не соответствуют предопределенным критериям (например, среднему значению).

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

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

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

Сценарий: Оптимизация краулингового бюджета для крупного E-commerce сайта

1. Задача: Ускорить индексацию новых товаров и снизить нагрузку от сканирования старых, неизменных страниц.
2. Действия на основе патента:
   • Реализовать автоматическую генерацию Sitemaps (используя Sitemap Generator).
   • Разделить Sitemaps: один для категорий (обновляется часто), другой для новых товаров (обновляется постоянно), третий для архивных товаров (обновляется редко).
   • Настроить точную передачу <lastmod>. Для архивных товаров указывать реальную дату последнего изменения контента.
   • Для Sitemap с новыми товарами настроить автоматическое уведомление (ping) Google после каждого обновления файла.
   • (Опционально) Установить более высокий <priority> (например, 0.8) для новых товаров и категорий, и низкий (например, 0.3) для архивных товаров.
3. Ожидаемый результат: URL Scheduler использует LastMod и не тратит ресурсы на сканирование архивных товаров. Он использует Priority и PageRank для приоритизации сканирования новых товаров и категорий. Новые товары быстрее попадают в индекс.