Как Google предлагает использовать номера версий контента для генерации в Sitemap, если реальная дата изменения недоступна

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

Actual Last Modified Time (Фактическое время последнего изменения)

Реальное время изменения контента. Патент применяется, когда эта информация недоступна.

Content Database (База данных контента)

Хранилище контента сайта (тексты, изображения, видео), доступ к которому осуществляется через СУБД, а не файловую систему.

Current Version Number (Текущий номер версии)

Актуальный идентификатор версии элемента контента на момент генерации Sitemap.

Historical List / Stored Version Number (Исторический список / Сохраненный номер версии)

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

Last Modified Time (<lastmod>)

Значение в файле Sitemap (тег <lastmod>), указывающее краулеру дату изменения. В данном патенте это значение устанавливается искусственно на основе изменения версии.

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

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

Version Number (Номер версии)

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

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

Claim 8 (Независимый пункт, Метод): Описывает основной процесс обработки отдельного элемента контента.

1. Считывается текущий номер версии (current version number) элемента контента.
2. Определяется наличие ранее сохраненного номера версии (previously stored version number).
3. Текущий номер сравнивается с сохраненным.
4. Если номера различаются, система устанавливает Last Modified Time в записи Sitemap для этого элемента на время, более позднее, чем время генерации последнего Sitemap.
5. Ключевое условие: этот метод применяется, когда фактическое время изменения контента недоступно (actual last modified time... is not available).

Claim 17 (Независимый пункт, Метод): Описывает процесс пакетной обработки через сравнение списков.

1. Генерируется текущий список (current list) номеров версий контента из базы данных.
2. Этот список сравнивается с историческим списком (historical list).
3. Для элементов, чьи номера версий отличаются, устанавливается Last Modified Time в Sitemap на время, более позднее, чем время генерации последнего Sitemap.
4. Условие применения аналогично: когда фактическое время изменения недоступно.

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

1. Наличие базы данных для хранения файлов и их номеров версий.
2. Наличие Sitemap Generator, который сравнивает текущий номер версии с ранее сохраненным.
3. Генератор создает Sitemap, где значение Last Modified Time основано на результате сравнения, при условии, что фактическое время изменения недоступно.

Зависимые пункты (например, Claims 11, 12, 14): Уточняют детали реализации и контекст:

• В качестве нового Last Modified Time может использоваться текущее системное время (Claim 14).
• Метод применим к сайтам обмена фотографиями (photograph sharing website), где инструменты редактирования обновляют номер версии изображения (Claims 11, 12).

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

Изобретение описывает механизм, реализуемый на инфраструктуре веб-сайта (Sitemap Generator) для управления поведением поисковой системы.

CRAWLING – Сканирование и Сбор данных
Это основная фаза, на которую влияет изобретение. Сгенерированный Sitemap с точно рассчитанными значениями <lastmod> напрямую управляет планированием сканирования (Crawl Scheduling). Предоставление актуальной даты изменения позволяет Network Crawler оптимизировать ресурсы и приоритизировать сканирование обновленного контента, даже если стандартные сигналы (например, HTTP-заголовок Last-Modified) недоступны.

INDEXING – Индексирование и извлечение признаков
Обеспечивая своевременное повторное сканирование, механизм гарантирует, что в индекс (Index) и кеш (Item Cache) попадает самая свежая версия контента, поддерживая актуальность данных для ранжирования.

Входные данные (для Sitemap Generator):

• Элементы контента из Content Database.
• Текущие номера версий (Current Version Numbers) этих элементов.
• Исторический список номеров версий (Historical List) с момента последней генерации.
• Текущее системное время.

Выходные данные (для Network Crawler):

• Файл Sitemap с URL (<loc>) и временем последнего изменения (<lastmod>). Для измененного контента <lastmod> будет содержать искусственно установленное свежее время.

На что влияет

• Конкретные типы контента: Наибольшее влияние на контент, управляемый базами данных, где временные метки файловой системы нерелевантны. Это включает изображения и видео на хостингах, товары в E-commerce, профили пользователей, UGC.
• Конкретные ниши или тематики: Критично для фотобанков, видеохостингов, крупных интернет-магазинов и агрегаторов. В патенте явно упоминаются сайты обмена фотографиями (photograph sharing website).

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

• Условие активации: Генерация файла Sitemap для контента, у которого недоступно или ненадежно фактическое время последнего изменения (actual last modified time).
• Необходимые данные: Наличие системы версионирования контента на стороне сайта, при которой изменение контента приводит к обновлению его version number.
• Частота применения: Каждый раз при генерации файла Sitemap.

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

Процесс генерации Sitemap с использованием номеров версий:

1. Инициализация: Запуск процесса генерации Sitemap. Загрузка исторического списка номеров версий (Historical List).
2. Чтение элемента и текущей версии: Считывание элемента контента и его текущего номера версии (Current Version Number) из базы данных.
3. Сравнение версий: Сравнение текущего номера версии с номером версии этого же элемента в историческом списке.
4. Проверка изменений: Определение, изменился ли номер версии или элемент является новым (отсутствует в историческом списке).
   • Если ДА (изменение или новый элемент): Переход к шагу 5.
   • Если НЕТ (изменений нет): Переход к шагу 6.
5. Установка времени изменения: Установка значения <lastmod> для этого элемента на время, которое позже времени предыдущей генерации Sitemap (например, текущее системное время).
6. Формирование записи Sitemap: Создание записи в Sitemap с URL элемента и установленным значением <lastmod> (либо свежим из шага 5, либо историческим, если изменений не было).
7. Обновление исторического списка (в процессе или по завершении): Сохранение текущего номера версии в новом историческом списке для будущего использования.
8. Итерация: Переход к следующему элементу контента и возврат к шагу 2.
9. Завершение: Сохранение файла Sitemap и предоставление его поисковой системе.

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

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

Патент фокусируется исключительно на данных, необходимых для определения факта изменения контента.

• Технические факторы / Данные из БД:
  • Version Number: Ключевой фактор. Индикатор, который должен обновляться при любом изменении контента.
  • Идентификаторы элементов (Keys/ID) или URL: Используются для сопоставления элементов в текущем и историческом списках.
• Мультимедиа факторы: В патенте упоминается применение к изображениям (image files), аудио, видео и текстовым файлам.

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

Система не вычисляет сложные метрики, а использует прямое сравнение и системные данные.

• Сравнение версий: Прямое сравнение на равенство/неравенство между Current Version Number и Stored Version Number.
• Текущее системное время: Используется для установки нового значения <lastmod> при обнаружении изменений. Указывается, что можно использовать текущее время или текущий день.

1. Приоритет точности сигналов для краулинга: Патент подтверждает критическую важность тега <lastmod> в Sitemap для управления поведением краулера и оптимизации краулингового бюджета.
2. Версионирование как валидированная альтернатива датам: Google признает ограничения инфраструктуры (отсутствие надежных временных меток) и предлагает использование внутренних номеров версий как надежный резервный механизм (fallback) для определения изменений.
3. Ответственность на стороне сайта: Реализация этого механизма (отслеживание версий и генерация Sitemap) лежит на владельце сайта или разработчиках CMS. Вебмастер несет ответственность за предоставление точных сигналов об обновлениях.
4. Искусственное обновление времени допустимо: Патент описывает механизм, при котором <lastmod> устанавливается искусственно (на текущее время), если обнаружено изменение версии. Это допустимая практика, если она точно отражает факт обновления контента.
5. Критичность для динамического контента: Метод необходим для обеспечения актуальности индексации для E-commerce, медиа-хостингов и UGC-платформ, управляемых базами данных.

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

• Аудит точности временных меток: Проверьте, насколько точно ваша CMS/сервер отдает HTTP-заголовок Last-Modified и заполняет <lastmod> в Sitemap. Они должны соответствовать времени значимого изменения контента.
• Внедрение версионирования (если необходимо): Если инфраструктура не может надежно предоставлять точное время изменения (особенно для контента в БД), необходимо внедрить систему отслеживания версий (счетчик изменений или хеш-сумма контента) для всего индексируемого контента.
• Адаптация генератора Sitemap: Убедитесь, что генератор Sitemap использует логику из патента: сравнивает текущую версию/хеш с исторической и обновляет <lastmod> только при наличии изменений.
• Тщательная проверка точности: Убедитесь, что <lastmod> (и номер версии) обновляется только при значимых изменениях контента, а не при технических или незначительных правках.

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

• Игнорирование <lastmod> для динамического контента: Отсутствие актуальной информации в <lastmod> приведет к замедлению обнаружения изменений и устареванию индекса.
• Ложное обновление <lastmod> (Crawl Budget Waste): Установка текущей даты для всего контента при каждой генерации Sitemap, независимо от того, менялся ли контент (и его версия). Это приводит к массовому повторному сканированию неизмененных страниц и может привести к игнорированию сигналов из Sitemap.
• Непоследовательное версионирование: Если система версионирования работает некорректно (например, номер версии не обновляется при изменении контента), описанный механизм будет бесполезен.

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

Патент подтверждает стратегическую важность файлов Sitemap как надежного канала коммуникации для управления сканированием. Он подчеркивает, что SEO-стратегия должна включать обеспечение технической инфраструктуры, способной точно сигнализировать об изменениях контента. Для современных веб-приложений, часто использующих сложные базы данных, реализация альтернативных методов отслеживания изменений является необходимостью для обеспечения конкурентоспособности в поиске.

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

Сценарий: Обеспечение актуальности карточек товаров в E-commerce на самописной CMS

Интернет-магазин хранит товары в базе данных. Цены и наличие часто меняются, но CMS не обновляет метки времени Last-Modified.

1. Реализация версионирования: В базу данных добавляется поле content_hash. При любом изменении товара (цена, описание, наличие) рассчитывается новый хеш контента и сохраняется в этом поле.
2. Настройка генератора Sitemap: Разрабатывается скрипт генерации Sitemap. При запуске он сохраняет текущее состояние хешей в лог-файл (Historical List).
3. Процесс генерации: При следующей генерации скрипт сравнивает текущий content_hash в БД со значением в лог-файле.
4. Обновление <lastmod>: Если хеши отличаются, скрипт устанавливает в теге <lastmod> для этого товара текущую дату и время. Если хеши равны, дата <lastmod> остается прежней.
5. Результат: Google получает Sitemap, видит свежую дату <lastmod> только для измененных товаров и оперативно ставит их в очередь на пересканирование.