Update Signale und dateModified im Schema Markup richtig einsetzen

dateModified, datePublished und das ISO-8601-Format im Überblick

dateModified ist eine Eigenschaft aus schema.org. Sie hält Datum und Uhrzeit der letzten wesentlichen Änderung eines Inhalts fest, etwa eines Article oder einer WebPage. Das Gegenstück heißt datePublished und steht für die Erstveröffentlichung. Beide Werte folgen dem Format ISO 8601, zum Beispiel 2026-11-07T09:30:00+01:00. Google empfiehlt, die Zeitzone anzugeben.

In der Google-Dokumentation zu Article ist dateModified eine empfohlene Eigenschaft und kein Pflichtfeld. Für das Datum im Suchergebnis wertet Google mehrere Quellen aus, die strukturierten Daten sind eine davon. Sichtbares Datum und Markup sollten deshalb dasselbe sagen.

Wie stark die KI-Assistenten das Datum gewichten, beschreiben die Anbieter nicht im Detail. Verstehen Sie dateModified daher als ehrliche Auskunft über den Stand einer Seite. Eine Nennung in KI-Antworten folgt daraus nicht automatisch, und zusagen lässt sie sich nicht.

Wann ist eine Änderung wesentlich genug für ein neues dateModified?

Als Probe genügt ein Vergleich: Legen Sie alte und neue Fassung nebeneinander. Findet ein Leser einen inhaltlichen Unterschied, der seine Entscheidung berühren könnte, ist die Änderung wesentlich. Google nennt in seinen Hinweisen zu hilfreichen Inhalten ausdrücklich die Frage, ob Seiten umdatiert werden, obwohl sich der Inhalt nicht wesentlich geändert hat.

Das rechtfertigt ein neues Datum

• geänderte Preise, Zahlen, Fristen oder technische Angaben
• neue, gestrichene oder umgeschriebene Abschnitte
• eine überarbeitete Kurzantwort-Box am Seitenanfang oder neue Antworten in der FAQ
• ausgetauschte Quellen, etwa eine neuere Norm

Das rechtfertigt kein neues Datum

• Tippfehler, Kommas, Farben und Layout
• Änderungen an Footer, Cookie-Hinweis, Seitenleiste oder Kommentaren
• automatisch erzeugte Blöcke wie „Ähnliche Beiträge“
• Updates von Theme oder Plugins ohne Textänderung

Wer beim Aktualisieren Werbefloskeln durch belegte Zahlen ersetzt, hat dagegen eine echte Änderung vorgenommen. Wie das gelingt, steht in der Anleitung zu messbaren Zahlen statt Werbefloskeln.

Wie läuft ein sauberer Update-Kreislauf von der Änderung bis zur Sitemap?

Ein Datum bleibt glaubwürdig, wenn alle Stellen aus einer Quelle kommen. Richten Sie deshalb einmal ein, dass das sichtbare Datum, dateModified im JSON-LD und lastmod in der Sitemap dasselbe CMS-Feld lesen. Danach läuft jedes Update in dieser Reihenfolge:

1. Änderung im Text vornehmen und jede Zahl gegen die Originalquelle prüfen, etwa Datenblatt oder Preisliste.
2. Entscheiden, ob die Änderung wesentlich ist. Nur dann das Änderungsdatum im CMS neu setzen.
3. Eine kurze Änderungsnotiz im sichtbaren Text ergänzen, wenn Sie ein Änderungsprotokoll führen.
4. Veröffentlichen. Sichtbares Datum, JSON-LD und Sitemap übernehmen den neuen Wert aus dem Feld.
5. Seiten- und CDN-Cache leeren, damit der neue HTML-Stand ausgeliefert wird.
6. Die Live-URL im Schema Markup Validator und im Rich-Results-Test prüfen.
7. In der Search Console die URL-Prüfung ausführen, bei Bedarf die Indexierung beantragen und den Sitemap-Bericht ansehen.

Den Aufbau des Markups selbst beschreiben die Best Practices zu JSON-LD für Article und FAQPage.

Welche Update-Signale gehören neben dateModified dazu?

Crawler vergleichen mehrere Stellen einer Seite. Widersprechen sich die Angaben, ist unklar, welcher Angabe ein Crawler trauen soll.

Laut Googles Anleitung zum Erstellen von Sitemaps wertet Google lastmod nur aus, wenn der Wert verlässlich und nachprüfbar stimmt. Die Felder priority und changefreq ignoriert Google.

Weitere Signale liegen außerhalb des Markups: ein Änderungsprotokoll am Seitenende und interne Links von Übersichtsseiten auf die aktualisierte URL, wie die Anleitung zur internen Verlinkung nach Themenclustern und Pillar Pages sie beschreibt. Wer eine llms.txt pflegt, nimmt sie in die Update-Routine auf (Anleitung zur llms.txt). Ob KI-Anbieter diese Angaben auswerten, lässt sich nicht zusagen.

Welche Fehler machen Datumsangaben unglaubwürdig?

Unglaubwürdig wird ein Datum, wenn es sich ohne inhaltliche Änderung bewegt oder an verschiedenen Stellen verschieden lautet. Diese Ursachen treten häufig auf:

• Das Template schreibt bei jedem Seitenaufruf die aktuelle Uhrzeit als dateModified. Das Datum wandert, obwohl niemand etwas geändert hat. Lesen Sie den Wert stattdessen aus dem gespeicherten Änderungsfeld.
• Jedes Speichern im CMS setzt das Datum neu, auch bei Tippfehlern und Plugin-Updates. Ein eigenes Feld oder eine feste Redaktionsregel für „wesentliche Änderung“ löst das.
• JSON-LD, sichtbares Datum und lastmod nennen drei verschiedene Tage. Eine gemeinsame Quelle für alle drei beseitigt den Widerspruch.
• Die Zeitzone fehlt oder wechselt zwischen UTC und Ortszeit, sodass das Datum auf den Vortag rutschen kann. Verwenden Sie durchgängig Ortszeit mit Offset oder durchgängig UTC.
• dateModified liegt vor datePublished, etwa nach einem Import alter Artikel. Gleichen Sie beide Felder ab.
• Theme und SEO-Plugin geben je einen Article-Block mit unterschiedlichen Werten aus. Schalten Sie einen der beiden ab.
• Ein Skript datiert über Nacht viele Seiten um. Ohne inhaltliche Änderung gehört kein neues Datum auf die Seite.
• Der Cache liefert den alten HTML-Stand aus, und Crawler lesen das alte Datum. Leeren Sie den Cache beim Veröffentlichen. Zur Ladezeit selbst gibt es die Anleitung zu Ladezeit und Core Web Vitals.

Wie kontrollieren Sie eine Datumsänderung vor und nach dem Livegang?

Vor und nach dem Livegang helfen drei Handgriffe:

1. Sichern Sie vor größeren Änderungen den bisherigen Stand, etwa über den Versionsverlauf Ihres CMS, damit Sie bei einem Fehler zurückgehen können.
2. Lassen Sie eine zweite Person die Änderung vor dem Livegang ansehen, besonders bei Preisen, Zahlen und Fristen.
3. Prüfen Sie wöchentlich in der Search Console, ob die aktualisierten URLs gelesen wurden. Stellen Sie die Käuferfragen, auf die Ihre Seite antworten soll, in festen Abständen den KI-Assistenten und notieren Sie Nennungen mit Datum und Plattform.

KI-Antworten schwanken je nach Zeitpunkt, Modellversion, Standort und Kontext. Einzelne Ergebnisse sind deshalb Stichproben und Indikatoren. Bewerten Sie den Verlauf über mehrere Wochen. Ob Ihre Domain bei einer Käuferfrage heute genannt wird, zeigt der kostenlose KI-Check als unverbindliche Momentaufnahme.

Häufige Fragen von Entscheidern

Soll datePublished bei einem Update ebenfalls geändert werden?

Nein. datePublished hält die Erstveröffentlichung fest und bleibt bei Updates bestehen. Es ändert sich nur dateModified, und dieser Wert liegt nie vor datePublished. Behandelt eine Seite nach einer Überarbeitung ein anderes Thema, kann eine neue URL sinnvoller sein als ein neues Datum auf der alten.

Gilt dateModified für die ganze Seite oder für einzelne Abschnitte?

Der Wert gilt für das gesamte Inhaltsobjekt, etwa einen Article oder eine WebPage. Ändern Sie einen Abschnitt wesentlich, setzen Sie das Datum der ganzen Seite neu. Was sich genau geändert hat, zeigt ein kurzes Änderungsprotokoll im sichtbaren Text.

Wie schnell erscheint ein neues Datum in Google oder in KI-Antworten?

Nach einem Antrag auf erneutes Crawlen dauert es laut Google einige Tage bis mehrere Wochen, und mehrere Anträge für dieselbe URL beschleunigen nichts. Wann ein Crawler Ihre URL erneut abruft, steuern Sie nur begrenzt. Sie können in der Search Console die Indexierung beantragen und die Sitemap aktuell halten. Wie lange KI-Antworten brauchen, bis sie die neue Fassung widerspiegeln, lässt sich nicht zusagen.

Kann Smart2Index die Datumsangaben auf meiner Website pflegen?

Wir setzen jeden Tag ein Arbeitspaket auf Ihrer Website um, höchstens 30 im Monat. Das kann eine Seite, ein Text, ein Rechner oder eine Korrektur sein, darunter On-Page-Fixes mit Titeln, Beschreibungen, strukturierten Daten und Ladezeit. Ob Ihre Datumsfelder dazugehören, hängt von Ihrer Seite ab. Nach Ihrer Anfrage sehen wir sie uns an und antworten innerhalb eines Werktags mit einem Ja und einer Liste, was wir brauchen, oder mit einem ehrlichen Nein.