Sitemap og canonical i headless WordPress: én kilde til sannhet, levert fra frontenden
Oppføring i sitemap er et svakt canonical-signal; videresending og rel=canonical er sterkere. Relatert implementeringskontekst: SEO-mønstrene for headless WordPress, ryker i det stille.
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 sitemap fra et komplett inventar av offentlige ruter og skriv én canonical i HTML-head. Inventaret kan komme fra frontenden eller en riktig konfigurert backend. Flere konsistente underfiler er gyldige.
Hvorfor ender headless WordPress-nettsteder opp med to sitemaps
WordPress har hatt kjernesitemaps siden versjon 5.5. Tilgjengeligheten avhenger av innstillinger og filtre, og SEO-utvidelser kan deaktivere kjernens generator. Kontroller faktiske endepunkter; tre samtidige generatorer er ikke uunngåelig.
/wp-sitemap.xmlfra WordPress-kjernen./sitemap_index.xmlfra Yoast eller Rank Math./sitemap.xmlfra frontend-rammeverket.
Flere sitemaps kan eksistere korrekt samtidig. Motstridende offentlige URL-inventarer må rettes, men Google velger ikke indekserte sider bare ut fra hvilken sitemap som leses først.
Alle aktive sitemap-endepunkter bør bruke et konsistent inventar av offentlige ruter. Deaktiver unødvendig origin-generator eller videresend XML-endepunktet når det passer. Flere underfiler kan svare 200 som del av en sitemap-indeks.
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.
Skriv canonical i opprinnelig HTML-head gjennom layout eller rammeverkets metadata-API. Google støtter canonical laget med JavaScript, men anbefaler tydelige signaler uten senere endringer. Opprinnelig HTML gjør også release-testene reproducerbare.
Tilpass SEO-metadata til det offentlige rutekartet. Yoast har et dokumentert REST API; andre utvidelser trenger sin egen støttede integrasjon. Canonical i svaret bruker ikke automatisk den offentlige headless-adressen.
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
Filtre trenger en uttrykkelig indekseringspolicy. Bruk canonical for reelle duplikater og noindex ved planlagt utelatelse. Ikke bruk begge ukritisk på alle filtre.
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.
Avklar offentlige adresser før metadata hentes
WordPress lagrer innleggs-ID og sine egne permalenker. En headless-frontend kan bruke andre språkprefikser, kategoristier og regler for avsluttende skråstrek. Definer derfor først hvordan innleggs-ID og språk blir til en offentlig URL. Denne mappingen er konfigurasjon i applikasjonen. Det holder ikke å bytte vertsnavn hvis stien også endres. En side under en overordnet WordPress-side kan få en flat rute, mens et produkt kan bruke en oversatt kategoridel.
Bruk samme resolver for interne lenker, sitemap, canonical, hreflang og identifikatorer i strukturerte data. Dette er et arkitekturvalg som hindrer at separate funksjoner lager forskjellige adresser til samme innhold. Behold redaksjonelle canonical-unntak som eksplisitte valg. En syndikert artikkel kan med vilje peke til partnerens nettsted. Automatisk erstatning av alle vertsnavn vil endre betydningen av dette valget. Valider eksterne mål separat fra vanlige egne adresser, og avvis utviklingsdomener og preview-verter før HTML publiseres.
Yoasts REST API leverer SEO-data knyttet til WordPress-adresser. Henting av disse dataene tilpasser dem ikke automatisk til frontendens rutekart. Velg om applikasjonen bygger head fra strukturerte felt eller bruker kontrollert HTML fra integrasjonen. Unngå å skrive ut hele pluginens SEO-head og deretter en ekstra canonical fra layouten. Kontroller sluttresponsen, fordi et riktig dataobjekt fortsatt kan bli rendret to ganger av forskjellige komponenter.
Hent et komplett innholdssnapshot
Generatoren må hente alle nødvendige sider fra API-et. Første svar fra en innleggssamling er ikke hele publiseringslisten. Taksonomier trenger et eget inventar når frontenden faktisk har nyttige arkivsider. Logg antallet innleste poster og sammenlign med forrige vellykkede bygg. Hvis origin slutter å svare midt i pagineringen, stopp publiseringen eller behold det forrige komplette artefaktet. En forkortet sitemap som presenteres som vellykket resultat, skjuler en integrasjonsfeil.
Inventaret skal bare inneholde offentlige ruter som finnes. Et publisert vedlegg, en forfatter eller et begrep i WordPress oppretter ikke automatisk en headless-side. Ta med adressen etter at mal og indekseringspolicy er bestemt. Utelat utkast, innloggede områder, interne søkeresultater, kilder til videresending og bevisst noindex. Lagre årsaken når en post utelates. Redaktøren må kunne skille en planlagt avgrensning fra innhold som forsvant under API-hentingen.
Googles sitemap-dokumentasjon setter en grense på 50 000 URL-er eller 50 MB ukomprimert per fil. Del større inventarer og publiser dem gjennom en sitemap-indeks. Flere underfiler er normal organisering og kan gjøre det enklere å analysere forskjellige samlinger. Bruk komplette offentlige adresser og korrekt XML-koding. Et uescapet ampersand i loc kan ødelegge XML selv om nettleseren åpner den tilsvarende adressen.
Lastmod bør komme fra en relevant endring i innhold eller metadata når et pålitelig tidspunkt finnes. Byggetidspunktet er tidspunktet for publisering av artefaktet, ikke dokumentasjon på at alle artikler er endret. Å skrive om hver lastmod ved hver deploy fjerner verdien av feltet. Avklar om en teknisk oppdatering fra en importjobb faktisk endret det leseren ser. Bruk samme vurdering i sitemap og artikkelmetadata, slik at de ikke oppgir forskjellige historier om oppdateringen.
Skill sletting fra canonical og crawl-styring
Canonical angir den foretrukne adressen i en gruppe like eller svært lignende sider. Den videresender ikke brukeren og garanterer ikke at Google velger målet. En permanent videresending passer når en tidligere offentlig adresse er erstattet av tilsvarende innhold. En reell sletting uten erstatning kan returnere 404 eller 410. Å sende alle slettede artikler til forsiden gjør det vanskeligere å se hvilket innhold migreringen faktisk fjernet.
Bruk noindex når en offentlig tilgjengelig side skal ut av søkeresultatene. Google må kunne hente siden for å lese instruksen, slik noindex-dokumentasjonen forklarer. Blokkering av samme adresse i robots.txt kan hindre dette. Disallow styrer crawling og erstatter ikke tilgangskontroll. Beskytt privat administrasjon og forhåndsvisninger med autentisering. Instrukser til søkemotorer hindrer ikke en bruker i å lese ubeskyttede data.
Hvis origin tidligere leverte offentlige artikler, velg videresendinger til tilsvarende frontend-adresser eller en tydelig canonical-policy for sider som fortsatt er tilgjengelige. Videresending av sitemap-filen alene flytter ikke artiklene som stod i den. Kontroller gamle adresser og interne lenker. Hvis WordPress bare skal levere innholds-API, begrens unødvendige offentlige maler uten å stenge API-endepunktene applikasjonen trenger.
Behandle paginering og språk som egne ruter
Hver nyttig arkivside har forskjellig innhold og normalt sin egen selvrefererende canonical. Google bruker ikke lenger rel=prev og rel=next til å identifisere paginering, ifølge pagineringens dokumentasjon. Gi crawlbare HTML-lenker til senere sider. En knapp som bare legger til resultater gjennom JavaScript, gir ikke crawleren samme oppdagelsesvei. Test siste gyldige side og adresser utenfor området, slik at tomme lister ikke svarer 200 uten noen grense.
Språkkartet må oppdateres sammen med publiseringene. En norsk artikkel skal ikke ha canonical til den engelske bare fordi engelsk var kildeteksten. Hreflang gjelder faktisk publiserte motstykker. Hvert språk må bruke den kanoniske offentlige adressen til sin egen artikkel. Når en oversettelse fjernes, oppdater både søskensidene og språkets sitemap. Den norske forsiden er ikke et tilsvarende alternativ til en fjernet teknisk veiledning.
Filtre krever en avgjørelse for det aktuelle produktet. En permanent kategoriside med egen tekst og et nyttig utvalg kan være selvstendig indekserbar. En annen sortering av samme liste kan peke til hovedvisningen. Interne søkeresultater kan utelates. Samme kombinasjon av canonical og noindex på alle parametere visker ut disse forskjellene. Dokumenter tillatte parametere, normalisering og indekseringshensikt før katalogrouteren får nye filtermuligheter.
Kontroller både artefakt og produksjonsrespons
Et rutemanifest bør inneholde forespurt adresse, forventet status, canonical-mål og indekserbarhet. Sammenlign det med generert XML og HTML. For hver sitemap-adresse kontrollerer du at siden finnes, er nyttig, mangler noindex og oppgir forventet canonical. For fjernede ruter kontrollerer du videresending eller slettestatus. Ta med norske bokstaver, kodede stier og underordnede sider i utvalget. En test bare mot forsiden avdekker ikke feil i slug-mappingen.
Gjenta kontrollene på produksjonsdomenet etter deploy. Preview kan være riktig mens CDN-et skriver om skråstreker, leverer gammel HTML eller legger til en uventet X-Robots-Tag. Sammenlign HTTP-headere og opprinnelig dokument. Endrer klientskript metadata, kontroller også rendret resultat. Lagre release-ID i driftsrapporten slik at SEO-gjennomgangen kan skille nye filer fra mellomlagrede svar fra en tidligere publisering.
Search Console viser canonical oppgitt av nettstedet og etter indeksering også Googles valgte canonical. Et avvik krever undersøkelse av duplikater, videresendingskjeder, intern lenking og tilgjengeligheten til målet. Det beviser ikke at to XML-filer konkurrerte. Start med den konkrete URL-en og dens varianter. Etter korrigering av signalene må Google få tid til å hente sidene på nytt. En vellykket deploy oppdaterer ikke søkemotorens lagrede tolkning umiddelbart.
Ved migrering av en norsk katalog bør gamle slugs med æ, ø og å få en egen kontroll. Adresser fra eldre importjobber kan ha en annen koding enn dagens router. Sammenlign dem med samme normalisering som applikasjonen bruker. Behold forrige manifest, slik at neste innholdsimport ikke endrer omfanget av offentlige sider uten at noen oppdager det.
Avhengigheter når en slug endres
En slug-endring påvirker mer enn den enkelte artikkelen. Oppdater lenker i kategoriarkiv, anbefalte innlegg og språkversjoner. Hvis sitemap og HTML bygges uavhengig, må webhooken utløse begge oppgavene eller publisere dem fra samme snapshot. Ellers kan XML peke til en ny rute som frontenden ennå ikke leverer. Det er en publiseringsrekkefølge som kan testes før søkemotoren møter feilen.
Lagre gammel og ny adresse i oppdateringshendelsen. Innleggs-ID gjør det mulig å finne den nye artikkelen, men gjenskaper ikke nødvendigvis den gamle adressen etter at posten er overskrevet. Køen må tåle gjentatte leveranser og nye forsøk. Videresendingen skal ende på riktig mål også når redaktøren endrer slug igjen før forrige bygg er ferdig.
Etter publisering henter du den gamle adressen uten automatisk å følge videresendingen. Kontroller status og Location-header, og test deretter målsiden separat. Bekreft at den nye adressen finnes i sitemap og oppgir riktig canonical. Dette skiller en riktig flytting fra et utilsiktet 200-svar fra applikasjonens feilside. Behold hendelsesloggen sammen med release-ID slik at et senere avvik kan knyttes til den publiseringen som endret adressen.
