Alex Matescu
    Articole

    AI Visibility Lab · Articole

    Site-ul nu dispare. Își schimbă clientul: cum se pregătește web-ul pentru agenți AI

    Ce înseamnă un site pregătit pentru agenți AI și ce nu înseamnă. Analizăm crawling, browser use, WebMCP, MCP, API-uri, structured data, autentificare și o metodă de măsurare bazată pe dovezi, fără a confunda accesibilitatea tehnică cu vizibilitatea sau recomandarea AI.

    · Fondator și coordonator AI Visibility Lab

    Publicat: · Ultima verificare factuală:

    Site-ul nu devine irelevant în era agenților AI. Dimpotrivă, începe să deservească o categorie suplimentară de utilizatori: software care poate descoperi informație, o poate interpreta și, în anumite condiții, poate executa acțiuni în numele unui om. Problema nu mai este doar dacă o pagină poate fi citită, ci și ce poate face un sistem AI după ce ajunge la ea.

    Pe 30 septembrie 2026, Cloudflare a publicat o analiză cu un titlu care surprinde foarte bine schimbarea: The Internet has a second audience. Compania spune că, în propria rețea, solicitările zilnice provenite de la agenți AI au crescut cu peste 1.700% într-un an și argumentează că agenții reprezintă o categorie distinctă față de oamenii care navighează și față de boții tradiționali.1

    Cifrele provin din infrastructura Cloudflare și nu trebuie generalizate automat la întregul internet. Dar fenomenul pe care îl descriu este verificabil și din alte direcții: OpenAI documentează user agents care accesează pagini la cererea utilizatorului, oferă site tools bazate pe WebMCP, iar Model Context Protocol continuă să evolueze ca infrastructură prin care agenții pot descoperi și folosi date și instrumente externe.234

    În primul articol al seriei am introdus problema machine accessibility. În al doilea am arătat de ce o informație publică nu este automat accesibilă fiecărui sistem AI. Acum mutăm analiza asupra site-ului propriu.

    Întrebarea nu mai este doar:

    Poate fi găsit site-ul meu?

    Ci și:

    Ce poate înțelege și ce poate face un sistem AI atunci când ajunge la el?

    Unde se încadrează în serie: din modelul în șapte niveluri propus în primul articol (Presence → Discoverability → Accessibility → Understanding → Verifiability → Recommendability → Actionability), acest articol privește nivelurile 2–5 și nivelul 7 din perspectiva site-ului propriu. Cele trei tipuri de readiness propuse aici le grupează: Information Readiness acoperă nivelurile 2–5, de la Discoverability la Verifiability, iar Interaction și Transaction Readiness detaliază nivelul 7, Actionability. Nivelul 6, Recommendability, rămâne în afara articolului: pregătirea site-ului nu garantează recomandarea.

    Articolul în 7 idei

    1. De ce site-ul nu dispare în era AI? Pentru că rămâne una dintre puținele surse digitale pe care o organizație le controlează direct și care poate servi atât oamenilor, cât și sistemelor automate.
    2. Cine este noul „client” al site-ului? Nu un model abstract, ci crawlere, sisteme de căutare, browser agents și agenți care folosesc instrumente oferite de site.
    3. Este suficient ca site-ul să fie crawlable? Nu. Accesul, interpretarea și posibilitatea de acțiune sunt capacități diferite.
    4. Trebuie refăcut site-ul pentru AI? Nu există o regulă universală. Google spune explicit că nu este nevoie de un markup special pentru generative AI search, iar llms.txt nu influențează vizibilitatea în Google Search.
    5. Ce aduc WebMCP, MCP și API-urile? O cale prin care un agent poate folosi funcții și date fără să depindă exclusiv de interpretarea interfeței vizuale.
    6. Ce înseamnă un site „agent-ready”? Este mai util să separăm pregătirea informațională, interacțională și tranzacțională decât să tratăm agent readiness ca pe o singură bifă.
    7. Cum măsurăm dacă un site este pregătit pentru agenți AI? Verificând separat documentația, accesul tehnic, comportamentul observat și acțiunile efectiv executabile.

    1. De ce site-ul nu dispare în era agenților AI?

    Pentru că site-ul rămâne un punct de publicare, control și interacțiune aflat direct sub responsabilitatea organizației. Intermediarii se schimbă, dar nevoia unei surse primare nu dispare.

    Traseele clasice, de la site prin motorul de căutare la om și, mai nou, prin răspunsul generat de AI, au fost descrise în primul articol al seriei. Agenții adaugă un traseu în care site-ul nu mai este doar citit, ci și folosit:

    Business
   ↓
Website / API / tool / business system
   ↓
AI agent
   ↓
Read / compare / update / book / buy / submit
   ↓
Human outcome

    Aceste trasee coexistă. Nu există dovadă că website-ul este pe cale să fie înlocuit în bloc de agenți. Dimpotrivă, documentațiile actuale ale Google, OpenAI și Cloudflare tratează în continuare site-ul ca infrastructură relevantă: Google cere ca o pagină să fie indexată în Search pentru a putea apărea în AI Overviews și AI Mode; OpenAI documentează crawlere și acces la pagini; Cloudflare dezvoltă instrumente pentru controlul accesului agenților la site-uri.256

    Așadar, afirmația „site-urile nu vor mai conta” confundă schimbarea interfeței cu dispariția sursei.

    Un utilizator poate să nu mai deschidă direct zece pagini înainte de a lua o decizie. Agentul său poate face acest lucru în locul lui. Dar dacă informația de bază provine de pe site-ul business-ului, calitatea, actualitatea și accesibilitatea acelui site continuă să conteze.

    2. Cine este noul „client” al site-ului?

    Nu există un singur vizitator AI. Există mai multe clase de software care pot interacționa cu site-ul în moduri diferite. Tocmai de aceea expresia „optimizat pentru AI” este prea vagă pentru o măsurare serioasă.

    OpenAI, de exemplu, separă în documentația sa mai multe roluri. OAI-SearchBot este folosit pentru search, GPTBot pentru crawling asociat potențialei utilizări în antrenarea modelelor, iar ChatGPT-User poate vizita pagini în urma unor acțiuni inițiate de utilizator. OpenAI precizează că aceste roluri sunt independente și că ChatGPT-User nu este un crawler automat pentru web.2

    Cloudflare folosește la rândul său categorii distincte precum AI Crawler, AI Search și AI Assistant în documentația AI Crawl Control.6

    Mai nou, există și o altă categorie: agentul care nu doar încarcă o pagină, ci folosește funcții oferite direct de ea. OpenAI descrie site tools în aplicația desktop ChatGPT ca instrumente pe care un website le poate pune la dispoziția ChatGPT pentru a găsi informație, actualiza conținut sau utiliza funcții interactive. Implementarea folosește WebMCP, descris de OpenAI ca un standard web propus. Funcția este disponibilă doar în anumite condiții de cont și model, nu tuturor utilizatorilor ChatGPT.3

    Prin urmare, „clientul” site-ului poate fi:

    Human browser
Search crawler
AI search crawler
User-triggered fetcher
Browser agent
Tool-using agent
API / MCP client

    Aceste categorii nu sunt interschimbabile. Faptul că una funcționează nu demonstrează că toate celelalte funcționează.

    3. Este suficient ca site-ul să fie crawlable?

    Nu. Crawlability rezolvă o problemă de acces, nu întreaga problemă de reprezentare și nici problema acțiunii. Un agent poate ajunge la o pagină și totuși să nu poată identifica informația relevantă, să nu aibă acces la datele actuale sau să nu poată executa funcția dorită.

    Pentru o pagină informațională, un traseu minimal poate fi:

    Reachable
   ↓
Crawlable
   ↓
Discoverable
   ↓
Retrievable
   ↓
Interpretable

    Pentru o acțiune, însă, traseul poate continua:

    Interpretable
   ↓
Authorized
   ↓
Interactive
   ↓
Actionable

    Un hotel poate avea o pagină perfect indexabilă care explică tipurile de camere, dar disponibilitatea pe 17 octombrie poate exista doar în motorul de rezervări. Un magazin poate publica un produs și prețul său, dar cumpărarea presupune stoc actual, autentificare, adresă, plată și confirmare. Un cabinet poate avea pagina serviciului, dar programarea poate depinde de un sistem separat.

    De aceea, pentru AI Visibility Lab, este util să nu reducem site readiness la robots.txt, sitemap sau accesul unui crawler. Acestea sunt importante, dar reprezintă doar o parte din traseu.

    4. Trebuie refăcut site-ul „pentru AI”?

    Nu există astăzi o rețetă universală și nici un set magic de fișiere care garantează vizibilitatea în răspunsurile AI. Unele practici clasice rămân fundamentale, iar standardele agentice trebuie evaluate separat de SEO.

    Google afirmă explicit în ghidul său pentru generative AI features din Search că practicile SEO fundamentale rămân relevante. Pentru apariția în AI Overviews sau AI Mode, pagina trebuie să îndeplinească cerințele tehnice pentru Google Search, să fie indexată și eligibilă pentru afișare cu snippet. Google spune că nu există cerințe tehnice suplimentare speciale pentru aceste funcții.5

    Același ghid contrazice două idei care apar frecvent în discuțiile GEO/AEO:

    • Google Search nu cere un schema.org special pentru generative AI;
    • Google Search ignoră llms.txt, astfel încât existența lui nu ajută și nu afectează vizibilitatea sau ranking-ul în Google Search.7

    Asta nu înseamnă că structured data este inutilă. Google o folosește pentru a înțelege și clasifica informații despre pagini și pentru eligibilitatea anumitor rich results, iar documentația recomandă ca markup-ul să fie corect, actualizat și reprezentativ pentru conținutul vizibil.8

    Distincția importantă este:

    Structured data poate avea valoare pentru anumite sisteme și funcții, dar nu trebuie prezentată ca o garanție universală de înțelegere, citare sau recomandare AI.

    La fel, un fișier sau protocol nou poate fi util unui anumit agent și complet ignorat de altul.

    Prin urmare, înainte de implementare trebuie identificat sistemul țintă și mecanismul documentat pe care vrem să îl servim.

    5. Ce aduc WebMCP, MCP și API-urile?

    Ele schimbă relația dintre agent și website de la „interpretează interfața” la „folosește o capacitate declarată”. Aceasta este una dintre cele mai importante diferențe dintre simplul browser automation și un web proiectat explicit pentru agenți.

    În cazul browser automation, agentul poate încerca să opereze site-ul aproximativ cum ar face-o un om:

    open page
   ↓
read interface
   ↓
find button
   ↓
click
   ↓
fill form

    Acest traseu poate funcționa, dar este sensibil la modificări de layout, formulare, autentificare și mecanisme anti-abuz.

    Prin WebMCP, un site poate expune instrumente direct agentului în contextul paginii deschise. OpenAI spune că site tools permit ChatGPT să descopere și să folosească aceste instrumente atunci când site-ul le oferă și utilizatorul are acces la funcție.3

    La un nivel mai general, Model Context Protocol (MCP) oferă un protocol deschis prin care clienții AI pot interacționa cu resurse și instrumente externe. Specificația publicată la 28 iulie 2026 a mutat nucleul protocolului către un model stateless și a continuat dezvoltarea componentelor de autorizare și extensibilitate.4

    Există și mecanisme web mai tradiționale. API-urile pot oferi acces structurat la produse, disponibilitate, documentație sau funcții. Cloudflare include în propriul său cadru de Agent Readiness elemente precum API Catalog, MCP, WebMCP, OAuth discovery și alte mecanisme de descoperire a capabilităților.9

    Aici este însă esențială o delimitare E-E-A-T:

    Cloudflare Agent Readiness este un cadru și un instrument creat de Cloudflare, nu un standard universal acceptat al web-ului. Unele componente pe care le testează sunt standarde consacrate, altele sunt propuneri sau tehnologii emergente. Articolul de față îl folosește ca dovadă că industria construiește infrastructură pentru agenți, nu ca autoritate finală asupra modului în care toate site-urile trebuie proiectate.

    6. Ce înseamnă, concret, un site pregătit pentru agenți AI?

    Nu este util să tratăm „agent-ready” ca pe o singură stare. Un site poate fi foarte bun ca sursă de informație și să nu aibă niciun motiv să permită tranzacții automatizate. Pentru măsurare, propunem trei dimensiuni distincte.

    6.1 Information Readiness

    Întrebarea este:

    Poate sistemul relevant să găsească, accesa și interpreta corect informația pe care business-ul intenționează să o publice?

    Aici intră, în funcție de obiectiv:

    • accesul HTTP și randarea conținutului;
    • robots.txt și sitemap;
    • canonicalizarea;
    • structurarea coerentă a paginii;
    • metadata și structured data acolo unde sunt suportate;
    • identitatea clară a organizației și entităților;
    • data actualizării;
    • evitarea contradicțiilor dintre pagini;
    • documentația și sursele primare.

    Pentru un articol, un laborator de cercetare sau un site de prezentare, acesta poate fi nivelul relevant și suficient.

    6.2 Interaction Readiness

    Întrebarea devine:

    Poate un agent autorizat să solicite informație sau să folosească o funcție într-un mod mai robust decât simpla interpretare vizuală a paginii?

    Aici pot intra:

    • API-uri;
    • WebMCP/site tools;
    • MCP servers;
    • formulare și endpoint-uri bine definite;
    • mecanisme de autentificare și autorizare;
    • documentație machine-readable pentru funcții.

    Nu toate site-urile au nevoie de aceste componente.

    6.3 Transaction Readiness

    Întrebarea este:

    Poate un agent, cu autorizarea necesară, să finalizeze o operațiune cu efect real?

    Exemplele pot include:

    • rezervare;
    • cumpărare;
    • programare;
    • modificarea unui document;
    • emiterea unei solicitări;
    • actualizarea unui cont.

    Acest nivel implică un risc și o responsabilitate mult mai mare. OpenAI descrie, de exemplu, riscul ca instrucțiuni ascunse în conținutul web (prompt injection) să încerce să determine un agent să transmită date sensibile printr-un URL, precum și măsurile prin care limitează acest risc.10 Dacă un simplu link poate deveni vector de exfiltrare, o operațiune cu efect real cere, în interpretarea noastră, cu atât mai mult confirmări explicite și controale de acces.

    Prin urmare:

    Information Readiness
        ↓
Interaction Readiness
        ↓
Transaction Readiness

    nu trebuie citit ca un „maturity ladder” în care orice business trebuie să ajungă la nivelul trei.

    Un site editorial poate avea nevoie doar de primul. Un serviciu de rezervări poate avea nevoie de toate trei. Pregătirea corectă este cea potrivită scopului și riscului.

    Termenii de mai sus sunt folosiți aici ca un cadru exploratoriu AI Visibility Lab, nu ca standard industrial validat.

    7. Cum măsurăm dacă un site este pregătit pentru agenți AI?

    Separând dovada de interpretare și testând fiecare capacitate printr-un mecanism observabil. Nu marcăm un site drept „agent-ready” doar pentru că are llms.txt, structured data sau un MCP endpoint.

    O matrice minimală de test poate arăta astfel:

    DimensiuneÎntrebareDovadă posibilăCe nu putem concluziona automat
    ReachabilityURL-ul răspunde tehnic?HTTP response, status, headersCă este indexat sau folosit de AI
    DiscoverabilityPoate fi descoperit prin mecanismul țintă?sitemap, link, crawler logs, documentațieCă va fi selectat într-un răspuns
    RetrievalPoate sistemul recupera informația într-un test datat?răspuns + citare + timestampCă o va recupera mereu
    UnderstandingExtrage corect entitatea și afirmațiile esențiale?test repetat și comparat cu sursaCă „înțelege” toate paginile site-ului
    Tool discoveryDescoperă instrumentele oferite?WebMCP/MCP/API testCă le va folosi în orice context
    AuthorizationPoate obține accesul permis fără bypass?flow autorizat, logsCă poate accesa date nepermise
    ActionabilityPoate finaliza operațiunea testată?rezultat verificabil și audit trailCă toate acțiunile similare vor funcționa

    Discoverability, Understanding și Actionability corespund nivelurilor cu același nume din modelul propus în primul articol. Reachability și Retrieval detaliază nivelul Accessibility, iar Tool discovery și Authorization sunt etape premergătoare nivelului Actionability, specifice site-ului.

    Lanțul metodologic rămâne cel prezentat în al doilea articol al seriei: Raw Evidence → Indexed Evidence → Observation → Measurement, iar dincolo de granița metodologică, Interpretation.

    Exemplu:

    Dacă robots.txt permite OAI-SearchBot, aceasta este o configurație tehnică observabilă. Nu este dovada că pagina este indexată, citată sau recomandată în ChatGPT.2

    Dacă site-ul expune un instrument WebMCP, avem dovada existenței unei capabilități. Nu este dovada că fiecare utilizator ChatGPT are acces la site tools, că instrumentul va fi ales automat într-un anumit task sau că alte sisteme AI îl pot folosi.3

    Dacă structured data validează corect, avem dovada conformității markup-ului cu un set de reguli. Google precizează chiar pentru propriile rich results că implementarea corectă nu garantează afișarea rezultatului îmbogățit.8

    Această disciplină este importantă deoarece piața „AI optimization” are tendința de a transforma rapid suportul tehnic într-o promisiune de vizibilitate.

    Ce poate verifica astăzi un business fără să reconstruiască site-ul?

    Mai întâi trebuie măsurat ce există deja. Înainte de API-uri noi, MCP servers sau redesign-uri, un business poate verifica dacă infrastructura actuală își îndeplinește rolul.

    Un audit minimal poate porni de la lista de mai jos; o parte din verificări se pot face și fără acces la cod, cum am arătat în ghidul de audit din exterior:

    1. paginile esențiale răspund corect și conținutul principal este disponibil fără erori majore;
    2. sitemap-ul și canonicalele descriu coerent structura site-ului;
    3. regulile pentru crawlerele relevante sunt intenționate, nu moștenite accidental;
    4. numele, adresa, serviciile, prețurile, disponibilitatea și celelalte date critice nu se contrazic între pagini;
    5. structured data, dacă este folosită, reflectă conținutul vizibil și actual;
    6. funcțiile care necesită autentificare rămân protejate;
    7. testele cu sisteme AI sunt datate și arhivate separat de configurația tehnică;
    8. eventualele instrumente pentru agenți sunt introduse numai dacă există un use case real.

    Google recomandă în continuare conținut util, fiabil, people-first și o experiență bună a paginii pentru generative AI features în Search. Acest lucru este important deoarece apariția agenților nu justifică degradarea experienței umane pentru a servi un presupus „AI format” universal.57

    Site-ul are acum două audiențe, dar nu doi stăpâni

    Metafora din titlu trebuie citită cu o limită importantă.

    Site-ul nu „își schimbă clientul” în sensul că omul încetează să conteze. Își extinde audiența tehnică. Oamenii rămân cei pentru care există business-ul, produsul, informația și tranzacția. Agenții sunt intermediari software care pot reprezenta intenția lor.

    Cloudflare numește acest fenomen „a second audience”: software care acționează în numele oamenilor și care se situează undeva între oameni și boții tradiționali.1 OpenAI descrie deja site-uri care oferă agenților instrumente directe prin WebMCP.3 MCP continuă să transforme datele și instrumentele externe într-un substrat reutilizabil pentru fluxuri agentice.4

    Asta schimbă designul întrebării, nu doar designul paginii.

    În loc de:

    Cum fac site-ul mai „AI friendly”?

    întrebarea mai precisă este:

    Ce informație și ce acțiuni vreau să fie accesibile fiecărui tip de sistem, prin ce mecanism și cu ce dovezi că funcționează?

    Aceasta este diferența dintre optimizare generică și machine accessibility măsurabilă.

    Concluzie: înainte să construim pentru agenți, trebuie să măsurăm ce pot face deja

    Site-urile au trecut deja printr-o transformare asemănătoare. Au fost construite pentru oameni, apoi au învățat să servească motoare de căutare, screen readers, aplicații mobile, API clients și nenumărate alte tipuri de software.

    Agenții AI adaugă o categorie nouă, dar nu șterg infrastructura precedentă.

    De aceea, cel mai bun punct de plecare pentru un business nu este instalarea tuturor standardelor emergente. Este identificarea traseelor care contează pentru propriul model operațional:

    Information
    ↓
Can it be found?
    ↓
Can it be accessed?
    ↓
Can it be interpreted correctly?
    ↓
Does the user need an action?
    ↓
If yes: can the authorized agent execute it safely?

    Înainte să construim site-uri pentru agenți AI, trebuie să demonstrăm ce pot face agenții cu site-urile pe care le avem deja.

    Pentru AI Visibility Lab, acesta este pasul următor: să transformăm ideea de agent readiness dintr-un concept general într-un set de observații și măsurători reproductibile, fără să confundăm accesibilitatea tehnică cu citarea, recomandarea sau performanța comercială.

    În articolul următor vom urmări ce se întâmplă după ce un sistem AI găsește și înțelege un business: „De la menționare la tranzacție: ce înseamnă Agentic Visibility pentru un business.”

    Seria „Machine accessibility și agentic web”

    1. De la web visibility la machine accessibility
    2. Public nu mai înseamnă accesibil: de ce fiecare sistem AI vede un internet diferit
    3. Site-ul nu dispare. Își schimbă clientul (acest articol)
    4. De la menționare la tranzacție: ce înseamnă Agentic Visibility
    5. Social media devine strat informațional pentru AI

    Surse și metodologie

    1. Cloudflare, The Internet has a second audience, 30 septembrie 2026. Sursa raportează date observate în rețeaua Cloudflare; acestea nu sunt tratate în articol ca măsurătoare exhaustivă a întregului internet. blog.cloudflare.com/agentic-web/
    2. OpenAI, Overview of OpenAI Crawlers, documentație oficială, consultată la 1 octombrie 2026. Documentația diferențiază OAI-SearchBot, GPTBot și ChatGPT-User și precizează rolurile lor distincte. developers.openai.com/api/docs/bots
    3. OpenAI Help Center, Using site tools in the ChatGPT desktop app, consultat prin indexul de căutare la 1 octombrie 2026 (pagina blochează accesul automat). Pagina descrie site tools și WebMCP ca standard web propus. help.openai.com/en/articles/20001423-using-site-tools-in-the-chatgpt-desktop-app
    4. Model Context Protocol, The 2026-07-28 Specification, 28 iulie 2026. Sursă oficială a proiectului MCP. blog.modelcontextprotocol.io/posts/2026-07-28/
    5. Google Search Central, AI Features and Your Website, documentație oficială, consultată la 1 octombrie 2026. Pagina precizează că pentru AI Overviews și AI Mode se aplică aceleași cerințe fundamentale Search și că îndeplinirea lor nu garantează crawling, indexare sau afișare. developers.google.com/search/docs/appearance/ai-features
    6. Cloudflare, Bot reference — AI Crawl Control, documentație oficială, consultată la 1 octombrie 2026. Documentația clasifică roboți precum GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot și alții în categorii funcționale distincte. developers.cloudflare.com/ai-crawl-control/reference/bots/
    7. Google Search Central, Optimizing your website for generative AI features on Google Search, documentație oficială, consultată la 1 octombrie 2026. Google precizează că llms.txt nu influențează vizibilitatea sau ranking-ul în Google Search și că nu este necesar un markup schema.org special pentru generative AI search. developers.google.com/search/docs/fundamentals/ai-optimization-guide
    8. Google Search Central, General Structured Data Guidelines, documentație oficială, consultată la 1 octombrie 2026. Google precizează că structured data trebuie să fie reprezentativă pentru conținutul vizibil și că implementarea corectă nu garantează apariția unui rich result. developers.google.com/search/docs/appearance/structured-data/sd-policies
    9. Cloudflare, Introducing the Agent Readiness score. Check to see if your site is agent-ready, 17 aprilie 2026, actualizat la 15 iulie 2026. Instrumentul este un cadru Cloudflare; articolul de față nu îl tratează ca standard universal. blog.cloudflare.com/agent-readiness/
    10. OpenAI, Keeping your data safe when an AI agent clicks a link, 28 ianuarie 2026 (pagina blochează accesul automat; conținutul a fost confirmat la 1 octombrie 2026 prin indexul de căutare). Pagina descrie riscuri asociate agenților care accesează conținut web, inclusiv exfiltrarea datelor și necesitatea măsurilor de siguranță. openai.com/index/ai-agent-link-safety/

    Notă metodologică AI Visibility Lab

    Acest articol distinge între capabilități documentate, configurații tehnice observabile, teste efectuate și interpretări. Nicio setare izolată — robots.txt, sitemap, structured data, llms.txt, WebMCP, MCP sau API — nu este prezentată ca dovadă suficientă că un business va fi citat, menționat, recomandat sau preferat de un sistem AI.

    Termenii Information Readiness, Interaction Readiness și Transaction Readiness sunt utilizați aici ca un cadru exploratoriu AI Visibility Lab pentru separarea tipurilor de acces. Nu sunt prezentați ca standarde oficiale, niveluri de maturitate recunoscute sau cerințe obligatorii pentru toate site-urile.

    Expresia agent-ready este deja folosită public de Cloudflare și de alte proiecte din ecosistemul agentic; AI Visibility Lab nu revendică originea termenului. Cadrul propriu introdus în acest articol constă în delimitarea operațională a celor trei tipuri de readiness și în integrarea lor în lanțul metodologic Raw Evidence → Indexed Evidence → Observation → Measurement → Interpretation.

    Notă de volatilitate

    WebMCP este un standard propus, MCP își schimbă specificația periodic, iar disponibilitatea site tools în ChatGPT, categoriile de boți din Cloudflare și criteriile Agent Readiness pot fi diferite la data lecturii. Afirmațiile despre produse și specificații au fost verificate la 1 octombrie 2026.

    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: 1 octombrie 2026.