Event schema markup: 19 of 1,419 sites declared it, and 171 of 429 start dates had passed

What is event schema markup, and what counts as declaring one?

The type is old, widely supported and specific. schema.org gives Event a start date, an end date, a location, a duration, an attendance mode drawn from an enumeration, a status drawn from another, an offer, a performer, an organiser, a sponsor and a super event for grouping. It also carries more specific types for the obvious kinds of occasion, among them BusinessEvent, EducationEvent, ConferenceEvent, Festival and ExhibitionEvent, with others further down the tree such as BroadcastEvent, which sits under PublicationEvent. This corpus used three of them, once each: EducationEvent on acponline.org, BroadcastEvent on foxnews.com and BusinessEvent on plaid.com. 438 of the 442 nodes are typed Event itself, and the fourth exception, on collibra.com, carries a value in @type that is not a schema.org type at all.

Google's Event documentation, carrying Last updated 2026-09-08 UTC when it was opened on 5 October 2026, is narrower than the vocabulary and that narrowness is what this post measures against. It names four required properties rather than three: name, startDate, location set to a Place, and location.address set to a PostalAddress, which it glosses as the venue's detailed street address with Sydney marked as not recommended and Bennelong Point, Sydney NSW 2000, Australia marked as recommended. Everything else is recommended rather than required, including description, endDate, eventStatus, image, location.name, organizer, performer, previousStartDate, and offers with five sub-properties of its own: availability, price, priceCurrency, validFrom and url.

Counting a declaration needs one decision stated up front. Every figure below counts a node whose @type includes Event or one of its more specific types, found by parsing every JSON-LD block on the page and walking every object inside it, so a node nested inside a WebPage or inside an @graph is found rather than missed. That is the same walk this blog has used to count 17 of 605 home pages declaring an ItemList and 8 of 1,114 declaring speakable, so the adoption figures are comparable with each other. Microdata and RDFa were not counted, which matters a little: this blog has separately found 22 of 385 home pages carrying microdata, so a site marking events up in that syntax is invisible to this run and would be invisible to a reader of the figures without this sentence.

19 of 1,419 sites declared an Event, and two pages held 355 of the 442 nodes

320 of the 1,078 reachable home pages linked a path that looked like an events page, which is the honest denominator for how many sites in this corpus visibly run events at all. 552 candidate URLs were requested from those 320 sites and 519 answered HTTP 200 with HTML. 16 of the 519 carried Event markup. Five home pages carried it as well, two of them on sites whose events page also did, so the union is 19 hostnames and 21 pages. Set against the 320 sites that advertise an events page, 19 is the figure worth holding on to: most sites in this corpus that run events do not tell a machine when they are.

The distribution inside the 442 nodes is more skewed than the adoption figure suggests. eplocalnews.org, a local news site, publishes 267 Event nodes on one calendar page, each in its own JSON-LD script element, and four more on its home page. aiven.io publishes 88 on its events index. Those two pages account for 355 of the 442, and the remaining 87 are spread across 19 pages on 17 sites, ten of which carry exactly one node. So a count of nodes describes two publishing systems, and a count of sites describes the corpus. Both appear above for that reason. As an adoption figure, 19 of 1,419 sits among the rarest types this blog has counted, next to 21 of the 270 home pages showing a video declaring video schema and 33 of 615 declaring a rating, and well below the types that describe the site itself rather than something on it.

The skew runs straight into the one piece of Google guidance that governs where this markup belongs. The same documentation states that the event experience on Google only supports pages that focus on a single event, and recommends adding markup to event posting pages rather than to pages that list schedules or multiple events. 11 of the 21 pages measured here list more than one, and the two largest list 267 and 88. Nothing about that is malformed, and a page listing a season of events is a reasonable thing to publish. It is simply not the shape the documented appearance reads, so the two sites that invested the most markup in this corpus did so in the configuration Google says it does not support. That pattern of valid markup aimed at an appearance it cannot win is one this blog keeps meeting, most directly where a retired FAQ rich result left FAQPage markup still scoring.

383 of 442 nodes carried the required set, and 112 typed the address

On the three properties most people would name from memory the corpus does well. 438 of 442 nodes carry a startDate, 424 carry a name, and 397 carry a location whose type is Place. 383 carry all three plus an address on the Place, which is Google's full required set if the type of the address is ignored. Ignoring it is exactly what most of these sites did. Only 112 of the 383 gave the address as a PostalAddress object with its parts separated; 271 gave it as one unstructured string, and all 271 of those are on eplocalnews.org, whose calendar names the venue correctly under location.name and then writes the whole street address into a single value, as in 574 Prairie Center Drive, Suite 165, Eden Prairie, trailing comma included. A further 14 Places carry no address at all, on ntu.edu.sg, rcgp.org.uk and postman.com.

Where properties are missing, they are missing in blocks rather than at random, which is what you would expect of markup generated by a template. All 9 of the unilag.edu.ng nodes carry no location. All 18 of the wien.gv.at nodes carry no location either, and the reason is instructive rather than careless. One of the 18 is the parent event, named re:pair FESTIVAL 2026, and it carries a description, an image, an organizer, an offer and a URL. The other 17 are its subEvent entries and hold exactly three keys each: @type, startDate and endDate. So 17 of the 18 nodes are bare time slots with no name and no venue, and the one node that does know the venue puts it under a key called addresses, inside an object typed Address with the street under a key called street. None of those three names is in the vocabulary, which has location, PostalAddress and streetAddress for the same three jobs, and the same node carries its coordinates under geos rather than under a Place. Every fact a reader would want is in the document and none of it is where a consumer of schema.org looks. Compare the same template effect in 119 of 191 home pages with a clickable phone number naming no telephone and in two of 172 LocalBusiness nodes carrying opening hours: the sites that get a property right tend to get it right everywhere, and the ones that miss it miss it on every node they emit. The same shape shows up when a property is present but its value is not usable, as in 44 of 433 declared logo URLs returning no image.

The single clearest case is one node on collibra.com. Its @type is the string In-person event, which is a label a person wrote rather than a type the vocabulary defines, so nothing resolves it to Event or to anything else. The same node names the event with title rather than name, gives the date as 6 Oct 2026 under a key called date rather than startDate, puts the venue in location as a bare string, and puts the ticket page under registration. Every value on it is correct and useful to a human reader, the JSON parses, and a consumer following schema.org gets a node of an unknown type with no recognised property on it. It is the purest example this corpus offers of the difference between markup that parses and markup that says something, which is the distinction behind 117 of 612 home pages carrying a defect a validator can name.

171 of 429 start dates had already passed on the day of the scan

A date is the one property on an Event that goes wrong by itself. Nobody has to edit a page for its event to become a past event, and a page that keeps publishing the markup afterwards is making a false statement to anything that reads it without looking at the calendar. 429 of the 438 start dates in this corpus parse as ISO 8601. 171 of those 429 were earlier than 5 October 2026, the day they were read. By year of start date the split is 365 in 2026, 52 in 2024, 11 in 2025 and one in 2020.

Two of the stragglers are worth naming because they show the two ways this happens. foxnews.com declares a single Event on its home page called Fox News Channel Live Feed with a start date of 9 September 2020, which is a continuous stream described using a type for a thing that starts and stops. scripps.org publishes a class called Nutrition and Fitness During Cancer Treatment with a start date of 18 December 2024 and an end date of 21 December 2027, so the markup asserts a three year event that began nearly two years ago. Neither is a typo. Both are what a date looks like after a template has outlived the thing it described, and the slow drift of a claimed date away from reality is the same failure this blog measured when 74 of 81 pages disagreed with their own server about dateModified.

The format of the dates is in better order than their contents, with two exceptions. Google's documentation says plainly to specify the timezone by including the UTC or GMT time offset, and gives a worked example of a 7pm New York start written with a minus five offset. 55 of the 429 ISO dates carry no offset, and all 55 of those are also date only, with no time of day in them at all: 44 on eplocalnews.org, 10 on trip.com and one on uipath.com. A date with no time and no zone is still usable for a listing and still ambiguous by up to a day for anything trying to place it in a reader's own timezone. Separately, all nine rcgp.org.uk nodes write both start and end as strings of the form 10/5/2026 7:30:00 PM, which is a US locale rendering rather than ISO 8601 and ambiguous between the fifth of October and the tenth of May. That is nine of 442, so it is a small finding, but it is the kind that a generic parser resolves silently and wrongly.

The one check the corpus passed unanimously is the one Google's own AI guidance asks for. Its page on AI features and your website lists making sure your structured data matches the visible text on the page among the practices it recommends. The page's visible text was retained alongside the markup for the events pages but not for the home pages, which leaves 422 of the 429 ISO dates available for the comparison. On all 422, the year named in the markup appeared somewhere in the text a crawler could read. The day and month match less often on a strict string comparison, but that is a limit of comparing formats rather than evidence of disagreement, so the claim here stops at the year. On this corpus the dates in the markup are not secret dates. That is a better result than the same comparison produced for question and answer content, where 298 of 1,277 answers did not appear anywhere in the page the crawler was served, and it is worth recording when the corpus does something right.

Every eventStatus in the corpus said EventScheduled

eventStatus exists for the case the rest of the markup cannot express. schema.org describes it as particularly useful when an event is cancelled or rescheduled, and Google documents four values for it with instructions attached to each. EventCancelled comes with an explicit warning to keep every other property as it was, because startDate and location are what identify the unique event. EventPostponed says to keep the original start date until the new one is known. EventRescheduled says to update the dates and optionally add previousStartDate. EventScheduled is the fourth, and the page states it is the default. The property appears on 413 of the 442 nodes in this corpus, and what an AI crawler receives from all 413 of them is the same word. All 413 of them say EventScheduled. Not one node in the corpus uses any of the other three, and previousStartDate appears nowhere at all.

There is a reading of that which is entirely innocent: these are the events that were going ahead on 5 October 2026, and a cancelled event is often simply deleted from a site rather than restated. Google's documentation anticipates exactly that and advises against it, because the startDate is what identifies a unique event and removing the page loses the correction rather than publishing it. What the measurement supports is narrower than a conclusion about anybody's practice, and worth saying in full: the property is nearly universal here while carrying no information, since the documentation also states that an absent eventStatus is understood as EventScheduled anyway. 413 nodes spend a property saying the default.

Attendance mode is a near mirror of the same pattern. 409 nodes declare one: 397 offline, 11 online and one mixed. The 11 online nodes sit on aiven.io, scripps.org and plaid.com, and 11 nodes also declare a VirtualLocation. Here the documentation is blunt in a way worth quoting, because the markup and the appearance point in opposite directions: virtual experiences that have no real world component are not supported, and events must take place in a physical location. That is the only place the word virtual appears in the body of that page. A site declaring an online event in this markup is describing its event correctly in the vocabulary and declaring itself ineligible for the feature in the same breath. Offers are the one recommended block that is widely filled and consistently incomplete: 361 nodes carry an offer object, 360 of those carry a URL, and 272 carry all four of a price, a priceCurrency, an availability and a validFrom. 89 carry no price at all, and 88 of those 89 do carry a URL, so they point at a ticket page without saying whether a ticket exists or what it costs.

What this does not show about AI answers

Nothing in this run asked an answer engine anything, so nothing in it is evidence that Event markup changes what ChatGPT, Perplexity or Google's AI features say about a site. It is worth being blunt about that, because the type is the sort that invites an inference: a model answering a question about when something happens has to find a date, and a date in a field beats a date in a sentence. That is an argument from the shape of the data and it stays an argument until somebody measures the behaviour, and treating it as settled is how a checklist for AI visibility fills up with work nobody has shown to pay. The closest published evidence either way is not ours: a GEO-16 audit posted to arXiv scored the 1,100 URLs that three answer engines had cited and placed structured data third of its six reported pillars, behind metadata freshness and semantic HTML. Lantad did not run that study, collect those citations or score those pages, and it concerns structured data as a whole rather than Event in particular.

Google's own position is the plainest available source and it is not an endorsement. The AI features page states that there are no additional requirements to appear in AI Overviews or AI Mode and no other special optimisations necessary, and adds that you do not need to create new machine readable files, AI text files or markup to appear in these features, and that there is no special schema.org structured data you need to add. Read alongside the Event documentation, which describes one search appearance with four required properties and a single event page constraint, the honest summary is that Event markup is a rich result feature with a documented shape, and that no vendor documents reading it for an answer. Lantad's own scoring agrees by omission rather than by judgement: SCHEMA_REQUIREMENTS in core/src/schema.ts recognises five types, Organization, Product, Article, FAQPage and BreadcrumbList, and Event is not one of them, so a Lantad scan says nothing about it. That is a decision about scope, not a finding about value.

What a reader can usefully take from this is a short sequence of checks on their own events pages, each of which is answerable from the bytes a crawler receives. Does the events page carry JSON-LD at all. Does each node type resolve to Event rather than to a phrase. Does it carry a name, a startDate, and a location typed Place with an address typed PostalAddress. Does the start date carry a time and an offset. Is the date still in the future. The first of those is visible with what GPTBot sees and the rest by reading the block it returns. The crawler's conduct in this run is set out at the bot policy and the reading rules at methodology, and the wider sampling frame is described in the crawlability study.

The method, for anyone reproducing it. One request per hostname to https://host/robots.txt as LantadBot/1.0, parsed with this scanner's own parser and evaluated for the LantadBot token at the site root; 13 hosts disallowed it and were dropped. One request to https://host/ on the rest, redirects followed, 20 second timeout, no JavaScript executed, no stylesheet fetched, from a single network location. Every JSON-LD block was extracted from the raw bytes, parsed with JSON.parse and walked to a depth of 64 so a node inside an @graph is found. Each reachable home page was then scanned for a same host link whose path names events, calendar, agenda, exhibitions, conferences or a local language equivalent, or whose anchor text does; up to three per site were requested, each evaluated against that site's robots.txt first, stopping at the first page that carried an Event node. 442 nodes on 21 pages were analysed. The figures describe this corpus on this day and nothing beyond it, and the corpus is an editorial frame rather than a random sample of the web, which is the same caveat that applies to 429 of 615 home pages naming no language in their JSON-LD.