Как да подготвим сайт за AI системи
Проверка на HTML съдържанието
...
```
Човек може да получи почти същата визуална страница чрез 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 сайтът се чупи при промени? Проблемът е в архитектурата](https://evtinwebsite.com/blog/zasho-vsyaka-nova-ai-promyana-zapochva-da-chupi-saita-ti)
А когато контекстът вече е за реално довършване или refactoring на такъв проект, логичното продължение е service page:
[Преработка на AI сайт](https://evtinwebsite.com/prerabotka-na-ai-sait)
Подобна връзка не е полезна само защото създава още един internal link.
Тя описва отношение:
```text
информационен проблем
↓
по-задълбочено техническо обяснение
↓
услуга, която решава този тип проблем
```
При друга тема връзката може да е различна. Статия за `llms.txt` например може естествено да насочи към по-подробния материал за [Agentic Browsing и llms.txt](https://evtinwebsite.com/blog/agentic-browsing-lighthouse-veche-proveryava-i-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