SEO-mønstre for headless WordPress: de sju tingene de fleste migreringer ødelegger

#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. Googles veiledning om lokaliserte versjoner krever at hver språkversjon lister seg selv og alle de andre, og når to sider ikke peker på hverandre, ignorerer Google taggene.

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.

#Slik behandler Google JavaScript i en headless-frontend

Ifølge Google Search Centrals grunnleggende om JavaScript-SEO behandler Google JavaScript-baserte nettapper i tre faser: gjennomsøking, gjengivelse og indeksering. Googlebot setter alle sider som svarer med statuskode 200 i køen for gjengivelse, med mindre en robots-metatagg eller -header sier at siden ikke skal indekseres. En side kan bli liggende noen sekunder i køen, men dokumentasjonen advarer om at det kan ta lengre tid.

For en headless-frontend har dette en praktisk følge. Det som kommer i det første HTML-svaret, behandles i første runde; det som avhenger av JavaScript, venter på gjengivelsen. Den samme veiledningen sier at serverside-rendring eller forhåndsrendring fortsatt er en god idé, fordi det gjør nettstedet raskere for brukere og robotsøkere, og fordi ikke alle roboter kan kjøre JavaScript. Derfor behandler vi den første HTML-en som SEO-kontrakten for hver rute: tittel, metabeskrivelse, canonical, hreflang, lenker og JSON-LD må ligge der uten at noe kjøres.

Bilder følger samme logikk. Googles veiledning om utsatt innlasting nevner nettleserens innebygde utsatte innlasting og IntersectionObserver API som søkevennlige metoder, fordi de laster innhold når det er synlig i visningsområdet og ikke avhenger av rulling eller klikk, noe Google Søk ikke gjør. Den fraråder også utsatt innlasting av bilder brukeren ser med en gang. Kontrollen gjøres i den gjengitte HTML-en: bildets URL må stå i src-attributtet til <img>-elementet, noe verktøyet for URL-inspeksjon i Search Console viser.

#Hvorfor dynamisk rendring ikke løser SEO for headless WordPress

I mange år var dynamisk rendring den raske utveien for en enkeltsideapp koblet til WordPress: roboter får forhåndsrendret HTML, brukere får JavaScript-appen. Google Search Central beskriver det nå som en midlertidig løsning som ikke anbefales, og anbefaler i stedet serverside-rendring, statisk rendring eller hydrering.

Den samme siden presiserer at Googlebot vanligvis ikke regner dynamisk rendring som cloaking, men at det kan regnes som cloaking å servere helt forskjellig innhold til brukere og robotsøkere. I et headless-prosjekt betyr det å vedlikeholde to rendringsløp som må gi samme innhold, og ingen merker det når de glir fra hverandre. En frontend som rendrer på serveren eller i bygget, fjerner dobbeltarbeidet: brukere, Googlebot og roboter uten JavaScript får den samme HTML-en.

#HTTP-statuskoder og soft 404 i en headless-frontend

Når frontenden spør WordPress REST API om en slug som ikke finnes, får den en tom samling, ikke en feil. Hvis den da rendrer en “ikke funnet”-mal med status 200, setter Googlebot den i gjengivelseskøen som en hvilken som helst gyldig side, og resultatet er en soft 404. Med serverside-rendring er rettelsen direkte: et tomt svar betyr at frontenden returnerer en ekte 404, eller en 410 når innholdet er fjernet med vilje.

Det samme gjelder utkast og private innlegg. Ifølge referansen for innleggsendepunktet har samlingens status-parameter standardverdien publish, så et avpublisert innlegg forsvinner fra svaret, og ruten må svare med en feilkode, ikke en tom side.

For ruter som bare løses i nettleseren, gir Googles veiledning to strategier: en JavaScript-viderekobling til en URL der serveren svarer med 404 (for eksempel /not-found), eller å legge til <meta name="robots" content="noindex"> på feilsider med JavaScript.

#Canonical, noindex og lenker satt med JavaScript

Den samme veiledningen fra Google setter tre regler som headless-bygg lett bryter.

• Canonical. Hvis canonical settes med JavaScript, må den alltid ha samme verdi som i den opprinnelige HTML-en; motstridende eller flere rel="canonical"-tagger kan gi uventede resultater. I headless skjer dette når HTML-en fra serveren har canonical fra WordPress-originen og en klientkomponent skriver den om til frontendens URL.
• Noindex. Når Google møter noindex, kan den hoppe over gjengivelse og kjøring av JavaScript. En frontend som sender noindex i den første HTML-en mens data lastes, og fjerner den senere med JavaScript, holder siden utenfor indeksen. Skal siden indekseres, kan ikke den opprinnelige koden inneholde noindex.
• Lenker. Google finner bare lenker som er <a>-elementer med href-attributt, og veiledningen ber deg ikke bruke fragmenter til å laste ulikt innhold, men History API. En meny som navigerer med onClick-håndterere eller ruter som #/innlegg, etterlater den interne strukturen WordPress hadde, ugjennomsøkt.

#Slik henter du URL-oversikten fra WordPress REST API

Den første regelen i denne artikkelen er å eksportere alle publiserte URL-er før du rører frontenden. REST API gjør det uten utvidelser. Ifølge håndboken for paginering i REST API returnerer samlingsendepunkter et begrenset antall elementer per forespørsel; per_page tar et heltall fra 1 til 100, og page angir hvilken resultatside som returneres. Hvert svar har headeren X-WP-Total med totalt antall poster og X-WP-TotalPages med totalt antall sider. Les X-WP-TotalPages i den første forespørselen til /wp-json/wp/v2/posts?per_page=100 og gå gjennom resten av sidene.

To felt fra innleggsreferansen betyr noe for hvert innlegg: link, innleggets URL slik WordPress publiserer den, og modified_gmt, datoen for siste endring i GMT. Det første er listen hver rute i den nye frontenden sammenlignes med; det andre fyller lastmod i nettstedskartet. Argumentet modified_after begrenser svaret til innlegg endret etter en ISO 8601-dato, noe som gir inkrementelle bygg uten å laste ned alt innhold hver gang. Det samme pagineringsmønsteret fungerer for /wp/v2/pages og taksonomiendepunktene.

#URL-oppslag, forhåndsvisninger og hurtigbuffer med WPGraphQL

WPGraphQL er en gratis utvidelse med åpen kildekode som gir WordPress et utvidbart GraphQL-skjema og -API. Dokumentasjonen viser hvordan du henter et innlegg med URI-en, altså stien til innlegget, som identifikator. For SEO betyr det at den offentlige ruten og innholdet kommer fra samme kilde: frontenden ber om noden med stien den mottar, og trenger ingen egen tabell som oversetter ruter til ID-er.

Forhåndsvisninger krever mer omtanke. Ifølge dokumentasjonen for forhåndsvisninger kan WPGraphQL returnere den upubliserte versjonen av et innlegg, men forespørselen må være autentisert med en metode WordPress gjenkjenner. Er den ikke det, returnerer WPGraphQL den publiserte noden som om ingen forhåndsvisning var bedt om, uten feil. En forhåndsvisningsrute med ødelagt autentisering viser altså det publiserte innholdet i det stille. Derfor har forhåndsvisningsruter noindex, holdes utenfor nettstedskartet og går utenom den offentlige hurtigbufferen, og feltet isPreview bekrefter at forhåndsvisningen faktisk ble brukt.

Hurtigbufferen avgjør hvor lang tid endringer i tittel, beskrivelse eller canonical gjort i WordPress bruker på å nå HTML-en. Ytelsesdokumentasjonen sier at WPGraphQL støtter GET-forespørsler, som et CDN eller en proxy kan bufre, og at utvidelsen WPGraphQL Smart Cache merker svar med headeren X-GraphQL-Keys og sender ut en hendelse med de berørte taggene når innhold endres, slik at verten bare tømmer de dokumentene. Med den invalideringen når en redaksjonell endring i SEO-metadata frontenden uten å vente på at bufferen utløper.

#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.