Як JavaScript впливає на crawling і rendering сторінок?

1. Що таке Rendering і чим він відрізняється від Crawling?

Crawling (сканування) — це початковий процес, під час якого пошуковий робот Googlebot робить HTTP-запит до вашого сервера, завантажує вміст сторінки (вихідний HTML-код) та витягує знайдені посилання для розширення своєї черги обходу. На цьому етапі код JavaScript не виконується.

Rendering (візуалізація / отрисовка) — це окремий, асинхронний етап. Googlebot ставить завантажену сторінку в спеціальну чергу рендерингу (Render Queue). Коли ресурси дозволяють, спеціальна служба Web Rendering Service (WRS) на базі безголового браузера Chromium запускає виконання JavaScript, підвантажує стилі, виконує API-запити та будує остаточний візуальний вигляд сторінки (DOM-дерево).

Головна різниця: Сканування — це просто збирання та завантаження "сирого" коду. Рендеринг — це повноцінне "відтворення" та виконання сторінки для того, щоб побачити контент, який з'являється лише після роботи скриптів.

2. Що Googlebot отримує під час першого завантаження HTML-сторінки?

Під час первинного сканування (перша фаза роботи з URL) Googlebot отримує лише початковий HTML-код (raw HTTP response).

Для класичних статичних сайтів або сайтів із рендерингом на стороні сервера (SSR) цей HTML уже містить повний текст та всі посилання.

Для сайтів, побудованих на JS-фреймворках (клієнтський рендеринг), початковий HTML часто є лише порожньою оболонкою — app shell (наприклад, технічні теги та один порожній контейнер <div id="root"></div>), а також лінки на зовнішні файли скриптів (*.js) та стилів (*.css), які роботу ще належить завантажити.

3. Навіщо Google потрібно виконувати JavaScript після Crawling сторінки?

Сучасні вебсайти активно використовують JavaScript для динамічної побудови контенту. Якщо Googlebot просто прочитає початковий HTML-код такого сайту (особливо SPA-додатків), він побачить порожній екран.

Google змушений виконувати JavaScript, щоб:

Побачити реальний вміст сторінки: тексти, картки товарів, огляди, які завантажуються динамічно через API-запити до сервера вже після завантаження браузером базового коду.

Знайти посилання: виявити внутрішні лінки на інші розділи сайту, які генеруються скриптами, щоб додати їх до черги сканування та не допустити появи невідкритих "сторінок-сиріт".

4. Чим контент у початковому HTML відрізняється від контенту, який створюється JavaScript?

Контент у початковому HTML (Стан 1): це статичний код, який сервер миттєво віддає на запит. Він стійкий до збоїв, зчитується роботом за мілісекунди й містить лише базову розмітку, метатеги, шапку й підвал сайту.

Контент від JavaScript (Стан 2): це живий, динамічний DOM-оверлей сторінки, сформований у браузері клієнта після завантаження та виконання JS-скриптів та успішного отримання даних з бази через API. Він містить основний корисний текст, зображення, інтерактивні карти та блоки рекомендацій.

5. Чим client-side rendering (CSR) відрізняється від server-side rendering (SSR) і static rendering з точки зору SEO?

Client-Side Rendering (CSR): сервер віддає пусту сторінку, а весь рендеринг лягає на WRS Google.

Мінуси для SEO: створюється "двофазне" індексування. Процес завантаження потребує колосальних апаратних ресурсів Google, що може призводити до затримок індексації (очікування в черзі рендерингу), а також несе ризик повної втрати контенту у разі помилок у JS чи перевищення часу очікування.

Server-Side Rendering (SSR): сервер самостійно виконує JS-код на своїй стороні й одразу віддає роботу готовий, наповнений контентом HTML-документ.

Плюси для SEO: Googlebot миттєво бачить та індексує весь текст та посилання за один крок (без черги рендерингу). Це покращує швидкість та показники Core Web Vitals (особливо LCP).

Static Rendering (SSG) / ISR: сторінки заздалегідь генеруються під час збірки сайту (build-time).

Плюси для SEO: це найшвидший та найбезпечніший варіант для пошукових систем. Сторінки завантажуються миттєво, а дані є максимально стабільними.

6. Чи може Google індексувати контент, який з’являється тільки після виконання JavaScript?

Так, повністю. Сучасні масштабні дослідження поведінки Googlebot підтверджують, що 100% працездатних HTML-сторінок успішно проходять етап рендерингу, а дані, що надходять потоком (наприклад, через React Server Components — RSC) чи асинхронні API-виклики, чудово індексуються.

Проте існують жорсткі обмеження, про які треба пам'ятати:

Googlebot ніколи не взаємодіє зі сторінкою (не клікає на вкладки, не закриває банери згоди на cookies та не скролить екран для активації lazy-loading). Контент має бути видимим у межах viewport без обов'язкових дій користувача.

WRS є stateless (не зберігає стан) — під час кожного візиту куки (cookies), локальне сховище (localStorage) та сесії (sessionStorage) повністю очищуються. Якщо ваш контент вимагає авторизації чи збережених станів, Googlebot його не побачить.

7. Як JavaScript може заважати Googlebot знаходити внутрішні посилання та нові URL?

Нестандартний формат посилань: Googlebot розпізнає посилання лише у форматі класичного тегу <a href="...">. Якщо переход у вашому SPA реалізований через події кліку на кнопках (наприклад, <div onclick="...">), псевдопосилання javascript:void(0) або через хеш-фрагменти (наприклад, domain.com/#/product), робот проігнорує їх. По таких лінках не передається PageRank та контекстний анкорний текст.

Затримки в черзі рендерингу: якщо посилання на товари з'являються лише після відпрацювання JS, Googlebot дізнається про них із затримкою. Якщо лінки заховані глибоко (наприклад, на 10-й сторінці нескінченного скролу без резервної пагінації), робот може просто не встигнути їх виявити через ліміт бюджету рендерингу.

8. Які JavaScript-помилки або заблоковані CSS/JS-ресурси можуть заважати нормальному Rendering?

Runtime-помилки (Uncaught exceptions): критичні помилки в коді JS (наприклад, збої при hydration фреймворків чи помилки парсингу API) можуть повністю "зламати" завантаження додатка на клієнті, залишивши Googlebot перед білим екраном.

Блокування ресурсів у robots.txt: якщо ви закрили доступ до папок зі скриптами (.js) або стилями (.css), Googlebot не зможе їх завантажити. Як результат, WRS не виконає рендеринг сторінки коректно, що завадить індексації.

Таймаути API-запитів: якщо сервери, які віддають динамічні дані для вашого JS, відповідають занадто повільно (понад 5 секунд), Googlebot припинить очікування й відрендерить порожній шаблон.

Зацикленість: якщо пошкоджений JS-файл потрапляє у нескінченний цикл виконання, Googlebot негайно перериває процес рендерингу для захисту своїх обчислювальних потужностей.

9. Як SEO-фахівцю перевірити, що Google бачить сторінку після Rendering, а не лише її початковий HTML?

Google Search Console (URL Inspection): введіть URL сторінки, запустіть Live Test (Перевірити активну URL-адресу) і перейдіть у вкладку "Tested Page". Тут ви зможете переглянути реальний фінальний код Rendered HTML, скріншот екрана Googlebot, лог консольних помилок JavaScript та список завантажених або заблокованих ресурсів.

Rich Results Test (Тест розширених результатів): офіційний публічний інструмент Google, який показує відрендерену версію DOM-дерева вашої сторінки.

Порівняння "трьох станів" (Методологія Metricum Lab): порівняйте три артефакти для однієї адреси сторінки: вихідний HTML-код (curl або View Source) → фінальний DOM у вашому браузері після виконання JS → Rendered HTML в інструментах Google. Перший шар, на якому зникає важливий текст або посилання, вкаже на точне джерело технічної проблеми.

10. Які практики JavaScript SEO допомагають зробити важливий контент і посилання максимально доступними для Googlebot?

Використовуйте лише чисті HTML-посилання: реалізуйте навігаційні елементи через <a href="/target-url">. Клієнтську маршрутизацію (SPA routing) налаштовуйте як прогресивне покращення за допомогою History API, повністю відмовившись від застарілих хеш-фрагментів (#).

Забезпечте надійний початковий HTML: налаштуйте серверний рендеринг (SSR) або статичну генерацію (SSG) для критично важливих SEO-елементів: унікальних метатегів title / description, тегів canonical, робочих інструкцій robots та основного текстового контенту сторінки.

Впроваджуйте Content Fingerprinting: додавайте унікальний хеш вмісту до назв файлів скриптів (наприклад, main.2bb85551.js). Це запобігає використанню WRS застарілих версій JS-файлів через агресивне кешування ресурсів роботом Google.

Створіть fallback-пагінацію для нескінченного скролу: використовуйте комбінацію динамічного завантаження та стандартних серверних сторінок пагінації (наприклад, ?page=N), щоб робот мав технічну можливість виявити всі товари.

Не публікуйте індексовані сторінки з початковим "noindex": ніколи не віддавайте вихідний HTML із тегом noindex з наміром прибрати його на клієнті через JS. Виявивши noindex у першому ж HTML-файлі, Googlebot може взагалі проігнорувати етап рендерингу та виконання JavaScript, повністю виключивши сторінку з пошуку.