Сайтът ви може да е невидим за ChatGPT: проверка за десет минути с curl
Започваме направо с проверката, защото тя отнема по-малко време от четенето на обяснението защо е нужна.
Ситуацията, която тя диагностицира, се среща често. Фирмата е минала преди две-три години на React или Vue. Позициите в Google са наред, Search Console изглежда здрава, техническият изпълнител няма забележки. После някой пита ChatGPT или Perplexity нещо, по което фирмата очевидно е специалист, и в отговора се появяват трима конкуренти. Първото обяснение обикновено е „моделът не ни харесва“. Истинската причина е много по-скучна: на страницата няма никакъв текст, докато не се изпълни JavaScript, а повечето AI ботове не го изпълняват.
Проверката: шест команди
Не са нужни инструмент, абонамент или табло. Нужни са 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 се вмъква от мениджъра на тагове на клиента | Часове до дни |
Защо 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. Всяко рендиране над това е подарък, на който не се разчита.
Какво проверката не казва
Тя казва дали машина може да прочете страницата. Не казва дали някой ще я цитира. Четимостта е предпоставка, а не стратегия, и разликата между двете е голяма. Идеално достъпна страница без нито една конкретика ще бъде подмината също толкова надеждно, колкото и празната.
Проверката не казва и дали ботовете изобщо минават през вас. Това се вижда само в сървърните логове с филтър по потребителски агент и е отделна работа за половин ден. Много сайтове са напълно четими и просто никой не ги иска.
Четири изхода, по нарастваща болка
| Подход | Какво прави | Кога е уместен | Къде е уловката |
|---|---|---|---|
| Статично генериране | Изгражда истински HTML файлове предварително | Маркетингови страници, документация, каталог с планови промени | Времето за изграждане расте с броя страници |
| Сървърно рендиране | Съставя страницата на сървъра, хидратира след това | Персонализирано или постоянно менящо се съдържание | Реална цена на сървъри и по-сложно внедряване |
| Предварително рендиране на периметъра | Отдава на ботовете кеширана рендирана снимка | Приложението не може да се пипа скоро | Пристройка, която се разминава с живия сайт |
| Хибрид: статична основа плюс джаджи | Текст и цени в HTML, интерактивност отгоре | Повечето бизнес сайтове, честно казано | Изисква да се реши кое е съдържание и кое приложение |
Компромисите между тези четири са разгледани подробно в класическия материал за начините на рендиране в мрежата, писан много преди AI търсенето и спечелил от това. AI търсенето не отмени нито един от онези аргументи. То само вдигна цената на грешката.
Изборът е тясно свързан с това как е устроена системата за управление на съдържанието. Ако и без това преценявате отделен фронтенд, това е същото решение, а разборът ни за това на кого наистина му трябва headless CMS показва къде такава архитектура се изплаща и къде е скъп театър. Същото важи за избора между приложение и сайт: проект, който по същество е приложение в раздел на браузъра, има този проблем структурно, и това е част от аргументацията в материала за мобилно приложение или PWA.
Ако преработка няма да има скоро
Пълният преход към сървърно рендиране е проект и рядко се вмества в текущото тримесечие. Междинните стъпки, които дават по-голямата част от ефекта за няколко дни работа, изглеждат така.
- Изнесете в сървърния отговор три неща: заглавието, първия абзац и цената. Точно те се вадят от страницата най-често и точно те най-често се появяват едва след скриптовете.
- Преместете Schema.org от мениджъра на тагове в шаблона. Това е поправка за час, която не изисква промяна в приложението.
- Направете текстова версия на ключовите страници достъпна на пряк адрес и я добавете в картата на сайта. Некрасиво, но се чете от всичко.
- Проверете правилата на периметъра преди всичко останало. Ако ботът получава 403, архитектурата няма нищо общо, а поправката отнема час.
Защо това стана масово
Причините са две. Компонентните рамки станаха обичайният начин да се сглоби каквото и да е, включително визитка с интерактивност за два клика. И генерирането на код го усилва: асистент, помолен да направи лендинг, ще вземе модела, който е виждал най-често, тоест клиентско приложение, независимо дали тук е нужно. За това семейство повреди писахме в материала какво се чупи в сайтовете, генерирани от AI, и тази повреда е най-тихата от тях, защото отвън нищо не изглежда счупено.
Отделно си струва да се прочете позицията на самия Google, защото лесно се приема като успокоение. В наръчника за оптимизация към генеративните функции на търсенето, обновен през юли 2026 г., пише, че Google умее да обработва съдържание вътре в JavaScript, стига то да не е блокирано, и че отделни файлове или маркиране не са нужни. И двете твърдения са верни и двете се отнасят за Google. За останалите системи, които днес четат мрежата, там не пише нищо, и точно тази разлика мери проверката.
Накратко
Пуснете curl върху най-важната търговска страница. Пребройте думите. Потърсете едно изречение, което виждате на екрана. Ако го няма, никой бот без изпълнение на скриптове няма да ви цитира, а такива са повечето. Поправката е архитектурна, а не редакторска: текстът се мести в сървърния отговор. Това решение струва в пъти по-малко, когато се взема по време на преработка, отколкото когато се доработва после. Ако преместването на сайта и без това е в плановете, това е моментът, в който промяната е почти безплатна, и е едно от първите неща, които проверяваме, когато разработваме корпоративен сайт, който трябва да бъде цитиран, а не просто посетен.
