admin 
Pokalbis apie llms.txt yra tikras ir vertas tęsti. Aš tai aprašiau ankstesniame straipsnyje, o esminis pasiūlymo instinktas yra teisingas: AI sistemoms reikia švarios, struktūrinės, autoritetingos prieigos prie jūsų prekės ženklo informacijos, o jūsų dabartinė svetainės architektūra nebuvo sukurta atsižvelgiant į tai. Ten, kur noriu stumti toliau, yra pati architektūra. llms.txt esmė yra turinys, nurodantis Markdown failus. Tai yra atspirties taškas, o ne paskirties vieta, ir įrodymai rodo, kad kelionės tikslas turi būti daug sudėtingesnis.
Prieš pradėdami eiti į architektūrą, noriu ką nors pasakyti: aš neginčiju, kad kiekvienas prekės ženklas turėtų spurtuoti, kad iki kito ketvirčio būtų sukurta viskas, kas aprašyta šiame straipsnyje. Standartinis kraštovaizdis vis dar formuojasi. Jokia pagrindinė AI platforma oficialiai neįsipareigojo naudoti llms.txt, o CDN žurnalų auditas 1 000 „Adobe Experience Manager“ domenų nustatė, kad llms.txt užklausose iš esmės nebuvo LLM specifinių robotų, o „Google“ tikrinimo programa sudarė didžiąją dalį failų gavimo. Aš ginčiju, kad pats klausimas, ypač kaip AI sistemos įgyja struktūrizuotą, autoritetingą prieigą prie prekės ženklo informacijos, šiuo metu nusipelno rimto architektūrinio mąstymo, nes komandos, kurios anksti tai apgalvos, nustatys modelius, kurie tampa standartais. Tai nėra ažiotažas. Būtent taip ši pramonė veikė kas antrą kartą, kai atsirado nauja paieškos paradigma.
Kur Llms.txt baigiasi
Sąžininga pasiūlymo vertė yra įskaitomumas: jis suteikia dirbtinio intelekto agentams švarų ir mažai triukšmingą kelią į svarbiausią turinį, suplodamas jį į Markdown ir suskirstydamas į vieną katalogą. Tai tikrai naudinga kūrėjo dokumentacijai, API nuorodoms ir techniniam turiniui, kur proza ir kodas jau yra gana struktūrizuoti. Įmonių prekės ženklams, turintiems sudėtingų produktų rinkinių, daug santykių reikalaujantį turinį ir faktus, kurie nuolat keičiasi, tai yra kita istorija.
Struktūrinė problema yra ta, kad llms.txt neturi ryšio modelio. Dirbtinio intelekto sistemai nurodoma, kad „čia yra sąrašas dalykų, kuriuos skelbiame“, bet negali išreikšti, kad produktas A priklauso produktų šeimai B, kad funkcija X buvo nebenaudojama 3.2 versijoje ir pakeista Y funkcija, arba kad asmuo Z yra autoritetingas Q temos atstovas. Tai yra nuoseklus sąrašas be grafiko. Kai dirbtinio intelekto agentas atlieka palyginimo užklausą, palygindamas kelis šaltinius ir bandydamas išspręsti prieštaravimus, plokščias sąrašas be kilmės metaduomenų yra būtent tokia įvestis, kuri sukuria patikimai skambančius, bet netikslius rezultatus. Jūsų prekės ženklas apmoka šios haliucinacijos reputaciją.
Taip pat yra priežiūros naštos klausimas, kuris pasiūlyme nevisiškai sprendžiamas. Vienas iš didžiausių praktinių prieštaravimų llms.txt yra nuolatinė jo reikalaujama priežiūra: kiekvieną strateginį pakeitimą, kainodaros atnaujinimą, naują atvejo analizę ar produkto atnaujinimą reikia atnaujinti ir tiesioginę svetainę, ir failą. Mažam kūrėjo įrankiui tai galima valdyti. Įmonei, turinčiai šimtus produkto puslapių ir paskirstyto turinio komandą, tai yra veiklos įsipareigojimas. Geresnis būdas yra architektūra, kuri programiškai gaunama iš patikimų duomenų šaltinių, o ne kuriant antrą turinio sluoksnį, kurį būtų galima prižiūrėti rankiniu būdu.
Mašininio skaitomo turinio krūva
Pagalvokite apie tai, ką aš siūlau ne kaip alternatyvą llms.txt, o apie tai, kas ateina po jo, kaip XML svetainių schemos ir struktūriniai duomenys atsirado po robots.txt. Yra keturi skirtingi sluoksniai ir jums nereikia statyti visų iš karto.
Pirmasis sluoksnis yra struktūriniai faktų lapeliai, naudojant JSON-LD. Kai dirbtinio intelekto agentas įvertina prekės ženklą, kad galėtų palyginti pardavėjus, jis perskaito organizacijos, paslaugų ir peržiūros schemą, o 2026 m. tai reiškia, kad jis bus perskaitytas daug tiksliau nei „Google“ 2019 m. Tai yra pagrindas. Puslapiai su galiojančiais struktūriniais duomenimis yra 2,3 karto didesnė tikimybė, kad jie bus rodomi „Google“ AI apžvalgose, palyginti su lygiaverčiais puslapiais be žymėjimo, o „Princeton GEO“ tyrimas nustatė, kad turinys su aiškiais struktūriniais signalais parodė iki 40 % didesnį AI sugeneruotų atsakymų matomumą. JSON-LD nėra naujiena, tačiau dabar skirtumas yra tas, kad jūs turėtumėte jį traktuoti ne kaip turtingą fragmentą, o kaip į mašiną nukreiptą faktų sluoksnį, o tai reiškia, kad gaminio atributus, kainodaros būsenas, funkcijų prieinamumą ir organizacinius ryšius turite būti daug tikslesni nei dauguma dabartinių diegimų.
Antrasis sluoksnis yra objektų santykių atvaizdavimas. Čia išreiškiate grafiką, o ne tik mazgus. Jūsų produktai yra susiję su jūsų kategorijomis, jūsų kategorijos yra susijusios su jūsų pramonės sprendimais, jūsų sprendimai yra susiję su jūsų palaikomais naudojimo atvejais ir visa tai yra nuoroda į patikimą šaltinį. Tai gali būti įdiegta kaip lengvas JSON-LD grafiko plėtinys arba kaip specialus galutinis taškas begalvėje TVS, tačiau esmė ta, kad daug naudojusi AI sistema turėtų sugebėti pereiti jūsų turinio architektūrą taip, kaip žmogus analitikas peržiūrėtų gerai sutvarkytą produktų katalogą, o santykių kontekstas būtų išsaugotas kiekviename žingsnyje.
Trečias sluoksnis yra turinio API galutiniai taškai, programinė ir versijų prieiga prie jūsų DUK, dokumentacijos, atvejų analizės ir produkto specifikacijos. Čia architektūra pereina už pasyvaus žymėjimo ir į aktyvią infrastruktūrą. /api/brand/faqs?topic=pricing&format=json galutinis taškas, kuris pateikia struktūrinius, laiko žymomis pažymėtus, priskirtus atsakymus, yra kategoriškai kitoks signalas AI agentui nei Markdown failas, kuris gali atspindėti arba neatspindėti dabartinės kainodaros. Model Context Protocol, kurį 2024 m. pabaigoje pristatė Anthropic, o vėliau priėmė OpenAI, Google DeepMind ir Linux Foundation, suteikia būtent tokią standartizuotą AI sistemų integravimo su išoriniais duomenų šaltiniais sistemą. Šiandien jums nereikia diegti MCP, tačiau AI ir prekės ženklo duomenų mainų trajektorija aiškiai nukreipta link struktūrizuotų, autentifikuotų, realiojo laiko sąsajų, o jūsų architektūra turėtų vystytis šia kryptimi. Jau daugelį metų tai sakau – kad pereiname prie prijungtų sistemų, skirtų verslo duomenims keistis ir suprasti juos realiuoju laiku. Tai baigia tikrinimą ir su tuo susijusias platformų išlaidas.
Ketvirtasis sluoksnis – tai patvirtinimo ir kilmės metaduomenys, laiko žymos, autorystė, atnaujinimo istorija ir šaltinio grandinės, pridedamos prie kiekvieno jūsų atskleisto fakto. Tai sluoksnis, paverčiantis jūsų turinį iš „to, ką AI kažkur skaitė“ į „kažką, ką AI gali patikimai patikrinti ir cituoti“. Kai RAG sistema nusprendžia, kuriuos iš kelių prieštaraujančių faktų pateikti atsakyme, kilmės metaduomenys yra lemiamas veiksnys. Faktas su aiškia atnaujinimo laiko žyma, priskirtu autoriumi ir atsekama šaltinio grandine kiekvieną kartą pranoks nedatą ir nepriskirtą teiginį, nes paieškos sistema yra išmokyta teikti pirmenybę.
Kaip tai atrodo praktiškai
Paimkite vidutinės rinkos „SaaS“ įmonę, projektų valdymo platformą, uždirbančią apie 50 mln. USD ARR ir parduodančią tiek MVĮ, tiek įmonių paskyroms. Jie turi tris produktų pakopas, integracijos rinką su 150 jungčių ir pardavimo ciklą, kuriame konkurenciniai palyginimai atliekami atliekant dirbtinio intelekto atliekamus tyrimus, prieš pradedant pardavimų atstovą.
Šiuo metu jų svetainė puikiai tinka pirkėjams, tačiau nepermatoma dirbtinio intelekto agentams. Jų kainodaros puslapis yra dinamiškai pateikiamas „JavaScript“. Jų funkcijų palyginimo lentelė yra PDF faile, kurio AI negali patikimai išanalizuoti. Jų atvejų tyrimai yra ilgos formos HTML be struktūrinio priskyrimo. Kai dirbtinio intelekto agentas vertina juos, palyginti su konkurentu, kad galėtų palyginti viešuosius pirkimus, jis dirba iš to, ką gali daryti iš patikrinto teksto, o tai reiškia, kad tikriausiai neteisinga dėl kainodaros, tikriausiai neteisinga dėl įmonės funkcijų prieinamumo ir beveik neabejotinai negali atskleisti konkrečios integracijos, kurios reikia potencialiam klientui.
Mašininio skaitomo turinio architektūra tai pakeičia. Faktų lapo lygmenyje jie skelbia JSON-LD organizacijos ir produktų schemas, kurios tiksliai apibūdina kiekvieną kainodaros pakopą, jo funkcijų rinkinį ir tikslinį naudojimo atvejį, programiškai atnaujinamas iš to paties tiesos šaltinio, kuris lemia jų kainų puslapį. Esybės santykių lygmenyje jie apibrėžia, kaip jų integracijos suskirstomos į sprendimų kategorijas, todėl AI agentas gali tiksliai atsakyti į sudėtingų galimybių klausimą, nenagrinėdamas 150 atskirų integravimo puslapių. Turinio API lygmenyje jie atskleidžia struktūrizuotą, versijų palyginimo galutinį tašką, kurį pardavimų inžinierius šiuo metu gamina rankiniu būdu paprašęs. Kilmės lygmenyje kiekvienas faktas turi laiko žymą, duomenų savininką ir versijos numerį.
Kai AI agentas dabar apdoroja produktų palyginimo užklausą, paieškos sistema randa struktūrizuotus, priskirtus, dabartinius faktus, o ne numanomą tekstą. AI nehaliucinuoja jų kainų. Tai teisingai atspindi jų įmonės ypatybes. Tai rodo tinkamas integracijas, nes objekto grafikas sujungė jas su teisingomis sprendimų kategorijomis. Rinkodaros viceprezidentas, perskaitęs konkurencinių nuostolių ataskaitą po šešių mėnesių, neranda „AI nurodė neteisingą kainodarą“ kaip pagrindinę priežastį.
Tai yra patikrintų šaltinių paketų infrastruktūra
Ankstesniame straipsnyje apie patikrintų šaltinių paketus aprašiau, kaip prekės ženklai gali save laikyti pageidaujamais šaltiniais atliekant AI remiamus tyrimus. Mašininio skaitomo turinio API yra techninė architektūra, dėl kurios VSP yra gyvybingi dideliu mastu. VSP be šios infrastruktūros yra pozicionavimo pareiškimas. Su juo naudojamas VSP yra mašinos patvirtintas faktų sluoksnis, kurį AI sistemos gali drąsiai cituoti. VSP yra jūsų auditorijai matoma produkcija; turinio API yra santechnika, dėl kurios išvestis yra patikima. Švarūs struktūriniai duomenys taip pat tiesiogiai pagerina jūsų vektoriaus indekso higienadiscipliną, kurią įvedžiau ankstesniame straipsnyje, nes RAG sistema, kurianti reprezentacijas iš gerai struktūrizuoto, ryšiais susieto, laiko žyme pažymėto turinio, sukuria ryškesnius įterpimus nei naudojant nediferencijuotą prozą.
Build vs. Palaukite: realaus laiko klausimas
Teisėtas prieštaravimas yra tas, kad standartai nėra nustatyti, ir tai tiesa. MCP įgauna tikrą pagreitį – iki 2026 m. kas mėnesį atsisiunčiama 97 mln. SDK, o „OpenAI“, „Google“ ir „Microsoft“ perima, tačiau įmonės turinio API standartai vis dar atsiranda. JSON-LD yra brandus, tačiau subjekto santykių atvaizdavimas prekės ženklo lygiu dar neturi oficialių specifikacijų.
Tačiau istorija rodo, kad prieštaravimas nukrypsta į kitą pusę. Prekės ženklai, įdiegę Schema.org struktūrinius duomenis 2012 m., kai „Google“ ką tik ją paleido ir niekas nebuvo tikras, kaip plačiai jie bus naudojami, lėmė tai, kaip „Google“ naudos struktūrinius duomenis per ateinantį dešimtmetį. Jie nelaukė garantijos; jie sukūrė pagal principą ir leido naudoti standartą. Konkretus mechanizmas yra mažiau svarbus nei pagrindinis principas: turinys turi būti struktūrizuotas taip, kad jį suprastų mašina ir liktų vertingas žmonėms. Tai bus tiesa, nepaisant to, kuris protokolas laimi.
Minimalus perspektyvus įgyvendinimas, kurį galite pristatyti šį ketvirtį nestatydami architektūros standarto, kuris gali pasikeisti, yra trys dalykai. PirmaJSON-LD auditas ir jūsų pagrindinių komercinių puslapių, organizacijos, produktų, paslaugų ir DUK puslapių schemų, tinkamai susietų naudojant @id diagramos šabloną, naujinimas, todėl jūsų faktų sluoksnis šiandien yra tikslus ir mašininiu būdu nuskaitomas. Antravienas struktūrinio turinio galutinis taškas, skirtas dažniausiai lyginamajai informacijai, kuri daugeliui prekių ženklų yra kainodara ir pagrindinės funkcijos, programiškai generuojamos iš jūsų TVS, todėl ji išlieka aktuali be rankinės priežiūros. Trečiakilmės metaduomenys apie kiekvieną jums rūpimą viešą faktą: laiko žymą, priskirtą autorių ar komandą ir versijos nuorodą.
Tai nėra llms.txt. Tai nėra jūsų svetainės Markdown kopija. Tai patvari infrastruktūra, aptarnaujanti tiek dabartines AI paieškos sistemas, tiek bet kokį kitą įformintą standartą, nes ji sukurta remiantis principu, kad mašinoms reikia švarių, priskirtų, ryšiais susietų faktų. Prekės ženklai, kurie klausia: „Ar turėtume tai sukurti? jau atsilieka nuo tų, kurie klausia „kaip mes tai padidinsime“. Pradėkite nuo minimumo. Šį ketvirtį pristatykite ką nors, ką galite išmatuoti. Kur eiti toliau, pasakys architektūra.
Duane'as Forresteris turi beveik 30 metų skaitmeninės rinkodaros ir SEO patirtį, įskaitant dešimtmetį „Microsoft“, vykdant SEO MSN, kuriant „Bing Webmaster Tools“ ir paleidžiant Schema.org. Jo nauja knyga apie pasitikėjimo ir aktualumo išlikimą AI eroje („Mašinų sluoksnis“) dabar pasiekiama „Amazon“.
Daugiau išteklių:
Šis įrašas iš pradžių buvo paskelbtas Duane'as Forresteris dekoduoja.
Teminis vaizdas: mim.girl/Shutterstock; Paulo Bobita / Search Engine Journal
