Škálování e-shopu s rostoucím katalogem

Když má e-shop tisíc produktů, skoro všechno jde udělat ručně. Při deseti tisících začnete hromadně importovat. Při padesáti tisících zjistíte, že import běží celou noc, filtry v kategoriích se načítají několik sekund a Google indexuje hlavně kombinace parametrů, o které nikdo nestojí. Růst katalogu je dobrá zpráva pro obchod. Pro techniku je to test, jestli e-shop postavený pro start zvládne další fázi.

Tenhle článek je pro e-shopy, které katalog rozšiřují: přidávají dodavatele, varianty, jazyky nebo marketplace. Ukážeme, kde se limity projeví nejdřív a co udělat dřív, než začnou bolet.

Kde se růst katalogu projeví nejdřív

Problémy s velkým katalogem se neobjeví najednou. Přicházejí v typickém pořadí:

Nejdražší bývá poslední řádek. Technický limit se dá vyřešit vyšším tarifem nebo lepším serverem. Nepořádek v datech se s každým dalším produktem zhoršuje a jeho úklid stojí nejvíc.

Limity platforem: znát je předem

Každá platforma má stropy a je lepší je znát dřív, než na ně narazíte. Příklady (k 9/2026, aktuální podmínky ověřte u poskytovatele):

• Shoptet podle nápovědy omezuje počet produktů tarifem: Business 1 000, Profi 5 000, Enterprise 50 000. Limit se týká základních produktů, ne variant. Jeden produkt může mít až 512 variant. Větší katalogy řeší Shoptet Premium.
• Shopify zvýšilo limit na 2 048 variant na produkt, stále ale platí maximálně tři možnosti (například barva, velikost, materiál) a 250 médií na produkt. Obchody s 500 000 a více variantami mají podle changelogu denní limit 10 000 nově vytvořených variant.
• WooCommerce nemá pevný strop, výkon ale závisí na hostingu, databázi a pluginech. Pro filtrování používá tabulku atributů (product attributes lookup table), jejíž přegenerování bylo u produktů s mnoha variantami pomalé. WooCommerce 9.1 přineslo optimalizovaný způsob aktualizace a nástroje pro příkazovou řádku.

Z toho plyne praktická rada: katalog s tisíci variantami na produkt nebo s desítkami parametrů navrhujte podle cílové platformy, ne podle toho, jak data posílá dodavatel.

Importy a synchronizace ve velkém

Import, který při tisíci produktech trvá deset minut, při padesáti tisících netrvá padesátkrát déle. Často trvá mnohem déle, protože narazí na limity API, zámky v databázi a souběh s provozem. Co pomáhá:

• Posílat jen změny. Porovnat nová data s posledním stavem a aktualizovat jen rozdíly. U skladu a cen to bývá zlomek katalogu.
• Rozdělit toky. Katalog (názvy, popisy, obrázky) stačí jednou denně. Sklad a cena potřebují častější a lehčí aktualizaci.
• Používat hromadné operace. Shoptet nabízí asynchronní úlohy, WooCommerce dávkový endpoint, Shopify bulk operations v GraphQL.
• Pracovat přes frontu. Změny zapisovat do fronty zpráv a zpracovávat je postupně tempem, které platforma unese.
• Plánovat mimo špičku. Těžký import nemá běžet ve chvíli, kdy na webu nakupuje nejvíc lidí.

Podrobný postup je v článku Automatizace importů a exportů dat.

Data: jeden model místo pěti tabulek

S růstem katalogu roste počet zdrojů. Každý dodavatel pojmenovává parametry jinak, jiný má kategorie, jiné jednotky. Bez jednotného datového modelu vznikají „Barva“, „barva“ a „Colour“ jako tři různé filtry a stejný produkt od dvou dodavatelů jako dva produkty.

Co zavádíme u rostoucích katalogů:

1. Jednotný slovník parametrů a hodnot. Každý zdroj se mapuje na něj, ne přímo do e-shopu.
2. Pravidla pro párování produktů. EAN, kód výrobce, případně kombinace atributů. Víc v článku o konsolidaci více dodavatelů.
3. Jedno místo pravdy. Pro větší katalogy to bývá PIM, ze kterého se data posílají do e-shopu, na marketplace i do feedů.
4. Kontrola kvality. Automatická kontrola chybějících parametrů, obrázků a popisů u nových produktů.

PIM nepotřebuje každý. Vyplatí se, když prodáváte ve více kanálech nebo jazycích a produktová data upravuje víc lidí. Rozhodování popisujeme v článku PIM systém: kdy ho e-shop potřebuje.

Výkon webu: filtry, vyhledávání a cache

Samotný počet produktů v databázi web zpomalovat nemusí. Zpomalují ho konkrétní operace:

• Filtry v kategoriích. Počítání, kolik produktů odpovídá každé hodnotě každého parametru, je náročné. Pomáhá cache výsledků a omezení filtrů na parametry, které zákazníci opravdu používají.
• Fulltextové vyhledávání. Hledání v databázi přes LIKE při desítkách tisíc produktů přestává stačit. Řešením je specializovaný vyhledávací index nebo externí služba.
• Stránkování a řazení. Hluboké stránky kategorií a řazení podle vypočtených hodnot zatěžují databázi.
• Invalidace cache. Když import mění ceny tisíců produktů, nesmí najednou vymazat celou cache webu.

U pronajímaných platforem tohle většinou řeší provozovatel a vy ovlivníte hlavně počet parametrů, doplňky a šablonu. U open source a vlastních řešení je to práce pro vývojáře a hosting. Víc k databázím v článku Databázová architektura pro velké produktové katalogy.

SEO: filtry a crawl budget

Google ve své dokumentaci uvádí, že optimalizace crawl budgetu se týká hlavně webů s více než milionem unikátních stránek, nebo webů s více než 10 000 stránkami, jejichž obsah se mění denně. E-shop s pár tisíci produkty se tam může dostat snadno: stačí facetová navigace, která z každé kombinace filtrů vyrobí novou URL.

Google sám píše, že facetová navigace je nejčastější příčinou nadměrného procházení, které mu majitelé webů hlásí. Doporučuje:

• zakázat procházení filtrovaných URL v robots.txt, pokud je nepotřebujete v indexu,
• pokud je v indexu chcete, držet stálé pořadí filtrů v URL a nepřipustit duplicitní kombinace,
• u kombinací bez výsledků vracet stavový kód 404,
• pomocí rel="canonical" označit hlavní verzi stránky.

Vyberte pár filtrů, které mají reálnou hledanost (třeba značka nebo typ), a z nich udělejte plnohodnotné landing pages. Zbytek držte mimo index. Podrobněji v článku Crawl budget a velké e-shopy.

Architektura: kdy e-shop rozdělit

Od určité velikosti přestává dávat smysl, aby jeden systém dělal všechno. Typicky se oddělují:

• Synchronizace dodavatelů a skladu do samostatné služby, která běží mimo e-shop a do e-shopu posílá jen hotové změny.
• Vyhledávání a filtrování do specializovaného indexu.
• Feedy pro srovnávače a marketplace, které se generují z vlastní kopie dat, ne dotazy na živý e-shop.

Nejde o módní mikroslužby. Jde o to, aby těžká práce na pozadí nebrzdila nákup. Kdy se takové rozdělení vyplatí, rozebíráme v článku o microservices architektuře pro rostoucí e-shop.

Jak na to prakticky

Checklist před tím, než katalog zdvojnásobíte:

• Znáte limity své platformy a tarifu na produkty, varianty a média?
• Aktualizujete sklad a ceny jen rozdílově a v dávkách?
• Máte jednotný slovník parametrů a pravidla párování produktů?
• Víte, které filtry mají být v indexu a které ne?
• Měříte rychlost kategorií a vyhledávání, ne jen homepage?
• Běží těžké importy mimo obchodní špičku?
• Dozvíte se o chybě importu dřív než zákazník?

Pokud si na víc otázek odpovídáte „nevím“, ozvěte se. Projdeme katalog, integrace a výkon a navrhneme, co řešit teď a co až při dalším růstu. Oddělení synchronizace nebo vyhledávání do samostatných služeb stavíme v rámci API a microservices, dlouhodobý dohled nad rychlostí a chybami zajišťuje Performance Monitoring.