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

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

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

<!DOCTYPE html>
<html lang="uk">
<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. Різнорідність екосистеми краулерів:

   • Googlebot: Виконує JavaScript на базі Evergreen Chromium, але підпорядковується затримкам черги Render Queue.
   • Bingbot: Підтримує рендеринг JavaScript, але має суворіші обмеження за квотами CPU, ніж Googlebot.
   • YandexBot / Baidu / Naver / DuckDuckGo: Або взагалі не виконують JavaScript, або підтримують його у вкрай обмеженому обсязі, покладаючись на серверний HTML.
   • Соціальні боти (Telegram, Twitter/X, Discord, Slack, WhatsApp, Facebook, LinkedIn): Ніколи не виконують JavaScript. Вони парсять виключно статичний HTML першого байта для генерації OpenGraph-прев'ю.

На практиці застосовується#

1. Новинні видання та медіа-платформи: Індексація свіжих публікацій у Google News критична до хвилин. SPA без попереднього рендерингу потрапляє в Render Queue і виходить в індекс через 12–72 години, коли інфопривід втрачає актуальність.
2. E-commerce каталоги з динамічною фільтрацією: Використання клієнтських параметрів хешу (/#/filter?category=shoes) замість реальних шляхів (/catalog/shoes) повністю приховує товари від краулера, оскільки WRS ігнорує URL-фрагменти за стандартом RFC 3986.
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 вказує на вузькі місця, що ламають виконання клієнтського коду.

Поширені помилки#

Питання для співбесіди#

Пов'язані теми#