Как Google разработал протокол XML Sitemaps для управления сканированием сайтов

Описание

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

Патент решает фундаментальные ограничения традиционного сканирования, основанного на обнаружении ссылок (discovery-based crawling):

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

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

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

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

Система функционирует следующим образом:

1. Сбор данных: Sitemap Generator сканирует источники информации на сервере, такие как файловая система (для получения списка файлов и дат изменения) или логи доступа (Access Logs) (для идентификации реально используемых URL и их популярности).
2. Обработка и фильтрация: Применяются контрольные параметры (Control Parameters) для исключения нежелательных URL, сопоставления путей файлов с публичными URL и добавления метаданных (частоты обновления changefreq и приоритета priority).
3. Генерация файлов: Создаются файлы Sitemap (например, в формате XML). Для больших сайтов создается Sitemap Index для объединения нескольких файлов.
4. Уведомление: Система автоматически отправляет уведомление (пинг) поисковым системам, сообщая, что новый или обновленный Sitemap доступен для скачивания.

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

Критически высокая. Этот патент (и его предшествующие заявки от 2005 года) описывает основу протокола XML Sitemaps (Sitemaps.org). Этот протокол является фундаментальным отраслевым стандартом для технического SEO и управления сканированием (Crawl Management) с момента его внедрения и по настоящее время (2025 год).

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

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

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

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

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

Записи веб-сервера о доступе к документам. Используются как источник для генерации Sitemap, позволяя идентифицировать существующие URL и оценить их популярность (popularity information).

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

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

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

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

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

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

Discovery-based crawling (Сканирование на основе обнаружения)

Традиционный метод, при котором краулер обнаруживает новые документы, следуя по ссылкам.

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

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

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

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

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

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

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

Документ (часто XML), перечисляющий URL документов сайта, доступных для сканирования, и связанные метаданные.

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

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

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

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

Sitemap Notification (Уведомление о карте сайта)

Механизм (пинг), с помощью которого веб-сервер сообщает краулеру о доступности обновленного Sitemap.

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

Патент содержит несколько независимых пунктов, описывающих метод, систему и носитель информации. Рассмотрим ключевой независимый пункт 1.

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

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

Claim 2-5 (Зависимые): Уточняют состав метаданных в Sitemap.

• Метаданные включают дату изменения документа (lastmod) (Claim 2).
• Метаданные включают частоту доступа к документу (популярность) (Claim 3).
• Метаданные включают информацию о приоритете документа (priority), указывающую приоритет сканирования (Claim 4).
• Метаданные включают информацию о частоте обновления документа (changefreq) (Claim 5).

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

Claim 10 (Зависимый): Описывает механизм масштабирования. Генерируется несколько карт сайта и индекс (Sitemap Index), ссылающийся на них. Уведомление идентифицирует этот индекс.

Claim 11 (Зависимый): Описывает механизм повышения эффективности. Определяется разница между текущей и предыдущей картой сайта, и генерируется дифференциальная карта сайта (Differential Sitemap).

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

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

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

Это основная область применения патента. Описанный механизм является альтернативой или дополнением к стандартному discovery-based crawling.

• Планирование сканирования (Crawl Scheduling): Сгенерированные файлы Sitemap предоставляют краулеру (например, Googlebot) критически важные входные данные для планирования. Метаданные (lastmod, changefreq, priority) используются для определения того, какие URL сканировать, когда и с какой частотой.
• Управление бюджетом (Crawl Budget Management): Предоставляя точные данные о последних изменениях (lastmod), система позволяет краулеру избегать повторного сканирования неизмененного контента, тем самым экономя ресурсы.
• Управление нагрузкой: Per-Site Information может включать запросы на определенную скорость сканирования (crawl rate) в разные промежутки времени.

Взаимодействие компонентов:

• Sitemap Generator работает на веб-сервере и взаимодействует с локальной файловой системой, базами данных и логами доступа.
• Sitemap Notification модуль взаимодействует с удаленным компьютером (поисковой системой) для передачи информации о доступности Sitemap (модель Push).

Входные данные (для генератора):

• Структура файловой системы или базы данных и метаданные файлов (дата изменения).
• Логи доступа веб-сервера (Access Logs).
• Контрольные параметры (правила исключения, правила приоритезации и т.д.).

Выходные данные (для краулера):

• Файлы Sitemap (список URL + метаданные).
• Файл Sitemap Index.
• Уведомление (Ping).

На что влияет

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

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

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

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

Патент описывает два основных варианта генерации Sitemap: на основе логов доступа и на основе сканирования файловой системы/базы данных.

Вариант А: Генерация на основе логов доступа (Access Logs)

1. Доступ к логам: Система получает доступ к логам доступа веб-сервера.
2. Сканирование URL: Логи сканируются для поиска URL, доступ к которым не привел к ошибке (non-error URLs).
3. Генерация списка URL и популярности: Создается список действительных URL. Опционально вычисляется информация о популярности (popularity information) на основе частоты доступа к каждому URL.
4. Фильтрация (Опционально): Список фильтруется с использованием URL exclusion patterns из параметров контроля. Исключенные URL удаляются.
5. Добавление частоты обновления (Опционально): К URL добавляется информация о частоте обновления (changefreq) на основе параметров контроля.
6. Добавление даты изменения: Система обращается к базе данных или файловой системе для получения даты последнего изменения (lastmod) для каждого URL в списке.
7. Формирование Sitemap: Генерируется файл Sitemap с итоговым списком URL и метаданными.

Вариант Б: Генерация на основе файловой системы/базы данных

1. Доступ к хранилищу: Система получает доступ к базе данных или директории файловой системы.
2. Сканирование/Обход: Выполняется сканирование базы данных или обход дерева директорий.
3. Генерация списка URL и дат изменения: Создается список URL (путем маппинга файлов/записей на URL) и извлекаются соответствующие даты последнего изменения (lastmod).
4. Фильтрация (Опционально): Список фильтруется, удаляются исключенные URL.
5. Добавление частоты обновления (Опционально): К URL добавляется информация о частоте обновления (changefreq).
6. Формирование Sitemap: Генерируется файл Sitemap с итоговым списком URL и метаданными.

Общий шаг: Уведомление

После формирования Sitemap (или Sitemap Index) система отправляет Sitemap Notification (пинг) на удаленный компьютер (краулер).

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

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

Патент фокусируется на данных, доступных на стороне веб-сервера для генерации Sitemap.

• Технические факторы:
  • URL и структура: Используются правила маппинга (File Path to URL mapping) для преобразования локальных путей файлов в публичные URL. Структура директорий используется при обходе файловой системы.
  • Код ответа (косвенно): При анализе логов доступа система ищет non-error URLs, что подразумевает анализ кодов ответа в логах.
• Временные факторы:
  • Дата последнего изменения (lastmod): Критически важный фактор. Извлекается из метаданных файловой системы или базы данных.
  • Частота обновления (ожидаемая): Задается владельцем сайта через контрольные параметры (changefreq).
• Поведенческие факторы (Данные сервера):
  • Частота доступа: Анализ Access Logs позволяет определить популярность (popularity information) документов на основе частоты их запросов.
• Контентные факторы (Опционально):
  • Патент упоминает возможность включения в URL record таких метаданных, как title (Заголовок) и author (Автор).

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

• <lastmod>: Извлекается напрямую из метаданных файловой системы или базы данных. Должен соответствовать времени фактического изменения контента.
• <changefreq>: Присваивается на основе правил (Control Parameters), заданных вебмастером. Используется предопределенный набор значений (daily, weekly и т.д.).
• <priority>: Присваивается на основе правил. Указывается как относительное значение (например, от 0.0 до 1.0). Патент отмечает, что краулер может игнорировать эти значения, если они не соответствуют предопределенным критериям (например, если среднее значение приоритетов не равно 0.5).
• Popularity Information (Информация о популярности): Определяется на основе количества доступов к каждому URL в логах доступа. Используется как подсказка для определения приоритета сканирования.
• Crawl Rate (Скорость сканирования): Может быть указана в Sitemap Index как Per-Site Information. Определяет желаемую интенсивность сканирования в разные интервалы времени (например, medium днем, fast ночью).

Выводы

1. Переход от обнаружения к декларированию: Патент фиксирует фундаментальный сдвиг в процессе сканирования. Вместо того чтобы полагаться исключительно на обнаружение ссылок (discovery-based crawling), поисковые системы используют прямые декларативные списки URL, предоставляемые владельцами сайтов.
2. Критичность временных меток (lastmod): Дата последнего изменения является ключевым элементом для повышения эффективности сканирования. Она позволяет краулеру оптимизировать использование краулингового бюджета, избегая повторного сканирования неизмененного контента.
3. Метаданные как подсказки (Hints): Метаданные changefreq и priority определены как подсказки для планировщика сканирования. Патент явно указывает, что краулер может использовать их по своему усмотрению или игнорировать, основываясь на других факторах (например, PageRank) или если данные используются манипулятивно.
4. Гибкость источников генерации: Система предусматривает генерацию Sitemap из разных источников: обход файловой системы (гарантирует полноту) или анализ логов доступа (выявляет реально используемый контент и его популярность).
5. Масштабируемость и эффективность: Использование индексных файлов (Sitemap Index) обеспечивает масштабируемость для больших сайтов. Концепция дифференциальных карт сайта (Differential Sitemap) оптимизирует передачу данных об обновлениях.
6. Управление нагрузкой на сервер: Включение информации на уровне сайта (Per-Site Information) о предпочтительной скорости сканирования (crawl rate) дает владельцам сайтов инструмент для управления нагрузкой, создаваемой краулерами.

Практика

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

• Обеспечить 100% покрытие релевантного контента: Все канонические URL, которые должны быть проиндексированы, должны быть включены в файлы Sitemap. Это гарантирует их обнаружение, даже если внутренняя перелинковка не идеальна.
• Поддерживать абсолютную точность lastmod: Критически важно передавать точную дату и время последнего значимого изменения контента в теге <lastmod>. Это напрямую влияет на эффективность использования краулингового бюджета и скорость переиндексации.
• Использовать автоматическую генерацию: Внедрить системы автоматической генерации Sitemap (используя методы, описанные в патенте: обход БД или файловой системы), чтобы поддерживать актуальность данных.
• Сегментировать Sitemap и использовать индексный файл: Для крупных сайтов необходимо разделять URL на несколько файлов Sitemap и объединять их с помощью Sitemap Index. Это соответствует описанному в патенте механизму масштабирования.
• Использовать механизм уведомления (Pinging): После обновления файлов Sitemap следует использовать механизм Sitemap Notification (отправка пинга поисковой системе) для информирования о доступности новой версии, как это предусмотрено патентом.
• Рассмотреть генерацию на основе логов (Продвинутая тактика): Для очень больших сайтов можно использовать анализ логов доступа (как описано в патенте) для создания отдельных Sitemap с наиболее популярными страницами или для выявления пробелов в покрытии.

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

• Включать неканонические URL и мусор: Добавление в Sitemap URL с кодами ответа 4xx/5xx, редиректов (3xx), неканонических версий или страниц, закрытых от индексации, снижает эффективность протокола и тратит ресурсы краулера.
• Манипулировать lastmod: Установка фиктивной даты последнего изменения (например, текущей даты для всех страниц при каждой генерации) контрпродуктивна. Это лишает краулер возможности определить реально измененный контент.
• Злоупотреблять priority и changefreq: Установка максимального приоритета (1.0) и частоты обновления (hourly/daily) для всех страниц неэффективна. Патент прямо указывает, что краулер может игнорировать эти подсказки, особенно если они используются для манипуляций.
• Вести Sitemaps вручную: Для любых сайтов, кроме самых маленьких, ручное обновление неэффективно и чревато ошибками, в отличие от автоматизированного подхода, описанного в патенте.

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

Этот патент является фундаментом современного управления сканированием (Crawl Management). Он подтверждает, что предоставление точной и структурированной информации о контенте является приоритетом для эффективного взаимодействия с поисковыми системами. Стратегически важно рассматривать Sitemaps не просто как список URL, а как критически важный компонент инфраструктуры сайта, обеспечивающий оптимизацию краулингового бюджета, ускорение индексации и полноту представления сайта в поиске.

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

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

1. Проблема: Сайт имеет 5 миллионов товарных страниц, краулинговый бюджет ограничен. Многие новые товары долго не попадают в индекс.
2. Применение патента: Внедрение генерации Sitemap на основе базы данных с фокусом на точности lastmod и использованием Differential Sitemap.
3. Действия:
   • Настроить генератор так, чтобы lastmod обновлялся только при изменении критически важной информации (цена, наличие, описание).
   • Сегментировать Sitemap по категориям товаров, используя Sitemap Index.
   • Внедрить генерацию ежечасных Differential Sitemap, содержащих только новые или измененные товары.
   • Настроить Sitemap Notification (пинг) после генерации дифференциального файла.
4. Ожидаемый результат: Googlebot, получая точные данные об изменениях, перестает тратить бюджет на сканирование неизмененных страниц. Ресурсы перераспределяются на сканирование нового и обновленного контента, ускоряя его индексацию.

Сценарий 2: Использование логов для генерации Sitemap

1. Задача: Обеспечить индексацию важных страниц на сложном сайте, где стандартный генератор CMS пропускает часть контента.
2. Применение патента: Использование Access Logs как источника данных.
3. Действия:
   • Настроить Sitemap Generator на анализ логов доступа.
   • Извлечь все успешные (non-error) URL, посещаемые пользователями.
   • Отфильтровать служебные URL с помощью exclusion patterns.
   • Определить популярность URL по частоте доступа и использовать это для расчета <priority>.
   • Сгенерировать отдельный Sitemap на основе этих данных.
4. Ожидаемый результат: Обнаружение и индексация страниц, которые реально востребованы пользователями, но могли быть пропущены при стандартном обходе сайта или генерации из БД.

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