Как Google индексирует динамический JavaScript-контент (AJAX/SPA), используя рендеринг и анализ URL-фрагментов

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

Base URL (Базовый URL)

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

Content Converter (Конвертер контента)

Компонент, который преобразует отрендеренный контент (например, DOM tree) в индексируемый формат (например, сериализованный HTML).

DOM Tree (Объектная модель документа)

Структурированное представление веб-страницы после рендеринга, включающее все динамически добавленные элементы и ресурсы. Источник истины для индексации.

Indexable Content (Индексируемый контент)

Контент, преобразованный в формат, который может быть обработан индексатором (например, статический HTML).

Indexable Fragment (Индексируемый фрагмент)

Фрагмент URL (после #), который идентифицирует уникальное состояние страницы, сгенерированное путем выполнения клиентского кода (dynamic content). Отличается от Pointer Fragment. Патент упоминает использование специальных символов (например, !) для их идентификации (т.е. #!).

Pointer Fragment (Указательный фрагмент)

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

Rendered Content (Отрендеренный контент)

Состояние веб-страницы после выполнения клиентских скриптов и загрузки всех встроенных ресурсов (embedded resources). Обычно представлено в виде DOM tree.

Rendering System (Система рендеринга)

Компонент, который эмулирует поведение браузера, выполняя клиентский код (JavaScript/AJAX) для генерации финального состояния страницы.

URL Inspector (Инспектор URL)

Компонент, который анализирует URL, обнаруженный краулером, и определяет наличие и тип фрагмента (Indexable или Pointer).

URL Separator (Разделитель URL)

Компонент, который разделяет URL с индексируемым фрагментом на Base URL и полный URL.

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

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

1. Система определяет URL, содержащий indexable fragment. Уточняется, что этот фрагмент связан с динамическим контентом, генерируемым исполняемым кодом (браузером) для частичной модификации страницы.
2. Система отделяет Base URL (часть до фрагмента).
3. Система обрабатывает контент Base URL для получения обработанного контента. Важное уточнение: этот контент не включает встроенные ресурсы, подлежащие рендерингу (т.е. это исходный код до выполнения JS).
4. Rendering System рендерит этот обработанный контент вместе с контентом, идентифицируемым полным URL (включая фрагмент), для получения rendered content. Важное уточнение: этот контент включает рендеринг встроенных ресурсов (т.е. после выполнения JS).
5. Content Converter преобразует rendered content в indexable content (код на языке разметки).

Ядро изобретения — это использование фрагмента URL как триггера для выполнения клиентского кода и последующего захвата результата для индексации.

Claim 3 (Зависимый от 1): Уточняет процесс идентификации.

Система способна отличить indexable fragment от pointer fragment (который только указывает на специфическую часть веб-сайта).

Claim 9 (Зависимый от 1): Детализирует результат работы Rendering System.

Рендеринг включает вывод Document Object Model (DOM) tree, который содержит динамически обновленные части веб-сайта, связанные с indexable fragment.

Claim 10 (Зависимый от 9): Детализирует работу Content Converter.

Конвертация отрендеренного контента включает сериализацию DOM tree для получения кода HyperText Markup Language (HTML).

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

Изобретение является ключевой частью инфраструктуры сканирования и индексирования Google, обеспечивающей обработку динамического контента.

CRAWLING – Сканирование и Сбор данных
На этом этапе краулер (Crawler) обнаруживает ссылки. URL Inspector анализирует эти ссылки на наличие фрагментов и классифицирует их. Если фрагмент идентифицирован как Indexable Fragment, запускается специальный процесс обработки, и URL Separator разделяет URL.

INDEXING – Индексирование и извлечение признаков
Это основной этап применения патента, соответствующий современному процессу рендеринга (Web Rendering Service - WRS).

1. Обработка Base URL: Исходный контент базового URL обрабатывается.
2. Рендеринг: Rendering System эмулирует браузер, объединяя контент Base URL и полный URL с фрагментом. Это заставляет систему выполнить JavaScript и AJAX-запросы для построения финального состояния страницы.
3. Конвертация: Content Converter сериализует полученный DOM tree в HTML.
4. Индексация: Полученный HTML передается стандартному индексатору для анализа контента и извлечения признаков.

Входные данные:

• URL с индексируемым фрагментом.
• Base URL.
• Исходный код (HTML) и связанные ресурсы (JS, CSS, API ответы).

Выходные данные:

• Сериализованный HTML-код (Indexable Content), представляющий финальное состояние динамической страницы.

На что влияет

• Типы контента: В первую очередь влияет на контент, который загружается асинхронно с помощью JavaScript (AJAX), а не присутствует в исходном HTML.
• Технологии: Критически важен для Single Page Applications (SPA), которые используют (или использовали) URL-фрагменты для маршрутизации (например, ранние версии Angular.js, React/Vue с хэш-маршрутизацией).
• Специфические запросы: Позволяет страницам с динамическим контентом ранжироваться по запросам, релевантным этому контенту.

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

• Триггеры активации: Алгоритм активируется, когда URL Inspector классифицирует фрагмент в URL как Indexable Fragment. Патент предлагает несколько методов для этой классификации (варианты реализации):
  • Наличие специальных символов (например, ! после #, т.е. hashbang #!).
  • Включение сайта в список (whitelist) ресурсов, использующих динамический контент.
  • Эвристики и машинное обучение для предсказания типа фрагмента на основе статистики сайта.
  • Эвристический подход: попытка обработать все фрагменты как индексируемые и откат в случае неудачи.

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

Процесс обработки URL с индексируемым фрагментом:

1. Сканирование и извлечение: Краулер сканирует веб-сайт и извлекает URL, содержащий фрагмент (например, www.example.com#!page1).
2. Инспекция фрагмента: URL Inspector анализирует фрагмент.
   • Если это Pointer Fragment: Процесс продолжается стандартно (фрагмент игнорируется).
   • Если это Indexable Fragment: Переход к шагу 3.
3. Разделение URL: URL Separator разделяет URL на Base URL (www.example.com) и полный URL (www.example.com#!page1).
4. Ассоциация и хранение: Оба URL могут быть сохранены в системе (например, в Index Table с общим флагом) для последующей совместной обработки.
5. Обработка Base URL: Контент Base URL сканируется и обрабатывается (это может произойти независимо или быть инициировано на данном этапе).
6. Поиск связанных URL: Система идентифицирует Base URL и ищет все связанные с ним URL с фрагментами (если используется механизм ассоциации).
7. Передача на рендеринг: Обработанный контент Base URL вместе с полным URL (с фрагментом) передается в Rendering System.
8. Рендеринг и выполнение скриптов: Rendering System эмулирует браузер, загружает ресурсы и выполняет JavaScript. Фрагмент используется для запуска скриптов, которые генерируют динамический контент.
9. Захват состояния: Система фиксирует финальное состояние страницы в виде DOM Tree.
10. Конвертация: Content Converter сериализует DOM Tree в статический HTML (Indexable Content).
11. Индексация: Полученный HTML индексируется стандартным образом.

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

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

Патент фокусируется на инфраструктуре обработки и использует следующие типы данных:

• Технические факторы (URL): Структура URL критически важна. Система анализирует наличие символа # и последующих символов (например, !) для идентификации Indexable Fragments.
• Контентные факторы (Исходный код): Исходный HTML Base URL используется как основа для рендеринга.
• Мультимедиа и Ресурсы (Встроенные ресурсы): Встроенные ресурсы (embedded resources), такие как JavaScript, CSS, изображения, а также данные, получаемые через API (AJAX-запросы), необходимы Rendering System для построения финального DOM.
• Системные данные (Внутренние): Списки сайтов (whitelists) и эвристики/статистика, используемые для классификации фрагментов.

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

Патент не описывает конкретных метрик ранжирования, но описывает механизмы классификации и обработки:

• Классификация фрагментов: Определение типа фрагмента (Indexable vs Pointer). Может основываться на синтаксисе (#!), списках сайтов или оценках уверенности от моделей машинного обучения (хотя конкретные модели не детализированы).
• Построение DOM: Процесс построения DOM tree на основе выполнения JavaScript и других ресурсов.
• Сериализация: Алгоритм преобразования структуры DOM обратно в HTML-код.

1. Рендеринг как необходимость для индексации JavaScript: Патент описывает сложную инфраструктуру, разработанную для решения проблемы индексации динамического контента. Это подтверждает, что для индексации JavaScript-контента требуется полноценный рендеринг.
2. Индексация основана на DOM, а не на исходном коде: Система индексирует контент, который присутствует в DOM tree после выполнения скриптов. Content Converter сериализует этот DOM в HTML. Если контент не попал в DOM, он не будет проиндексирован.
3. Подтверждение двухфазной индексации: Процесс четко разграничивает первичное сканирование/обработку Base URL (исходный HTML) и последующий, отдельный этап рендеринга, необходимый для выполнения динамического контента.
4. Специфическая обработка URL-фрагментов: Система активно различает традиционные анкорные ссылки (Pointer Fragments) и фрагменты, используемые для маршрутизации в SPA (Indexable Fragments). Это было критически важно для реализации AJAX Crawling Scheme.
5. Фундамент для современного Googlebot (WRS): Механизмы, описанные в патенте (Rendering System, Content Converter), являются основой того, как Google обрабатывает JavaScript сегодня, даже несмотря на то, что триггер в виде #! больше не требуется.

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

Хотя патент описывает механизм, связанный с устаревшей AJAX Crawling Scheme (#!), его принципы критически важны для современного JavaScript SEO.

• Обеспечение доступности ресурсов для рендеринга: Убедитесь, что все критически важные ресурсы (JavaScript, CSS, изображения, ответы API/XHR-запросов) доступны для Googlebot и не заблокированы (например, в robots.txt). Rendering System нуждается в них для построения DOM.
• Проверка отрендеренного HTML (DOM): Регулярно используйте инструменты (например, Инструмент проверки URL в GSC) для анализа HTML-кода, который видит Googlebot. Этот HTML является результатом работы Content Converter (сериализованный DOM). Убедитесь, что весь ключевой контент и ссылки присутствуют в этом коде, а не только в исходном коде (View Source).
• Оптимизация производительности JavaScript: Так как система тратит реальные ресурсы на выполнение скриптов (бюджет рендеринга), необходимо оптимизировать скорость их выполнения. Медленный JavaScript может привести к таймаутам рендеринга и неполной индексации.
• Использование History API для маршрутизации (Современная практика): Вместо использования фрагментов (# или #!) для маршрутизации в SPA, используйте History API (pushState) для генерации чистых URL. Это современный стандарт, который более надежен для поисковых систем.

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

• Использование Hashbang (#!) или простых хэшей (#) для нового сайта: Не используйте схему #!, она официально устарела. Использование простых хэшей (#state) для уникального контента рискованно, так как они могут быть восприняты как Pointer Fragments.
• Блокировка JavaScript или CSS: Это предотвратит корректную работу Rendering System, что приведет к индексации пустого или неполного контента.
• Игнорирование ошибок JavaScript: Ошибки во время выполнения скриптов могут остановить процесс рендеринга. Контент, который должен был быть сгенерирован после точки возникновения ошибки, не попадет в DOM.
• Зависимость основного контента от действий пользователя: Rendering System выполняет скрипты при загрузке, но обычно не симулирует сложные взаимодействия с пользователем (например, клики). Основной контент должен быть доступен в DOM после начальной загрузки.

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

Этот патент знаменует собой важный переход в истории поиска: от сканирования статического HTML к необходимости рендеринга динамического контента. Он подтверждает, что JavaScript SEO — это необходимость, продиктованная архитектурой поисковой системы. Стратегически, это подчеркивает важность оптимизации под процесс выполнения JavaScript (рендеринг) и признания того, что отрендеренный DOM является каноническим контентом.

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

Сценарий 1: Индексация каталога товаров в ранней версии SPA (Исторический контекст)

1. Ситуация: Интернет-магазин использует AJAX. При выборе категории URL меняется на www.shop.com#!category=shoes. Список товаров генерируется JavaScript.
2. Проблема (до патента): Googlebot игнорировал #!category=shoes и индексировал только www.shop.com. Контент категории «Обувь» терялся.
3. Решение (согласно патенту):
   • URL Inspector видит #! и классифицирует фрагмент как Indexable.
   • Rendering System загружает www.shop.com и использует #!category=shoes для запуска JavaScript, который загружает товары категории «Обувь».
   • Content Converter сериализует финальный DOM, содержащий список товаров, в HTML.
4. Результат: Google индексирует страницу категории «Обувь» со всем её содержимым.

Сценарий 2: Отладка отсутствующего динамического контента (Современный контекст)

1. Контекст: Сайт динамически загружает отзывы о товарах через AJAX. Отзывы не индексируются.
2. Действие: Проанализировать отрендеренный HTML (DOM) в инструменте проверки URL GSC.
3. Анализ: Если отзывы отсутствуют в отрендерованном HTML, Rendering System не смогла выполнить вызов AJAX или завершить рендеринг.
4. Отладка и Решение: Проверить GSC на наличие заблокированных ресурсов или ошибок JavaScript. Убедиться, что JavaScript, отвечающий за получение отзывов, доступен и выполняется корректно, позволяя Content Converter зафиксировать конечное состояние DOM.