Как Google заложил основу протокола Sitemaps для автоматической генерации и уведомления о списках URL

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

Sitemap (Карта сайта)

Документ (часто в формате XML), который перечисляет URL документов на веб-сайте, доступных для сканирования. Включает метаданные для каждого URL.

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

Документ, который перечисляет один или несколько файлов Sitemap. Используется для группировки нескольких файлов.

Sitemap Generator (Генератор Sitemap)

Программный модуль на веб-сервере («клиент»), отвечающий за сбор информации о документах и создание файлов Sitemap и Sitemap Index.

Sitemap Generator Control Parameters (Параметры управления генератором)

Настройки, определяемые вебмастером, которые управляют генерацией Sitemap (например, шаблоны исключения URL, маппинг путей к URL, предпочтительное время сканирования).

URL Record (Запись URL)

Блок информации в файле Sitemap, содержащий конкретный URL и его метаданные (например, lastmod, changefreq, priority, а также опционально title и author).

lastmod (Дата последнего изменения)

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

changefreq (Частота изменения)

Метаданные (Update Rate), указывающие, как часто ожидается изменение контента (например, daily, weekly). Является подсказкой для краулера.

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

Метаданные, указывающие относительный приоритет сканирования документа по сравнению с другими документами на том же сайте (например, от 0.0 до 1.0).

Sitemap Notification (Уведомление о Sitemap)

Сообщение, отправляемое веб-сервером на удаленный компьютер (поисковую систему), информирующее о доступности или обновлении Sitemap («пинг»).

Differential Sitemap (Дифференциальный Sitemap)

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

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

Опциональные данные в Sitemap Index (или Sitemap), применяемые ко всему сайту (например, предпочтительная скорость сканирования crawl_rate, географическое положение location, язык language).

Access Logs (Логи доступа)

Записи о доступе к документам сайта. Используются как источник информации о существующих URL и их популярности (access frequency).

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

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

1. Система получает доступ к источникам информации о документах на веб-сервере.
2. Извлекает информацию о документах, включая метаданные.
3. Генерирует Sitemap, включающий список документов и соответствующие метаданные для каждого из них.
4. Метаданные должны включать как минимум один из следующих элементов: дату изменения документа, частоту доступа к документу, приоритет документа (указывающий приоритет сканирования) или частоту обновления документа.
5. Система сохраняет Sitemap в определенном месте.
6. Система передает уведомление (notification) с веб-сервера на удаленный компьютер (систему веб-краулера), включающее информацию о местоположении Sitemap и указывающее на его доступность.

Claim 3 (Зависимый от 1): Уточняет источники информации. Источники включают как минимум одно из: файловая система, логи доступа (access logs) или списки местоположения документов (document location lists).

Claim 6 (Зависимый от 1): Уточняет состав метаданных. Метаданные включают информацию об относительном приоритете документа (relative priority information).

Claim 7 (Зависимый от 1): Уточняет процесс генерации. Генерация Sitemap включает создание списка документов, измененных после определенного времени (инкрементальное обновление).

Claim 8 (Зависимый от 1): Описывает использование нескольких файлов. Включает генерацию нескольких Sitemaps и генерацию индекса (Sitemap Index), ссылающегося на них. Уведомление идентифицирует этот индекс.

Claim 9 (Зависимый от 1): Описывает генерацию дифференциального списка. Включает определение разницы между текущим и предыдущим Sitemap и генерацию Differential Sitemap на основе этой разницы.

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

Изобретение напрямую связано с этапом сбора данных поисковой системой.

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

Патент описывает механизм, который функционирует на стороне веб-сервера, но его единственная цель — оптимизация работы компонента CRAWLING поисковой системы.

• Взаимодействие с Web Crawler: Система генерирует структурированные данные (Sitemaps), которые используются веб-краулером для обнаружения URL (URL Discovery) и планирования сканирования (Crawl Scheduling).
• Управление бюджетом (Crawl Budget Management): Повышая эффективность сканирования (за счет игнорирования неизмененных страниц с помощью lastmod), система позволяет краулеру сосредоточить ресурсы на новом или обновленном контенте.
• Механизм Push/Pull: Патент описывает как механизм Pull (краулер загружает Sitemap), так и механизм Push (веб-сервер активно уведомляет краулер об обновлении через Sitemap Notification).

Входные данные (на стороне веб-сервера):

• Файловая система сайта (структура директорий, метаданные файлов).
• Логи доступа (Access Logs).
• Данные из базы данных или CMS.
• Sitemap Generator Control Parameters (настройки, заданные вебмастером).

Выходные данные (предоставляемые краулеру):

• Файлы Sitemap (список URL с метаданными lastmod, changefreq, priority).
• Файл Sitemap Index (список файлов Sitemap и опционально Per-Site Information).

На что влияет

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

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

• Условия работы алгоритма: Алгоритм генерации работает на стороне веб-сервера. Он может запускаться по расписанию (например, ежедневно), или при изменении контента (триггер от CMS).
• Триггеры активации: Активация механизма уведомления (Sitemap Notification) происходит сразу после успешной генерации или обновления файла Sitemap.

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

Описание обобщенного процесса генерации Sitemap на стороне веб-сервера.

1. Инициализация и Конфигурация: Загрузка Sitemap Generator Control Parameters. Определение источников данных, шаблонов исключения URL, правил маппинга путей к URL, правил для changefreq и priority, а также URL для уведомления поисковых систем.
2. Сбор данных (Data Acquisition): Система обращается к указанному источнику:
   • Вариант А (Файловая система/БД): Сканирование базы данных или обход дерева директорий. Извлечение URL и даты последнего изменения (lastmod).
   • Вариант Б (Логи доступа): Сканирование Access Logs для поиска URL, которые были успешно запрошены (non-error URLs). Опционально: вычисление информации о популярности на основе частоты доступа.
3. Фильтрация (Filtering): Применение шаблонов исключения (URL exclusion patterns) к собранному списку URL.
4. Обогащение метаданными (Metadata Enrichment): Добавление метаданных к каждому URL:
   • Добавление lastmod (если не было получено ранее, например, при использовании логов).
   • Добавление changefreq и priority на основе предопределенных правил.
   • (Опционально) Добавление других метаданных, таких как title или author.
5. Генерация и Структурирование:
   • Создание одного или нескольких файлов Sitemap.
   • Если сгенерировано несколько файлов, создание файла Sitemap Index. Опционально: добавление Per-Site Information (например, crawl_rate, location, language).
6. (Опционально) Генерация дифференциального списка: Сравнение текущего Sitemap с предыдущей версией для создания Differential Sitemap, содержащего только изменения.
7. Уведомление (Notification): Отправка уведомления (пинга) на указанные URL поисковых систем.

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

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

Система использует данные, доступные на веб-сервере, и конфигурацию, предоставленную вебмастером.

• Технические факторы:
  • URL-структура и Файловые пути: Используются для генерации списка URL (через маппинг) и применения правил фильтрации.
  • Код ответа (из логов): Анализ логов доступа использует коды ответа сервера для идентификации успешных запросов (non-error URLs).
• Временные факторы:
  • Дата последнего изменения (Last Modification Date): Извлекается из метаданных файловой системы или базы данных. Критически важна для заполнения поля lastmod.
• Поведенческие факторы (косвенно):
  • Частота доступа (из логов): Анализ логов может использоваться для определения популярности документа, что может влиять на установку priority.
• Контентные факторы (Опционально):
  • Патент упоминает возможность включения в URL Record заголовка документа (title) и автора (author).
• Географические и Языковые факторы (Опционально):
  • В рамках Per-Site Information может быть указана геолокация сайта (location) и поддерживаемые языки (language).
• Конфигурационные данные (Control Parameters):
  • Шаблоны исключения URL, предопределенные значения метаданных, предпочтительное время и скорость сканирования.

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

Патент фокусируется на генерации и передаче следующих метрик:

• lastmod: Извлекается напрямую из временных меток файловой системы или БД.
• changefreq (Update Rate): Устанавливается на основе правил, заданных вебмастером в конфигурации.
• priority (Relative Priority): Устанавливается на основе правил (диапазон 0.0 до 1.0). Патент явно указывает, что краулер может игнорировать или модифицировать значения приоритета, если они не соответствуют предопределенным критериям (например, требованию, чтобы приоритеты имели предопределенное среднее значение, такое как 0.5).
• Популярность (Popularity information): Опциональная метрика, вычисляемая на основе количества успешных доступов к URL в логах.
• Crawl Rate (Скорость сканирования): Метрика в Per-Site Information, определяющая желаемую нагрузку (например, medium, fast) в определенные временные интервалы.

1. Фундаментальный механизм управления краулингом: Патент описывает основу протокола Sitemaps, который переносит часть ответственности за обнаружение URL с поисковой системы на владельца сайта. Это стандарт де-факто для обеспечения полноты индексации.
2. Автоматизация и источники данных: Ключевая идея патента — автоматическая генерация Sitemaps из первичных источников (файловая система, логи, БД), что обеспечивает актуальность и полноту данных без ручного вмешательства.
3. Важность метаданных для эффективности: Патент подчеркивает роль метаданных как сигналов для планировщика краулера. lastmod является критически важным для избежания повторного сканирования неизмененного контента.
4. Автономность краулера: Метаданные changefreq и priority определены как подсказки (hints). Патент явно указывает, что краулер может их игнорировать, основываясь на собственных данных (например, PageRank) или если они выглядят манипулятивно (например, если средний приоритет не равен 0.5).
5. Механизм уведомления (Push): Защищена идея активного уведомления поисковой системы об обновлении Sitemap («пинг»), что ускоряет реакцию краулера на изменения.
6. Гибкость и масштабируемость: Поддержка Sitemap Index и Differential Sitemaps обеспечивает масштабируемость для очень крупных сайтов и эффективность передачи данных об обновлениях.
7. Управление нагрузкой (Crawl Management): Патент предусматривает возможность передачи Per-Site Information, включая предпочтительное время и скорость сканирования (crawl_rate).

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

• Обеспечить автоматическую генерацию Sitemaps: Внедрить надежные механизмы (плагины CMS или собственные скрипты) для автоматической генерации и обновления Sitemaps. Источником данных должна быть непосредственно база данных или файловая система, чтобы гарантировать точность lastmod.
• Гарантировать полноту и чистоту Sitemap: Убедиться, что все канонические, индексируемые URL (с кодом ответа 200 ОК) включены в Sitemap, а мусорные URL исключены с помощью URL exclusion patterns.
• Использовать точный lastmod: Критически важно передавать корректную дату последнего изменения контента. Это напрямую влияет на решение краулера о необходимости повторного сканирования страницы и оптимизирует краулинговый бюджет.
• Структурировать Sitemaps для масштабируемости: Для крупных сайтов использовать Sitemap Index для разделения URL по типу контента или разделам. Это облегчает диагностику проблем индексации.
• Включать "глубинный" контент: Убедиться, что генератор включает URL, которые могут быть пропущены при стандартном сканировании (например, страницы из базы данных без прямых ссылок).
• (Если поддерживается) Использовать механизм уведомления: Использование механизма «пинга» (Sitemap Notification) при обновлении контента может ускорить обнаружение изменений.

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

• Генерировать Sitemaps вручную или сторонними краулерами: Это противоречит идее патента об использовании первичных источников данных. Сторонние краулеры не имеют доступа к точным датам изменения в базе данных.
• Включать мусорные URL в Sitemap: Добавление неканонических страниц, редиректов или страниц с ошибками тратит краулинговый бюджет и ухудшает качество данных.
• Устанавливать некорректный lastmod: Установка текущей даты для всех страниц при каждой генерации (вместо реальной даты изменения контента) является манипуляцией. Поисковые системы могут начать игнорировать этот сигнал.
• Устанавливать нереалистичный priority: Установка всем страницам приоритета 1.0. Патент указывает, что нереалистичные значения (например, если средний приоритет по сайту значительно отличается от 0.5) могут быть проигнорированы краулером.

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

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

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

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

1. Задача: На сайте миллионы товаров, многие из которых редко меняются, но краулер тратит слишком много ресурсов на их повторное сканирование, игнорируя новые товары.
2. Применение механизма патента:
   • Настраивается автоматический Sitemap Generator, подключенный к базе данных товаров.
   • Генератор создает несколько Sitemaps, сгруппированных по категориям, используя Sitemap Index.
   • Для каждого товара в поле lastmod передается точная дата последнего изменения (цены, описания или наличия) из базы данных.
   • Priority устанавливается на основе маржинальности или популярности товара (используя данные из Access Logs, как предлагает патент), соблюдая принцип относительности.
3. Результат: Краулер, получая Sitemap с точными lastmod, видит, что большинство старых товаров не изменились, и пропускает их сканирование. Освободившиеся ресурсы направляются на сканирование новых товаров и тех страниц, где lastmod обновился. Эффективность краулинга значительно возрастает.