Ваш сайт може бути невидимим для ChatGPT: перевірка на десять хвилин
Ситуація повторюється настільки часто, що стала впізнаваною. Компанія два-три роки тому переїхала на React або Vue. Позиції в Google не просіли, Search Console виглядає нормально, технічний підрядник претензій не має. Потім хтось питає в ChatGPT чи Perplexity те, у чому компанія має бути очевидним експертом, і у відповіді з’являються троє конкурентів. Першою гіпотезою стає «модель нас не любить». Насправді причина зазвичай значно нудніша: на сторінці немає жодного тексту, доки не відпрацює JavaScript, а більшість AI-краулерів його не виконують.
Це нова поломка. Десять років у веброзробці діяло правило: якщо Googlebot рендерить ваш застосунок, усе гаразд. Тепер це правило коштує грошей, бо системи, які генерують відповіді, не користуються рендерингом Googlebot.
Чому Googlebot і AI-краулер бачать різні сторінки
Googlebot запускає безголовий браузер. Він завантажує HTML, ставить сторінку в чергу, виконує скрипти й індексує вже те, що вийшло в DOM. Google описує цей триетапний цикл сканування, рендеру й індексації у власній документації з JavaScript SEO. Це працює, з затримкою, і саме тому чимало односторінкових застосунків спокійно ранжуються.
AI-краулери здебільшого так не роблять. Найкращий доступний первинний доказ – спільне дослідження Vercel і MERJ, опубліковане в грудні 2024 року на реальних серверних логах, а не на опитуваннях. Висновок був прямий: жоден із великих AI-краулерів не рендерив JavaScript. Краулери OpenAI та Anthropic скрипти завантажували – 11,5% і 23,84% усіх звернень відповідно – і не запускали їх. Винятків було два: пошук Gemini працює на інфраструктурі Googlebot і тому рендерить, а AppleBot використовує краулер на базі браузера.
До цієї цифри треба додати три застереження, і вони важливіші за заголовок. Дослідження датоване, тож це знімок грудня 2024 року, а не вічний закон природи. Логи взяті переважно з одного великого сайту документації та мережі Vercel, тобто це глибока вибірка, а не перепис вебу. І автори виключили Microsoft Copilot, бо той тоді не мав окремого користувацького агента.
Що точно не змінилося – це економіка. Рендер JavaScript дорогий. Google будував цю здатність роками, бо пошук був його основним бізнесом. Краулеру, який збирає навчальний корпус або дістає сторінку, щоб за дві секунди підперти нею відповідь, немає сенсу платити за браузерний рушій на кожну адресу. У документації самих постачальників про рендер не сказано нічого: ані в описі краулерів OpenAI, де є користувацькі агенти, діапазони IP і поведінка з robots.txt, ані в довідці Anthropic.
Заради чесності варто додати ще два пункти. MERJ повернувся до теми у матеріалі про те, яку версію сторінки віддавати якому краулеру у травні 2026 року, і там повторено, що ці агенти можуть не виконувати JavaScript, але без нових вимірювань. Тобто найсильніший доступний доказ – це одне дослідження, з однієї мережі, двадцятимісячної давнини, яке ніхто не оновлював. Це тонше за ту впевненість, з якою твердження зазвичай переказують, і про це варто знати до того, як витрачати на нього квартал.
Другий пункт: Google із висновком усе одно погоджується. У тій самій документації з JavaScript SEO є рядок про те, що серверний рендер або пререндер лишається гарною ідеєю, бо не всі боти вміють виконувати JavaScript. Це пошукова система з найдорожчим рендер-конвеєром у світі радить не покладатися на рендер.
Практичне правило звучить так: вважайте, що AI-краулер бачить рівно те, що бачить curl. Будь-який рендер понад це – подарунок, на який не варто розраховувати.
Шість команд, які дають відповідь
Ні інструмента, ні підписки, ні дашборда для цього не треба. Потрібні curl, браузер і одна важлива сторінка. Не головна: візьміть ту, яку ви хотіли б бачити процитованою. Сторінку послуги, сторінку з цінами, специфікацію.
Збережіть відповідь один раз і працюйте з файлом, щоб усі шість перевірок дивилися на ті самі байти.
curl -sL “https://yoursite.com/your-key-page/” > raw.html
1. Чи є там текст узагалі
Зріжте теги й порахуйте, що лишилося. Якщо сторінка, у якій ви бачите вісімсот слів, дає сорок, відповідь у вас уже є.
sed ‘s/<[^>]*>/ /g’ raw.html | tr -s “[:space:]” ” ” | wc -w
2. Пошук речення, яке ви бачите на екрані
Відкрийте сторінку в браузері, скопіюйте характерне речення із середини тексту й пошукайте його у файлі. Це найпереконливіша перевірка зі списку, бо до неї неможливо причепитися через методику підрахунку.
grep -c “речення, скопійоване з відрендереної сторінки” raw.html
Нуль означає, що цього речення не існує, доки не виконається JavaScript. Для краулера, який його не виконує, речення не існує взагалі.
3. Порожня оболонка
Клієнтський рендер зазвичай лишає слід: одну точку монтування, всередині якої нічого немає.
grep -o ‘id=”root”‘ raw.html ; grep -o ‘id=”__next”‘ raw.html ; grep -o ‘id=”app”‘ raw.html
Сама наявність такого елемента проблемою не є. Проблема – коли він порожній, а видимого тексту в файлі немає ніде.
4. Порівняння сирого файлу з відрендереним DOM
У консолі браузера на тій самій сторінці виконайте рядок нижче й порівняйте з числом із першого пункту. Дві тисячі слів після рендеру проти шістдесяти до нього – це готовий діагноз.
document.body.innerText.split(/\s+/).length
Те саме порівняння з боку Google дає інструмент перевірки URL у Search Console, у режимі перегляду просканованої сторінки. Варто зробити обидва: вони цілком можуть розійтися.
Сам по собі розрив ще не катастрофа, і корисно розуміти, як виглядає норма. Web Almanac від HTTP Archive міряв саме цю різницю по всьому вебу: медіанна десктопна головна сторінка додає близько 18% слів після рендеру, а на десятому процентилі різниця сягає приблизно 32%. Тобто помірний розрив – це звичайна справа. Розрив у дев’яносто з чимось відсотків – зовсім інша історія.
5. Що отримує ботівський користувацький агент
Частина фаєрволів, бот-менеджерів і правил CDN віддає сторінку виклику або 403 усьому, що схоже на краулер. Це окрема поломка з тими самими симптомами.
curl -sL -A “Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot” -o /dev/null -w “%{http_code} %{size_download}” “https://yoursite.com/your-key-page/”
Порівняйте код відповіді й розмір тіла зі звичайним запитом. 403, редирект на перевірку або тіло вдесятеро менше означають, що сторінку не віддають ще до того, як рендер стає питанням.
6. Чи є розмітка в сирому HTML
Schema.org, яку підставляє менеджер тегів після завантаження, має рівно ту саму проблему, що й текст, який підставляється після завантаження.
grep -c “application/ld+json” raw.html
Як читати результат
| Що ви побачили | Що це означає | Скільки коштує ремонт |
|---|---|---|
| Сирий текст близький до відрендереного, речення знайдено | Нічого робити не треба. У вас серверний рендер або статика | Нуль |
| Текст є, але немає цін і характеристик | Часткова гідратація. Невидимою лишилася саме комерційна частина | Дні. Перенести ці блоки у серверну відповідь |
| Порожня точка монтування, тексту майже немає | Повний клієнтський рендер. Для краулера без скриптів сторінка порожня | Тижні або місяці, залежно від фреймворку |
| Ботівський агент отримує 403 або виклик | Правило на периметрі, а не проблема рендеру | Години. Зміна конфігурації |
| HTML нормальний, розмітки немає | Schema.org підставляється менеджером тегів на клієнті | Години або дні |
Чого ця перевірка не показує
Вона показує, чи здатна машина прочитати сторінку. Вона не показує, чи буде хтось її цитувати. Читабельність – це передумова, а не стратегія, і розрив між ними великий. Ідеально доступна сторінка, у якій немає жодної конкретики, буде проігнорована так само надійно, як порожня.
Так само перевірка нічого не каже про те, чи краулери взагалі до вас заходять. Це видно тільки в серверних логах з фільтром за користувацьким агентом, і це окрема робота на пів дня. Чимало сайтів цілком читабельні й просто нікому не потрібні.
Чотири виходи, за зростанням болю
| Підхід | Що робить | Коли доречний | У чому підступ |
|---|---|---|---|
| Статична генерація | Збирає справжні HTML-файли заздалегідь | Маркетингові сторінки, документація, каталог із плановими змінами | Час збірки росте разом із кількістю сторінок |
| Серверний рендер | Формує сторінку на сервері, гідратує вже після | Персоналізований або постійно змінний контент | Реальна вартість серверів і складніший деплой |
| Пререндер на периметрі | Віддає краулерам закешований відрендерений знімок | Застосунок найближчим часом чіпати не можна | Накладка, яка з часом розходиться з живим сайтом |
| Гібрид: статична основа плюс віджети | Текст і ціни в HTML, інтерактив зверху | Більшість бізнесових сайтів, якщо чесно | Треба вирішити, де контент, а де застосунок |
Компроміси між цими варіантами добре розібрані в класичному матеріалі про способи рендеру у вебі, який писався задовго до появи AI-пошуку і від цього тільки виграв. AI-пошук не скасував жодного з тих аргументів. Він лише підняв ціну помилки.
Вибір тісно пов’язаний із тим, як улаштована система керування контентом. Якщо ви й так зважуєте відокремлений фронтенд, це те саме рішення, і наш розбір про те, кому справді потрібна headless CMS, показує, де така архітектура себе виправдовує, а де є дорогим театром. Те саме стосується вибору між застосунком і сайтом: проєкт, який по суті є застосунком у вкладці браузера, має цю проблему структурно, і це частина аргументації в матеріалі про мобільний застосунок і PWA.
Якщо переробки не буде найближчі пів року
Повний перехід на серверний рендер – це проєкт, і він рідко влазить у поточний квартал. Проміжні кроки, які дають більшу частину ефекту за кілька днів роботи, виглядають так.
- Винесіть у серверну відповідь три речі: заголовок, перший абзац і ціну. Саме їх дістають із сторінки найчастіше, і саме вони найчастіше з’являються тільки після скриптів.
- Перенесіть Schema.org із менеджера тегів у шаблон. Це годинна правка, яка не потребує жодних змін у застосунку.
- Зробіть текстову версію ключових сторінок доступною за прямою адресою і додайте її до карти сайту. Некрасиво, зате читається будь-чим.
- Перевірте правила на периметрі раніше за все інше. Якщо краулер отримує 403, архітектура тут ні до чого, а виправлення займає годину.
Чому це стало масовим
Причин дві. Компонентні фреймворки стали типовим способом зібрати будь-що, зокрема й візитку, у якій інтерактиву на два кліки. І генерація коду це підсилює: асистент, якого просять зробити лендинг, візьме патерн, який бачив найчастіше, тобто клієнтський застосунок, незалежно від того, чи він тут потрібен. Про цю родину поломок ми писали в матеріалі що ламається в сайтах, згенерованих AI, і ця поломка з них найтихіша, бо зовні нічого не зламано.
Окремо варто прочитати позицію самого Google, бо її легко сприйняти як заспокоєння. У посібнику з оптимізації під генеративні функції пошуку, оновленому в липні 2026 року, сказано, що Google уміє обробляти контент усередині JavaScript, якщо той не заблокований, і що жодних окремих файлів чи розмітки створювати не треба. Обидва твердження правдиві й обидва стосуються Google. Про решту систем, які зараз читають веб, там не сказано нічого, і саме цей розрив вимірює наша перевірка.
Коротко
Запустіть curl на найважливішу комерційну сторінку. Порахуйте слова. Пошукайте одне речення, яке ви бачите на екрані. Якщо його там немає, жоден краулер без виконання скриптів вас не процитує, а таких більшість. Ремонт тут архітектурний, а не редакційний: текст треба перенести у серверну відповідь. Ухвалити це рішення під час переробки коштує в рази дешевше, ніж дороблювати потім. Якщо перенесення сайту вже стоїть у планах, це той момент, коли зміна майже безкоштовна, і це одна з перших речей, які ми перевіряємо, коли розробляємо корпоративний сайт, який має бути процитованим, а не просто відвіданим.
