Уеб и бизнес · 11.09.2026 г. · 52 мин. четене

Може ли ChatGPT да прочете сайта ти? Какво виждат AI системите

Как да провериш дали ChatGPT може да прочете сайта ти. Практически тестове за HTML, robots.txt, sitemap, Schema.org, llms.txt и Markdown версии.

Пускаш сайт. Отваря се нормално в браузъра. Google го е открил. Имаш sitemap.xml, robots.txt, canonical адреси и Schema.org данни.

На пръв поглед всичко изглежда наред.

Това обаче не отговаря на един все по-важен въпрос:

Може ли ChatGPT или друга AI система действително да достигне до страницата и да извлече смислено съдържанието от нея?

Този въпрос не се проверява, като попитаме ChatGPT дали „познава“ даден бизнес. Можем да тестваме много по-конкретни неща: какъв HTTP отговор връща страницата, какво съдържание присъства в HTML, какво разрешава robots.txt, откриват ли се важните URL-и и има ли допълнителни машинно четими версии на съдържанието.

В тази статия ще направим точно това върху реален production сайт. Вместо да използваме example.com, ще проверяваме evtinwebsite.com и ще показваме реални команди, отговори и части от неговата техническа конфигурация.

Примерите с curl, grep и други shell команди са изпълнени в Linux среда. Самите HTTP проверки могат да бъдат направени и в Windows с curl.exe, а при PowerShell grep може да бъде заменен с Select-String или друг еквивалентен филтър. Логиката на тестовете остава същата.

Ще стигнем и до по-специализирания AI-ready слой: llms.txt, Markdown версии на страниците и механизмите, чрез които тези ресурси могат да бъдат свързани с основното HTML съдържание.

Важно е още в началото да поставим една граница. Няма технически тест, с който отвън да видим какво точно „мисли“ ChatGPT за дадена страница или какво се намира във вътрешния контекст на модела. Можем обаче да проверим дали сайтът създава необходимите технически условия съдържанието му да бъде достигнато, прочетено и обработено.

OpenAI например изрично посочва, че за включване на съдържание в summaries и snippets в ChatGPT Search сайтът не трябва да блокира OAI-SearchBot. Това е техническо условие за достъп, но не е обещание, че конкретна страница ще бъде избрана и цитирана при даден въпрос.

Какво означава една AI система да прочете сайта ти

Когато казваме, че ChatGPT или друга AI система може да „прочете“ един сайт, използваме удобна, но доста широка формулировка.

На практика зад нея стоят няколко различни процеса. Системата или свързан с нея crawler трябва първо да може да достигне до URL-а. След това трябва да получи съдържание, от което могат да бъдат извлечени полезни данни. Едва след това идват въпросите как това съдържание се интерпретира и дали изобщо е подходящо за конкретна потребителска заявка.

Тези етапи не трябва да се смесват.

Достъпът до страницата е само първата стъпка

Най-базовият тест няма нищо общо с „AI оптимизация“.

Страницата първо трябва да съществува и сървърът да може да я върне. Ако URL-ът отговаря с грешка, изисква authentication или заявката се спира от firewall още преди да достигне до приложението, съдържанието може изобщо да не бъде получено.

След това идва достъпът за конкретния crawler. Една страница може спокойно да се отваря в Chrome, но robots.txt, WAF правило или друга инфраструктурна настройка да ограничава автоматизирани заявки.

И дори при успешен достъп остава още един въпрос: какво действително получава машината?

Ако най-важната информация за бизнеса е лесно достъпна в документа, ситуацията е една. Ако първоначалният отговор съдържа почти празна страница и цялото съдържание зависи от допълнително изпълнение на JavaScript, вече трябва да проверим как е реализиран rendering-ът и какви възможности има конкретната система, която достъпва страницата.

Затова „сайтът се отваря при мен“ е полезна проверка за потребителя, но не е достатъчна проверка за автоматизиран достъп.

Crawlable не означава автоматично цитиран от ChatGPT

Това е едно от най-важните разграничения в цялата тема.

Достъпен за crawler, открит, машинно обработен и избран като източник са различни неща.

Една страница може да бъде технически достъпна, но системата все още да не я е открила.

Може да бъде открита, но информацията в нея да е слабо структурирана или недостатъчно релевантна за конкретен въпрос.

Може съдържанието да бъде напълно достъпно и разбираемо, но при определена заявка да има други източници, които системата преценява като по-подходящи.

Точно затова техническата AI подготовка не трябва да се представя като формула от типа „направи пет настройки и ChatGPT ще започне да те цитира“.

Дори OpenAI описва достъпа на OAI-SearchBot като начин съдържанието да може да бъде откривано, показвано и цитирано в ChatGPT Search. Самото разрешаване на crawler-а не представлява гаранция за присъствие при конкретна заявка.

Техническата работа решава по-конкретен проблем: премахва препятствия, които могат да затруднят достигането и обработването на съдържанието.

Какво всъщност ще проверяваме

За да не смесваме различните части на проблема, в тази статия ще използваме проста практическа рамка:

text

+-------------+    +------------+    +-----------+    +-----------+    +-----------------------+
| HTTP достъп | -> | съдържание | -> | структура | -> | discovery | -> | специализиран AI слой |
+-------------+    +------------+    +-----------+    +-----------+    +-----------------------+

Това не е официален стандарт на OpenAI, Google или друга AI платформа. Използваме го като удобен начин да разделим техническата проверка на отделни задачи.

Първо ще видим дали страницата отговаря нормално и дали автоматизирана заявка може да достигне до нея.

След това ще проверим какво съдържание действително връща сайтът и дали основната информация може да бъде извлечена от документа.

Ще разгледаме структурата на страницата, metadata, canonical адресите, structured data и връзките между отделните ресурси.

Следва discovery слоят: robots.txt, sitemap и механизмите, които помагат различните страници и версии на съдържанието да бъдат открити.

Едва след тази основа ще стигнем до llms.txt, Markdown representations и по-новите механизми за свързване на HTML страницата с нейни machine-readable алтернативи.

Така можем да проверим не дали сайтът е „харесван от AI“, а нещо много по-измеримо:

какво предоставя сайтът на една автоматизирана система и има ли очевидни технически пречки тя да достигне до важната информация.

Нека проверим реален сайт, а не example.com

При технически примери често се използва example.com и примерна конфигурация. Това е удобно, когато обясняваме синтаксис, но не показва как същите механизми работят в реална production среда.

Затова в тази статия ще използваме собствения ни evtinwebsite.com.

Това е същият сайт, на който четете материала, и всички основни проверки по-нататък могат да бъдат повторени директно от терминал. Ще гледаме какво връща сървърът, как изглежда HTML документът, какви ресурси са публично достъпни и как са свързани помежду си.

Целта не е да представяме evtinwebsite.com като някакъв универсален модел за „перфектен AI сайт“. По-полезно е да го използваме като работещ пример, при който можем да покажем реалната конфигурация и да проверим всяко твърдение.

Точно такъв ще бъде подходът и нататък: не приемаме, че дадена настройка работи само защото я има в source code. Проверяваме какво действително получава външната заявка.

Какво сме внедрили в evtinwebsite.com

Основното съдържание на evtinwebsite.com пристига в реалния HTML документ. При директна HTTP заявка могат да бъдат извлечени основното заглавие, текстовете на страницата, вътрешните връзки и структурирани данни, без да е необходимо първо човек да отвори сайта в браузър и да взаимодейства с интерфейса.

Около това съдържание има няколко допълнителни слоя.

Страниците използват metadata и canonical адреси. Налични са robots.txt и sitemap.xml, а според типа на страницата се добавят и Schema.org structured data.

За AI-oriented частта сайтът има публичен llms.txt, Markdown representations и discovery връзки, чрез които HTML страниците могат да обявяват тези ресурси. По-нататък ще проверим всяка част директно от production.

Преди да стигнем до тях обаче трябва да проверим нещо много по-базово.

Може ли външна система изобщо да достигне до страницата и какъв HTTP отговор получава?

Оттам започва същинският тест.

Първа проверка: отговаря ли страницата нормално

Преди да търсим llms.txt, Schema.org или Markdown версии, има по-базов въпрос: какво се случва, когато към страницата бъде изпратена директна HTTP заявка?

За начало можем да проверим evtinwebsite.com с:

bash

curl -I https://evtinwebsite.com/

Тази команда не зарежда сайта като браузър. Тя изпраща HEAD заявка и показва HTTP headers, без да изтегля цялото съдържание на страницата.

При нашата production проверка началната страница върна:

text

HTTP/2 200 
content-type: text/html; charset=utf-8

Това вече ни дава две полезни информации. Сървърът отговаря успешно, а ресурсът се представя като HTML документ.

Какво ни казва HTTP status кодът

При обикновена публична страница най-лесният за интерпретиране резултат е:

200 OK

Това означава, че заявката е обработена успешно и ресурсът е достъпен на този адрес.

Не всеки друг status code обаче е проблем.

Ако например сайтът пренасочва:

https://www.domain.com

към:

https://domain.com

може първо да получим 301 или 308, след което заявката да стигне до окончателната страница с 200.

Такова пренасочване е напълно нормално, когато сайтът има един основен hostname.

За да проследим redirect-ите, можем да добавим -L:

bash

curl -IL https://evtinwebsite.com/

По-важният въпрос е къде завършва веригата. Ако крайният публичен URL връща нормално съдържанието си, самото наличие на redirect не е причина за тревога.

Има и една подробност, която е добре да знаем. curl -I използва HEAD заявка, а някои приложения, CDN-и или защитни системи могат да обработват HEAD и GET по различен начин.

Ако искаме да видим headers от нормален GET request, без да отпечатваме цялата страница, можем да използваме:

bash

curl -sS -D - -o /dev/null https://evtinwebsite.com/

Именно с такава заявка при нашата проверка evtinwebsite.com отново върна успешен 200 response.

Кои отговори вече заслужават внимание

Някои status кодове са ясен сигнал, че трябва да проверим какво се случва.

403 Forbidden означава, че сървърът е получил заявката, но отказва достъп. Причината може да бъде firewall правило, bot protection, ограничение по IP или друга политика за достъп.

429 Too Many Requests показва, че заявките са ограничени. Rate limiting е напълно нормален защитен механизъм, но прекалено агресивна настройка може да засегне и legitimate crawlers.

При 500, 502, 503 или други 5xx отговори вече говорим за проблем от страната на сървъра, приложението, upstream услугата или инфраструктурата.

Има и случаи, при които status кодът сам по себе си не разказва цялата история.

Една защитна система може например да върне HTML страница с challenge вместо истинското съдържание. В някои конфигурации дори може да получим 200, но body-то да съдържа проверка за браузър, CAPTCHA или друг междинен екран.

Затова след HTTP status-а ще проверим и какво реално има в response body.

Authentication също променя картината. Ако съдържанието е достъпно само след вход, външният crawler няма автоматично същия достъп като потребителя, който вече има активна сесия.

Redirect loop е друг очевиден проблем. Ако заявката се мести между два или повече адреса и никога не достига до нормален документ, системата няма стабилен краен URL, от който да получи съдържанието.

Сайтът може да работи за теб и да е недостъпен за crawler

Това е причината тестът през терминал да е полезен.

Когато отвориш сайт в собствения си браузър, заявката може да носи cookies, запазена сесия и друга информация от предишни посещения. Може вече да си преминал Cloudflare challenge или защитната система да третира браузъра ти като познат клиент.

Crawler-ът идва при различни условия.

WAF правило може да блокира определени user agents. Rate limiter може да реагира на автоматизирани заявки. Bot protection може да изисква поведение, което обикновеният HTTP client не изпълнява. Географски или IP ограничения също могат да създадат различни резултати.

Именно затова: „Отваря се при мен“ не е достатъчен технически тест.

Успешният HTTP response също не доказва, че сме решили целия въпрос с AI достъпността. Той ни казва само, че сме преминали първото препятствие.

При evtinwebsite.com вече знаем, че публичната начална страница отговаря успешно.

Следващият въпрос е по-интересен:

Какво съдържание действително получава машината в този response?

Какъв HTML действително получава машината

Успешният 200 OK ни казва, че страницата е достъпна. Той обаче не ни казва какво има вътре.

Следващата проверка е по-важна: какво съдържание получаваме, ако изтеглим страницата директно, без да я отваряме в браузър?

Изтегляме страницата без браузър

Най-простият тест е:

bash

curl -Ls https://evtinwebsite.com/

-L казва на curl да следва евентуални redirects, а -s премахва progress информацията и оставя самия response.

Резултатът няма да прилича на страницата, която виждаме в браузъра. Получаваме суровия HTML документ, изпратен от сървъра.

При evtinwebsite.com още в него присъстват <title>, description, canonical, structured data, навигацията и основното съдържание на началната страница.

За нашия тест обаче не е необходимо да четем целия HTML. По-полезно е да потърсим информация, която знаем, че трябва да присъства на страницата.

Присъства ли основната информация в отговора

Началната страница на evtinwebsite.com има основно заглавие:

Евтин уебсайт за твоя бизнес. Готов до 5 дни.

Можем да потърсим част от него директно в получения HTML:

bash

curl -Ls https://evtinwebsite.com/ | grep -i "Евтин уебсайт"

При production проверката текстът се намира още в HTML response-а. В него присъства реалният <h1>:

html

<h1> Евтин уебсайт за <span>твоя бизнес.</span> Готов до 5 дни.</h1>

Това е много по-полезна информация от самото 200 OK.

Вече знаем, че сървърът не връща само празен контейнер от типа:

html

<div id="root"></div>

с очакването цялото съдържание да се появи по-късно след изпълнение на JavaScript.

Основният текст на страницата пристига в документа още при директната HTTP заявка.

Можем да проверим и конкретна услуга или вътрешна връзка. Например началната съдържа текст за индивидуална изработка на уебсайт и линк към съответната страница:

bash

curl -Ls https://evtinwebsite.com/ | grep -i "индивидуална изработка"

Този тип тест е прост, но много показателен. Ако можем да намерим важните части от съдържанието в директния response, знаем, че автоматизираният клиент поне има от какво да извлича информация.

Това все още не доказва как конкретна AI система ще обработи или използва текста. Доказва нещо по-основно и измеримо: съдържанието действително се предоставя от сайта.

Какво трябва да може да бъде извлечено

Няма универсално правило, че всяка дума от страницата трябва да присъства в един и същ HTML response.

По-важно е основната информация да не зависи изцяло от сложна интеракция в браузъра.

За бизнес сайт бихме очаквали при директно извличане да можем да разберем поне кой стои зад страницата, какво предлага и за какво е конкретният URL.

При началната на evtinwebsite.com например от документа могат да бъдат извлечени брандът DIMITROV.code, основното заглавие, описанието на услугата и връзките към по-конкретни страници.

Вътрешните links също имат значение. Те показват, че от началната могат да бъдат открити страници за индивидуална изработка, готови проекти, блог съдържание и други части от сайта.

При локален бизнес бихме търсили и информация като град, адрес или обслужван район, ако те са част от съдържанието на страницата. При продуктова страница ще ни интересуват име на продукта, описание, цена и връзки към свързани ресурси. Контекстът зависи от типа страница.

Основната идея е проста:

ако човек вижда най-важната информация, но тя липсва от директно получения документ, трябва да разберем откъде се появява и как се рендерира.

Това ни води към следващия въпрос.

Какво става, ако съдържанието се появява едва след изпълнение на JavaScript?

Ами ако съдържанието се появява само след JavaScript?

В предишната проверка видяхме, че основното съдържание на evtinwebsite.com присъства още в HTML response-а. Това обаче не е задължително при всеки сайт.

При някои приложения първоначалният документ съдържа почти всичко необходимо за разбиране на страницата. При други HTML-ът служи основно като обвивка, а текстовете и интерфейсът се създават едва след като браузърът изтегли и изпълни JavaScript.

Тази разлика си струва да бъде проверена, но без да я превръщаме в мита, че всичко, което се рендерира с JavaScript, автоматично е невидимо за търсачки или AI системи.

Server-delivered HTML срещу празна app shell

При страница, при която основното съдържание пристига от сървъра, директният response може да съдържа нещо подобно:

html

<main>
  <h1>Изработка на уебсайт за бизнес</h1>
  <p>
    Създаваме бързи уебсайтове за малък бизнес с ясна структура и достъпно съдържание.
  </p>
</main>

Дори без да изпълняваме JavaScript, вече имаме заглавие, описание и достатъчно контекст, за да разберем за какво е страницата.

При client-side приложение първоначалният документ може да изглежда много по-бедно:

text

<div id="root"></div>
<script src="/app.js"></script>

В този случай същественият текст още не е в получения документ. Той трябва да бъде създаден след зареждането и изпълнението на JavaScript.

Това е важна разлика при нашия тест с curl.

curl изтегля HTTP response-а, но не се държи като пълноценен браузър и не изпълнява JavaScript приложението. Ако основният текст липсва от неговия output, това не доказва, че никоя друга система не може да го достигне.

Показва само, че съдържанието не присъства в първоначално доставения HTML.

Client-side rendering не означава автоматично „невидимо“

Точно тук трябва да внимаваме с заключенията.

Различните crawlers и automated clients могат да имат различни възможности. Някои обработват само получения HTML. Други могат да изпълняват JavaScript или да използват допълнителен rendering етап.

Дори една и съща платформа може да използва различни механизми за различни свои продукти и задачи.

Затова от:

curl не намира текста

не следва автоматично:

AI системите не могат да го видят

Коректният извод е по-тесен:

основното съдържание не е налично в първоначалния HTML и за достигането му е необходим допълнителен rendering процес.

Оттам нататък вече трябва да знаем как работи конкретният crawler или система, преди да правим по-силни твърдения.

Това е и причината в тази статия да разделяме техническите факти от предположенията. Можем да проверим какво връща сървърът. Не можем само от един curl тест да заключим как всяка AI платформа ще обработи страницата.

Защо все пак предпочитаме основната информация да е достъпна без сложен rendering

Причината не е, че JavaScript е „лош за AI“.

Причината е предвидимостта.

Ако основното заглавие, описанието на услугата и важните връзки вече са в HTML response-а, една автоматизирана система има достъп до тях още след първата заявка.

Не е необходимо допълнително да зарежда JavaScript bundles, да изпълнява приложението, да чака асинхронни заявки или да възпроизвежда поведението на браузър.

Това намалява броя на местата, на които нещо може да се обърка.

Представи си страница, която след първоначалното зареждане трябва да изпълни JavaScript и след това да извика API, за да получи основното описание на услугата. Ако API заявката бъде блокирана, timeout-не или изисква различни credentials, автоматизираният клиент може да получи значително по-малко информация от потребителя в браузъра.

Когато основното съдържание вече присъства в документа, диагностиката също е много по-проста. Можем да го проверим с обикновена HTTP заявка и да видим точно какво е изпратил сървърът.

Това не означава, че всяка интерактивна част трябва да бъде server-rendered. Калкулатор, филтри, чат, интерактивна галерия или dashboard спокойно могат да разчитат на JavaScript.

По-важният въпрос е дали смисълът на публичната страница зависи изцяло от него.

При evtinwebsite.com основните заглавия, текстове и връзки са налични още в директния HTML response. JavaScript добавя поведението и интерактивността на интерфейса, но не е необходимо да изпълним приложението, за да разберем какво предлага страницата.

За публичен бизнес сайт това е добра техническа позиция: по-малко зависимости между заявката и основното съдържание, по-лесна проверка и по-малко неизвестни за crawler-и и други automated clients.

След като знаем, че страницата се отваря и основният ѝ текст действително пристига в HTML, можем да преминем към следващата бариера.

Разрешаваме ли изобщо на конкретните AI crawler-и да я посещават?

robots.txt: допускаш ли AI crawler-а, когото искаш да допускаш

След като установихме, че страницата отговаря нормално и основното съдържание присъства в HTML, следващият въпрос е дали crawler-ът, който ни интересува, има разрешение да го обходи.

Тук влиза robots.txt.

Можем да проверим файла директно:

bash

curl -L https://evtinwebsite.com/robots.txt

Проверяваме robots.txt на evtinwebsite.com

При production проверката релевантната част от файла изглежда така:

text

User-agent: *
Allow: /
Disallow: /api
Disallow: /success
Disallow: /studio
Disallow: /cdn-cgi/

Content-Signal: search=yes, ai-input=yes, ai-train=yes

User-agent: Bytespider
Disallow: /

Sitemap: https://evtinwebsite.com/sitemap.xml

Това вече ни казва доста.

Публичните страници са разрешени чрез общата User-agent: * група, докато технически и административни пътища като /api, /success, /studio и /cdn-cgi/ са изключени.

Не сме добавяли отделни секции за всеки AI crawler. Ако конкретен bot няма по-специфична група, за него важат правилата от:

User-agent: *

Това означава, че crawler-и като OAI-SearchBot, GPTBot, ClaudeBot и PerplexityBot не са блокирани от тази конфигурация.

Отделна група използваме само когато искаме различно поведение. В този случай:

text

User-agent: Bytespider
Disallow: /

блокира Bytespider изцяло.

Този подход е по-лесен за поддръжка от файл, в който повтаряме еднакви Allow и Disallow правила за всеки crawler поотделно.

Интересният детайл за нашия тест е OAI-SearchBot.

Той не присъства като отделна група, но тъй като няма по-специфично правило за него, публичната част на сайта попада под:

text

User-agent: *
Allow: /

Тоест robots.txt не го блокира.

Във файла има и допълнителна декларация:

text

Content-Signal: search=yes, ai-input=yes, ai-train=yes

Тя описва желаната политика за използване на публичното съдържание при search, AI input и training. Това е допълнителен механизъм и не заменя стандартните Allow и Disallow правила.

Ако искаме бързо да видим само интересуващите ни записи, можем да използваме:

bash

curl -Ls https://evtinwebsite.com/robots.txt \
  | grep -iE 'user-agent|allow|disallow|content-signal|sitemap'

text

User-agent: *
Allow: /
Disallow: /api
Disallow: /success
Disallow: /studio
Disallow: /cdn-cgi/
Content-Signal: search=yes, ai-input=yes, ai-train=yes
User-agent: Bytespider
Disallow: /
Sitemap: https://evtinwebsite.com/sitemap.xml

При evtinwebsite.com тази команда ни дава компактна картина на реалната crawl политика, без да се налага да четем целия файл.

GPTBot и OAI-SearchBot не са едно и също

Имената лесно могат да създадат впечатление, че говорим за един и същ crawler. OpenAI обаче ги използва за различни цели.

За включване на съдържание в summaries и snippets в ChatGPT Search OpenAI посочва OAI-SearchBot. Ако искаме страниците ни да могат да бъдат откривани и използвани по този начин, не трябва да го блокираме в robots.txt.

GPTBot има различна роля. OpenAI го използва като сигнал за това дали съдържание от сайта може да бъде включвано в potential training.

Затова е напълно възможна конфигурация като:

text

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Така собственикът на сайта може да допуска crawler-а за ChatGPT Search, но да изключи съдържанието си от potential training чрез GPTBot.

При evtinwebsite.com не правим това разграничение. Нито OAI-SearchBot, нито GPTBot имат собствена група и затова публичните страници попадат под общото правило:

text

User-agent: *
Allow: /

И двата crawler-а са разрешени от текущата ни robots.txt политика.

Това е причината въпросът „разрешил ли съм ChatGPT?“ да е прекалено общ. По-полезният въпрос е кой crawler ни интересува и за каква функция.

Какво проверяваме при Perplexity и другите системи

Същият принцип важи и при други AI платформи.

Perplexity например публикува два различни user agents.

PerplexityBot е crawler за откриване на страници и показването им с връзки в резултатите на Perplexity. Според документацията на платформата той не се използва за събиране на съдържание за обучение на foundation models.

Perplexity-User има друга функция. Той може да посети страница в отговор на конкретно действие или въпрос от потребител, за да помогне при съставянето на отговор. Това не е crawler за масово индексиране и според Perplexity този тип user-triggered fetch обикновено не се управлява чрез robots.txt по същия начин.

В текущия robots.txt на evtinwebsite.com няма отделна група за PerplexityBot, следователно публичните страници попадат под:

text

User-agent: *
Allow: /

При други платформи подхождаме по същия начин: първо проверяваме официалната документация за точния user agent и неговото предназначение, след което сравняваме това с реалната политика на сайта.

Не е добра идея да добавяме crawler-и по име само защото сме ги срещнали в някакъв списък. Имената, функциите и правилата могат да се променят.

Allow не помага, ако firewall-ът вече е върнал 403

robots.txt описва политика за обхождане. Той не е firewall и не може сам да осигури мрежов достъп до сайта.

Може например да имаме:

text

User-agent: OAI-SearchBot
Allow: /

и заявката въпреки това да бъде спряна от Cloudflare, WAF правило, bot protection, rate limiter или друга система пред приложението.

Резултатът може да бъде:

403 Forbidden

или:

429 Too Many Requests

дори когато robots.txt разрешава обхождането.

Това не е теоретичен детайл. И OpenAI, и Perplexity разглеждат WAF и bot protection като отделен слой от robots.txt. Perplexity например публикува IP диапазони за своите crawler-и и препоръчва при WAF конфигурации да се проверяват както user agent-ът, така и източникът на заявката.

Затова при реална диагностика имаме два различни въпроса:

text

robots.txt разрешава ли crawler-а?
        ↓
инфраструктурата действително пропуска ли заявката?

Положителният отговор на първия не гарантира положителен отговор на втория.

Ако robots.txt казва Allow: /, а реалните заявки на crawler-а завършват с 403, няма особен смисъл да редактираме robots файла отново. Трябва да проверим CDN, WAF, bot protection, rate limiting и server logs.

Allow: / разрешава обхождането на ниво robots политика. То не гарантира, че заявката ще стигне до съдържанието.

Има ли страницата ясна машинно разбираема структура

Дотук проверявахме дали външна система може да достигне до страницата и дали основното съдържание действително присъства в получения HTML.

Следващият въпрос е как е организирана тази информация.

Един HTML документ може да съдържа целия необходим текст и въпреки това да бъде труден за интерпретиране, ако заглавията, отделните секции и връзките между страниците са подредени хаотично.

Тук не търсим специален „AI формат“. Проверяваме стандартната структура на уеб документа.

Title, description и canonical

На началната страница на evtinwebsite.com в production HTML присъстват например:

html

<title>Евтин уебсайт за бизнес от 50€ | DIMITROV.code</title>
<meta name="description" content="Евтин уебсайт за малък бизнес с чист Next.js код. Лендинг страница от 50€, бизнес сайт от 100€, авторски проекти и ясно ценообразуване.">
<link rel="canonical" href="https://evtinwebsite.com">

Трите елемента имат различна работа.

title дава кратко име на документа. Това е един от най-ясните сигнали за основната тема на конкретния URL.

description предоставя кратко текстово резюме. Няма гаранция, че търсачка или AI система ще го използва дословно, но той е още един лесно достъпен източник на контекст за страницата.

canonical посочва предпочитания URL, когато едно и също или много сходно съдържание може да бъде достъпно през различни адреси.

Последното е особено интересно в нашия пример, защото вече имаме и Markdown representations. HTML страницата е основният документ, а .md версията сочи обратно към него чрез:

text

Link: <https://evtinwebsite.com/>; rel="canonical"

Това не е някаква специална техника за ChatGPT. Просто прави отношението между различните представяния на едно съдържание по-ясно.

Важно е да не приписваме на тези елементи повече, отколкото реално правят.

Добър title не гарантира цитиране. description не е команда към AI система какво да каже за страницата. Canonical също не означава, че всяка външна система задължително ще избере точно този URL.

Те дават по-ясно описание на документа и неговата роля в сайта.

H1, H2 и семантичният HTML

Същата логика важи и за видимото съдържание.

На началната на evtinwebsite.com основното заглавие е:

html

<h1> Евтин уебсайт за твоя бизнес. Готов до 5 дни.</h1>

След него отделните части на страницата са организирани с последващи заглавия и семантични HTML елементи.

Тук тезата не е:

ChatGPT обича H1 и H2.

По-полезният начин да го погледнем е като структура на документ.

Ако имаме:

html

<main>
  <article>
    <h1>Как да подготвим сайт за AI системи</h1>

    <section>
      <h2>Проверка на HTML съдържанието</h2>
      <p>...</p>
    </section>

    <section>
      <h2>Проверка на robots.txt</h2>
      <p>...</p>
    </section>
  </article>
</main>

ролите на отделните части са сравнително ясни още от markup-а.

Можем да различим основното съдържание от навигацията, да идентифицираме главната тема и да видим кои параграфи принадлежат към конкретна секция.

Сравнете това с документ, изграден почти изцяло от безименни контейнери:

html

<div class="a">
  <div class="b">Как да подготвим сайт за AI системи</div>
  <div class="c">
    <div>Проверка на HTML съдържанието</div>
    <div>...</div>
  </div>
</div>

Човек може да получи почти същата визуална страница чрез CSS, но самият HTML описва много по-малко за ролята на отделните елементи.

Семантичният HTML не премахва необходимостта съдържанието да бъде добро. Той просто дава по-ясна документна рамка около него.

Това е полезно за browsers, accessibility tools, search crawlers, parsers и други automated clients. При AI системите не е необходимо да измисляме отделна магия. Колкото по-ясно е организиран документът, толкова по-малко трябва да се предполага коя част каква роля има.

Особено важно е това при дълги информационни страници.

Статия като тази съдържа HTTP проверки, robots.txt, structured data, llms.txt, Markdown и още няколко отделни теми. H2 и H3 структурата позволява конкретен пасаж да бъде разглеждан в контекста на секцията, към която принадлежи, вместо целият документ да представлява една непрекъсната маса текст.

Вътрешните връзки също описват сайта

Структурата не приключва в рамките на една страница.

Вътрешните връзки показват как отделните URL-и са свързани помежду си.

На началната на evtinwebsite.com например от основното съдържание могат да бъдат достигнати по-конкретни страници за услуги, портфолио и информационни материали. Това позволява на crawler или друг automated client да премине от общата представа за бизнеса към по-тясна тема.

Същото важи и вътре в блога.

Ако статия разглежда защо AI-generated проект започва да се чупи при всяка промяна, естествената връзка е към по-подробен материал за архитектурния проблем:

AI сайтът се чупи при промени? Проблемът е в архитектурата

А когато контекстът вече е за реално довършване или refactoring на такъв проект, логичното продължение е service page:

Преработка на AI сайт

Подобна връзка не е полезна само защото създава още един internal link.

Тя описва отношение:

text

информационен проблем
        ↓
по-задълбочено техническо обяснение
        ↓
услуга, която решава този тип проблем

При друга тема връзката може да е различна. Статия за llms.txt например може естествено да насочи към по-подробния материал за Agentic Browsing и llms.txt, без от това да следва, че трябва да линкваме тази статия от всяка страница на сайта.

Точно тук информационната архитектура е по-важна от количеството links.

Ако всяка страница сочи към всичко, връзките дават малко допълнителен контекст. Когато линкът се появява там, където читателят действително има причина да продължи към следващия ресурс, той помага едновременно на навигацията и на разбирането как са свързани темите в сайта.

Затова при проверката не питаме просто:

Има ли вътрешни линкове?

По-полезният въпрос е:

Може ли от структурата на документа и връзките му да се разбере каква е тази страница, за какво говори и към кои по-конкретни ресурси принадлежи?

След като тази основа е ясна, можем да погледнем още един машинно четим слой, който често се разбира погрешно: Schema.org structured data.

Каква роля има Schema.org

Дотук разглеждахме структурата, която се вижда директно в HTML документа: заглавия, текст, canonical адреси и вътрешни връзки.

Structured data добавят още един слой. Вместо една система да извежда всички отношения само от видимия текст, можем изрично да опишем определени обекти и връзките между тях чрез речника на Schema.org.

Най-често това се реализира като JSON-LD в HTML страницата.

Какво добавят structured data

Schema markup може да даде по-формално описание на това какъв тип съдържание стои пред нас.

Например една страница може да описва:

text

Organization
WebSite
WebPage
Article
BreadcrumbList
Service
Product
Person

в зависимост от реалното съдържание и предназначението на URL-а.

На началната страница на evtinwebsite.com например използваме structured data за Organization, Person, WebSite, WebPage и Service.

Така информация като името на организацията, URL-а на сайта, автора, типа на страницата и предлаганата услуга не присъства само като свободен текст. Част от тези отношения са описани и в машинно четима структура.

Ето съкратен фрагмент от реалния Service markup на началната страница:

json

{
  "@type": "Service",
  "@id": "https://evtinwebsite.com/#web-development-service",
  "name": "Готови уебсайтове за малък бизнес",
  "serviceType": "Готови Next.js уебсайт пакети с фиксиран обхват и цена",
  "provider": {
    "@id": "https://evtinwebsite.com/#organization"
  },
  "areaServed": {
    "@type": "Country",
    "name": "Bulgaria"
  },
  "offers": {
    "@type": "AggregateOffer",
    "url": "https://evtinwebsite.com/#pricing",
    "priceCurrency": "EUR",
    "lowPrice": 50,
    "highPrice": 200,
    "offerCount": 3
  }
}

Тук има нещо по-интересно от самия "@type": "Service".

Полето provider не повтаря отново цялата информация за DIMITROV.code. То сочи чрез @id към отделно описания Organization entity:

json

{
  "@type": "Organization",
  "@id": "https://evtinwebsite.com/#organization",
  "name": "DIMITROV.code",
  "url": "https://evtinwebsite.com"
}

Така могат да се опишат отношения от типа:

text

WebPage
   ↓
Service
   ↓
Organization

При статията можем по сходен начин да опишем публикацията, нейния автор, издателя и страницата, към която принадлежи. Например реалният markup на една от статиите ни съдържа:

json

{
  "@type": "BlogPosting",
  "headline": "Безплатна изработка на сайт: как работи програмата ни",
  "author": {
    "@id": "https://evtinwebsite.com/#borislav-dimitrov"
  },
  "publisher": {
    "@id": "https://evtinwebsite.com/#organization"
  },
  "isPartOf": {
    "@id": "https://evtinwebsite.com/#website"
  }
}

Така една страница може да описва не само отделни entities, а и отношенията между тях. При други типове страници същият принцип може да се приложи към BreadcrumbList, Product, Service и други подходящи Schema.org типове.

Ключовото е structured data да описват реалното съдържание и отношенията, които страницата действително представя.

Тя не трябва да се използва като паралелна версия на сайта, в която декларираме информация, която потребителят не може да намери в самото съдържание.

Какво Schema не може да направи

Тук започват и най-честите преувеличения.

Добавянето на JSON-LD не означава автоматично, че страницата ще се класира по-високо в търсачките.

Не означава и че ChatGPT, Gemini или Perplexity задължително ще я изберат като източник.

Schema markup не може да гарантира:

ranking;
цитиране;
AI visibility;
включване в конкретен отговор.

Той също не поправя слабата основа на страницата.

Ако услугата е описана неясно, липсват важни факти или основният текст не отговаря на въпросите на потребителя, добавянето на:

"@type": "Service"

не създава липсващото съдържание.

Същото важи и за AI системите. Structured data могат да направят някои отношения по-ясно декларирани, но не заменят самия документ, неговия текст и достъпността му.

Затова при техническа AI подготовка гледаме Schema като допълнителен машинно четим слой върху вече добре структурирано съдържание, а не като shortcut към видимост.

Същото разграничение ще ни трябва и при sitemap.xml и canonical адресите. Те не са създадени специално за AI системи, но помагат да се разбере кои URL-и съществуват и коя версия на съдържанието считаме за основна.

Sitemap и canonical не са AI функции, но пак имат значение

Когато говорим за AI-ready сайтове, лесно е всяка техническа настройка да бъде представена като нов „AI сигнал“.

sitemap.xml и canonical адресите не са такива.

И двете съществуват отдавна и имат много по-обща задача: да помагат на автоматизираните системи да откриват URL-и и да разбират коя версия на дадено съдържание считаме за основна.

Точно затова имат място и в тази проверка.

Как sitemap помага при откриването на URL-и

Sitemap файлът дава структуриран списък с URL-и, които сайтът иска да направи лесни за откриване.

При evtinwebsite.com можем да го изтеглим директно:

bash

curl -L https://evtinwebsite.com/sitemap.xml

При по-голям sitemap обаче не е особено удобно да четем целия XML на ръка. Можем да проверим конкретна страница:

text

curl -Ls https://evtinwebsite.com/sitemap.xml | grep "zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti"

Търсим реалния URL на статията:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti

Идеята тук е проста.

Crawler не е задължително да открие всяка страница единствено чрез sitemap. URL-и могат да бъдат намерени чрез вътрешни връзки, външни линкове и други механизми.

Sitemap предоставя още един ясен discovery path.

Той е особено полезен при сайтове с повече страници, блог публикации или съдържание, което не е непосредствено достижимо от началната страница.

Това обаче не означава:

text

URL е в sitemap
      ↓
URL задължително ще бъде индексиран
      ↓
AI система задължително ще го използва

Sitemap показва, че URL-ът съществува и че собственикът на сайта го включва сред ресурсите, които иска да бъдат откривани.

Какво ще се случи след откриването е отделен въпрос.

Защо canonical е важен при няколко версии на едно съдържание

Тук нашият пример става по-интересен.

За една blog публикация на evtinwebsite.com имаме нормална HTML страница:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti

и Markdown representation:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

Това са два различни URL-а, които представят по същество едно и също съдържание в различен формат.

HTML страницата е основната web версия и декларира себе си като canonical:

html

<link rel="canonical" href="https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti" />

Същевременно тя обявява Markdown representation чрез:

html

<link rel="alternate" type="text/markdown" href="https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md" />

Markdown версията връща обратната връзка в HTTP headers:

text

Link: <https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti>; rel="canonical", <https://evtinwebsite.com/llms.txt>; rel="describedby"

Така ролите са ясни:

text

HTML
├── canonical → HTML
└── alternate → Markdown

Markdown
├── canonical → HTML
└── describedby → llms.txt

Markdown файлът не се опитва да се представи като втори основен URL на публикацията.

Той е алтернативно машинно четимо представяне на съдържанието, докато HTML адресът остава предпочитаната web версия.

Това разграничение е важно и извън AI темата.

При няколко URL-а с еднакво или много сходно съдържание canonical помага да покажем коя версия считаме за представителна. За Google това е сигнал за предпочитан URL, а не абсолютна команда. Търсачката може при определени обстоятелства да избере различен canonical.

При нашата реализация задачата е по-проста: не искаме Markdown версията да се конкурира концептуално с HTML страницата.

Искаме автоматизиран клиент да може да разбере:

това е същото съдържание в друг representation, а основната страница е HTML URL-ът.

Затова sitemap, canonical и Markdown discovery изпълняват различни задачи.

sitemap.xml помага URL-ът да бъде открит.

canonical показва коя версия считаме за основна.

rel="alternate" свързва HTML документа с неговото Markdown представяне.

А rel="describedby" вече ни отвежда към специализирания AI-ready слой на сайта.

И точно там започва по-новата част от тази архитектура: llms.txt.

Къде започва специализираната AI-ready подготовка

Досега почти всичко, което проверихме, е част от нормалната техническа основа на един добре изграден сайт.

HTTP достъпът, server-delivered HTML, robots.txt, semantic markup, Schema.org, sitemap и canonical адресите не са създадени специално за ChatGPT или други AI системи.

Те просто правят сайта по-предвидим за автоматизирани клиенти.

Едва тук стигаме до слой, който е създаден конкретно с LLM-oriented инструменти и agents предвид.

Какво е llms.txt

llms.txt е предложение за Markdown файл, чрез който един сайт може да предостави кратък контекст за себе си и подбран списък с важни ресурси в удобен за language models и agents формат.

Обичайното място е:

/llms.txt

Идеята не е файлът да съдържа целия сайт.

По-скоро той служи като ориентиращ слой: какъв е сайтът, кои са важните му секции и към кои по-подробни ресурси може да продължи автоматизиран клиент.

В актуалния v2 proposal се очаква agent да може да прегледа или претърси llms.txt, да намери релевантния ресурс и след това да последва връзката към по-подробно съдържание.

Самият формат е Markdown. Минималната структура започва с H1 за името на проекта или сайта, след което могат да се добавят кратко описание, допълнителен контекст и H2 секции със списъци от ресурси.

Важно е да уточним статуса му.

llms.txt е proposal, а не универсален web стандарт, който всеки crawler или AI продукт е длъжен да поддържа.

Това не го прави безполезен. Просто означава, че трябва да го разглеждаме като допълнителен интерфейс към съдържанието, а не като нов задължителен слой на интернет.

Ако темата ви интересува по-подробно, разглеждаме развитието на механизма и в статията за Agentic Browsing, Lighthouse и llms.txt.

Как изглежда llms.txt на evtinwebsite.com

Можем да проверим production файла директно:

bash

curl -L https://evtinwebsite.com/llms.txt

Началото му в момента изглежда така:

text

# EvtinWebsite

> Готови и индивидуални уебсайтове, лендинг страници и онлайн магазини с Next.js, както и миграция, преработка и поддръжка на съществуващи уеб проекти от DIMITROV.code.

EvtinWebsite предлага професионални уеб решения с ясни цени и без задължителни месечни такси:

След това файлът дава по-подробен контекст за услугите, собствеността върху проектите, поддръжката, AI-ready основата, пазара и начина на работа.

Например в AI-ready частта изрично е описано, че сайтът използва:

text

llms.txt
llms-full.txt
Markdown версии на основните публични страници
Markdown версии на блог статиите
Markdown версии на портфолио проектите

И още там е поставена важната граница:

Тази техническа подготовка подобрява машинната достъпност, но не е обещание или гаранция за цитиране и класиране от конкретна търсачка или AI платформа.

След общия контекст идват подбрани секции с конкретни ресурси.

Например:

text

## Главни страници
- [Начало](https://evtinwebsite.com/): [Markdown](https://evtinwebsite.com/index.md)
- [За нас](https://evtinwebsite.com/about): [Markdown](https://evtinwebsite.com/about.md)
- [Портфолио](https://evtinwebsite.com/portfolio): [Markdown](https://evtinwebsite.com/portfolio.md)
- [Уеб услуги за бизнес](https://evtinwebsite.com/services): [Markdown](https://evtinwebsite.com/services.md)

Тук вече се вижда разликата спрямо sitemap.

Sitemap обикновено изброява URL-и.

llms.txt може да бъде много по-селективен и да добави кратък контекст какво представлява всеки ресурс, както и да насочи директно към неговата Markdown версия.

В нашия случай например записът за индивидуална изработка не е просто URL. Той обяснява какъв тип страница стои зад него и предоставя отделен Markdown representation.

Това прави файла по-близък до кратка карта на съдържанието, отколкото до пълен индекс на сайта.

Какво llms.txt не прави

Наличието на llms.txt лесно може да бъде надценено.

Файлът не заменя robots.txt.

Ако crawler-ът няма достъп до страницата или е спрян от WAF, наличието на линк към нея в llms.txt няма да премахне тази пречка.

Не заменя и sitemap.xml.

Sitemap и llms.txt имат различна задача. Единият предоставя списък с URL-и за discovery, а другият може да предложи подбран LLM-oriented контекст и връзки към подходящи representations.

llms.txt не заменя canonical адресите и не решава отношенията между дублирани или алтернативни версии на едно съдържание.

Не поправя и слабата страница.

Ако основният HTML е недостъпен, съдържанието е неясно или важната информация липсва, добавянето на още един текстов файл не решава основния проблем.

Също толкова важно е какво не можем да обещаем от другата страна.

Самият proposal не определя llms.txt като универсален ranking signal и не обещава, че наличието му ще доведе до цитиране от ChatGPT, Gemini, Perplexity или друга конкретна система.

По-точно е да го разглеждаме като допълнителен discovery и context слой за agents, които решат да го използват.

Това е и причината да стигаме до него чак сега.

Ако сайтът не връща нормален HTTP response, няма смисъл първо да обсъждаме llms.txt.

Ако съдържанието липсва от документа, не го поправяме с llms.txt.

Ако crawler-ът е блокиран на инфраструктурно ниво, файлът не отваря firewall-а.

Но когато основната web архитектура вече е здрава, llms.txt може да добави нещо, което стандартните механизми не дават толкова директно: кратко ориентиране в сайта и подбран път към съдържание, подходящо за LLM-oriented инструменти.

Следващият въпрос е как един agent изобщо разбира, че този файл и Markdown версията на конкретната страница съществуват.

Точно това е проблемът, който llms.txt v2 се опитва да реши с новите discovery механизми.

Какво ново носи llms.txt v2

Да имаме llms.txt и Markdown версии на страниците е полезно, но остава един практичен проблем.

Как една автоматизирана система, която вече е попаднала на HTML страницата, разбира, че за нея съществува и по-чисто Markdown представяне?

И как разбира кой llms.txt файл описва тази част от сайта?

Това е една от съществените промени в llms.txt v2.

Проблемът не е само да имаш Markdown версия

Да приемем, че имаме:

https://evtinwebsite.com/index.md

Файлът може да съществува, да връща 200 OK и да съдържа отлично Markdown представяне на началната страница.

Но ако една система първо е отворила:

https://evtinwebsite.com/

самото съществуване на /index.md не ѝ казва непременно, че двата ресурса са свързани.

Бихме могли да разчитаме клиентът да предполага URL схема: / → /index.md или /page → /page.md.

Но това вече е догадка.

Различните сайтове могат да използват различни URL структури, а v2 допуска повече от един модел за Markdown адресите.

Затова по-добрият подход е връзката да бъде декларирана от самата страница.

Това е разликата между наличност и discovery.

Един ресурс може да съществува и да бъде публично достъпен, без системата лесно да разбере, че е свързан с документа, който разглежда в момента.

rel="alternate" за Markdown representation

За да свърже HTML страницата с нейното Markdown представяне, v2 препоръчва стандартната link relation:

text

<link
  rel="alternate"
  type="text/markdown"
  href="..."
>

При началната страница на evtinwebsite.com реалният production HTML съдържа:

html

<link
  rel="alternate"
  type="text/markdown"
  href="https://evtinwebsite.com/index.md"
/>

Можем да го проверим директно:

bash

curl -sSL https://evtinwebsite.com/ \
  | grep -oEi '<link[^>]+type="text/markdown"[^>]*>'

При нашата production проверка резултатът беше:

html

<link rel="alternate" type="text/markdown" href="https://evtinwebsite.com/index.md"/>

Това вече премахва необходимостта клиентът да предполага къде се намира Markdown версията.

HTML документът сам казва:

text

това е текущата страница
          ↓
ето нейното алтернативно Markdown представяне

При blog публикациите механизмът работи по същия начин.

HTML статията:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti

обявява конкретната си Markdown версия:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

Това е page-level discovery. Не е необходимо една AI система да търси целия llms.txt, само за да разбере дали конкретната страница има Markdown representation.

rel="describedby" и връзката с llms.txt

Вторият discovery механизъм свързва страницата с llms.txt, който я описва.

V2 използва:

html

<link
  rel="describedby"
  href="https://evtinwebsite.com/llms.txt"
/>

Точно това вече връща и production HTML на evtinwebsite.com.

Можем да го проверим с:

text

curl -sSL https://evtinwebsite.com/ \
  | grep -oEi '<link[^>]+rel="describedby"[^>]*>'

Реалният резултат е:

html

<link rel="describedby" href="https://evtinwebsite.com/llms.txt"/>

Така система, която е попаднала директно на началната страница, получава две отделни връзки:

text

HTML страница
├── rel="alternate" → Markdown representation
└── rel="describedby" → llms.txt

При нас root llms.txt описва целия сайт.

V2 позволява и по-специфични файлове в отделни пътища. Например секция /docs/ може да има собствен /docs/llms.txt, който да описва ресурсите под този path.

Затова смисълът на describedby не е просто „ето някакъв llms.txt“, а по-точно:

ето llms.txt файлът, който описва този ресурс.

V2 допуска тези relations да бъдат предоставени не само като HTML <link> елементи, но и чрез HTTP Link header.

Това е особено полезно при non-HTML ресурси.

Нашите Markdown версии например връщат:

text

Link: <https://evtinwebsite.com/>; rel="canonical",
      <https://evtinwebsite.com/llms.txt>; rel="describedby"

Можем да го видим с:

bash

curl -sSI https://evtinwebsite.com/index.md \
  | grep -i '^link:'

При blog Markdown страниците canonical адресът естествено е различен:

text

Link: <https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti>; rel="canonical",
      <https://evtinwebsite.com/llms.txt>; rel="describedby"

Така дори клиент, който е попаднал директно на .md ресурса, може да открие както основната HTML версия, така и приложимия llms.txt.

Защо discovery е различно от наличност

Това разграничение е може би най-важната идея във v2.

Можем да създадем:

/llms.txt/index.md/about.md/blog/article.md

и всички файлове да връщат 200 OK.

Това доказва, че ресурсите съществуват.

Не доказва обаче, че система, попаднала на /about, има ясен начин да разбере:

text

/llms.txt
/index.md
/about.md
/blog/article.md

Discovery механизмът описва точно тези отношения.

При evtinwebsite.com след внедряването на v2 връзките вече имаме:

text

                   ┌───────────────┐
                   │   llms.txt    │
                   └───────▲───────┘
                           │
                     describedby
                           │
┌──────────────┐    ┌──────┴───────┐
│ Markdown     │◄───│ HTML страница│
│ representation    └──────────────┘
└──────┬───────┘       alternate
       │
       └── canonical → HTML
       │
       └── describedby → llms.txt

„Имаме llms.txt“ и „имаме Markdown файлове“ не са достатъчно точни технически твърдения.

По-полезно е да проверим целия път:

text

ресурсът съществува
        ↓
достъпен е
        ↓
деклариран е от свързаната страница
        ↓
връзката може да бъде открита машинно

Точно тази последна част е едно от основните допълнения на llms.txt v2.

Markdown версията на една страница какво добавя

Дотук видяхме как HTML страницата може изрично да обяви свое алтернативно Markdown представяне чрез rel="alternate".

Остава въпросът защо изобщо бихме поддържали втора версия на същото съдържание.

Причината не е, че Markdown е някакъв универсално „предпочитан от AI“ формат. Различните системи могат спокойно да работят и с HTML.

Markdown representation има по-практична роля: предоставя основното съдържание в по-изчистена текстова форма, без голяма част от markup-а, layout компонентите, навигацията, JavaScript payload-а и останалата инфраструктура на нормалната web страница.

HTML страницата е за браузъра, Markdown representation е по-чисто текстово представяне

Една нормална HTML страница може да съдържа много повече от самата информация, която потребителят чете.

При реален Next.js сайт в response-а могат да присъстват:

text

navigation
CSS resources
JavaScript bundles
responsive images
structured data
interactive components
footer
tracking integrations
framework-specific markup

Това е напълно нормално. HTML страницата трябва да бъде пълноценен web документ и да работи в браузър.

Markdown representation може да се концентрира върху друго:

text

# Основно заглавие

Кратко въведение към темата.

## Първа секция

Основното съдържание...

## Втора секция

Още съдържание...

[Свързан ресурс](https://example.com/resource)

Получаваме заглавията, параграфите и връзките, но без голяма част от визуалния и application слой.

Това намалява количеството странична информация, която един text-oriented parser трябва да отдели от същинското съдържание.

Но е важно да не обръщаме причинно-следствената връзка.

Не казваме:

Markdown се цитира по-добре от HTML.

Можем да кажем нещо по-конкретно:

Markdown representation предоставя допълнителен, по-компактен начин основното съдържание на страницата да бъде извлечено като структуриран текст.

Как изглежда реална Markdown страница на evtinwebsite.com

Нека отново използваме production сайта, вместо измислен пример.

Имаме HTML статия:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti

и нейното Markdown representation:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

Можем да го изтеглим директно:

text

curl -L \
  https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

При production проверката ресурсът върна:

text

HTTP/2 200
content-type: text/markdown; charset=utf-8

а самото съдържание започва директно със статията:

text

# Защо всяка нова AI промяна започва да чупи сайта ти

Category: Уеб и бизнес

> Всяка нова AI промяна чупи нещо друго? Виж кога проблемът вече не е в prompt-а, а в архитектурата на проекта и кога има смисъл от refactoring.

Добавяш нов бутон.

Бутонът работи.

Това вече е съвсем различно от пълния HTML response на същата страница.

Няма navigation компоненти, CSS класове, Next.js runtime информация или JavaScript bundles. Получаваме текстовото съдържание във формат, в който заглавията, параграфите и links остават ясно различими.

Връзката между двете версии също е изрично декларирана.

HTML страницата сочи към Markdown:

text

<link
  rel="alternate"
  type="text/markdown"
  href="https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md"
/>

Markdown response-ът сочи обратно към HTML canonical и към llms.txt:

text

Link: <https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti>; rel="canonical",
      <https://evtinwebsite.com/llms.txt>; rel="describedby"

Така имаме свързан модел:

text

HTML article
     ↓
Markdown representation
     ↓
llms.txt context

Markdown
     ↓
canonical HTML

След публикуването на тази статия същият механизъм ще създаде и нейно Markdown representation. Така проверките, които правим тук върху друга реална публикация, ще могат да бъдат повторени и върху самия материал, който четете.

Какво трябва да остане еднакво между HTML и Markdown

Markdown версията не трябва да се превръща във второ, независимо съдържание.

Ако HTML страницата казва едно, а .md версията друго, вече сме създали два различни източника на информация за един и същ URL concept.

Основният фактологичен текст трябва да остане синхронизиран.

Същото важи за структурата на материала. H1, основните секции, важните връзки и съществените твърдения не трябва произволно да се променят само защото representation-ът е различен.

Визуалното представяне естествено няма как да бъде еднакво.

HTML може да съдържа cards, grids, интерактивни елементи, изображения, buttons и responsive layout. Markdown версията може да сведе същите части до headings, текст и links.

Различен формат не означава различна истина.

Добър начин да го мислим е:

text

HTML
= пълното web представяне

Markdown
= текстово представяне на същото основно съдържание

Ако в Markdown representation включваме автор, категория, дата или друга metadata информация, тя също трябва да отговаря на реалната страница.

Това е особено важно при автоматично генерирани .md версии. Колкото по-малко съдържание поддържаме ръчно на две места, толкова по-малък е рискът двете версии постепенно да се разминават.

Markdown не поправя слабо съдържание

Това е същото ограничение, което видяхме при Schema.org и llms.txt.

Да добавим:

/page.md

не прави автоматично страницата по-полезна.

Ако основният материал не казва ясно какво представлява услугата, кой я предлага, как работи или защо информацията е важна, Markdown версията просто ще предостави същото неясно съдържание в по-чист формат.

Ако една статия е повърхностна, .md файлът няма да добави липсваща експертиза.

Ако твърденията са неточни, Markdown няма да ги направи по-достоверни.

Ако две секции си противоречат, по-чистият markup не разрешава противоречието.

Затова Markdown representation има смисъл като част от вече добре изградена съдържателна и техническа основа.

То може да намали техническия шум около информацията.

Не може да подобри самата информация вместо нас.

Можем ли да проверим дали AI crawler действително посещава сайта

Дотук проверявахме дали сайтът създава условия един crawler да достигне до съдържанието.

Това обаче не ни казва дали конкретен crawler действително е посещавал сайта.

Ако имаме достъп до server, CDN или WAF logs, можем да потърсим реални заявки и да преминем от „би трябвало да има достъп“ към „имаме записана заявка“.

Server logs са по-силно доказателство от предположението

В зависимост от инфраструктурата заявките могат да бъдат записани в web server logs, Cloudflare, друг CDN, reverse proxy или WAF.

Ако използваме стандартен access log, първата проверка може да бъде нещо от типа:

bash

grep -Ei 'OAI-SearchBot|GPTBot|PerplexityBot|Perplexity-User' access.log

Ако намерим например заявка с OAI-SearchBot, timestamp, конкретен URL и HTTP response code, вече имаме доказателство, че заявка с този user agent е достигнала до нашата инфраструктура.

Логовете могат да ни покажат и неща, които robots.txt не може:

text

кой URL е поискан
кога е поискан
какъв status code е върнат
колко често идват заявките
дали crawler-ът получава 200, 403 или 429

Това е особено полезно при проблеми с WAF или rate limiting. Ако robots.txt разрешава достъп, но в логовете виждаме серия от 403, вече знаем на кой слой да търсим проблема.

Важно е обаче да не правим по-голям извод от наличните данни.

Запис в server log доказва, че заявката е достигнала до сайта.

Той не доказва, че съдържанието е било включено в индекс, запазено, цитирано или използвано в конкретен отговор.

User-Agent сам по себе си не винаги е достатъчно доказателство

Има още един проблем.

HTTP User-Agent header може да бъде подправен.

Всеки автоматизиран клиент технически може да изпрати:

text

User-Agent: OAI-SearchBot

без заявката действително да идва от инфраструктурата на OpenAI.

Затова при по-сериозна проверка не разчитаме единствено на името в access log.

Когато доставчикът публикува официален механизъм за проверка, можем да сравним и IP адреса или да използваме verified bot функционалността на CDN/WAF доставчика.

OpenAI например публикува официални IP диапазони за OAI-SearchBot и препоръчва при инфраструктурна проверка да не се разчита само на краткотрайни IP наблюдения от логовете. По-сигурният подход е комбинация от user agent, официално публикувани диапазони и bot verification механизмите на инфраструктурата.

Perplexity подхожда по сходен начин. За PerplexityBot и Perplexity-User има отделни публикувани IP списъци, а при WAF конфигурация документацията препоръчва да се комбинират проверка на user agent и IP source.

Следователно:

User-Agent съвпада

е полезен сигнал.

По-силното доказателство е:

text

User-Agent съвпада
        +
източникът отговаря на официалния verification механизъм

Тази проверка става особено важна, ако на базата на crawler identity ще създаваме firewall allowlist или ще променяме security правила.

Referral traffic от ChatGPT е друг тип измерване

Crawler traffic и човешките посещения от AI платформа не трябва да се смесват.

OAI-SearchBot може да посети страницата, без човек непосредствено след това да отвори сайта.

Обратното също е възможно: потребител може да види линк към нашата страница в ChatGPT и да го последва.

Тогава вече говорим за referral traffic.

OpenAI посочва, че посещенията от ChatGPT Search могат да бъдат проследявани чрез analytics платформи и че referral URL-ите включват:

utm_source=chatgpt.com

Това позволява подобен трафик да бъде отделен в инструменти като Google Analytics.

Но и тук измерваме нещо конкретно.

Referral traffic показва, че потребител е стигнал до сайта през линк от ChatGPT.

Той не ни казва колко пъти страницата е била разглеждана от AI система, без потребителят да кликне върху нея. Не показва и всички случаи, в които информацията от страницата може да е участвала в генериран отговор.

Затова е полезно да разграничим три вида доказателства:

text

crawler log
→ автоматизирана заявка е достигнала сайта

AI referral
→ потребител е последвал линк към сайта

цитиране в конкретен AI отговор
→ страницата е показана като източник в този отговор

Трите могат да бъдат свързани, но не са взаимозаменяеми.

Можем ли просто да попитаме AI системата

Да. Това също е полезен тест, стига да сме точни какво доказва.

При подготовката на тази статия използвахме например заявката:

Кои фирми в България предлагат изработка на Next.js сайт за малък бизнес?

Тя е умишлено формулирана като реално търсене на доставчик. Не подаваме името evtinwebsite.com и не питаме системата какво знае за конкретния ни сайт. Тестът е направен в инкогнито прозорец и без вход в потребителски акаунт, за да ограничим влиянието на предишна история и персонализация върху резултата.

При теста Google AI Overview включи DIMITROV.code / evtinwebsite.com сред конкретните предложения за заявката и го постави в секцията с решения за малък бизнес.

Google AI Overview резултат за търсене на фирми за изработка на Next.js сайт за малък бизнес в България, включващ DIMITROV.code и evtinwebsite.com

При отделен тест в ChatGPT резултатът също включи DIMITROV.code и в конкретния отговор го постави на първо място сред изброените варианти. Отговорът съдържаше и конкретна информация за Next.js, ценовите нива и срока за изработка.

ChatGPT отговор за фирми в България, предлагащи изработка на Next.js сайт за малък бизнес, с DIMITROV.code сред предложените резултати

ChatGPT резултат с DIMITROV.code и evtinwebsite.com при търсене на изработка на Next.js сайт за малък бизнес в България

Това вече е интересен резултат, но трябва да го четем правилно.

Не можем да заключим:

text

показахме се веднъж
        ↓
класираме се №1 в ChatGPT или Google AI

Можем да кажем нещо значително по-точно:

При тази конкретна заявка и в момента на теста платформата показа evtinwebsite.com сред източниците или предложенията си.

Ако в отговора присъства конкретна страница като citation или source, сигналът е още по-силен, защото можем да видим кой URL е използван или показан.

Резултатът обаче може да се промени при друга формулировка, друг момент, различен режим на търсене или друга налична web информация.

Затова подобен тест е полезен като наблюдение на крайния резултат, но не заменя техническата проверка.

Най-пълната картина получаваме, когато комбинираме двете:

text

техническа проверка
→ сайтът е достъпен и машинно четим

реална AI заявка
→ виждаме дали системата действително го показва при конкретно търсене

Едното проверява възможността.

Другото показва реален резултат в конкретен момент.

„ChatGPT може да прочете сайта ми“ не означава „ChatGPT знае бизнеса ми“

Дотук проверявахме дали една AI-oriented система има техническа възможност да достигне до сайта и да извлече смислено съдържанието му.

Това е важно, но не трябва да го бъркаме с друг въпрос:

Какво всъщност знае системата за бизнеса и кои източници ще използва, когато някой зададе конкретен въпрос?

Техническата достъпност е само една част от този процес.

AI системата може да използва други източници

Когато потребител попита за конкретен бизнес, услуга или тема, сайтът на самия бизнес не е задължително единственият наличен източник.

В зависимост от платформата, заявката и начина, по който се формира отговорът, могат да бъдат използвани и други публично достъпни web ресурси.

Това могат да бъдат например:

други сайтове, които споменават бизнеса;
публични directories и каталози;
новинарски публикации;
публични документи;
search results;
други достъпни страници, които системата прецени като релевантни.

Затова дори отлично подготвеният собствен сайт не съществува във вакуум.

Ако една AI система търси информация за DIMITROV.code, тя потенциално може да срещне evtinwebsite.com, но и други публични страници, които съдържат информация за бизнеса, неговите проекти или авторите зад него.

Тук вече въпросът не е само:

Може ли системата да прочете сайта?

а и:

Как се вписва информацията от този сайт сред останалите достъпни източници?

Техническата проверка, която правим в тази статия, не може сама да отговори на втория въпрос.

Сайтът може да бъде прочетен и въпреки това да не бъде избран като източник

Да приемем, че сме направили всичко дотук:

text

страницата връща 200
основният текст е в HTML
robots.txt разрешава достъп
структурата е ясна
Schema.org е коректна
sitemap и canonical са настроени
llms.txt съществува
Markdown representation е откриваем

Това е силна техническа основа.

Но от нея не следва автоматично, че ChatGPT ще цитира тази страница

Една система може да достигне до URL-а и въпреки това да не го избере при конкретна заявка.

Причините могат да бъдат различни.

Страницата може да не е достатъчно релевантна за конкретния въпрос. Информацията може да е прекалено обща. Друг източник може да предоставя по-пряко обяснение или по-подходящ контекст. При някои теми значение могат да имат и фактори като актуалност, качество на информацията и доверието към източника.

Тук вече навлизаме отвъд чистата техническа подготовка.

За целите на тази статия е достатъчно да направим едно важно разграничение:

Technical AI readiness отстранява част от техническите пречки. Не решава целия проблем с видимостта.

Можем да направим сайта достъпен.

Можем да предоставим чист HTML.

Можем да опишем структурата му по-ясно.

Можем да улесним discovery на Markdown representations и llms.txt.

Не можем чрез тези настройки да задължим конкретна AI система да използва страницата в конкретен отговор.

Затова и най-силното твърдение, което можем да направим след техническия одит, не е:

ChatGPT знае бизнеса ми.

По-точно е:

Сайтът не поставя очевидни технически пречки пред системите, които искат да достигнат и обработят публичното му съдържание.

Оттук нататък вече започват въпросите за това как самото съдържание се конкурира с останалите достъпни източници.

Практически тест: можеш ли да прочетеш evtinwebsite.com като машина

Вече разгледахме отделните слоеве. Нека ги съберем в една проверка, която може да бъде изпълнена директно от терминала.

Ще използваме evtinwebsite.com, без специален browser session и без да разчитаме на това как страницата изглежда визуално.

curl не е AI crawler и този тест не симулира вътрешната работа на ChatGPT. Той ни позволява да проверим нещо по-конкретно: какво може да получи обикновен автоматизиран HTTP клиент и какви machine-readable връзки сме публикували.

1. Проверяваме HTTP отговора

Започваме с най-основното:

bash

curl -I https://evtinwebsite.com/

Търсим нормален HTTP response, например:

text

HTTP/2 200
content-type: text/html; charset=utf-8

Това ни казва, че URL-ът отговаря и връща HTML документ.

Както видяхме по-рано, -I използва HEAD. Ако диагностицираме проблем и искаме headers от реална GET заявка, можем да използваме:

text

curl -sS -D - -o /dev/null https://evtinwebsite.com/

При тази първа стъпка още не знаем дали страницата съдържа полезна информация. Знаем само, че можем да я достигнем.

2. Извличаме HTML

Следващата команда изтегля самия документ:

text

curl -Ls https://evtinwebsite.com/

-L следва redirects, а -s премахва progress информацията на curl.

Тук вече виждаме response body, който автоматизиран HTTP клиент получава от сървъра.

При evtinwebsite.com това не е празен container, който чака JavaScript да създаде цялото съдържание. В HTML response-а присъстват заглавия, текст, links, metadata и structured data.

3. Търсим реално съдържание

Целият HTML е голям, затова можем да потърсим конкретен текст:

text

curl -Ls https://evtinwebsite.com/ | grep -i "Евтин уебсайт"

В response-а намираме основното заглавие:

Евтин уебсайт за твоя бизнес. Готов до 5 дни.

Това е прост, но много полезен тест.

Вече знаем не само че URL-ът връща 200, а че част от основната информация за страницата присъства в получения документ.

Същият подход може да се използва за име на бизнес, услуга, продукт или друг ключов факт, който очакваме машината да може да извлече.

4. Проверяваме robots.txt

След това проверяваме crawl политиката:

text

curl -L https://evtinwebsite.com/robots.txt

Тук гледаме дали публичното съдържание е разрешено и дали няма правило, което блокира crawler-а, който ни интересува.

При нашата конфигурация публичните страници попадат под общото:

text

User-agent: *
Allow: /

а технически и административни пътища са изключени отделно.

Тази проверка не доказва, че crawler действително е посещавал сайта. Тя показва каква политика сме декларирали за обхождането.

5. Проверяваме sitemap

Следващият discovery механизъм е:

bash

curl -L https://evtinwebsite.com/sitemap.xml

Можем да проверим и конкретен URL, вместо да четем целия XML:

text

curl -Ls https://evtinwebsite.com/sitemap.xml \
  | grep "zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti"

Търсим публикацията:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti

Ако URL-ът присъства, имаме още един explicit discovery path към него.

Отново, sitemap presence не означава автоматично индексиране или използване от AI система. Тук проверяваме само дали URL-ът е публикуван в sitemap структурата.

6. Отваряме llms.txt

Сега стигаме до специализирания AI-ready слой:

bash

curl -L https://evtinwebsite.com/llms.txt

Файлът започва с:

text

# EvtinWebsite

> Готови и индивидуални уебсайтове, лендинг страници и онлайн магазини с Next.js, както и миграция, преработка и поддръжка на съществуващи уеб проекти от DIMITROV.code.

По-надолу намираме подбрани страници, услуги, portfolio проекти и техните Markdown representations.

С тази проверка установяваме, че llms.txt не е просто споменат някъде в кода. Ресурсът действително е публично достъпен и съдържа контекст за сайта.

7. Проверяваме discovery връзките

При evtinwebsite.com discovery връзките на HTML страниците са декларирани директно в <head> чрез стандартни <link> елементи.

Markdown representation проверяваме така:

bash

curl -sSL https://evtinwebsite.com/ \
  | grep -oEi '<link[^>]+type="text/markdown"[^>]*>'

Production страницата връща:

html

<link
  rel="alternate"
  type="text/markdown"
  href="https://evtinwebsite.com/index.md"
/>

След това проверяваме връзката към llms.txt:

bash

curl -sSL https://evtinwebsite.com/ \
  | grep -oEi '<link[^>]+rel="describedby"[^>]*>'

Резултатът е:

text

<link
  rel="describedby"
  href="https://evtinwebsite.com/llms.txt"
/>

Така самият HTML документ декларира две отношения:

text

HTML
├── alternate → Markdown representation
└── describedby → llms.txt

llms.txt v2 допуска тези discovery relations да бъдат публикувани както чрез HTML <link> елементи, така и чрез HTTP Link header. При HTML страниците на evtinwebsite.com използваме първия вариант.

При Markdown endpoint-ите ситуацията е различна. Там няма HTML <head>, затова свързаната информация се подава чрез HTTP Link header:

bash

curl -sSI https://evtinwebsite.com/index.md \
  | grep -i '^link:'

Резултатът е:

text

Link: <https://evtinwebsite.com/>; rel="canonical",
      <https://evtinwebsite.com/llms.txt>; rel="describedby"

Така HTML и Markdown representations използват подходящ механизъм според формата си, без да е необходимо една и съща discovery информация да се дублира и като HTML markup, и като HTTP header.

8. Отваряме Markdown representation

Накрая следваме реалната Markdown връзка.

За началната страница това е:

bash

curl -L https://evtinwebsite.com/index.md

Но за по-добър тест можем да използваме конкретна публикация:

https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

Отваряме я с:

text

curl -L \
  https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md

Тук трябва да разпознаем същото основно съдържание, което присъства в HTML статията, но представено като Markdown.

Има още една проверка, която си заслужава:

bash

curl -sSI \
  https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti.md \
  | grep -iE '^(content-type|link):'

Очакваме Markdown content type:

content-type: text/markdown; charset=utf-8

и HTTP Link header, който свързва representation-а обратно с основната HTML страница и с llms.txt:

text

Link: <https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti>; rel="canonical",
      <https://evtinwebsite.com/llms.txt>; rel="describedby"

Така затваряме целия път:

text

HTTP 200
   ↓
HTML съдържание
   ↓
robots.txt
   ↓
sitemap.xml
   ↓
llms.txt
   ↓
HTML discovery
   ↓
Markdown representation
   ↓
canonical HTML + llms.txt context

Нито една от тези проверки сама по себе си не доказва, че ChatGPT ще цитира страницата.

Заедно обаче дават доста по-конкретен отговор на въпроса, с който започнахме:

Може ли автоматизирана система да достигне до публичното съдържание на evtinwebsite.com, да извлече основния текст и да открие допълнителните machine-readable representations, които сме публикували?

За проверените тук страници техническият отговор е да.

Пет нива на техническа AI готовност

Това не е официална класификация на OpenAI, Google или llmstxt.org. Използваме я като практическа рамка за технически одит.

След всички проверки дотук можем да подредим техническата AI готовност на един сайт в пет последователни нива.

Идеята не е да създаваме нов стандарт.

По-скоро ни трябва работещ начин да различим базовия достъп от по-специализираната подготовка и да видим къде точно се намира проблемът.

Ниво 1: достъп

Преди всичко останало URL-ът трябва реално да може да бъде достигнат.

Тук проверяваме:

text

URL
↓
HTTP response
↓
липса на инфраструктурна блокировка

Практически това означава нормален response, липса на redirect loop, authentication wall, CAPTCHA, WAF блокировка или постоянно 403, 429 и 5xx поведение.

Ако crawler не може да стигне до документа, всичко след това губи значение.

llms.txt, Schema.org и Markdown representation не могат да компенсират недостъпен URL.

Ниво 2: съдържание

Следващият въпрос е какво получаваме след успешната заявка.

Основната информация трябва действително да присъства в response-а или да бъде достъпна по начин, който автоматизираният клиент може да обработи.

Тук проверяваме например:

bash

curl -Ls https://example.com/

и търсим реалните факти, които очакваме да присъстват:

text

име на бизнеса
основна услуга
заглавие
описание
важни страници
съществен текст

Страница, която връща 200 OK, но предоставя почти празна app shell без основното съдържание, е на различно техническо ниво от документ, който връща смисления текст директно.

Ниво 3: структура

Когато съдържанието вече е достъпно, проверяваме дали е организирано по ясен начин.

Тук попадат:

text

semantic HTML
H1, H2 и последователна heading структура
title и description
canonical
Schema.org structured data
ясни отношения между отделните части на документа
логична информационна архитектура

Това ниво не добавя ново съдържание.

То помага вече съществуващата информация да бъде описана по-предвидимо.

Например текстът „изработка на уебсайт“ може просто да присъства някъде в HTML, но е различно, когато е част от ясно структурирана service page с H1, секции, вътрешни връзки и подходящ structured data слой.

Ниво 4: discovery

Следващият въпрос е дали отделните ресурси могат логично да бъдат открити.

Тук разглеждаме:

text

internal links
sitemap.xml
robots.txt
URL структура
връзките между основни и по-дълбоки страници

Това ниво описва как един crawler може да преминава през сайта и какви discovery paths сме предоставили.

Например една blog публикация може да бъде открита чрез вътрешна връзка, sitemap или друг публичен URL.

robots.txt също влиза тук, защото discovery без разрешение за обхождане може да се окаже безполезно.

Важното е да не смесваме discovery с selection.

Фактът, че един URL е лесен за откриване, не означава, че конкретна система задължително ще го избере като източник.

Ниво 5: специализиран AI слой

Едва на последното ниво добавяме механизми, създадени конкретно с LLM-oriented инструменти и agents предвид.

При evtinwebsite.com това включва:

text

llms.txt
Markdown representations
rel="alternate" type="text/markdown"
rel="describedby"
canonical връзка обратно от Markdown към HTML

Този слой може да даде по-чисто текстово представяне, допълнителен контекст и по-ясни discovery relations между HTML, Markdown и llms.txt.

Но той стои най-отгоре с причина.

Ако Ниво 1 е счупено, AI слоят няма да отвори firewall-а.

Ако Ниво 2 е слабо, Markdown просто ще представи слабо съдържание в по-чист формат.

Ако Ниво 3 е хаотично, llms.txt няма да поправи цялата информационна архитектура.

Ако Ниво 4 липсва, отделните ресурси могат да останат трудни за откриване независимо от това колко добре са написани.

Затова петте нива можем да обобщим така:

text

1. Достъп
   ↓
2. Съдържание
   ↓
3. Структура
   ↓
4. Discovery
   ↓
5. Специализиран AI слой

Тази рамка е полезна най-вече при диагностика.

Вместо да питаме:

„AI-ready ли е сайтът?“

можем да зададем по-точен въпрос:

На кое ниво възниква техническата пречка?

Така llms.txt престава да изглежда като универсално решение и заема реалното си място: последен специализиран слой върху вече достъпен, разбираем и добре организиран сайт.

Какво тази проверка не може да ти каже

Дотук проверихме много неща, но всички те са наблюдаеми отвън.

Можем да видим HTTP response-а.

Можем да изтеглим HTML.

Можем да проверим robots.txt, sitemap, canonical, structured data, llms.txt, Markdown representations и discovery връзките между тях.

Можем дори да използваме server logs, за да установим дали конкретен crawler е достигнал до сайта.

Това обаче не означава, че виждаме какво се случва вътре в самата AI система.

Не можем да видим вътрешния контекст на ChatGPT

Когато в заглавието на статията питаме какво „виждат“ AI системите, използваме това като практическо съкращение.

Тестът ни показва какво е достъпно за автоматизиран клиент и каква информация може да бъде извлечена от публичния сайт.

Не виждаме вътрешния context window на ChatGPT.

Не можем да инспектираме кои документи са били заредени при конкретен отговор, как са били оценени всички налични източници или какво вътрешно представяне е изградила системата за даден бизнес.

Дори когато виждаме конкретен URL като citation, наблюдаваме крайния резултат, а не целия вътрешен процес, довел до него.

Затова тази проверка отговаря на въпрос от типа:

Може ли системата технически да достигне и извлече съдържанието?

Тя не отговаря на:

Какво точно „мисли“ системата за този сайт в момента?

Не можем да гарантираме цитиране

Техническата проверка може да покаже, че страницата е достъпна и съдържанието ѝ може да бъде обработено. Тя не може да гарантира, че точно тази страница ще бъде избрана при конкретна заявка.

Най-краткото разграничение е:

crawlable ≠ selected as source

Изборът на източник остава решение на конкретната система в контекста на конкретната заявка.

Не можем да сведем AI visibility до един файл или една настройка

Това може би е най-важният извод от целия тест.

llms.txt не е AI visibility.

Schema.org не е AI visibility.

Markdown representation не е AI visibility.

Sitemap не е AI visibility.

Нито една от тези части не работи като универсален switch:

text

OFF
↓
добавяме една настройка
↓
ON

Всяка решава различен технически проблем.

robots.txt управлява crawl policy.

Sitemap подпомага discovery.

Canonical описва предпочитаната версия.

Schema.org добавя structured relationships.

Markdown representation предоставя по-чист текстов формат.

llms.txt може да даде допълнителен контекст и curated discovery слой.

Ползата идва от това, че тези механизми работят върху една и съща здрава основа.

Ако съдържанието е слабо, няма файл, който да го направи авторитетно.

Ако URL-ът е блокиран, Schema няма да отвори достъпа.

Ако информацията липсва, Markdown няма какво да „изчисти“.

Ако страницата не е релевантна за конкретната заявка, llms.txt не може да я наложи като source.

Точно затова предпочитаме да говорим за техническа AI готовност, а не за магическа AI оптимизация.

Техническата част може да премахне пречки.

Не може да гарантира крайното решение на външна AI система.

Проверка на собствения ти сайт за 10 минути

Ако искаш да приложиш същия тест върху собствен сайт, не е необходимо да започваш със сложен AI audit инструмент.

За първоначална техническа проверка можеш да минеш през следните стъпки.

Провери HTTP status.
Изтегли HTML и намери основния текст.
Прегледай robots.txt.
Провери sitemap.
Виж metadata, canonical и heading структурата.
Установи дали основното съдържание зависи от client-side rendering.
Ако използваш AI-ready слой, отвори llms.txt и Markdown representation.
Провери rel="alternate" и rel="describedby".
Сравни HTML и Markdown съдържанието.
Ако имаш logs, потърси реални crawler заявки.

Ако минеш успешно през тези проверки, можеш да кажеш нещо доста по-конкретно от:

„Сайтът ми е AI оптимизиран.“

По-точното твърдение е:

Основното съдържание на сайта е технически достъпно, структурирано и предоставено по начини, които улесняват автоматизираното му откриване и обработване.

Това не обещава ranking, citation или включване в конкретен AI отговор.

Но вече е проверимо техническо твърдение, а не маркетингов етикет.

Как сме решили това при evtinwebsite.com

При evtinwebsite.com използваме същите принципи, които разгледахме в тази статия.

Публичното съдържание е достъпно в HTML, страниците имат ясна структура, metadata, canonical адреси, structured data, sitemap и контролирана crawl политика. Върху тази основа сме добавили и специализиран AI-ready слой с llms.txt, Markdown representations и discovery връзки между отделните формати.

Това не е отделна „AI версия“ на сайта. По-скоро е допълнение към нормалната техническа архитектура, което прави публичното съдържание по-лесно за откриване, извличане и интерпретиране от автоматизирани системи.

Част от тези проверки използваме и в собствения ни SEO Audit Engine, където техническото SEO и AI visibility се разглеждат като свързани, но различни слоеве. По-подробно за llms.txt и новите discovery механизми сме писали в Agentic Browsing: Lighthouse вече проверява и llms.txt, а по-широкия контекст около machine-readable съдържанието и generative search разглеждаме в Как да оптимизирате сайта си за генеративния AI на Google.

Ако не си сигурен какво действително връща сайтът ти на crawler-и и автоматизирани системи, започни с техническа проверка.

Това обикновено дава много повече информация от това просто да питаш ChatGPT дали „познава“ бизнеса ти.

Следващият тест: murrayresto.eu

Следващият ни тест ще бъде върху наш реален проект: murrayresto.eu.

Там ще видим какво сме променили по техническата и съдържателната структура на сайта и какво можем реално да измерим след тези оптимизации.

Ще проверим и нещо още по-интересно: как AI системите виждат този локален бизнес, успяват ли да открият правилната информация и появява ли се сайтът като източник или препоръка при реални потребителски въпроси.

Засега ще оставим само това:

AI резултат за Murray Restaurant при търсене на най-добрите ливански ресторанти в София

Често Задавани Въпроси

Може ли ChatGPT да прочете всеки сайт?

Не. За да достигне до съдържанието, сайтът трябва да е технически достъпен за съответния crawler или автоматизиран клиент. Проблем могат да създадат robots.txt, WAF правила, authentication, rate limiting, JavaScript rendering или други инфраструктурни ограничения.

Трябва ли ми llms.txt, за да се появявам в ChatGPT?

Не. llms.txt е допълнителен AI-oriented слой, а не задължително условие за появяване в ChatGPT. По-важната основа остава достъпният HTML, ясното съдържание, нормалната crawl политика и добрата структура на сайта.

Помага ли Markdown версията на страницата за AI visibility?

Markdown representation може да предостави основното съдържание в по-чист текстов формат и да намали техническия шум около него. Това обаче не означава, че AI системите универсално предпочитат Markdown или че .md версията сама по себе си ще доведе до по-добра видимост или цитиране.

Ако robots.txt разрешава AI crawler-и, това гарантира ли цитиране?

Не. robots.txt може да разреши обхождането, но не определя дали страницата ще бъде избрана като източник. Релевантността на съдържанието, конкретната заявка и останалите налични източници също имат значение.

Как да проверя дали AI crawler действително е посещавал сайта ми?

Най-полезният източник са server, CDN или WAF logs. Там можеш да потърсиш заявки от user agents като OAI-SearchBot или PerplexityBot, а когато доставчикът предоставя официален verification механизъм, да провериш и произхода на заявката. Самото име в User-Agent header не е абсолютно доказателство, защото може да бъде подправено.

Автор: Борислав Димитров
Full Stack Developer
Next.js • SEO • AI Visibility