Sitemap og canonical i headless WordPress: én kilde til sannhet, levert fra frontenden
To av de sju SEO-mønstrene for headless WordPress fortjener en egen artikkel, fordi de ryker først og ryker i det stille. Sitemapen og den kanoniske URL-en er de to signalene Google stoler mest på når den skal avgjøre hva nettstedet er og hvilken URL som er den ekte. Et headless-oppsett som tar feil på ett av dem, mister rangeringene migreringen skulle bevare.
Denne artikkelen gjør mønsteret konkret. Den forutsetter at arkitekturvalget (Astro eller Next.js etter beslutningsmatrisen) allerede er tatt.
Hva er mønsteret for sitemap og canonical i headless, i ett avsnitt?
Generer sitemapen fra frontend-rammeverket, med URL-er som samsvarer med det faktiske offentlige nettstedet. Rendre den kanoniske URL-en som <link rel="canonical"> i HTML-head, hentet fra WordPress (Yoast eller Rank Math) og skrevet ut av frontenden. Slå av eller 301-videresend sitemapen og canonical fra WordPress-originen. Én sitemap, én canonical per side, begge rendret på serveren.
Hvorfor ender headless WordPress-nettsteder opp med to sitemaps?
WordPress 5.5 innførte /wp-sitemap.xml som kjernefunksjon. Siden da har alle WordPress-installasjoner den aktivert som standard. SEO-utvidelser (Yoast, Rank Math) genererer egne sitemaps som overstyrer eller supplerer kjernesitemapen. Et headless-oppsett som ignorerer dette, ender opp med tre sitemaps på samme vertsnavn:
/wp-sitemap.xmlfra WordPress-kjernen./sitemap_index.xmlfra Yoast eller Rank Math./sitemap.xmlfra frontend-rammeverket.
Search Console ser overlapp, flagger av og til inkonsistens, og hvilke URL-er som faktisk blir indeksert, avhenger av hvilken sitemap Google leser først den dagen. Løsningen er mekanisk:
- Frontend-rammeverket genererer den kanoniske sitemapen på én kjent sti (vi bruker
/sitemap-index.xmlfordi Cloudflare Pages leverer den uten problemer). - Sitemapen på WordPress-originen slås av (både Yoast og Rank Math har en bryter for det) eller 301-videresendes til frontend-sitemapen.
- Kjernesitemapen på
/wp-sitemap.xml301-videresendes også til tilsvarende fil i frontenden.
Etter omleggingen svarer bare én sitemap med 200 OK. Resten gir 301 eller 404.
Hvordan bygger du frontend-sitemapen i headless WordPress?
For en frontend i Astro eller Next.js finnes det to reelle alternativer:
Generering ved bygging. Frontend-bygget henter URL-ene til alle publiserte innlegg, sider og termer fra WordPress-originen under byggingen, sorterer dem og skriver ut XML-en. Dette fungerer for nettsteder med forutsigbar publiseringstakt (de fleste). Cache-invalidering løses ved å utløse et nytt bygg ved publisering.
På forespørsel i edge. En Cloudflare Worker-rute genererer sitemapen ved hver forespørsel og leser fra en mellomlagret URL-liste som WordPress-originen sender via webhook ved publisering. Dette passer for nettsteder som publiserer så ofte at byggetiden ville blitt et problem.
Vi bruker generering ved bygging som standard. Worker-mønsteret er forbeholdt nettsteder som publiserer mer enn noen få ganger i timen.
Hvordan skal den kanoniske URL-en rendres i en headless frontend?
Den kanoniske URL-en må stå i HTML-head, i den første serverresponsen, før noe skript kjører på klientsiden. Mønsteret:
<link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" />Tre regler.
Én: rendre på serveren. Astro rendrer den fra sidens frontmatter eller fra layouten. Next.js rendrer den fra metadata (App Router) eller fra <Head> i stier med getServerSideProps. Det du skal unngå, er å oppdatere den kanoniske URL-en i en klienteffekt; generative motorer og mange AEO-flater leser bare den første HTML-en.
To: hent den fra WordPress. Yoast og Rank Math eksponerer begge den kanoniske URL-en per innlegg via REST. Frontenden henter den under byggingen (eller per forespørsel) og rendrer den i HTML. WordPress forblir kilden til sannhet.
Tre: selvrefererende som standard. Hver URL oppgir seg selv som kanonisk, med mindre det finnes en uttrykkelig grunn til å peke et annet sted (paginerte arkiver, filtrerte URL-er med parametere, syndikert innhold). Når du peker et annet sted, peker canonical på målsiden tilbake på seg selv.
Hvilke grensetilfeller for sitemap og canonical ødelegger headless SEO?
- Inkonsekvent skråstrek på slutten. WordPress-permalenker slutter vanligvis med
/. Frontend-rammeverket kan som standard droppe skråstreken. Velg én variant, videresend den andre, og la aldri begge eksistere. - HTTP eller HTTPS, www eller apex. Løses som regel i CDN-et, men den kanoniske URL-en må oppgi den valgte varianten. Vi oppgir
https://på apex-domenet; alt annet 301-videresendes dit. - Filtrerte URL-er (fasettert katalogsøk). Disse gir ofte tusenvis av tynne URL-varianter. Canonical peker på den ufiltrerte basis-URL-en; de har også
noindexslik at de holdes utenfor sitemapen. - Paginerte arkiver. Side 2, side 3 og så videre har hver sin canonical til seg selv, med
rel="prev"ogrel="next"for tydelighet. Noen team peker canonical til side 1; da faller unike sider ut av indeksen. Det anbefaler vi ikke. - Oversatt innhold. Hver språkversjon har canonical til seg selv, med
<link rel="alternate" hreflang="...">for de andre versjonene. Hreflang-kartet er selvrefererende og må stemme på tvers av alle språkversjoner.
Hvordan validerer du sitemap og canonical før lansering?
To kontroller vi kjører på hvert headless WordPress-bygg:
Sitemap-diff. Generer den nye sitemapen og sammenlign URL-settet med den gamle WordPress-sitemapen. Alt som mangler i den nye, er et innholdshull. Alt som er nytt, er mistenkt regresjon (ofte et utkast eller et privat innlegg som lekker).
Canonical-stikkprøve. For 50 sider med mest trafikk ber du om URL-en i den nye frontenden og kontrollerer at canonical i HTML-head samsvarer med selve URL-en (eller med forventet mål hvis den bevisst peker til en annen side). Ett avvik er en feil; ti avvik er et mønster som krever at frontend-bygget sjekkes på nytt.
Begge kontrollene kjører i CI. Et nytt bygg som feiler på én av dem, blir ikke deployet.
Relaterte artikler om SEO i headless WordPress
Forankret i sjekklisten for SEO-mønstre for headless WordPress. Henger sammen med tjenestesøylen for headless WordPress og beslutningsmatrisen Next.js vs Astro for de bredere valgene rundt bygget.
