Ghid GEO pentru ecommerce în România

GEO pentru ecommerce în România nu înseamnă să publicăm sute de descrieri „pentru AI”, ci să facem comerciantul, produsele, ofertele și politicile ușor de identificat, verificat și măsurat în scenarii reale de cumpărare. Un magazin poate fi menționat corect și totuși să fie asociat cu varianta greșită, un preț expirat, stoc inexistent sau o livrare care nu se aplică destinației.

Acest ghid construiește un ciclu de 30 de zile pentru un magazin care vinde în România. Metodologia generală pentru vizibilitatea produselor, recomandări, share of voice, catalog și agentic commerce rămâne în articolele dedicate. Aici le legăm de identitatea comerciantului, limba română, moneda, livrarea și informațiile comerciale care influențează decizia locală.

1. GEO ecommerce începe cu o întrebare măsurabilă

„Vrem să apărem în AI” nu definește un proiect. Trebuie să alegem piața, categoriile, produsele, tipurile de clienți, limbile, destinațiile și suprafețele observate. Un magazin generalist și un comerciant specializat au universuri diferite; un produs disponibil numai în București nu are aceleași oportunități ca unul livrat național.

Fișa de scop poate preciza:

• România, plus eventual cohorte de export tratate separat;
• magazinul propriu, aplicația și magazinele oficiale din marketplace-uri;
• cinci categorii și 50 de produse prioritare, nu întregul catalog din prima zi;
• clienți noi, clienți care compară sau clienți care verifică o ofertă;
• descoperire, potrivire, încredere, preț, disponibilitate, livrare sau retur;
• data de referință, proprietarii datelor și frecvența remăsurării.

Eurostat publică statistici despre cumpărăturile online ale persoanelor în UE. Acestea descriu adopția ecommerce, nu vizibilitatea unui magazin în răspunsuri AI. Baseline-ul GEO trebuie observat direct și nu poate fi dedus din creșterea pieței.

2. Stabilim cine este comerciantul

Brandul magazinului, compania care operează site-ul, vânzătorul din marketplace și producătorul unui produs pot fi patru entități diferite. Înainte de prompturi construim un pașaport al comerciantului: nume legal, brand, domeniu canonic, date publice de contact, canale oficiale, rolul marketplace-ului, seller of record, piețe și limbi.

Serviciile ONRC pot ancora identitatea juridică și statutul profesionistului. Site-ul trebuie să explice relația comercială în limbaj clar: cine vinde, cine facturează, cine livrează și cine oferă suport. Nu copiem date personale sau informații cu acces limitat doar pentru optimizare.

Pe un marketplace, numele listării nu dovedește automat cine este comerciantul. În registrul de măsurare păstrăm separat platforma, sellerul, brandul produsului și URL-ul ofertei. Dacă răspunsul atribuie produsul marketplace-ului când oferta aparține unui vânzător terț, marcăm o confuzie de entitate.

3. Separăm produsul, varianta și oferta

Produsul descrie obiectul comercial stabil. Varianta adaugă atribute precum dimensiune, culoare, capacitate sau compatibilitate. Oferta leagă varianta de un vânzător, preț, monedă, stoc, condiții și moment. O recomandare pentru familie nu poate fi transferată automat tuturor variantelor și ofertelor.

Ghidul despre catalogul de produse ca sursă de adevăr definește arhitectura completă. Pentru playbookul românesc înghețăm un snapshot minimal:

• ID intern stabil, SKU și identificatori externi legitim atribuiți;
• brand, nume în română, categorie și atribute decisive;
• relația familie–produs–variantă–bundle;
• vânzător, preț, RON sau moneda reală și felul în care este afișată taxa;
• promoție și interval de valabilitate;
• stoc, backorder, indisponibil, retras sau înlocuit;
• URL canonic, imagine reprezentativă și momentul observației.

Nu verificăm un răspuns de la ora 10:00 cu prețul live de la ora 18:00 fără să păstrăm ambele momente. În ecommerce, adevărul comercial se schimbă mai repede decât specificația produsului.

4. Oferta românească include destinația și timpul

„Este în stoc” nu răspunde întotdeauna întrebării cumpărătorului. Oferta utilă include dacă varianta exactă poate fi comandată, unde poate fi livrată, costul, metoda, estimarea, eventualul cutoff și sursa acestor date. O estimare pentru București nu este promisiune pentru orice localitate.

Construim scenarii cu destinație declarată: municipiu mare, oraș mic, rural sau ridicare, numai dacă magazinul publică asemenea opțiuni. Nu inventăm timpi pentru a completa un câmp. Marcăm „neconfirmat” când informația se calculează abia în checkout sau depinde de codul poștal.

Pagina de produs poate oferi specificația, pagina de livrare regulile generale, iar checkout-ul oferta finală. Răspunsul AI trebuie verificat împotriva sursei potrivite. Un articol vechi despre „livrare în 24 de ore” nu înlocuiește termenul curent calculat pentru produs și destinație.

5. Politicile sunt parte din decizie, nu text de footer

Identitatea vânzătorului, returul, garanția, reclamațiile și suportul pot schimba alegerea dintre două oferte. Le tratăm ca afirmații verificabile, cu URL, domeniu de aplicare și dată. Nu rezumăm toate politicile într-o propoziție generică.

ANPC a publicat un ghid de bune practici pentru produsele și serviciile comercializate online. Your Europe explică garanțiile și perioada de retragere de 14 zile aplicabilă multor cumpărături la distanță, împreună cu excepții. Nu transformăm regula într-o promisiune universală pentru orice produs, serviciu sau situație.

Auditul GEO nu certifică respectarea legii. El poate identifica un răspuns care atribuie greșit politica altui vânzător, omite o excepție ori citează o pagină depășită. Afirmația sensibilă este trimisă proprietarului juridic/comercial pentru validare.

6. Paginile, markup-ul și feedul trebuie să spună același lucru

Catalogul intern poate proiecta date către pagina vizibilă, JSON-LD, feedul de comerciant, API, marketplace și suport. Fiecare canal are formate și viteze diferite, dar contradicțiile trebuie detectate. Un feed cu stoc actual și o pagină cu „disponibil” rămas din cache produc două adevăruri publice.

Documentația Google pentru Product structured data arată proprietăți pentru produs și ofertă. Merchant listing structured data poate exprima informații comerciale suplimentare. Datele trebuie să corespundă paginii și politicilor; markup-ul valid nu garantează afișarea sau recomandarea.

OpenAI descrie folosirea datelor structurate și a feedurilor comercianților pentru product discovery. Participarea, acoperirea regională și comportamentul trebuie verificate la data implementării. Feedul oferă date, nu dreptul la includere.

7. Verificăm accesul tehnic fără promisiuni

Paginile prioritare trebuie să răspundă cu HTTP 200, să aibă conținut util în HTML sau randare accesibilă, canonical coerent, directive corecte și legături interne. Product page, categorie, politici și informația despre comerciant nu trebuie ascunse accidental de crawl, autentificare sau parametri instabili.

Google spune că funcțiile AI folosesc cerințele și bunele practici Search existente și pot aplica query fan-out. Respectarea cerințelor nu garantează crawling, indexare sau apariție. Același realism se aplică oricărei platforme externe.

Nu permitem accesul la coșuri, conturi sau date personale pentru „vizibilitate”. Verificăm user-agent-urile și documentația operatorului înaintea regulilor de CDN. Pagina publică a produsului și oferta pentru un utilizator sunt una; sesiunea privată și datele de client sunt alt contract.

8. Construim scenarii românești de cumpărare

Setul inițial de 40–80 de scenarii trebuie să reprezinte decizii, nu reformulări artificiale:

• identitate: cine operează magazinul și cine vinde produsul;
• categorie: magazine sau produse pentru o nevoie concretă;
• potrivire: buget, utilizare, dimensiune, compatibilitate ori material;
• comparație: două produse eligibile și criterii declarate;
• ofertă: varianta exactă, preț, monedă și disponibilitate;
• livrare: destinație, cost și termen verificabil;
• încredere: vânzător, retur, garanție, suport și reputație;
• acțiune: accesarea paginii, verificarea ofertei ori cumpărarea.

Româna cu diacritice este cohorta canonică. Variantele fără diacritice intră separat doar dacă există date de cerere. „Ieftin”, „rapid” și „bun” trebuie transformate în constrângeri observabile; altfel evaluatorul nu poate decide dacă recomandarea respectă nevoia.

9. Separăm magazinul, produsul și oferta în măsurare

Un răspuns poate menționa magazinul fără produs, produsul fără comerciant sau o ofertă exactă. Folosim trei registre:

Nivel	Ce numărăm	Eroare frecventă
magazin	descoperire și identificarea comerciantului	brand confundat cu sellerul
produs	familie, model și variantă rezolvate	atribute transferate între variante
ofertă	seller, preț, stoc, livrare și timp	ofertă veche prezentată ca live

Articolul despre măsurarea vizibilității produselor în răspunsuri AI definește funnelul complet. În ghidul local păstrăm aceeași taxonomie și adăugăm câmpurile de comerciant, RON, destinație, politici și sursă temporală.

10. Registrul observației face rezultatul auditabil

Pentru fiecare rulare salvăm ID-ul scenariului, promptul exact, contextul conversației, suprafața și modelul afișat, data și ora, limba, locația disponibilă, starea autentificării, răspunsul, citările și URL-urile. Apoi clasificăm separat:

• magazinul și produsul sunt prezente sau absente;
• produsul este menționat, comparat, shortlistat, recomandat sau exclus;
• varianta și sellerul sunt rezolvate;
• prețul, moneda, stocul și livrarea sunt corecte la momentul capturii;
• politicile sunt corecte, neconfirmate, greșite sau depășite;
• citarea susține afirmația decisivă;
• există conflict între pagină, markup, feed sau o sursă terță.

O captură de ecran poate documenta un răspuns, dar nu înlocuiește textul complet și metadatele. Nu folosim conturi personale ori sidebar-uri. Dacă sesiunea publică nu permite testul, celula rămâne netestată; nu transformăm autentificarea într-o dovadă.

11. KPI-urile rămân separate

Raportăm rata de descoperire a magazinului, rata de rezolvare a produsului, rata recomandărilor calificate, citarea sursei primare, acuratețea comercială și acuratețea politicilor. Fiecare are numitor și cohortă explicite.

De exemplu, prețul corect se calculează numai în observațiile în care răspunsul afirmă un preț și există un snapshot comparabil. Nu împărțim prețurile corecte la toate prompturile. Disponibilitatea, livrarea și recomandarea au alte oportunități eligibile.

Ghidul care separă recomandarea unui produs de simpla mențiune rămâne contractul semantic. Un card vizual, un link ori un adjectiv pozitiv nu devin automat recomandare.

12. Verificăm afirmația în sursa potrivită

Nu există o singură ierarhie pentru toate câmpurile. Entitatea legală se verifică în surse oficiale și pe pagina comerciantului. Specificația se verifică în catalogul aprobat și, după caz, la producător. Prețul și stocul se verifică la seller, cu timp. Returul se verifică în politica aplicabilă ofertei. Experiența unui client poate documenta o experiență, nu rescrie condițiile comerciale.

Google documentează reprezentarea politicii de retur la nivel de organizație și, unde este cazul, override-uri la nivel de ofertă. Markup-ul trebuie să reflecte politica publicată; nu devine sursa juridică a regulii.

Fiecare afirmație primește sursă, moment, verdict și reviewer. Pentru sănătate, siguranță, finanțare, vârstă, compatibilitate critică ori conformitate, pragul de validare este mai ridicat. Un răspuns nesusținut nu este transformat în copy de produs.

13. Remediem sursa înainte să producem volum

Dacă modelul confundă două variante deoarece pagina folosește același titlu și aceeași imagine, corectăm identitatea. Dacă politica este ascunsă într-un PDF vechi, publicăm o pagină curentă și legată. Dacă feedul și pagina diferă, reparăm proiecția sau cache-ul. Dacă magazinul nu explică cine vinde, clarificăm entitatea.

Ordinea practică este:

1. afirmație greșită care poate schimba cumpărarea;
2. seller sau variantă confundată;
3. preț, stoc ori livrare depășite;
4. politică importantă neclară;
5. pagină canonică lipsă ori inaccesibilă;
6. atribut decisiv absent;
7. conținut editorial suplimentar cu nevoie demonstrată.

Nu clonăm pagini pentru fiecare oraș dacă oferta nu are diferențe reale. Nu umplem FAQ-ul cu întrebări inventate doar pentru volum. Fiecare pagină nouă trebuie să dețină o decizie, un set de date sau o dovadă unică.

14. Planul de 30 de zile

Săptămâna 1 — comerciantul și sursele

Definim scopul, brandul, entitatea legală, sellerii, canalele și politicile. Inventariem paginile, feedurile, markup-ul, marketplace-urile și proprietarii datelor. Verificăm accesul tehnic pentru suprafețele publice.

Săptămâna 2 — produsele și baseline-ul

Alegem produsele prioritare, înghețăm snapshotul, construim 40–80 de scenarii și rulăm protocolul. Păstrăm răspunsurile, citările, timpul și verdictul pe magazin, produs, variantă, ofertă și politici.

Săptămâna 3 — remedierea

Alegem maximum cinci conflicte cu impact. Corectăm sursa canonică, pagina, proiecțiile și legăturile. Marcăm exact ce s-a schimbat și când, fără să pretindem efect imediat.

Săptămâna 4 — remăsurarea

Rulăm cohorta prestabilită sau subsetul aprobat, comparăm numai celule echivalente și documentăm delta. Stabilim apoi cadența și trigger-ele: preț major, lansare, retragere, schimbare de politici, migrare, rebranding sau integrare nouă.

15. Româna și exportul nu sunt aceeași cohortă

Versiunea română folosește produse, monedă, seller, livrare și politici aplicabile României. Engleza ori germana pot servi exportul, dar oferta, disponibilitatea, costurile și drepturile aplicabile pot diferi. Traducerea paginii românești nu creează automat o ofertă pentru altă piață.

Păstrăm identitatea produsului, apoi localizăm termenii, unitățile, exemplele, destinațiile, suportul și call-to-action-ul. Dacă magazinul nu livrează într-o piață, nu construim scenarii de cumpărare care presupun contrariul.

16. Ce nu facem

• nu declarăm succes după o singură recomandare;
• nu confundăm magazinul cu produsul sau marketplace-ul cu sellerul;
• nu publicăm preț, stoc ori livrare fără momentul observației;
• nu considerăm markup-ul, feedul ori crawlerul garanții de apariție;
• nu prezentăm orice retur ca având aceleași reguli;
• nu copiem răspunsurile AI în catalog ca sursă de adevăr;
• nu generăm pagini locale fără ofertă și dovezi distincte;
• nu folosim capturi din conturi personale;
• nu publicăm clasamente de magazine sau produse din exemple neverificate;
• nu atribuim automat unei modificări efectul observat;
• nu descriem o funcție AYSA ca fiind lansată fără verificare.

Verdict

Un program GEO pentru ecommerce în România este o disciplină de adevăr comercial și măsurare. Definește comerciantul, rezolvă produsul și varianta, îngheață oferta, observă scenarii românești și verifică fiecare afirmație în sursa potrivită.

Obiectivul realist nu este „să convingem AI-ul”. Este să reducem confuzia, să corectăm informațiile depășite, să acoperim deciziile reale și să putem demonstra ce s-a schimbat între două rulări comparabile. Vizibilitatea, recomandarea, citarea, acuratețea și conversia rămân rezultate distincte.

Surse

• Eurostat — E-commerce statistics for individuals
• ONRC — Servicii online
• ANPC — Ghid de bune practici pentru piața online
• Your Europe — Guarantees and returns
• Google Search Central — Product structured data
• Google Search Central — Merchant listing structured data
• Google Search Central — Organization return policy
• Google Search Central — AI features and your website
• OpenAI — Powering product discovery in ChatGPT
• OpenAI — Shopping with ChatGPT Search

Acest ghid este o metodologie editorială și operațională independentă. Nu reprezintă consultanță juridică, nu recomandă magazine sau produse și nu garantează includerea, citarea ori recomandarea într-un sistem AI extern.