Canonical, Veröffentlichungs- und Änderungsdaten sowie Gegenwart und Vergangenheit korrekt darstellen

Adressen und Zeit beantworten unterschiedliche Fragen

„Wo ist das Original?“, „Wann wurde es veröffentlicht?“ und „Gilt es jetzt?“ sind verschiedene Fragen. canonical benennt die maßgebliche Adresse doppelter oder sehr ähnlicher Dokumente. Veröffentlichungs- und Änderungsdaten beschreiben die Dokumentgeschichte. Der Gültigkeitszeitraum erklärt, wann Gebühren, Zeitpläne oder Voraussetzungen im Inhalt gelten.

Wird der Zeitplan 2025 der fiktiven Bibliothek 2026 in ein neues CMS übernommen, lässt ein Veröffentlichungsdatum zum Migrationszeitpunkt und der Titel „Aktuelle Öffnungszeiten“ historische Daten aktuell erscheinen. Ein canonical auf den heutigen Zeitplan signalisiert zusätzlich, Fakten verschiedener Zeiträume gehörten zum selben Dokument. Erhalten Sie ursprünglichen Zeitraum, Quelle und eigene Adresse und verlinken Sie die aktuelle Anleitung, damit Leser frühere Regeln prüfen können.

Suchsysteme gruppieren Dokumente und schätzen Datumsangaben für Ergebnisse. Generierte Antworten müssen Material für den Zeitpunkt der Frage auswählen. Übereinstimmende Adressen, Zeiträume und Inhalte schaffen Vergleichsgrundlagen. Lesen Sie in Search Console ausgewählte kanonische Adresse und letzten Abrufzeitpunkt; vergleichen Sie bei KI-Antworten zitierte Seite und Gültigkeitszeitraum der Aussage.

Kanonisierungsbedürftige Duplikate von eigenständigen Dokumenten trennen

Kanonisierung wählt aus mehreren Kandidaten die maßgebliche URL. Bei demselben Artikel mit bloßen UTM-Trackingparametern oder anderer Ausgabeform kann die Adresse vereinheitlicht werden. Interne Links und Sitemap verwenden sie ebenfalls. Google bezeichnet Weiterleitungen und rel=canonical als starke, Sitemaps als schwächere Signale. Die endgültige Wahl trifft das Suchsystem. Richtlinien für kanonische URLs

Ein Browser bleibt beim Lesen eines canonical-Links auf der ursprünglichen URL. Besucher werden mit 301 oder 308 weitergeleitet. Private Dokumente benötigen Authentifizierung und Rechteprüfung; öffentliche Dokumente werden mit noindex aus der Suche ausgeschlossen.

Werden Grund- und UTM-Adresse derselben Anleitung getrennt abgerufen, muss das Suchsystem beide vergleichen und einen Vertreter wählen. Abgestimmte canonical-Angaben und interne Links bündeln Signale identischer Inhalte an der gewünschten Adresse. Historische und aktuelle Anleitungen beantworten unterschiedliche Zeiträume und behalten eigene URLs. Ob KI Vergangenheitsangaben als aktuell liest, muss auch anhand der Zeitraumerklärung und tatsächlicher Zitate geprüft werden.

Erstellung, Veröffentlichung, Änderung, Ereignis und Gültigkeit trennen

createdAt ist der interne Erstellungszeitpunkt des Entwurfs. Ein bestätigtes Erstveröffentlichungsdatum wird als publishedAt gespeichert und in JSON-LD datePublished verwendet. contentModifiedAt bezeichnet die inhaltliche Änderung der öffentlichen Fassung und liefert dateModified. Wird es bei jedem Speichern, Bereitstellen oder Abrufen geändert, ist nicht mehr erkennbar, welche Tatsache wann geändert wurde.

Das Ereignisdatum bezeichnet den Tag des beschriebenen Geschehens. Beschluss einer Betriebsregel, Veröffentlichung der Mitteilung und Gültigkeitsbeginn des neuen Zeitplans können auseinanderliegen. Trennen Sie auch die sichtbaren Labels „Veröffentlicht“, „Geändert“ und „Gültigkeitszeitraum“. Googles Datumsrichtlinie verlangt konsistente Veröffentlichungs- und wesentliche Änderungsdaten in sichtbarem Inhalt und strukturierten Daten, ohne Verwechslung mit Ereignisdaten. Richtlinien zu Seitendaten

lastmod in der Sitemap bezeichnet eine wichtige Änderung an der URL. Es wird aus tatsächlichen Änderungen an Inhalt, wichtigen Links oder strukturierten Daten gebildet und ohne genaue Aufzeichnung weggelassen. Ein heutiges Datum allein macht aus einem alten Artikel keine inhaltliche Aktualisierung. Sitemap-Richtlinien · Richtlinien zur Inhaltsaktualisierung

Wird am 25. Oktober ein Hinweis „Veröffentlicht am 24. Oktober; neue Öffnungszeiten ab 1. November“ gelesen, gelten noch die alten Zeiten. Die Auswahl nur nach neuestem Veröffentlichungsdatum kann künftige Zeiten als heutige ausgeben. Veröffentlichungs- und Änderungsdaten beschreiben das Dokument, Gültigkeitszeiträume die Anwendbarkeit seiner Fakten. Schreiben Sie deshalb „ab 1. November“ in den Text und trennen Sie aktuelle von geplanten Hinweisen.

Veröffentlichungsstatus unabhängig von aktueller oder historischer Gültigkeit darstellen

Auch historische Aufzeichnungen können öffentliche Dokumente sein. Trennen Sie publicationStatus mit Entwurf, veröffentlicht und zurückgezogen von der Gültigkeit der Fakten. Wird ein nicht mehr geltender Eintrag gelöscht, lassen sich Fragen nach früheren Regeln oder Gebühren nicht mehr beantworten. Entscheiden Sie nach Bewertung von Erhaltungswert und Zugriffsregeln über die Öffentlichkeit.

Die Dokument-ID identifiziert den Artikel, revision die bearbeitete Fassung, slug den Adressnamen. Bei geändertem Titel oder slug desselben Dokuments bleiben stabile ID und Änderungshistorie erhalten. Haben aktuelle Anleitung und historische Aufzeichnung eigene Dokumente, erhalten sie unterschiedliche IDs und Links wie „Aktuelle Anleitung“ oder „Frühere Anleitung“. supersedes kann intern kennzeichnen, dass ein Nachfolgedokument ein früheres ersetzt.

validFrom und validUntil speichern im Beispielmodell den Gültigkeitszeitraum. WebPage enthält Veröffentlichungs- und Änderungsdaten; die Gültigkeit steht sichtbar im Text, etwa „1. Januar bis 31. Dezember 2025“. Schema.org-Eigenschaften sind je Dokumenttyp definiert. WebPage-Eigenschaften

Datums- und Adressentscheidungen in ausführbare Funktionen umsetzen

Speichern Sie den folgenden Code als identity-time.mjs. Er läuft unter Node.js 22 ohne externe Pakete. dateOnly prüft ein tatsächlich existierendes YYYY-MM-DD und gibt es unverändert zurück. instant prüft sekundengenaue Zeitangaben mit expliziter Zeitzone. Ergänzen Sie keine erfundene Uhrzeit oder Zeitzone, wenn nur der Ereignistag bekannt ist.

ISO 8601 standardisiert die Darstellung von Datum und Uhrzeit. Das Beispiel verwendet sekundengenaue Werte mit UTC-Abstand wie 2026-10-23T12:00:00+09:00. +09:00 bedeutet neun Stunden vor UTC; derselbe Zeitpunkt lautet dort 2026-10-23T03:00:00Z. Dienste mit saisonalen regionalen Zeitwechseln müssen auch diese Regeln verwalten.

canonicalUrl bildet die URL aus gespeichertem Pfad und einer inhaltsverändernden Seitennummer. Das Beispiel erlaubt nur lateinische Kleinbuchstaben, Ziffern und Bindestriche. Unterstützt ein realer Dienst koreanische slugs oder weitere Parameter, wird entsprechend dem Datenvertrag erweitert. Request-Host und gesamte Query werden nicht kopiert; UTM und beliebige Domains gelangen daher nicht in die kanonische Adresse.

// Node.js 22, Keine externen Pakete. Zeitwerte sekundengenau; Veröffentlichung und Änderung können reine Daten sein. export function dateOnly(value) { if (typeof value !== 'string' || !/^\d{4}-\d{2}-\d{2}$/.test(value)) throw new Error('Invalid date'); const ms = Date.parse(value + 'T00:00:00Z'); if (!Number.isFinite(ms) || new Date(ms).toISOString().slice(0, 10) !== value) throw new Error('Invalid date'); return value; // Ereignistage nicht durch Zeitzonen verschieben. } export function instant(value) { const m = typeof value === 'string' && value.match( /^(\d{4}-\d{2}-\d{2})T(\d{2}):(\d{2}):(\d{2})(Z|[+-]\d{2}:\d{2})$/); if (!m) throw new Error('Timezone required'); dateOnly(m[1]); const offset = m[5] === 'Z' ? [0, 0] : m[5].slice(1).split(':').map(Number); if (+m[2] > 23 || +m[3] > 59 || +m[4] > 59 || offset[0] > 23 || offset[1] > 59) throw new Error('Invalid time'); const ms = Date.parse(value); if (!Number.isFinite(ms)) throw new Error('Invalid time'); return ms; } export function canonicalUrl(path, page = 1, origin = 'https://example.com') { // Gespeicherte Pfade und relevante Seitenzahlen statt Request-Host und Query verwenden. if (!/^\/[a-z0-9-]+(?:\/[a-z0-9-]+)*$/.test(path)) throw new Error('Invalid path'); if (!Number.isSafeInteger(page) || page < 1) throw new Error('Invalid page'); const url = new URL(path, origin); if (page > 1) url.searchParams.set('page', String(page)); return url.href; } // Veröffentlichung als Date oder sekundengenaues DateTime; reine Datumsgenauigkeit erhalten. export function contentDate(value) { if (/^\d{4}-\d{2}-\d{2}$/.test(value)) return dateOnly(value); instant(value); return value; } // Nur Vergleichsgrenzen; keine gespeicherten oder sichtbaren Veröffentlichungszeiten erfinden. // Übungsdaten beziehen sich auf den Bibliothekskalender Asia/Seoul. function bounds(value) { contentDate(value); if (value.length > 10) return [instant(value), instant(value)]; const start = instant(value + 'T00:00:00+09:00'); return [start, start + 86400000 - 1]; } export function isPublic(doc, now = Date.now()) { if (!Number.isFinite(now)) throw new Error('Invalid comparison time'); if (!['draft', 'published', 'withdrawn'].includes(doc.status)) throw new Error('Invalid status'); if (doc.publishedAt !== null) contentDate(doc.publishedAt); if (doc.deletedAt !== null) instant(doc.deletedAt); const release = doc.publicFrom === null ? null : instant(doc.publicFrom); return doc.status === 'published' && doc.deletedAt === null && release !== null && release <= now; } export function documentId(id, origin = 'https://example.com') { if (typeof id !== 'string' || !/^[a-z0-9-]+$/.test(id)) throw new Error('Invalid id'); return new URL('/#document-' + id, origin).href; } export function describeDocument(doc, asOf, origin = 'https://example.com') { const now = instant(asOf); // Gespeicherte Fehler auch bei Entwürfen melden; Öffentlichkeit nach Validierung prüfen. const published = doc.publishedAt === null ? null : bounds(doc.publishedAt); const modified = doc.contentModifiedAt === null ? null : bounds(doc.contentModifiedAt); const from = doc.validFrom === null ? null : instant(doc.validFrom); const until = doc.validUntil === null ? null : instant(doc.validUntil); if (published && modified && modified[1] < published[0]) throw new Error('Modified before publication'); if (from !== null && until !== null && from >= until) throw new Error('Invalid interval'); if (doc.eventDate !== null) dateOnly(doc.eventDate); const canonical = canonicalUrl(doc.path, 1, origin); const id = documentId(doc.id, origin); if (!isPublic(doc, now)) return null; if (published && published[0] > now) throw new Error('Future publication'); if (modified && modified[0] > now) throw new Error('Future modification'); const applicability = from === null ? 'unknown' : now < from ? 'scheduled' : until !== null && now >= until ? 'historical' : 'current'; return { id, canonical, applicability, ...(published === null ? {} : { datePublished: doc.publishedAt }), ...(modified === null ? {} : { dateModified: doc.contentModifiedAt }), }; } export function formatContentDate(value) { contentDate(value); // Reine Datumswerte nicht in andere Zeitzonen umrechnen. const day = value.length === 10 ? value : new Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Seoul', year: 'numeric', month: '2-digit', day: '2-digit', }).format(new Date(value)); const [year, month, date] = day.split('-').map(Number); return `${date}.${month}.${year}`; } export const example = { id: 'hours-2025', path: '/archive/opening-2025', revision: 2, status: 'published', deletedAt: null, publicFrom: '2024-12-23T09:00:00+09:00', createdAt: '2024-12-20T09:00:00+09:00', publishedAt: '2024-12-23T09:00:00+09:00', contentModifiedAt: '2026-10-01T09:00:00+09:00', eventDate: '2024-12-19', validFrom: '2025-01-01T00:00:00+09:00', validUntil: '2026-01-01T00:00:00+09:00', };

describeDocument erhält Dokument und Vergleichszeit asOf und prüft zuerst ID, Adresse, Daten und Zeiträume. Ungültige Entwurfsdaten werden ebenfalls gemeldet. Nur valide Eingaben gehen an isPublic; nichtöffentliche Dokumente ergeben null. Die Gültigkeit wird als startinklusives, endexklusives Intervall [Start, Ende) verglichen. Bei unbekanntem Beginn gilt unknown. id, canonical, datePublished, dateModified und applicability werden im nächsten Implementierungskapitel gemeinsam in Inhalt und JSON-LD verwendet.

publicFrom ist der genaue Beginn öffentlichen Zugriffs, unabhängig von publishedAt. contentDate bewahrt die Genauigkeit von Date und DateTime. bounds berechnet Vergleichsgrenzen reiner Datumswerte nach dem koreanischen Kalender dieser Bibliothek, speichert oder zeigt diese Grenzen aber nicht als Veröffentlichungszeit. Änderungen am selben Tag sind erlaubt, wenn Datum allein die Reihenfolge nicht klärt. Bei anderen regionalen Kalendern ist die Vergleichsregel ebenfalls anzugeben.

Bei applicability gleich historical werden eine Kennzeichnung als historische Aufzeichnung und der damalige Zeitraum angezeigt. Auch mit heutigem dateModified kann die Gültigkeit historisch bleiben. Die getrennte Berechnung verhindert, dass eine Tippfehlerkorrektur einen alten Zeitplan aktuell macht. Gemeinsame wiederverwendete Berechnung von canonical und Daten macht außerdem widersprüchliche Adressen und Datumsangaben in Titel, Text und JSON-LD leichter auffindbar.

Start- und Endgrenzen sowie ungültige Eingaben prüfen

Speichern Sie die nächste Datei als identity-time.test.mjs im selben Ordner und führen Sie node --test identity-time.test.mjs aus. Geprüft werden Öffentlichkeit, Gültigkeitsgrenzen, Zeitzonen sowie ungültige Daten und Adressen.

import test from 'node:test'; import assert from 'node:assert/strict'; import { dateOnly, instant, canonicalUrl, describeDocument, example, isPublic, formatContentDate } from './identity-time.mjs'; const at = '2026-10-23T12:00:00+09:00'; const historical = describeDocument(example, at); test('Historische Aufzeichnungen bleiben öffentlich und behalten ihre Adresse', () => { assert.equal(historical.applicability, 'historical'); assert.equal(historical.canonical, 'https://example.com/archive/opening-2025'); assert.equal(historical.datePublished, example.publishedAt); }); test('Gültigkeitsbeginn einschließen und Ende ausschließen', () => { const d = { ...example, contentModifiedAt: null }; assert.equal(describeDocument(d, '2024-12-31T23:59:59+09:00').applicability, 'scheduled'); assert.equal(describeDocument(d, d.validFrom).applicability, 'current'); assert.equal(describeDocument(d, d.validUntil).applicability, 'historical'); }); test('Entwürfe, zurückgezogene, gelöschte und noch nicht freigegebene Einträge nicht veröffentlichen', () => { for (const change of [{ status: 'draft' }, { status: 'withdrawn' }, { deletedAt: at }, { publicFrom: '2027-01-01T00:00:00Z', contentModifiedAt: null }]) { assert.equal(describeDocument({ ...example, ...change }, at), null); } }); test('Bei unbekanntem Beginn keine aktuelle Gültigkeit annehmen', () => { assert.equal(describeDocument({ ...example, validFrom: null }, at).applicability, 'unknown'); }); test('Nicht existente Daten und Zeitangaben ohne Zone ablehnen', () => { assert.throws(() => instant('2026-02-30T12:00:00+09:00')); assert.throws(() => instant('2026-10-23T12:00:00')); assert.throws(() => instant('2026-10-23T25:00:00Z')); assert.equal(dateOnly('2026-10-23'), '2026-10-23'); }); test('Gleiche Zeitpunkte verschiedener Zonen stimmen überein; Ereignistage bleiben gleich', () => { assert.equal(instant(at), instant('2026-10-23T03:00:00Z')); assert.equal(dateOnly(example.eventDate), '2024-12-19'); }); test('Umgekehrte Zeiträume sowie Änderungen in Zukunft oder vor Veröffentlichung ablehnen', () => { assert.throws(() => describeDocument({ ...example, validUntil: example.validFrom }, at)); assert.throws(() => describeDocument({ ...example, contentModifiedAt: '2027-01-01T00:00:00Z' }, at)); assert.throws(() => describeDocument({ ...example, contentModifiedAt: '2020-01-01T00:00:00Z' }, at)); }); test('Relevante Seitenzahlen und ungültige Pfade unterscheiden', () => { assert.equal(canonicalUrl('/guides', 2), 'https://example.com/guides?page=2'); assert.throws(() => canonicalUrl('//elsewhere.example/a')); assert.throws(() => canonicalUrl('/guides/../admin')); assert.throws(() => canonicalUrl('/guides', 0)); }); console.log(JSON.stringify(historical, null, 2)); test('Öffentlichkeitsprüfung lehnt nicht existente Kalendertage ab', () => { assert.throws(() => isPublic({ ...example, publishedAt: '2026-02-30T09:00:00+09:00' })); }); test('Ungültige Entwurfsdaten vor Veröffentlichungsausschluss melden', () => { assert.throws(() => describeDocument({ ...example, status: 'draft', validFrom: 'bad-date' }, at)); }); test('Reine Datumswerte und unbekannte Veröffentlichungsdaten erhalten', () => { const d = { ...example, publishedAt: '2024-12-23', contentModifiedAt: null }; assert.equal(describeDocument(d, at).datePublished, '2024-12-23'); assert.equal(formatContentDate('2024-12-23'), '23.12.2024'); assert.equal(describeDocument({ ...d, publishedAt: null }, at).datePublished, undefined); assert.equal(describeDocument({ ...d, publicFrom: null }, at), null); }); test('Dokument-ID bei Adressänderung erhalten', () => { const moved = describeDocument({ ...example, path: '/archive/old-hours' }, at); assert.equal(moved.id, historical.id); assert.notEqual(moved.canonical, historical.canonical); });

Die Ausgabe enthält applicability historical und canonical https://example.com/archive/opening-2025. Erstveröffentlichung und wesentliche Änderung behalten die Eingabewerte. Alle 12 Tests müssen bestehen. Ergibt die Endgrenze current, prüfen Sie, ob der Vergleich >= lautet. Wird 2026-02-30 akzeptiert, prüfen Sie die Kalenderdatumsvalidierung. Zeitangaben ohne Zone können je Serverregion denselben Text als unterschiedliche Zeitpunkte interpretieren.

Verwenden Sie Öffentlichkeit und Gültigkeitsstatus in der Seitenausgabe. Veröffentlichung schaltet die Datenbankrevision um und aktualisiert Caches. Soll eine statische Seite zum geplanten Zeitpunkt automatisch wechseln, verbinden Sie eine entsprechende Regenerierungsaufgabe. Bereits zwischengespeicherte Revisionen werden über die Aktualisierungspfade in Cache-Betrieb geprüft.

Aktuelle Anleitung und historische Aufzeichnung im Text erkennbar machen

Beginnen Sie historische Einträge mit Zeitraum und weiterführendem Weg, etwa „Dieser Zeitplan galt vom 1. Januar bis 31. Dezember 2025. Die aktuellen Öffnungszeiten finden Sie im folgenden Hinweis.“ Beim maschinenlesbaren Ende 2026-01-01T00:00:00+09:00 ist der letzte gültige Kalendertag der 31. Dezember 2025. Vergleichen Sie Grenzwerte und sichtbare Sätze gemeinsam.

Aktuelle Hinweise nennen Gültigkeitsbeginn und Ausnahmen; Veröffentlichungs- und Änderungsdaten erhalten eigene Labels. Ein historisches Dokument mit korrekten JSON-LD-Daten, aber dem Titel „Aktuelle Anleitung“, verwirrt dennoch. Titel, Zusammenfassung, Tabellen, Quellen und strukturierte Daten müssen denselben Zeitpunkt und dieselben Bedingungen beschreiben.

Erhalten Sie bei erneuter Veröffentlichung oder Migration die ursprünglich bestätigten Daten und Quellen. Ersetzen Sie ein unbekanntes Erstveröffentlichungsdatum nicht durch die Speicherzeit des neuen Systems. Erläutern Sie nur, was zur Interpretation nötig ist, etwa „Ursprüngliches Veröffentlichungsdatum unbekannt“, und verwenden Sie belegbare Änderungs- oder Gültigkeitsdaten.

Datumsgenauigkeit und Änderungsart bewahren

Ist nur „Veröffentlicht am 23. Dezember 2024“ überliefert, speichern Sie publishedAt als 2024-12-23. Der Zusatz 00:00:00+09:00 würde eine unbelegte Uhrzeit erfinden. Ist auch der Tag unbekannt, bleibt null und datePublished entfällt. Für serverseitige Veröffentlichungstermine dient ein gesondert bestätigtes publicFrom. Google beschreibt die Uhrzeit bei Veröffentlichungsdaten als optional. Richtlinien zu Veröffentlichungsdaten

const migrated = { publishedAt: "2024-12-23", // Im Original bestätigtes Datum publicFrom: "2026-10-24T09:00:00+09:00", // Freigabezeitpunkt der migrierten Fassung contentModifiedAt: null, // Keine wesentliche Änderung dokumentiert } // JSON-LD: "datePublished": "2024-12-23" // Anzeige: Veröffentlicht 23.12.2024

Tippfehlerkorrekturen und geänderte Öffnungszeiten benötigen unterschiedliche Datumsaktualisierungen. Die folgende Tabelle zeigt Beispiele für Veröffentlichungsdatum, Änderungsdatum, lastmod und Gültigkeit je Änderung. Auch der Austausch eines Quellenlinks für eine zentrale Regel zählt als Inhaltsänderung.

Aktuelle Institutionsdarstellung und historische Aktivitäten verschiedenen Zeitpunkten zuordnen

Angenommen, ein „Eröffnungsvorbereitungsausschuss“ bereitete die Bibliothek 2025 vor, und seit 2026 betreibt sie das „Bibliotheksbetriebsteam“. Bleibt der Startseitentitel beim Ausschuss, bleibt Material, das aktuelle Fragen mit der alten Rolle beantwortet. Wird umgekehrt die Unterschrift im Protokoll von 2025 auf Betriebsteam geändert, wird die historische Aufzeichnung verfälscht. Aktuelle Vorstellung und Protokoll nennen jeweils die aktuelle beziehungsweise damalige Rolle und Zeit.

Das Änderungsdatum des Textes erklärt, wann Informationen geändert wurden; der Gültigkeitszeitraum der Rolle erklärt, für welchen Fragezeitpunkt sie gelten. Ein 2026 hinzugefügter Folgelink kann das Änderungsdatum eines Protokolls von 2025 aktualisieren, während Rolle und Sitzungstag 2025 bleiben. Eine Suche, die nur zuletzt geänderte Dokumente wählt, kann dies verwechseln.

Behalten Sie die Institutions-ID im CMS und speichern Sie Rolle, Beginn, Ende und Belegdokument-ID getrennt. Aktueller Header, Vorstellung und Freigabetitel entstehen aus der aktuellen Rolle, historische Seiten aus der damals gespeicherten Rolle. Auch eigenes RAG erhält Dokument-ID, Rolle und Gültigkeitszeitraum. Verknüpfen Sie Fragen und Suchbedingungen so, dass „aktuell“ am Stichtag gültige Dokumente und „2025“ Material für dieses Jahr findet.