Event Schema

TL;DR — Event schemaEvent schema (schema.org/Event) is structured data that tells search engines an event's name, date, location, and ticket info so the page can appear in Google's event rich results. Google requires a physical location — virtual-only events aren't eligible for the event rich result. is code you add to an event page that labels the event details for search engines — “this is the event name,” “this is when it starts,” “this is where it’s held,” “here’s how to get tickets.” Adding it correctly to an individual event page can make it eligible for Google’s richer event listings. The catch most guides get wrong: Google’s event rich result needs a real, physical location — a purely online-only event isn’t eligible, no matter how you mark it up.

What Event schema is

When you look at an event page, you can tell the event name from the date from the venue just by reading. A search engine sees plain text and has to guess. Event schema spells it out in code, using the shared schema.org vocabulary — it tags each piece of the page with what it actually is: the name of the event, the startDate, the location, ticket offers, who’s performing, and who’s organizing.

It’s almost always written as JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — a small block of code that sits in the page without changing how the page looks.

Why it’s worth doing

The payoff is the event rich result: the enhanced, visually rich listing (and the dedicated event-search experience) Google shows for event-related searches. A page with clean Event markup can earn a more eye-catching listing that shows the date, venue, and ticket info right in the results — which can help it stand out. The same structured markup gives AI systems a cleaner, unambiguous read on the event’s details too, though I don’t have data showing that reliably translates into more AI-sourced traffic or citations for any particular event page.

The three things you must have

To be eligible at all, Google requires exactly three properties:

• name — the full title of the event (not the venue, and not a promo like “50% off tickets”).
• startDate — when it starts, with the date and time.
• location — where it’s held, as a Place with a name and an address.

Beyond those, it’s worth adding the recommended details — an endDate, an image, ticket offers (price, currency, availability), the performer, and the organizer — because they make the listing richer and more useful.

The thing most people get wrong

A purely virtual, online-only event isn’t eligible for Google’s event rich result. Google’s current documentation is blunt about it: events “must take place in a physical location.” A lot of advice still floating around from 2020 — when Google added online-event properties during the pandemic — makes it sound like flipping an “online event” switch is enough. It isn’t, for Google’s rich result. Those online-event properties still exist and are valid, but on their own they don’t get a webinar into the event experience.

Two more beginner traps:

• One event, one page. Mark up individual event pages — not a page that lists all your upcoming events. A listing/calendar page doesn’t qualify.
• Valid markup ≠ guaranteed rich result. It makes you eligible; Google still decides whether to display it.
• Don’t fake events. Marking up a sale, a coupon, or your business hours as an “event” is against Google’s rules and has gotten sites in trouble.

Want the full version — the required-vs-recommended property split, how to handle canceled and postponed events, multi-day vs. multi-performance events, and the content rules that get events disapproved? Switch to the Advanced tab.

TL;DR — schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./Event markup (usually JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) on an individual event page can make it eligible for Google’s event rich result. Google requires three properties: name, startDate, location. The load-bearing fact of this whole topic: per Google’s current (Dec 2025) docs, virtual-only events aren’t supported — “Events must take place in a physical location.” eventAttendanceMode and VirtualLocation are valid schema.org (added in the 2020 COVID era) but don’t unlock the rich result for an online-only event. Other rules people miss: one event = one unique leaf URL (listing pages don’t qualify); when you change eventStatus (EventScheduled / EventCancelled / EventPostponed / EventRescheduled) you must never strip startDate or location; multi-day is one Event, multiple ticketed performances are separate Events; and marking up sales, coupons, or non-events is against policy and has drawn manual actions. Valid markup only earns eligibility.

What Event schema does — and what it doesn’t

Event schemaEvent schema (schema.org/Event) is structured data that tells search engines an event's name, date, location, and ticket info so the page can appear in Google's event rich results. Google requires a physical location — virtual-only events aren't eligible for the event rich result. is the schema.org/Event vocabulary you put on an event page so search engines can read the event’s name, timing, location, and ticketing. On Google, correctly implemented markup on an individual event page makes it eligible for the event rich result — the enhanced listing and the dedicated event-search experience Google runs for event-related queries.

What it doesn’t do: it isn’t a ranking factor, and it isn’t a magic switch. Like every kind of structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., it makes a page eligible for a specific search feature — it doesn’t lift your organic positions and it doesn’t guarantee the feature shows. Evidence for this claim Google's event feature excludes promotional non-events and requires each event to have a unique page focused on that event. Scope: Google Search Event content guidelines; valid Schema.org markup alone does not establish eligibility. Confidence: high · Verified: 2026-07-14 Google: Event structured data

Required properties: name, startDate, location

Google is explicit that you must include the required properties: “You must include the required properties for your content to be eligible for display in enhanced search results.” For Event, that’s three:

• name (Text) — the full title of the event. Google’s rule is specific: don’t use the name of the venue as the event name (that’s what location.name is for), don’t use the type of event (“Concert” is not a descriptive name), and don’t stuff it with URLs, prices, performers, or “short-term promotions (for example, ‘buy your tickets now’).” Google’s own before/after: not “Bill Graham Civic Auditorium” and not “LIMITED TIME SALE - Kesha and Macklemore Concert - $25”, but “The Adventures of Kesha and Macklemore” or “Meet and Greet: Kesha and Macklemore.”
• startDate (DateTime) — “The start date and start time of the event in ISO-8601 format. Add both the date and time so users can find events that fit into their schedule.”
• location (Place) — set @type to Place and add location.name and location.address. Google’s steer on the address: be specific — not just “Sydney” but “Bennelong Point, Sydney NSW 2000, Australia.” And its best-practice notes for tricky cases: “If the event happens across several streets, define the starting location and mention the full details in description. If the event happens without a well-defined location, use the city name or the most representative location. If the event happens at multiple locations at the same time, create different events for each location.”

Recommended properties that improve the result

Beyond the required three, these make the listing fuller and are worth adding:

• endDate — same ISO-8601 format as startDate.
• eventStatus — the scheduled/canceled/postponed/rescheduled state (see the dedicated section below).
• image — Google’s general image guidance applies; provide multiple images at 1x1, 4x3, and 16x9 aspect ratios.
• offers (an Offer) — url, price, priceCurrency, availability (e.g. InStock, SoldOut, PreOrder), and validFrom for when tickets go on sale.
• performer (Person / PerformingGroup) and organizer (Organization / Person, with name and url).
• description — Google’s guidance: “Focus on the event details and not your site’s features. Don’t repeat other facts like date and location; instead, add that information to the respective properties.” Note it only shows a snippet.

Virtual and hybrid events: what Google’s current docs actually say

This is the section that separates current guidance from the recycled 2020 advice still all over the web, so read it carefully.

Google’s current documentation states, verbatim: “Virtual experiences that have no real-world component aren’t supported. Events must take place in a physical location.” That means a purely virtual, online-only event has no path into Google’s event rich result — regardless of how you mark it up.

Here’s the nuance that trips people up. Back in March 2020, at the start of the pandemic, Google announced new Event properties so publishers could communicate that events had moved online or been canceled: an eventAttendanceMode (with OnlineEventAttendanceMode / OfflineEventAttendanceMode / MixedEventAttendanceMode values), the eventStatus values, and support for VirtualLocation. Those properties are still valid schema.org vocabulary — nobody removed them. But the current Search Central Event doc no longer documents an online-event example and states outright that virtual-only events aren’t supported for the rich result.

So the honest, current position:

• A physical location is the anchor. Virtual and hybrid events likely still need a real-world location component to qualify for the event experience — because Google requires that physical location.
• eventAttendanceMode and VirtualLocation aren’t useless — they’re legitimate markup for a hybrid event that does have a real venue, and they’re useful for other consumers of the data (your own systems, other search engines, and AI/LLMA large language model (LLM) is a deep-learning model trained on massive text corpora to predict the next token and generate human-like text. LLMs use the transformer architecture and power AI search features like Google's AI Overviews (Gemini) and Bing Copilot (GPT-4). understanding). They just don’t, by themselves, get an online-only event into Google’s rich result.
• If you run webinars or online-only events, don’t expect the event rich result. Use the markup for machine-readability if you like, but plan your visibility around the rest of your SEO, not the event experience.

I want to be precise here rather than sensational: this is not “virtual events are banned.” It’s that a virtual event with no real-world component isn’t eligible for the specific event rich result. Most of the competing content on this topic still treats OnlineEventAttendanceMode as a live Google feature that gets an online event into the rich result on its own. Straight from Google’s current docs, that’s not how it works.

Handling event status: EventScheduled, EventCancelled, EventPostponed, EventRescheduled

eventStatus takes one of four values, and there’s one rule that dwarfs the rest: never remove startDate or location when the status changes. Google warns: “When the event status changes, DON’T remove the startDate. The startDate property is required to help identify the unique event.”

If you don’t set eventStatus at all, Google treats the event as EventScheduled (the normal, going-ahead state). The other three:

• EventCancelled — the event won’t happen. Google: “Don’t remove or change other properties (for example, don’t remove startDate or location); instead, keep all values as the same as they were before the cancelation, and update the eventStatus to EventCancelled. Why? Properties like startDate and location help identify the unique event and make sure people understand the new status of the event.”
• EventPostponed — it will happen, but the new date isn’t known yet. Google: “The event has been postponed to a later date, but the date isn’t known yet. Keep the original date in the startDate of the event until you know when the event will take place. Once you know the new date information, change the eventStatus to EventRescheduled and update the startDate and endDate with the new date information.”
• EventRescheduled — a new date is confirmed. Google: “The event has been rescheduled to a later date. Update the startDate and endDate with the relevant new dates. Optionally, you can also mark the eventStatus field as rescheduled and add the previousStartDate.”

The distinction people most often blur: EventPostponed and EventCancelled are not interchangeable. Cancelled means it’s off; postponed means it’s happening later on a date you don’t know yet — and you should upgrade postponed to rescheduled (with previousStartDate) once you do know.

One event, one URL — why listing pages don’t qualify

Google is unambiguous: “Each event MUST have a unique URL (a leaf page) and markup on that URL,” and “The event experience on Google only supports pages that focus on a single event. We recommend focusing on adding markup to your event posting pages instead of pages that list schedules or multiple events.”

This is one of the most common implementation mistakes for venues and ticketing platforms — marking up a calendar or “upcoming events” listing page and expecting a rich result for each event on it. That page doesn’t qualify. Each event needs its own dedicated page with its own markup.

Multi-day events vs. multiple performances

These are handled differently, and it trips up a lot of implementations:

• A single event that spans several days → one Event with the startDate and endDate covering the range. Google: “If your event or ticket info is for an event that runs over several days, specify both the start and end dates of the event.”
• Multiple distinct ticketed performances across days → a separate Event for each. Google: “If there are several different performances across different days, each with individual tickets, add a separate Event element for each performance.”

For genuinely recurring series, schema.org has EventSeries and eventSchedule properties. They’re valid markup — but I’d treat them as “valid schema.org, unconfirmed rich-result impact” rather than a guaranteed path to the event experience. When in doubt, follow Google’s documented pattern: one Event per performance.

Content policies — what gets events disapproved (and manually actioned)

Event markup has a real spam-enforcement history, so this isn’t hypothetical. Google requires that “Each event must accurately describe the event name, start date, and location,” and it spells out what not to mark up as an event:

• Non-events. Google: *“Don’t promote non-event products or services such as ‘Trip package: San Diego/LA, 7 nights’ as events. Don’t add short-term discounts or purchase opportunities, such as: ‘Concert — buy your tickets now,’ or ‘Concert
  • 50% off until Saturday.’ Don’t mark business hours as events, such as: ‘Adventure park open 8 AM to 5PM.’ Don’t mark coupons or vouchers as events, such as: ‘5% off your first order.’”*
• Membership/invitation-only events. Google: “Events must be bookable to the general public. Events that require a membership, or invitation prior to purchasing the ticket or attending the event are ineligible for the event experience.”
• School/minors on-premise events. Google: “Spectator events where the primary participants and audience are minors and occur on-premise of a school aren’t eligible for the event experience.”

And there are teeth behind this. Google: “If your site violates one or more of these guidelines, then Google may take manual action against it. Once you have remedied the problem, you can submit your site for reconsideration.” This isn’t theoretical — Google was reported to have issued manual actions against sites using Event markup to promote sales and coupons rather than genuine events, which is exactly the “don’t add short-term discounts” and “don’t mark coupons as events” guidance above. (I’d verify the specifics against a primary source before treating any particular case as canonical — the enforcement pattern is well established regardless.)

Date and time formatting

Use ISO-8601, and include the timezone offset. Google’s guidance: specify the timezone by including the UTC/GMT offset — an event at 7pm on September 5 in New York should carry the -04:00 or -05:00 offset. For a genuinely day-long event where the hour is unknown or irrelevant, use the date only (no time). And don’t fake a midnight start: a value like 2019-08-15T00:00:00+00:00 for an event whose start time you don’t actually know reads to Google as literally midnight, which is almost certainly wrong.

Event subtypes: base Event vs. MusicEvent, BusinessEvent, etc.

schema.org has subtypes — MusicEvent, BusinessEvent, EducationEvent, SportsEvent, and more. You don’t have to use them: the base Event type is valid and sufficient, and Google’s documented required/recommended properties apply the same way regardless. Subtypes add more specific semantic tagging if you want it, but “you must use MusicEvent” is a myth — base Event is fine.

Bing and Event schema

Bing doesn’t publish an Event-specific structured-data help page the way Google does. Its general reference — Marking Up Your Site with Structured Data — confirms Bing supports the schema.org vocabulary broadly (along with Microdata, RDFa, and Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears.), without Event-specific required/recommended property lists. I’m not going to invent Bing Event support that doesn’t have a documentation page behind it. The honest framing: Bing rewards well-formed schema.org markup generally and won’t punish you for including Event schema, but it has no equivalent of Google’s dedicated event rich-result/search experience. So the primary motivation for Event markup remains Google — plus general machine-readability for AI/LLM consumption.

Validating and troubleshooting

Validate the markup with Google’s Rich Results Test, and monitor the Events report and enhancements in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. A note on regional availability: Google’s event search experience is available in a specific set of countries/languages, and that list changes — verify the current availability directly on Google’s docs page at the time you implement, rather than trusting a stale list.

Where this sits

Event schema is one of the Social & Community schema types in the broader structured-data picture, alongside markup like DiscussionForumPosting, FAQPage, HowTo, QAPage, and SoftwareApplication. For the vocabulary as a whole and how these pieces fit together, see the broader Schema MarkupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and Structured Data hubs this article nests under.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/Event markup (usually JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) on an individual event page that labels the event’s name, date, location, and ticketing so the page can qualify for Google’s event rich result and event-search experience.
• Required properties (three): name, startDate, location. name is the event title (not the venue, not the event type, no promos); startDate is ISO-8601 with date and time; location is a Place with a name and a specific address.
• The load-bearing myth-bust: per Google’s current (Dec 2025) docs, virtual-only events aren’t supported — “Events must take place in a physical location.” eventAttendanceMode and VirtualLocation are valid schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. (added March 2020, COVID era) but don’t get an online-only event into the rich result on their own. Hybrid/virtual events likely still need a real-world location component.
• One event = one unique leaf URL. Listing/schedule/calendar pages with multiple events don’t qualify.
• eventStatus (four values): default EventScheduled; EventCancelled (off), EventPostponed (happening later, date unknown), EventRescheduled (new date set, add previousStartDate). Never strip startDate or location when the status changes.
• Multi-day vs. multi-performance: a single multi-day event is one Event with startDate/endDate; multiple ticketed performances are a separate Event each. EventSeries/eventSchedule are valid but unconfirmed for the rich result.
• Content policy has teeth: don’t mark up sales, coupons, business hours, or other non-events; membership/invitation-only and school-minors-on-premise events are ineligible; violations can draw manual actions.
• Dates: ISO-8601 with timezone offset; date-only for day-long events; don’t fake a midnight start.
• Subtypes optional: base Event is valid and sufficient — MusicEvent, BusinessEvent, etc. add semantics but aren’t required.
• Bing: no dedicated Event doc; supports schema.org broadly; no event rich result. Primary motivation for Event markup is Google (plus AI/LLMA large language model (LLM) is a deep-learning model trained on massive text corpora to predict the next token and generate human-like text. LLMs use the transformer architecture and power AI search features like Google's AI Overviews (Gemini) and Bing Copilot (GPT-4). readability).
• Eligibility ≠ display: valid markup only makes the page eligible; Google still decides whether to show it.

Official documentation

Primary-source documentation from the search engines.

Google

• Event (Event) structured data — the authoritative reference: required/recommended properties, eventStatus, the one-event-one-URL rule, content policies, and the virtual-events statement. (Footer: “Last updated 2025-12-10 UTC.”)
• New properties for virtual, postponed, and canceled events (March 2020) — the COVID-era rollout of eventAttendanceMode, eventStatus, and VirtualLocation. Useful for understanding why so much virtual-event advice exists — and why the current docs have moved on.
• General Structured Data Guidelines — the site-wide structured-data policies (accuracy, no spam) that Event markup must also follow.
• Rich Results Test — validate Event markup and check rich-result eligibility.

Schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. (the vocabulary)

• schema.org/Event — the full Event type reference and its properties.
• schema.org/eventAttendanceMode — the online/offline/mixed attendance-mode property (valid vocabulary, not sufficient alone for Google’s rich result).
• schema.org/EventSeries and schema.org/eventSchedule — the recurring-series vocabulary (valid markup, unconfirmed rich-result impact).

Bing / Microsoft

• Marking Up Your Site with Structured Data — Bing’s general structured-data support (schema.org, JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal., Microdata, RDFa). Note: Bing has no dedicated Event structured-data documentation.

Quotes from the source

On-the-record statements from Google’s documentation. Each link is a deep link that jumps to the quoted passage on the source page.

Google — required properties

• “You must include the required properties for your content to be eligible for display in enhanced search results.” — Google Search Central, Event structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.. Jump to quote
• “The start date and start time of the event in ISO-8601 format. Add both the date and time so users can find events that fit into their schedule.” Jump to quote
• On the event name: “Not recommended: Bill Graham Civic Auditorium.” Jump to quote
• On addresses: “If the event happens across several streets, define the starting location and mention the full details in description.” Jump to quote

Google — virtual events (the accuracy spine)

• “Virtual experiences that have no real-world component aren’t supported. Events must take place in a physical location.” Jump to quote

Google — event status changes

• “Warning: When the event status changes, DON’T remove the startDate. The startDate property is required to help identify the unique event.” Jump to quote
• On cancellations: “Don’t remove or change other properties (for example, don’t remove startDate or location); instead, keep all values as the same as they were before the cancelation, and update the eventStatus to EventCancelled.” Jump to quote
• On postponement: “The event has been postponed to a later date, but the date isn’t known yet. Keep the original date in the startDate of the event until you know when the event will take place.” Jump to quote
• On rescheduling: “The event has been rescheduled to a later date. Update the startDate and endDate with the relevant new dates.” Jump to quote

Google — one event, one URL, and multi-day events

• “Each event MUST have a unique URL (a leaf page) and markup on that URL.” Jump to quote
• “Mark up multi-day events correctly: If your event or ticket info is for an event that runs over several days, specify both the start and end dates of the event.” Jump to quote

Google — content policies

• “Don’t promote non-event products or services such as ‘Trip package: San Diego/LA, 7 nights’ as events.” Jump to quote
• “Events must be bookable to the general public. Events that require a membership, or invitation prior to purchasing the ticket or attending the event are ineligible for the event experience.” Jump to quote
• “Spectator events where the primary participants and audience are minors and occur on-premise of a school aren’t eligible for the event experience.” Jump to quote
• “If your site violates one or more of these guidelines, then Google may take manual action against it.” Jump to quote

Event schema cheat sheet

The minimum for the event rich result

Event.name + startDate + location (a Place with name and address). Individual event pages only — one event per leaf URL.

Required vs. recommended

The four eventStatus values

Multi-day vs. multiple performances

Fast facts

• Format: JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. (recommended).
• Virtual-only events aren’t eligible for Google’s event rich result — physical location required.
• eventAttendanceMode / VirtualLocation: valid schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor., not sufficient alone.
• Never strip startDate/location when updating eventStatus.
• Base Event is fine — subtypes (MusicEvent, etc.) are optional.
• Bing: no dedicated Event docs, no event rich result.
• Valid markup = eligible, not guaranteed to show.

Is my event eligible for Google’s event rich result?

Work down the questions:

Event schema myths and mistakes to avoid

Myth: “Add eventAttendanceMode: OnlineEventAttendanceMode and your virtual-only event will show in Google’s event rich result.” False per Google’s current docs — virtual-only events with no physical component aren’t supported for the event experience, regardless of eventAttendanceMode or VirtualLocation. Those properties are valid schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and fine for hybrid events (which have a real venue) or non-Google consumers, but they don’t get a purely online event into Google’s rich result.

Myth: “You must use a specific subtype like MusicEvent or BusinessEvent instead of the base Event type.” Not required — the base Event type is valid and sufficient, and Google’s documented required/recommended properties apply the same way. Subtypes add semantics if you want them, nothing more.

Myth: “Cancelled or expired events should have their schema removed.” False, and explicitly warned against. Keep startDate and location in place and just update eventStatus to EventCancelled, EventPostponed, or EventRescheduled. Google needs those properties to identify the unique event and communicate the new status.

Myth: “You can mark up a page listing all your upcoming events and get a rich result for each one.” Unsupported — each event needs its own unique leaf-page URL with its own markup. Listing/schedule/calendar pages don’t qualify.

Myth: “Event schemaEvent schema (schema.org/Event) is structured data that tells search engines an event's name, date, location, and ticket info so the page can appear in Google's event rich results. Google requires a physical location — virtual-only events aren't eligible for the event rich result. is a ranking factor.” Overstated — like other structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., it makes a page eligible for a specific rich result; it isn’t a general organic-ranking signal.

Myth: “EventPostponed and EventCancelled are interchangeable.” They’re not. EventCancelled means the event is off; EventPostponed means it’ll happen but the new date isn’t known yet — and should be upgraded to EventRescheduled (with previousStartDate) once the date is confirmed.

Mistake: marking up a sale, coupon, or “limited time offer” as an event. Against policy — Google explicitly calls out short-term discounts, coupons, business hours, and non-event products/services as ineligible/violating. This has historically triggered manual actions.

Mistake: putting the venue name (or a promo) in the event name. The event name is the event’s title. Use location.name for the venue, and keep promos, prices, and “buy your tickets now” out of the name entirely.

Mistake: faking a start time. A value like 2019-08-15T00:00:00+00:00 for an event whose start time you don’t know reads as literally midnight. For day-long events with an unknown/irrelevant hour, use the date only — no time.

Tools for validating Event schema

• Schema Markup Validator — paste Event JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. or the full page to catch syntax, schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. vocabulary, and graph-reference problems before checking Google’s Event-specific requirements.
• Rich-Result Eligibility Checker — verify that the Event includes the required name, startDate, and physical location, then review missing recommended properties.
• Google Rich Results Test — test the deployed event URL with Google’s renderer and confirm the Event markup it actually detects.

Common Event schema issues

The markup validates, but the online event is not eligible

• Symptom — A virtual-only event has valid schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. markup but no eligible Google event rich result.
• Likely cause — VirtualLocation and OnlineEventAttendanceMode are valid vocabulary, but Google’s current Event documentation requires a real-world physical location for this rich result.
• Fix — Do not fabricate a venue. Keep the markup for machine-readability if it accurately describes the event, but stop treating the Google event experience as an available channel for that online-only event.

A cancelled or postponed event develops required-property errors

• Symptom — An Event that previously qualified now reports a missing startDate or location after its status changed.
• Likely cause — The update process removed identifying properties when it set EventCancelled or EventPostponed.
• Fix — Restore the original startDate and location. Change eventStatus while retaining those values; once a postponed event has a new date, use EventRescheduled, update the dates, and add previousStartDate.

Event markup triggers a policy issue or manual action

• Symptom — Event enhancements disappear broadly, or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. reports a structured-data manual action.
• Likely cause — Pages are marking up sales, coupons, business hours, invitation-only activity, or other non-events as Event content.
• Fix — Remove Event markup from anything that is not a genuine, publicly bookable event, correct affected pages, validate them again, and follow Search Console’s reconsideration process if a manual action is present.

Prove an Event markup change took effect

Test 1 — A new in-person event is eligible in the rendered page

• Test to run — Test the deployed leaf-page URL with the Rich-Result Eligibility Checker and Google’s Rich Results Test.
• Expected result — Both detect one Event with name, startDate, and a physical Place location; Google reports no critical Event errors.
• Failure interpretation — A virtual-only location, missing required field, listing-page implementation, or client-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. failure prevents the intended eligibility.
• Monitoring window — Immediate in the validators; allow the next Google crawl before expecting Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. reporting to change.
• Rollback trigger — Do not ship markup that invents a physical venue or describes a different event than the visible page. Remove the block until the page and markup can agree.

Test 2 — A status update preserves the event identity

• Test to run — After setting EventCancelled, EventPostponed, or EventRescheduled, compare the rendered JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. with the prior version and validate the live URL again.
• Expected result — startDate and location remain present; a rescheduled event has the new dates and previousStartDate while the status uses the correct schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. enumeration.
• Failure interpretation — Missing identifying fields means the update job or template stripped data that Google says to retain.
• Monitoring window — Immediate after the status deployment and cache clearance.
• Rollback trigger — Revert the status-template change if it removes startDate or location across event pages, then redeploy a corrected mapping.

Event JSON-LD examples

A standard in-person event (Google’s own example)

A single, scheduled, physically-located event with the required three properties plus the recommended extras. This is reproduced from Google’s Event documentation:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "The Adventures of Kira and Morrison",
  "startDate": "2025-07-21T19:00-05:00",
  "endDate": "2025-07-21T23:00-05:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "location": {
    "@type": "Place",
    "name": "Snickerpark Stadium",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "100 West Snickerpark Dr",
      "addressLocality": "Snickertown",
      "postalCode": "19019",
      "addressRegion": "PA",
      "addressCountry": "US"
    }
  },
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "description": "The Adventures of Kira and Morrison is coming to Snickertown in a can't miss performance.",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/event_offer/12345_202403180430",
    "price": 30,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "validFrom": "2024-05-21T12:00"
  },
  "performer": {
    "@type": "PerformingGroup",
    "name": "Kira and Morrison"
  },
  "organizer": {
    "@type": "Organization",
    "name": "Kira and Morrison Music",
    "url": "https://kiraandmorrisonmusic.com"
  }
}

Note the details that matter: location is a real Place with a full address, the availability and eventStatus use the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. enum URL form (not plain strings), and the name is the event title — not the venue “Snickerpark Stadium,” which correctly lives in location.name.

The same event, cancelled — what changes and what doesn’t

When an event is called off, you keep startDate and location exactly as they were and only flip eventStatus:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "The Adventures of Kira and Morrison",
  "eventStatus": "https://schema.org/EventCancelled",
  "startDate": "2025-07-21T19:00-05:00",
  "endDate": "2025-07-21T23:00-05:00",
  "location": {
    "@type": "Place",
    "name": "Snickerpark Stadium",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "100 West Snickerpark Dr",
      "addressLocality": "Snickertown",
      "postalCode": "19019",
      "addressRegion": "PA",
      "addressCountry": "US"
    }
  }
}

The one change is eventStatus → https://schema.org/EventCancelled. Deleting startDate or location here would be the mistake — Google needs them to identify the unique event and tell users it’s off.

A rescheduled event — new dates, with previousStartDate

Once a postponed event has a confirmed new date, switch to EventRescheduled, update the dates, and record the old one:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "The Adventures of Kira and Morrison",
  "eventStatus": "https://schema.org/EventRescheduled",
  "previousStartDate": "2025-07-21T19:00-05:00",
  "startDate": "2025-09-14T19:00-05:00",
  "endDate": "2025-09-14T23:00-05:00",
  "location": {
    "@type": "Place",
    "name": "Snickerpark Stadium",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "100 West Snickerpark Dr",
      "addressLocality": "Snickertown",
      "postalCode": "19019",
      "addressRegion": "PA",
      "addressCountry": "US"
    }
  }
}

Individual event page vs. a listing page

This is the distinction that trips up venues and ticketing platforms:

• ✅ Eligible — individual event page: example.com/events/kira-morrison-july-21/ with a single Event object describing that one show. This is what qualifies.
• ❌ Not eligible — listing page: example.com/events/ showing a calendar or grid of ten upcoming shows, marked up (or not) as a batch. Google’s event experience only supports pages that focus on a single event — so mark up the individual event pages, not the listing.

(The JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. blocks above are simplified illustrative examples built on Google’s documented standard-event example; validate your own markup with the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test before shipping.)

Test yourself: Event Schema

Five quick questions on schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./Event, the physical-location rule, and event status handling. Pick an answer for each, then check.

Resources worth your time

My writing on this topic

I haven’t published a standalone Event schemaEvent schema (schema.org/Event) is structured data that tells search engines an event's name, date, location, and ticket info so the page can appear in Google's event rich results. Google requires a physical location — virtual-only events aren't eligible for the event rich result. guide of my own — so rather than point you at something that doesn’t exist, the honest move is to send you to the primary sources below and to the related structured-data work on this site. For the broader vocabulary and where Event fits, see the Schema MarkupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and Structured Data hubs; for the AI angle, Schema Markup for AISchema markup (structured data) is machine-readable code — usually JSON-LD — that labels what your content means using the schema.org vocabulary. For AI search it's infrastructure for entity disambiguation, not a direct citation lever: controlled studies found no meaningful uplift in AI citations from adding it..

From around the industry

• Event (Event) structured data (Google Search Central) — the authoritative reference for required/recommended properties, eventStatus, the one-event-one-URL rule, content policies, and the virtual-events statement.
• New properties for virtual, postponed, and canceled events (Google Search Central Blog, March 2020) — the COVID-era rollout that’s the source of most virtual-event advice; read it alongside the current docs to see how guidance evolved.
• General Structured Data Guidelines (Google) — the site-wide accuracy/spam policies Event markup must also satisfy.
• schema.org/Event — the full vocabulary reference for the Event type and its properties.
• Rich Results Test (Google) — validate Event markup and check eligibility.
• Marking Up Your Site with Structured Data (Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility.) — Bing’s general (non-Event-specific) structured-data support.
• A Simple SEO Guide for Successful Event Marketing (Ahrefs) — a broader look at SEO for events, with event structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. as one implementation tactic.
• What Is Schema Markup? How to Add It & Why It Matters (Ahrefs) — a general schema guide with a useful AI-agent/discovery angle.

Event Schema

Event schema (schema.org/Event) is structured data that tells search engines an event's name, date, location, and ticket info so the page can appear in Google's event rich results. Google requires a physical location — virtual-only events aren't eligible for the event rich result.

Related: Structured Data, Schema Markup, Rich Results

Event Schema

Event schema is the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./Event structured-data vocabulary you add to a page — usually as JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — so search engines can read an event’s name, startDate, location, and ticketing details (offers), plus recommended properties like endDate, eventStatus, image, performer, and organizer. When implemented correctly on an individual event page, it makes the page eligible for Google’s event rich result — the visually enhanced listing and event-search experience Google shows for event-related queries.

Google requires three properties: name, startDate, and location. The single most misunderstood point in current guidance is that Google’s event rich result requires a physical location — as of the December 2025 docs, “Virtual experiences that have no real-world component aren’t supported. Events must take place in a physical location.” That directly contradicts a lot of 2020-era advice that treats eventAttendanceMode: OnlineEventAttendanceMode and VirtualLocation as enough on their own.

Each event needs its own unique leaf-page URL — listing or schedule pages with multiple events aren’t eligible. As with any structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., valid Event markup only makes a page eligible; Google still decides whether to show the enhancement.

Related: Structured Data, Schema Markup, Rich Results

Changelog