Как Google использует свой индекс для автоматического обновления устаревших ссылок в закладках, истории поиска и на веб-страницах

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

Add-on Application (Дополнительное приложение)

Программное обеспечение (например, плагин, тулбар или встроенная функция браузера), которое может перехватывать ошибки доступа к URI, запрашивать канонические URI и выполнять перенаправление в реальном времени.

Backlinks (Обратные ссылки)

Информация в Document Index о том, какие документы ссылаются на данный ресурс. Используется для поиска страниц, содержащих устаревшие исходящие URI.

Canonical URI (Канонический URI)

Наиболее актуальная и предпочтительная версия URI для доступа к ресурсу, хранящаяся в Document Index. Может отличаться от сохраненного URI из-за перемещения ресурса или удаления ненужных параметров (например, идентификаторов сессий).

Crawler (Краулер)

Компонент поисковой системы, который просматривает документы в интернете и определяет актуальные URI. Он обнаруживает изменения URI, например, через HTTP-редиректы (301/302), мета-обновления или анализ текста на странице.

Document Index (Индекс документов)

Эталонная база данных (например, основной индекс Google). Хранит Canonical URI ресурса, другие (включая устаревшие) URI этого ресурса (Other URIs) и информацию об обратных ссылках (Backlinks).

Outdated URI (Устаревший URI)

URI, который больше не является каноническим или не позволяет получить доступ к ресурсу (неработающая ссылка).

URI Collection (Коллекция URI)

Любое хранилище ссылок. Примеры: закладки, история поиска, история браузера, ссылки в электронных письмах, SMS, сообщениях на форумах или ссылки на веб-странице.

URI Updates Publisher Server (Сервер публикации обновлений URI)

Сервер-посредник, который получает список недавно измененных URI из Document Index и рассылает обновления подписчикам (например, серверам закладок). Также может отвечать за уведомление владельцев контента о битых ссылках.

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

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

1. Система получает сохраненный URI из URI collection.
2. Система обращается к Document Index, который хранит информацию о канонических URI.
3. Определяется, отличается ли Canonical URI для данного ресурса от сохраненного URI.
4. Если отличается, система заменяет сохраненный URI в коллекции на Canonical URI.

Claim 2 (Зависимый от 1): Описывает механизм оптимизации для больших коллекций.

1. Генерируется список уникальных URI из коллекции.
2. Проверка каноничности выполняется для этого уникального списка.
3. После определения Canonical URI, система заменяет каждое вхождение (each instance) устаревшего URI в исходной коллекции на канонический. (Например, если 100 пользователей добавили одну ссылку в закладки, она проверяется один раз, а обновляется у всех).

Claims 3-7 (Зависимые от 1): Уточняют типы коллекций, к которым применим метод: закладки (3), история поиска (4), сообщения (email/SMS) (5), дискуссионные группы/форумы (6), URI, включенные в документ (веб-страницу) (7).

Claim 9 (Независимый пункт): Описывает модель публикации/подписки (Push Model) с точки зрения издателя (URI Updates Publisher Server).

1. Система получает из Document Index список Canonical URIs, которые изменились с определенного момента времени.
2. Получает связанные с ними устаревшие URI.
3. Генерирует обновление URI (URI update).
4. Предоставляет это обновление подписчикам для замены устаревших URI.

Claim 12 (Зависимый от 9): Описывает механизм уведомления владельцев сайтов.

1. Идентифицируется документ, который содержит устаревший URI.
2. Получается контактный адрес менеджера контента этого документа.
3. Отправляется уведомление об устаревшем URI на этот адрес. (Claim 14 уточняет, что уведомление включает новый Canonical URI).

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

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

CRAWLING – Сканирование и Сбор данных
Crawler обнаруживает изменения URI во время сканирования контента. Это происходит путем обнаружения кодов редиректов (HTTP 301 или 302), мета-тегов обновления (refresh redirect) или анализа текста документа (например, "эта страница перемещена").

INDEXING – Индексирование и извлечение признаков
Это ключевой этап. Document Index обновляется на основе данных краулера и служит источником истины. Для ресурса сохраняется новый Canonical URI, старый URI помечается как альтернативный (Other URIs), также сохраняется информация об обратных ссылках (Backlinks).

Применение вне основного поискового конвейера (Инфраструктура и Экосистема)
Основная логика патента реализуется здесь:

• Серверы коллекций (Bookmark/History/Mail Servers): Используют данные из Document Index (напрямую или через подписку) для обновления пользовательских данных.
• Клиентские устройства (Браузеры): Используют Add-on Application для исправления ссылок в реальном времени при возникновении ошибок доступа.
• URI Updates Publisher Server: Действует как посредник и система уведомлений. Он использует данные Backlinks из индекса, чтобы найти страницы с битыми ссылками и уведомить их владельцев.

На что влияет

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

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

• Периодически/По расписанию: Проактивное обновление коллекций и публикация обновлений выполняются периодически (например, проверка изменений с момента последней проверки).
• Реактивно (В реальном времени): Активируется в момент, когда пользователь пытается получить доступ к ресурсу по устаревшему URI и получает ошибку (при использовании клиентского приложения).
• При обнаружении изменений: Когда Crawler обновляет Document Index, это может служить триггером для генерации обновлений.

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

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

Процесс А: Проактивное обновление коллекции URI (Pull Model)

1. Генерация списка (Оптимизация): Сервер коллекции генерирует список уникальных URI из своей базы данных.
2. Извлечение URI: Система извлекает URI из списка уникальных URI.
3. Запрос к индексу: Система запрашивает Document Index для получения соответствующего Canonical URI.
4. Сравнение: Система сравнивает извлеченный URI и полученный Canonical URI.
5. Распространение обновлений: Если URI отличаются, система находит все вхождения устаревшего URI в основной коллекции (например, в аккаунтах разных пользователей) и заменяет их на Canonical URI.

Процесс Б: Публикация и подписка на обновления (Push Model)

1. Мониторинг индекса (Publisher): URI Updates Publisher Server периодически проверяет Document Index на наличие URI, которые изменились с момента последней проверки.
2. Генерация обновления (Publisher): Создается список обновлений, содержащий пары (Устаревший URI, Канонический URI).
3. Рассылка (Publisher): Обновление рассылается всем подписчикам.
4. Применение обновления (Subscriber): Сервер коллекции (подписчик) получает список и заменяет устаревшие URI в своей базе данных на канонические.

Процесс В: Коррекция в реальном времени (Add-on)

1. Обнаружение ошибки: Пользователь пытается получить доступ к ресурсу по URI, и браузер не может получить доступ (например, ошибка 404).
2. Перехват: Add-on Application перехватывает ошибку.
3. Запрос к индексу: Приложение запрашивает Canonical URI у Document Index.
4. Перенаправление: Если Canonical URI найден, приложение перенаправляет браузер на этот адрес, минуя показ ошибки пользователю.
5. Локальное обновление (Опционально): Если устаревший URI был сохранен локально (например, в закладках), он обновляется.

Процесс Г: Уведомление владельцев контента

1. Обнаружение устаревшего URI: Система идентифицирует устаревший URI (например, во время Процесса Б).
2. Поиск ссылающихся документов: Система запрашивает Document Index для получения Backlinks, чтобы найти документы, содержащие этот устаревший URI.
3. Идентификация владельца: Система определяет владельца или менеджера контента ссылающегося документа (например, путем поиска контактной информации на домене).
4. Уведомление: Система отправляет уведомление владельцу, сообщая об устаревшей ссылке и предлагая Canonical URI для замены.

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

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

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

• Технические факторы:
  • Коды ответа сервера: HTTP 301/302 используются краулером для обнаружения изменений. HTTP 404 (и другие ошибки) используются Add-on Application для реактивного обнаружения устаревших URI.
  • Мета-теги: Краулер может использовать refresh redirect (мета-обновление) для обнаружения изменений.
• Структурные данные (Индекс): Document Index хранит структурированные записи: Canonical URI, Other URIs (устаревшие/альтернативные) и Backlinks.
• Ссылочные факторы:
  • Backlinks: Данные об обратных ссылках критически важны для Процесса Г (идентификация документов с устаревшими исходящими ссылками).
• Контентные факторы:
  • Текст документа: Краулер может анализировать текст (например, "страница перемещена") для обнаружения изменений URI.
  • Контактная информация: Система ищет контактные данные на сайтах для отправки уведомлений владельцам контента (Процесс Г).
• Пользовательские данные: Сохраненные URI в коллекциях (закладки, история и т.д.).

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

Патент не описывает сложных метрик, оценок или алгоритмов машинного обучения. Основные механизмы основаны на сравнении строк и управлении базами данных:

• Сравнение URI: Основная операция — определение того, отличается ли сохраненный URI от Canonical URI. Это бинарное решение (отличается/не отличается), запускающее обновление.
• Управление уникальностью: Генерация списка уникальных URI для оптимизации процесса обновления (Процесс А).
• Временные метки: Используются в Процессе Б для определения URI, которые изменились «с определенного момента времени».

1. Индекс Google как единый источник истины: Document Index служит эталоном для определения Canonical URI не только для поиска, но и для всей экосистемы Google (закладки, история, почта). Google стремится к максимальной консистентности данных.
2. Автоматизация борьбы с «гниением ссылок»: Описана комплексная инфраструктура для борьбы с link rot на разных уровнях: в сервисах Google, на клиентских устройствах и в вебе в целом. Это направлено на значительное улучшение UX.
3. Критичность корректных редиректов: Эффективность всей системы напрямую зависит от способности Crawler своевременно и корректно обнаруживать изменения URI. Использование постоянных (301) редиректов является ключевым фактором для быстрого обновления индекса и пользовательских данных.
4. Активное уведомление вебмастеров: Патент описывает механизм, позволяющий Google активно уведомлять владельцев сайтов об устаревших исходящих ссылках (используя данные Backlinks) и предоставлять им корректный URL для замены. Это указывает на стремление улучшать общую гигиену ссылочного графа веба.
5. Инфраструктурный характер: Патент описывает внутренние процессы управления данными и не содержит прямых указаний на факторы ранжирования.

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

• Немедленное внедрение 301 редиректов: Это критически важно. При любых изменениях URL (миграция, изменение структуры) необходимо использовать постоянные (301) редиректы. Это гарантирует, что Crawler быстро обновит Document Index, что позволит системам, описанным в патенте, корректно обновить закладки и историю пользователей, обеспечивая им беспрепятственный возврат на ваш сайт.
• Четкая стратегия каноникализации: Поддерживайте ясные и последовательные сигналы каноникализации (rel=canonical, XML Sitemaps). Это гарантирует, что Document Index правильно идентифицирует предпочтительный URI, который затем будет распространяться этой системой.
• Мониторинг исходящих ссылок: Регулярно проверяйте исходящие ссылки на своем сайте на наличие ошибок (4xx/5xx). Хотя патент предполагает, что Google может уведомлять вебмастеров о битых ссылках (Процесс Г), проактивный мониторинг остается важным для UX и качества сайта.
• Доступность контактной информации: Убедитесь, что контактная информация (например, страница контактов, email вебмастера или данные в Search Console) актуальна. Это может быть использовано для связи с вами в случае реализации механизма уведомлений, описанного в патенте.

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

• Использование временных редиректов (302) для постоянных перемещений: Это замедляет процесс обновления Canonical URI в Document Index. В результате система не сможет оперативно обновить устаревшие ссылки в закладках пользователей.
• Удаление страниц без редиректов (404): Если страница удалена без настройки редиректа на релевантную замену, Document Index не сможет определить новый Canonical URI. Пользователи, сохранившие ссылку, столкнутся с ошибкой, и автоматическая система обновления не сработает.
• Использование сложных цепочек или нестандартных редиректов: Использование JavaScript-редиректов или длинных цепочек HTTP-редиректов может затруднить краулеру быстрое и точное определение нового Canonical URI, что замедлит работу всей инфраструктуры.

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

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

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

Сценарий 1: Миграция сайта и обновление закладок пользователя

1. Ситуация: Пользователь сохранил закладку на http://old-site.com/page. Сайт переехал на https://new-site.com/page с настройкой 301 редиректа.
2. Действие Google (CRAWLING/INDEXING): Crawler обнаруживает 301 редирект. Document Index обновляет Canonical URI на новый адрес.
3. Действие Google (Обновление Коллекции): Сервер закладок Google (например, Chrome Sync) выполняет Процесс А или Б. Он сверяет закладку с индексом и автоматически обновляет её на https://new-site.com/page.
4. Результат: Пользователь кликает по старой закладке и попадает на новый адрес без ошибок.

Сценарий 2: Уведомление вебмастера о неработающей исходящей ссылке

1. Ситуация: На вашем сайте (Site A) есть ссылка на внешний ресурс http://siteB.com/resource. Site B удалил эту страницу (404).
2. Действие Google (CRAWLING/INDEXING): Crawler обнаруживает 404 ошибку на Site B. Document Index обновляется.
3. Действие Google (Уведомление): Система активирует Процесс Г. Она использует Backlinks, чтобы найти Site A как источник ссылки на устаревший URI.
4. Результат: Система может отправить вам (владельцу Site A) уведомление (например, через Search Console), информируя о неработающей исходящей ссылке и, если возможно, предлагая актуальную замену.