XML-sitemap: fem feil vi fant i vår egen

Joost de Valk publiserte 27. september 2026 en tekst om at nesten ingen får XML-sitemaper riktig. Med utvidelsen Sitemap Inspector gikk han gjennom seks nettsteder, fra Adobe til GOV.UK, og fant det samme overalt: adresser med noindex, omdirigeringer, 404, kanoniske adresser som peker et annet sted, én dato for hundrevis av oppføringer. Tesen hans lyder: «A sitemap should list the URLs a site wants indexed, and nothing else.»

Vi er enige i både tesen og listen, og brukte den på vårt eget nettsted. Mellom august og oktober 2026 fant vi fem feil i sitemap-generatoren til wppoland.com, hver av dem målt i produksjon. Tre av dem ville listen til Joost ha fanget. To vil ingen inspektør som leser sitemap-oppføringene fange, fordi feilen lå i det som ikke var der. Denne teksten handler om begge typene.

Teknisk bakgrunn: wppoland.com er et Astro-nettsted på seks språk, med rundt 6700 adresser i sitemapene. Sitemapene genereres av en egen integrasjon, astro-sitemaps.mjs, ikke av en utvidelse. Det har betydning for konklusjonene: hver av feilene nedenfor satt i koden som leser data og bygger listen, ikke i selve listen.

#Feil 1: byggdato som lastmod

24. august 2026 hadde fem ulike sitemaper nøyaktig én lastmod-verdi for alle oppføringer, den samme, dagens dato. Integrasjonen regnet ut new Date() én gang og stemplet 3079 adresser med den. Hver utrulling fortalte Google at alt var endret.

Google beskriver betingelsen direkte: <lastmod> brukes hvis verdien «consistently and verifiably» stemmer med siste endring på siden (Google Search Central, siden om å bygge sitemaper, oppdatert 8. juli 2026). En dato som hopper ved hver build oppfyller ikke den betingelsen, så Google slutter å stole på den for hele domenet, også der den ville vært riktig. I stikkprøver fra den perioden lå siste crawl for enkelte sider fra tre uker til tre måneder tilbake.

Rettelsen satte inn updatedDate fra frontmatter, med pubDate som reserve. Effekten i artefaktet: den polske bloggsitemapen gikk fra 1 til 98 ulike datoer.

Ved denne rettelsen er det lett å gjøre en feil av andre grad. Det var fristende å bruke feltet lastVerified for bysidene, siden hver av de 4733 filene har det. Men 4697 av 4733 filer har samme verdi i det. Det er et massestempel, ikke et signal, og det ville bare flyttet samme defekt fra «i dag» til en annen fast dato. Før et datofelt havner i lastmod, må du telle hvor mange ulike verdier det har.

Rettelsen fra august omfattet bloggen, porteføljen og sidene fra innholdssamlingene. Den omfattet ikke håndskrevne .astro-ruter. Artikkelen til Joost fikk oss til å sjekke på nytt: 29. september hadde 62 av 113 adresser i /pl/sitemap-pages.xml fortsatt byggdatoen som lastmod, fordi det ikke finnes noen innholdsdato for dem, og koden falt da tilbake på today. Rettelsen (commit af97c7a887) henter for slike ruter datoen for siste commit av kildefilen fra ett enkelt git log-kall per build, og når heller den mangler, utelates lastmod. Den felles malen [lang]/[slug].astro regnes bevisst ikke som kilde, fordi datoen dens ikke sier noe om noen bestemt side. Samme fil etter rettelsen: 87 av 113 adresser har lastmod, 42 ulike datoer, den vanligste gjelder 7 adresser, og 26 adresser har ingen dato i det hele tatt. I den polske sitemapen for bysider hadde 684 av 692 oppføringer byggdatoen før rettelsen, etter den har 8 oppføringer en ekte dato: bymalen har ingen dato som kan brukes ærlig, så resten oppgir ingen dato. Rettelsen har vært i produksjon siden 29. september 2026, og den levende filen viser de samme tallene.

#Feil 2: noindex-filteret passet på ett felt

Etter at 723 bysider ble satt til noindex, fortsatte Search Console å melde dem som oppdaget. Sidene selv hadde korrekt noindex. De kom tilbake til Google en annen vei: sitemap-locations.xml listet dem som språkalternativer (xhtml:link, også x-default) til sider som ble værende i indeksen.

Noindex-filteret i integrasjonen sjekket bare <loc>. Alternativene kommer fra sidens head, som lister alle språkversjoner, så filteret så dem ikke. Rettelsen beholder bare alternativer der adressen selv er en <loc> i sitemapen. Etter den ga builden 6407 adresser og 0 feilaktige alternativer.

Lærdommen gjelder mer enn sitemaper: et filter på ett felt i en oppføring dekker ikke de andre feltene i samme oppføring som bærer en adresse. I en sitemap finnes det flere slike steder: loc, alternativer, x-default, image:loc.

#Feil 3: 500 fungerende sider utenfor sitemapen

21. september 2026 begynte integrasjonen å utelate alle adresser som passet med prefiksene som middleware i functions/_middleware.ts omdirigerer. Men middleware omdirigerer dem bare når ressursen returnerer 404, og hver sitemap-kandidat er en bygget side, så den returnerer aldri 404. Filteret kopierte regelen uten betingelsen.

Resultat: 500 fungerende sider med index, follow falt ut av sitemapen, inkludert målet for en av omdirigeringene (/pl/audyt-bezpieczenstwa-wordpress/ passet med prefikset audyt-bezpieczenstwa-). Rettelsen kom inn 26. september, og builden med sitemap ga +500 adresser og 0 fjernet.

Denne feilen fanger ingen kontroll av oppføringer. Hver av de gjenværende adressene var korrekt: den ble rendret, hadde ikke noindex og omdirigerte ikke. Færre adresser i sitemapen ser ut som opprydding, ikke som en defekt. Den kan bare oppdages ved å sammenligne adressemengden før og etter endringen.

#Feil 4: >- som bildeadresse

Integrasjonen hentet heroImage fra frontmatter med et regulært uttrykk, linje for linje. Ved en foldet YAML-blokk (heroImage: >-) står verdien på neste linje, så regexet fanget den bokstavelige strengen >-. Sitemapen fikk oppføringer som <image:loc>https://wppoland.com/>-</image:loc>.

17. september 2026 var det 31 slike oppføringer i produksjon, fordelt på seks språk. Search Console viste fem feil for pl/sitemap-blog.xml, mens selve XML-en var korrekt bygget og hver <loc> var i orden. YAML-en i filene var også korrekt. Det var leseren som var ødelagt.

Rettelsen parser frontmatter med en YAML-parser, og funksjonen som henter ut metadata ble eksportert fra integrasjonen slik at en test kan nå den uten full build. Før satt den midt i en fil på 900 linjer, og ingen test hadde tilgang til den.

#Feil 5: IndexNow sendte adresser som ikke finnes

Skriptet for IndexNow bygde adresser fra filnavn i src/content/. 17. september 2026 genererte det 2328 adresser, og 0 av dem fantes i sitemapen. Blogginnlegg fikk et /blog/-segment som ikke finnes i adressene, og sider beholdt språksuffikset fra filnavnet (/de/about.de/). Begge variantene returnerte 301. I tillegg fanget filmønsteret bare .md, så 100 tjenestepilarer i .mdx ble aldri sendt.

Rettelsen er én setning: kilden til adresser for IndexNow er sitemap-index.xml. Den mengden er allerede kontrollert: sidene rendres og har ikke noindex. Heuristikken basert på filnavn forsvant, og tre feilklasser med den.

#Feil uten feil: Google hentet ikke sitemapen

Dette tilfellet var ikke en defekt i generatoren, men det hører til samme familie. I begynnelsen av september 2026, etter at bysidene ble åpnet for indeksering, hadde seks lokasjonssitemaper 4071 adresser. Alt på vår side var korrekt: stikkprøver returnerte 200 og index, follow, og ingen adresse i sitemapen var noindex eller en omdirigering.

Search Console hentet disse sitemapene sist 1. september kl. 10:08, da de hadde 2037 adresser, og oppdaterte dem ikke på fem dager. Bloggsitemapene leste den hver dag. Alt som ble lagt til etter det tidspunktet, fantes ikke for Google. En ny innsending via API-et ble hentet samme dag.

Uken etter økte antallet bysider med visninger fra 223 til 343, og visningene deres fra 1570 til 4382. Disse 343 sidene er 8,4 prosent av 4071, og på sju dager ga de 2 klikk. Det som ble låst opp, var oppdagelse, ikke trafikk, og det er to ulike tall.

#Det en oppføringsinspektør ikke ser

En utvidelse som den Joost brukte, svarer på spørsmålet «er det som står i sitemapen, korrekt». Det er et godt spørsmål, og som han viste, svarer de fleste nettsteder ikke på det. Men tre av våre seks tilfeller handlet om noe annet: hva som mangler i sitemapen, hva som bruker den, og hvilken versjon Google ser.

#Sjekkliste for sitemap-generatoren

Kontroll av oppføringene er en nødvendig betingelse, ikke en tilstrekkelig en. Disse fem punktene sjekker generatoren, ikke bare filen:

1. Tell ulike lastmod-verdier i hver fil. Én verdi for hundrevis av oppføringer betyr et stempel, ikke en dato. Det samme gjelder før du tar i bruk et nytt datofelt: hvis nesten alle filer har samme verdi i det, egner ikke feltet seg som lastmod. Ingen lastmod er bedre enn en uriktig.
2. Sammenlign adressemengden før og etter en endring i generatoren. Antall lagt til og fjernet, med liste. Et fall i antall adresser krever en forklaring på samme måte som en økning.
3. Hvert felt som bærer en adresse, går gjennom de samme filtrene. loc, språkalternativer, x-default, image:loc. Et filter på ett av dem beskytter ikke de andre.
4. En regel kopiert fra en annen komponent følger med betingelsen sin. En omdirigering «ved 404» er ikke det samme som en omdirigering alltid.
5. Sitemapen er den eneste kilden til adresser for alt som sender adresser videre: IndexNow, Indexing API, lister for manuell innsending. Og én gang i uken: datoen for siste henting i Search Console og antallet adresser som vises der, ved siden av antallet <loc> i den levende filen.

To ting fra Googles dokumentasjon som er greie å ha for hånden: én sitemap-fil rommer maksimalt 50 000 adresser eller 50 MB ukomprimert, og verdiene <priority> og <changefreq> ignoreres. De skader ikke, men de er ikke verdt arbeidet.

Hvis nettstedet kjører som headless WordPress, kommer spørsmålet om hvem som i det hele tatt genererer sitemapen, frontenden eller WordPress. Det har vi beskrevet i en egen tekst om sitemap og kanonisk adresse i headless WordPress.