Feed produse XML pentru magazin: câmpurile care decid acceptarea și cum găsești câmpul care blochează

Un feed produse XML pentru magazin nu are nicio legătură cu fluxurile RSS sau Atom, deși poartă același nume și aceeași extensie. Este un fișier de date care descrie catalogul tău într-un format pe care îl citesc mașinile: un rând pe produs, un set fix de câmpuri pe rând, și o specificație publică pentru fiecare canal care îl consumă.

Răspunsul scurt, dacă ai ajuns aici pentru că jumătate din produse îți sunt respinse:

1. Câmpurile obligatorii nu sunt aceleași pe toate canalele. Google cere șapte atribute pentru orice produs, plus costuri de livrare pentru România. eMAG cere șase la salvarea unei oferte, dintre care cota de TVA și starea ofertei nu au corespondent la Google.
2. Identificatorii sunt cauza cea mai frecventă de confuzie, iar regula circulată în piață e greșită: brand e obligatoriu, gtin e „depinde”.
3. Prețul și disponibilitatea de pe pagina de destinație suprascriu ce ai trimis în feed. Poți avea fișierul corect și tot să primești neconcordanță.
4. Cadența nu se alege, se citește: fișier găzduit la un URL — 24 de ore; platformă conectată — pot trece 24–48 de ore.
5. Câmpul care blochează se izolează în șase pași, în ordinea din secțiunea finală. Nu se caută citind lista de erori.

Textul e scris pentru cineva care are deja un magazin cu produse reale și trimite date către cel puțin un canal extern. Nu tratează configurarea contului de Merchant Center și nu tratează structura campaniilor de produs — sunt subiecte separate, cu proceduri separate. Dacă abia evaluezi dacă merită să deschizi un canal de marketplace, ordinea corectă e invers: întâi calculul de marjă din articolul despre cât reții de fapt din fiecare vânzare, apoi partea tehnică de aici.

Cine citește fișierul tău și ce face cu el

Feed-ul e un activ de date, iar consumatorii lui sunt patru, cu specificații scrise separat și cu apetituri diferite. Cel mai scump lucru pe care îl poți face e să îl construiești pentru unul singur și să afli peste șase luni că al doilea cere altceva.

Tabelul se citește pe coloana a treia, nu pe prima: metoda de livrare a datelor decide cât de repede se propagă o modificare de preț, iar asta e diferența dintre un canal care merge și unul care îți dezaprobă produse în fiecare lună.

Despre ultimul rând, cu formularea exactă pe care o poate susține: dintre sursele pe care le-am verificat la 29 iulie 2026, comparatoarele românești nu publică deschis specificația lor de feed — compari.ro, price.ro și documentația de platformă a Gomag returnează 403 pentru cereri automate. Nu înseamnă că specificația nu există; înseamnă că se obține din contul de comerciant, nu de pe web, iar un articol nu poate reproduce câmpuri pe care nu le-a văzut.

Ce fișier produci depinde și de ce îți permite platforma pe care stai: unele generează feed-uri complete și configurabile, altele exportă un set fix pe care nu îl poți extinde fără dezvoltare. Discuția asta e în articolul despre ce control ai pe export și pe integrări, în funcție de platformă, și merită citită înainte de a promite cuiva un canal nou. Așa privim și noi creșterea unui magazin online: infrastructura de date înainte de canale, nu invers.

Notă: configurarea propriu-zisă a contului Merchant Center — verificarea site-ului, setările de livrare, revendicarea domeniului — nu intră în acest articol. Aici tratăm fișierul, nu contul.

Câmpurile fără de care produsul nu intră deloc

La Google, șapte atribute sunt marcate Required pentru orice produs, plus două condiționate care în România devin obligatorii în practică.

Ultimele două rânduri sunt cele care surprind. Costurile de livrare sunt obligatorii pentru anunțurile Shopping și listările gratuite într-o listă de țări care include explicit România, alături de Austria, Belgia, Cehia, Franța, Germania, Irlanda, Italia, Olanda, Polonia, Spania și restul. Nu e o recomandare de bună practică; e o cerință de specificație, iar un magazin românesc care nu o vede rămâne cu produse care nu se afișează și cu impresia că problema e la altceva.

La preț, regula e la fel de scurtă și la fel de des ratată: pentru Statele Unite și Canada, documentația cere ca taxele să nu fie incluse; pentru toate celelalte țări, TVA-ul se include în preț. Un feed exportat dintr-un sistem configurat pentru piața americană trimite prețuri fără TVA și produce neconcordanță cu pagina la fiecare rulare.

Două termene pe care merită să le pui în calendar acum, ambele din specificația citită pe 29 iulie 2026:

• imaginile de produs vor trebui să aibă minimum 500 × 500 de pixeli, iar aplicarea cerinței începe pe 31 ianuarie 2027. Dacă exporți miniaturi de 300 × 300, ai un an și jumătate ca să regenerezi biblioteca de imagini, și e o operațiune care se face o singură dată, mai bine devreme;
• din aprilie 2025, clasa energetică pentru produsele vândute în Uniunea Europeană se trimite prin atributul certification, cu referință în baza EPREL a Comisiei Europene, în forma EC:EPREL:123456. Vechiul energy_efficiency_class a rămas disponibil doar pentru Elveția, Norvegia și Regatul Unit.

Poți trimite până la zece imagini suplimentare, repetând atributul additional_image_link. Merită, pentru că e singurul loc din feed unde adaugi informație fără să riști o neconcordanță cu pagina.

Identificatorii: brand, GTIN și supapa pe care o folosești greșit

Aici e cea mai răspândită eroare din conținutul românesc pe subiect, și e o eroare de atribuire: se scrie că GTIN-ul e obligatoriu pentru toate produsele noi, cu excepția filmelor, cărților și mărcilor de înregistrări muzicale. Fraza aceea există în specificație, dar aparține atributului brand, care e listat imediat deasupra lui gtin. Statutul real al GTIN-ului, în specificația deschisă pe 29 iulie 2026, e „It Depends”, cu mențiunea „strongly recommended if available”.

Diferența nu e academică. Un magazin care crede că are nevoie de cod de bare pentru fiecare referință va inventa coduri sau va renunța la produsele handmade, iar ambele sunt mai rele decât situația reală.

Interpretarea tabelului: cele patru câmpuri formează un singur mecanism, nu patru decizii independente. Google verifică dacă produsul ar trebui să aibă identificatori, iar identifier_exists=no e declarația ta că nu are — nu o cale de a scăpa de completare.

Cele trei situații în care valoarea no e corectă, verbatim din specificație: produsul e un articol de media și GTIN-ul nu e disponibil (codurile ISBN și SBN se acceptă ca GTIN); produsul e un articol de îmbrăcăminte și marca nu e disponibilă; în orice altă categorie, produsul nu are nici GTIN, nici combinația MPN plus marcă. Și avertismentul care închide discuția: dacă produsul chiar are identificatori și tu trimiți no, produsul poate fi dezaprobat.

Aceeași logică se aplică valorilor greșite. Documentația e explicită pe amândouă: „If you submit a product with an incorrect MPN value, your product will be disapproved.” Regula practică e simplă și contraintuitivă pentru cine vine din marketing: când nu ești sigur de un identificator, nu îl trimiți. Un câmp gol e o stare validă; un cod ghicit e o dezaprobare cu întârziere.

Motivele de respingere, în ordinea în care apar în cont

Problemele nu vin ca o listă plată. Contul le separă pe două niveluri, iar ordinea în care le rezolvi contează mai mult decât numărul lor.

1. Probleme la nivel de cont. Afectează tot catalogul. Cât timp există una activă, nu are sens să repari câmpuri: produsele reparate rămân tot neafișate.
2. Probleme la nivel de produs, de tip avertisment. Produsele continuă să se afișeze, dar performanța poate fi limitată. Netratate, se transformă în dezaprobări.
3. Probleme la nivel de produs, de tip dezaprobare. Produsul nu se mai afișează deloc și are nevoie de o corecție înainte de reaprobare.
4. Dezaprobarea preventivă, în documentație „preemptive item disapproval”. Se declanșează când prețul sau disponibilitatea nu se potrivesc între datele trimise și pagina de destinație, iar ieșirea din ea cere o cerere de revizuire, nu doar o corecție tăcută.

Precizare de metodă, pentru că e ușor de citit greșit: ordinea de mai sus e ordinea de prioritate din cont, nu o frecvență măsurată. Nu am găsit nicio sursă cu metodologie publicată care să spună ce procent din respingeri vine de la ce câmp, iar o distribuție inventată ar fi fost cea mai citabilă și cea mai falsă parte a acestui articol.

Cauzele care țin de site, nu de fișier, sunt enumerate ca atare în documentație și merită citite ca listă de verificare separată:

• conținut de tip substituent lăsat pe pagină;
• linkuri rupte;
• informații lipsă sau inconsecvente între site și datele trimise;
• descrieri de produs inexacte;
• categorii care nu se potrivesc între site și feed;
• o configurație robots.txt care blochează Googlebot sau Googlebot-image;
• pagina de destinație indisponibilă, din erori de server sau din încărcare lentă;
• pagina de destinație care redirecționează către o pagină generică în loc de produsul exact.

Ultimele trei sunt cele pe care le ratează aproape toată lumea, pentru că nu se văd în fișier. Un feed impecabil peste un site care blochează crawlerul de imagini produce dezaprobări la care nu găsești cauza în export.

Locul unde se citesc toate e fila „Needs attention” din secțiunea de produse. Lista se poate filtra după impact, etichetă, stare sau titlu, și se poate descărca integral ca fișier CSV — iar descărcarea e primul pas real de depanare pe un catalog mare, pentru că îți dă tiparul, nu exemplele.

Prețul de pe pagină bate prețul din feed

Mecanismul acesta explică majoritatea situațiilor de tipul „fișierul e corect și tot primesc eroare”, și nu apare în niciun conținut românesc pe care l-am verificat.

Merchant Center are un set de automatizări care actualizează patru atribute — price, sale_price, availability și condition — citindu-le de pe pagina de destinație, peste ce ai trimis tu. Exemplul din documentație e cât se poate de direct: „If your most recent product upload contains a product that costs $4 USD, but your product landing page lists it as $3 USD, we’ll update the product to $3 USD in your ads or product listings.”

De unde citește, mai exact:

• prețul, din price și priceCurrency sub Offer, sau din priceSpecification;
• disponibilitatea, din ItemAvailability;
• starea produsului, din itemCondition.

Potrivirea nu e strictă pe disponibilitate: in_stock, preorder și backorder sunt tratate ca fiind compatibile cu in_stock. Diferența dintre „în stoc” și „precomandă” nu îți va sparge contul; diferența dintre 199 și 179 de lei, da.

Două limite schimbă însă felul în care te poți baza pe mecanism, și amândouă sunt scrise explicit:

• automatizările nu înlocuiesc actualizarea regulată a datelor — „Automations aren’t a replacement for regular updates of your product data.” Sunt gândite să repare probleme temporare, pe un procent mic din produse, și nu acoperă tot catalogul. Dacă prețurile și stocurile ți se schimbă des, răspunsul documentat e trecerea pe API, nu bazarea pe corecție automată;
• pagina de destinație nu are voie să varieze după client — „Your landing page cannot change based on information about the customer, such as if you adapt prices based on a customer’s IP address or browser type.” Marcajul trebuie să arate valorile pe care le vede clientul.

A doua limită e cea pe care magazinele o încalcă fără să știe. Un test A/B de preț, o afișare diferită pentru vizitatorii dintr-o anumită țară sau un preț de membru afișat implicit sunt toate cauze de dezaprobare, nu optimizări.

Marcajul de pe pagină nu e, prin urmare, o alternativă la feed — e a doua sursă a aceleiași informații, iar când cele două nu coincid, câștigă pagina. Cum se scrie corect marcajul pe pagina de produs, ca element de SEO, e o discuție separată, tratată în articolul despre datele structurate de pe pagina de produs. Aici ne interesează doar ca semnal către canale.

La ce interval se reia efectiv fiecare metodă de încărcare

„Cât de des trebuie actualizat feed-ul” e o întrebare greșit pusă. Corect e: la ce interval reia canalul datele, și ce se întâmplă între două reluări.

Fraza de interpretare a tabelului e și regula de decizie: dacă modificarea medie de preț sau de stoc trebuie să ajungă la client în mai puțin de 24 de ore, niciuna dintre primele patru metode nu îți este suficientă, iar discuția se mută de la „ce fișier export” la „cine scrie integrarea”. Documentația însăși recomandă trecerea pe API exact în acest caz.

Ultimul rând merită un avertisment separat: metoda de preluare din marcajul site-ului nu e compatibilă cu anunțurile de inventar local și cu listările locale gratuite. Dacă ai magazin fizic și vrei să afișezi stocul din magazin, alegerea e deja făcută în locul tău.

Pe partea de eMAG, regimul e cu totul altul, pentru că nu e un fișier preluat, ci un API pe care îl apelezi tu. Limitele declarate în specificația v4.5.1, valabilă din 2 martie 2026:

• 12 cereri pe secundă pentru resursele de comenzi și 3 cereri pe secundă cumulat pentru toate celelalte; la depășire primești HTTP 429, iar cererile invalide se numără și ele la limită;
• maximum 4.000 de elemente pe cerere;
• salvare în bloc limitată la 50 de entități pe cerere, cu recomandarea de a rămâne între 10 și 50;
• programarea la ore fixe e descurajată explicit: recomandarea din documentație e să rulezi la 12:04:42, nu la 12:00:00, tocmai ca să nu te aliniezi cu toți ceilalți integratori;
• o modificare programată prin start_date poate fi setată cu până la 60 de zile în avans, dar nu mai devreme de ziua următoare.

Un integrator care nu citește aceste cinci rânduri construiește un job care rulează la fix, trimite 5.000 de produse odată și se oprește cu 429 în a doua lună, când catalogul crește. Costul canalului nu e doar comisionul; e și munca de integrare, iar cifrele de mai sus îți spun cât e. Pentru partea de buget media a canalului de produs, calculul e în articolul despre ce te costă efectiv canalul de produs, iar campaniile care consumă acest feed le construim în programul nostru de Google Ads.

Același catalog, trei destinații: ce se schimbă între canale

Aici se vede de ce feed-ul merită tratat ca activ comun. Aceeași informație, trei formate, cu diferențe suficient de mici cât să nu le observi la export și suficient de mari cât să blocheze produse.

Citește tabelul pe rândul „Disponibilitate” și ai toată problema într-o singură celulă: același concept, in_stock la Google și in stock la Meta. Un export care tratează cele două canale identic pică pe unul dintre ele, iar mesajul de eroare nu îți spune că e vorba de un caracter.

Rândurile care contează cel mai mult pentru un magazin românesc sunt însă „Preț” și „Cod de bare”. La eMAG, prețul se trimite fără TVA și trebuie însoțit de un interval minim și maxim la prima salvare a ofertei — un mecanism care nu are corespondent la Google. Iar codul de bare nu e o regulă globală: obligativitatea lui se citește per categorie, din parametrul is_ean_mandatory al categoriei, nu dintr-o listă generală. Cum arată în practică fișa de produs pe eMAG, inclusiv atașarea la o ofertă existentă prin part_number_key, e tratat în articolul despre cerințele de catalog ale eMAG, când listezi manual.

Șase pași care izolează câmpul care blochează

Aceasta e procedura pe care o folosim, construită pe documentația celor trei canale. Se rulează în ordine, iar fiecare pas elimină o clasă de cauze, ca să nu ajungi să compari 4.000 de rânduri cu ochiul.

1. Verifică întâi dacă fișierul a fost preluat. Dacă ultima preluare reușită e de acum trei zile, nimic din ce ai corectat între timp nu a ajuns la canal, iar erorile pe care le vezi descriu o versiune veche. Aici se opresc, de fapt, jumătate din investigații.
2. Separă problemele de cont de cele de produs. Cât timp există o problemă la nivel de cont, produsele reparate rămân neafișate. Ordinea corectă e cont, apoi produs, niciodată invers.
3. Descarcă lista completă de produse afectate ca CSV și numără pe câmp, nu pe produs. Dacă 800 de produse au aceeași problemă, ai o eroare de export, nu 800 de erori de date. Tiparul se vede în agregare, nu în exemple.
4. Verifică cele patru atribute pe care le poate suprascrie pagina — preț, preț redus, disponibilitate, stare — comparând feed-ul cu pagina publică, nu cu baza de date. Ele sunt sursa neconcordanțelor la magazinele care jură că fișierul e corect.
5. Verifică identificatorii ca mecanism, nu ca listă. Marca prezentă unde e cerută, GTIN-ul doar unde e sigur, MPN-ul doar în absența GTIN-ului de producător, identifier_exists folosit exclusiv în cele trei situații documentate.
6. La final, verifică cerințele specifice canalului pe care ai eroarea. Costurile de livrare pentru România la Google, intervalul de preț minim și maxim la eMAG, formatul disponibilității la Meta. Sunt ultimele pentru că sunt cele mai ușor de verificat și cele mai rar cauza reală.

Dacă după cei șase pași eroarea persistă și nu o poți reproduce, ce lipsește nu e o corecție, ci o măsurătoare: cineva trebuie să vadă exact ce a primit canalul, la ce oră, și ce servea site-ul în acel moment. Asta e verificarea automată a fluxului de date, și e diferența dintre a repara o eroare și a repara cauza ei.

Întrebări frecvente

De ce îmi sunt respinse produsele din feed?

În ordinea de prioritate din cont: mai întâi problemele care afectează tot contul, apoi avertismentele la nivel de produs, apoi dezaprobările propriu-zise, apoi dezaprobarea preventivă declanșată de neconcordanțe de preț sau disponibilitate între feed și pagină. Lista completă de produse afectate se descarcă în format CSV din fila „Needs attention”, iar cauza reală se găsește numărând pe câmp, nu citind exemple.

Cât de des trebuie actualizat feed-ul de produse?

Depinde de metoda de încărcare, nu de preferința ta. Un fișier găzduit la un URL e preluat de Google la fiecare 24 de ore, o foaie Google se sincronizează tot la 24 de ore, iar la o platformă conectată schimbările pot dura 24–48 de ore. Dacă prețul sau stocul trebuie să ajungă la client mai repede de o zi, ai nevoie de API, nu de un fișier actualizat mai des.

Pot folosi același feed pentru Google și pentru eMAG?

Aceleași date, da; același fișier, nu. eMAG nu preia un feed în același sens: produsul și oferta se trimit prin apeluri API, cu câmpuri pe care Google nu le are — preț fără TVA, interval minim și maxim obligatoriu, timp de procesare pe depozit, taxa verde. Sursa de adevăr rămâne una singură, în sistemul tău; ce se schimbă e stratul care o traduce pentru fiecare canal.

Am nevoie de cod de bare pentru fiecare produs?

Nu. La Google, gtin e marcat „depinde” și puternic recomandat când există; obligatoriu pentru toate produsele noi, cu excepțiile din specificație, e brand. Dacă produsul chiar nu are identificatori, trimiți identifier_exists=no, dar numai în cele trei situații documentate. La eMAG, regula e diferită: codul ean e obligatoriu pe anumite categorii, iar obligativitatea se citește din parametrul categoriei.

Ce se întâmplă dacă prețul din feed diferă de cel de pe site?

Câștigă pagina. Merchant Center actualizează automat prețul, prețul redus, disponibilitatea și starea produsului citindu-le din marcajul paginii de destinație, peste ce ai trimis. Consecința practică e că un feed corect nu te scutește de o pagină corectă, iar un preț afișat diferit în funcție de vizitator încalcă explicit cerințele și duce la dezaprobare.

Feed-ul înlocuiește datele structurate de pe site?

Nu, și nici invers. Marcajul de pe pagină poate fi sursa din care se construiesc datele de produs, prin preluare automată, dar metoda respectivă nu e compatibilă cu anunțurile de inventar local și cu listările locale gratuite. Practic, cele două straturi se verifică reciproc: feed-ul propune, pagina confirmă, iar diferența dintre ele devine eroare.

Magazinul tău are o a doua versiune și o scrii tu

Modelul de reținut e că feed-ul nu e un export, ci a doua versiune a magazinului tău — cea pe care o citesc mașinile. Are propria structură, propriile limite de caractere, propriul calendar de actualizare și propriile motive de respingere. Diferența față de prima versiune, cea pe care o vede omul, e că nimeni nu se plânge când a doua e stricată: produsele pur și simplu nu apar, iar tu tragi concluzia că nu e cerere.

Din asta decurge singura decizie de arhitectură care contează cu adevărat: unde ține magazinul tău sursa de adevăr. Dacă răspunsul e „în fiecare export separat”, atunci ai deja trei versiuni ale catalogului, care diverg cu fiecare lună. Dacă răspunsul e „într-un singur loc, din care se generează traduceri pentru fiecare canal”, atunci un canal nou costă o zi de mapare, nu o reconstrucție. Cele trei coloane din tabelul de mai sus nu sunt trei proiecte; sunt trei traduceri ale aceluiași text.

Testul pe care îl poți face în cincisprezece minute, azi, fără să deschizi niciun fișier:

1. alege un produs oarecare din catalog și deschide-i pagina publică, nu fișa din administrare;
2. deschide același produs în fila de produse a canalului pe care ai erori;
3. compară trei lucruri: prețul, disponibilitatea și titlul.

Dacă diferă, ai găsit deja cauza pentru care jumătate din catalog nu se afișează, iar restul articolului îți spune doar în ce ordine să repari. Dacă nu diferă, problema ta e la câmpurile specifice canalului — adică la pasul 6, cel ieftin. Oricare ar fi rezultatul, l-ai obținut comparând ce vede clientul cu ce vede mașina, și exact asta e operațiunea pe care nimeni nu o face lunar, deși e singura care prinde eroarea înainte s-o prindă canalul. Dacă vrei să ne uităm împreună la ce trimiți efectiv, cere un diagnostic.