SEO, GEO & AI

Site-ul tău arată bine. Dar îl pot citi Google, ChatGPT și agenții AI?

Cum verifici dacă JavaScript, robots.txt, firewallul, URL-urile parametrizate sau conținutul ascuns împiedică motoarele AI să-ți citească site-ul.

Publicat 29 iulie 202611 minute
Un site complet pentru utilizator devine o structură aproape goală în fața unui crawler AI
Un design impecabil nu garantează că informația importantă există și în răspunsul HTML pe care îl primește un crawler.

Un website poate arăta impecabil, poate avea animații fluide, filtre inteligente și pagini care se încarcă instantaneu în browserul proprietarului. În același timp, crawlerul care ar trebui să-i descopere produsele poate primi un document aproape gol, un challenge de securitate sau mii de URL-uri fără o versiune clară. Problema nu este că „AI-ul nu înțelege designul”. Problema este că informația comercială nu ajunge întotdeauna până la sistemul care trebuie să o găsească.

Aceasta este partea tehnică a vizibilității în căutarea generativă. Înainte să discutăm despre citări, autoritate, mențiuni, răspunsuri concise ori query fan-out, trebuie să răspundem unei întrebări mai simple: poate sistemul automat să acceseze, să randaze și să identifice informația esențială de pe site?

Dacă răspunsul este „nu”, optimizarea editorială începe prea târziu. O pagină pe care crawlerul nu o poate procesa nu intră serios în competiția pentru selecție și citare.

„Crawler AI” nu înseamnă un singur robot

Prima greșeală este să punem Googlebot, GPTBot, OAI-SearchBot, ClaudeBot și agenții care navighează la cererea utilizatorului în aceeași categorie. Au scopuri și reguli diferite.

Sistem Rol principal Ce trebuie înțeles
Googlebot Crawling, randare și indexare pentru Google Search Conținutul eligibil pentru funcțiile AI din Google Search provine în continuare din infrastructura și indexul Search.
OAI-SearchBot Descoperirea site-urilor pentru ChatGPT Search Este controlul relevant pentru apariția conținutului în răspunsurile de căutare ChatGPT.
GPTBot Colectare de conținut care poate fi utilizat la antrenarea modelelor OpenAI Poate fi blocat independent de OAI-SearchBot. Search și training nu sunt aceeași decizie.
ChatGPT-User Accesarea unei pagini ca urmare a unei acțiuni inițiate de utilizator Nu este crawlerul automat care stabilește dacă o pagină poate apărea în ChatGPT Search.
PerplexityBot Descoperirea și afișarea surselor în rezultatele Perplexity Are documentație și intervale IP proprii; există separat și accesul inițiat de utilizator.
ClaudeBot / Claude-SearchBot Antrenare, respectiv îmbunătățirea căutării Claude Anthropic documentează boți diferiți și semnale distincte în robots.txt.

OpenAI explică explicit că un publisher poate permite OAI-SearchBot pentru Search și poate bloca GPTBot pentru training. A spune doar „am permis ChatGPT” nu este suficient de precis. Trebuie să știi ce user-agent ai permis, pentru ce funcție și prin ce strat al infrastructurii. Documentația oficială OpenAI despre crawlere separă clar aceste roluri.

Stratul 1: crawlerul ajunge efectiv la pagină?

Un fișier robots.txt permisiv nu garantează accesul. Cererea mai trece prin DNS, CDN, firewall, reguli anti-bot, limitare de trafic, challenge-uri JavaScript, autentificare și eventual restricții geografice.

O pagină poate răspunde cu HTTP 200 pentru browserul tău și cu 403 pentru un crawler. Poate livra un challenge Cloudflare în locul articolului. Poate accepta user-agentul declarat, dar bloca IP-ul. Poate returna o pagină de eroare mascată sub status 200. Pentru un proprietar care verifică doar vizual homepage-ul, toate acestea rămân invizibile.

OpenAI recomandă verificarea concomitentă a regulilor robots.txt și a intervalelor IP publicate. Perplexity publică aceeași categorie de informații. Cloudflare arată că regulile WAF sunt evaluate înaintea unor funcții dedicate controlului crawlerelor AI. Concluzia practică: accesul trebuie verificat la nivel de răspuns, nu presupus dintr-o bifă din panoul CDN.

Stratul 2: conținutul există în HTML sau apare numai după JavaScript?

Într-un website clasic ori randat pe server, răspunsul HTML conține deja titlul, descrierea, prețul, caracteristicile și linkurile importante. JavaScript adaugă interactivitate. Într-o aplicație randată exclusiv în browser, serverul poate trimite doar un container și câteva scripturi, iar conținutul apare după ce aplicația pornește și descarcă date suplimentare.

<div id="app"></div>
<script src="/assets/app.js"></script>

Pentru utilizator, diferența poate fi de câteva sute de milisecunde. Pentru un sistem care nu execută toate scripturile, nu așteaptă aceleași requesturi sau nu poate trece de o eroare JavaScript, diferența este între o ofertă completă și o pagină goală.

Google execută JavaScript prin infrastructura sa de randare, însă chiar Google recomandă server-side rendering, static rendering sau hydration. Motivele nu sunt doar SEO: răspunsul devine mai rapid, mai robust și accesibil unui număr mai mare de clienți automatizați. Ghidul oficial Google pentru JavaScript SEO precizează și că nu toți boții pot executa JavaScript.

CSR, SSR, SSG și hydration, fără jargon inutil

  • Client-side rendering (CSR): browserul construiește conținutul după descărcarea și executarea aplicației JavaScript.
  • Server-side rendering (SSR): serverul trimite HTML-ul complet pentru cererea respectivă.
  • Static generation (SSG): HTML-ul este construit înainte și servit ca document gata de citit.
  • Hydration: pagina pornește cu HTML util, apoi JavaScript îi adaugă comportamentul interactiv.

Nu trebuie eliminat React, Vue sau JavaScript. Trebuie eliminată dependența informației esențiale de o singură execuție fragilă. Un produs, un serviciu, un preț, o localitate deservită și un argument de încredere ar trebui să existe în HTML-ul inițial ori într-o variantă server-rendered echivalentă.

Stratul 3: „ascuns” vizual nu este același lucru cu „inexistent”

FAQ-urile, taburile și acordeoanele sunt frecvent acuzate că ascund conținutul de AI. Realitatea tehnică este mai nuanțată.

Dacă răspunsul este deja prezent în DOM și CSS doar îl afișează sau îl ascunde, textul poate fi extras din document. Dacă textul este descărcat prin API abia după primul click, un crawler care nu interacționează cu elementul nu îl primește. Iar dacă interfața nu are un buton semantic, nume accesibil, stare aria-expanded și relație clară cu panoul controlat, nici agenții care încearcă să folosească pagina nu au un traseu robust.

Această problemă depășește SEO. OpenAI recomandă etichete și roluri ARIA pentru ca agenții să poată interpreta controalele unei pagini, iar modelul W3C pentru disclosure documentează relația dintre buton, stare și conținut. Un website mai accesibil pentru oameni este, de regulă, și mai ușor de operat de către agenți.

Flux tehnic de audit pentru accesul motoarelor AI la un website
Accesul real se verifică pe straturi: răspunsul serverului, filtrele de securitate, HTML-ul inițial, randarea, semantica și structura URL-urilor.

Stratul 4: URL-urile parametrizate pot transforma site-ul într-un labirint

Filtrele de preț, culoare, localitate, categorie și sortare pot genera mii sau milioane de combinații. Unele răspund unei cereri reale. Cele mai multe sunt duplicări sau pagini aproape identice.

Problema nu este existența caracterului ?. Problema este lipsa unei politici:

  • care combinații merită indexate și au conținut propriu;
  • care sunt doar stări temporare ale interfeței;
  • care URL este canonical;
  • cum sunt tratate combinațiile fără rezultate;
  • dacă filtrarea produce linkuri crawlable către un spațiu practic infinit.

Google numește navigația cu filtre una dintre cele mai frecvente surse de overcrawling. Pentru combinațiile fără valoare editorială, recomandările includ blocarea atentă a crawlingului, folosirea fragmentelor în anumite implementări și întoarcerea unui 404 real pentru rezultate imposibile. Pentru paginile similare, canonicalul ajută la consolidarea semnalelor, dar nu trebuie folosit ca scuză pentru a produce necontrolat milioane de URL-uri. Vezi documentația despre faceted navigation și canonicalizare.

Stratul 5: semantica ajută, dar schema nu repară o pagină goală

Datele structurate pot preciza că o entitate este o organizație, că o pagină descrie un produs sau că un articol are un autor. Sunt utile atunci când reprezintă fidel informația vizibilă.

Nu sunt însă un înlocuitor pentru conținut. Un JSON-LD perfect nu compensează o descriere absentă, un preț încărcat doar după autentificare sau o pagină blocată de firewall. Google spune explicit că nu există schema specială necesară pentru funcțiile sale AI și avertizează împotriva datelor structurate care descriu conținut inexistent ori ascuns utilizatorului. Regulile pentru structured data cer ca markup-ul să fie o reprezentare reală a paginii.

Ordinea corectă este:

  1. informație reală și utilă;
  2. acces HTTP stabil;
  3. HTML lizibil și structură semantică;
  4. canonical și linkuri coerente;
  5. date structurate conforme;
  6. autoritate, dovezi și distribuție externă.

Auditul practic în 12 verificări

Verificare Ce urmărești Semnal de alarmă
1. Răspuns HTTP 200 real pentru paginile publice 403, 429, challenge sau soft 404
2. Redirecturi Lanț scurt și destinație stabilă Bucle, redirecturi geografice sau pe user-agent
3. robots.txt Reguli intenționate pentru fiecare crawler Blocare moștenită din plugin ori template
4. WAF/CDN Acces permis crawlerelor alese Regulă „block all bots” ori challenge obligatoriu
5. HTML inițial Titlu, ofertă, dovezi și linkuri în sursă Doar containerul aplicației
6. Randare Același mesaj esențial înainte și după JavaScript Conținutul dispare fără JS sau după o eroare API
7. Interacțiuni Controale semantice și conținut disponibil Text descărcat exclusiv după click
8. Canonical URL absolut, stabil și consecvent Canonical schimbat de JavaScript ori conflict cu sitemapul
9. Parametri Politică pentru filtre și sortări Combinații nelimitate și indexabile
10. Linkuri interne Linkuri HTML normale către paginile importante Navigație disponibilă doar prin evenimente JavaScript
11. Date structurate Entități reale, conforme cu textul vizibil Schema inventează informații inexistente pe pagină
12. Loguri și refereri Cereri reale, erori și trafic de la platforme AI Decizii luate doar pe baza unei simulări

Cum testezi fără să te păcălești

1. Compară trei versiuni ale aceleiași pagini

  • HTML-ul primit direct de la server;
  • DOM-ul după ce browserul a executat JavaScript;
  • textul și controalele expuse în arborele de accesibilitate.

Dacă informația comercială apare doar în a doua variantă, ai o dependență de randare. Dacă interfața există în DOM, dar nu poate fi înțeleasă în arborele de accesibilitate, ai o problemă pentru screen readere și potențial pentru agenții care navighează semantic.

2. Verifică user-agentul și IP-ul, nu doar unul dintre ele

Schimbarea user-agentului într-un instrument local arată cum răspunde infrastructura la acel text, dar nu demonstrează că un request provine de la operatorul real. Pentru allowlist și investigații de securitate, corelează user-agentul cu intervalele IP oficiale și cu logurile CDN.

3. Testează pagini reprezentative, nu doar homepage-ul

Include o pagină de serviciu, un produs, o categorie cu filtre, un articol, o pagină locală și o pagină cu taburi sau acordeoane. Homepage-ul poate fi randat pe server în timp ce restul aplicației rămâne exclusiv client-side.

4. Separă accesul de selecție

Faptul că un crawler poate citi pagina nu înseamnă că pagina va fi indexată, selectată sau citată. Accesul este condiția de intrare. Calitatea, relevanța, originalitatea, autoritatea și potrivirea cu interogarea decid competiția ulterioară.

Ce nu aș implementa

  • Nu aș permite automat orice bot doar pentru că include „AI” în nume. Vizibilitatea, securitatea și drepturile asupra conținutului sunt decizii separate.
  • Nu aș trata llms.txt ca soluție universală. Google spune că nu îl folosește pentru funcțiile sale AI Search.
  • Nu aș crea o versiune diferită și mai „optimizată” doar pentru crawler. Dacă diferența devine substanțială, intrăm în zona de cloaking și pierdem coerența produsului.
  • Nu aș pune toate răspunsurile doar în JSON-LD. Informațiile importante trebuie să existe și pentru utilizator.
  • Nu aș genera pagini subțiri pentru fiecare întrebare posibilă. O arhitectură coerentă și materiale substanțiale sunt mai solide decât mii de variații fabricate.

De ce contează pentru business, nu doar pentru SEO

Când sursa oficială este inaccesibilă sau ambiguă, sistemul nu încetează neapărat să răspundă. Poate folosi directoare, recenzii, presă, marketplace-uri, pagini vechi sau concurenți. Brandul pierde astfel șansa ca propriile informații actuale să participe la răspuns.

Pentru un SaaS, pot dispărea funcțiile și limitele produsului. Pentru un ecommerce, prețul și disponibilitatea. Pentru o afacere locală, zona deservită și programul. Pentru o companie B2B, cazurile de utilizare și dovezile de încredere.

De aceea, în proiectele de SEO și AEO prin AYSA.RO și în automatizările construite prin AYSA.AI, accesibilitatea tehnică trebuie tratată înaintea promisiunilor despre vizibilitatea în AI. Iar atunci când aplicația are nevoie de SSR, performanță și o arhitectură stabilă, discuția devine și una de dezvoltare software pentru IMM-uri, nu doar de conținut.

Concluzie: AI nu vede designul, vede ceea ce poate accesa și interpreta

Nu există un singur „crawler AI” și nici o bifă magică pentru GEO. Există sisteme diferite, reguli diferite și un traseu tehnic care începe înaintea conținutului: răspuns HTTP, permisiuni, randare, DOM, semantică, canonicalizare și abia apoi selecție.

Testul corect nu este „site-ul se vede bine pe laptopul meu?”. Este:

Informația esențială există în HTML, poate trece de infrastructura de securitate, are o adresă stabilă și poate fi înțeleasă fără să ghicim intenția interfeței?

Dacă răspunsul este da, site-ul poate intra în competiție. Dacă răspunsul este nu, nu avem încă o problemă de „optimizare pentru AI”. Avem o problemă fundamentală de livrare a informației.

Surse oficiale și documentație tehnică