React SEO: як оптимізувати JavaScript-сайти для пошукових систем та ШІ
- Тетяна Кучер
- 16 вер.
- Читати 7 хв
React та інші JavaScript-фреймворки зробили розробку застосунків та створення сайтів набагато швидшими. Проте для SEO це справжній виклик — сторінки довше індексуються, а частину контенту пошуковики можуть взагалі не побачити за відсутності правильних технічних налаштувань та внутрішньої перелінковки.
До цього додається ще один фактор — штучний інтелект. Сьогодні контент із сайтів збирають не лише Google чи Bing, а й ChatGPT, Perplexity та інші ШІ-системи. Щоби вони могли правильно просканувати, проіндексувати та ранжувати ваш сайт, їм потрібна зрозуміла структура та чистий HTML (який в React-сайтах розгортається лише на клієнті). То як же змусити їх проіндексувати те, що ШІ-боти не в змозі навіть «побачити»?
Авторка цієї колонки — Еллісон Рід, SEO-стратегиня в Ohayu, компанії, що створила власну систему eSIM та надає послуги доступного мобільного інтернету для міжнародних подорожей.
У матеріалі для High Bar Journal експертка поділилась досвідом із пошукової оптимізації сайту на React та розповіла, до чого треба бути готовим власникам односторінкових застосунків, які хочуть бути проіндексованими Google, ChatGPT та іншими пошуковими і ШІ системами.
SEO та React-сайти (SPA)
React-сайти, в яких рендеринг контенту відбувається на боці користувача, працюють на кшталт мобільного застосунку.
Порівняємо два підходи: SSR (server-side rendering, звичайний сайт з рендерингом на стороні сервера, де сторінки вже існують в зібраному вигляді та передаються клієнту й пошуковикам); та SPA (single-page application, де рендеринг відбувається на клієнті після запиту).
Звичайний сайт (SSR) працює як паперова книга: відкрив сторінку — і текст одразу розгортається перед тобою. Все видно і людині, і пошуковику, всі сторінки з друкованими літерами на своєму місці.
Односторінковий сайт-застосунок (SPA) без додаткових налаштувань більше схожий на електронну книгу, де зміст з’являється лише тоді, коли користувач почне взаємодіяти із вмістом, і комп’ютер чи телефон «підвантажить» його. Для користувача це виглядає нормально, але для Google чи інших пошукових систем на перший погляд сторінка може виглядати порожньою.
Саме тому потрібні додаткові рішення, щоб пошуковики теж «бачили» динамічні сторінки React-сайту так само швидко, як люди.
Пошукові системи та SPA
Щоб зрозуміти, чому динамічність сторінок не влаштовує пошукові системи, подивимось на те, як працюють пошуковики на прикладі Google.
У пошуку Google є три головні етапи роботи з будь-яким сайтом:
Краулінг (Crawling) — бот переходить за посиланнями, «завантажує» сторінки та зберігає код. Офіційне пояснення від Google: How Search works – Crawling & indexing.
Індексація (Indexing) — бот аналізує вміст, структуру, ключові слова, медіа й додає сторінку у свою базу даних.
Ранжування (Ranking) — коли користувач вводить запит, Google обирає з індексу сторінки, що найкраще відповідають, і сортує їх за багатьма факторами.
Чому Google любить статичні сторінки?
Статичні сторінки одразу віддають готовий HTML-код із усім контентом. Це швидко, бот не витрачає ресурси на рендеринг JavaScript.
Динамічні сторінки (SPA, React, Vue, Angular) віддають мінімальний HTML, а основний текст і блоки генеруються у браузері. Для цього Google має запускати додатковий процес — рендеринг. Це дорого, повільно і не завжди успішно.
Через це:
статичні сторінки індексуються швидше;
контент майже завжди враховується повністю;
бот менше витрачає «crawl budget» (обмежений ресурс, скільки сторінок Google готовий обійти на вашому сайті).
Тобто Google — свого роду бібліотекар. Якщо ви приносите йому готову роздруковану книгу (статичну сторінку) — він одразу кладе її на полицю. А якщо даєте конструктор із порожніх сторінок та інструкцій (SPA) — бібліотекарю ще треба самому збирати книжку. І не факт, що він складе її до кінця.
Ось проста таблиця для порівняння.
SPA (React, Vue, Angular) vs статичні сторінки
Етап | Статичні сторінки | SPA (динамічні) |
Краулінг | Googlebot бачить готовий HTML-код одразу. | Бот бачить мінімальний HTML, без контенту. Потрібен додатковий рендеринг. |
Індексація | Контент додається в індекс швидко й повністю. | Частина контенту може не потрапити в індекс або з’явитися із затримкою. |
Ранжування | Є всі дані для аналізу, шанси на високу видимість кращі. | Якщо бот не зміг «зібрати» сторінку або пропустив елементи — ранжування гірше. |
Краул-бюджет | Використовується ефективно, бот проходить більше сторінок. | Рендеринг з’їдає ресурс, менше сторінок потрапляє в індекс. |
Швидкість для бота | Дуже швидко. | Повільно і ресурсозатратно. |
Google заявляє, що може обробляти JavaScript, але на практиці рендеринг SPA часто затримується або зовсім не відбувається через великі бандли, клієнтську навігацію та обмеження краул-бюджету.
Наразі Google — єдиний пошуковик, який хоч якось справляється з індексацією JavaScript. Решта систем із цим мають великі проблеми, серед них такі:
Bing — підтримка JavaScript покращилася, але зі складними SPA працює нестабільно.
DuckDuckGo і Yahoo — використовують індекс Bing, тому обмеження такі ж самі.
Baidu, Naver, Seznam — фактично не індексують динамічний контент.
ШІ-платформи як-от ChatGPT, Claude, Perplexity взагалі не рендерять JavaScript.
Meta, LinkedIn, X та інші соціальні мережі не рендерять JavaScript.
Тож якщо ми хочемо, щоб сайт успішно індексувався та був доступним для ботів ШІ та соціальних мереж, необхідно впровадити додаткові технічні рішення і далі я розповім, що саме ми вже зробили і плануємо продовжити на сайті Ohayu.
SPA + SSR архітектура на прикладі сайту Ohayu
Сетап сайту Ohayu складається з двох технічно відмінних частин:
Головна сторінка та сторінки країн реалізовані як SPA на основі React (динамічні).
Блог — SSR на основі WordPress (статичний).
При відвідуванні головної сторінки сайту ви побачите безліч текстів, зображень, та інтерактивних елементів.
Проте якщо ви хочете переглянути вихідний HTML, відкривши в браузері view-source:https://ohayu.com/, та спробуєте знайти <h1> заголовок сторінки, або бодай слово з тексту сторінки, нічого не вийде.
Усе, що ви там знайдете — це базові метадані, які виводяться за замовчуванням на цій та інших сторінках сайту, а також кілька скриптів, які й ініціюють рендеринг на боці клієнта. Той самий плейсхолдер відображається і на сторінках країн США, Туреччини, України та інших.
Така поведінка — типова ознака односторінкових застосунків (SPA). Зазвичай такі сайти є досить гнучкими та динамічними, на них легко запускати А/B-тести, вносити масові зміни, персоналізувати користувацький досвід, ділити спільний бекенд між вебверсією та застосунком. Але саме динамічний принцип роботи таких сторінок створює проблеми для пошукової оптимізації.
Проблеми та рішення
Загалом SPA використовується для сторінок eSIM по країнах (їх понад 200 сторінок). На початковому етапі без додаткових рішень Google проіндексував менше 50 сторінок (<25%), показів було менше 10 000 на місяць, Open Graph-сніпети соцмереж не працювали, сайт не відображався в Bing та LLM.
Розуміючи проблемність цього рішення ми почали впроваджувати зміни в SPA, а також паралельно вели блог на WordPress на тому ж домені (/blog/) для нарощування трафіку і порівняння результатів між SPA та SSR.
Етап 1: технічне та оn-page SEO
Ми розбили оптимізацію SPA на два напрямки — технічне SEO та on-page оптимізацію.
Технічне SEO
Дія | Призначення | Результат |
XML-карта сайту | Покажчик для ботів | Покращений crawl flow |
Навігація та структура сайту | Логічна структура | Легше індексувати сторінки |
Internal linking з різними анкорами | Підтримка краул-бюджету | Краще ранжування сторінок |
Canonical tags | Уникнення дублювання | Коректна індексація |
4xx та 301 редиректи | Створення правильних статус-кодів для сторінок, виправлення помилок Search Console | Зменшення марного обходу, повністю зникли soft 404 |
Зручні URL-адреси | Зрозумілі URL з ключовим терміном eSIM та назвою країни | Краща релевантність ключових слів |
Structured data (FAQ, Reviews, Breadcrumbs) | Rich snippets | Підвищений CTR |
Robots.txt | Контроль індексації | Більш ефективний розподіл краул-бюджету |
Моніторинг у Search Console | Виявлення проблем | Регулярні виправлення |
Он-пейдж SEO
Дія | Призначення | Результат |
Унікальні метадані для всіх індексованих сторінок | Покращення видимості | Вища CTR та покази |
Noindex для службових URL | Видалення непотрібних сторінок | Чистий індекс |
Ієрархія заголовків HTML | Зрозуміла структура | Зручний для SEO контент |
Alt-теги для зображень | Доступність та контент для ботів | Допомога індексації |
Внутрішні посилання в тілі сторінки | Підтримка ключових сторінок | Кращий crawl flow |
External references & backlinks | Довіра та E-E-A-T (experience, expertise, authoritativeness, trustworthiness) | Підвищення авторитету |
Унікальний контент (FAQ, відгуки, geo-info, country-specific data) | Уникнення дублювання | Зростання релевантності та E-E-A-T |
Цей чекліст підходить для будь-якого SPA і є базовим етапом, без якого контент не буде ефективно індексуватися. Після реалізації основних технічних задач та базової оптимізації контенту сторінок, ми перейшли до наступного етапу - інтеграція пререндерингу.
Етап 2: Пререндеринг для SPA
Щоби ботам, які не виконують JS, відображався повний контент, ми впровадили Prerender.io. Протокол пререндерингу вирішили запускати лише для конкретних агентів за заданим нами списком. Це допомогло нам далі проводити стандартні тести та персоналізацію з користувачами, які, як і раніше, отримують динамічну версію сайту.
На скріншотах статистики можна побачити, що після пререндерингу, саме ШІ-боти почали активно сканувати сайт (47.95% від усіх запитів), на другому місці - соціальні мережі (17.27%) і, звісно, боти пошукових систем (11.45%).
Результати
Google бюджет-краул зріс із ~600 до 1400 сторінок за день відповідно до Search Console.
Більшість сторінок eSIM-каталогу почала індексуватися в Google і Bing (>200).
Відображаються правильні Open Graph-сніпети для соцмереж.
Контент став доступним для ChatGPT та інших LLM.
Етап 3: порівняння SPA та SSR (WordPress)
Ми вели блог на WordPress паралельно зі SPA для стабілізації та нарощування органічного трафіку. Які результати ми отримали?
Опубліковали ~80 постів.
Отримали 5000 кліків на місяць.
Ще ~1 млн показів.
Мали середню позицію в Google — 13.9.
Регулярна з'являлися у AI Overviews.
Регулярне ведення блогу на тому ж домені допомогло нам порівняти дві технології та відстежити стабільність індексації після Google Core Updates. Так, після чергового оновлення алгоритму у червні 2025 року, частина сторінок сайту випала з індексу і ми швидко провели аналіз за кластерами URL та зробили висновки щодо двох технологій.
Кластер | Технологія | Індексовані сторінки | Crawl:Index ratio | Стабільність |
Blog (/blog/) | SSR | 137 | 96% | Висока, без втрат при апдейтах |
Country Store (/esim/) | SPA + Prerender.io | 200 | 80% | Середня, частина сторінок досі випадає з індексу |
Crawl:index ratio — це співвідношення між кількістю сторінок, які пошуковик просканував, і кількістю сторінок, які реально потрапили в індекс.
Якщо показник високий (наприклад, 80-90%), це означає, що більшість сторінок, які бачить бот, доступні й достатньо якісні, щоби бути в пошуку. Фактично це індикатор ефективності індексації: показує, чи конвертується краул-бюджет у видимість у пошуковій видачі.
У нашому випадку, таблиця показує, що SSR забезпечує більш стабільну індексацію сторінок (96%), навіть після Google Core Updates, SPA архітектура досі більш чутлива до змін алгоритму, навіть з використанням пререндерингу.
Ми зробили такі висновки:
SPA без SSR-пререндерингу: низька індексація, обмежений краул-бюджет, проблеми з LLM і соцмережами.
SPA + Prerender.io: покращена доступність, але crawl:index ratio досі слабкий.
SSR/WordPress: стабільний, прогнозований, без втрат під час апдейтів.
Паралельний блог — дієвий варіант для обмежених SPA-сайтів.
SEO-рекомендації для React SEO-проєктів
Наш досвід із Ohayu показав, що без SSR або пререндерингу будь-який React-SPA сайт буде програвати у видимості, навіть якщо контент якісний.
Наостанок хочу дати декілька порад колегам, розробникам та власникам бізнесу, які матимуть справу з сайтами на React.
Не зволікайте з використанням інструментів пререндерингу. Рекомендую Rendertron, Prerender.io.
Як альтернативу, використовуйте в проєктах SSR / Hybrid Rendering – Next.js, Nuxt.js, Remix — це підхід, де сторінки можуть генеруватися наперед (як у SSR) і при цьому оновлюватися з певним інтервалом без повного рендерингу на кожен запит. Такий варіант часто вважають «золотою серединою», бо він дає швидкість і стабільність статичного контенту та водночас дозволяє підтримувати актуальність даних без великого навантаження на сервер.
В межах одного проєкту можна розподілити технології відповідно до цілей: SSR (динамічні сторінки); SSG (статичні сторінки); ISR (оновлення на льоту).
Завжди проводьте моніторинг індексації. Google Search Console, Ahrefs допоможуть виявити проблеми з індексацією на ранніх етапах та уникнути бізнес-втрат.
Контентна стратегія. Не забувайте створювати унікальний контент, якісне внутрішнє лінкування, оскільки мало просто зробити сторінку доступною — треба створити контент, достатньо релевантний для індексації та ранжування.
Проводьте регулярні технічні перевірки — canonical, robots.txt, Open Graph, швидкість сторінки, 4xx/301.
