Ai configurat llms.txt, ai optimizat meta tag-urile, ai construit intern link-uri. Faci tot ce trebuie pentru ca ChatGPT, Perplexity şi Claude să citeze site-ul tău. Şi totuşi, în tabloul de bord, ai zero apariții în AI. Nu un scor mic — zero absolut.
Înainte să cauți o problemă de conținut sau de autoritate, verifică un lucru pe care probabil nu l-ai bănuit: hosting-ul tău poate bloca în tăcere roboții AI — fără să-ți spună, fără să apară în log-urile tale, fără niciun avertisment.
O investigație recentă publicată pe Search Engine Land a arătat exact asta. Şi dacă site-ul tău rulează pe un hosting WordPress administrat, merită să ştii cum să verifici dacă pățeşti acelaşi lucru.
De ce roboții AI nu sunt ca Googlebot
Googlebot trimite câteva cereri, indexează pagina, şi pleacă. Raportul e decent: aproximativ 5 cereri de crawl pentru fiecare vizită pe care o generează. Roboții AI de antrenament funcționează diferit. ClaudeBot (Anthropic) generează în medie 20.583 de cereri de crawl pentru fiecare referință pe care o trimite înapoi. GPTBot face 1.255 de cereri per referință.
Infrastructura de hosting a observat această diferență. Şi unele platforme au început să răspundă automat. Nu neapărat din rea-voință față de tine — ci pentru a proteja serverele de volume masive de trafic bot. Problema: decizia se ia la nivel de platformă, fără să fii consultat.
Gândeşte-te ca la un filtru de spam agresiv care blochează şi mesajele importante. Intenția e bună. Efectul pentru tine poate fi dezastruos dacă vizibilitatea în AI search e un obiectiv real.
Ce s-a descoperit: un studiu de caz concret
Investigația analizată pe Search Engine Land pornea de la o anomalie clară. Un site aprea în răspunsurile Google AI Mode în proporție de 37,8% — dar Claude îl cita în proporție de 0,0%. Meta AI: 0,0%. Perplexity: 7,8%. Toate platformele citesc acelaşi conținut, deci calitatea nu explică diferența.
Datele Cloudflare din 7 zile au arătat tabloul complet. Din 29.099 de cereri bot, 65,8% veneau de la roboți AI. Procentul blocat pe bot:
| Robot AI | Procent blocat | Mecanism |
|---|---|---|
| ClaudeBot (Anthropic) | 29% | HTTP 429 (prea multe cereri) |
| GPTBot (OpenAI) | 29% | HTTP 429 |
| Amazonbot | 51% | HTTP 429 |
| Bytespider | 61% | HTTP 403/5xx (blocat complet) |
| ChatGPT-User | 0% | Nelimitat |
| PerplexityBot | 0% | Nelimitat |
Roboții de antrenament sunt throttled; roboții de răspuns în timp real nu sunt. ChatGPT-User şi PerplexityBot răspund cereri ale utilizatorilor live — ca nişte asistenți care fac o singură căutare la comandă. ClaudeBot şi GPTBot aspiră întreg site-ul ca să construiască baze de date de antrenament — un cu totul alt comportament.
Vinovatul ascuns: platforma de hosting, nu plugin-ul tău de securitate
Investigatorul a eliminat pe rând: plugin-ul de securitate Solid Security, WAF-ul Sucuri, Cloudflare propriu. Niciunul nu era sursa blocajului. Răspunsul s-a văzut abia la un simplu curl -I: headerul x-powered-by: WP Engine. Blocajul venea de la platforma de hosting în sine, dintr-un strat pe care clientul nici nu îl vede.
WP Engine a confirmat în suport: „WP Engine aplică rate limiting la nivel de platformă pe anumiți roboți cu impact mare, pentru a proteja performanța serverelor, şi această parte nu poate fi dezactivată selectiv per bot.”
Traducere practică: dacă eşti pe WP Engine, nu există setare în panoul tău care să schimbe asta. Blocajul nu apare în log-urile tale Cloudflare, nici în log-urile plugin-urilor de securitate. Este invizibil pentru orice audit standard.
Cum să verifici dacă site-ul tău are aceeaşi problemă
Nu ai nevoie de acces root sau de tool-uri speciale. Ai nevoie de trei minute şi de un terminal (sau poți ruga un developer să ruleze comanda).
Pasul 1: Rulează 30 de cereri simulate cu UA-ul ClaudeBot:
for i in $(seq 1 30); do
curl -sI -A "ClaudeBot/1.0 (+https://www.anthropic.com/claudebot)"
"https://domeniultau.ro/"
-o /dev/null -w "%{http_code}n"
sleep 0.05
done | sort | uniq -cPasul 2: Repetă comanda cu un UA de browser normal (Mozilla/5.0). Dacă browserul primeşte 200 şi ClaudeBot primeşte 429, blocajul există şi e bazat pe user-agent.
Pasul 3: Verifică headerele răspunsului pentru x-powered-by sau server. Dacă apare WP Engine, eşti în scenariul descris mai sus.
Ce face WP Engine diferit față de alte hosturi managed
Nu toate platformele managed WordPress funcționează la fel. Datele publice arată o diferență clară:
| Hosting | Blochează roboții AI? | Controlabil de client? |
|---|---|---|
| WP Engine | Da, by default | Nu (necesită escaladare la ProdEng) |
| Kinsta | Nu by default | Da (4 niveluri opt-in) |
| Pressable | Nu by default | Da (prin robots.txt) |
| Pantheon | Nu | N/A |
| SiteGround | Da, by default (roboți de antrenament) | Parțial (mai transparent) |
WP Engine pare să fie singurul host major care aplică un bloc de platformă activ by default, fără o setare de client pentru a-l opri. Interesant: Flywheel, deținut tot de WP Engine din 2019, nu are o astfel de politică documentată. Nu e o decizie corporativă — e o decizie specifică produsului WP Engine.
De ce blocajul este atât de greu de detectat
Codul de răspuns HTTP 429 („prea multe cereri”) este cheia camuflajului. Un 403 („interzis”) ar ridica imediat semne de întrebare în Google Search Console. Un 429 apare în analizele WAF ca o problemă de rate limiting — şi toți te trimit să cauți configurări de rate limiting la nivelul plugin-urilor, care nu au nicio problemă.
În plus, blocajul se activează sub nivelul plugin-urilor tale de securitate. Wordfence, Sucuri, Solid Security — toate loghează la nivelul aplicației WordPress. WP Engine blochează la edge-ul platformei, înainte ca cererea să ajungă la WordPress. Log-urile tale sunt curate pentru că cererea nici nu ajunge la WordPress.
Mai există o ciudatănie: cache-ul funcționează normal. Dacă pagina e cache-uită la edge, ClaudeBot primeşte un 200 (HIT din cache). Dacă nu e în cache, primeşte 429. Acelaşi URL, acelaşi bot, două rezultate — asta face diagnosticarea şi mai confuză.
Impactul real: corelația dintre acces şi citare
Datele din studiul de caz arată o corelație directă între accesul crawlerului şi prezența în răspunsurile AI:
- Googlebot ~100% acces → Google AI Mode 37,8% prezență în citări
- PerplexityBot 100% acces → Perplexity 7,8% prezență
- GPTBot 54% acces → ChatGPT 9,6% prezență
- ClaudeBot 57% acces (dar mai ales cache-hits) → Claude 0,0% prezență
Concluzia e simplă: accesul crawlerului este podeaua. Calitatea conținutului este plafonul. Poți scrie cel mai bun conținut din nişa ta, poți configura perfect optimizarea SEO şi optimizarea de performanță, dar dacă robotul nu poate citi site-ul, plafonul nu contează.
Ce poți face dacă eşti afectat
1. Escaladare la suportul hostului. WP Engine are o cale de escaladare la echipa Product Engineering pentru cazuri speciale. Formularea corectă: „Am reprodus prin curl că cererile cu user-agent ClaudeBot/GPTBot primesc HTTP 429 pentru cache-miss. Cloudflare şi plugin-urile noastre de securitate nu sunt sursa. Este vorba despre rate limiting la nivel de platformă WP Engine? Poate fi dezactivat sau configurat per-bot?”
2. Migrare la un host care lasă decizia la tine. Kinsta, Pressable şi Pantheon oferă control explicit clientului. Dacă vizibilitatea în AI search e o prioritate strategică, costul migrării trebuie comparat cu costul absenței din citările AI. Mulți clienți cer astăzi website de prezentare cu focus pe AI search — alegerea hostului contează.
3. Completarea optimizărilor pe care le controlezi. Dacă hosting-ul tău nu are acest blocaj (sau l-ai rezolvat), asigură-te că faci tot restul corect: SEO tehnic solid, schema markup complet, llms.txt configurat, conținut structurat şi autoritar. Acces complet + conținut bun = citare maximă.
4. Acceptarea conştientă a blocajului. Dacă ai motive să vrei să rămâi în afara datelor de antrenament AI, asta e o decizie validă. Important: documenteaz-o intern şi nu mai rula audituri de vizibilitate AI care nu pot da rezultate bune prin construcție.
Dacă ai nevoie de ajutor să verifici starea site-ului tău sau să optimizezi configurarea pentru AI search, programează o discuție gratuită — evaluăm împreună situația şi îți spunem ce acțiuni au sens concret pentru afacerea ta.
Întrebări frecvente despre WordPress şi roboții AI
Dacă am llms.txt configurat corect, înseamnă că roboții AI pot accesa site-ul meu?
Nu neapărat. llms.txt este un fişier de instrucțiuni pentru roboții AI — le spune ce conținut să prioritizeze. Dar dacă hosting-ul tău blochează cererile acestor roboți cu HTTP 429, fişierul llms.txt nu este niciodată citit. Accesul fizic la server vine înaintea oricăror instrucțiuni din fişiere de configurare.
Cum ştiu dacă hosting-ul meu blochează ClaudeBot sau GPTBot?
Cel mai simplu test este prin curl: rulezi 30 de cereri simulate cu user-agent-ul ClaudeBot şi compari cu 30 de cereri cu un browser normal. Dacă browserul primeşte HTTP 200 şi ClaudeBot primeşte HTTP 429, există un bloc UA-based în stiva ta. Testul durează 3 minute şi nu necesită acces root.
De ce HTTP 429 şi nu 403? Diferă pentru SEO?
HTTP 429 înseamnă „prea multe cereri” (rate limit), iar HTTP 403 înseamnă „interzis”. Platformele de hosting aleg 429 tocmai pentru că 403 poate genera alertă în Google Search Console. Un 429 arată ca o problemă de performanță, nu de acces — ceea ce îl face mult mai greu de detectat în auditurile standard.
Plugin-urile mele de securitate nu detectează nimic — înseamnă că nu am problema?
Nu. Tocmai acesta este punctul esențial: dacă blocajul vine de la nivel de platformă hosting, se activează înainte ca cererea să ajungă la WordPress. Wordfence şi Sucuri loghează la nivelul aplicației WordPress — nu văd cererile care sunt oprite la edge-ul platformei. Log-urile curate nu garantează acces complet.
Dacă folosesc Cloudflare, nu ar trebui să apară în analytics-ul meu?
Nu neapărat. Dacă hosting-ul tău are propriul strat Cloudflare (cum are WP Engine), acela este un nivel separat de Cloudflare-ul tău. Evenimentele de blocare care se produc la nivelul hostului nu apar în dashboard-ul tău Cloudflare personal. Sunt două instanțe diferite, una în spatele celeilalte.
Blocarea roboților AI afectează şi SEO tradițional pe Google?
Depinde de tipul de bot blocat. Roboții de antrenament (ClaudeBot, GPTBot ca antrenament) sunt diferiți de Googlebot — blocarea primilor nu afectează indexarea Google. Totuşi, dacă blocajul e configurat greşit şi blochează şi crawleri legitimi de indexare, da, poate afecta SEO. Googlebot rămâne de obicei neafectat.
Cache-ul meu ar putea masca problema — site-ul apare OK în teste, dar bots-ii sunt blocați?
Exact. Acesta e unul dintre cele mai insidioase aspecte ale problemei. Paginile cache-uite sunt servite normal — ClaudeBot primeşte 200 pentru un cache-hit. Dar pentru orice pagină care nu e în cache, primeşte 429. Testele tale pot părea OK dacă testezi pagini populare, dar roboții nu pot accesa conținut nou sau mai puțin popular.
Merită să-mi fac griji pentru vizibilitatea în AI search în 2026?
Da. ChatGPT procesează miliarde de interogări pe săptămână, iar răspunsurile citează un set relativ mic de surse. Dacă categoria ta este acoperită în acele răspunsuri şi site-ul tău nu poate fi crawled, nu vei fi citat — indiferent cât de bun e conținutul. Roboții de indexare AI funcționează similar cu cei de la Google în 2008: cei care s-au pregătit atunci au câştigat vizibilitate organică pentru ani de zile.