Rettet et sitemap der 172 av 176 URL‑er delte ett endringstidspunkt, ved å hente datoen fra git‑historikken etter å ha slått fast at eksporten skriver om hver fil ved hver kjøring.

Situasjon. Nettstedets sitemap fortalte søkemotorene at 172 av de 176 sidene var sist endret i det samme øyeblikket. Det er ikke en subtil unøyaktighet — en endringsdato er et løfte til en søkerobot om at innholdet på en side har endret seg, og et nettsted som gir det løftet 172 ganger samtidig, forteller enten sannheten om en fullstendig omskriving eller forteller ingen noe nyttig.

Oppgave. Datoene måtte beskrive innholdet og ikke filen, uten å finne opp en presisjon repoet ikke har.

Handling. Årsaken var at datoen kom fra filens endringstidspunkt, og innholdseksporten skriver om hver fil ved hver kjøring, så én enkelt synkronisering stemplet hele korpuset. Rettelsen flytter kilden til versjonshistorikken, med en reservekjede som først prøver et eksplisitt felt, så commit‑historikken, så filen. Fellen i den rettelsen er verdt å dokumentere: det bokstavelige feltnavnet må stå i listen, ellers leser generatoren det aldri, så en konfigurasjon som ser ut til å foretrekke en forfatterangitt dato, men utelater navnet, ignorerer i det stille hver forfatterangitte dato. To andre datobeslutninger kom ut av det samme arbeidet. Databasen lagrer nå når hver post ble skrevet og sist revidert, bevisst holdt atskilt fra når arbeidet fant sted — det er år mellom dem, og å blande dem sammen ville datere en side skrevet i år til for et tiår siden. Og radene i den filen er valgfrie, og ingenting utledes, fordi repoets egen historikk begynner etter at innholdet gjorde det: en manglende dato lar feltet stå tomt i stedet for å registrere en migrering, ut fra prinsippet om at et presist, feil tall er verre enn et fraværende, siden bare det feile blir trodd.

Resultat. En ny synkronisering etter en måned med innholdsendringer berører nå åtte filer av 186 i stedet for alle, og sitemapen sier noe sant. Den generelle regelen ble skrevet inn i metadatadokumentet ved siden av, fordi den samme fellen gjelder hvert felt som har en reservekjede.