Lesanlegar dagsetningar
Tilgreindu hvenær hver mikilvæg síða var birt og hvenær henni var síðast breytt, á formi sem vélar geta túlkað – ekki bara sem dagsetningu sem birtist í textanum. Leitarvélar og AI-aðstoðarmenn leggja mikla áherslu á nýnæmi þegar þeir ákveða hvað eigi að raða ofar og hvað eigi að vitna í, og síða sem ekki er hægt að dagsetja er síða sem ekki er hægt að treysta sem núverandi.
Dagsetning sem aðeins er sýnileg gerir þetta ekki. „05/06/26“ í eftirbyline er óljóst fyrir vél á þrjá vegu: maí eða júní, birt eða uppfært, og hvaða ársform er notað. Dagsetningin þarf að vera tilgreind í lýsigögnum á ótvíræðu sniði og sýnilega dagsetningin ætti að samræmast henni.
Hvers vegna þetta virkar
Þegar svaravél velur á milli tveggja síðna sem setja fram sömu fullyrðingu er „hversu nýlegt er þetta?“ hluti af matinu. Síða sem tilgreinir dagsetningar svarar spurningunni; síða sem tilgreinir ekkert tapar fyrir dagsettu efni, jafnvel þótt það sé betur skrifað. Þetta kostar þig tilvitnanir og sæti í leitarniðurstöðum í hljóði – engin villa, engin viðvörun, bara síður annarra valdar í stað þinnar.
Tilgreindar dagsetningar vinna einnig saman við allt annað sem þú birtir. Samanburðarefni, tölfræði, verðupplýsingar og fullyrðingar um vörur – allt þetta er auðveldara að vitna í þegar aðstoðarmaður sér að það var nýlega uppfært, og vekur meiri tortryggni þegar það gæti verið frá hvaða ári sem er.
Hvernig á að gera þetta
Tilgreindu dagsetningar á einu af þessum formum, í röð eftir styrkleika. Þú þarft aðeins eitt form, en þau geta verið saman og samræmst.
1. Skipulögð gögn (sterkasta formið)
Bættu datePublished og dateModified við síðunnar – yfirleitt Article eða BlogPosting í . Þetta er það form sem svaravélar sækja áreiðanlegast:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to reconcile corporate card statements",
"datePublished": "2026-05-01T09:00:00Z",
"dateModified": "2026-07-10T14:30:00Z"
}
</script>
Notaðu fullar ISO 8601-tímastimplanir með tímabelti. Ef síðan hefur aldrei verið uppfærð er dateModified sama og datePublished.
2. Lýsigagnamerki fyrir dagsetningar
Ef þú getur ekki sent skipulögð gögn bera hefðbundin lýsigagnamerki sömu upplýsingar:
<meta property="article:published_time" content="2026-05-01T09:00:00Z">
<meta property="article:modified_time" content="2026-07-10T14:30:00Z">
3. Sýnileg dagsetning sem vélar geta einnig lesið
<time>-einingin gerir dagsetningu sem er sýnileg fólki lesanlega fyrir vélar í einu skrefi:
Last updated <time datetime="2026-07-10">July 10, 2026</time>
Þetta virkar aðeins sem merki um dagsetningu þegar síðan inniheldur eina ótvíræða dagsetningu – síða með mörgum <time>-einingum (viðburðaskráningum eða athugasemdakerfum) segir vél ekkert um sjálfa síðuna. Notaðu þetta helst með skipulögðum gögnum, ekki í stað þeirra.
Alls staðar, ekki handvirkt
Ekki gera þetta síðu fyrir síðu. Flest -kerfi og SEO-viðbætur geta sent datePublished og dateModified sjálfkrafa út frá ritstjórnarlegum dagsetningum sem þau geyma nú þegar – virkjaðu það og þá nær það yfir alla síðuna, þar á meðal allar síður sem þú birtir á næsta ári. Ef þú býrð til eigin sniðmát skaltu tengja dagsetningarnar við greinasniðmátið einu sinni.
Á meðan þú ert að þessu skaltu tengja <lastmod>-gildi XML-vefsíðukortsins við sömu ritstjórnarlegu dagsetningar. Vefsíðukort dagsetja ekki síður í þeim tilgangi að hægt sé að vitna í þær, en vefskriðlar nota <lastmod> til að ákveða hvað skuli heimsótt aftur. Ný síða verður því skriðin aftur – og nýja dagsetningin tekin eftir – fyrr.
Hafðu dagsetningarnar réttar
dateModified verður að þýða að efnið hafi raunverulega breyst. Svaravélar bera tilgreindar dagsetningar saman við efnið, skjalasöfn og eigin feril vefskriðs:
- Ekki uppfæra dagsetninguna við hverja endurbirtingu eða sniðmátsbreytingu. Síða þar sem
dateModifieduppfærist vikulega á meðan textinn breytist aldrei lítur út fyrir að vera tilraun til blekkingar og þá hættir fólk að trúa dagsetningunni. - Ekki setja dagsetningu aftur í tímann eða fram í tímann. Tilgreind dagsetning eftir vefskrið eða áður en vefurinn var til verður hunsuð.
- Láttu sýnilegu dagsetninguna passa við þá tilgreindu. Eftirbyline sem segir 2023 undir lýsigögnum sem segja þetta ár er mótsögn, og mótsagnir eru leystar þér í óhag.
Hinum megin málsins er þetta: þegar þú uppfærir síðu í raun – með nýrri tölfræði, uppfærðu verði eða leiðréttum fullyrðingum – skaltu uppfæra dateModified í sömu breytingu. Heiðarleg uppfærsla sem þú tilgreinir aldrei er tilvitnun sem þú færð aldrei.
Það sem virkar ekki
- Dagsetning aðeins í sýnilegum texta. Óljóst fyrir vélar, eins og lýst er hér að ofan.
- HTTP-hausinn . Hann lýsir svarinu frá netþjóninum, ekki efninu. Á síðum sem eru búnar til á virkan hátt breytist hann við hverja beiðni, sem er einmitt ástæðan fyrir því að neytendur treysta honum ekki. Það er í lagi að senda hann, en hann má aldrei vera eina merkið.
- Dagsetningar aðeins í vefslóðinni (
/blog/2024/06/...). Veikt vísbending um birtingardag, segir ekkert um uppfærslur og festir síðuna í fortíðinni: vefslóðin segir enn 2024 eftir uppfærslu þína árið 2026.
Hvernig Silktide hjálpar
Silktide les dagsetningarnar sem síðurnar þínar tilgreina – fyrst skipulögð gögn, síðan lýsigagnamerki fyrir dagsetningar og loks ein ótvíræð <time datetime>-eining – og notar þær í skýrslugjöf sinni:
- Content dates-prófunin flaggar mikilvægum, skráningarhæfum síðum sem tilgreina alls enga birtingar- eða uppfærsludagsetningu.
- Velocity-skjár Presence sýnir birtingartíðni út frá þessum sömu tilgreindu dagsetningum, þannig að ódagsettar síður draga úr nákvæmni hans.
Ef Silktide getur ekki dagsett síðurnar þínar geta vélarnar sem þú vilt að vitni í þig það ekki heldur – prófunin er bein forskoðun á því hvernig vefurinn þinn birtist þeim.
Tengt efni
- Content dates – Silktide-prófunin sem flaggar ódagsettum síðum
- Structured data markup – ítarleg tækni sem þetta sterkasta form tilheyrir
- Comparison pages – efni seint í kaupferlinu þar sem úrelt eða vantar dagsetningu kostar mest
- – hvers vegna svaravélar eru markhópurinn fyrir þessi merki