SEO-mønstre for headless WordPress: de sju tingene de fleste migreringer ødelegger
Headless WordPress selges på Core Web Vitals, gjenbruk av innhold og redaksjonell fart. Hvis ingen følger med, begraver det sju konkrete SEO-signaler underveis. Vi har gjennomført nok slike migreringer til å vite hvilke av dem som koster uker med gjenoppretting, og hvilke som er rent mekaniske å holde riktige.
Denne artikkelen er sjekklisten. Den erstatter ikke tjenestesiden for headless WordPress, som tar den arkitektoniske argumentasjonen. Den beskriver det vi går gjennom før, under og etter hver migrering, i den rekkefølgen.
Kort fortalt
- Bevar kanoniske URL-er på URL-nivå, ikke bare på slug-nivå.
- Bevar hreflang i HTML, ikke bare i nettstedskartet.
- Rendre metatagger og JSON-LD på serveren, ikke på klienten.
- Flytt viderekoblingshistorikken før du endrer URL-er, ikke etterpå.
- Ha ett nettstedskart som sannhetskilde, ikke to.
- Skjul WordPress-originen for søkeindeksen.
- Ta med alt-tekster og strukturerte bildedata videre.
Slik beholder du kanoniske URL-er i en headless-migrering
En kanonisk URL er et løfte. Hver ekstern lenke, hver oppføring i Googles indeks og hver deling i sosiale medier regner med den. En headless-migrering som i det stille kutter et stisegment, endrer store og små bokstaver eller bytter rekkefølge på spørringsparametere, har nettopp brutt hvert eneste av disse løftene uten at noen merker det.
To regler. For det første: hent ut hele settet med kanoniske URL-er fra den gamle WordPress-installasjonen før du rører frontenden. Vi eksporterer hvert publiserte innlegg, hver side og hver taksonomiside med URL-en Google har indeksert; det er sannhetskilden. For det andre: skriv canonical inn i HTML-svaret fra headless-frontenden, ikke i en endring av <head> på klientsiden. Generative motorer og svarmotorer parser den første HTML-en; metatagger som endres på klientsiden, finnes ikke for dem.
Hvis du må endre en URL, viderekoble med 301 fra den gamle til den nye, og la det stå i minst ett år.
Hreflang-tagger i HTML fra headless WordPress
Flerspråklige WordPress-nettsteder bruker WPML, Polylang eller en egen løsning for å styre oversettelser. Koblingen ender opp riktig i databasen. Headless-frontenden må deretter rendre <link rel="alternate" hreflang="..."> for hver språkversjon i HTML-svaret.
Mønsteret de fleste byråer overser: hreflang må være selvrefererende. Den engelske siden lister seg selv pluss alle oversatte alternativer. Den polske siden lister seg selv pluss alle alternativer. De to listene stemmer overens. Verktøy som rapporten for internasjonal målretting i Search Console flagger avviket når én side glemmer noe.
Vi behandler generering av hreflang som en del av bygget, ikke som en beslutning ved kjøretid. Stikartet beregnes ved bygging og hashes, og enhver avdrift får bygget til å feile.
Serverside-rendring av metatagger og JSON-LD
Den vanligste SEO-tilbakegangen vi har sett i headless-migreringer: metatagger og JSON-LD som settes inn med JavaScript etter at siden er lastet. Nettleseren ser dem. Googlebot ser dem noen ganger. Generative motorer, stemmeassistenter og de fleste LLM-crawlere gjør det som regel ikke.
To regler. Rendre metataggene, canonical, Open Graph og hver Schema.org JSON-LD-blokk i det første HTML-svaret. Med Astro er det standard. Med Next.js betyr det å rendre på serveren (metadata i App Router, eller den eldre veien via getServerSideProps) og ikke stole på at next/head kjøres på nytt i klienten.
Det samme gjelder bilder: et <img>-element med alt og src i HTML kan indekseres. Et <img> som injiseres etter en klienteffekt, er usynlig for de fleste crawlere og for pipelines med treningsdata for KI.
Gjenbruk av JSON-LD fra Yoast i headless WordPress
WordPress med Yoast SEO eller Rank Math lager allerede god JSON-LD for Article, Product og Organization. I en headless-migrering er fristelsen å skrive den på nytt fra bunnen av i frontenden. Ikke gjør det.
Les eksisterende JSON-LD fra WordPress-originen via REST- eller GraphQL-endepunktet. Send den videre. Legg bare til det frontenden faktisk vet og WordPress ikke vet (for eksempel byggetidsstempler for dateModified hvis den redaksjonelle arbeidsflyten din ikke rører datoene). To systemer som lager overlappende JSON-LD, er veien til at rapportene for utvidede resultater i Search Console begynner å feile.
På våre egne sider bruker vi komponentene fra fase 0 i src/components/seo/: DirectAnswer, FAQ og Quote. Hver av dem sender ut sin egen minimale JSON-LD uten å overlappe med Article-skjemaet for siden.
Slik flytter du viderekoblinger før URL-ene endres
Rekkefølgen betyr noe. Sjekklisten før migreringen fanger opp hver interne og eksterne viderekobling, også de stille (/wp-content/... til /uploads/..., viderekoblinger etter landskode, AMP-varianter). Den nye frontenden leverer disse viderekoblingene på dag null, før den offentlige overgangen til de nye URL-ene.
På Cloudflare Pages holder vi _redirects-filen under plattformens grense på 2000 regler. Et bygg som ville gått over grensen, feiler. Alt som trenger mer enn 2000 regler, havner i stedet i en Worker med logikk for parameteriserte viderekoblinger.
Når den offentlige DNS-en til slutt peker til den nye frontenden, er ingen viderekobling ny i produksjon: hver regel er testet i bygget i flere uker før overgangen.
Ett XML-nettstedskart for headless WordPress
WordPress 5.5 la til en standard /wp-sitemap.xml. Yoast SEO og Rank Math legger til sine egne. Frontend-rammeverket i headless-oppsettet lager også et nettstedskart. Tre nettstedskart på samme domene er en sikker oppskrift på at Search Console river seg i håret.
Regelen: velg ett kanonisk nettstedskart og deaktiver eller viderekoble de andre. Vi genererer som regel nettstedskartet i frontend-rammeverket, slik at URL-ene stemmer nøyaktig med det offentlige nettstedet, og viderekobler nettstedskartet fra WordPress-originen med 301 til det fra frontenden. Da blir WordPress-originen usynlig for søk.
Slik setter du noindex på backenden i headless WordPress
En headless-migrering lar WordPress-originen kjøre videre, som regel på et underdomene eller et privat vertsnavn. Den serverer fortsatt rendret HTML, har et fungerende nettstedskart og svarer på REST-spørringer. Søkemotorer som finner originen, indekserer den som et duplikat av det offentlige nettstedet, og duplikatet blir ikke det som rangerer.
Tre kontroller. Originens robots.txt blokkerer alle stier unntatt REST- og GraphQL-endepunktene. Originen sender X-Robots-Tag: noindex, nofollow i HTTP-headerne for hvert HTML-svar. Originens nettstedskart fjernes eller returnerer 410.
Hvis originen ligger på samme domene som det offentlige nettstedet under et stiprefiks (for eksempel /wp-admin/ eller /wp/), gjelder de samme kontrollene, avgrenset til disse stiene.
Relaterte guider om SEO for headless WordPress
Denne artikkelen støtter tjenestesiden for headless WordPress. Står du foran valget av teknologi, se Headless WordPress, Next.js vs Astro 2026. Det større bildet av synlighet, inkludert LLM-siteringer, finner du i guiden til synlighet i KI og LLM-er: den er vår samlede beskrivelse av hva vi leverer for AEO og GEO oppå dette SEO-fundamentet.
