Sitemap i canonical w headless WordPress: jedno źródło prawdy, serwowane z frontu
Dwa z siedmiu wzorców SEO dla headless WordPress zasługują na osobny artykuł, bo psują się jako pierwsze i psują się po cichu. Mapa strony i adres kanoniczny to dwa sygnały, którym Google ufa najbardziej, gdy ustala, czym jest ta witryna i który adres jest właściwy. Wdrożenie headless, które pomyli się w którymkolwiek z nich, traci pozycje, dla których utrzymania przeprowadzono migrację.
Ten artykuł pokazuje wzorzec w praktyce. Zakłada, że decyzja architektoniczna (Astro czy Next.js według macierzy decyzyjnej) już zapadła.
Na czym polega wzorzec sitemapy i canonical w headless w jednym akapicie?
Sitemapę generuje framework frontendowy, z adresami zgodnymi z rzeczywistą publiczną stroną. Adres kanoniczny renderujesz jako <link rel="canonical"> w head HTML: dane pochodzą z WordPressa (Yoast albo Rank Math), a emituje je front. Sitemapę i canonical originu WordPressa wyłączasz albo przekierowujesz 301. Jedna mapa strony, jeden canonical na stronę, oba renderowane po stronie serwera.
Dlaczego witryny headless WordPress kończą z dwiema sitemapami?
WordPress 5.5 wprowadził /wp-sitemap.xml jako funkcję rdzenia. Od tamtej pory każda instalacja WordPressa ma ją domyślnie włączoną. Wtyczki SEO (Yoast, Rank Math) generują własne mapy, które zastępują albo uzupełniają tę z rdzenia. Wdrożenie headless, które to ignoruje, kończy z trzema sitemapami na tym samym hoście:
/wp-sitemap.xmlz rdzenia WordPressa./sitemap_index.xmlz Yoasta albo Rank Math./sitemap.xmlz frameworka frontendowego.
Search Console widzi nakładanie się, czasem zgłasza niespójność, a to, które adresy faktycznie trafią do indeksu, zależy od tego, którą mapę Google przeczyta danego dnia jako pierwszą. Poprawka jest mechaniczna:
- Framework frontendowy generuje kanoniczną sitemapę pod jedną znaną ścieżką (my używamy
/sitemap-index.xml, bo Cloudflare Pages serwuje ją bez problemów). - Sitemapa originu WordPressa jest wyłączona (Yoast i Rank Math mają do tego przełącznik) albo przekierowana 301 na sitemapę frontu.
- Sitemapa z rdzenia pod
/wp-sitemap.xmlrównież dostaje przekierowanie 301 na odpowiednik we froncie.
Po przełączeniu tylko jedna mapa strony odpowiada kodem 200 OK. Pozostałe zwracają 301 albo 404.
Jak zbudować sitemapę frontu w headless WordPress?
Przy froncie na Astro albo Next.js są dwie realne opcje:
Generowanie w czasie builda. Build frontu pobiera z originu WordPressa adresy wszystkich opublikowanych wpisów, stron i termów, sortuje je i emituje XML. Sprawdza się to w witrynach z przewidywalnym rytmem publikacji (czyli w większości). Unieważnianie cache załatwia przebudowa uruchamiana przy publikacji.
Na żądanie na krawędzi. Trasa w Cloudflare Worker generuje sitemapę przy każdym żądaniu, czytając z zapisanej w cache listy adresów, którą origin WordPressa wypycha webhookiem przy publikacji. To rozwiązanie dla witryn publikujących tak często, że czas przebudowy byłby problemem.
Domyślnie wybieramy generowanie w czasie builda. Wzorzec z Workerem zostawiamy dla witryn publikujących częściej niż kilka razy na godzinę.
Jak renderować adres kanoniczny na froncie headless?
Adres kanoniczny musi być w head HTML, w pierwszej odpowiedzi serwera, zanim wykona się jakikolwiek skrypt po stronie klienta. Wzorzec:
<link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" />Trzy zasady.
Po pierwsze, renderuj po stronie serwera. Astro renderuje go z frontmattera strony albo z layoutu. Next.js renderuje go z metadata (App Router) albo z <Head> w ścieżkach z getServerSideProps. Unikaj aktualizowania adresu kanonicznego w efekcie po stronie klienta: silniki generatywne i wiele powierzchni AEO parsuje wyłącznie pierwotny HTML.
Po drugie, pobieraj go z WordPressa. Yoast i Rank Math udostępniają adres kanoniczny każdego wpisu przez REST. Front pobiera go w czasie builda (albo przy każdym żądaniu) i renderuje w HTML. WordPress pozostaje źródłem prawdy.
Po trzecie, domyślnie samoodwołujący. Każdy adres deklaruje jako kanoniczny sam siebie, chyba że istnieje wyraźny powód, by wskazać inny (paginowane archiwa, adresy z parametrami filtrów, treści syndykowane). Gdy wskazujesz inny adres, docelowy canonical wskazuje z powrotem na siebie.
Które przypadki brzegowe sitemapy i canonical psują SEO w headless?
- Niespójny ukośnik na końcu. Permalinki WordPressa zwykle kończą się
/. Framework frontendowy może domyślnie działać bez ukośnika. Wybierz jedną wersję, drugą przekieruj i nigdy nie pozwól, by istniały obie. - HTTP a HTTPS, www a domena główna. Zwykle rozwiązywane na CDN, ale adres kanoniczny musi deklarować wybrany wariant. My deklarujemy
https://na domenie głównej; cała reszta dostaje 301 na ten adres. - Adresy z filtrami (fasetowe wyszukiwanie w katalogu). Często generują tysiące ubogich wariantów adresu. Ich canonical wskazuje na bazowy adres bez filtrów; mają też
noindex, żeby nie trafiały do sitemapy. - Paginowane archiwa. Strona 2, strona 3 i kolejne mają canonical na siebie, z
rel="prev"irel="next"dla jasności. Niektóre zespoły kierują canonical na stronę 1; w ten sposób unikalne strony wypadają z indeksu. Nie polecamy tego. - Treści tłumaczone. Każda wersja językowa ma canonical na siebie, z
<link rel="alternate" hreflang="...">dla pozostałych wersji. Mapa hreflang jest samoodwołująca i musi być zgodna we wszystkich wersjach językowych.
Jak sprawdzić sitemapę i canonical przed startem?
Dwie kontrole, które uruchamiamy przy każdym wdrożeniu headless WordPress:
Porównanie sitemap. Wygeneruj nową mapę strony i porównaj zbiór adresów z dotychczasową sitemapą WordPressa. Wszystko, czego brakuje w nowej, to luka w treści. Wszystko, co nowe, to podejrzenie regresji (często wyciekający szkic albo prywatny wpis).
Próbka adresów kanonicznych. Dla 50 stron o największym ruchu pobierz adres z nowego frontu i sprawdź, czy canonical w head HTML jest zgodny z samym adresem (albo z oczekiwanym celem, jeśli canonical celowo wskazuje inną stronę). Jedna niezgodność to błąd; dziesięć niezgodności to wzorzec, który wymaga ponownego sprawdzenia builda frontu.
Obie kontrole działają w CI. Nowy build, który nie przejdzie którejkolwiek z nich, nie trafia na produkcję.
Powiązane poradniki o SEO w headless WordPress
Artykuł opiera się na liście kontrolnej wzorców SEO dla headless WordPress. Uzupełnia filar usługi headless WordPress oraz macierz decyzyjną Next.js czy Astro, gdzie omawiamy szersze decyzje dotyczące builda.
