Headless CMS: Když se klasický CMS stane brzdou

Klient provozoval e-shop na WordPressu s WooCommerce. Na první pohled fungoval - produkty se zobrazovaly, objednávky procházely. Jenže pod kapotou běželo 47 aktivních pluginů, šablona z ThemeForest stará čtyři roky a frontend propletený s backendem tak, že každá změna banneru na hlavní stránce vyžadovala zásah vývojáře. Načítání stránky trvalo přes 6 sekund na mobilu. Obsahový tým měl přístup do WordPressu, ale bál se cokoli měnit, protože poslední úprava rozbila rozložení produktové stránky na tři dny.

Přestavěli jsme frontend na Nuxtu a WordPress jsme ponechali jako headless CMS backend pro správu obsahu. Načítání kleslo na 1,2 sekundy. Obsahový tým začal publikovat samostatně - bez vývojáře, bez strachu. Objednávky z organického vyhledávání vzrostly o 34 % během prvních dvou měsíců, hlavně díky lepšímu výkonu na mobilu.

Tohle není příběh o tom, že WordPress je špatný. Je to příběh o tom, kdy přestane stačit a co s tím jde dělat.

Co headless ve skutečnosti znamená

Klasický CMS jako WordPress spojuje dvě věci dohromady: správu obsahu (backend) a zobrazení obsahu (frontend). Téma určuje, jak stránka vypadá. Pluginy přidávají funkce. Všechno běží na jednom serveru, v jedné PHP aplikaci. Když uživatel navštíví stránku, WordPress sestaví HTML z databáze, prožene ho přes téma a pošle do prohlížeče.

Headless CMS odděluje tyto dvě vrstvy. Backend se stará o obsah - texty, obrázky, strukturovaná data. Frontend je samostatná aplikace, postavená v libovolné technologii, která si obsah stahuje přes API. Backend neví nic o tom, jak obsah vypadá. Frontend neví nic o tom, kde se obsah ukládá.

V praxi to znamená: redaktor píše článek v rozhraní CMS. Vývojář staví frontend v Nuxtu, Next.js nebo čemkoli jiném. Obě strany pracují nezávisle. Změna designu nevyžaduje zásah do CMS. Změna obsahu nevyžaduje nový deployment frontendu.

WordPress sám o sobě umí fungovat jako headless CMS - má REST API i podporu GraphQL přes plugin WPGraphQL. Ale existují nástroje, které byly pro headless práci navrženy od začátku a nabízejí lepší vývojářský zážitek.

Proč WordPressové weby narazí na zeď

WordPress pohání přes 40 % webu a pro většinu projektů funguje dobře. Problémy začínají, když web přeroste určitou hranici - a ta hranice je konkrétnější, než se zdá.

Plugin bloat. Průměrný WordPressový web, který auditujeme, má 25–40 aktivních pluginů. Každý plugin načítá vlastní CSS a JavaScript, registruje databázové dotazy a přidává HTTP požadavky. U našeho e-commerce klienta 47 pluginů generovalo přes 120 HTTP požadavků při prvním načtení stránky. Třetina z nich patřila pluginům, které se na dané stránce vůbec nepoužívaly.

Vendor lock-in témat. Premium témata z ThemeForest nebo Elegant Themes přinášejí vlastní page buildery, shortcody a datové struktury. Když chcete téma vyměnit - nebo jen výrazněji upravit design - zjistíte, že obsah je provázaný se specifickými shortcody tématu. Migrace obsahu ze starého tématu do nového někdy zabere víc času než postavit web znovu.

Výkonnostní strop. WordPress generuje každou stránku dynamicky z databáze. Cachování tento problém zmírňuje, ale neodstraňuje - jakmile uživatel přidá do košíku produkt nebo se přihlásí, cache se obchází. Na větších e-shopech s personalizovaným obsahem dosáhne WordPress výkonnostního stropu, který žádný optimalizační plugin nepřekoná.

Bezpečnostní povrch. Každý plugin je potenciální vstupní bod. V roce 2025 evidoval WPScan přes 49 000 známých zranitelností ve WordPressových pluginech. To neznamená, že WordPress je nezabezpečitelný - ale znamená to, že údržba zabezpečení roste lineárně s počtem pluginů.

Žádný z těchto bodů sám o sobě neříká „migrujte pryč.“ Ale kombinace tří nebo čtyř z nich - pomalé načítání, redakce závislá na vývojáři, opakované bezpečnostní záplaty, nemožnost škálovat bez dalších pluginů - je vzorec, který signalizuje, že architektura přestala vyhovovat.

Headless možnosti, které stojí za zvážení

Na trhu je dnes desítky headless CMS. Čtyři z nich vidíme nejčastěji u projektů podobného rozsahu jako mají čeští klienti - střední e-commerce, firemní weby s vícejazyčným obsahem, aplikace s vlastním frontendem.

Strapi je open-source, napsaný v Node.js. Hostujete si ho sami nebo použijete jejich cloud. Výhodou je úplná kontrola - definujete si vlastní typy obsahu, API endpointy, role a oprávnění. Nevýhodou je, že za hosting a údržbu odpovídáte sami. Pro týmy se zkušeností s Node.js je to solidní volba.

Contentful je nejstarší z velkých SaaS headless platforem. Má propracovaný systém workflow - schvalování obsahu, plánované publikace, granulární role. Cenový model rychle roste s počtem uživatelů a objemem obsahu, takže pro menší projekty může být předimenzovaný.

Sanity nabízí neobvykle flexibilní datový model a real-time spolupráci přímo v editoru. Sanity Studio (admin rozhraní) je open-source React aplikace, kterou si přizpůsobíte podle potřeby. Nevýhodou je strmější učicí křivka pro redaktory zvyklé na WYSIWYG editory.

Storyblok je zajímavý pro projekty, kde redaktoři potřebují vizuální náhled - editor zobrazuje stránku tak, jak bude vypadat, a redaktor přímo kliká na bloky a upravuje je. Pro vícejazyčné weby má vestavěnou podporu lokalizace. Mezi českými agenturami vidíme Storyblok čím dál častěji.

WordPress s WPGraphQL nebo REST API je pátá varianta. Pokud máte existující obsah ve WordPressu, máte zavedené workflow a redaktoři jsou zvyklí na rozhraní, má smysl WordPress ponechat jako backend a vyměnit jen frontend. Přesně tohle jsme udělali pro klienta z úvodního příběhu.

Jak migrace skutečně vypadá

Migrace z klasického WordPressu na headless architekturu není víkendový projekt. U středně velkého webu (50–200 stránek, e-commerce) počítáme s 6–12 týdny. Tady je realistický průběh.

Týden 1–2: Audit a modelování obsahu. Procházíme existující web a mapujeme každý typ obsahu - stránky, produkty, kategorie, blog, custom post types. Definujeme datový model pro headless CMS. Tohle je nejdůležitější krok. Špatně navržený model se projeví v každé další fázi.

Týden 3–4: Nastavení CMS a migrace obsahu. Nasazení headless CMS, konfigurace API, migrace existujícího obsahu. U WordPressu to obvykle znamená export přes WP REST API a import do nového systému. Obrázky, metadata, taxonomie - všechno se musí přemapovat. Automatizujeme co jde, ale ruční kontrola je nutná.

Týden 5–8: Přestavba frontendu. Stavíme frontend v Nuxtu (nebo Next.js, podle preferencí klienta a týmu). Implementujeme design, napojujeme komponenty na API, řešíme stránkování, filtrování, vyhledávání. U e-shopů přidáváme košík, checkout, propojení s platební bránou.

Týden 9–10: SEO a přesměrování. Tohle je místo, kde se migrace nejčastěji pokazí. Každá existující URL musí buď fungovat na nové verzi, nebo mít 301 přesměrování na správný cíl. Ztráta indexovaných URL znamená ztrátu pozic ve vyhledávání. Generujeme kompletní mapu přesměrování, nastavujeme strukturovaná data (JSON-LD), ověřujeme sitemapu a řešíme canonical URL.

Týden 11–12: Testování a spuštění. Funkční testování, výkonnostní testování, kontrola na různých zařízeních. Paralelní provoz starého a nového webu. Postupný přesun provozu. Monitorování pozic ve vyhledávání po spuštění.

Co se obvykle rozbije: interní vyhledávání (WordPress full-text search se chová jinak než to, co postavíte na frontendu), pluginy třetích stran, které nemají API alternativu (kontaktní formuláře, reservační systémy), a zvyklosti redaktorů, kteří jsou zvyklí na WordPress admin.

Co se zlepší: rychlost načítání (typicky 2–4× zrychlení), nezávislost obsahového týmu, škálovatelnost, bezpečnost (menší útočná plocha), a možnost nasadit frontend na CDN jako Vercel nebo Netlify.

Kdy je headless zbytečný

Headless architektura přidává komplexitu. Místo jedné aplikace máte dvě - CMS backend a frontend aplikaci. Potřebujete vývojáře, který rozumí oběma stranám. Hosting se komplikuje. Debugging znamená zjistit, jestli je problém v API, ve frontendu, nebo v konfiguraci CMS.

Headless nedává smysl pro:

• Prezentační weby malých firem - 5–10 stránek, blog, kontaktní formulář. WordPress s kvalitním hostingem a dobře nakonfigurovaným cachováním tady funguje výborně. Načítání pod 2 sekundy je dosažitelné bez jakékoli architektury navíc.
• Osobní blogy a portfolia - pokud nemáte specifický důvod pro vlastní frontend, WordPress nebo dokonce statický generátor (Hugo, Eleventy) udělá práci lépe a levněji.
• Projekty s omezeným rozpočtem a bez vývojáře - headless vyžaduje technickou údržbu. Pokud nemáte přístup k vývojáři ani na občasnou údržbu, klasický WordPress s pravidelným servisem je rozumnější volba.
• Weby, kde WordPress funguje dobře - pokud se web načítá rychle, redakce je spokojená a nenarážíte na limity, migrace na headless je řešení problému, který nemáte.

Pravidlo, které používáme: pokud problém vyřeší lepší hosting, optimalizace obrázků a vyčištění pluginů, neudělejte headless migraci. Nejdřív zkuste jednodušší řešení. Servisní podpora WordPressového webu stojí zlomek ceny přestavby.

Výkon a SEO po migraci

Čísla z reálných migrací, které jsme v Kosmoweb realizovali:

Hlavní důvod zlepšení není magie headless přístupu - je to kontrola nad frontendem. Když stavíte frontend v Nuxtu, rozhodujete přesně, které skripty se načtou, kdy se načtou a jak se vykreslí. Žádné pluginy nenačítají JavaScript, o kterém nevíte. Žádné téma nepřidává CSS, které nepoužíváte.

Nuxt nabízí tři režimy vykreslování: SSR (server-side rendering), SSG (statická generace) a hybridní režim. Pro většinu obsahových webů používáme SSG - stránky se vygenerují při buildu jako statické HTML soubory a servírují se z CDN. Doba odezvy serveru je prakticky nulová, protože žádný server v reálném čase nic negeneruje.

Pro e-commerce a dynamické části používáme SSR nebo hybridní přístup - produktové stránky se vykreslují na serveru s aktuálními cenami a dostupností, zatímco statické stránky (o nás, blog, podmínky) se servírují jako předgenerované HTML.

Z pohledu SEO je přechod na headless neutrální až pozitivní - za předpokladu, že správně ošetříte přesměrování a strukturovaná data. Google indexuje JavaScript-rendered obsah, ale SSR a SSG dávají jistotu, že crawler vidí kompletní obsah okamžitě. Strukturovaná data (JSON-LD) implementujeme přímo v kódu frontendu, bez závislosti na SEO pluginech.

Otázka nákladů

Férový rozbor nákladů, protože tohle je místo, kde se rozhoduje:

Počáteční náklady jsou vyšší. Přestavba středně velkého webu na headless architekturu stojí typicky 1,5–3× více než redesign ve WordPressu. Stavíte dvě věci místo jedné - CMS backend a vlastní frontend. Modelování obsahu, migrace dat, nastavení API - to jsou kroky, které u klasického WordPressu odpadají.

Průběžná údržba je nižší. Odpadá aktualizace 30+ pluginů každý měsíc. Odpadají bezpečnostní záplaty WordPressu. Frontend na Vercelu nebo Netlify se škáluje automaticky, neřešíte serverové prostředky. CMS backend (Strapi, Contentful) se buď aktualizuje sám (SaaS), nebo vyžaduje méně častou údržbu než WordPress.

Hosting se mění. WordPress vyžaduje PHP hosting s databází - u solidního poskytovatele (DigitalOcean, Hetzner s dobrým stackem) počítejte od 500 Kč měsíčně pro seriózní provoz. Headless frontend na Vercelu má free tier, který pokryje většinu webů. CMS backend záleží na volbě - SaaS řešení jako Contentful nebo Storyblok mají free plány pro malé týmy, self-hosted Strapi vyžaduje vlastní server.

Kdy ROI dává smysl:

• Web generuje měřitelné tržby (e-commerce, lead generation) a pomalé načítání prokazatelně stojí konverze
• Obsahový tým tráví hodiny týdně čekáním na vývojáře kvůli publikaci obsahu
• Bezpečnostní incidenty nebo výpadky způsobují opakované náklady
• Plánujete mobilní aplikaci nebo jiné kanály, které budou konzumovat stejný obsah přes API

Pro e-shop s měsíčním obratem nad 500 000 Kč, kde 34% nárůst konverzí z organického vyhledávání znamená desítky tisíc korun měsíčně, se investice vrátí během 4–6 měsíců. Pro firemní prezentaci s 500 návštěvami měsíčně se pravděpodobně nevrátí nikdy.

Závěr

Headless CMS není upgrade, který potřebuje každý web. Je to architektonické rozhodnutí, které dává smysl ve specifických situacích - když klasický CMS začne brzdit výkon, obsahový tým nebo škálování. Většina webů tam není a nepotřebuje tam být.

Pokud ale narazíte na vzorec z úvodu - rostoucí počet pluginů, zpomalující se načítání, redakce závislá na vývojáři - stojí za to se podívat, jestli problém vyřeší optimalizace stávajícího WordPressu, nebo jestli je čas na jiný přístup.

V Kosmoweb děláme obojí. Servisní podpora pro weby, kterým stačí optimalizace. Kompletní přestavba pro projekty, které přerostly možnosti klasického CMS. Začínáme auditem - a doporučíme jednodušší variantu, pokud dává smysl.