Sitemap i canonical w headless WordPress: jedno źródło prawdy, serwowane z frontu
Obecność w sitemapie jest słabym sygnałem canonical; przekierowania i rel=canonical są silniejsze. Kontekst wdrożenia: wzorców SEO dla headless WordPress, psują się po cichu.
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
Generuj mapę z kompletnego spisu publicznych tras i renderuj jeden canonical w head HTML. Spis może tworzyć front albo poprawnie skonfigurowany backend. Utrzymuj spójność aktywnych endpointów; kilka map podrzędnych jest poprawne.
Dlaczego witryny headless WordPress kończą z dwiema sitemapami
WordPress udostępnia sitemapę w rdzeniu od wersji 5.5. Dostępność zależy od konfiguracji i filtrów, a wtyczka SEO może wyłączyć dostawcę rdzenia. Sprawdź rzeczywiste endpointy; trzy jednoczesne generatory nie są nieuniknione.
/wp-sitemap.xmlz rdzenia WordPressa./sitemap_index.xmlz Yoasta albo Rank Math./sitemap.xmlz frameworka frontendowego.
Kilka sitemap może poprawnie współistnieć. Napraw sprzeczne listy publicznych adresów, lecz Google nie wybiera indeksowanych stron wyłącznie według kolejności odczytu map.
Wszystkie aktywne mapy powinny korzystać ze spójnego spisu publicznych tras. Wyłącz zbędny generator originu lub przekieruj jego XML, gdy to właściwe. Kilka map podrzędnych może zwracać 200 w ramach indeksu sitemap.
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.
Renderuj canonical w początkowym head HTML przez layout lub API metadanych frameworka. Google obsługuje canonical dodany przez JavaScript, lecz zaleca czytelny sygnał i unikanie późniejszych zmian. Początkowy HTML ułatwia również powtarzalne testy wydania.
Dopasuj metadane SEO do publicznej mapy tras. Yoast ma udokumentowane API REST; inne wtyczki wymagają własnej obsługiwanej integracji. Nie zakładaj, że canonical w ich odpowiedzi wskazuje już publiczny adres frontu.
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
Filtry wymagają jawnej polityki indeksacji. Canonical stosuj dla rzeczywistych duplikatów, a noindex przy zamierzonym wyłączeniu. Nie nakładaj obu dyrektyw automatycznie na wszystkie filtry.
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 stronę usługi headless WordPress oraz macierz decyzyjną Next.js czy Astro, gdzie omawiamy szersze decyzje dotyczące builda.
Wspólny model publicznych adresów
WordPress przechowuje identyfikatory wpisów i własne permalinki. Front headless może mieć inne prefiksy językowe, ścieżki kategorii oraz zasady końcowego ukośnika. Przed generowaniem XML ustal mapowanie ID wpisu i języka na publiczny adres. Traktuj ten model jak konfigurację aplikacji. Sama zamiana domeny originu nie wystarczy, jeśli zmienia się też ścieżka. Strona zagnieżdżona pod rodzicem w WordPressie może mieć na froncie płaski adres, a produkt przetłumaczony segment kategorii.
Ten sam resolver powinien obsługiwać linki wewnętrzne, sitemapę, canonical, alternatywy hreflang i identyfikatory danych strukturalnych. To zalecenie projektowe ogranicza sytuacje, w których kilka funkcji stopniowo zaczyna zwracać różne adresy dla jednego wpisu. Zachowaj jawne wyjątki redakcyjne. Canonical może celowo wskazywać publikację partnera przy syndykacji treści. Automatyczna zamiana wszystkich domen zniszczyłaby wtedy znaczenie ustawienia. Zewnętrzne cele weryfikuj osobno, zamiast mieszać je z domyślną polityką własnych adresów.
API Yoast udostępnia wynik SEO powiązany z adresami WordPressa. Pobranie tych danych nie dopasowuje ich automatycznie do innych tras frontu. Wybierz, czy aplikacja składa head z pól strukturalnych, czy przyjmuje zweryfikowany wynik integracji. Nie emituj pełnego head od wtyczki i dodatkowego canonical z layoutu. Sprawdzaj końcową odpowiedź, bo prawidłowy obiekt danych nadal może zostać wyrenderowany przez dwa komponenty.
Kompletny snapshot zamiast pierwszej strony API
Generator musi pobrać wszystkie strony kolekcji API. Pierwsza odpowiedź z wpisami nie jest pełnym spisem publikacji. Archiwa taksonomii wymagają osobnego zbioru, jeśli front rzeczywiście udostępnia ich użyteczne szablony. Zapisuj liczbę pobranych rekordów i porównuj ją z ostatnim poprawnym buildem. Gdy origin przestanie odpowiadać w połowie paginacji, zatrzymaj publikację albo zachowaj poprzedni kompletny artefakt. Skrócona mapa opublikowana jako poprawny wynik ukrywa awarię integracji.
Spis powinien zawierać wyłącznie istniejące trasy publicznego frontu. Opublikowany załącznik, autor lub termin w WordPressie nie tworzy automatycznie strony w aplikacji headless. Dodaj adres dopiero po ustaleniu szablonu i polityki indeksacji. Wyklucz szkice, strony wymagające logowania, wyszukiwanie wewnętrzne, źródła przekierowań i celowe noindex. Przy każdym odrzuconym rekordzie zapisz powód. Redaktor musi odróżnić świadome wyłączenie od wpisu zgubionego podczas pobierania.
Dokumentacja sitemap Google określa limit 50 000 adresów lub 50 MB nieskompresowanego pliku. Większy zbiór podziel i udostępnij przez indeks sitemap. Kilka plików podrzędnych jest normalną organizacją mapy, a podział według kolekcji pomaga analizować indeksację. Używaj pełnych publicznych adresów i poprawnego kodowania XML. Nieucieczony ampersand w loc może zepsuć dokument, choć przeglądarka otwiera odpowiadający mu adres.
Wartość lastmod powinna wynikać z istotnej zmiany treści lub metadanych, jeśli dysponujesz wiarygodnym czasem takiej zmiany. Data builda oznacza publikację artefaktu, a nie aktualizację wszystkich poradników. Zmiana lastmod dla każdego wpisu przy każdym deployu usuwa jego wartość informacyjną. Ustal też, czy techniczne przepisanie rekordu przez importer rzeczywiście zmieniło treść widoczną dla czytelnika. Stosuj tę decyzję konsekwentnie w mapie i metadanych artykułu.
Oddziel usunięcie strony od wyboru canonical
Canonical wskazuje preferowany adres w grupie duplikatów lub bardzo podobnych stron. Nie przekierowuje użytkownika i nie gwarantuje wyboru tego adresu przez Google. Jeśli dawny adres został zastąpiony, zastosuj stałe przekierowanie do odpowiednika. Rzeczywiste usunięcie bez odpowiednika może zwracać 404 albo 410. Przekierowanie wszystkich usuniętych wpisów na stronę główną utrudnia rozpoznanie treści, które faktycznie zniknęły przy migracji.
Noindex stosuj, gdy dostępna publicznie strona ma zostać wyłączona z wyników. Robot musi móc ją pobrać, aby odczytać dyrektywę. Wyjaśnia to dokumentacja noindex. Jednoczesna blokada tego adresu w robots.txt może uniemożliwić odczyt. Disallow steruje pobieraniem i nie zastępuje kontroli dostępu. Prywatny panel i podglądy zabezpieczaj uwierzytelnianiem, ponieważ instrukcje dla robotów nie chronią danych przed użytkownikiem.
Jeśli origin wcześniej obsługiwał publiczne artykuły, wybierz przekierowania do odpowiedników frontu albo jawną politykę canonical dla pozostawionych stron. Przekierowanie samego XML nie przekierowuje wpisów, które wcześniej były w nim wymienione. Sprawdź dawne adresy i linki wewnętrzne. Gdy WordPress ma służyć wyłącznie jako API, ogranicz niepotrzebne szablony publiczne bez blokowania endpointów potrzebnych aplikacji.
Paginacja i języki wymagają pełnych odpowiedników
Każda użyteczna strona archiwum zawiera inną listę wpisów i zwykle powinna wskazywać własny canonical. Google nie wykorzystuje już rel=prev i rel=next do rozpoznawania paginacji. Potwierdza to dokumentacja paginacji. Zapewnij zwykłe linki do następnych stron. Przycisk dokładający wyniki przez JavaScript nie daje robotowi tej samej ścieżki odkrywania treści. Sprawdź ostatnią stronę i adresy poza zakresem, aby puste wyniki nie zwracały bez końca statusu 200.
Mapa językowa musi zmieniać się razem z publikacjami. Niemiecki artykuł nie powinien wskazywać angielskiego canonical tylko dlatego, że angielski był tekstem źródłowym. Alternatywy hreflang dodawaj dla rzeczywiście opublikowanych odpowiedników. Każdy język powinien wskazywać kanoniczny adres swojej publikacji. Gdy usuniesz tłumaczenie, zaktualizuj również pozostałe wersje i sitemapę językową. Strona główna danego języka nie jest odpowiednikiem usuniętego poradnika.
Filtry wymagają decyzji o konkretnym produkcie. Stały landing kategorii z własnym opisem i użytecznym wyborem produktów może być indeksowany samodzielnie. Zmiana sortowania tej samej listy może wskazywać podstawowy adres. Wyniki wyszukiwania wewnętrznego można wyłączyć. Jedna kombinacja canonical i noindex dla wszystkich parametrów ignoruje te różnice. Przed rozszerzeniem routera zapisz dozwolone parametry, zasady normalizacji i cel indeksacyjny każdej klasy adresów.
Sprawdzenie artefaktu i odpowiedzi produkcyjnej
Manifest tras powinien zawierać adres żądania, oczekiwany status, cel canonical i politykę indeksacji. Porównaj go z XML i wygenerowanym HTML. Dla każdego adresu w mapie sprawdź, czy istnieje użyteczna strona, nie ma noindex i deklaruje oczekiwany canonical. Dla usuniętych tras sprawdź przekierowanie lub status usunięcia. W próbce uwzględnij polskie znaki, ścieżki zagnieżdżone i adresy kodowane. Sama kontrola strony głównej nie wykryje błędów mapowania slugów.
Po wdrożeniu wykonaj te same kontrole na produkcyjnej domenie. Preview może być poprawne, podczas gdy CDN zmienia ukośnik, zwraca starszy wariant HTML albo dodaje nieoczekiwany X-Robots-Tag. Porównaj nagłówki HTTP i początkowy dokument. Gdy skrypty zmieniają metadane, sprawdź również wynik renderowania. Zapisz identyfikator wydania, aby raport SEO rozróżniał nowy artefakt i odpowiedź z poprzedniego cache.
Search Console pokazuje canonical zadeklarowany przez właściciela, a po indeksacji także wybrany przez Google. Rozbieżność wymaga sprawdzenia duplikatów, przekierowań, linków i dostępności celu. Nie dowodzi rywalizacji dwóch plików sitemap. Zacznij od konkretnego adresu i jego wariantów. Po naprawie sygnałów pozostaw czas na ponowne pobranie, ponieważ udany deploy nie zmienia od razu interpretacji zapisanej przez wyszukiwarkę.
Przy migracji polskiego katalogu sprawdź dodatkowo sposób kodowania znaków w slugach historycznych. Ręcznie skopiowany adres z panelu i adres otrzymany przez API mogą wyglądać podobnie, lecz różnić się reprezentacją. Porównuj adres po tej samej normalizacji, której używa router. Zachowaj dawny manifest, aby kolejny import treści nie zmienił niezauważenie zakresu publicznych stron.
Odbiór migracji przez redakcję i zespół techniczny
Rozdziel odpowiedzialność za listę publikacji i sposób ich obsługi. Redakcja potwierdza, które poradniki mają pozostać dostępne, które zostały połączone i które tłumaczenia mają opublikowane odpowiedniki. Programista sprawdza, czy router realizuje tę decyzję. Lista zaakceptowana przez redakcję staje się punktem odniesienia dla porównania sitemap, dzięki czemu brak adresu nie jest automatycznie traktowany jako błąd pobierania.
Przy przeprowadzce z WordPressa sprawdź także linki ze starych newsletterów i dokumentów klientów. Nie wystarczy poprawna nawigacja nowej aplikacji. Historyczny link nadal trafia pod dawny adres i potrzebuje odpowiedniego statusu albo przekierowania. Zapisuj każde celowe połączenie artykułów wraz z docelową publikacją. Ta decyzja przydaje się również podczas analizy spadku ruchu na usuniętym adresie.
Kontrolę końcową wykonuj z uprawnieniami zwykłego odwiedzającego. Zalogowany administrator może zobaczyć szkic lub podgląd niedostępny publicznie. Test powinien potwierdzić rzeczywistą odpowiedź bez sesji, a nie ekran widoczny w panelu. Zachowaj wyniki dla adresu wejściowego i końcowego celu przekierowania, ponieważ poprawne 200 na końcu nie ujawnia niepotrzebnej wieloetapowej ścieżki.
Zależności po zmianie sluga
Zmiana sluga wpływa na więcej niż pojedynczy artykuł. Zaktualizuj odwołania w archiwum kategorii, polecanych publikacjach i wersjach językowych. Jeśli mapa powstaje niezależnie od HTML, webhook powinien uruchomić oba zadania albo opublikować je z tego samego snapshotu. Inaczej XML może wskazywać nową trasę, której bieżący frontend jeszcze nie obsługuje.
Zapisz stary i nowy adres w zdarzeniu aktualizacji. Samo ID wpisu pozwala znaleźć nową publikację, ale nie wystarcza do odtworzenia przekierowania ze starego adresu po nadpisaniu rekordu. W kolejce uwzględnij ponowienia i przetwarzanie tego samego zdarzenia więcej niż raz. Przekierowanie powinno prowadzić do końcowego celu, również wtedy, gdy redakcja zmieni slug ponownie przed ukończeniem poprzedniego builda.
Po zakończeniu publikacji pobierz stary adres bez automatycznego podążania za przekierowaniem. Sprawdź status i nagłówek Location, a następnie osobno stronę docelową. Potwierdź także, że nowy wpis pojawił się w mapie i posiada właściwy canonical. Te kontrole rozdzielają poprawną zmianę adresu od przypadkowego 200 zwracanego przez stronę błędu aplikacji.
Dla dokumentu PDF sprawdź również nagłówek HTTP Link z rel=canonical. Plik nie ma head HTML, więc kopiowanie testu przeznaczonego dla artykułów nie zweryfikuje tego sygnału. Osobno ustal, czy dokument powinien być w sitemapie i jaki publiczny adres jest jego wersją preferowaną.
