Event-Schema für SEO: Wenn Termine falsch werden

Event-Schema ist die strukturierte Auszeichnung, mit der eine Suchmaschine die wesentlichen Fakten einer Veranstaltung herauslesen kann, ohne den Fließtext zu interpretieren: Name, Beginn und Ende, Ort, ob sie online stattfindet, ob es noch Zugang gibt und was er kostet. Richtig gesetzt kann das dazu führen, dass Datum, Ort und Preis direkt im Suchergebnis erscheinen – der eigentliche Nutzen liegt aber tiefer: Es ist der einzige Weg, diese Fakten eindeutig und ohne Interpretationsspielraum zu machen.

Die Schwierigkeit dabei ist selten die erste Auszeichnung. Eine einzelne Veranstaltungsseite korrekt zu markieren ist eine halbe Stunde Arbeit. Schwierig wird es danach: wenn sich ein Termin verschiebt, ein Ticketkontingent ausverkauft ist oder die Veranstaltung längst vorbei ist und die Seite trotzdem weiterläuft. Genau dort entstehen die Fehler, die diesen Artikel tragen.

Für wen sich Event-Schema wirklich lohnt

Wer im eigenen Kalender öffentliche Termine anbietet, ist die Zielgruppe: Veranstaltungsorte, Kulturhäuser, Ticketanbieter, aber ebenso Anbieter von Webinaren, Online-Kursen, Zertifizierungsseminaren und wiederkehrenden Fachveranstaltungen. Das Muster ist immer dasselbe – ein fixer Zeitpunkt, ein Ort, real oder virtuell, und meist eine Form von Zugang, der begrenzt oder kostenpflichtig ist. Damit ist der Fall relevant.

Wer keine festen Termine hat, etwa "Beratungsgespräche jeden Montag nach Vereinbarung" ohne konkretes Startdatum, hat streng genommen kein Event, sondern eine Dienstleistung. Event-Schema für einen Dauerzustand zu verwenden, der weder echten Anfang noch echtes Ende hat, ist der erste verbreitete Fehler: Es entsteht eine Auszeichnung ohne belastbaren Inhalt, weil Pflichtfelder mit Platzhaltern gefüllt werden müssen, um überhaupt gültig zu sein.

Start und Ende: mit Zeitzone, nicht ohne

Die zwei Felder, an denen ein Event-Markup am häufigsten scheitert, sind startDate und endDate – genauer: das Fehlen der Zeitzone. Ein Datum ohne Zeitzonenangabe wird von der auswertenden Maschine nicht automatisch als "Ortszeit der Website" gelesen, sondern uneindeutig oder als UTC behandelt. Für eine Veranstaltung, die um 19 Uhr in Berlin beginnt, ist der Unterschied zwischen "19:00" und "19:00+02:00" der Unterschied zwischen richtig und zwei Stunden daneben.

Ebenso häufig fehlt endDate ganz, weil die Seite nur mit dem Beginn wirbt. Verpflichtend ist das Feld nicht, aber wo eine Dauer bekannt ist – ein zweistündiger Vortrag, eine dreitägige Messe –, gehört sie hinein, weil sie beantwortet, ob eine Veranstaltung zum Zeitpunkt einer Suche noch läuft, gerade beginnt oder bereits vorbei ist.

• startDate im ISO-8601-Format mit Zeitzonen-Offset angeben, zum Beispiel 2026-11-04T19:00+01:00
• endDate ergänzen, sobald eine Dauer feststeht, statt das Feld leer zu lassen
• Bei mehrtägigen Veranstaltungen den Start des ersten und das Ende des letzten Tages angeben, nicht nur ein einzelnes Datum

Der Ort: real, virtuell – oder beides

location erwartet ein Ortsobjekt mit Adresse, wenn eine Veranstaltung physisch stattfindet. Der verbreitete Fehler bei Online-Veranstaltungen ist, genau dieses Objekt trotzdem zu verwenden – mit der Firmenadresse des Veranstalters, obwohl niemand dorthin fährt. Für ein Webinar oder einen rein digitalen Kongress ist das schlicht falsch, weil es keinen physischen Ort gibt, der beschrieben werden könnte.

Für Online-Events existiert dafür eine eigene virtuelle Location: der Teilnahmemodus wird als reines Online-Event gekennzeichnet, und als Ort dient die tatsächliche Zugangs-URL, nicht eine Straßenadresse. Findet eine Veranstaltung sowohl vor Ort als auch per Stream statt, gehören beide Angaben nebeneinander – die physische Adresse für die Teilnehmer im Saal, die virtuelle Location für die Teilnehmer am Bildschirm, verbunden über den entsprechenden gemischten Teilnahmemodus.

Wer die Wahl zwischen online und vor Ort nicht klar trifft, produziert eine Auszeichnung, die formal gültig ist, aber inhaltlich irreführt – etwa ein Webinar mit einer Straßenadresse, an der niemand ist. Ein Validator meldet das nicht als Fehler, weil das Schema syntaktisch korrekt bleibt; auffallen tut es erst, wenn jemand versucht, der Adresse zu folgen.

Verfügbarkeit und Preis: offers korrekt setzen

offers beschreibt, ob und zu welchem Preis Zugang zur Veranstaltung besteht, über Preis, Währung und Verfügbarkeit. Der verbreitete Fehler ist selten ein falscher Preis, sondern ein veralteter Verfügbarkeitsstatus: ein Ticketkontingent, das seit Wochen ausverkauft ist, während das Markup weiterhin verfügbaren Zugang meldet, weil das Feld beim Verkaufsstart einmal gesetzt und danach nie wieder angefasst wurde.

Wo mehrere Preisstufen existieren – Frühbucher, Standard, ermäßigt –, reicht ein einzelnes Angebotsobjekt oft nicht aus. Genauer ist eine Liste mehrerer Angebote, jedes mit eigenem Preis und eigener Verfügbarkeit, statt stellvertretend für alle nur den günstigsten oder den zuerst verkauften Preis zu melden.

• Verfügbarkeit aktuell halten – verfügbar, ausverkauft oder vorbestellbar, je nach tatsächlichem Verkaufsstand
• Bei kostenlosen Veranstaltungen den Preis explizit auf 0 setzen, das Feld nicht weglassen
• Ein Startdatum für den Verkauf ergänzen, wenn der Vorverkauf erst zu einem bestimmten Zeitpunkt beginnt

Verschoben, umbenannt, abgesagt: der Statuswechsel

Veranstaltungen ändern sich, und der Eventstatus bildet das ab: planmäßig für den Normalfall, verschoben ohne neuen Termin, auf einen neuen Termin verlegt sobald einer feststeht, und abgesagt, wenn nichts mehr stattfindet. Der verbreitete Fehler ist, den Status im Fließtext zu ändern – ein Banner "Achtung: verschoben!" auf der Seite –, während das Markup unverändert den ursprünglichen Status mit dem alten Datum meldet.

Diese Lücke ist deshalb ärgerlich, weil sie genau in dem Moment entsteht, in dem korrekte Information am wichtigsten ist: kurz vor einem abgesagten oder verschobenen Termin, wenn Menschen aktiv nach dem aktuellen Stand suchen. Wer den Status pflegt, statt ihn beim Anlegen der Seite einmalig zu setzen und danach zu vergessen, vermeidet genau diesen Fall.

Bei einer echten Absage stellt sich zusätzlich die Frage, wie lange die Seite überhaupt online bleibt. Eine abgesagte Veranstaltung dauerhaft als abgesagt zu kennzeichnen ist ehrlicher als sie kommentarlos zu entfernen, insbesondere wenn Suchanfragen zu Name und Termin weiterlaufen – wer nach der abgesagten Veranstaltung sucht, soll eine klare Bestätigung finden, keine Fehlerseite.

Wiederkehrende Termine: eine URL pro Ausgabe

Ein wöchentlicher Kurs, eine monatliche Meetup-Reihe, ein jährliches Fachseminar – überall dort besteht die Versuchung, eine einzige Seite zu pflegen und bei jedem neuen Termin einfach Datum und Ort zu überschreiben. Das spart Pflegeaufwand, zerstört aber die Historie: Wer die Seite verlinkt, geteilt oder gespeichert hatte, findet später einen anderen Termin vor als den, auf den ursprünglich verwiesen wurde.

Der robustere Weg ist eine eigene URL pro Ausgabe – etwa /webinar-2026-11 statt einer immer wieder überschriebenen /webinar –, jeweils mit eigenem Event-Markup für genau diesen einen Termin. Eine übergeordnete Seite kann weiterhin die Reihe als Ganzes vorstellen und auf die einzelnen Ausgaben verlinken, sollte sich aber nicht selbst als den jeweils aktuellen Termin ausgeben.

Für echte Serien kennt das Vokabular zusätzlich ein eigenes Konstrukt für Veranstaltungsreihen, mit dem eine Reihe als Ganzes ausgezeichnet und mit ihren einzelnen Terminen verknüpft werden kann. Sinnvoll ist das, wenn tatsächlich mehrere feste Termine gleichzeitig bekannt sind, etwa eine Konferenz mit drei Terminen im Jahr – weniger sinnvoll für einen Termin, der erst nach und nach feststeht.

Ein Beispiel macht den Unterschied greifbar: Ein Anbieter von Online-Seminaren trägt jeden ersten Donnerstag im Monat ein neues Webinar zum selben Thema aus. Die naheliegende, aber problematische Umsetzung ist eine einzige Seite /webinar, deren startDate am Anfang jedes Monats manuell aktualisiert wird. Solange das jemand zuverlässig tut, funktioniert es – bis genau einmal jemand krank ist, im Urlaub ist oder den Termin vergisst, und die Seite tagelang mit dem Datum des Vormonats stehen bleibt, während sie weiterhin als bevorstehende Veranstaltung markiert ist.

Die robustere Umsetzung trennt drei Ebenen: eine Übersichtsseite für die Reihe als Ganzes, ohne eigenes Datum, ein Event-Markup pro Monatstermin unter einer eigenen URL wie /webinar/2026-11, und eine feste Regel, was mit dem November-Termin passiert, sobald er vorbei ist – hier: automatische Umschaltung auf einen Archivstatus mit Verweis auf den Dezember-Termin, statt eines manuellen Eingriffs. Weil die virtuelle Location bei einem Webinar ohnehin nur der Zugangslink ist, bleibt dieser Teil über alle Ausgaben hinweg gleich; nur startDate, endDate, eventStatus und gegebenenfalls die Verfügbarkeit der Plätze ändern sich von Termin zu Termin.

Das eigentliche Problem: Die Seite altert, das Markup nicht mit

Eine Event-Seite ist für einen begrenzten Zeitraum richtig – typischerweise die paar Wochen zwischen Veröffentlichung und Veranstaltungstermin – und danach dauerhaft falsch, wenn sich niemand mehr darum kümmert. Das unterscheidet Event-Schema von den meisten anderen Auszeichnungsarten: Ein Produkt bleibt ein Produkt, ein Artikel bleibt ein Artikel, aber ein Termin verfällt mit Ansage, an einem exakt bekannten Datum.

In der Praxis ist genau das die häufigste Fehlerquelle im gesamten Themenfeld: nicht eine falsch gesetzte Eigenschaft, sondern eine Veranstaltungsseite mit einem Datum in der Vergangenheit, die weiterhin als bevorstehendes Event ausgezeichnet ist, weil sie seit dem Launch niemand mehr angefasst hat. Das ist kein Randfall, sondern der Regelfall, sobald eine Website über mehr als eine Handvoll Veranstaltungen läuft.

Die Lösung ist keine technische, sondern eine organisatorische: vor der Veröffentlichung festlegen, was nach dem Termin mit der Seite geschieht, und diese Entscheidung so einrichten, dass sie automatisch greift, statt von einer manuellen Erinnerung abzuhängen. Drei Wege sind in der Praxis brauchbar:

• Als Archiv stehen lassen, aber sichtbar und im Markup klar als vergangene Veranstaltung kennzeichnen, statt sie stillschweigend als bevorstehend weiterzuführen
• Auf die nächste Ausgabe weiterleiten, wenn die Seite ohnehin nur den jeweils nächsten Termin einer Serie repräsentieren soll
• Als dauerhafte Serienseite führen, die selbst nie ein einzelnes Datum trägt, sondern auf die aktuellen Einzeltermine verweist

Validieren – und mit der sichtbaren Seite synchron halten

Ein Validator prüft, ob das Markup syntaktisch korrekt ist und die Pflichtfelder enthält. Er prüft nicht, ob eine Zeitzone stimmt, ob eine virtuelle Location tatsächlich zu einem Online-Event passt, oder ob der Verfügbarkeitsstatus dem echten Ticketstand entspricht. Diese Prüfungen kann nur ein Mensch übernehmen, der Markup und sichtbare Seite nebeneinanderlegt.

Der zuverlässigste Test ist deshalb der einfachste: Stimmen Datum, Ort, Preis und Status im Markup mit dem überein, was ein Besucher auf derselben Seite lesen würde? Weichen beide voneinander ab – weil die Seite textlich aktualisiert wurde, das Markup aber nicht, oder umgekehrt –, ist das eine Inkonsistenz, die eine auswertende Maschine nicht auflösen kann und im Zweifel zugunsten der falscheren Version entscheidet.

• Nach jeder inhaltlichen Änderung an Datum, Preis oder Status auch das Markup prüfen, nicht nur den sichtbaren Text
• Stichprobenartig ältere Event-Seiten kontrollieren, nicht nur neu veröffentlichte
• Bei Vorlagen, die Event-Markup automatisch erzeugen, den generierten Code am fertigen Feed testen, nicht nur an der Beispielseite in der Entwicklung