Як зробити JavaScript-сайт читабельним для ChatGPT і ШІ

Більшість ШІ-краулерів завантажують ваш сирий HTML і ніколи не запускають ваш JavaScript. Тому, якщо контент домальовується клієнтськими скриптами, ШІ-система може запитати сторінку й майже нічого не побачити. Ось уся проблема, якщо коротко. Розвʼязання не в хитрому промпті й не в спеціальному файлі. Воно в тому, щоб суть сторінки існувала в першій HTML-відповіді, до того як виконається будь-який бандл.

Зручно тримати це в голові як порядок дій. Видимість у ШІ зводиться до доставлення контенту, і в неї три шари, які мають працювати по черзі. Спершу доступ: чи може бот узагалі завантажити сторінку? Потім змістовний HTML: чи є основний контент у цій першій відповіді, без запуску JavaScript? І лише потім клієнтська інтерактивність: скрипти, що покращують уже читабельну сторінку. Пропустіть шар, і ті, що над ним, перестають мати значення.

Ключові висновки

• Багато ШІ-краулерів читають сирий HTML і не виконують JavaScript. Vercel спостерігала, як GPTBot і OAI-SearchBot від OpenAI, ClaudeBot від Anthropic і PerplexityBot завантажують HTML, не рендерячи його; Gemini від Google (через Googlebot) і AppleBot — винятки (Vercel).
• Працюйте за порядком: доступ → змістовний HTML → інтерактивність. Клієнтський JS має покращувати вже читабельну сторінку, а не створювати її.
• «Google це рендерить» — слабкий критерій. Googlebot надзвичайно потужний, тож пройти його рендеринг ще не означає, що інші ШІ-краулери побачать ваш контент.
• Боти не взаємозамінні: OAI-SearchBot для видимості в пошуку ChatGPT, GPTBot для керування навчальним обходом, ChatGPT-User для завантаження за запитом користувача; налаштовуються незалежно (OpenAI).
• Що бачить бот, можна відтворити за допомогою curl, View Source, перезавантаження з вимкненим JS і знімків у headless-браузері. aiSiteReady автоматизує ті самі перевірки й оцінює сайт від 0 до 100.

Чи читає ChatGPT JavaScript на вашому сайті?

Чесна відповідь: не варто на це розраховувати. Публічна документація OpenAI описує ідентичність краулерів, семантику їхнього robots.txt і діапазони IP, але не стверджує, що ці боти виконують JavaScript вашого сайту (OpenAI). Коли вендор мовчить про рендеринг, безпечне інженерне припущення полягає в тому, що рендерингу немає.

Незалежні виміри вказують туди ж. Коли Vercel проаналізувала поведінку краулерів у своїй мережі, GPTBot і OAI-SearchBot від OpenAI, ClaudeBot від Anthropic і PerplexityBot завантажували HTML, але не рендерили клієнтський JavaScript. Vercel навіть бачила, як краулер ChatGPT запитував JavaScript-файли в 11,5% завантажень, а Claude — у 23,8%. Жоден із цих ботів не виконував цей код (Vercel). Gemini від Google (через Googlebot) і AppleBot — помітні винятки: вони рендерять.

Цей останній момент важливіший, ніж здається. Googlebot надзвичайно потужний: він запускає свіжу версію Chromium. Тому «Google це бачить» виявляється критерієм слабшим, ніж багато хто гадає. Якщо контент зʼявляється лише після повноцінного браузерного рендерингу, він усе одно може бути невидимим для ШІ-краулерів, які дедалі частіше живлять відповіді в ChatGPT, Perplexity та Claude. Common Crawl, чий архів навчає та заземлює багато систем, знімає будь-яку двозначність: він завантажує через HTTP GET, не виконує JavaScript і не використовує cookies (Common Crawl).

Одну різницю варто зрозуміти правильно, бо її постійно плутають: боти OpenAI — це не одне й те саме. OAI-SearchBot показує ваші сторінки в пошуку ChatGPT. GPTBot керує тим, чи можна використовувати ваш контент для навчання моделей. ChatGPT-User завантажує сторінку, коли людина явно просить ChatGPT її переглянути (OpenAI). Вони налаштовуються незалежно. Хочете потрапити в пошук ChatGPT — дозвольте OAI-SearchBot; блокування GPTBot лише виключає вас із навчання й не прибирає з пошуку (OpenAI Help Center). Anthropic і Perplexity публікують такий самий поділ між автоматичними краулерами та завантажувачами за запитом користувача (Anthropic, Perplexity).

Чому ШІ не може прочитати мій сайт?

Якщо бот доходить до сторінки, але йде ні з чим, причина майже завжди одна з цих. Кожна по-своєму провалює шар «змістовного HTML».

• Рендеринг лише на клієнті. Перша відповідь — це здебільшого порожній кореневий елемент і теги скриптів, а справжній контент збирається в браузері. Не-рендерувальний краулер бачить оболонку й зупиняється. web.dev прямо протиставляє це HTML, відданому сервером, і зазначає мінуси збирання сторінок у браузері для виявлення контенту (web.dev).
• Лінива загрузка чи безкінечне прокручування для основного контенту. Google повідомляє, що Пошук не прокручує й не клікає, щоб розкрити контент, і рекомендує посторінкові URL для безкінечних списків (Google). Якщо навіть Google не прокручуватиме, щоб знайти ваш основний текст, то менш документовані ШІ-краулери — куди ризикованіше місце, щоб його ховати.
• Заблоковані JS чи CSS. Якщо потрібні для рендерингу ресурси заборонені в robots.txt, рушій, який міг би рендерити, не зможе й може хибно зрозуміти сторінку (Google).
• Контент за логіном, cookies чи банером згоди. Для публічного виявлення вважайте, що краулери не авторизовані й не несуть cookies. Common Crawl буквально без них (Common Crawl).
• Розбіжність під час гідратації. React очікує збігу серверної та клієнтської розмітки; типові причини на кшталт Date.now(), Math.random(), розгалужень за window чи відмінностей локалі призводять до розбіжності, після якої React може відкинути серверний HTML і перезібрати дерево на клієнті (React). Ваша історія «HTML насамперед» настільки ж стабільна, наскільки стабільна ваша гідратація.

Що CSR, SSR і предрендеринг насправді віддають боту?

За всім цим стоїть просте механічне питання: які байти приходять у першій відповіді й скільки роботи краулеру ще лишається, перш ніж зʼявиться ваш контент? Таблиця нижче це узагальнює, з практичними оцінками читабельності, синтезованими з документації фреймворків і пошуковиків.

Усе це розвʼязує одне й те саме питання: чи може краулер дістати тему сторінки, ієрархію заголовків, основний текст, важливі посилання й посилання на медіа з першого HTML, не виконуючи ваш бандл? Якщо ні, ви ставите свою видимість на пайплайн рендерингу, який вам не підконтрольний.

Як перевірити, що бачить бот?

Гадати не треба. Ця послідовність іде від найгрубішого інструмента до підтвердження з боку пошуковика, і розробник може прогнати все це на ноутбуці.

1. Почніть із сирої відповіді. curl і wget показують тіло першого HTML без виконання JavaScript. Це рівно те, що отримує не-рендерувальний краулер.

# Зберегти сирий HTML, який отримує базовий завантажувач
curl -L -s https://example.com/page > raw.html

# Чи справді змістовний контент там є?
grep -n "<title>" raw.html
grep -n "<h1"     raw.html
grep -n "<main"   raw.html
grep -n "очікувана вами фраза" raw.html

Якщо тіло статті, опис товару, заголовки чи навігаційні посилання тут відсутні, це вже свідчення того, що не-рендерувальним краулерам буде важко.

2. Порівняйте View Source із живим DOM. View Source показує HTML у тому вигляді, як його віддав сервер; панель Elements у DevTools показує живий DOM після виконання скриптів (Chrome). Якщо ваш справжній текст зʼявляється лише в Elements, але не у View Source, він залежить від JavaScript.

3. Вимкніть JavaScript і перезавантажте. У Chrome DevTools для цього є вбудована команда (Chrome). Відкрийте DevTools, натисніть Cmd+Shift+P (або Ctrl+Shift+P), виконайте Disable JavaScript і перезавантажте. Якщо сторінка згортається в порожню оболонку чи спінер, це й бачить краулер без JS.

4. Знімайте відтворювано. Для перевірки в CI Playwright підтримує javaScriptEnabled: false на рівні контексту браузера (Playwright). Відрендерте сторінку один раз із вимкненим JS і один раз із увімкненим, потім порівняйте довжину тексту:

const ctx = await browser.newContext({ javaScriptEnabled: false });
const page = await ctx.newPage();
await page.goto(url, { waitUntil: "networkidle" });
const text = await page.locator("body").innerText();
// Якщо тут майже порожньо, а в прогоні з JS — повно, ваш контент залежить від скриптів.

5. Підтвердіть інструментами пошуковиків. Інструмент перевірки URL / Rich Results Test від Google показує відрендерений DOM, завантажені ресурси й вивід консолі, а в Bing є свій URL Inspection. Вони підтверджують, що бачать індексувальні рушії. Це корисно, але памʼятайте: вони відображають рендерери, а не простіші ШІ-краулери.

Як це виправити, і що лише тимчасовий міст?

Довговічне розвʼязання концептуально просте: зробіть сторінку змістовною до запуску клієнтського JavaScript. Віддавайте контент через серверний рендеринг, статичну генерацію, інкрементальну регенерацію або схему островів/гібрида. А потім дозвольте гідратації навісити інтерактивність зверху. Власне керівництво Google тепер називає динамічний рендеринг обхідним рішенням і рекомендує натомість серверний рендеринг, статичний рендеринг або гідратацію (Google). Сучасні фреймворки роблять це за замовчуванням: Nuxt, наприклад, за замовчуванням рендерить на сервері й дозволяє предрендерити чи ввімкнути гібрид для кожного маршруту (Nuxt).

Практичне правило вибору:

• Публічні, переважно стабільні сторінки (документація, маркетинг, статті): схиляйтеся до SSG чи ISR.
• Публічні сторінки, що мають бути свіжими на кожен запит: використовуйте SSR.
• Дуже інтерактивні контентні сторінки: тримайте контент серверно-відрендереним і гідратуйте лише інтерактивні віджети (підхід островів).
• Поверхні застосунку за авторизацією: CSR зазвичай підходить, адже ці сторінки й не призначені для публічного виявлення.
• Велике legacy-SPA: використовуйте предрендеринг чи динамічний рендеринг як міст, а не пункт призначення, поки переводите шаблони на SSR/SSG/острови. Єдине жорстке правило: версія, яку ви віддаєте ботам, має бути по суті тим самим контентом, що й у користувачів, інакше ризикуєте клоакінгом.

Тримайте й no-JS-фолбек чесним. Починайте з нативного семантичного HTML, додавайте ARIA лише щоб покращити семантику взаємодії, а <noscript> використовуйте для необхідного повідомлення-фолбека, а не як заміну справжньому серверному HTML (MDN). Мета — сторінка, у якої тема, текст, посилання й метадані існують у відповіді, а JavaScript нашаровується зверху як покращення.

Як перевірити весь сайт одразу?

Перевірити один шаблон вручну реально; перевіряти кожен шаблон на кожному релізі — ні. Цю роботу робить aiSiteReady. Він завантажує ваш сайт так, як це зробив би агент: запитує сирий HTML, дотримується robots.txt і читає те, що насправді отримує клієнт без JavaScript. А потім повідомляє, де ваш контент зникає.

Це напряму належить до категорії доступності контенту в оцінці: чи може агент прочитати вашу сторінку без браузера? Це одна з приблизно 15–20 перевірок із виявлюваності, доступності контенту, керування ботами, протоколів і комерції, обʼєднаних в оцінку Agent Readiness Score від 0 до 100. Точні перевірки та ваги описані на сторінці методології, а цей гайд — докладний розбір за тим самим шлюзом доступності контенту з матеріалу про те, що означає готовність до ШІ-агентів. Якщо ж ви хочете дати асистентам куровану карту читання після того, як ваші сторінки стануть читабельними, погляньте, що таке llms.txt і як його додати.

Запустіть безкоштовне сканування, щоб порівняти ваш сирий HTML із відрендереним DOM, знайти контент, який існує лише після запуску JavaScript, і отримати пріоритизований список виправлень за кожним шаблоном, англійською, українською чи російською.

IMozz має 20 років у розробці ПЗ, а останній рік будує продукти за допомогою LLM. Він розвиває aiSiteReady, сканер лише для читання, що перевіряє, чи може ШІ-агент прочитати сайт. Сканер серверно рендерить власний контент як робочий приклад.