Typické chyby ve feedu e-shopu a jak je opravit

Proč se odmítnutý produkt neohlásí sám a co vás to stojí

Odmítnutý produkt je neviditelný produkt. Zákazník ho na srovnávači nenajde, takže ho nekoupí, i kdyby to byl váš nejprodávanější kus. Rozdíl proti běžné chybě na webu je v tom, že se nic nerozbije a nikde se neobjeví červené hlášení. E-shop funguje dál, feed se generuje dál a mění se jediné: počet produktů na druhé straně.

Nedozvíte se to proto, že rozhodnutí padá jinde, než se díváte. Kanál si soubor stáhne, projde ho vlastní vstupní kontrolou a výsledek zapíše do svého rozhraní: do Merchant Center, do Centra prodejce Zboží.cz, do administrace Heureky. Váš e-shop se to nedozví a sám vám nic neohlásí.

My v Conviu, kde se správou feedů živíme, vidíme u nových klientů nejčastěji situaci, kdy o problému nikdo neví několik měsíců. Feed se tváří, že odešel, počty v administraci e-shopu sedí a chybějící část katalogu si nikdo nespojí s klesajícími tržbami z jedné kategorie.

Vysvětlení je skoro vždycky totéž: chyba je systémová, což je dobrá i špatná zpráva zároveň. Špatná je v tom, že vada nezůstane u jednoho produktu. Rozsypané kódování znehodnotí celý soubor a chybějící EAN u jednoho dodavatele vyřadí všechno, co od něj berete. Dobrá v tom, že se stejnou logikou dá i opravit: když spolu odmítnuté produkty něco sdílejí, stačí jedno pravidlo pro celou skupinu.

Do té doby ale platíte dvakrát. Přímo přicházíte o tržby z neviditelných produktů. Nepřímo platíte za reklamu u těch, které sice projdou, ale mají špatná data, takže z nich stejně nikdo nenakoupí. A necháte-li to běžet dlouho, přestane jít o jednotlivé položky. Google při plošných problémech s kvalitou dat pošle e-mail s příklady chyb a lhůtou 28 dnů na nápravu. Když se za tu dobu nic nestane, účet pozastaví a všechny položky z daného zdroje zmizí z reklam i z neplacených záznamů (Google Merchant Center, nápověda, 2026). Heureka má vlastní pojistku u dostupnostního souboru, tedy druhého, menšího feedu, kterým se hlásí jen skladová dostupnost. Obsahuje-li chybu déle než dvě hodiny, přestane ho stahovat úplně a znovu se do toho pustí, teprve až v administraci vynulujete počet neúspěšných pokusů (Heureka, nápověda k dostupnostnímu feedu, 2026).

Proto se chyby ve feedu vyplatí řešit průběžně. Nejde o to, že by čtvrtletní revize byla málo pečlivá. Jde o to, že mezi dvěma revizemi se z pár zamítnutých položek stane zastavený kanál.

Tři místa, kde se feed láme

Když se ptáte, proč Heureka odmítá vaše produkty, odpověď má tři různé podoby podle toho, kde se feed láme. Rozdíl mezi nimi je praktický: každé z těch tří míst se pozná podle jiného hlášení a opravuje se jiným zásahem. Než tedy začnete cokoli hledat v datech, zjistěte si nejdřív, na kterém z nich jste.

1. Kanál soubor vůbec nepřečte. Vada je v souboru jako celku a s jednotlivými produkty nemá co dělat. Poznávací znamení: kanál nehlásí počet zamítnutých položek, hlásí, že data nemá. Zboží.cz to v Diagnostice pojmenovává jako „Závažná chyba dat“ a doslova píše, že se hláška objeví ve chvíli, kdy je váš XML feed nepoužitelný (Seznam.cz, blog, březen 2026).
2. Kanál soubor přečte, ale produkt odmítne. Soubor je v pořádku, jen některé položky neprojdou vstupní kontrolou. Poznávací znamení: vidíte konkrétní počet dotčených produktů a název chyby. V Merchant Center je to karta „Vyžaduje pozornost“ na stránce Produkty, na Zboží.cz stav „Zamítnuté nabídky“ v Diagnostice.
3. Produkt projde a stejně se neprodává. Kanál nabídku přijal, ale nespojil si ji se správnou produktovou kartou. Poznávací znamení: v přehledech chyb nemáte nic, a přesto se produkt na srovnávači těžko hledá. Na Heurece to uvidíte v Přehledu spárovanosti pod řádkem Nespárované produkty, na Zboží.cz v Centru prodejce přes Sortiment, Nabídky a Párování.

Jedna vada se přitom do téhle řady nevejde úplně čistě. Je to nesoulad ceny nebo dostupnosti mezi feedem a webem: srovnávače ho nehlásí a spadá tedy do třetího místa, jenže Google ho hlídá aktivně a rovnou produkt zamítne. Uvidíte-li proto zamítnutí kvůli ceně, nehledejte chybu v datech. Porovnejte cenu ve feedu s cenou na produktové stránce.

Heureka se navíc od obou zbylých srovnávačů liší ještě v něčem podstatnějším. Obrazovku se seznamem zamítnutých položek, jakou má Merchant Center nebo Zboží.cz, pro hlavní XML feed nezveřejňuje. Její zpětná vazba stojí na párování, takže na Heurece začínáte vždycky v Přehledu spárovanosti. Najdete tam řádky Nespárované produkty a Ignorované kategorie. Třetí řádek, Nevyplněné povinné parametry, se týká Heureka Marketplace, ne výpisu nabídek. A jestli si soubor vůbec přečetla, ověříte nejrychleji sami: otevřete si adresu feedu v prohlížeči.

K tomu ještě jeden předpoklad, se kterým dál počítáme. Když se v článku mluví o pravidle nad daty, myslí se tím nastavení v nástroji na feedy, který stojí mezi e-shopem a srovnávačem a data cestou upravuje. Vypadá to zhruba takhle: „u všech produktů dodavatele Novák vezmi hodnotu z pole KOD_VYROBCE a zapiš ji do EAN.“ Napíšete ho jednou a platí pro všechny dotčené produkty. I pro ty, které od téhož dodavatele přibudou příště. Nemáte-li takový nástroj, zbývá oprava přímo v e-shopu: je pomalejší, ale platí naráz pro web i pro všechny srovnávače.

Tohle rozdělení není jen pořádek v hlavě. Rozhoduje o tom, kde budete hledat a co bude oprava stát. První případ je nejrychlejší: opravíte generování souboru a celý katalog se objeví při nejbližším stažení. Druhý potřebuje doplnit nebo srovnat hodnoty u konkrétních položek, třetí se ani nehlásí jako chyba a musíte si ho najít sami. Než se ale pustíme do jednotlivých chyb, je potřeba položit si ještě druhou otázku: jestli vada vzniká už ve vašich datech, nebo až při generování feedu. Podle ní se totiž pozná, kde se má opravovat.

Vzniká chyba v datech, nebo až při generování feedu?

Chyba může vzniknout na obou místech a rozdíl mezi nimi rozhoduje o tom, kde ji budete opravovat. Je to druhá otázka diagnostiky: první byla, kde se feed láme, tahle zní, kde vada vznikla.

Rozlišují se tu totiž dvě slova, která uslyšíte u každého nástroje na feedy. Import je všechno, co do nástroje přitéká z e-shopu nebo od dodavatele; export je soubor, který z něj vytéká ven pro konkrétní kanál. Buď je tedy hodnota špatná už na importu, a pak je potřeba opravit zdroj. Nebo data v e-shopu sedí a ve výsledném feedu jsou jinak, což znamená, že chyba vzniká až na exportu, typicky špatným mapováním nebo pravidlem.

Rozhodne to jednoduchý test: porovnejte hodnotu v administraci e-shopu s hodnotou ve vygenerovaném feedu. Když se liší, je problém v transformaci; když je špatná na obou místech, je v datech. V Conviu obě hodnoty ukazuje vedle sebe záložka Elementy Import/Export u produktu.

Příklad: produkt má v e-shopu cenu 1 290 Kč, ale ve feedu je zapsaná s desetinnými místy, která kanál neumí přečíst. Cena v e-shopu je správně, problém vzniká až formátováním při exportu, takže opravíte pravidlo pro výstup a karty produktů necháte být. V e-shopu byste se jen marně hrabali ve správných datech.

Tenhle rozdíl rozhoduje ještě o jedné věci: kolik kanálů oprava zasáhne. Vady na exportu se opravují jen pro jeden kanál a ostatní výstupy se nemění. Vady na importu se naopak vyplatí opravit u zdroje, protože se propíšou i na váš web a do všech ostatních feedů najednou. Jak se opravená data posílají zpátky do e-shopu, popisuje článek o obohacení a transformaci feedu.

Feed se nepřečte celý: kódování a rozbitá struktura

Soubor, který se nepřečte, neprojde celý najednou. Ze všech chyb to vypadá nejhůř, jenže se opravuje nejlevněji: příčina bývá jedna jediná a leží v generování souboru, tedy mimo váš katalog.

Nejdřív ale vylučte nejbanálnější možnost: soubor na dané adrese vůbec není. Poznáte to tak, že adresu feedu otevřete v anonymním okně prohlížeče. V běžném okně jste totiž přihlášení do administrace a soubor uvidíte i tehdy, když je pro kohokoli zvenčí zavřený. Nezobrazí-li se, je problém v přístupu k souboru a obsahem dat se zatím zabývat nemusíte.

Přístup řeší server, takže tohle je jedna z mála věcí, se kterou budete potřebovat hosting nebo programátora. Ten může robota srovnávače blokovat podle IP adresy, takže mu napište, ať ho pustí, a jmenujte ho: Heureka si pro feedy posílá Heurekabot-Feed, Zboží.cz i Google mají vlastní. Používáte-li nástroj na feedy, musí projít i ten; Conviu chodí z adres 217.16.177.43 a 217.16.177.44. U novějších instalací Shoptetu k tomu ověřte, že adresa feedu obsahuje jedinečný klíč ve tvaru ?hash=; bez něj vrátí prázdno.

Rozsypaná diakritika a kódování, které nesedí

Nejviditelnější podoba rozsypaného kódování je text, ve kterém se místo „ž“ a „ř“ objevují podivné znaky. Míň viditelná a horší podoba je ta, kdy se soubor nenačte vůbec.

Za rozsypaným textem i za nenačteným souborem přitom stojí jedna a tatáž příčina: v hlavičce souboru je napsané jedno kódování a uvnitř je jiné. Hlavička slibuje UTF-8, jenže export e-shopu poslal text ve windows-1250, což je na českých Windows běžné výchozí nastavení. Program, který soubor čte, to nepřejde. Norma XML takový nesoulad označuje výslovně jako fatální chybu, tedy stav, ve kterém zpracování končí (W3C, XML 1.0, sekce 4.3.3). Zvláštním případem je pak BOM, tedy pár neviditelných znaků na začátku souboru, kterými některé programy označují kódování. U XML v UTF-8 je povolený, u tabulek v CSV se ale umí přilepit k prvnímu názvu sloupce; sloupec EAN se pak jmenuje neviditelně jinak a kanál ho nenajde.

Jak si to ověříte: otevřete adresu svého feedu v prohlížeči a podívejte se na první produkty. Když je text rozsypaný v prohlížeči, bude rozsypaný i u kanálu. Na BOM se podíváte tak, že si soubor uložíte a otevřete v Poznámkovém bloku nebo ve VS Code; kódování se ukazuje ve stavovém řádku dole a bývá popsané jako „UTF-8 s BOM“.

Čím začít: nastavte export na UTF-8 bez BOM a zkontrolujte, že hlavička souboru říká totéž. Heureka i Zboží.cz s UTF-8 pracují jako s výchozím kódováním, takže je to nastavení, se kterým projdete u obou. Ta volba ale v hotových e-shopových řešeních, jako je Shoptet nebo Upgates, často chybí. Pak zbývají dvě cesty: požádat o změnu podporu platformy, nebo kódování převést až na výstupu v nástroji na feedy. Jak vlastně soubor s produkty vzniká, si můžete připomenout v základech XML a CSV feedu.

Nevalidní XML nebo rozbité CSV

Nevalidní soubor je takový, který nedodržuje pravidla svého formátu, takže ho program odmítne otevřít, i kdyby data uvnitř byla správná. U XML za tím stojí tři obvyklé příčiny a všechny vznikají tím, že se do textové hodnoty dostane znak, který má v souboru jinou roli:

1. Znaky & a < v textu. Podle normy se nesmějí objevit ve své doslovné podobě, protože jimi začíná zápis entity a značky (W3C, XML 1.0, sekce 2.4). Stačí popis produktu se slovem „mléko & med“ a soubor je rozbitý.
2. Neuzavřený element. Typicky když se do popisu dostane HTML z redakčního systému a některá značka zůstane otevřená.
3. Sekvence ]]> uvnitř popisu. Popisy se ve feedu často balí do bloku zvaného CDATA, který říká „tenhle text neber jako značky, ale doslova“. Blok končí právě znaky ]]>. Popis, ve kterém se tahle trojice objeví, ho tedy ukončí dřív, než měl, a zbytek souboru se rozsype. Přepsat ji nejde; oprava spočívá v tom, že se popis rozdělí na dva bloky tak, aby trojice zůstala rozlomená mezi ně. To je práce pro toho, kdo feed generuje.

K tomu si Heureka přidává ještě dvě vlastní pravidla: adresa nesmí být relativní ani obsahovat mezery a názvy prvků musí být velkými písmeny (Heureka, specifikace XML feedu, 2026).

Oproti tomu u tabulek v CSV se soubor láme na čárkách a uvozovkách uvnitř hodnot. Pole, ve kterém je čárka, uvozovka nebo zalomení řádku, musí být celé v uvozovkách a uvozovka uvnitř takového pole se zdvojuje (RFC 4180). Popis produktu s rozměry „šířka 30, výška 45“ tedy bez uvozovek posune všechny další sloupce o jeden doprava a od toho řádku dál nesedí nic.

Jak si to ověříte: otevřete adresu feedu v prohlížeči. U nevalidního XML prohlížeč obsah nezobrazí a místo něj napíše, co a na kterém řádku ho zastavilo. Samotný soubor si pak uložte klávesou Ctrl+S, otevřete ho v Poznámkovém bloku nebo ve VS Code a skočte na ten řádek (ve VS Code klávesou Ctrl+G).

Čím začít: produkt z toho řádku si otevřete v administraci e-shopu a podívejte se, čím se liší od ostatních. Skoro vždycky jde o znak v názvu nebo popisu, a skoro nikdy nejde o jediný produkt. Jakmile víte, který znak to je, hledáte ho hromadně ve zbytku katalogu.

Chybějící a neplatná pole, bez kterých produkt neprojde

Vstupní kontrola je okamžik, kdy kanál soubor už přečetl a rozhoduje o jednotlivých položkách. Poznáte ji podle toho, že místo hlášky o nepoužitelném souboru vidíte číslo: kolik produktů neprošlo a proč. Dva nejčastější důvody vypadají na první pohled podobně, protože v obou případech kanál hlásí chybějící nebo neplatnou hodnotu. Liší se ale tím, odkud se pro ně správná hodnota bere: chybějící popis si doplníte z vlastních dat, kdežto EAN má jediného majitele, a tím je výrobce.

Chybí povinné pole kanálu

Povinné pole je takové, bez kterého kanál nabídku nezpracuje. Potíž je v tom, že „povinné“ znamená u každého kanálu něco jiného a seznamy se nepřekrývají: popis produktu je u Zboží.cz povinný a u Heureky ne, u obrázku je to naopak. Zboží.cz ke svému seznamu navíc dodává jednou větou, co se stane při jeho nedodržení: XML bez povinných značek nelze použít k inzerci na Zboží.cz (Sklik, specifikace XML feedu, 2026). Vyplatí se proto podívat se na požadavky tří hlavních kanálů vedle sebe.

Zdroje: Heureka, specifikace XML feedu · Sklik, specifikace XML feedu pro Zboží.cz · Google, specifikace produktových dat, vše ověřeno v srpnu 2026.

U Heureky si jeden rozpor zaslouží vysvětlení. Slovem „povinné“ označuje její specifikace jen čtyři prvky: ITEM_ID, PRODUCTNAME, PRICE_VAT a URL. Obrázek IMGURL, kategorie CATEGORYTEXT, doprava DELIVERY a doba expedice DELIVERY_DATE mezi nimi nejsou, figurují jen v seznamu toho, co obsahuje kvalitní soubor. Prakticky to ale žádná úleva není: bez kategorie se nabídka nespáruje, bez obrázku si jí zákazník mezi ostatními nevšimne a u dopravy platí zvláštní pravidlo popsané níž. Bezpečná úvaha proto zní: první čtyři pole rozhodují o tom, jestli produkt vůbec projde vstupní kontrolou, a druhá čtyřka o tom, jestli se pak vůbec dostane před zákazníka. Takhle vypadá položka, která je má všechny pohromadě. V prvku PRODUCT si všimněte dovětku o osobním odběru: je to součást názvu nabídky, nikoli nastavení dopravy, a proč to tak je, vysvětluje kapitola o dopravě níž.

<SHOPITEM>
  <ITEM_ID>KOLO-AUTHOR-SIMPLEX-2026-YEL</ITEM_ID>
  <PRODUCTNAME>Městské kolo Author Simplex 2026, žluté</PRODUCTNAME>
  <PRODUCT>Městské kolo Author Simplex 2026, žluté – osobní odběr v Praze</PRODUCT>
  <DESCRIPTION>Lehké městské kolo s nízkým rámem...</DESCRIPTION>
  <URL>https://www.mujeshop.cz/kolo-author-simplex</URL>
  <IMGURL>https://www.mujeshop.cz/foto/kolo.jpg</IMGURL>
  <PRICE_VAT>19990</PRICE_VAT>
  <EAN>8591234567890</EAN>
  <CATEGORYTEXT>Heureka.cz | Sport | Cyklistika | Městská kola</CATEGORYTEXT>
  <DELIVERY_DATE>0</DELIVERY_DATE>
  <DELIVERY>
    <DELIVERY_ID>CESKA_POSTA</DELIVERY_ID>
    <DELIVERY_PRICE>89</DELIVERY_PRICE>
    <DELIVERY_PRICE_COD>119</DELIVERY_PRICE_COD>
  </DELIVERY>
</SHOPITEM>

Jak si to ověříte: v Merchant Center otevřete stránku Produkty a kartu „Vyžaduje pozornost“. Kliknutím na název problému se rozbalí podrobnosti, u každé karty je počet dotčených produktů a celý výběr si můžete stáhnout (Google Merchant Center, nápověda, 2026). Na Zboží.cz totéž najdete v Centru prodejce v sekci Diagnostika.

Čím začít: stáhněte si seznam dotčených produktů a podívejte se na sloupec, který u nich chybí. Když jde o pole, které v e-shopu prostě nemáte (typicky popis u zboží od dodavatele), doplňte ho pravidlem nad feedem; jak se taková pravidla staví, rozebírá článek o obohacení a transformaci feedu. Nemáte-li pole čím naplnit, je lepší produkt z výstupu úplně vyřadit než posílat prázdnou hodnotu. Prázdné pole se totiž počítá jako chybějící a jen vám navyšuje počet zamítnutých položek.

Chybějící nebo neplatný EAN a GTIN

GTIN je mezinárodní kód, který produktu přiděluje jeho výrobce a podle kterého se pozná, že vaše nabídka a nabídka konkurence jsou tentýž kus zboží. Třináctimístný EAN, na který jste zvyklí z čárových kódů, je jeho nejběžnější podoba, takže se obě označení v praxi používají zaměnitelně. Kanály ho proto chtějí, a chybuje se u něj dvěma opačnými směry: buď chybí tam, kde má být, nebo se do pole dosadí něco vymyšleného.

Google ho přitom nežádá plošně, ale podmíněně. Ve specifikaci produktových dat stojí u atributu gtin „Povinný (u všech produktů se známým kódem GTIN k aktivaci plného výkonu nabídky)“, u ostatních produktů pak „Volitelný (důrazně se doporučuje)“. Přeloženo do češtiny: má-li produkt kód od výrobce, Google ho chce (Google, specifikace produktových dat, 2026). Kód, který výrobce nikdy nepřidělil, tedy u vlastní výroby ani u privátní značky uvádět nemusíte. Když ale kód existuje a vy ho ve feedu vynecháte, Google k tomu píše, že takové produkty „mohou mít omezenou viditelnost“ (Google Merchant Center, nápověda, 2026). Nabídka se tedy nezamítne, jen se prosadí hůř než konkurence, která kód posílá.

Nákladnější je ale opačná chyba, tedy dosadit do pole GTIN vlastní skladové číslo, aby pole nebylo prázdné. Google k tomu píše, že máte atribut (tedy pole ve feedu) nechat prázdný a neuvádět nesprávné identifikátory, například interní skladové číslo. A dodává: „Pokud uvedete nesprávné identifikátory, vaše produkty mohou být zamítnuty“ (Google Merchant Center, nápověda, 2026). Vymyšlený kód je tedy horší než žádný. U variant to platí zvlášť: tamtéž stojí, že „jestliže je váš produkt dodáván v několika barvách a velikostech, musíte pro každou z variant uvést jedinečný identifikátor produktu“. Zkopírovaný kód přes všechny velikosti tedy vyrobí duplicity.

Zato Heureka je v tomhle mírnější. EAN u ní není obecně povinný, ani když produkt kód má (Heureka, specifikace XML feedu, 2026). Povinný je jen u šesti kategorií: knih, učebnic, map a průvodců, filmů, hudby a komiksů. Zboží.cz ho mezi povinné značky neřadí vůbec, ale využívá ho při párování. Když je shoda mezi názvem nabídky a názvem produktu příliš nízká, přítomnost kódu EAN zvyšuje šanci na spárování (Sklik, nápověda k párování nabídek, anglicky, 2026).

Jak si to ověříte: v Merchant Center vyfiltrujte na kartě „Vyžaduje pozornost“ chyby s GTIN v názvu. Jsou tři a každá znamená něco jiného:

• Duplicitní kód GTIN: dva nebo více produktů má stejný kód.
• Neplatná hodnota: GTIN znamená, že kód nesplňuje pravidla pro GTIN, například vznikl přepsáním interního čísla.
• Neplatný kód GTIN v nepodporovaném formátu: kód obsahuje jiné znaky než číslice, má jiný počet číslic než 8, 12, 13 nebo 14, nebo neprojde kontrolou kontrolní číslice.

Čím začít: rozdělte si produkty bez kódu na dvě hromádky. U těch, které kód mít mají a vy ho nemáte, si ho vyžádejte od dodavatele nebo dohledejte v jeho ceníku. U těch, které kód nemají a mít nebudou, pole nechte prázdné a nic nevymýšlejte.

Hodnota je správná, jen v jiném tvaru

Nejhůř se hledá skupina chyb, u které v e-shopu všechno sedí. Cena je správná, váha je správná, identifikátor je vyplněný. Vada nevzniká v hodnotě, ale v jejím tvaru. Kanál čeká číslo v jiném formátu, jednotku jinak zapsanou, nebo hodnotu, která se nesmí opakovat u jiného produktu. Kdo hledá příčinu v administraci e-shopu, hledá ji marně, protože zdroj je v pořádku.

Špatný formát, jednotka nebo měna

Formát hodnoty je tvar, ve kterém ji kanál očekává: kolik desetinných míst, jaký oddělovač, jestli s jednotkou, nebo bez ní. Jedno správné řešení neexistuje, protože kanály se v něm rozcházejí. Kvůli tomu tentýž feed jednomu kanálu projde a druhý ho odmítne.

Právě na ceně je to vidět nejlíp. Google chce číslo a měnu podle normy ISO 4217, tedy zápis 150.00 CZK, a nejvýš dvě desetinná místa; cokoli za nimi automaticky zaokrouhlí (Google Merchant Center, nápověda, 2026). Heureka je volnější a výslovně připouští obě podoby: cena smí být uvedená jako 25000,50 i 25000.50. Zakazuje jen tečku jako oddělovač tisíců a víc než dvě desetinná místa (Heureka, specifikace XML feedu, 2026). Když tedy kanál cenu odmítne, obvykle není napsaná špatně. Je napsaná pro jiný kanál.

K tomu se přidávají čtyři případy z naší praxe, ke kterým se vracíme opakovaně a které v žádné diagnostice dat neuvidíte:

• Jednotka navíc u hodnoty. Hmotnost přijde ze zdroje zapsaná jako 500 g, jenže cílový systém čeká u prvku WEIGHT čisté číslo. Takhle se chová třeba Upgates, když do něj feed nahráváte. Stačí jednotku odebrat až na výstupu; v e-shopu se nic měnit nemusí.
• Měna, kterou účet nezná. Cena dorazí ze zdroje v eurech, ale vy prodáváte v Česku. Merchant Center takovou nabídku odmítne s chybou „Neplatná měna“ (Google Merchant Center, nápověda, 2026). Cenu přepočítejte a pošlete ji s kódem CZK.
• Pořadí sloupců v tabulce. Kaufland soubor odmítne, když sloupce nepřijdou v pořadí, které žádá; u jednoho feedu k odmítnutí stačilo, že sloupec locale stál jako první. Obsah bývá v pořádku, jen sloupce potřebují jiné řazení, a to se nastavuje na výstupu.
• Doprava pro nepodporovanou zemi. Feed nese dopravu do země, kterou účet v Merchant Center nepodporuje, a Google kvůli tomu produkt zamítne. Do výstupu pro Google taková doprava nepatří.

Jak si to ověříte: otevřete si adresu feedu v prohlížeči a projděte u pěti produktů jen ten prvek, o který jde: PRICE_VAT u ceny, WEIGHT u hmotnosti. Formátové vady se totiž týkají všech položek stejně, takže je poznáte i na malém vzorku. Pohodlnější je stáhnout si výstup jako tabulku a otevřít ho v Excelu; v Conviu na to slouží převod dat z XML do CSV.

Čím začít: otevřete si specifikaci daného kanálu u dotčeného prvku, poznamenejte si přesný požadovaný tvar a převod nastavte až na výstupu pro tenhle jediný kanál. Kdybyste kvůli formátu přepsali data přímo v e-shopu, rozbijete tím výstupy pro ostatní kanály. Přesně na to slouží master feed: jeden zdroj, různé výstupy.

Duplicitní ID položek

Identifikátor položky je hodnota, podle které kanál pozná, že jde pořád o tentýž kus zboží, i příště, až přijde nový soubor. Když ji dva produkty sdílejí, kanál neví, který z nich je který, a nabídky se navzájem přepisují nebo se ztratí.

K atributu id říká Google tři věci. Jednou použité ID už nikdy nedávejte jinému zboží a stejné ID nedávejte dvěma produktům ve stejné cílové zemi nebo jazyce. Zároveň platí, a to je oproti dřívějšku změna, že použití stejných ID v několika účtech Merchant Center je povolené a nezpůsobí zamítnutí kvůli duplicitám (Google Merchant Center, nápověda, 2026).

Máte-li tedy víc účtů pro víc trhů, duplicitou se trápit nemusíte; uvnitř jednoho účtu ano. Heureka k tomu popisuje ITEM_ID jako jednoznačnou a trvalou identifikaci produktu, tedy hodnotu, která má u jednoho zboží zůstat stejná napořád.

Duplicitní ID vznikají obvykle dvěma způsoby. Varianty převezmou identifikátor nadřazeného produktu, pod který patří, takže všechny velikosti trika sdílejí jedno ID. Nebo se identifikátor po vyřazení produktu uvolní a systém ho později přidělí jinému zboží.

Jak si to ověříte: stáhněte si výstup do tabulky a na sloupci s identifikátorem použijte v Excelu podmíněné formátování a volbu Duplicitní hodnoty. Duplicity se obarví a vy je uvidíte i s produkty, kterých se týkají. Funkci Odebrat duplicity na to nepoužívejte: řekne vám počet, jenže vám u toho smaže řádky.

Čím začít: složte identifikátor tak, aby byl jedinečný z podstaty, tedy z kódu produktu a rozlišovače varianty (například kód zboží plus velikost). Aby srovnávač poznal, že velikosti patří k sobě, přidejte k tomu u všech variant společný prvek ITEMGROUP_ID; ten označuje skupinu nabídek, které jsou vzájemně variantami téhož produktu.

Obrázek, který kanál nepřijme

Obrázek je u srovnávače první věc, kterou zákazník uvidí, takže si na něj kanály drží vlastní pravidla. Produkt s nevyhovujícím obrázkem buď neprojde, nebo se zobrazuje hůř než konkurence. U rozměrů navíc narazíte na jedinou vadu z celého článku, kterou žádné pravidlo nad daty nespraví: chybějící pixely se dopočítat nedají.

Google u nich navíc přitvrzuje. Minimum je 500 × 500 pixelů a od 31. ledna 2027 ho začne vyžadovat u všech kategorií produktů; varování u obrázků, které ho nesplňují, se v účtech objevují už od 14. dubna 2026 (Google Merchant Center, nápověda, 2026).

Google ale doporučuje jít výš. Pro dobrý výsledek chce Google 1500 × 1500 pixelů a víc a produkt má na fotce zabírat alespoň 75 % a nejvýš 90 % plochy. A co na obrázku naopak být nesmí (Google Merchant Center, nápověda k obrázkům, 2026):

• výzvy k akci a propagační výrazy,
• ceny a informace o dopravě zdarma,
• vodoznaky a loga značky,
• čárové kódy.

Druhá polovina problémů je naopak čistě technická a pravidlem se řeší: adresa obrázku musí být platná, na https a dostupná robotovi srovnávače. Heureka si pro obrázky posílá vlastní roboty, takže nestačí povolit na serveru jen Googlebota. A obrázek, který se načte vám, protože ho máte v mezipaměti prohlížeče, nemusí být dostupný nikomu jinému.

Jak si to ověříte: vezměte z feedu adresu obrázku a otevřete ji v anonymním okně prohlížeče. Když se obrázek nezobrazí vám, nezobrazí se ani kanálu. Rozměry hledat ručně nemusíte: Merchant Center malé obrázky sám hlásí, takže seznam dotčených produktů si stáhnete z karty „Vyžaduje pozornost“.

Čím začít: ten seznam si stáhněte a rozdělte podle toho, odkud fotky máte. U vlastních produktů jde o práci pro fotografa, kterou je potřeba naplánovat s předstihem před koncem ledna 2027. U zboží od dodavatele si vyžádejte fotky ve vyšším rozlišení; zvětšení malého obrázku ho jen rozmaže.

Nabídka, která se nespáruje na produktovou kartu

Produktová karta je stránka jednoho konkrétního výrobku, na které srovnávač shromažďuje nabídky všech obchodů. Když se vaše nabídka na kartu nespáruje, zákazník ji při porovnávání cen neuvidí, i když ji máte levnější. V žádném přehledu chyb se to přitom neobjeví: z pohledu srovnávače je všechno v pořádku, protože soubor se načetl, položka prošla a počet zamítnutých je nula. Nespáruje se ze dvou docela různých důvodů. Buď ji srovnávač nedokáže zařadit do své kategorie, takže se k párování vůbec nedostane, nebo se zařadit dá, jen se její název neshodne s žádnou existující kartou.

Kategorie mimo strom srovnávače (CATEGORYTEXT)

Kategorie ve feedu není totéž co kategorie ve vašem e-shopu. Srovnávač má vlastní strom kategorií a vaši nabídku do něj musí umět zařadit; když se mu to nepodaří, produkt buď skončí ve špatné sekci, nebo se do katalogu nedostane vůbec.

Heureka přitom zapisuje kategorii do prvku CATEGORYTEXT jako celou cestu, jejíž úrovně odděluje svislítko s mezerami po obou stranách. Ve specifikaci to vypadá takhle: Heureka.cz | Velké spotřebiče | Pračky a sušičky | Pračky. Vlastní kategorie použít smíte, jen se musí dát spárovat na strom Heureky, který je ke stažení jako XML export sekcí Heureky. Cesty, které vycházejí přesně z tohohle stromu, spáruje Heureka automaticky. Kategorie, které ještě nezná, jí projdou rukama a spáruje je sama, jen to chvíli trvá. Je-li vaše cesta nejednoznačná, Heureka ji zablokuje a nabídky pod ní se dál nepárují.

Stejně tak to má postavené Zboží.cz, jen s vlastním číselníkem: do feedu je potřeba uvádět kompletní cestu kategorie ze stromu kategorií Zboží.cz a jako oddělovač slouží svislá čára. Strojově čitelný strom je průběžně aktualizovaný v souboru categories.json, případně ke stažení pro Excel jako categories.csv.

Jak si to ověříte: v administraci Heureky otevřete záložku Přehled spárovanosti a v ní sekci Ignorované kategorie. Přesně tam skončí cesty, které Heureka nedokázala zařadit, a jsou to zároveň produkty, které dál nepostoupí.

Čím začít: stáhněte si strom srovnávače a cesty z něj kopírujte, místo abyste je přepisovali ručně; jediná chybějící mezera kolem svislítka stačí, aby se cesta nespárovala. Mapování, tedy přiřazení vašich kategorií k cizím, se dělá jednou a pak platí i pro nové zboží, které do dané kategorie přibude. Proto ho držte jako pravidlo nad feedem: v kartách jednotlivých produktů byste totéž museli udržovat znovu a znovu.

Název, podle kterého se páruje

Název nabídky je druhá věc, na které párování stojí, a u obou českých srovnávačů je to ta hlavní. Heureka má pro něj konkrétní pravidla: PRODUCTNAME má nejvýš 200 znaků a nemá obsahovat doplňkové informace typu dárek nebo pouzdro zdarma. U každé kategorie je navíc předepsané, co v názvu být má; u praček třeba výrobce a produktové číslo. Heureka k tomu dodává rovnou důsledek: když v názvu některá doporučená informace chybí, může produkt v dané kategorii zablokovat (Heureka, doporučené názvy, 2026). Strohý název „Tričko“ si tedy o problém opravdu říká.

Zároveň posílá Heureka ještě druhý název, prvek PRODUCT. Obsahuje totéž co PRODUCTNAME plus případnou informaci o distribuci nebo osobním odběru. Záměna těch dvou prvků feed nerozbije. Když PRODUCT neposíláte, Heureka si ho prostě zkopíruje z PRODUCTNAME. A když se oba názvy příliš liší, páruje podle PRODUCT a PRODUCTNAME nebere v potaz (Heureka, vzájemné využití tagů, 2026). Pozornost proto patří tomu prvku, na který se nikdo nedívá. PRODUCT za vás obvykle vygeneruje šablona e-shopu a nikdo ho pak nečte, jenže Heureka páruje právě podle něj. Otevřete si feed v prohlížeči, projděte PRODUCT u deseti produktů a ověřte, že v něm je opravdu název zboží.

Stejně tak páruje podle názvu i Zboží.cz a EAN používá jako pomůcku, když je shoda nízká. Pravidla má jen o něco volnější: PRODUCTNAME smí mít až 255 znaků, doporučuje se ale zůstat kolem sedmdesáti.

Jak si to ověříte: na Heurece otevřete Přehled spárovanosti a v něm řádek Nespárované produkty. E-shopy v placeném režimu, kde se platí za prokliky, si navíc mohou nechat vygenerovat Report nespárovaných produktů v CSV. U položek s vyplněným EANem v něm najdou rovnou návrh správného názvu a kategorie. Na Zboží.cz vede cesta přes Centrum prodejce do sekce Sortiment, dál Nabídky a Párování, kde je u každé nabídky tlačítko pro ruční spárování.

Čím začít: vezměte z reportu prvních padesát nespárovaných produktů a podívejte se, co mají v názvu společného. Skoro vždy jim chybí výrobce, produktové číslo nebo rozlišovač varianty. Doplnit se to dá pravidlem nad názvem, ruční párování si nechte na zbytek, který se nespáruje ani potom. V Conviu na to slouží párovač produktů do srovnávačů, který nespárované nabídky vyfiltruje i s návrhy karet.

Nespárování ale není jediný důvod, proč se schválený produkt neprodává. Existuje ještě jedna podoba téhož, která se jako chyba netváří vůbec. Produkt projde, spáruje se a cena sedí, a přesto se u řady dotazů neukáže, protože o něm feed říká málo. Rozhoduje o tom úplnost parametrů, tedy kolik toho feed o produktu vůbec řekne. Je to samostatné téma; vysvětluje ho článek o tom, proč o viditelnosti produktu rozhodují parametry.

Cena a dostupnost, které nesedí s webem

Nesoulad mezi feedem a webem je situace, kdy zákazník vidí na srovnávači jinou cenu než po prokliku na e-shop. Kanály to berou vážně, protože je to přesně ten druh zklamání, kvůli kterému lidé přestanou srovnávačům věřit.

Google to kontroluje aktivně. Googlebot pravidelně prochází vaše vstupní stránky a porovnává cenu ve zdroji dat s cenou na stránce nebo ve strukturovaných datech (Google Merchant Center, nápověda, 2026). Ceny v kódu stránky musí přesně odpovídat těm, které máte v Merchant Center.

U dostupnosti je laťka ještě vyšší, protože se porovnává na víc místech zároveň: na vstupní stránce, na stránce placení a ve zdroji dat, a máte-li je, tak i ve strukturovaných datech. Google k tomu píše, že „neshoda v jednom z údajů bude mít za následek zamítnutí produktu“ (Google Merchant Center, nápověda k dostupnosti, 2026).

Pojistka naštěstí existuje. Automatické aktualizace položek si cenu a dostupnost samy opraví podle vaší stránky a jsou zapnuté ve výchozím stavu (Google Merchant Center, nápověda k automatizacím, 2026). O tuhle výpomoc ale můžete přijít: když se údaje ve feedu a na stránce liší příliš často, Google ji pro účet vypne.

Nesoulad ale nemusí být vaše chyba. Někdy jde jen o důsledek toho, jak často si srovnávač feed stahuje. Heureka si soubor bere každé dvě hodiny v placeném režimu a každé čtyři hodiny v bezplatném režimu (Heureka, specifikace XML feedu, 2026). Na Zboží.cz si frekvenci nastavíte v rozmezí jednou až dvanáctkrát denně. Akce spuštěná v deset ráno se tedy na srovnávači objeví s odstupem a v mezičase tam visí stará cena.

O zobrazení ale nerozhoduje jen shoda s webem. Zboží.cz navíc srovnává vaši cenu s rozpětím ostatních nabídek u téhož produktu, a jste-li mimo něj, nabídka se sice spáruje, ale u produktu se nezobrazí. Podezřele levné zboží proto může zmizet z docela jiného důvodu, než je chyba v datech (Sklik, nápověda k párování nabídek, anglicky, 2026).

Jak si to ověříte: vyberte si tři produkty, u kterých právě běží sleva, a porovnejte cenu ve svém výstupním feedu s cenou na produktové stránce. Když se liší, znáte velikost problému, aniž byste čekali na hlášení kanálu. U podezřele levné položky se na Zboží.cz podívejte na kartu produktu a srovnejte svou cenu s ostatními nabídkami; často jde o jiné balení nebo jinou variantu, kterou máte spárovanou omylem.

Čím začít: zvyšte frekvenci stahování na maximum, které kanál dovolí. K tomu doplňte na produktové stránky strukturovaná data s cenou a dostupností, podle kterých si Google údaje sám dorovná v mezičase mezi dvěma feedy. Jak se nasazují na produktovou stránku, rozebírá samostatný článek o strukturovaných datech.

Heureka a Zboží.cz: pravidla, která jinde neplatí

České srovnávače mají nad rámec obecných pravidel vlastní požadavky, na kterých e-shopy opakovaně padají: dopravu, energetické štítky a doplňkové služby. Nejsou nijak tajné, jen se na ně snadno zapomene: obecná pravidla feedu je nepokrývají.

Doprava se u Heureky vybírá z číselníku

Když u produktu uvedete dopravu volným textem, Heureka ji nezobrazí vůbec. Doprava u ní totiž není prostý text, ale strukturovaný prvek DELIVERY, uvnitř kterého musí být identifikátor dopravce DELIVERY_ID, cena dopravy DELIVERY_PRICE a cena při platbě na dobírku DELIVERY_PRICE_COD. Dopravce se nevypisuje slovy, ale vybírá ze seznamu, který Heureka udržuje. Člení se na doručení na adresu, výdejní místa, výdejní boxy a ostatní možnosti a Balíkovna České pošty v něm má vlastní identifikátor.

Číselník se přitom v čase mění a dřív se do něj dopravci přidávali na požádání; pro dopravu, kterou v seznamu nenajdete, dnes slouží hodnota VLASTNI_PREPRAVA. Návody kolující po internetu proto často uvádějí identifikátory, které už neplatí. Aktuální seznam si vždycky opište přímo ze specifikace XML feedu Heureky, ne z cizího článku.

Navíc se u dopravy opakují dvě chyby. První je uvedení dvou dopravců u jednoho produktu; Heureka k tomu píše přímo, že tím způsobíte chybu a ani jednu dopravu nezobrazí. Druhá je souběh s administrací: zvolíte-li dopravu přes feed, dopravu vyplněnou v administraci Heureka zcela pomine, protože prvek DELIVERY má přednost. Osobní odběr jako způsob doručení přes XML zadat nejde a nastavuje se výhradně v administraci. Text „osobní odběr v Praze“ v prvku PRODUCT je něco jiného: součást názvu nabídky, ne nastavení odběrného místa.

Energetický štítek: povinnost z EU, kterou chce i Zboží.cz

Energetický štítek je povinné označení spotřebičů a od 1. března 2021 má novou stupnici: plusové třídy skončily a označení se vrátilo k písmenům A až G, takže z původního A+++ se stalo B až D.

Pro feed z toho plyne konkrétní požadavek na straně Zboží.cz. Odkaz do evropské databáze EPREL se tam zapisuje vlastním prvkem EPREL_ID a bez něj se produkt nemusí správně zobrazit (Sklik, pravidla Zboží.cz pro energetické štítky, 2026). Seznam dotčeného zboží je přitom širší, než by čekal ten, kdo si vybaví jen přeznačení bílé techniky:

• chladicí spotřebiče (ledničky, mrazničky, vinotéky) a chladicí zařízení s přímým prodejem,
• pračky, pračko-sušičky, sušičky prádla a domácí spotřebiče s funkcí sušení,
• myčky nádobí a varné spotřebiče,
• televizory a elektronické displeje,
• chytré telefony a tablety,
• světelné zdroje,
• klimatizace a ventilace,
• ohřívače vody a zásobníky, kotle a topné systémy,
• pneumatiky.

Prodáváte-li tedy mobily nebo pneumatiky, EPREL_ID se týká i vás; kompletní výčet výrobků najdete v databázi EPREL. U Heureky obdobný prvek v aktuální specifikaci feedu není, takže energetickou třídu tam posílejte jako běžný parametr produktu. Povinnost zobrazit štítek a informační list u dotčeného zboží ale platí pro e-shop vždycky, bez ohledu na to, co po vás žádá který srovnávač.

Prodloužená záruka a doplňkové služby mají vlastní prvky

Prodloužená záruka a doplňkové služby se často píšou do názvu produktu, kam nepatří: Heureka doplňkové informace v PRODUCTNAME nechce a produkt kvůli nim může v kategorii zablokovat. Mají proto vlastní prvky.

Chcete-li na Heurece zobrazit prodlouženou záruku, je vyplnění prvku EXTENDED_WARRANTY povinné a doba prodloužení se uvádí v měsících. Bez něj se záruka u nabídky prostě neukáže. Doplňkové služby typu vynesení do patra nebo odvoz obalu patří do prvku SPECIAL_SERVICE, kterých smí být u jednoho produktu nejvýš pět.

Zároveň záruku i doplňkové služby přidáte do feedu pravidlem, aniž byste zakládali nové parametry v e-shopu. A platí pro ně totéž co pro všechny ostatní chyby: univerzální feed pro srovnávače neexistuje. Existuje jeden zdroj dat a z něj dva různé výstupy, jeden pro Heureku a jeden pro Zboží.cz, a pravidla obou se řeší na výstupu, jedním zásahem pro celou skupinu produktů.

Jak chybu najít a opravit jedním pravidlem

Postup, který funguje, má čtyři kroky a jejich pořadí není libovolné: každý z nich zužuje okruh míst, kde se dá hledat.

1. Začněte tam, kde chybu hlásí kanál. V Merchant Center je to karta „Vyžaduje pozornost“, na Zboží.cz sekce Diagnostika v Centru prodejce, na Heurece Přehled spárovanosti. Je to jediné místo, které vám řekne důvod odmítnutí; všechno ostatní je odhad.
2. Ověřte požadavek proti specifikaci kanálu. Než začnete hodnotu měnit, přečtěte si, jak ji kanál chce. Většina zbytečné práce vzniká z toho, že si autor pravidla domyslel formát podle jiného kanálu.
3. Vezměte vzorek a hledejte společný jmenovatel. Otevřete si dvacet odmítnutých položek a ptejte se: je to stejná kategorie? stejný dodavatel? jsou to samé varianty? Ta odpověď je tou skutečnou diagnózou, protože z ní plyne, jak široké pravidlo budete psát.
4. Opravte to jedním pravidlem pro celou skupinu. Protože je chyba systémová, ruční oprava u jednotlivých produktů je nejen pomalá, ale i nespolehlivá: u příštího importu se vada vrátí.

Modelově to vypadá takhle. Merchant Center hlásí 240 odmítnutých produktů s chybou kolem GTIN. Ve vzorku dvaceti položek zjistíte, že jde výhradně o zboží jednoho dodavatele, který kódy neposílá. Místo ručního dohledávání nastavíte jedno pravidlo: kód doplníte z jiného pole, kde ho dodavatel schovává, a u produktů, které ho nemají, necháte pole prázdné. Jedním zásahem vyřešíte všech 240 položek a s nimi i všechno, co od téhož dodavatele přibude příště.

Právě tady se vyplatí feed editor. Ve feed editoru Conviu opravíte data transformací: doplníte chybějící parametr, sjednotíte kategorie, nahradíte text, přepočítáte hodnoty, a to bez zásahu do e-shopu a pro všechny dotčené produkty naráz. Zdroj zůstává, jak je; čistý je až výstup pro kanál.

Jak chybám předcházet

Levnější než opravovat je nechybovat, a kontrolu feedu už dnes nemusíte dělat až podle stížností kanálu. Většinu toho, co se v praxi láme, pokryjí tři věci, které si nastavíte jednou a pak už jen sledujete.

Validace feedu před odesláním

Validace je kontrola, která projde vygenerovaný soubor proti požadavkům cílového kanálu dřív, než si ho kanál stáhne. Nástroje na ni jsou zdarma a u dvou kanálů je nabízí přímo provozovatel.

Google má zkoušku zdroje přímého nahrávání: ukáže náhled produktových dat, aniž byste přepsali stávající zdroje, takže dopředu vidíte, kolik položek by prošlo a kolik ne. Je to nejlevnější způsob, jak si ověřit větší zásah do feedu, protože běžící reklamy zůstanou netknuté, i když se v novém souboru něco nepovede. Heureka má obdobu pro dostupnostní soubor: nástroj „Zkontrolovat XML soubor“ v administraci, kterému stačí zadat adresu souboru. Kontroluje ale jen strukturu podle specifikace, ne věcnou správnost dat (Heureka, nápověda k dostupnostnímu feedu, 2026).

Máte-li nástroj na feedy, kontrolu spustíte rovnou nad výstupem. V Conviu je to validace exportních dat, která vrátí seznam chyb i s konkrétními prvky. Víte tak, že problém je třeba v PRICE_VAT, ještě než soubor kdokoli stáhne.

Upozornění, když počet produktů spadne

Upozornění, kterému se v nástrojích říká alert, je e-mail, který vám přijde, když se u importu nebo exportu změní stav. Vyplatí se ho nastavit i tehdy, když feed hlídáte, protože zachytí přesně ty chyby, které se nikde neohlásí jako chyba.

Nejcennější je ale upozornění na to, že se vyexportovalo výrazně míň produktů než jindy. Tak se totiž pozná systémová chyba, která se nikde neohlásila, jen odřízla část katalogu. Upozornění na selhání i na propad počtu produktů si v Conviu nastavíte v alertech a reportech.

Kontrola vzorku po každé změně

Změna šablony e-shopu, nový dodavatel nebo úprava kategorií je nejčastější okamžik, kdy se feed rozejde s realitou. Nemusíte procházet celý katalog: stačí deset produktů z dotčené skupiny porovnat mezi e-shopem a výstupem. Zabere to pár minut a chytí to většinu vad dřív, než je uvidí kanál.

Když na to nechcete být sami

Zpátky k té třetině katalogu, která na srovnávači chybí. Nemusíte dopředu vědět, co přesně je rozbité. Stačí se podívat, co kanál hlásí: jestli nemá data, jestli hlásí počet zamítnutých položek, nebo nehlásí nic. Tím máte skupinu, a skupina se opravuje jedním pravidlem.

S tím vám umíme pomoct. Propadají-li vám produkty opakovaně a nechcete trávit hodiny v diagnostikách, napište nám a feed projdeme za vás. Zvažujete-li, jestli se o feedy starat svépomocí, nebo je předat, srovnání obou cest včetně cen nabízí samostatný článek.

Začínáte-li s feedy teprve teď, projděte si nejdřív základy XML a CSV feedu. Širší kontext pak najdete v průvodci produktovými feedy a napojením.