WordPress headless

Architektura gdzie WordPress zarządza treścią jako headless CMS i wystawia ją przez REST API lub GraphQL, a frontend (Next.js, Gatsby) jest osobną aplikacją. SSR/SSG generuje czysty HTML bez JavaScript — naturalnie agent-readable.

W Polsce nazywane też:

headless WordPressWordPress headless CMSWordPress bez frontendudecoupled WordPress

„Headless” — bez głowy. WordPress bez frontendu. WordPress który nie renderuje HTML który wyświetla przeglądarka — tylko przechowuje treść i wystawia ją przez API.

Tradycyjny WordPress: żądanie → PHP renderuje HTML → przeglądarka wyświetla. Wszystko jest razem — dane, logika i prezentacja.

Headless WordPress: frontend jest osobną aplikacją (Next.js, Gatsby, React) która pobiera treść z WordPress przez REST API lub GraphQL, i renderuje ją po swojej stronie. WordPress jest „backend” — system zarządzania treścią bez interfejsu użytkownika.

Czym jest Headless WordPress

Headless WordPress to architektura w której WordPress pełni rolę „headless CMS” — zarządza treścią przez Gutenberg i wystawia ją przez REST API lub GraphQL (WPGraphQL plugin) — podczas gdy frontend (strona widoczna dla użytkownika i agentów) jest osobną aplikacją, często Next.js lub Gatsby, która pobiera i renderuje treść z WordPress API.

Kiedy Headless ma sens

Performance-critical sites: Next.js z SSR/SSG może generować statyczne strony z treści WordPress — ultraszybkie ładowanie, doskonałe Core Web Vitals, naturalnie czytelny HTML dla agentów.

Multi-channel: ta sama treść w WordPress jest serwowana przez stronę webową, aplikację mobilną, kiosk interaktywny, interfejs głosowy — przez to samo API. Treść raz, wiele prezentacji.

Developer experience: frontend team preferuje React/Next.js zamiast PHP templates. Headless pozwala każdemu teamowi używać swojego stack bez kompromisu.

Headless a agent-readiness

Headless WordPress z SSR (Server-Side Rendering) lub SSG (Static Site Generation) generuje czysty HTML bez JavaScript hydration dla pierwszego render. To jest naturalnie agent-readable — agent otrzymuje pełny HTML z treścią bez potrzeby wykonania JavaScript.

WordPress CMS jako backend + Next.js jako frontend z llms.txt, NLWeb endpoints i structured data jest jedną z najlepszych architektur dla agent-ready site.

WPGraphQL jako alternatywa REST

WPGraphQL plugin dodaje GraphQL endpoint do WordPress — /graphql. GraphQL pozwala agentowi zapytać dokładnie o dane których potrzebuje (nie pełny post z metadanymi których nie chce) w jednym żądaniu. Dla agentów które wykonują wiele zapytań — GraphQL może być bardziej efektywne niż REST API.

Powiązane pojęcia

WordPress REST APIWbudowany interfejs programistyczny WordPress pod /wp-json — wystawiający endpointy JSON dla treści, stron i mediów — umożliwiający agentom programatyczne czytanie i modyfikowanie zawartości bez HTML parsing. Naturalna baza pod serwer MCP dla WordPress.NLWebStandard Microsoftu ogłoszony na Build 2025 przez R.V. Guha — pozwala każdej stronie wystawiać konwersacyjny interfejs dla agentów AI przez endpointy /ask i /mcp, używając Schema.org jako bazy wiedzy. Każda instancja NLWeb jest też serwerem MCP.Gotowość agentowaZestaw cech strony internetowej decydujący o tym, czy agent AI potrafi ją skutecznie odczytać, zrozumieć i wykonać na niej działanie w imieniu użytkownika.Optymalizacja pod silniki generatywneTermin wprowadzony przez badaczy z Princeton w 2024 roku opisujący optymalizację treści pod kątem cytowania przez silniki generatywne takie jak ChatGPT, Perplexity czy Google AI Overviews.Czytelność dla agentaPierwszy filar agent-readiness: zdolność strony do bycia odczytaną przez agenta AI bez renderowania JavaScript — obejmuje semantyczny HTML, hierarchię nagłówków i dostępność treści w czystym HTML.