React та інші JavaScript-фреймворки зробили розробку застосунків і створення сайтів значно швидшими. Але для SEO це справжній виклик: сторінки індексуються повільніше, а частина контенту може взагалі бути невидимою для пошукових систем без належного технічного налаштування та внутрішньої перелінковки.
Тепер до цього додається ще й фактор штучного інтелекту (AI). Сайт намагаються сканувати не лише Google чи Bing, а й ChatGPT, Perplexity та інші AI-системи. Щоб правильно їх проіндексувати й ранжувати, потрібна чітка структура та чистий HTML (який у SPA-сайтах рендериться лише на клієнтській стороні). Тож як змусити їх «бачити» ваш JavaScript, якщо AI-боти навіть не можуть його обробити?
Авторка цього кейсу — Елісон Рід, SEO-стратегиня в Ohayu — компанії, що створила власну eSIM і надає доступний мобільний інтернет для міжнародних мандрівників. У цій статті ділюсь досвідом оптимізації React-сайту та пояснюю, що мають робити власники односторінкових застосунків, щоб індексуватися пошуковиками та генеративними ШІ-системами.
SSR та SPA: у чому різниця
Ми всі добре знаємо, як працювати з SSR (server-side rendering) сайтами. Більшість SEO-фахівців «собаку з'їли» на WordPress, Shopify або конструкторах сайтів. Контент таких сторінок є статичним, створюється на сервері та надсилається всім користувачам і пошуковим ботам у незмінному вигляді.
Приклад: перегляньте будь-яку сторінку блогу Collaborator, наприклад, статтю Олександри Хілової https://collaborator.pro/blog/link-building-startups. Перевірте елементи за допомогою інструментів перевірки, а потім спробуйте знайти ті ж HTML-теги, що й нас сторінці
source.view-source:https://collaborator.pro/blog/link-building-startups
Ви побачите, що HTML аналогічний. Боти пошукових систем та боти штучного інтелекту легко отримають доступ до цього контенту та проіндексують його. Так зазвичай виглядає SSR.
А от SPA (single-page application) JavaScript-сайти, побудовані на фреймворках React, Vue або Angular, мають зовсім іншу логіку і більше схожі на мобільні додатки. Сторінки рендеряться у браузері, тому під час першого візиту бот бачить лише порожній шаблон JSON із підключеними скриптами (однаковий для кожної сторінки сайту), а не сам контент. Через це індексація та ранжування ускладнюються.
Приклад: перевірте сторінку https://ohayu.com/esim/united-states-us/, перегляньте елементи SPA-сторінки в браузері, і побачите, що всі заголовки та контент знаходяться на своїх місцях. Але якщо переглянете джерело за допомогою view-source:https://ohayu.com/esim/united-states-us/, побачите лише стандартний скрипт без контенту.
Це типовий випадок для SPA. Такі сайти зручні й гнучкі, адже легко:
- проводити A/B-тестування;
- вносити масові зміни;
- персоналізувати користувацький досвід;
- використовувати спільний бекенд для мобільної та вебверсії.
Але саме ця динамічність і створює труднощі для SEO.
Якщо порівняти обидві технології з чимось більш звичним, SSR — як друкована книга: відкриваєте сторінку, а текст уже є. Все видно як користувачеві, так і пошуковій системі, всі сторінки на своїх місцях. SPA більше схожий на електронну книгу, де контент з'являється тільки тоді, коли користувач взаємодіє з ним. Для людини все виглядає нормально, але для Google або інших пошукових систем сторінка може виглядати порожньою під час першого відвідування.
Щоб пошукові системи могли «бачити» контент так само як користувачі, SPA потребують додаткових рішень.
Пошукові системи та сайти JavaScript SPA
Щоб зрозуміти, чому динамічні сторінки не індексуються належним чином пошуковими системами, згадаймо базові етапи роботи Google:
- Crawling (сканування) — боти переходять за посиланнями та збирають дані.про відвідані сторінки (щоб освіжити знання, дивіться просте пояснення у статті «How Google Search works»).
- Indexing (індексування) — пошукова система аналізує отриманий контент, структуру, ключові слова та медіафайли і додає сторінку до своєї бази даних.
- Ranking (ранжування) — коли користувач вводить запит, Google вибирає найрелевантніші сторінки з індексу і сортує їх за кількома факторами
Джерело: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
Чому Google більше «любить» статичні SSR-сторінки
Статичні сторінки відразу віддають готовий HTML-код з усім контентом. Це швидко і бот не витрачає ресурси на рендеринг JavaScript.
Динамічні сторінки (SPA на React, Vue, Angular) повертають мінімальний HTML-код, а основний текст і блоки генеруються в браузері. Щоб обробити фактичний вміст, Google має запустити додатковий процес — рендеринг. Це ресурсозатратно, повільно і не завжди успішно.
У результаті:
- статичні сторінки індексуються швидше;
- контент обробляється повністю;
- бот пошукової системи витрачає менше crawl budget (обмежений ресурс, який визначає, скільки сторінок Google готовий просканувати на вашому сайті протягом певного періоду часу, див. JavaScript SEO basics).
Ось проста порівняльна таблиця:
Якщо спростити: Google — це бібліотекар. Якщо принести йому надруковану книгу, він одразу поставить її на полицю. Але якщо дати набір порожніх сторінок з інструкціями (SPA), бібліотекар повинен буде сам зібрати книгу. І немає гарантії, що він це зробить.
Google стверджує, що вміє обробляти JavaScript, але на практиці рендеринг SPA часто затримується або не спрацьовує — через великі бандли, клієнтську навігацію чи обмеження crawl budget.
На сьогодні Google — єдиний пошуковик, який частково справляється з JavaScript-індексацією. Інші мають труднощі:
- Bing — підтримка JavaScript покращилася, але складні SPA нестабільні.
- DuckDuckGo, Yahoo — залежать від Bing, тож мають такі ж обмеження.
- Baidu, Naver, Seznam — динамічний контент майже не індексують.
- AI-платформи на кшталт ChatGPT, Claude, Perplexity взагалі не рендерять JavaScript.
- Meta, LinkedIn, X та інші соціальні мережі також не рендерять JavaScript.
Висновок: щоб сайт був правильно проіндексований і доступний для AI-ботів та соціальних мереж, потрібні додаткові технічні рішення. Далі я покажу, що саме ми вже реалізували та продовжуємо впроваджувати на SPA сайті.
Налаштування SPA + SSR
Налаштування сайту Ohayu eSIM складається з двох технічно різних частин:
- головна та сторінки країн — React-based SPA (динамічні);
- блог — SSR на базі WordPress (статичний).
На старті сайт складався з 200 SPA-сторінок. І без додаткових виправлень за перші 6 місяців Google проіндексував менше ніж 50 сторінок (<25%). У результаті — менше ніж 10 тис. показів на місяць, сніпети Open Graph не працювали, а сайт був повністю невидимий для Bing або LLM.
Розуміючи проблему, ми почали вносити зміни в SPA і одночасно запустили блог WordPress на тому ж домені (/blog/), щоб збільшити трафік і порівняти результати SPA і SSR.
Етап 1: Технічні та On-Page SEO-завдання
Ми розділили базову SPA-оптимізацію на два напрямки: технічне SEO та On-Page оптимізацію.
Technical SEO для SPA
On-page SEO для SPA
Цей чекліст підходить для будь-якого SPA і є базовим — без нього контент просто не буде ефективно індексуватись. Після основних технічних правок і контентної оптимізації ми перейшли до наступного етапу — пререндерингу.
Етап 2: Prerendering для SPA
Щоб вирішити проблеми з індексацією та розширити семантичне ядро, ми підключили Prerender.io (3 квітня 2025 року). Цей сервіс кешує сторінки SPA у вигляді статичного HTML, що спрощує для пошукових систем процес краулінгу та індексації контенту.
Ми зробили наступне:
- підключили Prerender до SPA;
- надсилали кешовані HTML-версії Googlebot, Bingbot та іншим ботам;
- регулярно перевіряли логи, щоб упевнитись, що боти отримують prerender-версії сторінок;
- протестували швидкість індексації та видимість контенту в пошуковій видачі.
Ми вирішили запускати протокол prerendering лише для пошукових систем, соцмереж і AI-ботів. Це дозволило продовжити A/B-тестування продукту та персоналізацію, адже користувачі, як і раніше, отримували динамічну версію сайту.
На скриншотах видно, що після встановлення prerendering AI-боти почали активно сканувати сайт (47,95% усіх запитів), далі йдуть соцмережі (17,27%) і, звісно, боти пошукових систем (11,45%).
Результати:
- індексація покращилася з <25% до ~80% сторінок за країнами;
- краулінговий бюджет Google збільшився з ~600 до 1400 сторінок на день згідно з Google Search Console.
- кількість показів збільшилася більш ніж у 5 разів;
- метадані Open Graph почали коректно працювати в соціальних мережах;
- Bing і Yandex підхопили та проіндексували контент;
- контент став доступним для ChatGPT та інших LLM.
Водночас ми залишили активним блог на WordPress. Це дозволило порівняти результати SPA + prerender із продуктивністю традиційного SSR.
Етап 3: Результати та порівняння (SPA + Prerender vs WordPress SSR)
Ми паралельно вели блог на WordPress, щоб стабілізувати й нарощувати органічний трафік:
- опубліковано близько 80 постів;
- 5 000 кліків на місяць;
- ~1 млн показів;
- середня позиція в Google — 13,9;
- регулярна поява в AI Overviews.
Постійне ведення блогу на тому ж домені дозволило порівнювати дві технології і відстежувати стабільність індексації після Google Core Updates. Після чергового оновлення алгоритму в червні 2025 року частина сторінок сайту випала з індексу. Ми швидко проаналізували кластери URL і побачили наступне:
*Співвідношення Crawl:Index — це відношення кількості сторінок, які пошукова система просканувала, до кількості сторінок, які потрапили до індексу. Якщо показник високий (наприклад, 80–90%), це означає, що більшість сторінок, які бачить бот, доступні та достатньо якісні, щоб бути у пошуку.
Фактично, це показник ефективності індексації: він демонструє, наскільки crawl budget перетворюється у видимість у результатах пошуку.
У нашому випадку таблиця показує, що SSR забезпечує стабільнішу індексацію сторінок (96%), навіть після оновлень Google Core Updates. Натомість SPA залишається більш чутливою до змін алгоритмів, навіть із використанням prerendering.
Після трьох місяців експериментів ми зібрали достатньо даних, щоб порівняти обидва підходи:
SPA (React-сайт) + Prerender:
- сторінки індексуються, але не завжди стабільно;
- кешування працює добре, проте новий контент з’являється в Google із затримкою;
- частину структурованих даних пошуковики ігнорують або обробляють лише частково.
SSR (блог на WordPress):
- сторінки індексуються швидко та надійно;
- FAQ-структура повністю розпізнається;
- внутрішнє лінкування підвищує ефективність обходу сайту ботом;
- контент починає ранжуватись за long-tail запитами вже через кілька годин (після подачі через IndexNow).
Головний висновок: prerender допоміг тимчасово, але це не остаточне рішення. Для стабільного довгострокового зростання потрібен SSR або гібридний рендеринг.
SEO-рекомендації для JavaScript SPA-проєктів
Наш досвід з Ohayu показав: без SSR або prerendering будь-який сайт на React-SPA втратить видимість, навіть якщо контент якісний.
Ось кілька порад для SEO-фахівців, розробників і власників бізнесів, які працюють із React-сайтами:
1. Не бійтеся використовувати інструменти prerendering — наприклад, Rendertron, Prerender.io. Вони допомагають ботам бачити контент, навіть якщо індексація відбувається не завжди стабільно.
2. Як альтернативу, розгляньте SSR / гібридний рендеринг в проєктах — Next.js, Nuxt.js, Remix. Це підхід, коли сторінки можуть створюватися заздалегідь (як у SSR) і водночас оновлюватися з певним інтервалом, без повного рендерингу на кожен запит. Такий варіант вважається «золотою серединою», бо забезпечує швидкість і стабільність статичного контенту, але при цьому дозволяє підтримувати актуальність даних без перевантаження сервера. У межах одного проєкту можна розділити технології відповідно до цілей:
- SSR — для динамічних сторінок;
- SSG — для статичних сторінок;
- ISR — для сторінок, що оновлюються «на льоту».
3. Постійно моніторте краулінг та індексацію — Google Search Console та серверні логи допоможуть швидко виявити проблеми й уникнути втрат для бізнесу.
4. Посилюйте внутрішню перелінковку — особливо з авторитетних розділів (наприклад, блогу на WordPress) на SPA-сторінки.
5. Контент-стратегія — створюйте унікальний, якісний контент з продуманим внутрішнім лінкуванням. Просто зробити сторінку доступною — недостатньо. Вона має бути вартою індексації та ранжування.
6. Регулярно проводьте технічні перевірки: canonical, robots.txt, OpenGraph, швидкість сторінок, 4xx/301.
Підсумок: prerender — це лише тимчасове рішення. Для досягнення масштабних SEO-результатів, особливо у конкурентних нішах, SSR (або хоча б частковий SSR) — найкращий варіант.
Додаткові ресурси:
Схожі статті
