AI Visibility Lab · Articole

Cum verific tehnic un site pentru AI Visibility? Protocolul minim folosit în AI Visibility Lab

Ce verifică protocolul tehnic AVL-203 înainte de orice măsurare a vizibilității în AI, de ce dovada se separă de interpretare, cum devin observațiile diagnostic după grila AVL-204 și ce primește clientul. Cu exemple reale din prima rulare T0 pe delamatescu.ro: 6 pagini, 56 de cereri, 12 crawlere, 109 constatări.

Alex Matescu · Fondator și coordonator AI Visibility Lab

Publicat: 28 octombrie 2026 · Ultima verificare factuală: 28 octombrie 2026

Un site nu poate fi evaluat corect pentru vizibilitate în motoare de căutare și sisteme AI doar verificând dacă apare în ChatGPT, Claude, Perplexity, Google sau Bing. Înainte de citare, menționare sau recomandare există un strat tehnic care trebuie măsurat separat: dacă site-ul poate fi accesat, ce livrează serverul, ce reguli impune crawlerelor, cum își declară URL-urile și dacă diferite sisteme primesc același conținut.

În AI Visibility Lab folosesc un protocol tehnic minim și repetabil pentru a documenta această stare înainte de interpretarea rezultatelor: AVL-203.¹ Observațiile lui devin diagnostic după o grilă publică separată, AVL-204.² Amândouă sunt la început: drafturi 0.x, construite din primele rulări pe propriul site și revizuite pe măsură ce apar situații pe care nu le-au prevăzut (secțiunea „În ce stadiu de maturitate este protocolul?”).

Protocolul nu este un audit SEO complet și nici nu pretinde că poate prezice dacă un sistem AI va cita sau recomanda o sursă.

Rolul lui este mai precis: să creeze o evidență tehnică reproductibilă asupra condițiilor în care un site poate fi descoperit, accesat și procesat de sisteme automate.

Exemplele din acest articol sunt reale. Provin din prima rulare T0 a protocolului, pe site-ul meu, delamatescu.ro, la 26 octombrie 2026: 6 pagini, 56 de cereri, 12 crawlere declarate. Rularea e documentată integral în studiul de caz CS-002, iar dovezile brute sunt publicate, cu checksum-uri.³

Care sunt cele 7 idei principale ale protocolului?

Protocolul pornește de la șapte principii: măsurăm accesibilitatea înaintea vizibilității, separăm dovada de interpretare, verificăm regulile de crawling și indexare, documentăm identitatea URL-urilor, comparăm răspunsurile oferite crawlerelor, păstrăm artefactele brute și repetăm aceleași verificări între T0 și Fn.

Accesibilitatea tehnică precede vizibilitatea. Mai întâi verificăm dacă resursa poate fi obținută și ce răspuns livrează serverul.
Dovada trebuie separată de interpretare. Un 200, 403, canonical sau robots.txt este o observație, nu o concluzie despre vizibilitatea AI.
Crawlingul, indexarea, citarea și recomandarea sunt fenomene diferite. Protocolul evită să le trateze ca sinonime.
Identitatea tehnică a documentului trebuie să fie observabilă. Redirecturile, canonical-ul, sitemap-ul și directivele robots oferă context despre ce resursă este expusă sistemelor automate.
Răspunsurile pentru crawlere pot fi comparate. Googlebot, bingbot, OAI-SearchBot, Claude-SearchBot și PerplexityBot pot fi folosite în teste de User-Agent Response Parity.
Evidența brută trebuie păstrată. Headers, HTML, robots.txt, sitemap-uri, răspunsuri și hash-uri trebuie să poată fi verificate ulterior.
Metoda trebuie repetată identic. Valoarea principală apare când aceeași verificare este executată la baseline T0 și apoi la F1, F2, F3 sau Fn.

De ce este necesară o verificare tehnică înainte să măsurăm AI Visibility?

Verificarea tehnică este necesară pentru că o schimbare observată într-un răspuns AI nu poate fi interpretată riguros dacă nu știm în ce condiții tehnice era disponibilă sursa în momentul măsurării.

Dacă un brand nu apare într-un răspuns ChatGPT, Claude sau Perplexity, există multe explicații posibile.

Sistemul poate să nu cunoască sursa. Sursa poate să nu fi fost descoperită. Crawlerul relevant poate fi blocat. Pagina poate declara noindex. URL-ul poate redirecționa. Canonical-ul poate indica o altă resursă. Serverul poate răspunde diferit crawlerelor. Sau toate aceste condiții tehnice pot fi corecte, iar sistemul să aleagă pur și simplu alte surse.

De aceea, AI Visibility trebuie tratată ca un lanț de condiții și observații, nu ca o singură variabilă.

Pentru GEO și AEO această distincție este esențială. Optimizarea pentru motoare generative sau motoare de răspuns nu începe cu întrebarea „Cum fac să mă citeze ChatGPT?”, ci cu una anterioară: Ce informație despre această entitate este disponibilă sistemelor automate, în ce formă și prin ce mecanisme poate fi descoperită?

Cum separă AI Visibility Lab dovada de interpretare?

AI Visibility Lab folosește un lanț explicit în care captura dovezii, artefactul brut, indexarea dovezii, observația, măsurarea și interpretarea sunt tratate ca etape diferite.

Evidence Capture Process
          ↓
Raw Evidence
          ↓
Indexed Evidence
          ↓
Observation
          ↓
Measurement
          ↓
Interpretation

Un exemplu din rularea T0. Evidence Capture Process: o cerere curl către https://delamatescu.ro/robots.txt. Raw Evidence: fișierul salvat, robots/delamatescu.ro.try1.body, cu headerele și metricile cererii. Indexed Evidence: același fișier, înregistrat cu identificator, URL, oră și hash SHA-256 în indexul de dovezi al rulării.⁴

Din el se extrage o observație:

26  User-agent: OAI-SearchBot
27  Allow: /

După aplicarea regulilor RFC 9309 pentru fiecare pereche pagină–crawler, observația devine măsurare:

P01 https://delamatescu.ro/ · OAI-SearchBot · ALLOW · metoda PARSER · regula câștigătoare: linia 27

Abia după aceea apare interpretarea: pentru această pagină și acest crawler, regulile din robots.txt corespund politicii de acces declarate.

Această ordine previne salturile logice. Un 403 nu înseamnă automat că site-ul este invizibil în AI. Un 200 nu înseamnă că pagina este indexată. Un sitemap nu demonstrează că URL-urile sale au fost procesate. Un canonical declarat nu demonstrează că un motor de căutare a selectat acel canonical. Iar prezența datelor structurate nu demonstrează că un sistem AI a înțeles sau folosit entitatea descrisă.

Pentru GEO/AEO, valoarea acestei separări este că permite diferențierea între:

availability
discovery
crawlability
indexability
retrieval
citation
mention
recommendation

Acestea sunt fenomene legate între ele, dar nu identice.

Ce verifică protocolul despre accesibilitatea și identitatea tehnică a unei pagini?

Protocolul verifică dacă pagina răspunde, unde ajunge requestul după redirecturi, ce tip de conținut livrează serverul și dacă variantele HTTP/HTTPS și www/non-www converg spre aceeași identitate tehnică.

Comenzile exacte și cerințele sunt în AVL-203 §5. Pentru pagina principală a delamatescu.ro, metricile cererii arată așa:

http_code=200
url_effective=https://delamatescu.ro/
num_redirects=0
content_type=text/html; charset=utf-8
curl_exit=0

Toate cele 6 pagini din plan au răspuns la fel: 200, fără redirecturi. Asta arată că cererea a reușit (RFC 9110 §15.3.1), nu că pagina e indexată.⁶

Variantele adresei au convers toate spre https://delamatescu.ro/, dar nu în același fel: http://delamatescu.ro/ cu 301 (redirecționare permanentă, RFC 9110 §15.4.2), iar variantele cu www cu 302 (temporară, RFC 9110 §15.4.3).⁶ Destinația e aceeași, deci identitatea tehnică e convergentă. Tipul redirectului e o observație separată, pe care o urmăresc la remăsurare.

Dacă aceeași informație este expusă prin mai multe URL-uri contradictorii, redirecturi inconsistente sau canonical-uri diferite, apare o problemă de identitate tehnică înainte să apară problema de interpretare semantică.

Cum verificăm dacă motoarele de căutare și sistemele AI pot descoperi și procesa conținutul?

Protocolul verifică robots.txt, sitemap-ul, directivele de indexare, canonical-ul, datele structurate de bază și prezența textelor importante în HTML-ul livrat de server, pentru a documenta semnalele machine-readable expuse de site.

Detaliile sunt în AVL-203 §6–§8. Pe scurt, la delamatescu.ro:

robots.txt are 24 de grupuri User-agent și o declarație Sitemap. Aplicate după RFC 9309, regulile permit accesul tuturor celor 12 crawlere declarate, pe toate paginile. Un grep nu ajunge: RFC 9309 cere combinarea grupurilor care corespund aceluiași crawler și alegerea celei mai specifice reguli (§2.2.1, §2.2.2).⁵
Sitemap-ul e declarat în robots.txt și răspunde 200, cu un document XML de 200 de adrese.
Semnalele paginilor: fiecare pagină are <title>, canonical spre propria adresă și lang="ro", fără noindex; toate cele 10 blocuri JSON-LD au sintaxă JSON validă.
Textele-cheie declarate în plan (de exemplu „audit AI Visibility” pe pagina serviciului) apar în corpul HTML-ului brut, nu doar în scripturi.

Trebuie însă păstrată o distincție importantă: robots.txt controlează crawlingul, nu demonstrează indexarea. Google spune explicit că robots.txt nu e un mecanism prin care o pagină e ținută în afara Google și că o pagină blocată poate fi totuși indexată dacă alte site-uri trimit la ea.⁷ RFC 9309 precizează că regulile nu sunt o formă de autorizare a accesului (§1).⁵ Un crawler permis nu înseamnă automat că pagina a fost accesată. Un crawler care a accesat pagina nu înseamnă automat că pagina a fost indexată. Iar indexarea nu garantează citarea într-un răspuns generativ.

Canonical-ul indică URL-ul preferat declarat de site, dar Google îl tratează ca indiciu, nu ca regulă, și poate alege alt canonical.⁸ Pentru AI Overviews și AI Mode, Google spune că nu e nevoie de fișiere noi, fișiere text pentru AI sau markup special: pagina trebuie să fie indexată și eligibilă să apară în Search cu snippet.⁹

Pentru GEO/AEO, aceste elemente contează deoarece contribuie la stratul machine-readable al site-ului. Dar protocolul păstrează aceeași limită: semnalul declarat nu trebuie confundat cu modul în care un sistem extern îl interpretează sau îl folosește.

Ce înseamnă User-Agent Response Parity și de ce este relevantă pentru AI?

User-Agent Response Parity verifică dacă același server livrează răspunsuri diferite atunci când requestul se identifică drept client generic, Googlebot, bingbot sau crawler de search asociat unui sistem AI.

Același URL e cerut cu clientul de referință (de două ori, cu aceiași parametri) și cu fiecare User-Agent declarat. Se compară statusul, URL-ul final, headerele, dimensiunea și hash-ul conținutului. Regulile complete sunt în AVL-203 §9.

La delamatescu.ro, statusul, URL-ul final și headerele au fost identice pentru toți cei 5 crawleri de căutare, pe toate paginile. Conținutul însă a diferit chiar între cele două capturi ale clientului de referință, făcute la câteva secunde distanță:

referință 1   10.109 octeți   sha256 fa04f81aa515368e…
referință 2   10.119 octeți   sha256 7343888b289daaea…

Când pagina se schimbă singură de la o cerere la alta, o diferență față de un crawler nu poate fi atribuită User-Agent-ului. Comparația de conținut rămâne „nu poate fi stabilit”.

Testul demonstrează doar cum a răspuns serverul unui request care s-a identificat drept un anumit crawler. User-Agent-ul poate fi falsificat, iar furnizorii pot folosi și verificarea adreselor IP; OpenAI, de exemplu, publică intervalele de IP ale crawlerelor sale.¹⁰ Cererile mele au plecat de pe IP-ul meu, nu din infrastructura lor.

Din acest motiv, numele testului este intenționat precis: User-Agent Response Parity, nu crawler accessibility proof.

Pentru GEO/AEO, testul este util deoarece poate identifica bariere tehnice evidente care merită investigate înainte de a formula ipoteze despre vizibilitatea efectivă.

De ce sunt păstrate HTML-ul brut, headerele și hash-urile?

Artefactele brute sunt păstrate pentru ca orice observație sau concluzie ulterioară să poată fi urmărită înapoi până la dovada originală.

Dacă un raport afirmă că OAI-SearchBot are acces la pagina principală, ar trebui să existe posibilitatea de a inspecta:

request context
response headers
response body
timestamp
URL
hash

Fără aceste artefacte, rămâne doar afirmația celui care a făcut analiza. În AI Visibility Lab încerc să păstrez traseul:

claim
↑
measurement
↑
observation
↑
indexed evidence
↑
raw evidence

Hash-ul SHA-256 ajută la acest proces. El funcționează ca o amprentă digitală a fișierului: dacă fișierul se modifică, hash-ul se modifică, cu probabilitate covârșitoare. Rularea T0 are 234 de artefacte cu checksum, publicate ca pachet de dovezi pe GitHub.⁴ În pachetul public am înlocuit un singur lucru, numele mașinii din fișierul care descrie mediul rulării. Verificarea o arată imediat:

integritate: PARTIAL {'OK': 233, 'MODIFICAT': 1}

Hash-urile sunt utile și în User-Agent Response Parity. Dacă două body-uri au exact același SHA-256, ele pot fi considerate, în practică, identice la nivel de bytes. Dacă hash-urile diferă, știm că există o diferență, dar nu știm încă dacă este relevantă.

Ea poate proveni din timestamp-uri, identificatori dinamici, cookies, teste A/B, personalizare, token-uri generate, protecții anti-bot sau conținut diferit. La delamatescu.ro am găsit două surse: un token semnat, injectat de platforma pe care e construit site-ul, cu dată de expirare proprie la fiecare cerere, și marcajele de timp ale randării pe server. Cu ele mascate, toate cele 42 de corpuri comparate au devenit identice. Grila nu permite însă mascarea, deci rezultatul oficial a rămas „nu poate fi stabilit”, iar mascarea e doar o observație suplimentară.³

Prin urmare: hash diferit = diferență detectată, nu hash diferit = problemă de AI Visibility.

Cum devin observațiile diagnostic?

Observațiile devin diagnostic numai prin regulile publice ale grilei AVL-204: fiecare regulă are o condiție, o zonă și o stare, iar aceleași reguli se aplică oricărei entități evaluate.

Grila grupează verificările în șase zone (Z1 răspunsul site-ului și adresa oficială, Z2 regulile pentru crawlere, Z3 sitemap-ul, Z4 semnalele paginilor, Z5 conținutul livrat în HTML, Z6 răspunsurile pentru crawlere) și folosește patru stări: „problemă confirmată”, „problemă posibilă”, „nu poate fi stabilit” și „nicio problemă observată”. Regulile și criteriile de prioritizare sunt în AVL-204.²

Pentru delamatescu.ro, grila 0.3.0 a produs 109 constatări:

Zonă	Constatări	Stare
Z1	6	nicio problemă observată
Z2	54 (9 crawlere × 6 pagini)	nicio problemă observată
Z3	1	nicio problemă observată
Z4	6	nicio problemă observată
Z5	6	nicio problemă observată
Z6	36	nu poate fi stabilit (conținutul); nicio problemă observată (status, URL, headere)

Diagnosticul a produs o singură recomandare, de tip „verificare suplimentară”: comparația de conținut de la Z6 se reia la o rulare nouă. Grila nu îi dă clasă de prioritate, pentru că o constatare „nu poate fi stabilit” nu e o problemă.

Separarea grilei de protocol are un motiv practic. Dacă regula de interpretare e scrisă înainte de rulare și e publică, nu o pot ajusta după rezultat, nici pentru site-ul meu, nici pentru al unui client. „Nicio problemă observată” descrie condițiile testate, nu certifică site-ul.

Ce primește clientul?

Clientul primește un raport pe zone, de trei pagini: o întrebare pe înțelesul lui pentru fiecare zonă, starea și explicația ei, recomandările cu prioritate și limitele verificării. Nu primește anexa tehnică.

Raportul tehnic al rulării T0 are 109 constatări, identificatorii regulilor și trimiteri la dovezi. E necesar pentru trasabilitate, dar clientul nu îl poate folosi. Raportul pentru client se generează din același diagnostic, cu formulări fixe, aceleași pentru orice client, și trece prin aceeași verificare automată a afirmațiilor excluse de grilă (de exemplu „pagina e indexată” sau „site-ul face cloaking”).

Exemplul pentru delamatescu.ro e public: raportul pentru client, T0 (PDF). Concluzia lui, pentru un site fără probleme tehnice, e una pe care o consider utilă tocmai pentru că e modestă: în condițiile testate nu există blocaje de acces, deci dacă site-ul are probleme de vizibilitate, cauza trebuie căutată în celelalte etape ale auditului AI Visibility: identitatea entității, conținutul și sursele.

Cum ajută repetarea protocolului la măsurarea GEO/AEO în timp?

Repetarea acelorași verificări la T0 și Fn permite documentarea schimbărilor tehnice ale site-ului și analizarea lor în paralel cu schimbările observate în menționări, citări și recomandări AI.

La baseline T0 capturăm starea inițială. Ulterior, la F1, F2, F3…Fn, repetăm aceeași procedură, cu aceleași pagini și aceleași texte-cheie, declarate dinainte într-un plan înghețat.

Putem observa dacă între două momente s-a schimbat statusul HTTP sau un redirect, a apărut sau a dispărut o regulă în robots.txt, sitemap-ul ori canonical-ul s-au modificat, a apărut JSON-LD, directivele de indexare sunt diferite, un User-Agent primește alt răspuns sau conținutul brut al paginii s-a modificat. Pentru delamatescu.ro, primele lucruri pe care le urmăresc la F1 sunt tipul redirectului www și variabilitatea de la Z6.

Un plan înghețat ține de versiunea protocolului pentru care a fost înghețat. Planul T0 al delamatescu.ro a fost înghețat sub AVL-203 0.5.0, iar instrumentul actual îl refuză. Pentru F1 se îngheață un plan nou, cu aceleași pagini, iar schimbarea de versiune se declară la comparație.

Aceste observații pot fi puse alături de măsurătorile efective de AI Visibility:

citation
mention
recommendation
entity resolution
source selection
answer composition

Aici apare valoarea reală a protocolului. Dacă la T0 o entitate nu este identificată, iar la F3 începe să fie menționată corect, putem analiza în paralel ce s-a schimbat în ecosistemul informațional.

Nu înseamnă că orice schimbare tehnică a cauzat schimbarea răspunsului AI. Dar avem mai multă informație pentru a formula și testa ipoteze.

În loc să spunem „am optimizat pagina și ChatGPT a început să mă citeze”, putem ajunge la o afirmație mai riguroasă: „între T0 și F3 au fost documentate aceste schimbări; în aceeași perioadă a apărut acest comportament în sistemele măsurate; datele permit sau nu permit atribuirea unei relații între ele”.

Această diferență este centrală pentru modul în care vreau să tratez GEO și AEO în AI Visibility Lab.

În ce stadiu de maturitate este protocolul?

Protocolul și grila sunt într-un stadiu incipient: drafturi 0.x, construite din trei rulări de test și o rulare T0, toate pe delamatescu.ro. Vor fi revizuite pe măsură ce apar situații pe care nu le-au prevăzut, după o procedură scrisă dinainte.

Nu e o limită ascunsă, ci una declarată. Versiunile 0.x și lista deciziilor deschise înainte de 1.0.0 sunt publice în AVL-203 și AVL-204. Un caz pe care regulile nu îl acoperă nu se interpretează din mers: nu poate primi „problemă confirmată”, e declarat ca abatere în raport și devine propunere pentru versiunea următoare.

Secvența, de la draft la pașii care urmează:

1. Draft
   AVL-203 0.1.0 (1 oct.), AVL-204 0.1.0 (22 oct.)
        ↓
2. Rulări TEST pe delamatescu.ro (2 și 25 oct.)
   revizii: AVL-203 0.2.0 și 0.5.0, AVL-204 0.2.0
        ↓
3. Rularea T0 pe delamatescu.ro (26 oct.)
   decizii: AVL-203 0.6.0, AVL-204 0.3.0
        ↓
4. Publicare (28 oct.)
   CS-002, pachetul de dovezi, raportul-exemplu
        ↓
──── de aici, pașii prevăzuți de protocol ────
5. Rulări pe proiecte și clienți
   (fișa entității completată de reprezentant)
        ↓
6. Situație neacoperită de reguli
   nu devine „problemă confirmată”;
   se declară ca abatere în raport
        ↓
7. Propunere de modificare
   versiune nouă, cu rând în istoric
        ↓
8. Remăsurare F1 … Fn, cu plan nou înghețat
   versiunile diferite se declară la comparație
        ↓
   pașii 5–8 se repetă
        ↓
9. Activare 1.0.0, după închiderea
   deciziilor deschise (AVL-203 §19, AVL-204 §15)

Pașii 1–4 s-au întâmplat. Pașii 5–9 sunt cei prevăzuți de reguli, nu un calendar: protocolul se îmbunătățește când apare un caz pe care nu l-a prevăzut, nu la o dată fixă. Rapoartele clienților nu se publică; ce se publică e modificarea regulilor, cu motivul ei, în istoricul versiunilor. Regulile citate sunt AVL204-REQ-003 și AVL204-REQ-012 (cazul neacoperit și abaterea declarată), AVL204-REQ-013 și AVL204-REQ-014 (versiunea nouă și comparația între versiuni).

Declarația privește protocolul tehnic și grila lui. Cadrul metodologic (AVL-202) și standardul de dovezi (AVL-200) sunt documente active. Pentru un client, consecința practică e simplă: regulile după care e evaluat site-ul lui sunt publice și versionate, iar raportul spune cu ce versiune a fost produs.

Poate acest protocol demonstra că un site va fi citat, menționat sau recomandat de AI?

Nu; protocolul tehnic poate documenta condițiile tehnice de acces, descoperire și machine-readability, dar nu poate demonstra singur indexarea, retrieval-ul, citarea, menționarea sau recomandarea într-un sistem AI.

Aceasta este limita metodologică cea mai importantă. Protocolul nu poate demonstra singur:

Google indexed the page
Bing indexed the page
ChatGPT knows the page
Claude knows the page
Perplexity indexed the page
an AI system understood the entity
the page will be retrieved
the page will be cited
the brand will be mentioned
the entity will be recommended

Aceste fenomene trebuie măsurate separat. Tocmai de aceea AI Visibility Lab nu tratează „optimizarea pentru AI” ca pe o colecție de trucuri tehnice.

Putem distinge analitic mai multe straturi:

technical accessibility
↓
discovery
↓
machine readability
↓
entity understanding
↓
retrieval
↓
source selection
↓
citation / mention
↓
recommendation

Aceasta este o schemă conceptuală de analiză, nu o descriere verificată a unui pipeline comun tuturor sistemelor. Nu toate sistemele urmează aceleași etape, iar funcționarea lor internă nu este complet observabilă. Separarea straturilor ne ajută însă să evităm afirmațiile mai puternice decât dovezile de care dispunem. Verificarea tehnică acoperă primele trei straturi; restul se măsoară cu alte metode, de exemplu în studiul Tabula Rasa pentru rezolvarea entității.

Acesta este și motivul pentru care protocolul tehnic rămâne intenționat restrâns. Nu încerc să includ în el fiecare posibil audit de DNS, TLS, Core Web Vitals, JavaScript rendering, internal linking, Schema.org validation, server logs, WAF, ARIA, cache sau performanță. Acestea pot deveni relevante într-o investigație particulară, ca extensii declarate, dar protocolul de bază trebuie să rămână suficient de mic încât să poată fi executat consecvent la fiecare măsurare.

Care este rolul instrumentului în metodologia AI Visibility Lab?

Instrumentul automatizează capturarea repetabilă a dovezilor tehnice și aplicarea grilei, dar metodologia stabilește ce se măsoară, de ce se măsoară și ce concluzii pot fi trase.

Instrumentul laboratorului e o linie de comandă cu câte un pas pentru fiecare etapă: planul se validează și se îngheață, se capturează, se verifică integritatea, se extrag observațiile, se aplică grila și se scriu rapoartele. Ieșirea fiecărei comenzi, la rularea T0, e în studiul de caz CS-002. Pasul de diagnostic, de exemplu, afișează doar starea zonelor:

Z1: nicio problemă observată
...
Z6: nu poate fi stabilit
109 constatări · 1 recomandări · 0 abateri

Dar instrumentul nu decide singur semnificația rezultatului. Aplică literal reguli scrise înainte, în AVL-204. Întrebarea „Ce înseamnă acest rezultat pentru experimentul analizat?” aparține unui nivel ulterior.

Methodology
      ↓
defines measurement
Automation
      ↓
executes measurement
Evidence
      ↓
records result
Analysis
      ↓
evaluates result
Interpretation
      ↓
connects result with research question

Automatizarea nu înlocuiește metodologia. O face mai repetabilă.

Ce încearcă, în final, să măsoare acest protocol?

Protocolul încearcă să stabilească ce putea fi observat tehnic despre un site la momentul măsurării, înainte ca rezultatele de AI Visibility să fie interpretate.

Scopul nu este să strâng cât mai multe comenzi curl și nici să construiesc cel mai sofisticat scanner posibil.

Întrebarea fundamentală este: În momentul în care am măsurat comportamentul unui sistem AI, care era starea tehnică observabilă a sursei?

Dacă această stare este capturată la T0 și apoi din nou la F1, F2 sau Fn, putem construi un istoric. Iar atunci când apar schimbări în entity resolution, menționări, citări, selecția surselor sau recomandări, avem un strat suplimentar de dovezi prin care putem încerca să înțelegem ce s-a întâmplat.

Nu eliminăm incertitudinea. Dar o documentăm mai bine.

Pentru mine, aceasta este diferența dintre a aplica câteva „best practices GEO” și a încerca să construiesc o metodă de măsurare a AI Visibility.

Surse și metodologie

Exemplele provin din rularea AVL203-delamatescu-ro-T0-20261026T085234Z, verificată pe dovezile brute la 28 octombrie 2026. Documentația externă a fost verificată live la aceeași dată.

AI Visibility Lab, AVL-203 — Protocolul minim de verificare tehnică a unui site pentru AI Visibility, v0.6.1, draft pentru revizuire. /lab/metodologie/protocol-verificare-tehnica
AI Visibility Lab, AVL-204 — Grila de interpretare a verificării tehnice, v0.3.1, draft pentru revizuire. /lab/metodologie/grila-interpretare-verificare-tehnica
AI Visibility Lab, Poate fi citit tehnic site-ul meu de crawlerele AI? Verificarea AVL-203 a delamatescu.ro, punctul T0, studiul de caz CS-002. /lab/studii-de-caz/verificare-tehnica-delamatescu-ro
AI Visibility Lab, AVL203-delamatescu-ro — T0 Technical Evidence Package v1.0, release GitHub. github.com/alexmatescu/alexmatescu-hub-reflection/releases/tag/evidence-avl203-delamatescu-ro-t0-v1.0
IETF, RFC 9309 — Robots Exclusion Protocol (§1, §2.2.1, §2.2.2). rfc-editor.org/rfc/rfc9309
IETF, RFC 9110 — HTTP Semantics (§15.3.1, §15.4.2, §15.4.3). rfc-editor.org/rfc/rfc9110
Google Search Central, Introduction to robots.txt. developers.google.com/search/docs/crawling-indexing/robots/intro
Google Search Central, What is canonicalization. developers.google.com/search/docs/crawling-indexing/canonicalization
Google Search Central, AI features and your website. developers.google.com/search/docs/appearance/ai-features
OpenAI, Overview of OpenAI Crawlers. developers.openai.com/api/docs/bots

Notă de volatilitate

Documentația furnizorilor despre crawlere, rolul fiecărui User-Agent și intervalele de IP se schimbă. Afirmațiile despre Google și OpenAI au fost verificate la 28 octombrie 2026. Exemplele descriu delamatescu.ro la 26 octombrie 2026; site-ul s-a schimbat de atunci, iar starea actuală se măsoară la F1.

Istoricul versiunilor

Versiune	Dată	Modificări
1.0	28 octombrie 2026	Publicare inițială.
1.1	28 octombrie 2026	Secțiune nouă „În ce stadiu de maturitate este protocolul?”, cu secvența pașilor de la draft la publicare și pașii următori prevăzuți de protocol; o frază despre stadiul protocolului în introducere. Restul textului nu a fost modificat.

Articol publicat de AI Visibility Lab, proiect independent de cercetare aplicată și documentare în AI Visibility, GEO și AEO, fondat și coordonat de Alex Matescu. Ultima verificare factuală și a surselor: 28 octombrie 2026.