Et sitemap er en liste over sider, du fortæller Google er værd at indeksere. De fleste af de sitemaps vi scanner, indeholder URL’er der viderestiller, ikke længere findes eller bærer et tag der beder Google om ikke at indeksere dem.

Sitemaps går i stykker på en bestemt måde: tavst, og altid i samme retning. Sider bliver slettet, omdøbt, lagt sammen med andre eller sat til noindex under en oprydning, og sitemappet bliver ved med at liste dem. Intet fejler. Ingen opdager det, for ingen læser et sitemap for fornøjelsens skyld.

Hvad bruger man et XML-sitemap til?

Et XML-sitemap er en fil der lister de URL’er på dit website, du gerne vil have søgemaskiner til at hente og indeksere. Den får ikke sider til at rangere bedre, og søgemaskiner kan godt finde sider uden den. Det den gør, er at gøre nye sider hurtigere at opdage og give søgemaskinen en klar melding om hvilke URL’er du betragter som de rigtige — hvilket betyder mest på store websites og på websites med få interne links.

Den ramme er værd at holde fast i, for den sætter den standard filen skal leve op til. Et sitemap er en påstand: det her er mine rigtige sider, og de er din tid værd. Hele værdien kommer af, at påstanden er sand. Et sitemap der er halvt forkert, er ikke halvt så nyttigt — det er en kilde, søgemaskinen har lært at vægte lavere.

Hvorfor betyder det noget at der er døde URL’er i mit sitemap?

Fordi et sitemap er en hensigtserklæring, og at modsige den spilder præcis det crawl-budget du forsøgte at styre. Hver URL der viderestiller, giver 404 eller er markeret noindex, er en side du bad søgemaskinen hente og derefter bad den se bort fra. På et lille website er spildet ubetydeligt; på et stort betyder det, at de sider du faktisk går op i, bliver hentet sjældnere.

Tre modsigelser går igen, og de har hver sin årsag:

  • Listet, men kan ikke nås. URL’en giver 404, timer ud eller fejler. Siden blev slettet eller omdøbt, og sitemappet blev ikke genereret igen — eller det blev, ud fra en forældet cache.
  • Listet, men sat til noindex. Den mest selvmodsigende af de tre. Sitemappet beder om indeksering; sidens eget tag afviser den. Som regel resultatet af en noindex tilføjet af en god grund, på en side ingen fik fjernet fra listen.
  • Listet, men aldrig hentet. Linjen er der, og siden fejler ikke, men søgemaskinen har ikke hentet den. Ofte et tegn på at URL’en er blokeret i robots.txt, ikke er linket til internt, eller ligger i et sitemap søgemaskinen er holdt op med at stole på.

TrustCtrl rapporterer hver af dem for sig, med URL’en og det faktiske svar, fordi løsningen er forskellig: den første er et genereringsproblem, den anden en beslutning ingen gjorde færdig, den tredje handler som regel om adgang og slet ikke om sitemappet.

Hvor ofte skal et sitemap opdateres?

Det bør opdatere sig selv, hver gang sider tilføjes, fjernes eller flyttes — de fleste CMS’er gør det, og et sitemap der vedligeholdes i hånden, skrider inden for få uger. Datoen i lastmod bør afspejle hvornår sidens indhold reelt blev ændret, for søgemaskiner bruger den som et signal om friskhed, og en fil hvor hver eneste linje påstår at være ændret i dag, er et signal de lærer at se bort fra.

Det sidste fortjener en understregning, for fristelsen trækker den anden vej. At sætte lastmod til dags dato på hver side ligner et gratis friskhedsboost. Det er det modsatte: en fil hvor intet skiller sig ud, bærer ingen information, og et mønster af kunstig friskhed er præcis det søgemaskiner vægter ned. Ærlige datoer er mere brugbare end smigrende.

Hvad er forskellen på et sitemap og robots.txt?

Et sitemap siger hvilke sider du gerne vil have hentet; robots.txt siger hvilke stier en crawler overhovedet må hente. De kan modsige hinanden, og gør de det, vinder spærringen — at liste en URL i sitemappet som robots.txt blokerer, opnår intet ud over en advarsel i Search Console. Robots.txt er samtidig dér, du bør henvise til sitemappet med en Sitemap-linje.

Og når du alligevel er inde i robots.txt for den linje, er det værd at læse resten af filen ordentligt. Den samme fil afgør, om AI-assistenter overhovedet kan hente dine sider, og reglerne matches pr. crawler — det er sådan et website ender med at være perfekt synligt i Google og fraværende i alle AI-svar. Det er emnet for blokerer du AI-crawlerne.

Hvad Search Console lægger oveni

Google Search Console viser de sitemaps den kender, hvornår hvert af dem sidst blev læst, og hvilke fejl den fandt. Tre tilstande er værd at holde øje med, og ingen af dem melder sig selv: et sitemap Google aldrig har kunnet læse, et den ikke har læst i lang tid, og et den læste med fejl.

Forbinder du Search Console til TrustCtrl, rapporteres de tilstande sammen med det vores egen crawler finder inde i selve filen. Kombinationen er det der gør billedet helt: vores crawler ved, om hver listet URL faktisk kan nås og indekseres, og Search Console ved, om Google overhovedet læser filen. Hver halvdel for sig efterlader et oplagt spørgsmål ubesvaret.

Et tjek på ti minutter

Åbn dit sitemap — som regel på /sitemap.xml, og nævnt i robots.txt hvis det ligger et andet sted. Vælg ti URL’er tilfældigt og åbn dem. Tæl hvor mange der viderestiller, giver 404 eller bærer et noindex-tag. Er svaret mere end nul, er filen begyndt at skride, og de ti du tjekkede, er en stikprøve af et større tal.

Sørg derefter for at tjekket gentager sig, for det her er et vedligeholdelsesproblem og ikke en engangsrettelse. TrustCtrl tjekker URL’erne i dit sitemap ved hver crawl og rapporterer dem der ikke kan nås, er spærret for indeksering eller aldrig er blevet hentet, sammen med titler og beskrivelser, indhold crawlere ikke kan se, hastighed, tilgængelighed og sikkerhedsindstillinger. Én liste, på almindeligt dansk, med den tekniske detalje til den der genererer filen.