Sanity CMS: co to je, jak funguje a kdy se vyplatí

Co je Sanity CMS

Sanity je headless CMS — redakční systém, který se stará výhradně o obsah a vůbec neřeší, jak bude web vypadat. Obsah v něm žije jako strukturovaná data v cloudu a vy si k nim postavíte libovolný frontend: web v Next.jsu, mobilní aplikaci, e-shop, digitální ceduli v prodejně. Všechno tahá ze stejného zdroje.

To je zásadní rozdíl oproti systémům jako WordPress nebo Webflow, kde je obsah svázaný se šablonou a se stránkou. V Sanity nemáte „stránku s textem“. Máte článek, produkt nebo referenci — datový objekt s poli, který si vykreslíte, kdekoli potřebujete.

Sanity dělám vedle Webflow. Nejsou to konkurenti, jsou to nástroje na jiné situace, a níže popisuju, jak poznat, která je ta vaše.

Headless znamená, že frontend je na vás

V klasickém CMS dostanete administraci i vzhled v jednom balíku. Výhoda je rychlost, nevýhoda je strop: co šablona neumí, to neuděláte bez obcházení systému.

Headless CMS ten balík rozdělí. Sanity vám dá obsah přes API, frontend si postavíte sami. Tím pádem nemáte žádný strop na vzhled ani na výkon — ale taky nedostanete web „zdarma k CMS“. Někdo ho musí naprogramovat.

Prakticky to znamená, že Sanity projekt je vždycky vývojářský projekt. Když hledáte něco, kde si po zaplacení naklikáte web sami, chcete Webflow, ne Sanity.

Structured content: modelujte data, ne vzhled

Tohle je myšlenka, na které Sanity stojí, a zároveň nejčastější místo, kde se projekty pokazí.

Obsah se modeluje podle toho, co věci jsou, ne podle toho, jak vypadají. Pole se jmenuje features, ne threeColumnRow. callToAction, ne redButton. Test je jednoduchý: kdybyste web za dva roky předělali, dávalo by to jméno pořád smysl? threeColumnLayout neprojde — co až budou sloupce dva?

Vyplatí se to, protože stejná data pak použijete v novém designu, v aplikaci i v newsletteru bez přepisování obsahu. Když se do schématu dostane vzhled, jste zpátky u šablon a celá výhoda headless přístupu je pryč.

Schéma se píše v kódu

Datový model není klikací — definujete ho v TypeScriptu. Vypadá to takhle:

import { defineType, defineField } from 'sanity'

export const article = defineType({
  name: 'article',
  title: 'Článek',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
  ],
})

Že je schéma v kódu má praktický důsledek: model obsahu žije v Gitu. Vidíte historii změn, děláte revize v pull requestech a nasazujete stejně jako zbytek aplikace. U klikacích CMS tohle nemáte.

Sanity Studio: editor, který si upravíte

Studio je redakční rozhraní — React aplikace, kterou si hostujete sami nebo ji necháte běžet u Sanity. Není to hotový produkt, který berete jak je. Můžete v něm měnit strukturu menu, přidávat vlastní vstupní pole, náhledy i celé nástroje.

Pro klienta to znamená administraci šitou na míru jeho obsahu, ne obecný systém, ve kterém se musí naučit, co které pole znamená. Za mě je to největší praktická výhoda Sanity: editor se přizpůsobí redakci, ne naopak.

GROQ: jak se obsah dostane na web

Data si z Sanity tahá dotazovacím jazykem GROQ. Plní podobnou roli jako SQL nebo GraphQL, jen je navržený přímo na strukturovaný obsah:

*[_type == "article" && defined(slug.current)] | order(publishedAt desc) [0...10] {
  title,
  "slug": slug.current,
  publishedAt,
  author->{ name }
}

Ten dotaz vybere články, které mají slug, seřadí je od nejnovějšího, vezme prvních deset a u každého rovnou dotáhne jméno autora z propojeného dokumentu. Šipka -> je právě to rozbalení reference.

Podstatné je, že si vytáhnete přesně pole, která potřebujete — ne celý dokument. To se pozná na rychlosti webu.

S čím se Sanity nejčastěji staví

Sanity je na frontendu agnostické, ale v praxi se potkáváte hlavně s těmito kombinacemi:

• Next.js — nejběžnější volba, má oficiální balíček next-sanity a nejlepší podporu pro živý náhled.
• Astro — sedí na obsahové weby, kde jde hlavně o rychlost.
• Nuxt a SvelteKit — když tým jede na Vue nebo Svelte.
• Shopify Hydrogen — e-shopy, kde produkty drží Shopify a zbytek obsahu Sanity.

Bonus, který klienti ocení nejvíc: Visual Editing. Redaktor klikne na text přímo v náhledu webu a Studio ho rovnou otevře na správném poli. Ztrácí se tím hlavní nevýhoda headless přístupu, totiž že editor nevidí, co edituje.

Kdy Sanity dává smysl a kdy ne

Dává smysl, když:

• Stejný obsah potřebujete na víc míst — web, aplikace, e-shop.
• Máte hodně strukturovaného obsahu: katalog, databáze projektů, vícejazyčný archiv.
• Chcete redakci na míru a jste ochotní za to zaplatit vývojem.
• Počítáte s tím, že web za pár let předěláte, ale obsah chcete zachovat.

Nedává smysl, když:

• Potřebujete prezentační web o deseti stránkách. Tam je Sanity dělo na vrabce a Webflow vás dostane k cíli levněji a rychleji.
• Chcete si po předání sami měnit rozvržení stránek. V Sanity měníte obsah, ne design — na design potřebujete vývojáře.
• Nemáte rozpočet na frontend. CMS je jen půlka projektu.

Říkám to na rovinu, protože špatně zvolený nástroj se pozná až za rok, kdy je drahé couvat. Podobné rozhodování řeším i v článku o vícejazyčném webu ve Webflow.

Co si z toho odnést

Sanity je nástroj pro projekty, kde je obsah aktivum — má strukturu, žije dýl než současný design a používá se na víc než jednom místě. Za tu flexibilitu platíte tím, že frontend a redakční rozhraní někdo musí postavit.

Když si nejste jistí, jestli je Sanity vaše cesta, nebo vám bohatě stačí Webflow, napište mi. Projdeme, co váš projekt reálně potřebuje, a řeknu vám i to, když bude levnější varianta ta správná.