· 5 min read
How to Build Event Markup That Validates
Heshan Fernando
Co-founder & COO
An event listed for 10:00 shows in search results at 05:00 for some people and 15:00 for others.
The start date was written without a time zone offset. Every consumer of that markup interpreted it in whichever zone they defaulted to, and none of them were wrong to.
Dates need an offset
startDate should be ISO 8601 with an explicit time zone offset:
2026-10-03T10:00:00+01:00
Not 2026-10-03 10:00, not 3 October 2026, 10am, and not an ISO string with no offset.
A date without an offset is ambiguous, and there is no safe default for a consumer to assume. Search engines, calendar applications and aggregators each make their own choice, and the results diverge.
endDate matters too. Omitting it limits how the event can be displayed and means a consumer cannot tell whether the event has finished, which affects whether it is still shown.
For a multi-day event, startDate and endDate span the whole thing, and individual sessions are separate Event items if they need to be listed.
Attendance mode and status became required distinctions
Two properties added importance when online events became common, and both are frequently omitted.
eventAttendanceMode distinguishes physical, online and hybrid events. Without it, consumers infer from whether a location or a URL is present, and the inference is often wrong — a physical event with a livestream URL is not an online event.
eventStatus covers scheduled, postponed, rescheduled, moved online and cancelled. This is what lets a cancelled event remain listed with the cancellation visible.
| Property | Values |
|---|---|
| eventAttendanceMode | Offline, Online, Mixed |
| eventStatus | Scheduled, Postponed, Rescheduled, Cancelled, MovedOnline |
Do not delete a cancelled event
The instinct on cancelling is to remove the page. That is the wrong move.
Someone searching for the event finds a stale result pointing at a 404, learns nothing, and may still turn up. Search engines take time to drop the old result, during which it is actively misleading.
Setting eventStatus to cancelled and keeping the page — with the cancellation stated clearly in the visible content, not only in the markup — means the search result carries the cancellation. That is the outcome you want.
The same applies to postponement: set the status, update the dates when known, and keep the page.
Offers and the visible page
If tickets are sold, offers carries price, currency, availability and a URL. This is what makes an event rich result useful rather than decorative, and it is worth including even for free events, where price is zero.
The overriding rule remains: the markup must describe what is visible on the page. An event page with markup listing a price the page does not show, or a location it does not state, is a policy violation regardless of accuracy.
That includes the dates. If the markup says 10:00 and the page says 10:30, the markup is wrong even if the markup is right.
Recurring events need separate items
A weekly class is not one event, and marking it up as one produces a result that is wrong every week but the first.
Schema.org supports event series, and support for them across consumers varies. The reliable approach for a recurring event is separate Event items for each occurrence, each with its own dates and its own URL.
That is more markup and it renders correctly. A single Event with a start date months ago is treated as a past event and stops appearing.
Where generating individual occurrences is impractical, marking up the next few and updating them on a schedule is better than one perpetual entry. The pages need to exist for each occurrence anyway, since markup must describe what is on the page.
Common mistakes to avoid
- Dates without a time zone offset.
- Omitting eventAttendanceMode and letting consumers infer it.
- Deleting a cancelled event’s page rather than setting its status.
- Marking up an event with details the page does not display.
- Using a single Event for a recurring series rather than separate items or a proper recurrence structure.
How to do it with Event Schema Builder
The Event Schema Builder enforces the date format.
- Enter the event details with dates in ISO 8601 including the offset.
- Set attendance mode and status explicitly rather than leaving them out.
- Include offers if tickets exist, even free ones.
- Check every property against what the page actually shows.
Google’s event structured data documentation lists required and recommended properties. Other SEO tools are in the tools directory.
Frequently asked questions
Why does the date format matter so much?
Because a date without a time zone offset is ambiguous, and every consumer resolves it differently. An event listed in the wrong time zone is worse than one not listed at all.
What is eventAttendanceMode for?
Distinguishing physical, online and hybrid events. Omitting it means search engines infer from the location field, and a physical event with a livestream link is frequently misclassified.
Should a cancelled event be removed?
No. Set eventStatus to cancelled and keep the page with the cancellation visible. Deleting it leaves a stale search result pointing at nothing.
Final thought
Put the offset on every date. It is four characters and it is the difference between an event listed correctly and one listed five hours out.