Feed pro Google Merchant Center: struktura a validace

Většina chyb v Merchant Center nevzniká v Google Ads, ale ve feedu. Špatně zapsaná měna, datum bez časového pásma, GTIN s chybnou kontrolní číslicí. Každá taková drobnost znamená varování nebo zamítnutý produkt.

V tomto článku se díváme na feed pro Google technicky: jaké formáty Merchant Center přijímá, jak má vypadat struktura, jak zapisovat hodnoty a jak feed validovat. Nastavení účtu a kampaní popisujeme v článku Google Nákupy: nastavení feedu a kampaní a provozní zásady účtu v článku Google Merchant Center: best practices. Stav je k září 2026.

Formáty a cesty, jak dostat data do Merchant Center

Merchant Center přijímá produktová data pěti způsoby. Každý se hodí na něco jiného.

Pro soubory platí podle nápovědy Googlu:

• Jeden soubor může mít až 4 GB. Limit platí i pro soubor stahovaný podle plánu.
• Adresa musí začínat http://, https:// nebo sftp:// a vést přímo na soubor.
• Výchozí plán stahuje soubor jednou za 24 hodin, frekvenci lze upravit.
• Soubory RSS a Atom musí končit příponou .xml. Soubor bez přípony Google zpracuje jako TSV.

Content API skončilo, nastupuje Merchant API

Google ukončil Content API for Shopping k 18. 8. 2026. Od 1. 9. 2026 začaly požadavky přes staré API postupně selhávat, pokud integrace nemá schválený prodloužený přístup. Nástupcem je Merchant API.

Změna se týká jen napojení přes API: vlastních skriptů, starších pluginů a některých feedových nástrojů. XML nebo TSV stahované z URL a Google tabulky fungují dál. Pokud si nejste jistí, jak váš e-shop data posílá, podívejte se v Merchant Center na seznam zdrojů dat. U zdroje typu API zjistěte u dodavatele pluginu, jestli už používá Merchant API. Nepřesunutá integrace se pozná podle toho, že ceny a dostupnost v Merchant Center přestanou odpovídat webu.

Struktura XML feedu

Nejčastěji pracujeme s RSS 2.0. Kořen tvoří rss s deklarací jmenného prostoru xmlns:g="http://base.google.com/ns/1.0", uvnitř je channel a v něm jeden element item na každou nabídku. Atributy produktu mají předponu g:.

Jedna varianta trička pak obsahuje například:

TSV má stejné atributy jako sloupce. První řádek obsahuje názvy atributů v angličtině, každý další řádek jeden produkt, oddělovačem je tabulátor. Atributy s podatributy se v TSV zapisují do jedné buňky s dvojtečkami, například doprava jako CZ:::79.00 CZK (země, region, služba, cena).

Formát hodnot: kde feed nejčastěji padá

Povinné atributy zná každý. Chyby vznikají ve formátu hodnot.

• Cena. Číslo s desetinnou tečkou a kód měny podle ISO 4217: 1299.00 CZK. Desetinná čárka nebo „Kč" místo CZK vede k chybě. V Česku uvádějte cenu s DPH.
• Akční cena. Původní cena zůstává v price, akční jde do sale_price. Období akce patří do sale_price_effective_date ve formátu ISO 8601 jako rozsah oddělený lomítkem, například 2026-10-01T00:00+02:00/2026-10-14T23:59+02:00.
• Dostupnost. Jen hodnoty in_stock, out_of_stock, preorder a backorder. U preorder a backorder je povinné availability_date. Datum musí být v budoucnu a nejvýš rok dopředu. Bez času a pásma ho Google bere jako půlnoc UTC.
• Varianty. Všechny varianty sdílejí item_group_id a liší se atributy size, color, material nebo pattern. Každá varianta má vlastní id a ideálně vlastní link.
• `id`. Nemění se. Změněné ID Google bere jako nový produkt, který znovu prochází kontrolou a přichází o historii výkonu.

GTIN a identifikátory

GTIN pomáhá Googlu zařadit produkt k dotazům a porovnat ho s nabídkami jiných obchodů. U zboží, kterému výrobce GTIN přidělil, ho uvádějte vždy. Na co dát pozor:

• GTIN má typicky 8, 12, 13 nebo 14 číslic. Evropský EAN má 13.
• Poslední číslice je kontrolní. Když nesedí, Google GTIN odmítne. Kontrolu kontrolní číslice děláme automaticky už při generování feedu.
• Kódy začínající dvojkou jsou vyhrazené pro interní použití v obchodech a validací neprojdou. Totéž platí pro nuly, opakující se číslice a testovací řady.
• Pokud GTIN neexistuje (vlastní výroba, zakázková výroba), uveďte brand a mpn. Když chybí i ty, použijte identifier_exists s hodnotou no. Jen u produktů, které identifikátor opravdu nemají.

U dodavatelských feedů je GTIN častý zdroj chyb. Dodavatel posílá interní kód v poli EAN nebo EAN s chybějící úvodní nulou. Proto kontrolu děláme už při importu dat od dodavatele, ne až ve feedu pro Google.

Cena a dostupnost musí sedět s webem

Google porovnává feed se vstupní stránkou a s pokladnou. Cena, akční cena, měna i dostupnost musí odpovídat tomu, co zákazník uvidí po prokliku. Nesoulad vede k zamítnutí produktu a opakované nesoulady mohou vést i k problémům na úrovni účtu.

Nejčastější příčiny nesouladu:

• Feed se generuje jednou denně, ale ceny a sklad se mění častěji.
• Web ukazuje cenu pro přihlášené nebo po slevovém kódu, feed běžnou cenu.
• Zaokrouhlení nebo DPH se počítá jinak ve feedu a na webu.
• Varianta ve feedu vede na stránku s jinou předvybranou variantou.

Pojistkou jsou automatické aktualizace položek. Google podle webu opraví cenu nebo dostupnost, pokud na stránce najde spolehlivá data. K tomu potřebuje strukturovaná data podle Schema.org s cenou, měnou a dostupností. Opravy ale berte jako signál, že feed nestíhá web, ne jako řešení.

Doplňkové zdroje a pravidla atributů

Primární zdroj přináší produkty. Doplňkový zdroj jen doplňuje nebo přepisuje atributy u produktů, které už v primárním zdroji jsou. Nový produkt přes něj nepřidáte. Pravidla, která hlídáme:

• Doplňkový zdroj obsahuje sloupec id a aspoň jeden další atribut.
• id musí přesně odpovídat primárnímu zdroji, včetně velkých a malých písmen.
• Štítek zdroje (feed label) musí odpovídat primárnímu zdroji, jinak se data nepropojí.

Typické použití: vlastní štítky pro marži a bestsellery, opravené titulky u části katalogu, cost_of_goods_sold z ERP. Jako doplňkový zdroj dobře funguje Google tabulka nebo malý TSV, který generuje skript.

Pravidla atributů upravují hodnoty přímo v Merchant Center pro zvolený zdroj dat a štítek. Hodí se na jednoduché transformace, třeba doplnění značky do titulku. Složitou logiku do nich nedáváme. Je špatně vidět, verzovat a testovat. Tu držíme v generátoru feedu.

Validace a diagnostika krok za krokem

1. Validita souboru. XML musí jít načíst, se správně deklarovaným jmenným prostorem g: a kódováním UTF-8. TSV musí mít správný počet sloupců v každém řádku.
2. Automatická kontrola před publikací. Povinné atributy, formát ceny a dat, povolené hodnoty dostupnosti, kontrolní číslice GTIN, délka titulku, odkazy na obrázky. Pokud se počet produktů oproti minulé verzi výrazně změní, feed nepublikujeme a spustíme upozornění.
3. Stav zdroje dat v Merchant Center. U každého zdroje vidíte poslední zpracování a chyby stažení či čtení souboru.
4. Problémy produktů. Přehled produktů, které vyžadují pozornost, s konkrétním atributem a počtem dotčených položek.
5. Problémy účtu. Varování na úrovni účtu mají přednost, protože mohou vypnout celý katalog.

Jak nastavit hlídání tak, aby chyba nečekala na týdenní kontrolu, popisujeme v článku Monitoring a alerty na chyby feedů.

Jak na to prakticky: checklist

• XML (RSS 2.0) nebo TSV stahované z URL, frekvence podle toho, jak často se mění ceny a sklad.
• Napojení přes API jen přes Merchant API.
• Ceny ve formátu 1299.00 CZK, s DPH, shodné s webem i pokladnou.
• availability_date u předobjednávek a zboží na objednávku.
• Stálé id, varianty přes item_group_id.
• GTIN s ověřenou kontrolní číslicí, jinak brand a mpn.
• Doplňkový zdroj pro štítky a opravy, složitá logika v generátoru feedu.
• Strukturovaná data na detailu produktu.
• Automatická validace před každou publikací a denní pohled do diagnostiky.

Feedy pro Google stavíme a udržujeme v rámci služby napojení dodavatelů a feedy, od importu dat dodavatele až po výsledný XML feed. Průběžné hlídání chyb řeší AI správce feedů.