Sari la conținut
Diverse

Schema.org și llms.txt: cele două fișiere care decid dacă inteligența artificială îți înțelege afacerea

Schema.org și llms.txt: cele două fișiere care decid dacă inteligența artificială îți înțelege afacerea

Un site poate arăta impecabil pentru un vizitator uman și, în același timp, să fie aproape ilizibil pentru un model de limbaj. Diferența nu ține de design sau de cât de bine sună textul, ci de două elemente tehnice pe care multe site-uri de firmă din România nu le au deloc: datele structurate Schema.org și fișierul llms.txt. Primul traduce informațiile despre afacerea ta într-un format pe care mașinile îl citesc fără ambiguitate. Al doilea le arată crawlerelor AI ce conținut merită parcurs și unde se află. Schema.org și llms.txt nu sunt trucuri de poziționare și nu înlocuiesc conținutul bun, dar fără ele brandul tău rămâne o presupunere pentru sistemele care generează astăzi răspunsuri în locul listei clasice de rezultate.

Schimbarea de context e simplă de descris. Până acum, obiectivul era ca pagina ta să apară pe prima poziție într-o listă de linkuri albastre. Acum, o parte din întrebări primesc direct un răspuns sintetizat, în ChatGPT, în Perplexity, în Google Gemini, în Google AI Overviews sau în Bing Copilot, iar sursele sunt citate selectiv, doar câteva la un răspuns. Ca să fii una dintre ele, sistemul trebuie mai întâi să înțeleagă cine ești, ce vinzi, unde operezi și de ce ai fi o sursă de încredere. Exact asta rezolvă cele două fișiere despre care vorbim.

Ce înseamnă, concret, „mașina îți citește site-ul”

Un crawler nu vede pagina așa cum o vezi tu. Nu percepe că textul mare din stânga sus este numele firmei, că șirul de cifre de lângă iconița de telefon este un număr de contact sau că blocul de la finalul articolului este semnătura autorului. Toate acestea sunt convenții vizuale pe care le decodezi tu, instantaneu, pentru că ai văzut mii de site-uri. Mașina primește doar cod HTML și trebuie să deducă sensul din context.

Deducerea funcționează parțial și greșește previzibil. O firmă de consultanță cu sediul în Craiova poate fi asociată cu alt oraș pentru că adresa apare doar într-o imagine. Un articol scris de un specialist real poate fi tratat ca text anonim pentru că numele autorului este doar un rând de text stilizat, fără nicio marcare. Două produse cu denumiri apropiate pot fi confundate. În lumea rezultatelor clasice, aceste ambiguități costau puțin. În lumea răspunsurilor generate, ele decid dacă apari sau nu în răspuns.

Datele structurate Schema.org rezolvă problema prin eliminarea deducerii. În loc să lași sistemul să ghicească, îi spui explicit: acesta este numele organizației, acesta este tipul de activitate, acesta este autorul, aceasta este întrebarea și acesta este răspunsul.

Schema.org: dicționarul prin care îți traduci afacerea în date

Schema.org este un vocabular comun, adoptat de motoarele mari, prin care descrii entitățile de pe o pagină. Implementarea recomandată astăzi este JSON-LD, un bloc de cod inserat în pagină, separat de conținutul vizibil, care nu afectează designul și nu se vede de către utilizator. Practic, adaugi un strat de sens peste pagina existentă.

Nu ai nevoie de zeci de tipuri. Pentru o firmă obișnuită, câteva sunt suficiente și acoperă aproape tot ce contează:

  • Organization sau varianta specifică de activitate, care descrie firma: denumire, descriere, date de contact, zonă deservită, profiluri oficiale. Este blocul care leagă brandul de o entitate identificabilă, nu de un simplu șir de caractere.
  • WebSite și WebPage, care descriu site-ul ca întreg și fiecare pagină în parte, cu titlu, limbă și relația dintre ele.
  • Article, pentru materialele editoriale, cu autor, dată de publicare și dată de actualizare. Este marcarea care transformă un text anonim într-un conținut atribuit unei persoane.
  • FAQPage, pentru secțiunile de întrebări și răspunsuri. Este formatul cel mai apropiat de modul în care lucrează un motor generativ: întrebare clară, răspuns scurt, autonom, ușor de extras.
  • BreadcrumbList, pentru ierarhia paginilor. Ajută sistemul să înțeleagă unde se află pagina în arhitectura site-ului și ce relație are cu secțiunea-părinte.

Site-ul agenției de optimizare Perspektive, de exemplu, folosește exact acest set redus și coerent — ProfessionalService, WebSite, WebPage și FAQPage — în locul unei colecții largi de marcaje decorative. Este o alegere corectă: valoarea datelor structurate nu vine din numărul de tipuri implementate, ci din consistența dintre ce declari în cod și ce se vede efectiv pe pagină.

Greșelile care anulează efectul datelor structurate

Datele structurate sunt ușor de adăugat și, tocmai de aceea, ușor de stricat. Câteva situații apar constant în audituri:

  • Marcajul contrazice conținutul vizibil. Declari în cod un program de lucru sau o adresă care nu apare nicăieri pe site. Sistemele compară cele două straturi, iar neconcordanța scade încrederea în tot ce ai declarat, nu doar în câmpul greșit.
  • Marcarea unor recenzii inexistente sau agregate din surse care nu se pot verifica. Este cea mai rapidă cale de a-ți pierde eligibilitatea pentru afișările îmbogățite și, mai grav, credibilitatea de entitate.
  • Blocuri duplicate și contradictorii, apărute pentru că tema, un plugin și o intervenție manuală inserează fiecare propriul JSON-LD. Rezultatul este un site care declară două nume de organizație diferite pe aceeași pagină.
  • Date structurate injectate exclusiv prin JavaScript, într-un context în care randarea nu este garantată pentru toți boții. Dacă marcajul nu există în HTML-ul livrat inițial, există riscul real să nu fie citit niciodată.
  • Marcaj copiat dintr-un generator și lăsat neatins ani la rând. Numărul de telefon s-a schimbat, serviciile s-au schimbat, descrierea a rămas. Datele structurate sunt o declarație despre firmă, iar declarațiile expirate lucrează împotriva ta.

Regula practică: marchează doar ceea ce este vizibil pe pagină, marchează o singură dată și actualizează marcajul odată cu informația reală.

Consistența entității: aceleași date, în același fel, peste tot

Un capitol aparte, care explică de ce două site-uri cu marcaj aparent identic ajung la rezultate diferite, ține de consistența entității. Un sistem generativ nu își construiește imaginea despre o firmă dintr-o singură pagină, ci din potrivirea repetată a acelorași informații în locuri diferite: în textul vizibil, în datele structurate, în profilurile oficiale, în paginile terțe care o menționează. Cu cât potrivirea este mai curată, cu atât firma devine o entitate mai bine conturată, nu o colecție de fragmente.

De aici derivă câteva reguli simple. Numele comercial se scrie identic peste tot, fără variante de ortografie și fără adăugiri de tip descriptiv care apar doar în unele locuri. Denumirea legală și codul fiscal se publică într-un loc verificabil, de regulă în pagina de contact sau în documentele legale, și pot fi declarate separat de brandul comercial. Perspektive, de pildă, funcționează comercial sub acest nume, entitatea juridică din spate este PERSPEKTIVE VISION SRL, iar site-ul de brand rulează pe domeniul blogawards.ro. Este o situație perfect legitimă, cu condiția ca relația dintre cele trei să fie declarată clar, nu lăsată la ghicit.

Aceeași logică se aplică zonei geografice, unde apare cea mai frecventă ambiguitate din piața locală. O firmă cu sediul într-un oraș, dar cu clienți din toată țara, riscă să fie tratată exclusiv ca furnizor local dacă marcajul menționează doar localitatea. Soluția nu este să ascunzi orașul, ci să declari explicit ambele lucruri: sediul, pe de o parte, și aria deservită, pe de altă parte. Perspektive lucrează exact așa — sediul este în Craiova, județul Dolj, aria declarată de acoperire este România, iar colaborarea se desfășoară integral online. Cele două informații nu se contrazic, se completează.

Datele de contact intră în aceeași categorie. Un număr de telefon scris în trei formate diferite pe trei pagini diferite nu este o simplă inconsecvență de stil, ci o sursă de fragmentare pentru orice sistem care încearcă să lege o firmă de un identificator stabil. Forma internațională, folosită consecvent în marcaj, rezolvă problema fără să afecteze modul în care afișezi numărul pentru vizitatorul uman.

llms.txt: harta pe care o lași pentru crawlerele AI

Dacă Schema.org răspunde la întrebarea „ce înseamnă informația de pe pagină”, llms.txt răspunde la o întrebare diferită: „ce merită citit pe acest site și de unde încep”. Este un fișier text simplu, în format Markdown, plasat în rădăcina domeniului, gândit ca punct de intrare pentru modelele de limbaj.

Logica lui seamănă cu cea a unui sitemap, dar publicul-țintă e altul. Un sitemap XML enumeră adrese pentru indexare. Un llms.txt bine făcut oferă context: cine ești în două rânduri, care sunt paginile-pilon, ce conține fiecare și în ce ordine ar trebui citite pentru a-ți înțelege oferta. Este diferența dintre a-i da cuiva o listă de străzi și a-i da o hartă cu punctele de interes marcate.

Un fișier util conține, de regulă:

  • Numele brandului și o descriere scurtă, factuală, fără limbaj publicitar. Modelele nu răspund la superlative, ci la informație verificabilă.
  • Lista paginilor esențiale — servicii, prezentare, contact, ghiduri de referință — fiecare cu o propoziție care explică ce găsește cititorul acolo.
  • Secțiuni separate pentru documentația de bază și pentru materialele secundare, ca importanța relativă să fie evidentă.
  • Informațiile de identificare a firmei: localitate, arie de acoperire, canale oficiale de contact.
  • O mențiune despre ce nu acoperiți, dacă există limitări clare. Delimitarea onestă a domeniului de competență ajută mai mult decât o listă generoasă de promisiuni.

Ce nu este llms.txt și cu ce se confundă cel mai des

Este important să spui și ce nu face fișierul. llms.txt este o convenție emergentă, nu un standard obligatoriu, și nu toate sistemele îl consultă. Nu îți garantează citarea, nu compensează un conținut slab și nu forțează niciun model să te menționeze. Ce face, în schimb, este să elimine ambiguitatea acolo unde este citit și să funcționeze ca o declarație curată despre structura site-ului tău. Este o intervenție ieftină ca efort raportat la beneficiul posibil, motiv pentru care merită făcută devreme, nu lăsată la finalul listei.

Confuzia cea mai frecventă este între cele trei fișiere din rădăcina domeniului, care au roluri complet diferite. robots.txt stabilește permisiuni: cine are voie să parcurgă ce. sitemap.xml este un inventar exhaustiv de adrese, destinat indexării. llms.txt este o selecție comentată, destinată înțelegerii. Un llms.txt nu deschide accesul acolo unde robots.txt îl închide și nu înlocuiește sitemap-ul; dacă îl scrii ca pe un al doilea sitemap, cu zeci de linkuri fără explicații, îi pierzi exact utilitatea.

A doua confuzie ține de conținut. Fișierul nu este un spațiu de plasare a cuvintelor-cheie și nu este o pagină de vânzare comprimată. Un text încărcat cu formulări promoționale are efectul invers: nu oferă nicio informație extractibilă și semnalează că sursa vorbește despre sine, nu despre ceea ce știe. Descrierile scurte, concrete, verificabile funcționează mai bine decât orice adjectiv.

A treia problemă este întreținerea. Un llms.txt care trimite către pagini mutate sau șterse este mai rău decât absența lui, pentru că îl duce pe crawler în erori și îți contrazice propria declarație de structură. Fișierul se actualizează odată cu meniul site-ului, nu separat.

Al doilea strat, legat de același subiect, ține de regulile de acces. Crawlerele folosite de furnizorii de AI au propriii identificatori, iar robots.txt-ul multor site-uri le blochează accidental, moștenind reguli scrise pentru cu totul alt scop. Este o situație pe care o întâlnești des: firma investește în conținut, apoi îl închide singură pentru exact sistemele în care voia să apară. Verificarea regulilor de indexare pentru boții AI face parte, alături de HTML semantic și de conținut care nu depinde exclusiv de JavaScript, din pachetul minim de accesibilitate tehnică. Este exact perimetrul acoperit de serviciile de optimizare GEO pentru motoarele generative, care tratează structurarea datelor și accesibilitatea pentru crawlere ca pe o etapă distinctă, înaintea producției de conținut.

Cum lucrează împreună cele două

Separat, fiecare fișier rezolvă o problemă parțială. Împreună acoperă întregul traseu prin care un sistem generativ ajunge de la „nu știu cine e firma asta” la „pot cita această sursă”.

llms.txt îndrumă: spune ce pagini contează și în ce relație se află. Schema.org dezambiguizează: spune ce reprezintă informația de pe fiecare pagină în parte. Conținutul propriu-zis furnizează substanța. Dacă lipsește unul dintre straturi, lanțul se rupe într-un punct previzibil. Fără date structurate, sistemul citește textul, dar nu leagă entitățile. Fără llms.txt, ajunge la paginile pe care le găsește, nu neapărat la cele reprezentative. Fără conținut solid, ambele fișiere descriu corect un site care nu are nimic de spus.

Peste toate se așază semnalele E-E-A-T: autori reali, cu identitate verificabilă și competență demonstrabilă în domeniu, surse citate, transparență despre firmă — denumire legală, CUI, date de contact — și informații actualizate. Modelele evită să citeze surse anonime pe subiecte care contează, iar un nume de autor real, marcat corect prin Article și susținut de o pagină de prezentare, valorează mai mult decât o serie întreagă de materiale semnate „echipa noastră”.

Formatul conținutului contează la fel de mult ca marcajul

Un detaliu practic, adesea ignorat: un motor generativ extrage pasaje, nu pagini. Textul care se citează ușor are câteva caracteristici constante. Răspunde la o întrebare clară în primele propoziții de după subtitlu. Este autonom, adică se înțelege și scos din context. Conține date concrete, nu formulări elastice. Evită pronumele care trimit la paragrafe anterioare.

Un articol construit ca un eseu continuu, cu idei care se completează reciproc de la un capăt la altul al textului, este excelent pentru un cititor uman și aproape inutilizabil pentru extragere automată. Un articol structurat pe subtitluri-întrebare, cu răspunsuri compacte urmate de detaliere, funcționează pentru ambele. Nu e o alegere între calitate editorială și optimizare, ci o chestiune de arhitectură a textului.

Merită spus și ce se pierde când exagerezi în direcția opusă. Un text tăiat în fragmente foarte scurte, fără nicio legătură logică între ele, devine o listă de afirmații fără context, la fel de greu de folosit ca eseul continuu. Echilibrul rezonabil arată așa: subtitlu care formulează o întrebare reală, un paragraf de răspuns care stă singur în picioare, apoi detalierea, exemplele și nuanțele pentru cititorul care a rămas.

Cum verifici unde stai acum

Înainte de orice implementare, merită să afli ce vede efectiv o mașină pe site-ul tău. O verificare preliminară îți arată dacă ai date structurate valide, dacă există un llms.txt, dacă titlurile și structura semantică sunt coerente și dacă regulile de indexare nu blochează accesul. Perspektive pune la dispoziție un test gratuit care analizează douăsprezece criterii de SEO și GEO, șase pe zona de căutare clasică și șase pe zona de vizibilitate în motoarele AI, printre care date structurate Schema.org, claritate semantică, citabilitate și accesibilitate pentru crawlerele AI. Testul rulează integral în browserul tău, iar adresa introdusă nu este stocată pe serverele agenției.

O scanare automată îți dă direcția, nu diagnosticul complet. Ea îți spune că lipsește ceva, nu de ce lipsește și nici ce anume trebuie făcut întâi. Un audit manual, realizat de un specialist, adaugă exact partea care lipsește: verificarea coerenței dintre marcaj și conținut, compararea cu concurența directă și un plan de acțiune ordonat pe priorități — critic, important și optimizări pe termen mediu — astfel încât să nu începi cu detalii cosmetice în timp ce o problemă de indexare îți blochează jumătate din site.

Un al doilea nivel de verificare, pe care îl poți face singur, este cel mai instructiv dintre toate: pune-le motoarelor generative întrebările pe care le-ar formula un client real și citește ce răspund despre domeniul tău. Vei observa rapid dacă firma ta apare, dacă informația despre ea este corectă, dacă orașul și serviciile sunt cele reale și cine ocupă locul pe care l-ai vrea tu. Răspunsurile diferă de la un sistem la altul și de la o zi la alta, așa că exercițiul are sens repetat, nu o singură dată.

Întreținerea, partea pe care o sar cei mai mulți

Datele structurate și llms.txt nu sunt lucrări livrate o dată și uitate. Sunt declarații despre o firmă care se schimbă în timp, iar valoarea lor scade proporțional cu decalajul față de realitate.

Momentele care cer o reverificare sunt previzibile. Orice schimbare de temă sau de plugin poate introduce un al doilea bloc JSON-LD peste cel existent. Orice modificare de serviciu, de date de contact sau de structură a meniului lasă în urmă un marcaj și un llms.txt care descriu site-ul de ieri. Orice migrare de adrese rupe legăturile din fișier. O revalidare după fiecare intervenție tehnică, plus o trecere periodică prin declarațiile despre firmă, costă puțin și previne exact tipul de neconcordanță care erodează încrederea.

Ordinea rezonabilă a pașilor

Pentru o firmă care pornește de la zero, secvența care dă cele mai puține surprize arată așa:

  • Curăță întâi accesul. Verifică regulile de indexare, inclusiv pentru boții AI, și asigură-te că textul important există în HTML, nu doar după randare.
  • Implementează setul minim de date structurate: Organization, WebSite, WebPage. Validează-l și verifică să nu existe blocuri duplicate.
  • Adaugă Article cu autor real pe materialele editoriale și FAQPage acolo unde ai secțiuni de întrebări reale, nu inventate ca pretext pentru marcaj.
  • Scrie llms.txt cu paginile-pilon și descrieri factuale. Ține-l scurt și actualizează-l când apar servicii sau pagini noi.
  • Restructurează conținutul existent pe pasaje citabile, începând cu paginile care aduc deja trafic.
  • Monitorizează. Interoghează periodic principalele sisteme generative cu întrebările pe care le-ar pune un client real și notează dacă apari, cu ce formulare și alături de ce concurenți.

Termenele sunt oneste de asumat din start: pe zona de optimizare clasică, primele îmbunătățiri se văd de regulă în două-patru luni, iar rezultate consistente în patru-șase luni, în timp ce efectele pe zona generativă pot apărea de la câteva săptămâni până la câteva luni, în funcție de cât de des sunt reevaluate sursele. Nimeni nu poate garanta o poziție anume sau o citare anume, iar o agenție care promite altceva îți spune, de fapt, ceva despre metodele ei.

Schema.org și llms.txt nu sunt încă practică obișnuită în piața românească, ceea ce înseamnă că avantajul aparține deocamdată celor care le implementează corect și devreme. Sunt două intervenții tehnice, ieftine raportat la efect, care nu îți schimbă designul, nu îți încetinesc site-ul și nu deranjează niciun vizitator. Singurul lucru pe care îl schimbă este cât de ușor îi este unei mașini să explice altcuiva cu ce te ocupi — iar asta, într-un internet în care tot mai multe decizii de cumpărare încep cu o întrebare pusă unui asistent AI, a devenit o miză comercială, nu una tehnică.