Event Schema Markup for Search-Ready Event Pages
A practical guide to event schema markup: required properties, a working JSON-LD example, common mistakes, and how to validate your structured data for event rich results.
On this page
Event pages have a short shelf life and a specific job: get someone to show up. Structured data is how you tell Google, Bing, and assistants the four things they need to render an event result: what it is, when it starts, where it happens, and how to attend. Get those right and your listing can appear with a date, venue, and ticket link attached, which is a lot more useful than a blue link on its own.
This is a supporting topic under the broader subject of what schema markup is. Here I want to stay narrow and cover the Event type specifically: the properties that matter, a copy-ready example, the mistakes that get pages disqualified, and how to check your work.
What event schema markup describes
The schema.org Event type covers "an event happening at a certain time and location, such as a concert, lecture, or festival." Ticketing details attach through the offers property. According to schema.org's own usage data, the Event type appears on roughly 100K to 1M domains, so it is well-established vocabulary that the major engines recognize.
Event markup can be used across a wide range of formats. Search Engine Watch's guide to event schema lists business events, courses, dance and music events, exhibitions, festivals, food events, hackathons, screenings, sports events, and theater events, among others. You can also connect a series of related events. What you should avoid is marking up things that are not events at all.
Required properties and eligibility
An event record starts with the three core properties below. For Google eligibility, the location also needs a detailed physical address:
- name: the full event title, without prices or promotional text baked in
- startDate: the start date and time in ISO 8601 format, in the local timezone; if you do not have an exact time, leave it off rather than guessing
- location: for physical events, a
Placewith a venue name and a detailed address
Recommended properties add context once the required event and address fields are complete.
The optional properties worth adding
These are not required, but they let more detail surface and reduce ambiguity for engines and assistants:
| Property | Why it helps |
|---|---|
endDate | Signals duration; useful for multi-day conferences and festivals |
eventAttendanceMode | Marks the event as online, offline, or mixed; critical for virtual events |
eventStatus | Communicates scheduled, cancelled, postponed, rescheduled, or moved-online states |
offers | Ticket URL, price, currency, and availability |
performer | The act, speaker, or group appearing |
organizer | Who is running the event |
image | Gives the result a visual |
description | Plain-language summary for users |
On eventStatus, Rank Math's event schema documentation spells out the practical workflow: if an event is postponed to an unknown date use the postponed status, and once you have a new confirmed date switch it to rescheduled and update startDate and endDate. Keeping that field current is how you avoid sending people to a cancelled show.
A worked JSON-LD example (hypothetical)
Here is a complete, illustrative example for a made-up in-person event. Values are invented for demonstration. Adjust the timezone offset, currency, and dates to your own.
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Coastal Sound Festival 2026",
"startDate": "2026-10-18T18:00:00-07:00",
"endDate": "2026-10-18T23:00:00-07:00",
"eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
"eventStatus": "https://schema.org/EventScheduled",
"location": {
"@type": "Place",
"name": "Harbor Green Amphitheater",
"address": {
"@type": "PostalAddress",
"streetAddress": "400 Marina Blvd",
"addressLocality": "San Diego",
"addressRegion": "CA",
"postalCode": "92101",
"addressCountry": "US"
}
},
"image": ["https://example.com/events/coastal-sound.jpg"],
"description": "An outdoor evening of live coastal-inspired music with four acts.",
"offers": {
"@type": "Offer",
"url": "https://example.com/tickets/coastal-sound-2026",
"price": "45.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"validFrom": "2026-09-01T09:00:00-07:00"
},
"performer": {
"@type": "MusicGroup",
"name": "The Tidewater Trio"
},
"organizer": {
"@type": "Organization",
"name": "Harbor Events Co.",
"url": "https://example.com"
}
}
A few details in that block do heavy lifting. The country code uses the two-letter ISO 3166-1 alpha-2 format (US), which Rank Math flags as a common requirement. The currency uses an ISO 4217 code (USD). The price field carries only the number with no symbol. Follow those conventions and validators stay quiet.
For a Schema.org description of an online event, VirtualLocation can describe attendance details. Google?s current event guidelines exclude virtual-only experiences from its event search feature and require a physical location. Events must also be publicly bookable. Use the following fragment as a vocabulary example; it does not establish Google event eligibility:
"eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
"location": {
"@type": "VirtualLocation",
"url": "https://example.com/livestream/coastal-sound"
}
One event, one page
Search Engine Watch is direct on this: Google only supports event rich results for pages that feature a single event. If your calendar dumps twenty listings onto one URL, give each event its own crawlable page and mark that page up. Also confirm your robots.txt and robots meta tags allow Googlebot to reach those pages, since a blocked page will never qualify no matter how clean the JSON-LD is.
If you want the mechanics of adding this to a live site, whether by hand in the <head>, through a plugin, or via a tag manager, our walkthrough on how to implement schema markup covers the priority order and the validation loop. If you are weighing JSON-LD against Microdata or RDFA, the format templates guide shows the same markup three ways. JSON-LD is the format Google recommends and the one used above.
Mistakes that get event pages disqualified
- Marking up non-events. Search Engine Watch warns that tagging business hours, coupons, limited-time discounts, or vacation packages as events risks disqualifying your entire site from event rich results. Reserve the type for real occurrences.
- Missing a required property. No
location, no validstartDate, or nonamemeans no eligibility. Validators catch these immediately. - Stale status. A cancelled show still marked
EventScheduledsends people to a closed door. UpdateeventStatusandpreviousStartDatewhen plans change. - Prices in the name. Keep promotional copy and ticket prices out of the
namefield. - Timezone drift. Use the local timezone offset in your ISO dates so the displayed time matches the actual start.
Test, then trust the data
Before you consider a page done, run it through Google's Rich Results Test and the Schema.org validator. The former checks Google's supported rich-result requirements; the latter checks Schema.org vocabulary and syntax. A clean vocabulary check can coexist with a feature-eligibility failure. Fix errors first, inspect the published URL in Search Console, then monitor indexing and enhancement reports after recrawling.
About results: structured data makes a page eligible for the event enhancement, and eligibility is not the same as a guaranteed appearance. Our piece on whether schema moves rankings or just pixels unpacks the evidence, including Eventbrite's reported year-over-year traffic gains after implementation. Treat those numbers as one company's experience and measure your own.
Event markup is also increasingly how assistants and AI answer engines read your listings, which is the terrain our AI search optimization service is built for. If you want to skip hand-coding the JSON-LD, our schema generator is another structured-data resource to explore alongside this Event example. Either way, the goal stays the same: give machines a clean, current, unambiguous record of who is performing, when, where, and how to buy a ticket.
