# JavaScript SEO: проблеми рендерингу і як їх виправити

> Проблеми рендерингу JavaScript ховають контент, посилання і теги від Google та AI-краулерів. 9 типових причин, як їх перевірити й виправити кожну.

URL: https://seorecheck.com/ua/blog/javascript-seo-rendering-problems · Опубліковано: 2026-10-28 · [English](https://seorecheck.com/blog/javascript-seo-rendering-problems.md), [Español](https://seorecheck.com/es/blog/javascript-seo-rendering-problems.md)

Проблеми рендерингу JavaScript у SEO виникають тоді, коли контент, посилання або метатеги сторінки з'являються лише після того, як JavaScript виконається в браузері. Щоб їх побачити, Google має відрендерити сторінку, а це може статися із затримкою або піти не так. Багато AI-краулерів JavaScript взагалі не виконують. Рішення — віддавати критичний контент у HTML, який надсилає сервер.

У цьому посібнику з JavaScript SEO розберемо, як Google обробляє JavaScript, дев'ять проблем рендерингу, які найбільше шкодять сайтам, як перевірити, що насправді бачать краулери, і який спосіб виправлення обрати.

## Як Google рендерить JavaScript-сторінки?

Google обробляє JavaScript-сторінки у три етапи: сканування, рендеринг та індексування. Спершу він завантажує сирий HTML, потім ставить сторінку в чергу на рендеринг у headless-браузері Chromium і лише після цього індексує те, що показує відрендерена сторінка. Усе, що зламалося на етапі рендерингу, до індексу не потрапляє.

Згідно з [основами JavaScript SEO від Google](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), Googlebot ставить у чергу на рендеринг усі сторінки з кодом статусу `200`, якщо метатег robots або заголовок не забороняє індексування. Сторінка «може перебувати в цій черзі кілька секунд, але це може тривати й довше». Рендеринг виконується в актуальній (evergreen) версії Chromium, тож сучасний JavaScript загалом підтримується.

Звучить заспокійливо, але має три наслідки:

- **Два шанси зламатися.** Сирий HTML і відрендерений DOM можуть не збігатися, а деякі рішення (коди статусу, `noindex`) Google ухвалює за сирим HTML ще до рендерингу.
- **Затримка.** Контент, який існує лише після рендерингу, потрапляє в індекс пізніше, ніж контент у HTML.
- **Жодної взаємодії.** Googlebot завантажує сторінку, але не клікає, не прокручує й не входить в акаунт.

## Чому проблеми рендерингу JavaScript важливі й для AI-пошуку?

Багато AI-краулерів завантажують ваш HTML, але не виконують JavaScript, тож контент, який з'являється лише після рендерингу, для них невидимий. Сторінка, яку Google ідеально проіндексував, усе одно може бути порожньою для ботів, що постачають дані для відповідей ChatGPT, Claude чи Perplexity.

Дослідження Vercel [The rise of the AI crawler](https://vercel.com/blog/the-rise-of-the-ai-crawler) (грудень 2024) проаналізувало трафік краулерів у їхній мережі й показало, що «жоден із головних AI-краулерів наразі не рендерить JavaScript», зокрема GPTBot від OpenAI та ClaudeBot від Anthropic. У частині запитів вони завантажували JavaScript-файли, але не виконували їх. Винятком був Gemini, бо він використовує інфраструктуру рендерингу Google. Поведінка краулерів може змінюватися, і не всі вендори її документують, тож сприймайте це як виміряний зріз, а не гарантію.

Практичне правило однакове для обох аудиторій: якщо речення важливе для ранжування або для цитування у відповіді AI, воно має бути у відповіді сервера. Ширшу картину див. у нашому посібнику [GEO vs SEO](https://seorecheck.com/ua/blog/geo-vs-seo-differences).

## Які проблеми рендерингу JavaScript трапляються найчастіше?

Найпоширеніші проблеми — контент і посилання, що завантажуються лише в браузері, навігація тільки на JavaScript, сторінки помилок із кодом `200`, `noindex`, змінений скриптом, заблоковані ресурси, контент, що потребує кліку чи прокручування, і застарілі кешовані бандли. Кожна з них або ховає контент від Google, або надсилає йому хибний сигнал.

| Проблема | Що бачить Google або AI-краулер | Типове рішення |
|---|---|---|
| Контент рендериться лише на клієнті | Порожня оболонка в сирому HTML; контент пізніше або ніколи | SSR, статичний рендеринг або пререндеринг |
| Посилання без `<a href>` | Немає URL для переходу, сторінки-сироти | Справжні посилання `<a href="/path">` |
| Маршрутизація через хеш (`/#/products`) | Одна URL-адреса на весь застосунок | History API зі справжніми шляхами |
| Сторінки помилок SPA повертають `200` | Soft 404, сторінки помилок в індексі | Серверний 404 або `noindex`, доданий через JS |
| `noindex` видаляється JavaScript-ом | Сторінка може лишитися поза індексом | Правильний тег robots у сирому HTML |
| JS/CSS/API заблоковані в robots.txt | Зламаний або порожній рендер | Дозволити ресурси для рендерингу |
| Контент за кліком, прокручуванням або дозволами | Контент ніколи не завантажується | Завантаження при появі у viewport, URL пагінації |
| Застарілі кешовані бандли | Старий або зламаний рендер | Імена файлів із відбитком (fingerprint) |
| Стан у cookies/localStorage | Щоразу нова порожня сесія | Не робити контент залежним від збереженого стану |

### 1. Критичний контент існує лише після рендерингу

Класичний single-page app надсилає `<div id="root"></div>` і бандл. Google може відрендерити його без проблем, але контент надходить пізніше, а краулери без рендерингу не бачать нічого. Зазвичай страждають описи товарів, ціни, заголовки й тексти статей.

### 2. Посилання, за якими Google не може перейти

Google зазначає, що [може виявляти лише посилання](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), які є елементами `<a>` з атрибутом `href`. Меню на `<span onclick>` або кнопки, що викликають `router.push()`, не дають Google нічого для сканування, тож глибші сторінки стають сиротами. Як виправити структуру, коли посилання вже скануються, пояснює наш [посібник із внутрішньої перелінковки](https://seorecheck.com/ua/blog/internal-linking-seo-guide).

```html
<!-- Crawlable -->
<a href="/pricing">Pricing</a>

<!-- Not crawlable -->
<span onclick="goTo('/pricing')">Pricing</span>
<a onclick="goTo('/pricing')">Pricing</a>
```

### 3. Хеш-фрагменти замість справжніх URL

Адреси на кшталт `example.com/#/services` виглядають для користувачів як окремі сторінки, але [посібник Google з виправлення проблем JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) зазначає, що схему сканування AJAX застаріло ще у 2015 році, тож на маршрутизацію через фрагменти покладатися не можна. Використовуйте History API, щоб кожне подання мало власний шлях.

### 4. Soft 404 в односторінкових застосунках

Коли SPA показує «Товар не знайдено», а сервер усе одно повертає `200`, Google може проіндексувати сторінку помилки. Google рекомендує або перенаправляти на URL, де сервер повертає справжній `404`, або додавати `<meta name="robots" content="noindex">` через JavaScript на сторінках помилок. Коли 404 — правильна відповідь, читайте в статті [Помилки 404 і SEO](https://seorecheck.com/ua/blog/404-errors-seo-impact).

### 5. `noindex`, який має прибрати JavaScript

На цьому спотикається багато команд. Google стверджує, що коли він бачить тег `noindex`, «він може пропустити рендеринг і виконання JavaScript», тож видалення `noindex` за допомогою JavaScript «може працювати не так, як очікується». Якщо в сирому HTML стоїть `noindex`, вважайте, що сторінка лишиться поза індексом, хоч би що потім робив ваш скрипт.

### 6. Заблоковані ресурси

Якщо robots.txt забороняє `/static/`, `/_next/`, `/api/` або сторонній скрипт, що рендерить контент, Google відрендерить зламану сторінку. Перевірте, що кожен файл, потрібний для побудови основного контенту, доступний для завантаження. Безпечні шаблони описано в нашому [посібнику з robots.txt](https://seorecheck.com/ua/blog/robots-txt-seo-guide).

### 7. Контент, що потребує дій користувача

У [рекомендаціях Google щодо lazy loading](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading) сказано, що Google Search «не взаємодіє з вашою сторінкою», тож контент має завантажуватися, коли він видимий у viewport, а не після прокручування чи кліку. Кнопки «Показати ще», вкладки, що підвантажують контент по кліку, і нескінченне прокручування без URL пагінації — усе це ховає контент. Для нескінченного прокручування Google радить постійну URL-адресу для кожної частини, наприклад `?page=12`, з послідовними посиланнями. Googlebot також відхиляє запити дозволів, як-от доступ до камери чи геолокації, тож контент не повинен від них залежати.

### 8. Застарілий кешований JavaScript

Google зазначає, що його Web Rendering Service може ігнорувати заголовки кешування й використовувати застарілі JS або CSS. Якщо ви розгортаєте новий бандл під тим самим іменем файлу, Google може відрендерити сторінку старим кодом, який звертається до вже видаленого API-ендпоінта. Проблему розв'язує додавання відбитка вмісту в ім'я файлу (`main.2bb85551.js`).

### 9. Залежність від cookies, сховища або WebSockets

За словами Google, local storage, session storage і cookies очищуються між завантаженнями сторінок, а WebSockets і WebRTC не підтримуються, бо Googlebot використовує звичайні HTTP-запити. Сторінка, яка перед показом контенту зчитує cookie згоди або збережений регіон, показує Googlebot порожній варіант за замовчуванням.

## Як перевірити, що Google насправді рендерить?

Порівняйте три версії сторінки: сирий HTML (перегляд коду або `curl`), HTML, який відрендерив Google (перевірка URL у Search Console), і те, що бачить користувач у браузері. Якщо важливого тексту, посилань чи тегів немає в перших двох, у вас проблема з рендерингом.

Ось практична процедура для одного шаблону за раз:

1. **Перевірка сирого HTML.** Виконайте `curl -s https://example.com/page | grep "your key sentence"` або відкрийте перегляд коду сторінки (не вкладку Elements у DevTools — там показано відрендерений DOM). Якщо H1, основний текст, canonical і внутрішні посилання на місці, краулери без рендерингу можуть прочитати сторінку.
2. **Відрендерений HTML у Search Console.** В інструменті перевірки URL запустіть *Перевірити URL наживо*, потім *Переглянути перевірену сторінку*, щоб побачити відрендерений HTML, скриншот і розділ *Докладніше* з ресурсами, які не вдалося завантажити, та повідомленнями консолі JavaScript. Саме на цей інструмент і Rich Results Test Google посилається у своєму [посібнику з усунення проблем](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript).
3. **Порівняння сигналів.** Переконайтеся, що title, [meta description](https://seorecheck.com/ua/blog/meta-description-best-practices), canonical і тег robots однакові в сирому та відрендереному HTML. Суперечливі значення — часта причина [проблем з індексацією](https://seorecheck.com/ua/blog/fix-website-indexing-problems).
4. **Перевірка індексу.** Пошукайте в лапках характерне речення з контенту, що завантажується через JS. Якщо сторінка в індексі, а речення не знаходиться, Google, імовірно, проіндексував неповний рендер.
5. **Вимкнення JavaScript.** Завантажте сторінку з вимкненим у браузері JavaScript. Те, що залишилося, приблизно відповідає тому, що отримує AI-краулер без рендерингу.

Вручну це працює для кількох шаблонів; для сотень URL потрібен краулер, який зберігає обидві версії. [Безкоштовний SEO-аудит SEORecheck](https://seorecheck.com/ua/request) завантажує ваші сторінки у справжньому браузері та позначає текст, видимий лише після виконання JavaScript, а також перевіряє доступ AI-краулерів у robots.txt.

Симптоми, що вказують саме на рендеринг, а не на якість контенту: багато URL у статусі «Проскановано – наразі не проіндексовано» на JS-шаблонах, Google показує загальні заголовки на кшталт назви вашого застосунку, а проіндексовані сторінки не ранжуються за жодною фразою з основного тексту. Розмежувати причини допоможуть наші посібники про [«Проскановано – наразі не проіндексовано»](https://seorecheck.com/ua/blog/crawled-currently-not-indexed-fix) та [помилки Search Console](https://seorecheck.com/ua/blog/google-search-console-errors-explained).

## Який спосіб рендерингу найкращий для SEO?

Server-side rendering або статичний рендеринг — найбезпечніший вибір для сторінок, які мають ранжуватися: увесь контент є в HTML, його може прочитати будь-який краулер, а JavaScript потім додає інтерактивність. Чистий client-side rendering підходить для екранів застосунку після входу, які й так не варто індексувати.

| Підхід | Контент у сирому HTML? | Добре для | На що зважати |
|---|---|---|---|
| Client-side rendering (CSR) | Ні | Дашборди, застосунки після входу | Невидимий для краулерів без рендерингу |
| Server-side rendering (SSR) | Так | Сторінки товарів, категорій, динамічні сторінки | Навантаження на сервер, розбіжності при гідратації |
| Статичний рендеринг / SSG | Так | Маркетингові сторінки, блоги, документація | Перезбирання при зміні контенту |
| Гібрид (SSR/SSG + гідратація) | Так | Більшість сучасних сайтів | Метатеги мають бути у відповіді сервера |
| Динамічний рендеринг | Лише для ботів | Тимчасове рішення для легасі | Google називає це обхідним шляхом |

Сторінка Google про [динамічний рендеринг](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) каже прямо: він «був обхідним рішенням, а не довгостроковим», і замість нього Google рекомендує server-side rendering, статичний рендеринг або гідратацію. Якщо ви досі використовуєте сервіс пререндерингу для ботів, плануйте його заміну.

Більшість фреймворків підтримують серверний вивід: Next.js і Remix для React, Nuxt для Vue, Angular SSR, SvelteKit і Astro. Переведення CSR-застосунку на SSR — це повноцінний проєкт, тож почніть із шаблонів, що приносять трафік: сторінок товарів, категорій, послуг і статей.

## У якому порядку виправляти проблеми рендерингу JavaScript?

Спершу виправляйте проблеми, що ховають цілі сторінки, потім ті, що ховають контент, і лише потім ті, що просто сповільнюють обробку. Хибний `noindex` або навігація, яку неможливо просканувати, коштує дорожче, ніж відкладений рендеринг, тож упорядковуйте виправлення за кількістю цінних URL, яких кожне з них стосується.

Розумний порядок:

1. **Блокери індексації:** `noindex` у сирому HTML, заблоковані JS/CSS/API-файли, soft 404.
2. **Виявлення:** перетворіть JavaScript-навігацію на посилання `<a href>`, а хеш-маршрути — на справжні шляхи.
3. **Контент у HTML:** перенесіть заголовки, основний текст, ціни та структуровані дані у відповідь сервера для шаблонів, що приносять гроші.
4. **Контент за взаємодією:** замініть контент, що підвантажується по кліку чи прокручуванню, на завантаження у viewport і URL пагінації.
5. **Гігієна:** додайте відбитки до імен бандлів, приберіть залежність від cookies і сховища, тримайте метатеги в сирому та відрендереному HTML однаковими.

Рендеринг впливає й на користувацький досвід: важкі бандли затримують найбільший елемент контенту й блокують введення, що видно в [Core Web Vitals](https://seorecheck.com/ua/blog/core-web-vitals-guide) як поганий LCP (понад 2,5 с) або INP (понад 200 мс). SSR часто покращує обидва показники, але вимірюйте, а не припускайте. Після кожного оновлення фреймворку повторюйте порівняння сирого й відрендереного HTML у межах [SEO-регресійного тестування](https://seorecheck.com/ua/blog/seo-regression-testing-website-updates): рендеринг ламається непомітно.

## Головне

- Google рендерить JavaScript на окремому етапі з чергою; усе, що зламалося там, до індексу не потрапляє.
- Багато AI-краулерів не виконують JavaScript, тож контент, якого немає в сирому HTML, може бути невидимим для AI-відповідей.
- Використовуйте справжні посилання `<a href>` і маршрути History API, а не обробники кліків чи URL з `#/`.
- `noindex` у сирому HTML може зупинити рендеринг у Google, тож надійно прибрати його JavaScript-ом не вийде.
- Сторінкам помилок у SPA потрібен справжній статус 404 або тег `noindex`.
- Для кожного шаблону порівнюйте сирий HTML із відрендереним HTML в інструменті перевірки URL.
- Для сторінок, які мають ранжуватися, обирайте server-side або статичний рендеринг; динамічний рендеринг Google називає обхідним шляхом.

Щоб побачити, як ці проблеми виглядають у готовому звіті, перегляньте [приклад звіту](https://seorecheck.com/ua/sample).

---

## Хочете знати, що виправити на своєму сайті?

Отримайте безкоштовне превʼю SEO-аудиту: оцінку й реальні проблеми з доказами з ваших сторінок.

- [Отримати безкоштовне превʼю аудиту](https://seorecheck.com/ua/request)
- [Переглянути приклад звіту](https://seorecheck.com/ua/sample)