JavaScript SEO і рендеринг

JavaScript SEO і рендеринг — це питання про те, чи бачить Google вміст сторінки, що зʼявляється лише після виконання скриптів. Коротка відповідь документації: так, Google запускає JavaScript в актуальній версії Chromium, але в цього процесу є етапи й умови, від яких залежить результат. Нерідко пишуть, що Google «повертається за кілька днів» і що потрібен конкретний фреймворк, але таких тверджень у документації немає. Тут — лише те, що в ній описано, і конкретні перевірки.

Основа — посібник Google з основ JavaScript SEO і довідка з пошуку й виправлення проблем.

Три етапи: обхід, рендеринг, індексування

Google обробляє JavaScript-застосунки в три етапи, і Googlebot ставить сторінки в чергу і на обхід, і на рендеринг:

1. Обхід. Googlebot бере URL із черги, спершу перевіряє robots.txt. Якщо URL заборонений, запит не виконується, а скрипти із заблокованих файлів і зі сторінок, закритих від обходу, Google не рендерить. Потім він шукає посилання в атрибутах href отриманого HTML;
2. Рендеринг. Усі сторінки з кодом відповіді 200 потрапляють у чергу рендерингу, незалежно від того, чи є на них JavaScript, окрім тих, де метатег або заголовок robots забороняє індексування. Сторінка може чекати кілька секунд, але може й довше. Коли ресурси дозволяють, браузер без інтерфейсу виконує скрипти. Для відповідей не 200, наприклад сторінок помилок, рендеринг може бути пропущений;
3. Індексування. Google використовує відрендерений HTML для індексування й повторно витягує з нього посилання.

Документація додає: серверний рендеринг або попередній рендеринг лишається чудовою ідеєю, бо робить сайт швидшим для користувачів і краулерів, а не всі боти вміють виконувати JavaScript.

Способи віддати контент

Google називає три рекомендовані рішення: серверний рендеринг, статичний рендеринг і гідратацію. Додатково: динамічний рендеринг був обхідним рішенням, а не довгостроковим, а замість нього рекомендовано три рішення вище. Нерідко такі способи ранжують: SSG та ISR «відмінно», клієнтський «ризиковано». Цих оцінок у документації немає, а клієнтський рендеринг сам по собі не заборонений: Google бачить такий контент разом з рештою HTML. Критично, щоб потрібне було доступне в підсумковій сторінці й відповідало правилам нижче.

Правила для JavaScript-сайтів

• Посилання. Google знаходить посилання лише в елементах a з атрибутом href. Упроваджувати посилання в DOM скриптом можна, якщо вони відповідають правилам доступних для обходу посилань. Докладніше — в уроці про пошук і навігацію та на сторінці про посилання;
• Історія браузера замість фрагментів. В односторінкових застосунках маршрутизуйте через History API: адреси із фрагментом після решітки Googlebot не розвʼязує надійно;
• Title і description. Їх можна задавати й змінювати скриптом; вони мають бути унікальними й описовими;
• Canonical. Краще задавати в HTML. Скриптом можна, але не можна змінювати його на інший URL порівняно з вихідним HTML; якщо в HTML задати не можна, залиште його там порожнім і задайте лише скриптом, і переконайтеся, що елемент один. Докладніше — в уроці про canonical;
• Коди відповіді. Використовуйте змістовні коди: 404 для ненайденої сторінки, 401 для сторінок за входом, перенаправлення для переїхалих;
• Структуровані дані. JSON-LD можна генерувати й упроваджувати скриптом; обовʼязково перевіряйте результат. Див. урок про структуровані дані;
• Кешування. Google кешує агресивно й може ігнорувати заголовки кешування, через що використовує застарілі JavaScript і CSS. Рішення — в імʼя файлу включають відбиток вмісту, наприклад main.2bb85551.js.

Пастки robots meta

Скриптом можна додати метатег robots або змінити його. Але коли Google зустрічає noindex, він може пропустити рендеринг і виконання JavaScript, тому зміна чи видалення noindex скриптом може не спрацювати. Якщо сторінка має індексуватися, не ставте noindex у вихідний HTML. Це саме правило пояснює ще одну пастку, описану в уроці про robots.txt і meta robots.

Мʼяка 404 в односторінковому застосунку

За клієнтської маршрутизації серверний код відповіді часто неможливий. Щоб сторінки помилок не стали soft 404, Google пропонує два способи: перенаправити скриптом на URL, для якого сервер відповідає 404, або додати на сторінку помилки noindex. Про коди й перенаправлення — в уроці про редиректи.

Як перевірити

1. У Search Console відкрийте перевірку URL або Rich Results Test: видно завантажені ресурси, вивід консолі JavaScript, винятки й відрендерений DOM.
2. Порівняйте це з HTML, який віддає сервер: наші аналізатор сторінки і краулер читають саме відповідь сервера й скрипти не виконують. Якщо важливий текст, посилання чи canonical є лише у відрендереному вигляді, це залежність від рендерингу.
3. Перевірте, що меню й посилання — елементи a з href, а не обробники подій.
4. Переконайтеся, що скрипти, CSS і дані не закриті в robots.txt.
5. Перевірте коди відповіді для неіснуючих адрес.
6. Для масової перевірки статусів індексування — аудит URL. Швидкість і стабільність — Core Web Vitals.

Чого в документації немає

• Строку «за кілька днів» для рендерингу: сказано лише, що черга може забрати більше кількох секунд;
• рейтингу SSR, SSG, ISR та оцінок «найкращий» і «хороший компроміс»;
• рекомендації конкретних фреймворків;
• твердження, що клієнтський рендеринг сам по собі блокує індексування.

Чек-лист

1. Потрібний контент і посилання є у відрендереному HTML.
2. Посилання — це a з href; маршрутизація через History API.
3. Canonical один і збігається з HTML.
4. Немає noindex у вихідному коді сторінок, які мають індексуватися.
5. Неіснуючі адреси дають 404 або noindex.
6. Ресурси відкриті для Googlebot; файли з відбитком в імені.

Помилки

• Вважати, що Google не виконує JavaScript.
• Вважати, що клієнтський рендеринг сам по собі безпечний без перевірки результату.
• Ставити noindex в HTML і сподіватися зняти його скриптом.
• Будувати навігацію на фрагментах і обробниках подій.
• Закрити скрипти в robots.txt.

Що далі

Далі — модуль просунутої технічної оптимізації: структуровані дані, Core Web Vitals і переїзд сайту.