SEO w headless WordPress: siedem rzeczy, które psuje większość migracji
Headless WordPress sprzedaje się na Core Web Vitals, wielokrotnym użyciu treści i szybkości pracy redakcji. Jeśli nikt nie pilnuje, po drodze grzebie siedem konkretnych sygnałów SEO. Przeprowadziliśmy dość takich migracji, żeby wiedzieć, które z nich kosztują tygodnie odrabiania strat, a które da się utrzymać mechanicznie.
Ten artykuł to lista kontrolna. Nie zastępuje filaru usługi headless WordPress, gdzie stoją argumenty architektoniczne. To jest to, co sprawdzamy przed każdą migracją, w jej trakcie i po niej, w tej kolejności.
W skrócie
- Zachowuj adresy kanoniczne na poziomie całego URL, nie samego sluga.
- Zachowuj hreflang w HTML, nie tylko w mapie witryny.
- Renderuj meta tagi i JSON-LD na serwerze, nie w przeglądarce.
- Przenieś historię przekierowań przed zmianą adresów, nie po niej.
- Trzymaj jedną mapę witryny jako źródło prawdy, nie dwie.
- Ukryj origin WordPressa przed indeksem wyszukiwarek.
- Przenieś teksty alternatywne grafik i dane strukturalne obrazów.
Jak zachować adresy kanoniczne przy migracji do headless
Adres kanoniczny to obietnica. Liczy na nią każdy link zewnętrzny, każdy wpis w indeksie Google, każde udostępnienie w mediach społecznościowych. Migracja do headless, która po cichu obcina segment ścieżki, zmienia wielkość liter albo kolejność parametrów zapytania, właśnie złamała każdą z tych obietnic, i to bez śladu.
Dwie zasady. Po pierwsze, zanim dotkniesz frontendu, zbierz pełny zestaw adresów kanonicznych ze starej instalacji WordPressa. Eksportujemy każdy opublikowany wpis, stronę i stronę taksonomii z adresem, który Google ma w indeksie; to jest źródło prawdy. Po drugie, wpisz adres kanoniczny do odpowiedzi HTML frontendu headless, a nie do modyfikacji <head> wykonywanej po stronie klienta. Silniki generatywne i silniki odpowiedzi parsują początkowy HTML; meta tagi zmieniane w przeglądarce dla nich nie istnieją.
Jeśli musisz zmienić adres, zrób przekierowanie 301 ze starego na nowy i utrzymuj je przez co najmniej rok.
Tagi hreflang w HTML headless WordPress
Wielojęzyczne strony na WordPressie zarządzają tłumaczeniami przez WPML, Polylang albo własne rozwiązanie. W bazie danych mapowanie jest poprawne. Frontend headless musi potem wyrenderować <link rel="alternate" hreflang="..."> dla każdej wersji językowej w odpowiedzi HTML.
Wzorzec, który umyka większości agencji: hreflang musi wskazywać także na samą stronę. Strona angielska wymienia siebie i wszystkie przetłumaczone alternatywy. Strona polska wymienia siebie i wszystkie alternatywy. Obie listy się zgadzają. Narzędzia takie jak raport kierowania międzynarodowego w Search Console zgłaszają rozbieżność, gdy jedna strona o czymś zapomni.
Generowanie hreflang traktujemy jako część buildu, nie decyzję w czasie działania. Mapa ścieżek jest liczona przy buildzie i hashowana, a każdy dryf wywala build.
Renderowanie meta tagów i JSON-LD po stronie serwera
Najczęstszy regres SEO, jaki widzieliśmy w migracjach do headless: meta tagi i JSON-LD wstawiane JavaScriptem po załadowaniu strony. Przeglądarka je widzi. Googlebot czasem je widzi. Silniki generatywne, asystenci głosowi i większość crawlerów LLM zwykle nie.
Dwie zasady. Renderuj meta tagi, adres kanoniczny, Open Graph i każdy blok JSON-LD Schema.org w początkowej odpowiedzi HTML. W Astro to zachowanie domyślne. W Next.js oznacza to renderowanie na serwerze (metadane App Routera albo starsza ścieżka getServerSideProps), a nie poleganie na ponownym uruchomieniu next/head w przeglądarce.
To samo dotyczy grafik: element <img> z alt i src w HTML da się zaindeksować. <img> wstrzyknięty po efekcie po stronie klienta jest niewidoczny dla większości crawlerów i dla potoków danych treningowych AI.
Ponowne użycie JSON-LD z Yoast w headless WordPress
WordPress z Yoast SEO albo Rank Math już generuje dobry JSON-LD dla Article, Product i Organization. Przy migracji do headless kusi, żeby napisać go od zera na frontendzie. Nie ulegaj.
Odczytaj istniejący JSON-LD z originu WordPressa przez endpoint REST albo GraphQL. Przekaż go dalej. Dodaj tylko to, co frontend faktycznie wie, a WordPress nie (na przykład znaczniki czasu buildu dla dateModified, jeśli Twój proces redakcyjny nie rusza dat). Dwa systemy generujące nakładający się JSON-LD to prosta droga do błędów w raportach wyników z elementami rozszerzonymi w Search Console.
Na własnych stronach używamy komponentów z fazy 0 w src/components/seo/: DirectAnswer, FAQ i Quote. Każdy emituje własny, minimalny JSON-LD, który nie nakłada się na schemat Article całej strony.
Jak przenieść przekierowania przed zmianą adresów URL
Kolejność ma znaczenie. Lista kontrolna przed migracją zbiera każde przekierowanie wewnętrzne i zewnętrzne, także te ciche (/wp-content/... do /uploads/..., przekierowania według kodu kraju, warianty AMP). Nowy frontend wypuszcza te przekierowania w dniu zero, zanim publiczny ruch przejdzie na nowe adresy.
Na Cloudflare Pages trzymamy plik _redirects poniżej limitu platformy wynoszącego 2000 reguł. Build, który przekroczyłby limit, nie przechodzi. Wszystko, co wymaga więcej niż 2000 reguł, trafia zamiast tego do Workera z logiką przekierowań z parametrami.
Gdy publiczny DNS w końcu przełącza się na nowy frontend, żadne przekierowanie nie jest na produkcji nowe: każda reguła była testowana w buildzie przez tygodnie przed przełączeniem.
Jedna mapa witryny XML dla headless WordPress
WordPress 5.5 dodał domyślną mapę /wp-sitemap.xml. Yoast SEO i Rank Math dodają własne. Framework frontendu headless też generuje mapę witryny. Trzy mapy w jednej domenie to przepis na to, żeby Search Console wyrywało sobie włosy z głowy.
Zasada: wybierz jedną kanoniczną mapę witryny, a pozostałe wyłącz albo przekieruj. Zwykle generujemy mapę we frameworku frontendu, żeby adresy dokładnie zgadzały się z publiczną stroną, a mapę z originu WordPressa przekierowujemy 301 na tę z frontendu. Origin WordPressa staje się wtedy niewidoczny dla wyszukiwarek.
Jak ustawić noindex na backendzie headless WordPress
Migracja do headless zostawia origin WordPressa w działaniu, zwykle na subdomenie albo prywatnym hoście. Nadal serwuje wyrenderowany HTML, ma działającą mapę witryny i odpowiada na zapytania REST. Wyszukiwarki, które znajdą ten origin, zaindeksują go jako duplikat publicznej strony, a ten duplikat nie będzie tym, który się pozycjonuje.
Trzy zabezpieczenia. robots.txt originu blokuje wszystkie ścieżki poza endpointami REST i GraphQL. Origin wysyła X-Robots-Tag: noindex, nofollow w nagłówkach HTTP dla każdej odpowiedzi HTML. Mapa witryny originu jest usunięta albo zwraca 410.
Jeśli origin działa w tej samej domenie co publiczna strona, pod prefiksem ścieżki (na przykład /wp-admin/ albo /wp/), te same zabezpieczenia stosujesz w zakresie tych ścieżek.
Powiązane poradniki o SEO w headless WordPress
Ten artykuł wspiera filar usługi headless WordPress. Jeśli stoisz przed wyborem technologii, zobacz Headless WordPress, Next.js czy Astro 2026. Szerszy obraz widoczności, łącznie z cytowaniami w LLM, opisuje przewodnik po widoczności w AI i LLM: to nasze kanoniczne ujęcie tego, co wdrażamy w ramach AEO i GEO na tych fundamentach SEO.
