Ви зробили все правильно. Сторінки швидкі, метатеги на місці, структуровані дані є, Google Search Console показує зростання показів. А коли ви питаєте ChatGPT про свою нішу, вашого продукту у відповіді немає. І це не тому, що ви погано попрацювали над SEO. Просто пошуковий робот Google і робот OpenAI мають різні можливості, і ваш проєкт потрапив рівно в цю щілину.
Ми з нашими Laravel-розробниками стикаємось із цим останнім часом регулярно. Спершу здавалось, що це поодинокі історії й проблема десь у конкретному проєкті. Потім я подивився на це підряд по кількох клієнтах і зрозумів, що річ системна: причина в одному технічному рішенні, яке ухвалюють на старті й потім майже ніколи не переглядають.
Нижче розберу, у чому саме асиметрія, як вона стосується конкретних режимів рендерингу в Laravel і що з цим робити. З цифрами й перевіркою, яку можна зробити самому за хвилину.
Асиметрія, з якої все починається
Ось факт, який пояснює більшість подібних історій.
Googlebot виконує JavaScript. У Google є окремий етап рендерингу: робот завантажує сторінку, запускає скрипти в безголовому браузері й індексує те, що вийшло після виконання коду. Bingbot робить приблизно те саме.
Краулери ШІ-сервісів JavaScript не виконують. Вони забирають сирий HTML з першої відповіді сервера, парсять розмітку й на цьому зупиняються. Ніякого безголового браузера, ніякого очікування гідратації.
Це не здогад. У грудні 2024 року Vercel разом із MERJ опублікували аналіз понад 500 мільйонів звернень краулерів і не знайшли жодного великого ШІ-краулера, який виконує JavaScript. Окрема деталь із того ж дослідження, яка свого часу здивувала нашу команду: краулери ChatGPT завантажують файли JavaScript приблизно в 11,5% запитів, але ніколи їх не запускають. Тобто вони бачать, що скрипт існує, скачують його й не роблять з ним нічого.
Практичний наслідок простий і неприємний. Ви можете пройти всі перевірки в Search Console, бачити нормальну індексацію й при цьому бути порожньою сторінкою для будь-якого ШІ-сервісу.
Хто до вас ходить і що вміє
І окремо про поширену плутанину. Google-Extended це не краулер. Це перемикач, який керує тим, чи можна використовувати ваш контент для навчання моделей Google. Він не впливає на те, чи покажуть вас в AI Overviews, бо туди контент потрапляє через звичайний Googlebot. Ми натрапляли на кілька проєктів, де Google-Extended закрили в надії прибрати сайт із ШІ-відповідей, а потім не могли зрозуміти, чому нічого не змінилось.
Що саме повертає Laravel у кожному режимі
Тепер до конкретики. Laravel сам по собі нічого не ламає, але дає кілька дуже різних способів віддавати сторінку. Різниця між ними вирішує все.
Blade
Класичні шаблони рендеряться на сервері. У відповідь іде повний HTML з усім текстом, заголовками й посиланнями. Браузер може показати сторінку взагалі без JavaScript.
Для контентних сторінок це найнадійніший варіант. Якщо у вас Blade, проблем із видимістю фреймворк вам не створить.
Livewire
Тут теж усе гаразд, хоч це й неочевидно через назву. На першому завантаженні компонент рендериться на сервері через той самий Blade, і в первинній відповіді вже лежить готова розмітка. JavaScript лише «оживляє» її й далі обробляє взаємодії, надсилаючи запити назад на сервер і отримуючи діфи.
Тобто перегляд коду сторінки покаже вам серверну версію компонента. Агент побачить те саме.
Inertia з Vue або React, режим за замовчуванням
А ось тут починається проблема. Inertia віддає невелику Blade-оболонку, всередину якої вкладає JSON з назвою компонента й пропсами. Сам компонент на сервері не рендериться. Вміст малює Vue чи React уже в браузері, після завантаження бандла.
Для людини різниці немає, сторінка з’являється миттєво. Для агента, який не виконує JavaScript, у відповіді лежить порожній контейнер і трохи JSON.
Саме тут і виникає та сама асиметрія. Googlebot виконає скрипти й побачить вміст. OAI-SearchBot не виконає й не побачить. Один і той самий URL, різний результат.
Inertia з увімкненим SSR
Inertia вміє рендерити компоненти на сервері, і це офіційно підтримана можливість, а не милиця. Схема така: Laravel обробляє запит, передає дані сторінки в окремий рендерер, той повертає готовий HTML-рядок, і Laravel вкладає цей HTML у Blade-оболонку. У первинній відповіді з’являється справжній вміст, а гідратація відбувається поверх нього.
Важлива деталь для тих, хто це вмикатиме: SSR-рендерер це окремий процес Node, який має постійно працювати поруч із вашим PHP-застосунком. Його треба запустити, тримати живим через менеджер процесів і перезапускати після кожного деплою, бо він тримає в пам’яті стару збірку. Найпоширеніша причина «ми вмикали SSR, але не працює» саме така: процес упав або не перезапустився після викладки, а сайт продовжив віддавати оболонку. Тому SSR потребує моніторингу так само, як черги чи планувальник.
Laravel як API з окремим фронтендом
Якщо Laravel у вас це тільки бекенд, питання видимості вирішується не в ньому. Дивіться на фронтенд і на те, чи є там серверний рендеринг. Сам API до індексації стосунку не має.
Перевірка, яка займає хвилину
Не вгадуйте. Витягніть сторінку так, як це робить агент, тобто без браузера й без виконання скриптів:
curl -A «OAI-SearchBot» https://ваш-сайт/сторінка | grep «текст, який має бути на сторінці»
Якщо текст знайшовся, все гаразд. Якщо у відповіді лише каркас, порожній контейнер і теги скриптів, то для ретриву ваша сторінка порожня.
Раджу перевіряти не головну, а саме ті сторінки, заради яких усе робиться: картки товарів, статті, сторінки послуг. У кількох проєктах ми натрапляли на те, що головна віддавала нормальний HTML, бо була на Blade, а весь каталог жив в Inertia без SSR. Формально сайт «серверний», фактично невидимий там, де це важливо.
Дрібниці, які ламають видимість уже після рендерингу
Коли з рендерингом розібрались, лишається кілька речей, на яких Laravel-проєкти спотикаються регулярно.
Час відповіді. Якщо серверний рендеринг важкий, агент може не дочекатись. Найчастіша причина в Laravel це запити в циклі: на сторінку категорії летить сотня звернень до бази замість одного, бо звʼязки завантажуються ліниво. Це лікується попереднім завантаженням звʼязків і кешем, і дає більше, ніж будь-яка робота над текстом.
Чесні коди відповідей. Сторінка, що віддає 200 із написом «нічого не знайдено», засмічує індекс. У Laravel це виходить ненавмисно, коли контролер повертає порожню колекцію замість того, щоб кинути виняток. Перевіряйте реальні статуси, а не те, що бачить користувач.
Кеш конфігурації після деплою. Класика: локально працює, на проді віддається старе, бо кеш конфігурації чи маршрутів не скинули. Разом з ним, до речі, часто не перезапускають і SSR-процес.
robots.txt, написаний нашвидкуруч. Порада «закрийте ботів OpenAI» гуляє по інтернету без пояснень, і люди закривають усе, що містить у назві GPT. Разом із тренувальним GPTBot під роздачу потрапляє пошуковий OAI-SearchBot, після чого сайт системно випадає з кандидатів на цитування. Якщо ви хочете закрити навчання, але лишитись у пошуку, це різні агенти й різні рядки.
Блокування на рівні CDN. Окремо перевірте налаштування Cloudflare або що у вас там стоїть. Там є готові перемикачі блокування ШІ-ботів, які легко ввімкнути, забути й потім довго шукати причину.
Порядок дій, якщо вас не видно
Порядок тут важливіший за старанність. Немає сенсу переписувати тексти, поки сервер віддає порожню оболонку.
- Перевірте curl-ом, що в серверній відповіді є текст. Поки цього немає, решта не має значення.
- Якщо повертається оболонка, вмикайте SSR або переносьте контентні сторінки на Blade чи Livewire.
- Переконайтесь, що SSR-процес живий і перезапускається при деплої.
- Перевірте коди відповідей і час генерації сторінки.
- Перевірте robots.txt і налаштування CDN, розділивши тренувальних і пошукових агентів.
- І лише потім беріться за структуру тексту й розмітку.
Що Laravel дає, коли база в порядку
Коли сервер віддає нормальний HTML, фреймворк починає працювати на вас, і це справді зручно.
Структуровані дані збираються на бекенді з тих самих сутностей, що й видимий текст. Вам не треба дублювати дані в шаблоні руками, а отже вони не розʼїдуться з часом. Та сама історія із заголовками, описами й сайтмапом: якщо вони генеруються з бази, то показують реальний стан, а не те, що було рік тому.
Узгодженість між розміткою й видимим текстом важить більше, ніж наявність розмітки як такої. Коли структуровані дані кажуть одне, а на сторінці написано інше, це не додає довіри, а забирає її.
Чого ми не знаємо й де межі цього розбору
Кілька чесних застережень, без яких висновки виглядатимуть надто впевненими.
Поведінка краулерів може змінитись. Дані про виконання JavaScript це зріз на кінець 2024 року плюс профільні матеріали 2026-го. Ніхто не заважає OpenAI додати етап рендерингу завтра, і тоді частина цієї статті застаріє. Перевіряйте на своєму проєкті, а не покладайтесь на статті, включно з цією.
Наявність у HTML не гарантує цитування. Серверний рендеринг це необхідна умова, а не достатня. Він лише дає системі можливість прочитати ваш текст. Чи оберуть саме ваш фрагмент серед десятків кандидатів, вирішує вже зовсім інша логіка, і на неї рендеринг не впливає.
Ми не міряли частку кожного агента на своїх проєктах. Цифри про 500 мільйонів звернень і 11,5% це чуже дослідження, на яке ми спираємось, а не наш власний замір. Свої логи ви можете подивитись самі, і це буде точніше за будь-яку загальну статистику.
Коротко
Googlebot і Bingbot виконують JavaScript, а краулери ChatGPT, Perplexity й Anthropic ні. Тому проєкт на Inertia без SSR може мати нормальні позиції в Google і бути порожньою сторінкою для ШІ-сервісів. Blade і Livewire віддають серверний HTML і проблем не створюють, Inertia за замовчуванням віддає оболонку, а його SSR це окремий процес Node, який треба тримати живим і перезапускати при деплої. Перевіряється все це одним запитом curl із ботівським user-agent, і робити цю перевірку варто до будь-яких робіт над контентом.
Джерела: дослідження Vercel і MERJ про активність ШІ-краулерів (грудень 2024, понад 500 млн звернень); офіційна документація Laravel, Inertia.js і Livewire щодо режимів рендерингу й серверного рендерингу; профільні розбори поведінки агентів OpenAI за 2026 рік. Схеми в статті наші власні.
Джерело: www.ukrinform.ua