Как Google предлагает использовать номера версий контента для управления <lastmod> в Sitemap и обеспечивать свежесть индекса

Описание

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

Патент решает проблему обеспечения свежести поискового индекса (Index Freshness) для контента, у которого отсутствует доступная метка времени последнего изменения (Last Modified Time). Поисковые системы используют эту метку для определения необходимости повторного сканирования. Если контент хранится в базе данных (Content Database) — например, изображения на фотохостинге или товары в E-commerce — стандартные временные метки файлов могут быть недоступны или ненадежны. Это приводит к тому, что обновленный контент несвоевременно попадает в индекс и кэш (Item Cache) поисковой системы.

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

Запатентована система и метод использования номеров версий (Version Numbers) в качестве индикатора изменения контента, когда реальное время изменения недоступно. Генератор Sitemap сравнивает текущий номер версии элемента с номером, зафиксированным при предыдущей генерации Sitemap. При обнаружении изменений система искусственно устанавливает в поле <lastmod> файла Sitemap свежую дату (например, текущее системное время). Это сигнализирует поисковой системе о необходимости обновить индекс для данного элемента.

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

Механизм работает на стороне веб-сайта в процессе генерации Sitemap:

• Хранение истории версий: Sitemaps Generator сохраняет список номеров версий контента на момент последней генерации.
• Сравнение версий: Во время генерации нового Sitemap система считывает текущий номер версии каждого элемента и сравнивает его с сохраненным значением.
• Обнаружение изменений: Если текущий номер версии отличается от сохраненного или элемент новый.
• Манипуляция <lastmod>: Для этого элемента устанавливается время последнего изменения (<lastmod>), которое гарантированно позже времени предыдущей генерации (например, текущее системное время).
• Реакция поисковой системы: Получив Sitemap, поисковая система видит свежую дату <lastmod> и направляет краулер для обновления своего индекса и кэша.

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

Высокая. Оптимизация краулингового бюджета (Crawl Budget Optimization) и обеспечение свежести индекса остаются критически важными задачами, особенно для крупных динамических сайтов (E-commerce, UGC-платформы, медиа-ресурсы). Этот патент описывает конкретное техническое решение для эффективного управления сканированием контента, не предоставляющего стандартные временные метки.

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

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

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

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

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

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

Crawler (Краулер, Сетевой робот)

Приложение поисковой системы (например, Googlebot), которое сканирует сеть для обнаружения и индексации контента.

Index (Индекс)

База данных поисковой системы, содержащая информацию об элементах, найденных в сети.

Item Cache (Кэш элементов)

Репозиторий поисковой системы, хранящий копии элементов (например, веб-страниц или изображений) в том виде, в котором они были считаны во время последнего сканирования.

Last Modified Time (Время последнего изменения, <lastmod>)

Метка времени. В контексте патента относится к значению тега <lastmod> в Sitemap. Используется поисковой системой для принятия решения о повторном сканировании.

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

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

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

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

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

Идентификатор или счетчик, связанный с элементом контента, который обновляется при его изменении. Используется как индикатор изменения, когда Last Modified Time недоступно. В патенте различаются Current Version Number (текущий) и Previously Stored Version Number (сохраненный).

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

Патент содержит системные утверждения (System Claims), описывающие как генератор Sitemap, так и взаимодействие с поисковой системой.

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

Часть А (Генератор Sitemap):

1. Система определяет наличие ранее сохраненного номера версии (previously stored version number) для файла.
2. Сравнивается текущий номер версии файла (current version number) с ранее сохраненным.
3. Если номер версии изменился, генерируется Sitemap с записью для этого файла.
4. Этой записи присваивается новое время последнего изменения (new last modified time) в качестве значения last modified time value, при условии, что фактическое время изменения файла недоступно (actual last modified time… is not available).

Часть Б (Поисковая система):

1. Поисковая система получает этот Sitemap.
2. Определяет, что запись была проиндексирована ранее, в момент времени, предшествующий указанному last modified time value.
3. В ответ на это, поисковая система получает доступ к информации о файле и генерирует обновленный индекс (updated index).

Ядром изобретения является использование сравнения номеров версий как триггера для принудительной установки нового Last Modified Time с целью инициации повторного сканирования.

Claim 6 (Независимый пункт): Фокусируется на процессе со стороны поисковой системы, принимающей Sitemap, сгенерированный описанным методом.

1. Система получает Sitemap с записью о ресурсе. Запись содержит last modified time и была сгенерирована в ответ на определение того, что текущий номер версии ресурса изменился по сравнению с предыдущим.
2. Система определяет, что запись была проиндексирована ранее, до указанного last modified time value.
3. Система получает доступ к информации о ресурсе и генерирует обновленный индекс.

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

Изобретение применяется на стыке инфраструктуры веб-сайта и процессов сканирования поисковой системы.

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

INDEXING – Индексирование и извлечение признаков
Механизм гарантирует, что контент, поступающий в конвейер индексирования, является актуальным. Это предотвращает ситуацию, когда в индексе (Index) и кэше (Item Cache) хранятся устаревшие версии контента.

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

• Content Database (на стороне сайта) хранит контент и обновляет Version Number при изменениях.
• Sitemaps Generator (на стороне сайта) считывает данные из Content Database, сравнивает версии и генерирует файл Sitemap.
• Network Crawler (поисковая система) считывает Sitemap и планирует сканирование на основе <lastmod>.
• Index Generator (поисковая система) обрабатывает свежий контент и обновляет Index и Item Cache.

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

• Текущие номера версий (Current Version Numbers) для элементов контента.
• Сохраненный список номеров версий с момента последней генерации Sitemap (Stored Version Numbers).
• Текущее системное время (для использования в качестве нового <lastmod>).

Выходные данные (от Sitemaps Generator):

• Файл Sitemap (XML) с записями для измененных элементов, содержащий искусственно установленные значения <lastmod>.

На что влияет

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

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

• Условия работы: Алгоритм применяется во время плановой или инициированной вручную генерации файла Sitemap.
• Триггеры активации: Активируется для конкретного элемента контента, если выполнены два условия:
  1. Фактическое время последнего изменения (Last Modified Time) недоступно или ненадежно.
  2. Текущий номер версии элемента отличается от номера версии, зафиксированного во время предыдущей генерации Sitemap (или если элемент новый).
• Необходимые условия: Система управления контентом должна поддерживать и последовательно обновлять Version Number для элементов при их изменении.

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

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

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

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

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

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

• Технические факторы / Метаданные:
  • Version Number (Номер версии): Критически важные данные. Источник этих данных — внутренняя логика CMS или базы данных, которая обновляет это значение при модификации контента.
  • URL или Идентификатор элемента: Используется как уникальный ключ (Table Key) для сопоставления текущих элементов с сохраненной историей версий.
• Временные факторы:
  • Current System Time (Текущее системное время): Используется для генерации нового значения <lastmod>, если обнаружено изменение версии.

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

В патенте используются простые логические операции и установка времени.

• Сравнение версий (Обнаружение изменений): Используется простая проверка на неравенство: (Current Version Number != Stored Version Number).
• Определение новизны: Проверка наличия идентификатора элемента в списке сохраненных версий.
• Установка времени (New Last Modified Time): Значение <lastmod> устанавливается равным Current System Time или дате, основанной на текущем системном времени. Оно должно быть позже времени предыдущей генерации Sitemap.

Выводы

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

Практика

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

• Внедрение контроля изменений для динамического контента: Для сайтов, где контент хранится в БД (товары, объявления, изображения, профили), необходимо реализовать механизм автоматического обновления индикатора изменений при любой модификации элемента. Это может быть номер версии (как в патенте), хэш контента или надежное поле updated_at в базе данных.
• Интеграция индикаторов изменений с генератором Sitemap: Необходимо настроить генератор Sitemap так, чтобы он использовал эти индикаторы для установки <lastmod>. Если используется версионирование (или хэширование), генератор должен сравнивать текущее состояние с предыдущим и принудительно устанавливать <lastmod> на текущее время при обнаружении изменений.
• Обеспечение точности <lastmod>: Главная цель — предоставить Google точный сигнал о том, что контент действительно изменился. Если надежные временные метки (updated_at) доступны, следует использовать их. Если нет — использовать метод версионирования или хэширования.
• Регулярная генерация Sitemap: Для того чтобы метод был эффективным, файлы Sitemap должны генерироваться достаточно часто, чтобы своевременно отражать изменения в контенте (например, ежедневно или чаще для высокодинамичных сайтов).

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

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

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

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

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

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

1. Ситуация: Крупный интернет-магазин хранит информацию о товарах в базе данных. Цены и статус наличия обновляются несколько раз в день через ERP. Стандартные метки времени изменения недоступны.
2. Проблема: Стандартный генератор Sitemap не видит изменений в БД и указывает старые даты <lastmod>. Googlebot редко переобходит карточки товаров, в индексе отображаются неверные цены.
3. Реализация по патенту (Вариант А — Счетчик версий):
   • Разработчики добавляют поле version_counter в таблицу товаров в БД.
   • При любом обновлении товара (цена, наличие, описание) значение version_counter увеличивается на 1.
   • Генератор Sitemap модифицируется: он сохраняет version_counter после каждой генерации. При следующем запуске он сравнивает текущий счетчик с сохраненным. Если они отличаются, <lastmod> устанавливается на текущее время.
4. Реализация по патенту (Вариант Б — Хэш контента):
   • Если счетчик версий недоступен, разработчики реализуют функцию, которая вычисляет хэш (например, MD5) от всех значимых полей товара (цена, наличие, описание, URL фото).
   • Генератор Sitemap сохраняет этот хэш после каждой генерации. При следующем запуске он вычисляет текущий хэш и сравнивает его с сохраненным. Если они отличаются, <lastmod> устанавливается на текущее время.
5. Результат: Google получает Sitemap, видит обновленную дату и быстро переиндексирует карточку товара с актуальной ценой и статусом наличия.

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