Har rettet et sitemap med ét fælles tidsstempel

Situation. Sitets sitemap fortalte søgemaskinerne, at 172 af dets 176 sider sidst var ændret i samme øjeblik. Det er ikke en subtil unøjagtighed — en ændringsdato er et løfte til en crawler om, at en sides indhold er ændret, og et site, der giver det løfte 172 gange på én gang, fortæller enten sandheden om en fuld omskrivning eller fortæller ingen noget brugbart.

Opgave. Datoerne skulle beskrive indholdet og ikke filen, uden at opfinde en præcision, som repositoryet ikke har.

Handling. Årsagen var, at datoen kom fra filens ændringstidspunkt, og indholdseksporten skriver hver fil om ved hver kørsel, så en enkelt synkronisering stemplede hele korpusset. Rettelsen flytter kilden til versionshistorikken med en fallback‑kæde, der først prøver et eksplicit felt, så commit‑historikken og til sidst filen. Fælden i den rettelse er værd at notere: selve feltnavnet skal stå på listen, ellers læser generatoren det aldrig, så en konfiguration, der ser ud til at foretrække en angivet dato, men udelader navnet, ignorerer i stilhed alle angivne datoer. To andre beslutninger om datoer kom ud af det samme arbejde. Databasen registrerer nu, hvornår hver post blev skrevet og sidst revideret, bevidst holdt adskilt fra, hvornår arbejdet fandt sted — de ligger år fra hinanden, og at blande dem sammen ville datere en side, der er skrevet i år, til et årti siden. Og rækkerne i den fil er valgfrie, og intet udledes, for repositoryets egen historik begynder senere end indholdets: en manglende dato lader feltet stå tomt i stedet for at registrere en migrering, ud fra det princip, at et præcist forkert tal er værre end et manglende, eftersom det kun er det forkerte, der bliver troet.

Resultat. En ny synkronisering efter en måneds redigeringer af indholdet rører nu otte filer ud af 186 i stedet for dem alle, og sitemappet siger noget sandt. Den generelle regel kom ind i metadatadokumentet ved siden af, for den samme fælde gælder for hvert felt, der har en fallback‑kæde.