What Is Event Schema?

The Event type covers concerts, conferences, workshops, festivals, sports and other scheduled experiences, with more specific subtypes available. One canonical leaf page should describe one event or performance in enough detail for a person to decide whether and how to attend.

Markup does not turn business hours, discounts, travel packages or ordinary product availability into events. It cannot verify that tickets exist, force a search feature or rescue inaccurate dates and venues. Every structured fact must match the visible event and operational systems.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Model one real scheduled event.
• Use operational dates, venue and status.
• Connect only genuine tickets and organizers.

Primary specification: Schema.org definition for Event.

Event schema is a machine-readable schedule for a genuine attendable experience, not a promotional wrapper for products or recurring business activity.

A parser reads the name, start time and location, then evaluates supporting properties such as image, description and offers. A physical venue uses Place and PostalAddress. Schema.org also defines VirtualLocation and mixed attendance, although individual search features can support a narrower subset.

Syntax validation cannot prove the venue is booked, the organizer authorized the listing or a ticket remains available. Event, venue and ticketing systems must stay synchronized. Updates should change status and schedule without silently replacing the event identity.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm a single public event.
2. Assign canonical identity and schedule.
3. Map venue and attendance mode.
4. Connect organizer and ticket source.
5. Maintain status through completion.

The graph works when one stable event entity mirrors the schedule, access and status users see on the canonical page.

The event name should contain the actual title rather than generic labels, prices, URLs or calls to action. Date values need ISO 8601 formatting and a timezone offset when time is known. A physical Place should include the venue name and complete address.

Use the most specific truthful event subtype. Connect the organizer through the business identity described in Organization schema. Optional data is useful only when it stays synchronized with the registration and scheduling source.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use a unique descriptive event name.
• Publish exact timezone-aware dates.
• Verify venue and ticket access.

Prioritize specific identity, time and place before enriching an event with media, participants and ticket details.

Timezone handling is essential for US events because daylight saving rules can change the offset. The schedule source should store a time-zone identifier and generate the correct offset for the event date rather than hardcoding a winter offset for a summer event.

A multi-day event can use one start and end when admission covers the continuous program. Separate performances with distinct tickets or attendance choices should use separate Event entities. Do not use an all-day date when the event has a known public start time.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Store the event’s local time zone.
2. Generate the correct date-specific offset.
3. Separate distinct ticketed performances.
4. Preserve previous dates on reschedule.
5. Test displayed and structured time together.

Accurate timezone-aware dates let users understand when the event occurs and prevent schedule ambiguity across regions and daylight changes.

An online webinar can still be modeled semantically as an Event with OnlineEventAttendanceMode and a controlled access location. A hybrid conference can include both a Place and VirtualLocation with MixedEventAttendanceMode. Keep private access URLs out of public markup when registration is required.

Search consumers differ. Generic schema validity does not establish eligibility for every event experience. Teams should document why they maintain online event markup and measure actual discovery rather than repeating outdated screenshots or unsupported CTR forecasts.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Model actual attendance mode.
• Protect private streaming access.
• Never equate valid schema with feature eligibility.

Use accurate online or mixed Schema.org modeling, while separating semantic validity from the physical-location rules of a specific search feature.

A free event can use a zero price when registration or attendance is genuinely free. A waitlist is not InStock, and a sold-out event should update availability promptly. Multiple ticket tiers can be represented when the page and consumer support them without mixing benefits or dates.

Do not put promotional phrases in the event name. Early-bird pricing needs valid dates and replacement when it expires. Ticket URLs should reach the specific event offer rather than a generic homepage, broken checkout or private administrative route.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the public ticket inventory.
2. Set price, currency and availability.
3. Connect the event-specific checkout.
4. Expire promotional offers on time.
5. Test registration from a clean session.

Offer markup is useful only when price, availability and registration destination describe the ticket a user can actually obtain.

Cancellation does not always require deleting the page. Keeping the canonical event page with EventCancelled can help ticket holders understand what happened. Postponed events may lack a new date; communicate uncertainty visibly instead of inventing a placeholder schedule.

When a date changes, retain the same event identity and use previousStartDate where appropriate. If the venue or attendance mode changes, update location and access details together. Ticket refunds and new registration terms belong in visible user guidance.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Keep the canonical event identity stable.
• Update status, date, venue and tickets together.
• Preserve clear attendee guidance.

Status markup should preserve event identity and communicate the exact operational change users need to act on.

Calendars often generate one Event node on a list page and another on the detail page with different IDs. Recurring series can collapse many independently ticketed dates into one range. Ticket platforms and organizer sites may also disagree about price, status or venue.

Events must be real and publicly attendable under the applicable feature rules. Membership-only, invitation-only or misleading listings should not be promoted as generally bookable. Validation cannot prove admission, authorization or operational status.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm each item is a genuine event.
2. Reconcile names, dates and time zones.
3. Verify venue, attendance and offers.
4. Separate independently ticketed occurrences.
5. Test cancellation and reschedule states.

Event markup fails when the scheduled experience, time, place, access or lifecycle is false, fragmented or stale.