What Is Event Schema Markup?
The only common type whose subject stops existing on a known day. That single fact changes what matters about it, making maintenance the whole subject rather than a caution added at the end.
Everything It Describes Expires
Every other type in this section describes something ongoing: a business, a page, a product, a person. An event stops existing on a date you already know, which changes what you should plan for.
Why the difference is structural. Truth has a deadline.
Most markup is true until circumstances change. This markup is true until a specific day, after which it is false regardless of whether anything else changed.
What that permits. Scheduling the removal.
Because the expiry date is known when the event is created, the update can be planned at the same time. That is an advantage this type has over anything else that goes stale.
What actually happens. Nobody plans it.
The event is published, it happens, everybody moves on to the next one. The description stays behind. By the third or fourth event there is a small pile of them.
Why nobody notices. Attention moves forward.
The team is focused on the next event rather than tidying the last. Nothing prompts a look back and nothing reports a problem, so the accumulation is silent.
What this page is therefore mostly about. Housekeeping.
The properties matter less than the process. An organisation that will not maintain this is better off not implementing it, which block six covers.
What It Asserts
Name, date, time, location, availability and cost where relevant. Two of those go wrong far more often than the rest. They are also the two everything else depends on.
Name and description. What it is.
The title and a summary of what happens. Stable, rarely wrong, being the least interesting part of the description.
Date and time. The property that expires.
When it starts and ends, including time zone where that matters. This is the value that makes the whole description true or false. It is also the one nobody revisits.
Location. Where, else where online.
A venue address, a joining arrangement, else both. Block four covers the distinction, which is expressed explicitly rather than left to be inferred.
Availability. Whether tickets remain.
Whether places can still be booked. This changes continuously in the days before an event and is the second property that regularly misleads people.
Cost. Where it applies.
What attendance costs, else that it is free. Stated as a property rather than an estimate, subject to the same accuracy rule as anything else asserted about money.
Past Events Are Stale Assertions
Markup left in place after an event is asserting something untrue. It accumulates on sites running regular events, needing a process rather than good intentions.
What the false claim is. That this is happening.
The description says an event takes place at a time and place. Once that time has passed, the site is stating something that did not survive its own date.
Why accumulation is the real issue. One becomes twenty.
A single expired event is untidy. An organisation running monthly events for two years, with nobody removing anything, is making a substantial number of false statements simultaneously.
What that does to the site. Dilutes the real ones.
A site describing twenty events where one is genuinely forthcoming has made its actual event harder to identify among nineteen that are over.
Why intentions fail here. The prompt never comes.
Nothing alerts anybody. The date passes quietly, the page still loads and the team is already working on the next thing.
What works instead. Decide at creation.
When the event is published, decide what happens to the page afterwards. That is the one moment somebody is thinking about this event, making it the only reliable time to decide.
Online, In Person Or Both
The vocabulary distinguishes events people attend, events people join remotely and events that are both. Getting this wrong misleads attendees in a way that costs them a journey.
Why it became prominent. Remote attendance stopped being unusual.
Online and hybrid events moved from rare to routine, so the description had to keep up. What was once assumed to mean a physical gathering can no longer be assumed at all.
What each means. Three distinct claims.
Attend in person at a place. Join remotely from anywhere. Or both, with a venue and a joining arrangement running together. Each is a different promise to somebody deciding.
The failure that costs somebody. Travelling to an online event.
An event described as having a location, which is actually online, gives somebody an address to arrive at. That is the same category of harm the local business page describes about opening hours.
The opposite failure. Missing an in-person event.
Somebody who believed they could join remotely and discovers on the day that they cannot. Less dramatic and equally avoidable.
What hybrid requires. Both sets of detail.
A venue for those attending and joining information for those who are not, described together rather than choosing one and mentioning the other in passing.
Cancelled And Rescheduled
Statuses exist for cancelled, postponed and rescheduled events. These are the correct way to handle a change. Deleting the page is not the same thing at all.
What the statuses do. State what happened.
Rather than leaving the description saying an event is going ahead, they say it was cancelled, moved or postponed. That is accurate rather than merely absent.
Why deletion is worse. Somebody is looking for it.
People who booked, people who saw it advertised and people who heard about it all go to the page. Removing it leaves them with nothing, which is the worst outcome for the one group who cares most.
What a cancelled page should say. Plainly, what happened.
That it is cancelled, why if you can say, then what happens about refunds or rebooking. The markup describes the status and the page answers the question.
What rescheduling involves. Two facts.
The original date, marked as moved, plus the new date it moved to. Both stated, so somebody holding the old date finds the new one rather than a contradiction.
Why almost nobody does this. They are not the obvious response.
The instinct on cancelling something is to take it down. Using the status instead takes a moment longer and serves everybody who was expecting to attend.
Who This Genuinely Suits
Organisations running events as a regular part of what they do. A business with an occasional event should not bother. That is a recommendation rather than a caution.
Venues. The clearest case.
Somewhere whose entire business is things happening on dates. The process already exists because the events do, so describing them adds little effort.
Training providers. Scheduled courses.
Where courses run on published dates with places to book. The information is already maintained for booking purposes and describing it is nearly free.
Membership bodies and schools. Recurring occasions.
Meetings, talks, open days and terms. Our schools material covers the open day case, where parents are genuinely searching for dates.
Businesses running workshops. If regularly.
Where workshops are a real strand of the business rather than something attempted twice. The test is whether there is a next one already planned.
Who should not bother. Everybody else.
A business holding one event a year will implement this, fail to maintain it and be left asserting something false for eleven months. Not implementing it is better than that.
Ticketing Platforms Assert It Too
An event listed on a ticketing platform is already described there. Your own description makes two. Where they differ, the event is being asserted twice with conflicting details.
What the platform does. Describes it thoroughly.
Ticketing platforms describe events comprehensively, because that is their entire purpose. Date, venue, availability and cost are all stated by them already.
Where the conflict arises. Updates in one place.
A time changes and gets corrected on the platform, since that is where bookings happen. The site keeps the original, so two descriptions of one event now disagree.
Why that is worse than one being wrong. Nothing resolves it.
Two authoritative-looking descriptions with different times leave somebody guessing which is right. That is the same problem the platform page describes about duplicate sources.
What to decide. Which one is authoritative.
Either the platform holds the detail and your page points at it, else your page holds it and the platform reflects your dates. Choosing prevents the drift.
The simpler answer for many. Let the platform do it.
Where bookings happen there anyway, describing the event yourself adds a maintenance burden for little gain. The troubleshooting page covers finding conflicting sources.
Decide at
publication, not
afterwards.
The expiry date is known the day an event goes live, which makes it the one moment somebody is thinking about it. Nothing will prompt you later: the date passes quietly, the page still loads and the team is already working on the next thing.
On every page we build:
If you run one event a year, we will tell you not to bother with this.
Every guide.
One practice.
What structured data is, which types apply to your business, how to test it, where the results features come from and what to do when nothing appears.
