Cum analizăm un articol pentru GEO și AEO

Un articol nu devine „optimizat pentru AI” pentru că are multe subtitluri, un FAQ și un fișier special. O analiză serioasă verifică dacă pagina rezolvă intenția, susține afirmațiile, poate fi găsită și înțeleasă, evită duplicarea și oferă fragmente care pot fi citate fără să piardă contextul.

Nu folosesc un scor GEO/AEO unic. Un 82/100 amestecă probleme foarte diferite: o eroare factuală, un canonical greșit și lipsa unui exemplu nu au aceeași natură sau aceeași remediere.

În schimb, auditul are piste independente și dovezi pentru fiecare constatare.

1. Definim rolul canonic al articolului

Înainte de checklist, scriem într-o propoziție ce trebuie să facă pagina: pentru cine este, ce întrebare principală rezolvă și ce acțiune legitimă urmează.

Exemplu: „Articolul explică antreprenorilor români cum verifică sursele unui răspuns AI despre RO e-Factura și îi trimite către documentația oficială pentru obligațiile curente.”

Dacă propoziția conține trei audiențe și cinci intenții, pagina poate avea nevoie de separare. Dacă alt URL are deja același rol, nu publicăm încă un articol doar cu alte cuvinte.

2. Construim matricea întrebărilor

Question coverage nu înseamnă să adăugăm toate întrebările imaginabile. Înseamnă să acoperim traseul necesar pentru intenția declarată:

• definiția și delimitarea problemei;
• criteriile de eligibilitate sau aplicare;
• procesul ori metoda;
• dovezile și exemplele;
• excepțiile și limitele;
• următorul pas;
• subiectele adiacente trimise către pagina canonică potrivită.

Pentru fiecare întrebare marcăm: răspuns direct, răspuns parțial, lipsă, neaplicabil sau rutat către alt URL. O pagină bună știe și ce nu trebuie să acopere.

3. Verificăm afirmațiile și dovezile

Separăm afirmațiile importante în propoziții verificabile. Pentru fiecare păstrăm sursa, data, domeniul de aplicare și tipul dovezii.

O definiție academică cere lucrarea sau standardul. O obligație fiscală cere autoritatea sau textul legal actual. O funcție de produs cere documentația oficială și starea funcției. O comparație cere criterii și metodologie independentă.

Articolul despre verificarea afirmațiilor despre brand oferă registrul complet pentru stările corect, incorect și neconfirmat.

O pagină cu multe linkuri nu este automat bine documentată. Sursa trebuie să susțină exact afirmația lângă care este plasată.

4. Evaluăm citation standing

Citation standing descrie poziția paginii în lanțul dovezii:

• sursă primară a datelor sau definiției;
• documentație oficială a entității;
• analiză independentă cu metodologie;
• sinteză care trimite corect la sursa originară;
• repetare fără proveniență.

Un articol care citează numai alte rezumate are standing slab pentru afirmații originale. Îmbunătățirea nu înseamnă eliminarea tuturor surselor secundare, ci urmărirea datelor și ideilor până la originea potrivită.

Ghidul despre sursele folosite în răspunsurile AI separă sursa găsită, recuperată, reflectată și citată.

5. Verificăm valoarea originală și expertiza

O pagină care rescrie primele rezultate fără experiență, date sau analiză nouă adaugă puțină valoare. Auditul caută:

• observații first-hand și limitele lor;
• un exemplu local sau un protocol reproductibil;
• calcule verificabile;
• o taxonomie mai clară;
• date proprii publicate cu metodologie;
• o concluzie proporțională cu dovezile.

Google recomandă conținut people-first, original, substanțial și de încredere și avertizează împotriva rezumatelor produse în masă. Documentația spune și că nu există un număr preferat de cuvinte. Pragul intern de profunzime al acestui cluster este control editorial, nu factor de ranking.

6. Brand fit fără inserție promoțională

Brandul trebuie să apară când aduce experiență, metodă, date sau un instrument relevant. Nu îl introducem în fiecare răspuns doar pentru frecvență.

Verificăm dacă:

• rolul autorului și experiența sunt clare;
• opinia este separată de fapt;
• funcțiile produsului sunt etichetate disponibil, beta, planificat sau metodologie;
• CTA-ul corespunde intenției și nu întrerupe răspunsul;
• limitările și conflictele de interes sunt declarate.

O mențiune comercială nepotrivită poate reduce încrederea chiar dacă mărește densitatea numelui.

7. Structură, lizibilitate și fragmente autonome

Titlul și introducerea trebuie să spună clar ce rezolvă pagina. Subtitlurile descriu întrebările reale, nu repetă variante artificiale ale unei expresii.

Listele sunt bune pentru pași și criterii. Tabelele sunt bune pentru comparații repetabile. Proza rămâne necesară pentru cauzalitate, limitări și context.

Un fragment citabil poate fi înțeles și separat, dar nu trebuie scurtat până devine fals. Definiția include termenul definit, formula include numitorul, iar procentul include eșantionul și perioada.

Ghidul Google pentru funcțiile generative spune că nu există o cerință de a fragmenta conținutul în bucăți minuscule și nici un stil special de scriere pentru AI.

8. Findability, crawl și index eligibility

Calitatea editorială nu ajută o pagină inaccesibilă. Verificăm:

• status HTTP 200 pe URL-ul canonic;
• HTTPS și redirecționări coerente;
• robots și meta robots;
• conținutul principal disponibil în HTML procesabil;
• legături interne reale către pagină;
• prezența în sitemap;
• title, description și un singur H1;
• imagine, alt text și metadate sociale.

OpenAI explică faptul că accesul OAI-SearchBot ajută descoperirea, rezumarea și citarea. Accesul nu garantează selecția. Aceeași limită se aplică oricărui audit tehnic: eligibil nu înseamnă afișat.

9. Canonical, duplicare și canibalizare

Comparam titlul, întrebarea principală, entitățile și secțiunile cu paginile existente. Dacă două URL-uri răspund aceleiași intenții și au corp similar, decidem între consolidare, diferențiere sau redirecționare.

Google descrie canonicalizarea ca alegerea unui URL reprezentativ dintr-un set de duplicate. `rel=canonical` este un semnal, nu o comandă absolută. Redirectul, canonicalul și sitemapul trebuie să indice aceeași direcție.

Pentru traduceri, fiecare limbă are self-canonical și hreflang către echivalente. Nu publicăm o rută EN sau DE cu corpul rămas în română.

10. Structured data trebuie să corespundă paginii

Verificăm tipul Article sau BlogPosting, titlul, autorul, datele, imaginea și URL-ul. Datele structurate nu trebuie să inventeze recenzii, FAQ-uri sau funcții care nu sunt vizibile.

Google spune că structured data poate oferi indicii explicite și eligibilitate pentru anumite rezultate îmbogățite, dar nu există un schema special obligatoriu pentru generative search. Marcajul corect ajută claritatea; nu garantează citarea.

11. Prospețime, versiune și autor

Data actualizării trebuie schimbată când conținutul se modifică substanțial, nu pentru a simula prospețimea. Afirmațiile volatile — prețuri, funcții, legislație, modele — au dată de verificare și proprietar.

Pentru metodologii păstrăm versiunea. O schimbare de formulă sau criteriu devine series break. Pentru articole cu experiență personală arătăm autorul, rolul și limita observației.

12. Measurement readiness

Înainte de editare salvăm baseline-ul:

• URL, hash sau versiune a conținutului;
• indexare și canonical observat;
• impresii/clickuri first-party disponibile;
• conversațiile și citările din cohorta de test;
• data, motorul, interfața, limba și geografia;
• coverage și eșecurile.

După publicare repetăm cohorta într-o fereastră declarată. O asociere temporală nu este automat cauzalitate, mai ales când motorul, indexul sau concurența se schimbă simultan.

Cum prioritizăm constatările

Lista de probleme nu se ordonează după cât de ușor este de bifat fiecare element. O afirmație juridică greșită sau un `noindex` accidental are prioritate față de rafinarea unui subtitlu. Folosim patru criterii:

• blocaj: problema împiedică accesul, indexarea sau înțelegerea paginii?
• risc: poate induce în eroare cititorul ori afecta o decizie importantă?
• acoperire: afectează întreaga pagină, o secțiune sau o singură afirmație?
• dovadă: avem suficiente date pentru remediere sau trebuie întâi investigat?

Ordinea practică este: blocaje tehnice și factualitate, rol canonic și overlap, acoperirea întrebărilor, dovezi și citation standing, apoi structură și rafinare. Această ordine poate varia când pagina tratează sănătate, finanțe, drept sau siguranță, unde revizuirea specializată precede editarea.

Fiecare constatare primește un proprietar și o stare. `Not verified` nu este echivalent cu `needs work`: prima spune că nu avem încă dovada, a doua că dovada confirmă problema. Separarea împiedică transformarea presupunerilor într-un backlog de modificări inutile.

După remediere, atașăm dovada nouă și închidem constatarea numai după verificare. O modificare în editor nu este finalizată dacă URL-ul live păstrează vechiul conținut, schema nu s-a actualizat sau canonicalul observat indică altă pagină.

Checklist reutilizabil

Pistă	Dovadă minimă	Stare
Rol canonic	audiență, întrebare, acțiune	pass / needs work
Question coverage	matrice răspuns/rutare	pass / needs work
Afirmații	registru cu sursă și dată	pass / not verified
Originalitate	date, experiență sau analiză	pass / needs work
Structură	headinguri, fragmente, tabele	pass / needs work
Tehnic	200, robots, canonical, sitemap	pass / not verified
Overlap	inventar URL și decizie	pass / needs work
Schema	JSON-LD egal cu pagina	pass / not applicable
Freshness	owner și review date	pass / needs work
Măsurare	baseline și cohortă	pass / not verified

Fiecare constatare are URL, captură sau fragment, severitate, proprietar și acțiune. Nu adunăm stările într-un procent care ascunde riscul.

Verdict

Analiza GEO/AEO nu înlocuiește SEO, editarea sau verificarea factuală. Le conectează într-un audit orientat către răspunsuri, citări și decizii.

Pagina bună are un rol clar, răspunde complet fără să invadeze alte intenții, își arată dovezile, poate fi accesată tehnic și poate fi măsurată înainte și după schimbare.

Checklistul nu garantează vizibilitatea. El garantează ceva mai modest și mai util: știm ce am verificat, ce lipsește, ce modificăm și ce rezultat vom remăsura.

Un rezultat `pass` este valabil pentru versiunea și data auditate. Nu este o certificare permanentă și trebuie revizuit când se schimbă pagina, sursele sau infrastructura.

Surse

• Google Search Central — Generative AI optimization guide
• Google Search Central — Helpful, reliable, people-first content
• Google Search Central — Canonicalization
• Google Search Central — Consolidating duplicate URLs
• OpenAI — Publishers and Developers FAQ
• Google Search Central — Structured data introduction

Ultima verificare a surselor: 31 iulie 2026. Checklistul este metodologie editorială și nu afirmă existența unui scor sau analizor AYSA lansat.