WordPress jako headless CMS: Průvodce pro vývojáře [2026]

WordPress jako headless CMS: Průvodce pro vývojáře [2026]

Podle W3Techs pohání WordPress 43 % všech webových stránek a stále více týmů zcela odstraňuje PHP frontend a používá jej pouze jako obsahové API. Zde je vše, co potřebujete vědět o provozování WordPressu v headless režimu, od výběru mezi REST API a WPGraphQL až po nasazení frontendu Next.js na Vercelu s využitím ISR.

Co je to Headless WordPress? (A proč by vás to mělo zajímat?)

Headless WordPress je nastavení, kde WordPress zpracovává správu a ukládání obsahu, zatímco samostatná frontendová aplikace postavená na Next.js, Nuxt, Astro nebo jakémkoli jiném frameworku načítá tento obsah prostřednictvím API. WordPress si ponechává svou administrační nástěnku, editor, ekosystém pluginů a databázi MySQL. Místo renderování stránek pomocí PHP šablon však zpřístupňuje obsah prostřednictvím WordPress REST API nebo WPGraphQL a váš frontend zcela převezme prezentační vrstvu.

Představte si to takto: WordPress je kuchyně a váš frontendový framework je restaurace. Kuchyně připravuje jídlo (obsah), ale restaurace rozhoduje o tom, jak bude naservírováno, jak vypadá jídelna a jak hosté zažijí celé jídlo.

Tradiční vs. Headless architektura

V tradičním WordPressu je vše monolitické. Návštěvník požádá o stránku, PHP zpracuje požadavek, dotáže se MySQL, provede jej přes šablonové soubory vaší šablony a odešle zpět vyrenderované HTML. Šablona řídí rozvržení, stylování, směrování – prostě všechno.

V headless WordPressu tuto celou renderovací vrstvu odstraníte. WordPress běží za API, obvykle na spravovaném hostingu, jako je WP Engine nebo Kinsta. Váš frontend, aplikace v Reactu, Vue nebo Svelte, provádí požadavky na API pro načtení obsahu a poté jej vykreslí podle vašich představ. Tyto dva systémy mohou běžet na zcela odlišných serverech, používat různé technologické stacky a mít odlišné pipeline nasazení.

Je zde jemný rozdíl, který 9 z 10 průvodců přehlíží: decoupled (oddělený) a headless nejsou úplně totéž. Decoupled WordPress může stále fallbackovat na PHP renderování pro určité stránky (například administrační oblast nebo starší routy). Plně headless znamená, že frontend WordPressu je zcela deaktivován, běží pouze na API, bez jakéhokoli renderování šablon. V tomto průvodci se bavíme o plně headless přístupu.

Kdy přejít na Headless (a kdy zůstat u tradičního řešení)

Přechod na headless dává smysl, když má váš tým frontendové vývojáře, kteří chtějí pracovat s moderními nástroji, když potřebujete doručovat obsah na více kanálů (web, mobilní aplikace, digitální signage) nebo když je výkon nepostradatelný. Nedává to smysl pro každého a upřímnost v této otázce vám ušetří týdny zbytečné práce.

Přejděte na Headless, když...

• Váš tým již zná React/Vue/Svelte. Pokud vaši frontendoví vývojáři celý den píší JSX, nutit je do PHP šablon je jako žádat šéfkuchaře, aby vařil v mikrovlnné troubě.
• Potřebujete doručování na více kanálů. Jeden backend WordPressu může napájet váš marketingový web, mobilní aplikaci a informační kiosky v prodejnách prostřednictvím stejného API.
• Výkon je tvrdým požadavkem. Statické stránky obsluhované z edge CDN budou vždy porážet PHP renderování na sdíleném serveru.
• Provozujete headless WooCommerce. Složité e-commerce front-endy mají enormní prospěch z vlastních storefrontů v Reactu/Next.js.
• Chcete moderní DX (Developer Experience). Hot module replacement, TypeScript, knihovny komponent, CI/CD, kompletní frontendový toolchain.

Zůstaňte u tradičního řešení, když...

• Redaktoři obsahu potřebují live preview a page buildery. Gutenberg, Elementor a WPBakery předpokládají tradiční šablonu. Přechod na headless zabije většinu vizuálních pracovních postupů editace.
• Jste solo vývojář nebo malý tým. Headless přidává 40–60 % složitosti nastavení. Pokud udržujete blog jen vy sami, tradiční šablona je jednodušší.
• Silně spoléháte na frontendové pluginy. Kontaktní formuláře, SEO pluginy (Yoast renderuje meta tagy na straně serveru), bannerky souhlasu s cookies – to vše předpokládá PHP renderování.
• Rozpočet je těsný. Budete potřebovat samostatný hosting pro WordPress i pro váš frontend. To jsou dvě faktury místo jedné.

REST API vs WPGraphQL: Výběr datové vrstvy

WordPress vám poskytuje dva způsoby, jak načítat obsah v headless nastavení: vestavěné REST API a plugin WPGraphQL. REST API je součástí jádra WordPressu a funguje hned po instalaci, nejsou potřeba žádné pluginy. WPGraphQL vyžaduje instalaci pluginu, ale umožňuje vám dotazovat přesně ta pole, která potřebujete, čímž eliminuje problém s nadměrným načítáním dat (over-fetching), který trápí REST. Z našich zkušeností vyplývá, že WPGraphQL vítězí ve většině projektů, ale REST má jedno podceňovanou výhodu: nativní HTTP caching.

WordPress REST API: Vestavěná možnost

REST API je dostupné v každé instalaci WordPressu od verze 4.7 (prosinec 2016). Stačí zavolat /wp-json/wp/v2/posts a dostanete zpět JSON. Jednoduché, dobře zdokumentované a funguje to bez jakékoli konfigurace.

Háček? Over-fetching. Když požádáte o příspěvek, WordPress vrátí všechno: vyrenderovaný obsah, raw obsah, excerpt, ID autora, ID hlavního média, kategorie, štítky, meta pole, GUID, stav komentářů, stav pingů, šablonu a asi 15 dalších polí, která pravděpodobně nepotřebujete. Pro stránku s výpisem blogu, kde potřebujete pouze titulky, slugy a excerpty, přenášíte 3–5x více dat, než je nutné.

// REST API: Fetch 5 recent posts with author and categories
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// The _embed parameter includes author and category objects
// But also includes EVERY field on each post -- ~8KB per post
// For 5 posts, you're looking at ~40KB of JSON

Můžete použít parametr _fields k omezení vrácených polí (?_fields=id,title,slug,excerpt), ale nepomáhá to s vloženými zdroji a stále budete muset provádět více požadavků, pokud potřebujete související data.

WPGraphQL: Dotazujte se na to, co potřebujete

WPGraphQL je bezplatný open-source plugin od Jasona Bahla (nyní udržovaný společností WP Engine), který přidává do WordPressu plnohodnotné GraphQL API. Napíšete dotaz specifikující přesně pole, která chcete, a dostanete zpět přesně to, nic víc.

# WPGraphQL: Same query -- 5 recent posts with author and categories
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Response: ~2KB of precisely structured JSON
# No extra fields, no bloat

Porovnání kódu vedle sebe

Zde je ukázka toho, jak skutečně vypadají odpovědi (payloads):

Co byste měli vybrat?

Použijte REST, když stavíte něco rychle, váš tým nezná GraphQL nebo potřebujete agresivní HTTP caching bez dalšího toolingu.

Použijte WPGraphQL, když stavíte produkční frontend se složitými datovými potřebami, chcete menší payloady nebo váš tým již jinde používá GraphQL.

Odvážný verdikt: Pro seriózní headless projekt WordPressu s Next.js je WPGraphQL lepší volbou. Úspory na payloadu, developer experience s GraphiQL IDE a načítání dat jediným requestem stojí za závislost na pluginu.

Nastavení WordPressu jako Headless CMS

Nastavení WordPressu jako headless CMS zahrnuje šest kroků: instalace WordPressu, přidání správných pluginů, konfigurace modelu obsahu, deaktivace frontendové šablony, nastavení autentizace a ověření funkčnosti API. Celý proces trvá asi 30–45 minut, pokud jste to již dělali, nebo pár hodin poprvé.

Krok 1: Začněte čistou instalací WordPressu na spravovaném hostingu. Kinsta, WP Engine a Cloudways nabízejí prostředí optimalizovaná pro WordPress. Pokud jen experimentujete, lokální instalace pomocí LocalWP také postačí.

Krok 2: Nainstalujte nezbytné pluginy:

Krok 3: Vytvořte svůj model obsahu pomocí ACF. Definujte skupiny polí, které mapují na vaše frontendové komponenty. Typ příspěvku portfolio může mít pole pro projectUrl, techStack (repeater), clientName a projectYear.

Nezbytné pluginy

WPGraphQL for ACF si zasluhuje zvláštní pozornost. Bez něj se vaše pole ACF neobjeví v GraphQL dotazech. Po instalaci můžete dotazovat vlastní pole takto:

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

Deaktivace WordPress Frontendu

Krok 4: Nechcete, aby návštěvníci přistupovali na URL vašeho WordPressu a viděli rozbitou šablonu. Přidejte toto do functions.php vaší šablony nebo použijte mu-plugin:

// Redirect all frontend requests to the API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

Krok 5: Nastavte Application Passwords pro autentizaci. Přejděte do Users > Your Profile > Application Passwords, vygenerujte heslo a použijte jej pro autentizované požadavky na API (vytváření/aktualizace obsahu z externích nástrojů).

Testování vašeho API

Krok 6: Otevřete prohlížeč a přistupte na https://vas-web.com/graphql, měli byste vidět GraphiQL IDE. Zkuste dotazovat své příspěvky. Pokud používáte REST, přejděte na https://vas-web.com/wp-json/wp/v2/posts a ověřte, že dostanete zpět JSON.

Profesionální tip: GraphiQL IDE dodávané s WPGraphQL je skutečně vynikající pro zkoumání vašeho schématu. Získáte automatické doplňování, dokumentaci a historii dotazů. Je to nejrychlejší způsob, jak zjistit, která pole jsou dostupná a jak jsou strukturována vaše data ACF.

Stavba Next.js Frontendu s WPGraphQL

Nejčistší způsob, jak v roce 2026 postavit headless WordPress frontend, je pomocí App Routeru v Next.js 15 a React Server Components. Server Components načítají data na serveru bez odesílání JavaScriptu klientovi a WPGraphQL poskytuje přesné dotazy, což je přirozená kombinace. Když jsem poprvé nastavoval WPGraphQL s Next.js App Routerem, největším úskalím bylo zpracování obrázků, ale k tomu se dostaneme.

Nastavení projektu a proměnné prostředí

Začněte novým projektem Next.js. Vercel také nabízí oficiální startovací šablonu pro WordPress, pokud chcete referenční architekturu.

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

Vytvořte .env.local s vašimi endpointy WordPressu:

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Nyní vytvořte lehkou utilitu pro GraphQL fetch. Pro Server Components nepotřebujete Apollo ani urql, obyčejný fetch funguje perfektně, protože není třeba spravovat stav na straně klienta:

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR: revalidate every hour
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

Pro možnosti React frameworků se podívejte na naše srovnání Next.js vs plain React s Vite, existují platné důvody, proč framework vynechat, ale pro práci s headless CMS činí vestavěné SSR a ISR z Next.js praktickou volbu. A pokud váháte mezi Next.js a Remix, rozebíráme to v našem článku o tom, proč doporučujeme Next.js pro většinu projektů.

Načítání příspěvků pomocí Server Components

Zde je stránka s výpisem blogu jako Server Component, žádné useEffect, žádné stavy načítání, žádná hydratace na straně klienta:

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

Dynamické stránky příspěvků

Stránky jednotlivých příspěvků používají generateStaticParams k před-renderování všech příspěvků v době buildu, poté ISR zachytí nový obsah:

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

Nezapomeňte nakonfigurovat next.config.ts pro obrázky z WordPressu:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

Nasazení Headless WordPressu do produkce

Produkční nastavení headless WordPressu využívá duální hosting: WordPress běží na spravovaném WordPress hostingu (WP Engine, Kinsta nebo Cloudways), zatímco Next.js frontend se nasazuje na edge platformu, jako je Vercel nebo Netlify. Toto oddělení znamená, že každá vrstva se může škálovat nezávisle, WordPress zpracovává editaci obsahu a požadavky na API, zatímco frontend obsluhuje statické a ISR stránky z edge uzlů CDN po celém světě.

Architektura hostingu

Tok dat vypadá takto: redaktoři publikují v administraci WordPressu, WordPress ukládá obsah do MySQL, Next.js frontend načítá obsah přes WPGraphQL, Vercel generuje statické HTML na edgi a návštěvníci míří na CDN, aniž by se přímo dotkli WordPressu.

Pro hosting frontendu se podívejte na naše srovnání Vercel vs Netlify pro podrobný rozbor. Oba fungují dobře pro headless WordPress. Pokud zvažujete alternativy založené na kontejnerech, naše srovnání Railway, Render a Fly.io pokrývá i tyto možnosti.

ISR a On-Demand Revalidace

Tohle je část, díky které je headless WordPress v produkci skutečně životaschopný. Zjistili jsme, že on-demand revalidace stojí za námahu s nastavením, protože bez ní jste nuceni vybírat mezi zastaralým obsahem (dlouhé intervaly revalidace) a pomalými buildy (krátké intervaly, které zatěžují vaše WordPress API).

ISR vám umožňuje nastavit čas revalidate pro každou stránku. Po uplynutí tohoto intervalu dostane další návštěvník uloženou stránku v cache, zatímco Next.js ji regeneruje na pozadí. Ale skutečná magie spočívá v on-demand revalidaci, která spustí rebuild okamžitě po publikování obsahu:

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Also revalidate the listing page
  }

  return NextResponse.json({ revalidated: true });
}

Na straně WordPressu přidejte webhook, který se spustí při publish_post pomocí pluginu jako WP Webhooks nebo jednoduchého snippetu v functions.php, který zavolá váš Vercel endpoint /api/revalidate. Nyní se obsah objeví online během sekund po kliknutí na „Publikovat“, žádné plné rebuildy, žádné čekání. Více možností konfigurace najdete v dokumentaci Next.js ISR.

Rozpis nákladů

WordPress Headless vs. Specializované Headless CMS

Po práci s headless WordPressem i specializovanými CMS, jako jsou Sanity, Contentful a Strapi, zde je můj upřímný názor: Headless WordPress je pragmatická volba, když máte existující web na WordPressu nebo redakční tým. Zřídka je to nejlepší volba při startu od nuly.

Kde Headless WordPress vítězí

• Redaktoři obsahu jej již znají. Admin UI WordPressu má 20 let vylepšování. Zaškolení netechnického týmu na Sanity Studio nebo rozhraní Contentfulu trvá týdny.
• Ekosystém pluginů. Více než 60 000 pluginů. Potřebujete vícejazyčnost? WPML. E-commerce? WooCommerce. Analýzu SEO obsahu? Yoast (stále funguje v adminu). Žádné specializované CMS se nemůže rovnat této šíři.
• Nábor. WordPress má největší pool vývojářských talentů ze všech CMS. Najít vývojáře na WordPress je dramaticky snazší než najít specialistu na Sanity nebo Payload.
• WooCommerce. Pokud potřebujete headless e-commerce s obsahem WordPressu, WooCommerce + WPGraphQL je osvědčený stack. Saleor a Medusa jsou alternativy, ale WooCommerce má větší podíl na trhu.

Kde vítězí specializovaná CMS

• Modelování obsahu. GROQ od Sanity, typy obsahu Contentfulu a TypeScript schéma Payloadu jsou navrženy pro strukturovaný obsah od základu. Model post/page/custom-post-type ve WordPressu působí dojmem, že byl nalepen dodatečně.
• Real-time spolupráce. Sanity má real-time editaci ve stylu Google Docs. Contentful má live spolupráci. WordPress? Dostanete zamykací obrazovku „Tento příspěvek právě edituje někdo jiný“.
• API-first architektura. WPGraphQL je brilantní, ale stále je to plugin sedící na PHP monolitu. API Contentfulu a API Sanity byly navrženy jako API-first od prvního dne.
• Zpracování médií. Knihovna médií WordPressu je funkční, ale základní. Image pipeline Sanity s automatickým ořezáváním, hotspots a doručováním přes CDN je jiná liga. Contentful a Storyblok se nativně integrují s Cloudinary.
• Developer experience. Strapi a Payload vám poskytují lokální dev experience s hot-reload při změnách schématu. WordPress vyžaduje obnovení adminu a spuštění migrací databáze.

Verdikt: Co byste měli vybrat?

Použijte headless WordPress, když: máte existující web na WordPressu s roky obsahu, vaši redaktoři se odmítají učit nové CMS, potřebujete WooCommerce nebo specifický plugin WordPressu, který nemá jinde ekvivalent.

Zvolte specializované headless CMS, když: začínáte nový projekt od nuly, potřebujete real-time spolupráci, váš model obsahu je komplexní a strukturovaný nebo váš tým oceňuje developer experience více než šíři pluginů.

Ve společnosti Techsy jsme pro klienty migrující z tradičního WordPressu postavili headless frontendy. Naším typickým přístupem je: WPGraphQL + Next.js App Router na Vercelu, s ISR pro výkon a on-demand revalidací pro čerstvost obsahu. Získejte bezplatnou konzultaci ->

WordPress MCP a Abilities API: Budoucnost AI

WordPress 6.9 představil Abilities API, které se slučuje do jádra WordPressu 7.0 (duben 2026). Vytváří standardizované, typované a objevitelné rozhraní pro funkčnost WordPressu, představte si to jako vystavení schopností WordPressu ve strojově čitelném formátu, kterému mohou AI nástroje rozumět a používat.

WordPress MCP Adapter propojuje toto Abilities API s Model Context Protocol (MCP), otevřeným standardem pro připojování AI systémů k externím nástrojům. Co to vlastně znamená? AI agenti v Claude, Cursoru nebo VS Code nyní mohou zjistit, co váš web na WordPressu umí, a poté tyto akce přímo provádět.

Zde je praktický scénář: Claude může vytvořit příspěvek ve WordPressu, naplnit pole ACF strukturovanými daty, přiřadit kategorie, nastavit hlavní obrázek a spustit váš webhook pro revalidaci na Vercelu, vše v rámci jedné konverzace. Žádný prohlížeč, žádný admin panel, žádné kopírování a vkládání.

Jedná se o ranou fázi a MCP adapter se stále vyvíjí. Ale signalizuje to něco důležitého: WordPress nejen nečinně sedí, zatímco specializovaná headless CMS inovují. Kombinace Abilities API + MCP by mohla udělat z WordPress jeden z nejpřístupnějších CMS pro AI, využívající jeho masivní ekosystém pluginů způsoby, kterým novější, menší platformy nemohou konkurovat. Kompletní technické detaily si přečtěte v oficiálním oznámení na WordPress Developer Blog.

Výkon: Headless WordPress vs. Tradiční WordPress

Headless WordPress se statickým frontendem dramaticky zlepšuje výkon ve srovnání s tradičním WordPressem renderovaným v PHP. Tradiční WordPress obsluhuje dynamické stránky spuštěním PHP při každém požadavku, což vede k špatnému Time to First Byte (TTFB). Podle dat o výkonu z poloviny roku 2025 vidí dobré skóre TTFB pouze 31 % desktopových klientů WordPressu a 24 % na mobilech. Přechod na headless s Next.js a ISR znamená, že stránky jsou před-renderovány a obsluhovány z edge uzlů CDN, což snižuje TTFB u cachovaných stránek pod 100 ms.

Case study WP Engine na Android Authority ukázala 6násobné zlepšení skóre výkonu Lighthouse po migraci na headless WordPress. Data Core Web Vitals vyprávějí podobný příběh: pouze 45 % webů na WordPressu splňuje všechny tři metriky CWV na mobilech, ve srovnání s 65 % pro Shopify a 83 % pro Duda.

Jedno důležité upozornění: headless neopraví pomalý backend WordPressu. Pokud vaše WordPress API odpovídá 3 sekundy, protože jste na levném sdíleném hostingu s 40 pluginy, bude pomalá i vaše ISR regenerace. Frontend nemůže být rychlejší než API, na kterém závisí. Investujte do kvalitního spravovaného hostingu, v headless nastavení záleží více, ne méně. Weston Ruter, lead pro výkon WordPressu, má na svém blogu vynikající data o tom, co skutečně hýbe jehlou u výkonu serveru WordPress.

FAQ

Co je to headless WordPress?

Headless WordPress je architektura, kde WordPress slouží pouze jako backend pro správu obsahu, přičemž jeho PHP frontendová šablona je zcela deaktivována. Obsah je doručován prostřednictvím REST API nebo WPGraphQL do samostatné frontendové aplikace postavené na frameworcích jako Next.js, Nuxt nebo Astro. Administrace WordPressu zůstává plně funkční pro redaktory obsahu.

Je WordPress dobrý jako headless CMS?

WordPress funguje dobře jako headless CMS, když máte existující web na WordPressu, redaktory, kteří znají rozhraní, nebo potřebujete ekosystém pluginů (zejména WooCommerce). Je méně ideální než specializovaná headless CMS jako Sanity nebo Contentful při startu od nuly, protože modelování obsahu a API WordPressu byla přidána dodatečně, nikoliv budována jako API-first.

Jaké jsou nevýhody headless WordPressu?

Hlavní nevýhody jsou: zvýšená složitost (dvě hostingová prostředí místo jednoho), ztráta vizuální editace a funkcionality page builderů, frontendové pluginy přestávají fungovat (renderování meta tagů Yoast, kontaktní formuláře, bannerky cookies), žádná real-time spolupráce na obsahu a GraphQL API je závislost na pluginu, nikoliv core funkcionalita. Rozpočet se také zvyšuje, protože platíte za hosting WordPressu i za hosting frontendu.

Jak připojím Next.js k WordPressu?

Nainstalujte WPGraphQL na svůj web WordPress, poté vytvořte projekt Next.js s App Routerem. Nastavte endpoint WordPress GraphQL jako proměnnou prostředí, napište jednoduchou utility funkci pro GraphQL založenou na fetch a použijte ji v Server Components pro dotazování příspěvků, stránek a vlastních typů obsahu. Nepotřebujete Apollo ani urql, obyčejný fetch funguje, protože Server Components běží na serveru.

WPGraphQL vs REST API, co je lepší?

WPGraphQL je lepší pro produkční front-endy, protože vrací pouze pole, která žádáte (snižuje velikost payloadu o 60–80 %), podporuje vnořené dotazy v jednom requestu a poskytuje GraphiQL IDE pro prozkoumávání schématu. REST API je lepší pro rychlé prototypy, týmy neznalé GraphQL nebo scénáře, kde je kritický nativní HTTP caching bez dalšího toolingu.

Kolik stojí headless WordPress?

Minimální nastavení headless WordPressu stojí kolem 14 USD měsíčně, Cloudways pro hosting WordPressu plus bezplatná hobby tier Vercelu pro frontend. Produkční nastavení s WP Engine a Vercel Pro běží na 40–70 USD měsíčně. Přidejte 0–50 USD měsíčně za prémiové pluginy jako ACF Pro a WPML. Specializovaná headless CMS často mají štědré free tiery, takže cena sama o sobě není důvodem zvolit headless WordPress.

Mohu použít WooCommerce s headless WordPressem?

Ano. WPGraphQL má rozšíření pro WooCommerce (WPGraphQL WooCommerce nebo „WooGraphQL“), které vystavuje produkty, objednávky, košík a funkčnost checkoutu prostřednictvím GraphQL. To vám umožňuje budovat vlastní storefronty v Reactu s plnou e-commerce kapacitou. Proces checkoutu vyžaduje více práce ve srovnání s tradičními šablonami WooCommerce, ale zisky na výkonu a UX jsou významné pro obchody s vysokou návštěvností.

Potřebuji vývojáře na nastavení headless WordPressu?

Ano, nastavení headless WordPressu vyžaduje frontendové vývojářské dovednosti, konkrétně React (nebo Vue/Svelte) a znalost API. Budete muset postavit celý frontend od nuly nebo přizpůsobit startovací šablonu. Toto není no-code řešení. Redaktoři obsahu mohou stále běžně používat administraci WordPressu, ale počáteční nastavení a průběžná údržba frontendu vyžadují zapojení vývojáře.

Jaké pluginy jsou nezbytné pro headless WordPress?

Nezbytné pluginy jsou WPGraphQL (GraphQL API), Advanced Custom Fields nebo ACF (modelování strukturovaného obsahu) a WPGraphQL for ACF (vystavuje vlastní pole přes GraphQL). Důrazně doporučeno: Custom Post Type UI pro registraci typů příspěvků přes admin a webhook plugin jako WP Webhooks pro spouštění rebuildů frontendu při publikování obsahu. Vyhněte se pluginům závislým na frontendu, jako je renderování meta tagů Yoast SEO nebo pluginy pro formuláře.

Je headless WordPress dobrý pro SEO?

Headless WordPress může být vynikající pro SEO, když je správně implementován s Next.js nebo Nuxt, protože získáte server-side rendering, rychlejší načítání stránek (zlepšující Core Web Vitals) a plnou kontrolu nad meta tagy, strukturovanými daty a strukturou URL. Rizikem je, že ztratíte automatické funkce SEO pluginů, jako je renderování meta tagů Yoast, budete muset meta tagy, sitemapu a strukturovaná data řešit ručně ve kódu vašeho frontendu.