Двухфазная индексация SPA: Web Rendering Service, краулинговый бюджет и боты

Архитектурная база#

Архитектура Single Page Applications (SPA) на базе React, Vue или Angular перенесла ответственность за сборку Document Object Model (DOM) с веб-сервера на клиентский браузер. При запросе страницы сервер отдает минимальный HTML-каркас:

<!DOCTYPE html>
<html lang="ru">
<head>
  <meta charset="UTF-8">
  <title>App</title>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/assets/main.js"></script>
</body>
</html>

Для классических поисковых роботов и социальных сетей такой ответ представляет собой информационный вакуум. Несмотря на то, что Googlebot с 2019 года использует «вечнозеленый» headless Chromium (Evergreen Chromium) для исполнения клиентского JavaScript, предположение о том, что «Google сам всё отрендерит и проиндексирует точно так же, как обычный браузер», является опасным инженерным заблуждением.

Главная проблема кроется в разделении процесса краулинга на две асинхронные фазы посредством сервиса Web Rendering Service (WRS). Рендеринг JavaScript требует колоссальных вычислительных мощностей (CPU, GPU, RAM), в тысячи раз превышающих парсинг сырого HTML. В результате поисковик экономит ресурсы инфраструктуры: страницы SPA встают в буфер отложенного рендеринга (Render Queue), из-за чего индексация динамического контента задерживается на дни или недели, а краулинговый бюджет сайтов быстро истощается.

+-------------------------------------------------------------------------+
|                    АРХИТЕКТУРА ИНДЕКСАЦИИ GOOGLEBOT WRS                 |
+-------------------------------------------------------------------------+

 [ HTTP GET Запрос ]
        |
        v
 +--------------+       Первичный HTML
 |  Краулер     | -------------------------------------> [ Фаза 1: Индексация HTML ]
 |  (Googlebot) |    (Статические теги, links,           (Сырой DOM, <div id="root">,
 +--------------+     метаданные сервера)                 зачастую без контента)
        |                                                           |
        | Сохранение HTML в базу                                    |
        v                                                           v
 +--------------+                                         [ Индекс поисковика ]
 | Render Queue | <--- Буфер ожидания CPU ресурсов                  ^
 +--------------+      (Задержка: от часов до 3-4 недель)           |
        |                                                           |
        v Выделение слота headless-браузера                         |
 +--------------+                                                   |
 | WRS          | ---> [ Выполнение JS / API fetch ]               |
 | (Chromium)   | ---> [ Построение Rendered DOM ] -----------------+
 +--------------+                                   Фаза 2: Вторичная индексация
                                                    (Обновление сниппета, ссылок)

Ментальная модель#

Чтобы принимать взвешенные архитектурные решения при проектировании клиентских приложений, необходимо понимать три фундаментальных ограничения:

1. Двухфазная индексация (Two-Wave Indexing):

   • Фаза 1 (Мгновенная): Googlebot скачивает начальный HTML, парсит директивы заголовков, статические метатеги и извлекает ссылки <a href="...">. Если SPA не использует Server-Side Rendering (SSR) или Static Site Generation (SSG), в индекс попадает пустая страница либо базовый fallback загрузчика (spinner).
   • Фаза 2 (Отложенная): Страница отправляется в Render Queue. Когда освобождаются вычислительные кластеры WRS, headless Chromium загружает JavaScript-бандлы, исполняет их, выполняет сетевые запросы fetch(), формирует Rendered DOM и передает его в индекс. Разрыв во времени между первой и второй фазами называется Rendering Delay (задержка рендеринга).

2. Краулинговый бюджет (Crawl Budget) и ограничения CPU:

   • Поисковые системы выделяют сайту конечный лимит ресурсов. Сложный клиентский JS с долгими вычислениями, неоптимизированными ре-рендерами или тяжелыми бандлами перегружает WRS.
   • Жесткий таймаут WRS: если API-запрос или сборка интерфейса длятся дольше 5–10 секунд, WRS прекращает выполнение скрипта и индексирует текущий недорендеренный снимок экрана.

3. Разнородность экосистемы краулеров:

   • YandexBot: Имеет ограниченную поддержку выполнения JavaScript. Поисковый робот Яндекса рендерит страницы выборочно и намного реже Googlebot, полагаясь преимущественно на серверный HTML.
   • Baidu / Naver / DuckDuckGo / Yahoo: Либо вообще не выполняют JavaScript, либо поддерживают его в крайне примитивном объеме.
   • Социальные боты (Telegram, Twitter/X, Discord, Slack, WhatsApp, Facebook): Никогда не исполняют JavaScript. Они парсят исключительно статический HTML первого байта для генерации OpenGraph-превью.

На практике применяется#

1. Новостные издания и медиа-платформы: Индексация свежих публикаций в Google News критична к минутам. SPA без предварительного рендеринга попадает в Render Queue и выходит в индекс спустя 12–72 часа, когда инфоповод теряет актуальность.
2. E-commerce каталоги с динамической фильтрацией: Использование клиентских параметров хэша (/#/filter?category=shoes) вместо реальных путей (/catalog/shoes) полностью скрывает товары от краулера, так как WRS игнорирует URL-фрагменты.
3. Enterprise B2B SaaS с публичными базами знаний: Документация на базе чистого React SPA рискует потерять трафик по длинному хвосту поисковых запросов из-за таймаутов WRS при загрузке тяжелых JS-библиотек подсветки синтаксиса и рендеринга Markdown.

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

При оценке SPA инженером по веб-производительности ключевой метрикой является прозрачность приложения для краулера. Рассмотрим типовые сетевые и архитектурные барьеры WRS.

Проблема: Блокировка критических ресурсов в robots.txt#

Headless Chromium при исполнении React-бандла запрашивает все вспомогательные ассеты: .js, .css, а также эндпоинты внутренних API (/api/v1/products/...). Если файл robots.txt запрещает скачивание API или статики, WRS получает ошибку сетевого запроса, страница не может выполнить гидратацию, и поисковик индексирует пустой экран.

# НЕПРАВИЛЬНО: Блокировка API ломает клиентский рендеринг в WRS
User-agent: *
Disallow: /api/
Disallow: /assets/
Disallow: /static/

# ПРАВИЛЬНО: Разрешение краулеру загружать ассеты и публичные данные
User-agent: *
Allow: /assets/
Allow: /static/
Allow: /api/v1/public/
Disallow: /api/v1/private/
Disallow: /admin/
Sitemap: https://agenticlab.dev/sitemap.xml

Проверка рендеринга WRS через headless-эмуляцию#

Для верификации того, что видит WRS до и после выполнения скриптов, используется Playwright или Puppeteer с отключенным кэшем и строгим таймаутом выполнения скриптов:

import { chromium, type Browser, type Page } from 'playwright';

interface AuditResult {
  url: string;
  hasRootContentBeforeJs: boolean;
  hasContentAfterJs: boolean;
  jsExecutionTimeMs: number;
  blockedRequests: string[];
  pageTitle: string;
  h1Count: number;
}

export async function auditWrsRendering(targetUrl: string): Promise<AuditResult> {
  const browser: Browser = await chromium.launch({ headless: true });
  const context = await browser.newContext({
    userAgent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)',
  });

  const page: Page = await context.newPage();
  const blockedRequests: string[] = [];

  // Фиксируем сетевые сбои критических API
  page.on('requestfailed', (req) => {
    blockedRequests.push(`${req.method()} ${req.url()} - ${req.failure()?.errorText || 'Unknown'}`);
  });

  // 1. Проверяем сырой HTML (Фаза 1 WRS)
  const rawResponse = await fetch(targetUrl, {
    headers: { 'User-Agent': 'Googlebot/2.1' },
  });
  const rawHtml = await rawResponse.text();
  const hasRootContentBeforeJs = !rawHtml.includes('<div id="root"></div>') && rawHtml.includes('<h1');

  // 2. Проверяем Rendered DOM (Фаза 2 WRS)
  const startTime = performance.now();
  await page.goto(targetUrl, { waitUntil: 'networkidle', timeout: 10000 });
  const jsExecutionTimeMs = Math.round(performance.now() - startTime);

  const pageTitle = await page.title();
  const h1Count = await page.locator('h1').count();
  const hasContentAfterJs = h1Count > 0;

  await browser.close();

  return {
    url: targetUrl,
    hasRootContentBeforeJs,
    hasContentAfterJs,
    jsExecutionTimeMs,
    blockedRequests,
    pageTitle,
    h1Count,
  };
}

Диагностика в Google Search Console (URL Inspection)#

Google Search Console предоставляет инструмент URL Inspection (Проверка URL):

1. Downloaded HTML (Загруженный HTML): Вкладка показывает документ, полученный на Фазе 1. Для чистого React SPA здесь всегда находится пустой тег <div id="root"></div>.
2. View Tested Page -> Screenshot: Снимок экрана, сделанный headless Chromium на Фазе 2. Если здесь виден серый экран или прелоадер — код приложения выбросил ошибку во время выполнения скрипта или превысил таймаут рендеринга (5–10 секунд).
3. More Info -> Page Resources: Список ресурсов, которые Googlebot не смог загрузить. Статус Other error или Blocked by robots.txt указывает на узкие места, ломающие выполнение клиентского кода.

Распространённые ошибки#