De ce nu-ți poate citi ChatGPT site-ul: 79% blocați
Fișierul care spune roboților ce au voie era complet permisiv. Cu toate astea, 79% din cererile crawlerelor AI către cittago.com erau respinse, în timp ce Googlebot trecea aproape de fiecare dată. Am găsit cauza pe propriul nostru site, cu propriile log-uri.
Ce s-a întâmplat. Ne-am uitat, din curiozitate, câte cereri ale crawlerelor AI ajung efectiv pe cittago.com. Răspunsul: mai puțin de una din cinci. Restul primeau 403, adică ușa în nas.
De ce nu-i pentru toată lumea. Dacă site-ul tău nu stă în spatele unui firewall configurat de cineva, cândva, probabil n-ai problema asta. Dacă stă — și majoritatea site-urilor de firmă stau — merită jumătate de oră.
Ce câștigi din lectură. Nimeni nu bifase „blochează AI-urile". Blocajul a apărut din suprapunerea a două decizii de securitate rezonabile, luate separat, la ani distanță. Exact de asta e greu de găsit.
- Cifra pe care o poți verifica diseară la tine: câte din cererile roboților AI primesc conținut și câte primesc 403.
- De ce panoul de control îți arată verde peste tot în timp ce ușa e închisă.
- Un tip de blocaj care se raportează ca succes — HTTP 200 — și se vede doar dacă numeri octeții.
- Ce am schimbat concret în firewall și cât a scăzut blocajul, măsurat la 15 ore după.
Lucrăm cu Cloudflare de ani de zile. Îl punem în fața site-urilor pe care le construim, îl configurăm pentru clienți, avem o pagină de serviciu despre asta. Și tot noi am descoperit, pe 5 august, că propriul nostru site respingea patru din cinci cereri venite de la roboții asistenților AI.
Nu e o poveste despre incompetență. E o poveste despre cum arată o problemă care nu apare în niciun panou de control.
A început banal. Primul articol de pe site-ul nou, GEO față de SEO, a apărut pe 12 iulie; munca serioasă pe conținut, construit pentru căutare și pentru asistenții AI, a început pe 27 iulie. De atunci scriem săptămânal despre vizibilitatea în asistenții AI. Și tot de atunci observam ceva ciudat în felul în care lucram: când dădeam unui AI linkul unui articol proaspăt de-al nostru și îi ceream o părere, patru din cinci nu puteau deschide pagina. Ni se părea o ciudățenie de-a lor. Am notat-o și am mers mai departe.
Pe 5 august ne-am uitat în log-uri în loc să presupunem. Ciudățenia era la noi.
Ce înseamnă, de fapt, „crawler AI blocat"
Un crawler AI este programul cu care un asistent — ChatGPT, Perplexity, Claude, Gemini — citește pagini de pe internet, fie ca să învețe din ele, fie ca să răspundă acum, în timp real, la întrebarea unui om. Dacă serverul tău îi răspunde cu 403, asistentul nu are ce cita: pentru el, pagina ta nu există.
Distincția care contează e între cele două feluri de roboți. Unii adună text pentru antrenament, și pe ăia poți avea motive întemeiate să-i ții afară. Alții intră pe pagină în secunda în care cineva pune o întrebare despre domeniul tău. Al doilea fel e literalmente un client care sună la ușă.
ChatGPT-User nu e crawler de antrenament. E fetcher-ul live: intră pe pagina ta în momentul în care un utilizator ChatGPT pune o întrebare la care pagina ta ar putea răspunde. La noi, 92% din cererile lui primeau 403.
79% față de 1%, pe același site, în aceeași zi
Cifrele de mai jos vin din API-ul de analytics al Cloudflare, pe o fereastră de 23 de ore încheiată pe 5 august la 17:21 UTC. Pe planul gratuit datele se păstrează 24 de ore, deci fereastra asta nu mai poate fi extrasă din nou. Am salvat-o.
| Crawler | Cereri | Oprit de Cloudflare | Oprit de server | A primit pagina | Blocat |
|---|---|---|---|---|---|
| Amazonbot | 228 | 228 | 0 | 0 | 100% |
| ChatGPT-User | 191 | 157 | 18 | 16 | 92% |
| PerplexityBot | 129 | 50 | 0 | 78 | 39% |
| GPTBot | 96 | 53 | 4 | 36 | 59% |
| ClaudeBot | 82 | 0 | 56 | 26 | 68% |
| OAI-SearchBot | 69 | 49 | 8 | 11 | 83% |
| Google-Extended | 58 | 58 | 0 | 0 | 100% |
| Total AI | 910 | 610 | 106 | 185 | 79% |
| Googlebot | 79 | 1 | 0 | 62 | 1% |
| bingbot | 30 | 0 | 0 | 25 | 0% |
Sursa: API-ul GraphQL de analytics al Cloudflare, zona cittago.com, 4 august 18:21 – 5 august 17:21 UTC. Tabelul conține crawlerele cu peste 50 de cereri, plus grupul de control; diferența până la total vine din crawlerele mici. Pe fiecare rând, ce lipsește din sumă sunt cereri încheiate cu alte coduri — redirecturi, timeout-uri.
Contrastul e miezul poveștii. Aceeași infrastructură, aceeași zi, același site: motoarele de căutare clasice trec, roboții asistenților AI sunt tratați ca trafic ostil.
Nu aveam o setare „blochează AI". Aveam o regulă anti-spam scrisă cu ani în urmă, care s-a nimerit să taie exact populația greșită.
De ce nu vezi problema când o cauți
Am verificat, înainte, exact locurile în care s-ar uita oricine.
Fișierul robots.txt era impecabil. Permisiune explicită pentru GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended. Scria negru pe alb „intrați". Numai că robots.txt e o notă de bună purtare, nu o cheie. Îi spui robotului ce ai vrea să facă. Ce se întâmplă efectiv la ușă decide firewall-ul.
Setările generale erau blânde. Nivelul de securitate era pe „practic dezactivat", verificarea de browser era oprită, firewall-ul gestionat era oprit. Nimic agresiv. Dacă te uitai la configurație, arăta ca un site care nu blochează pe nimeni.
Panoul dedicat crawlerelor AI arăta „permis" peste tot. Și aici e partea pe care merită s-o reții, pentru că e documentată chiar de Cloudflare: regulile scrise de tine se evaluează înaintea panoului de control al crawlerelor AI, iar blocările lor nu apar în statisticile acelui panou. Deci panoul spune adevărul despre el însuși și minte despre realitate. Cererea a fost deja tăiată, mai devreme, de altcineva.
Sunt două uși, nu una
Aici povestea devine mai interesantă decât ne așteptam. Blocajul nu venea dintr-un loc, ci din două, complet independente.
Prima ușă e Cloudflare, care stă în fața site-ului și oprește cererile înainte să atingă serverul. A doua ușă e serverul însuși, care are propriul lui filtru de securitate, pus de furnizorul de hosting, cu propriile lui reguli. Cine trece de prima nu a intrat încă.
Dovada că sunt două uși e cel mai frumos accident din toate datele. Zona noastră avea, din alte motive, o excepție pentru un singur crawler: ClaudeBot. Deci avem în date un experiment natural — un robot cu permis special, restul fără.
ClaudeBot a trecut de Cloudflare de 82 de ori din 82. Și a luat 403 de la server în 56 din cele 82 de cazuri.
Dacă repari doar firewall-ul din față și te oprești acolo, ai făcut jumătate de treabă și n-ai cum să știi. Verificarea trebuie să distingă între „oprit la Cloudflare" și „oprit la server" — sunt două cifre diferite, cu două soluții diferite.
Crawlerele AI ies din Singapore
Regula vinovată pentru prima ușă era o singură linie, scrisă cu ani în urmă împotriva unui val de spam: blochează traficul care vine din Africa, Asia, Oceania și din rețeaua Tor. Atât. Nimic despre AI, nimic despre roboți.
Ea a produs 815 din cele 940 de blocări ale zonei în fereastra măsurată. Adică 87%.
Iar distribuția pe țări explică totul: 630 de blocări din Singapore, 43 din Australia, 25 din China, 24 din India, 23 din Turcia, 15 din Vietnam. Infrastructura marilor furnizori de AI iese masiv prin Singapore. O regulă geografică scrisă în alt deceniu al internetului, împotriva altei probleme, a nimerit exact populația pe care astăzi vrei s-o primești.
Nu e o greșeală de configurare. E o regulă care a îmbătrânit. Diferența contează, pentru că a doua se întâmplă tuturor.
Ce-ți trebuie
Ca să verifici la tine ai nevoie de patru lucruri
- Acces la panoul furnizorului tău de CDN sau firewall — la Cloudflare, secțiunea de securitate și lista de reguli scrise de tine.
- Statistici care separă edge de origine, adică ce a fost oprit în fața site-ului și ce a fost oprit de server. Fără distincția asta repari pe ghicite.
- Cineva care poate umbla la server, sau un furnizor de hosting căruia îi poți deschide un tichet. A doua ușă nu e la tine în panou.
- O pagină de test cu un cod pe care nimeni nu-l poate ghici. Explicăm mai jos de ce e obligatorie.
Fixul: nu deschizi poarta, ceri legitimația
Soluția evidentă ar fi: fac o excepție pentru toate numele de roboți AI și gata. E și soluția greșită, dintr-un motiv pe care l-am avut sub ochi chiar în timp ce lucram.
Numele pe care îl declară un robot — User-Agent-ul — e un șir de text pe care oricine îl poate scrie. Se falsifică în două secunde.
În log-urile din timpul auditului apar cereri care se prezentau drept PerplexityBot, OAI-SearchBot și ChatGPT-User și care căutau fișiere de parole: /.env, chei SSH, credențiale de cloud, configurații de Kubernetes. Toate au primit 403. Nu era niciun asistent AI. Era un scanner care se dădea drept unul, în timp real, exact în fereastra în care noi măsuram roboții adevărați.
De asta regula pe care am scris-o nu se uită la nume. Se uită la bot verificat criptografic — condiția prin care Cloudflare confirmă, pe baza adresei IP, că robotul e cu adevărat cine spune că e. Numele singur nu deschide nimic.
Concret, am lărgit o regulă care exista deja, în loc să adăugăm una nouă peste ea. Regula lasă să treacă roboții verificați ai asistenților AI și motoarelor de căutare, și păstrează blocajul geografic intact pentru traficul uman și pentru scraperele neverificate. Câțiva roboți rămân blocați intenționat — cei care adună conținut fără să trimită nimic înapoi.
Modificarea a intrat pe 5 august, la 17:33 UTC.
Blocajul care se raportează ca succes
Un unghi pe care noi îl considerăm important în articolul ăsta: nu toate blocajele arată ca blocaje.
Codul 403 e cinstit. Îl vezi, îl numeri, știi ce ai de făcut. Problema e celălalt fel de refuz: serverul răspunde 200 OK și trimite un ecran de verificare în loc de pagină. În orice statistică normală, asta e un succes. Robotul a cerut, robotul a primit, cod 200, toată lumea fericită.
Numai că robotul a primit un ecran de încărcare, nu conținut.
Singurul mod de a vedea diferența e să numeri octeții.
| Ce primește robotul | Mărime | Cod HTTP |
|---|---|---|
| Pagina reală | 50.000 – 58.000 octeți | 200 |
| Ecran de verificare | ~6.000 octeți | 200 |
| Refuz direct | 1.100 – 1.500 octeți | 403 |
Măsurători pe cittago.com, 5–6 august 2026. Rândul din mijloc e cel care nu apare nicăieri ca problemă.
Pe 6 august, un fetcher ChatGPT venit din Elveția a cerut pagina noastră de servicii Google Ads și a primit 6.064 de octeți. Pagina reală are 54.801. Codul a fost 200. Din exterior, o citire reușită.
Testul
Ce spun AI-urile față de ce arată log-urile
Aici e capcana în care intră oricine încearcă să verifice singur: întrebi un AI dacă îți poate citi site-ul, iar el îți răspunde ce crede el că s-a întâmplat. Uneori greșește în ambele direcții.
Ca să scoatem părerea din ecuație, am construit o pagină de test. E publică, dar nu e legată de nicăieri și nu e în sitemap: cittago.com/ai-access-test/. Conține un cod la începutul paginii, un al doilea cod la sfârșit, un cuvânt-cheie la mijloc și trei numere într-un tabel. Suma celor trei numere nu e scrisă nicăieri — trebuie calculată.
Un model nu poate reproduce toate patru decât dacă a citit efectiv pagina. Codurile sunt aleatorii și pagina nu există în niciun index, deci nu pot veni din memorie. Apoi am citit în log-uri ce a primit fiecare, măsurat în octeți. Declarația modelului și log-ul stau față în față.
Perplexity: conținutul corect, fără să fi descărcat nimic
I-am cerut să citească prima pagină a site-ului. A întors titlul exact, toate cele cinci cifre din secțiunea de sus, ambele proiecte listate. Corect, cap-coadă. A încheiat cu o propoziție despre cum a obținut conținutul:
„Am descărcat pagina acum."
Log Cloudflare, aceeași fereastră: PerplexityBot → 403 pe /. 1.133 octeți trimiși. Nicio descărcare.
Conținutul era corect pentru că îl avea deja în indexul propriu, din vizite mai vechi. Iar pe o pagină pe care indexul nu o avea, a raportat cinstit că nu poate lua conținutul.
Gemini: a citit pagina, dar a răspuns dintr-o copie veche
A trecut testul: a dat toate cele patru valori, inclusiv suma pe care trebuia s-o calculeze singur. Log-ul confirmă — a primit 54.801 octeți, adică pagina întreagă.
Apoi, la o întrebare despre proiectele noastre recente, a numit un proiect care nu mai e afișat acolo de câteva zile.
Ce înseamnă: A citit pagina reală, dar a răspuns dintr-o copie mai veche decât pagina live. Accesul reușit nu garantează un răspuns actualizat.
Acces confirmat
Grok: singurul care a trecut curat, de fiecare dată
Toate cele patru valori, inclusiv suma calculată din tabel, plus data tipărită pe pagină. Repetat, pe două pagini diferite, în două zile.
Observație tehnică: Nici Grok, nici Gemini n-au raportat codul-momeală ascuns în sursa HTML, vizibil doar în cod, nu la randare. Deci amândoi citesc textul randat, nu fișierul brut.
Acces confirmat
ChatGPT: două motive diferite, ușor de confundat
Pe pagina de test a răspuns că nu are acces. Log-ul arată însă că nu a existat nicio cerere către acea adresă. Nu a fost blocat: pur și simplu nu descarcă un URL pe care nu-l are deja în index, iar pagina era nouă și nelegată de nicăieri.
Pe o pagină indexată, în schimb, cererea a existat — și a primit 6.064 octeți în loc de 54.801. Ecranul de verificare, cu cod 200.
De ce contează distincția: „Nu găsesc pagina" și „am fost oprit la ușă" arată identic din exterior. Doar log-ul le separă.
Dacă te iei după ce-ți spune AI-ul despre accesul la site-ul tău, tragi concluzii greșite în ambele direcții. Unul spune „am citit" fără să fi cerut. Altul spune „nu pot" când de fapt nu te caută.
Ce s-a schimbat după reparație
Am re-măsurat pe 6 august, cu aceeași metodă, pe fereastra de după modificare: 5 august ora 18:00 UTC → 6 august ora 8:35 UTC. Sunt aproape cincisprezece ore de trafic real, nu teste de-ale noastre.
| Prima ușă | Înainte (23 h) | După fix (14,5 h) |
|---|---|---|
| Cereri ale crawlerelor AI | 910 | 583 |
| Oprite de Cloudflare | 610 | 12 |
| Procent oprit la Cloudflare | 67% | 2% |
Sursa: API-ul de analytics Cloudflare, zona cittago.com. Ferestrele diferă ca lungime, deci comparația validă e pe procente, nu pe cifre absolute.
Prima ușă e rezolvată, și se vede în cifre: de la 67% la 2%. Cele douăsprezece blocări rămase sunt roboții pe care îi ținem afară intenționat — cei care adună conținut fără să trimită nimic înapoi.
Ce merită reținut din cifra asta nu e mărimea salturi, ci că a fost măsurabilă în cincisprezece ore. O modificare de o linie într-o regulă de firewall, iar a doua zi dimineață știi dacă a funcționat sau nu. Puține lucruri din SEO îți dau un răspuns atât de repede.
Ce nu spun cifrele astea
| Ce am măsurat | Ce nu putem afirma |
|---|---|
| Un site, două ferestre scurte | Nu e un studiu. E un caz, al nostru, cu datele la vedere. |
| Cereri blocate | Nu știm câte citări în asistenți AI am pierdut. Nimeni nu publică cifra asta. |
| Ferestre de 23 h și 14,5 h | Traficul roboților vine în valuri. O oră cu un crawler agresiv mișcă procentele. |
| Regula geografică | Nu spunem că e greșită. Blochează în continuare trafic uman nedorit, și rămâne activă. |
Cum verifici la tine, în douăzeci de minute
- Deschide statisticile de securitate ale furnizorului din fața site-ului și filtrează după numele roboților AI: GPTBot, ChatGPT-User, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended, Applebot.
- Uită-te la regulile scrise de tine, nu la setările generale. Blocajele geografice și listele de țări sunt suspecții principali, mai ales cele scrise cu ani în urmă.
- Separă cele două uși. Dacă o cerere a fost oprită înainte să ajungă la server, o rezolvi din panoul tău. Dacă a ajuns la server și a primit 403 acolo, se rezolvă pe server — singur, dacă îl administrezi, sau printr-un tichet la furnizorul de hosting.
- Numără octeții, nu codurile. Un răspuns de 200 cu 6.000 de octeți în loc de 50.000 e un blocaj deghizat în succes.
- Fă-ți pagina de test. Un cod aleatoriu sus, altul jos, un cuvânt la mijloc, trei numere de adunat. Apoi cere-i unui asistent să le raporteze exact și verifică în log ce a primit. Cinci minute de construit, și e singura probă care nu se contrazice.
Un singur avertisment, din experiență proprie: dacă testezi de pe propriul server sau de pe o adresă pusă pe listă albă, primești 200 indiferent ce nume de robot folosești. Rezultatul e frumos și nu înseamnă nimic. Singura măsurătoare care contează e traficul roboților adevărați, citit din log-uri.
Unde ești tu, în trei praguri
Dacă n-ai firewall în fața site-ului și nici filtru de securitate pe server, probabil n-ai problema asta. Verifică totuși o dată; „probabil" nu e o măsurătoare.
Dacă ai firewall și n-ai deschis niciodată statisticile pe roboți AI, ești exact unde eram noi pe 4 august. Nu înseamnă că ești blocat — înseamnă că nu știi, iar asta se rezolvă în douăzeci de minute.
Dacă ai verificat și găsești blocaje, repară-le în ordinea corectă: întâi ușa din față, unde ai control, apoi pe serverul tău. Dacă partea de server e prea complicată pentru tine, deschide un tichet de suport la furnizorul tău de hosting. Și re-măsoară după fiecare pas, altfel nu ai cum să știi care dintre ele a contat.
La noi, prima ușă e rezolvată în întregime și verificată în cifre. La a doua am făcut progrese mari, și în zilele următoare o aducem exact unde ne-o dorim. Mai discutăm despre asta peste 3–6 luni 😉
Întrebări
Întrebări pe care nu ni le-a pus nimeni
Suntem la o zi de la măsurătoare, deci nu, nu ne-a întrebat nimeni nimic. Sunt întrebările pe care le-ar avea un cititor, plus cele care apar oricum în discuțiile reale cu clienții despre vizibilitate în AI.
Cum îmi dau seama, fără cont tehnic, dacă am problema asta?
Cel mai rapid semn: dai unui asistent AI linkul unei pagini de-ale tale și îi ceri să-ți spună ce scrie în ea. Dacă îți răspunde cu generalități despre firma ta, dar nu poate cita o propoziție anume, probabil n-a deschis pagina.
E un indiciu, nu o probă. Proba e în log-uri, și pentru ea îți trebuie cineva cu acces la panoul de securitate.
Dacă am robots.txt permisiv, nu e de ajuns?
Nu. robots.txt e o instrucțiune de bunăvoie pentru roboții care aleg s-o respecte. Firewall-ul e o ușă. Poți avea scris „intrați liber" pe un perete și ușa încuiată la doi metri mai încolo — exact asta aveam noi.
Chiar contează dacă un asistent AI îmi citește sau nu site-ul?
Contează dacă vrei să fii propus ca soluție când cineva întreabă un asistent. Un model nu poate cita o pagină pe care nu o poate citi, iar cei care răspund în timp real, în momentul întrebării, sunt exact cei blocați cel mai des la noi.
Am scris separat despre distanța dintre a fi găsit și a fi recomandat, în cum ajungi să fii citat de căutarea AI.
De ce Googlebot trecea și ceilalți nu?
Din geografie, nu din favoritism. Googlebot crawlează masiv din centre de date din Statele Unite și din Europa, iar regula noastră bloca alte continente. Infrastructura furnizorilor de AI iese în bună parte prin Singapore, care intra fix în regulă.
Aceeași regulă, două rezultate opuse, dintr-un motiv care n-are legătură cu conținutul.
Nu e periculos să las roboții AI să intre?
Depinde ce fel de robot și ce fel de site. Cei care citesc ca să răspundă acum, la o întrebare, sunt trafic pe care în general îl vrei. Cei care adună masiv text pentru antrenament sunt o decizie de business, nu una tehnică — există motive legitime să-i ții afară.
Ce nu e o soluție e să lași pe cineva să intre pe baza numelui pe care și-l declară. Numele se falsifică; verificarea pe adresă IP, nu.
Cât m-ar costa să repar asta?
Prima ușă e o modificare de reguli în panoul tău de firewall: se face într-o oră dacă știi ce cauți, și nu costă nimic în plan de abonament — noi suntem pe planul gratuit Cloudflare.
A doua ușă ține de server. Dacă îl administrezi singur, e tot o chestiune de reguli; dacă nu, o rezolvă furnizorul de hosting. La noi, partea principală e închisă, iar în zilele următoare mai facem câteva ajustări fine.
Cum știu că nu se strică altceva când modific regula?
Salvează configurația actuală înainte, ca să poți reveni. Apoi lărgește o regulă existentă în loc să adaugi una nouă peste ea — regulile se evaluează în ordine, iar o regulă nouă pusă greșit poate anula alta.
Și lasă blocajele care apără traficul uman în picioare. Nu deschizi tot, faci o excepție îngustă pentru roboții verificați.
De ce nu se vede blocajul în panoul dedicat crawlerelor AI?
Pentru că regulile scrise de tine se evaluează înaintea acelui panou, iar ce taie ele nu apare în statisticile lui. E documentat de Cloudflare, dar e ușor de ratat.
Consecința practică: panoul poate arăta „permis" pentru toate crawlerele în timp ce zero dintre ele ajung pe site.
Cum arată un blocaj cu cod 200?
Serverul răspunde că totul e în regulă și trimite un ecran de verificare, de câteva mii de octeți, în loc de pagina reală de câteva zeci de mii. Pentru un om e o secundă de așteptare; pentru un robot, ăla e conținutul tău.
Se prinde numai comparând mărimea răspunsului cu mărimea paginii adevărate. Codul HTTP nu-ți spune nimic aici.
Merită să pun o pagină de test permanentă?
Da, și e cel mai ieftin instrument din toată povestea. Un cod aleatoriu la începutul paginii, altul la sfârșit, trei numere de adunat. Dacă un model îți dă toate valorile, a citit; dacă nu, ai un motiv concret de căutat.
A noastră rămâne publică, la cittago.com/ai-access-test/. Poți să-ți faci una identică în cinci minute.
Ultima actualizare: 6 august 2026. Cifrele vin din API-ul GraphQL de analytics al Cloudflare, zona cittago.com, ferestre încheiate pe 5 august la 17:21 UTC și pe 6 august la 8:35 UTC; datele brute sunt salvate, pentru că pe planul gratuit se păstrează 24 de ore. Modificarea regulii a intrat pe 5 august, 17:33 UTC, iar efectul ei e verificat pe fereastra de după. Actualizăm pagina când se schimbă starea.
