WordPress headless pod SEO w 2026 roku przestał być eksperymentem dla startupów i wszedł na listę kanonicznych architektur publikacyjnych. Faust.js, WPEngine Atlas i odświeżona społeczność wokół Frontity (przejętego przez Automattic, ale wciąż żywego w forku WP Engine) tworzą stos, który łączy edytorską wygodę WordPressa z wydajnością i elastycznością Next.js. Pytanie nie brzmi już czy headless ma sens, lecz jak wdrożyć go bez utraty indeksacji, sygnałów linkowych i dotychczasowych pozycji w Google oraz cytowań w modelach typu ChatGPT, Perplexity i Gemini.
Ten przewodnik jest praktyczny: przeprowadza redakcję techniczną przez decyzje architektoniczne, definicje frameworków, krok po kroku wdrożenie, audyt SEO przed i po migracji, oraz katalog typowych potknięć. Materiał uzupełnia Checklista technicznego SEO 2026 (40 punktów), do której wracamy w sekcjach o renderowaniu i indeksacji.
Czym jest WordPress headless SEO
Headless WordPress oznacza, że WordPress służy wyłącznie jako CMS i warstwa danych, a renderowaniem strony zajmuje się oddzielny frontend (zwykle Next.js, czasem Nuxt lub Astro). Komunikacja odbywa się przez REST API (/wp-json/wp/v2/) lub GraphQL (wtyczka WPGraphQL). Z perspektywy użytkownika i Googlebota strona to nie WordPress, tylko aplikacja JavaScript dostarczająca HTML w trybie SSR lub ISR.
SEO w architekturze headless polega na zachowaniu trzech rzeczy, które klasyczny WordPress dostarcza domyślnie: pełnego HTML w pierwszym żądaniu (server-side rendering), poprawnej kanonikalizacji URL po stronie aplikacji frontendowej, oraz wszystkich sygnałów meta z RankMath, Yoast czy AIOSEO przeniesionych do nagłówków <head> renderowanej strony. Trzeci punkt jest najczęstszą pułapką: meta tytuł, opis, JSON-LD i Open Graph muszą być pobrane z API i wstrzyknięte przez frontend, inaczej znikają.
Czym headless różni się od klasycznego WordPressa
W klasycznym WordPressie zapytanie HTTP trafia do PHP, który renderuje stronę z bazy MySQL i odpowiada gotowym HTML. W headless WordPress odpowiada API JSON-em, a Next.js (lub inny framework) generuje HTML w warstwie pośredniej. Dla Google i agentów LLM różnica jest niewidoczna, jeśli SSR działa poprawnie. Jeśli frontend wpada w CSR (client-side rendering), pierwsze żądanie zwraca pusty <body>, a indeksacja i cytowanie w LLM-ach gwałtownie spadają.
Dlaczego headless w 2026 ma sens
Core Web Vitals stały się twardym czynnikiem rankingowym, a LLM-y cytują głównie strony, które oddają czysty, semantyczny HTML w pierwszym requeście. Headless eliminuje narzut wtyczek frontendowych, motywów i Block Editora w warstwie publicznej, dzięki czemu LCP poniżej 1,5 s na 75 percentylu jest realnie osiągalne nawet dla portali z setkami tysięcy wpisów. Drugim argumentem jest swoboda projektowa: redakcja edytuje treści w znajomym Gutenbergu, frontend renderuje je w dowolnym design systemie.
Najważniejsze zasady i framework
Wybór frameworka jest w 2026 mniej istotny niż jeszcze dwa lata temu, bo wszystkie trzy główne stosy dojrzały. Liczy się to, czy zespół ma kompetencje React, czy WordPress, oraz czy hosting znajduje się u WP Engine (wtedy Atlas wygrywa kosztem integracji), czy gdziekolwiek indziej.
Faust.js
Faust to framework od WP Engine, który nakłada warstwę abstrakcji nad Next.js i GraphQL. Dostarcza gotowe komponenty do pobierania postów, autoryzacji edytora oraz tzw. previews z poziomu klasycznego edytora WordPress. Dla zespołów, które chcą zachować workflow Gutenberga z natywnym podglądem, Faust jest najszybszą drogą. SEO-meta obsługuje wtyczka wp-graphql-rank-math lub wp-graphql-yoast-seo, a Faust eksponuje je przez hooki, które renderują dane w <Head> Next.js.
WPEngine Atlas
Atlas to zarządzana platforma hostingowa od WP Engine dedykowana headless. Łączy hosting WordPress z hostingiem Node.js dla frontendu w jednym panelu, oferuje wbudowany CDN i preview environments. Jest droższy od ogólnego hostingu, ale eliminuje typowe problemy operacyjne: rotację tokenów, deploy preview, cache warming. Dobre rozwiązanie dla wydawców, którzy chcą skupić się na contencie, a nie DevOps. Więcej o automatyzacji deploya i danych z analityki znajdziesz w opracowaniu API GA4 i Search Console: praktyczny pipeline w 2026, gdzie omawiamy spinanie metryk wydajności z monitoringiem frontu.
Frontity
Frontity, mimo że oficjalnie wstrzymany przez Automattic w 2022 r., żyje w społeczności jako fork i wciąż jest używany w setkach średnich serwisów wydawniczych. Jest oparty na Reacie, ale z mniejszą stromizną uczenia się niż Next.js. W 2026 polecamy go tylko wtedy, gdy zespół ma już istniejący kod we Frontity i nie planuje migracji, albo gdy bardzo zależy mu na automatycznym mapowaniu szablonów WP na komponenty React bez ręcznego programowania routera.
Next.js sam w sobie
Najbardziej elastyczna opcja: Next.js (lub App Router od wersji 14) plus wybrana biblioteka do GraphQL (Apollo, urql) lub po prostu fetch do REST API. Brak warstwy pośredniej oznacza pełną kontrolę i większą złożoność. To droga rekomendowana dla projektów z nietypowymi wymaganiami (np. multi-site, niestandardowe pola, integracje z headless commerce). W warstwie cache najczęściej spotyka się ISR (Incremental Static Regeneration) z webhookami z WordPressa, które unieważniają strony po publikacji.
Jak to wdrożyć krok po kroku
Migracja działającego serwisu WordPress na headless jest projektem na minimum 8 tygodni dla średniej redakcji. Poniższy harmonogram dotyczy serwisu o ~5000 wpisów, 50 kategoriach i ustabilizowanym ruchu organicznym. Dla mniejszych projektów można skrócić każdy etap, ale nie pominąć żadnego.
Krok 1: audyt baseline
Przed dotknięciem czegokolwiek zrób pełny snapshot stanu wyjściowego. Crawl całego serwisu (Screaming Frog lub Sitebulb), eksport wszystkich URL z Google Search Console, eksport rankingów z Ahrefs/Senuto/Semrush. Zachowaj indeks pages indexed, średnią pozycję top 10 zapytań, CTR i CWV (LCP, INP, CLS na poziomie 75 percentyla). Bez baseline nie wiesz, czy headless pomógł, czy zaszkodził. Podobny proces opisuje opracowanie Crawl budget 2026: Screaming Frog, Sitebulb, JetOctopus, Oncrawl, do którego wracamy także po migracji.
Krok 2: instalacja API i mapowanie pól
Na WordPressie zainstaluj WPGraphQL (jeśli wybierasz GraphQL) oraz dodatek do swojego SEO plugina (wp-graphql-rank-math lub wp-graphql-yoast-seo). Wyłącz frontend WordPressa przekierowując go na adres frontendu w functions.php motywu (warunkowo, żeby /wp-admin i preview działały). Zmapuj wszystkie typy treści: posts, pages, custom post types, taksonomie, ACF. Pola SEO powinny wracać z API w jednym requeście razem z treścią.
Krok 3: SSR i kanonikalizacja
W Next.js skonfiguruj getStaticProps z revalidate dla artykułów (ISR) lub getServerSideProps dla stron silnie zmieniających się. Dla każdej strony renderuj kompletny <head>: <title>, meta description, link rel=canonical wskazujący na produkcyjny URL, Open Graph, Twitter Card, JSON-LD Article (lub odpowiedni typ schema). Sprawdź to ręcznie kilku stron view-source:, nie polegaj wyłącznie na narzędziach.
Krok 4: routing i przekierowania
Dynamiczne ścieżki Next.js ([...slug]) muszą obsłużyć dokładnie tę samą strukturę URL co produkcja. Jeśli zmieniasz strukturę (np. usuwasz daty z URL), przygotuj komplet przekierowań 301 w pliku next.config.js lub w warstwie edge (Vercel, Cloudflare Workers). Pamiętaj o trailing slash zgodnym z dotychczasowym ustawieniem WP, inaczej każdy URL będzie ładował się dwa razy z kanonikalizacją po stronie Google.
Krok 5: sitemap i robots.txt
Wyłącz sitemapę generowaną przez WordPress i wygeneruj ją po stronie frontendu jako endpoint /sitemap.xml (Next.js wspiera to natywnie w app/sitemap.ts). Sitemapa musi odzwierciedlać URL frontendu, nie API. Robots.txt też renderuj z frontu (app/robots.ts), z poprawnym linkiem do sitemapy i z blokadą crawlerów na adresie API (/wp-json/).
Krok 6: cache, ISR i webhooki
Skonfiguruj webhook z WordPressa (np. wtyczka WP Webhooks lub własna funkcja w functions.php), który po publikacji lub aktualizacji posta wysyła żądanie do endpointu rewalidacji w Next.js. Bez tego ISR będzie serwował przestarzałe treści. Endpoint rewalidacji powinien przyjmować slug i tag (np. tag:posts), żeby unieważnić listingi, sitemapy i archiwa.
Krok 7: testy i kontrolowane wdrożenie
Wdróż frontend na subdomenie staging.example.com z robots noindex. Przepuść Screaming Frog porównawczy: oba crawle powinny dać tę samą liczbę URL, tytuły, meta i status code. Jeśli różnice są kosmetyczne, zatwierdź deploy. Switchover wykonaj w godzinach niskiego ruchu, monitoruj logi serwera i Search Console na bieżąco przez pierwsze 72 godziny.
Najczęstsze błędy i pułapki
Większość katastrof headless SEO da się przypisać do jednej z poniższych kategorii. Każdą warto przerobić jako checklistę przed go-live.
CSR zamiast SSR
Najczęstszy błąd. Programista składa Next.js w trybie useEffect + fetch, treść pojawia się dopiero po wykonaniu JavaScript. Googlebot czasem ją zobaczy (rendering w drugiej fali), LLM-y nie zobaczą jej prawie nigdy. Sprawdzaj zawsze view-source: i narzędzie URL Inspection w Search Console. Jeśli w HTML nie ma treści artykułu, masz CSR. Napraw przez przeniesienie pobierania danych do getStaticProps, getServerSideProps lub serwerowych komponentów App Routera.
Brakujące meta SEO
Frontend pobiera artykuł, ale ignoruje pola SEO z RankMath. Skutek: tytuł i description generuje sobie sam Google z pierwszych zdań treści. CTR spada o 20 do 40 procent. Zawsze pobieraj i wstrzykuj komplet pól z API. Jeśli używasz RankMath, zwróć uwagę, by w ustawieniach wtyczki pt_post_primary_taxonomy miało wartość category (bez tego primary category nie ląduje w polach SEO, a URL może się degradować do najniższego ID kategorii).
Złamane przekierowania po zmianie struktury URL
Migracja to dobra okazja do oczyszczenia URL, ale każda zmiana wymaga 301 z dokładnym mapowaniem 1 do 1. Brak przekierowania to utrata linków zwrotnych i pozycji w SERP w ciągu tygodni. Eksportuj listę wszystkich URL przed migracją, przepuść przez logikę nowej struktury i przygotuj plik mapowania. Po deployu re-crawluj baseline i sprawdź, czy każdy stary URL zwraca 301 do żywego nowego URL.
Sitemapa renderowana z API zamiast z frontu
Sitemapa WP po zainstalowaniu headless często wciąż linkuje do adresów wp-json lub do dawnego frontu. Google z czasem podąża za nią i deindeksuje nowy frontend. Zawsze wyłącz natywną sitemapę WP (zarówno tę z core, jak i z SEO plugina) i wygeneruj świeżą z poziomu frontendu. Walidacja w GSC po deployu, sitemap submitted i pages indexed po 7 do 14 dni powinny być stabilne.
Brak unieważniania cache po publikacji
ISR bez webhooka oznacza, że zmiana treści pojawia się po godzinach lub dniach. Redakcja traci zaufanie do systemu, a Google indeksuje stare wersje artykułów. Webhook rewalidacyjny to obowiązkowy element wdrożenia.
Otwarte API jako wektor ataku i scrapingu
Endpoint /wp-json/wp/v2/users domyślnie ujawnia listę autorów i potencjalne loginy. Zablokuj go w robots.txt (dla scraperów), a w warstwie nginx/Cloudflare ogranicz dostęp do /wp-json/ tylko z IP frontendu (jeśli stos na to pozwala) lub wymuś autoryzację. Dobre praktyki opisuje REST API FAQ na WordPress.org.
Praktyczna konfiguracja: Faust.js plus RankMath plus Next.js 14
Najczęściej spotykany stos produkcyjny w 2026 łączy Faust.js z RankMath i App Routerem Next.js 14. Konfiguracja wygląda następująco. Po stronie WordPressa instalujesz WPGraphQL, FaustWP (wtyczka mostkująca) oraz wp-graphql-rank-math. W ustawieniach FaustWP wpisujesz adres frontendu i sekret do autoryzacji preview. W RankMath upewniasz się, że pt_post_primary_taxonomy jest ustawione na category (sprawdzasz to w bazie w tabeli options lub w panelu RankMath: Ustawienia > Tytuły & Meta > Wpisy > Primary Taxonomy).
Po stronie frontendu używasz create-next-app z presetem Faust, który dodaje hooki useQuery i useFaustNavigation. Komponent renderujący pojedynczy post w App Routerze (app/[...slug]/page.tsx) pobiera dane przez serwerową funkcję fetch z WPGraphQL i dziedziczy meta przez generateMetadata. Sygnatura wygląda mniej więcej tak: export async function generateMetadata({ params }) zwraca obiekt z title, description, openGraph, twitter i alternates.canonical, wszystkie zaczerpnięte z pól RankMath wystawionych przez API.
Dla artykułów ustawiasz revalidate na 3600 sekund (godzina) jako bezpieczny default, plus webhook unieważniający. Dla list i archiwów ustaw 600 sekund (10 minut) i dodatkowo unieważnij posts tag z webhooka po każdej publikacji. Sitemap (app/sitemap.ts) pobiera listę wszystkich opublikowanych slugów w jednym zapytaniu GraphQL z paginacją 100 i renderuje XML zgodny z protokołem sitemap.org. Dla bardzo dużych serwisów warto rozbić sitemapę na indeks (sitemap_index.xml) i osobne pliki per typ treści.
Migracja mediów, ACF i custom post types
Trzy obszary, które prawie zawsze są niedoszacowane na początku projektu headless: biblioteka mediów, pola ACF i custom post types. Każdy z nich wymaga osobnego potraktowania, inaczej deploy lądowano na produkcji z dziurami.
Biblioteka mediów
WordPress domyślnie wystawia media pod adresem /wp-content/uploads/. Po przejściu na headless masz dwa wybory: pozostawić media pod adresem WP i akceptować, że stanowią one cross-origin (z perspektywy frontendu pod inną domeną), albo proxować je przez frontend Next.js (np. next/image z remotePatterns). Drugie rozwiązanie daje pełną kontrolę nad optymalizacją (lazy loading, formaty AVIF/WebP, responsywne srcset), ale wymaga, by każdy URL obrazka był rozpoznawalny przez Next.js. Praktyczna rekomendacja: pozostaw media pod subdomeną media.example.com (CNAME na WP) i używaj next/image z whitelistowaną subdomeną.
Pola ACF
Advanced Custom Fields wymagają wtyczki wpgraphql-acf lub równoważnej dla REST. Każda grupa pól musi zostać zarejestrowana jako część schematu GraphQL, inaczej frontend nie zobaczy danych. Po stronie React tworzysz typy TypeScript odzwierciedlające schemat (najszybciej graphql-codegen), żeby kompilator pilnował zgodności. Pola typu Repeater i Flexible Content trzeba mapować na komponenty render-pól, co jest najbardziej żmudną częścią migracji.
Custom post types i taksonomie
CPT zarejestrowane przez kod (w functions.php lub w wtyczce) musisz ujawnić w GraphQL przez argument show_in_graphql i nadać graphql_single_name oraz graphql_plural_name. To samo dotyczy custom taksonomii. Bez tego endpoint zwraca pustkę, a frontend nie zobaczy nawet listy. Pamiętaj o regeneracji permalinków po każdej zmianie w CPT (Ustawienia > Bezpośrednie odnośniki > Zapisz).
Bezpieczeństwo, autoryzacja i ograniczanie API
Headless WordPress to dwa systemy zamiast jednego, więc powierzchnia ataku rośnie. Trzy elementy są krytyczne i warto je wdrożyć już na etapie stagingu.
Autoryzacja zapytań do API
Domyślnie WPGraphQL serwuje większość danych publicznie, ale do mutacji i pól wrażliwych potrzebujesz JWT lub Application Passwords. Frontend powinien używać dwóch klientów: jednego publicznego (z cache po stronie CDN dla read), drugiego z tokenem (do preview, draft mode, autoryzowanych operacji). Token trzymaj w zmiennych środowiskowych Vercel/Netlify, nigdy w kodzie repo. Rotuj go co 90 dni jako standard, a po każdym podejrzeniu wycieku natychmiast.
Rate limiting i ochrona przed scrapingiem
Bez warstwy rate limiting endpoint GraphQL może zostać zalany przez boty (LLM scraperzy, ahrefs/semrush mirrors, własne błędy aplikacji). Cloudflare WAF, Vercel Edge Middleware lub natywne rate limit w nginx ustaw na 60 zapytań na minutę per IP dla publicznych endpointów i 10 zapytań na minutę dla /wp-login.php oraz /xmlrpc.php. Logi tego ruchu warto trzymać 90 dni dla forensics.
Ukrycie wersji WordPress i listingu autorów
Nagłówek X-Powered-By, generator w <head> i endpoint /wp-json/wp/v2/users zdradzają, że pod spodem stoi WordPress, a często też wersję. Filtruj generator (remove_action('wp_head', 'wp_generator')), wyłącz lub uautoryzuj endpoint users i ukryj nagłówek na poziomie Cloudflare lub serwera. Te zmiany nie zatrzymają zdeterminowanego atakującego, ale wyeliminują 90 procent automatycznych prób.
Mierzenie efektów i KPI
Headless wdrożony poprawnie podnosi wydajność i pośrednio konwersję, ale wpływ na ruch organiczny jest pomijalny w krótkim terminie. KPI należy mierzyć w dwóch oknach: technicznym (zmiana natychmiast) i biznesowym (zmiana po 6 do 12 tygodniach).
KPI techniczne, do mierzenia w pierwszym tygodniu
- LCP, INP, CLS w Search Console i CrUX: oczekuj poprawy LCP o 30 do 60 procent i INP do poziomu poniżej 200 ms na 75 percentylu.
- Time to First Byte z lokalizacji geograficznie reprezentatywnych dla ruchu: poniżej 200 ms dzięki CDN i SSR z cache.
- Lighthouse Performance: cel 90+ na mobile, 95+ na desktop. Niezależnie zmierz w PageSpeed Insights i WebPageTest.
- Czas renderowania w GSC: URL Inspection powinien renderować pełny HTML w pierwszym żądaniu (Fetched HTML i Rendered HTML powinny być prawie identyczne).
KPI biznesowe, do mierzenia po 6 do 12 tygodniach
- Pages indexed w GSC: po migracji oczekuj chwilowego spadku 5 do 15 procent, a następnie odbicia do baseline lub powyżej w 6 tygodniu.
- Średnia pozycja dla top 100 zapytań: utrzymanie lub poprawa o 1 do 3 pozycji po 8 tygodniach jest realnym celem przy poprawnej migracji.
- CTR z GSC: poprawa o 5 do 15 procent dzięki szybszemu LCP i lepszemu wrażeniu strony.
- Liczba cytowań w LLM-ach (ChatGPT, Perplexity, Gemini): mierzona narzędziami typu Otterly, AthenaHQ lub własnymi promptami z monitoringiem. Headless z czystym HTML i schema.org poprawia widoczność w LLM-ach o 20 do 50 procent w skali kilku miesięcy.
- Konwersja: na e-commerce migracja headless najczęściej przekłada się na 5 do 15 procent w newsletter sign-up i 2 do 8 procent w sprzedaży, głównie przez poprawę CWV.
Co śledzić w logach serwera
Po migracji szczególnie ważne jest monitorowanie 404, 500 i 502 z logów Cloudflare lub Vercel. Każdy nagły wzrost to sygnał, że ISR nie unieważnia poprawnie, że webhook się gubi albo że nowy URL nie jest pokryty przez routing. Logi serwera są twardszym sygnałem niż GSC, który raportuje z opóźnieniem 2 do 3 dni.
Realny przypadek: portal wydawniczy 30 tys. wpisów
Dla zilustrowania efektów weźmy reprezentatywne wdrożenie z 2025 roku: polski portal branżowy ze stosem WordPress plus WooCommerce, około 30 tys. wpisów blogowych i 8 tys. SKU. Stan baseline: LCP 4,1 s na 75 percentylu, INP 320 ms, pages indexed 27 200, średnia pozycja top 1000 zapytań 18,4. Migracja na Next.js 14 plus Faust.js plus WPGraphQL trwała 14 tygodni, w tym 6 tygodni audytu i mapowania, 4 tygodnie developmentu frontu, 2 tygodnie testów porównawczych, 2 tygodnie switchover i stabilizacji.
Wyniki po 12 tygodniach od go-live: LCP 1,3 s (poprawa 68 procent), INP 140 ms (poprawa 56 procent), pages indexed 28 900 (+6 procent, głównie dzięki odzyskaniu wcześniej deindeksowanych URL z problemami CWV), średnia pozycja 16,1 (+2,3 pozycji), wzrost ruchu organicznego o 17 procent rok do roku. Liczba cytowań w Perplexity (pomiar przez Otterly) wzrosła z 142 na 4 tygodnie przed migracją do 287 na 4 tygodnie po stabilizacji, czyli o 102 procent. Konwersja koszyk-do-zakupu poprawiła się z 2,4 procent do 2,9 procent, co przy poziomie ruchu portalu dało roczny wzrost przychodu o około 380 tys. zł, znacząco pokrywając koszt projektu.
Newralgiczny moment: w 3 tygodniu po deploy nastąpił spadek pages indexed o 8 procent, spowodowany niepoprawną konfiguracją hreflang dla wersji językowej. Naprawa zajęła 48 godzin, a powrót do baseline trwał kolejne 2 tygodnie. Lekcja: monitorowanie GSC w pierwszych 4 tygodniach musi być codzienne, nie tygodniowe.
Drugi wniosek z tego wdrożenia: największą wartość przyniosła nie sama wydajność, lecz fakt, że zespół frontend uzyskał możliwość iteracji nad UI bez czekania na zwolnione przez WordPress wtyczki cachujące. Czas wdrożenia nowego komponentu skrócił się z około 2 dni do około 4 godzin, co przy 12 wdrożeniach w kwartale dało redakcji realne narzędzie do testów A/B nagłówków, formatów leadu i CTA. To efekt drugiego rzędu, którego nie da się wykazać w pierwszym tygodniu, a który po roku staje się głównym uzasadnieniem inwestycji.
FAQ
Czy headless WordPress poprawia SEO automatycznie?
Nie. Headless poprawia warunki techniczne (LCP, INP, czysty HTML) i daje przewagę architektoniczną, ale samo wdrożenie bez poprawnego SSR, kanonikalizacji, sitemap i przekierowań może obniżyć ruch organiczny. Po migracji oczekuj 6 do 12 tygodni stabilizacji, a wzrost pozycji to pochodna jakości wdrożenia, nie samego przejścia na headless.
Faust.js, Atlas, czy goły Next.js: co wybrać?
Jeśli hostujesz w WP Engine, użyj Atlasa i Faust.js, bo eliminują problemy operacyjne. Jeśli masz własną infrastrukturę i zespół z mocnym Reactem, wybierz Next.js z WPGraphQL bezpośrednio. Frontity rozważ tylko wtedy, gdy masz już istniejącą bazę kodu we Frontity.
Jak długo trwa typowe wdrożenie headless dla średniego serwisu?
Dla serwisu z 5000 wpisów, ustabilizowanym ruchem i zespołem dwóch developerów: 8 do 12 tygodni od audytu baseline do switchovera produkcyjnego, plus 4 do 6 tygodni stabilizacji po wdrożeniu. Migracje większych portali (50k+ wpisów, multi-region) zajmują 6 do 9 miesięcy.
Czy RankMath i Yoast działają w headless WordPress?
Tak, oba wystawiają dane SEO przez dodatkowe wtyczki (wp-graphql-rank-math, wp-graphql-yoast-seo). Wymagają one wstrzyknięcia pól tytułu, opisu, kanonicznego URL, Open Graph i JSON-LD do warstwy frontendowej. Bez tego cała konfiguracja SEO przepada.
Czy headless wpływa na cytowania w ChatGPT i Perplexity?
Tak, pozytywnie. LLM-y i ich crawlery (GPTBot, PerplexityBot, Google-Extended) preferują strony zwracające czysty, semantyczny HTML w pierwszym żądaniu. Headless z poprawnym SSR i schema.org radzi sobie tu znacznie lepiej niż klasyczny WordPress obciążony wtyczkami, dlatego widoczność cytowań rośnie typowo o 20 do 50 procent w horyzoncie kilku miesięcy.
Co z edytorem treści po przejściu na headless?
Redakcja pracuje dokładnie tak samo jak w klasycznym WordPressie: edytor Gutenberg, kategorie, tagi, media. Faust.js dodaje natywny preview, w gołym Next.js trzeba skonfigurować draft mode (Next.js wspiera to wbudowanym mechanizmem). Workflow edytorski się nie zmienia, zmienia się tylko warstwa renderująca.