Event Schema Markup: The JSON-LD That Puts Your Events in Rich Results

A concert hall posts its September lineup. A yoga studio opens registration for a weekend workshop. A restaurant books a live jazz trio for Friday nights. All three publish the details on their own websites, and all three watch Eventbrite, Facebook, and ticket resellers outrank them for their own event names. The mechanism that flips that outcome is structured data. This is piece twelve in our schema series, and it maps to Vector 6, Structure, in the 12-Vector methodology: markup that machines read with high confidence.

What Event Schema Markup Actually Does

Event schema markup is a block of JSON-LD placed in the head or body of an event page that declares, in Schema.org vocabulary, exactly what the event is: its name, when it starts and ends, where it happens, what tickets cost, and whether it is running as planned. Google reads that declaration and can then render the page as an event rich result, list it in the events experience on Search and Maps, and surface it under the Things to do tab for a city.

Two things follow from that. First, the enhanced listing carries the date, venue, and price straight into the search results page, which is why event rich results tend to draw clicks that a plain blue link does not. Second, the same machine-readable declaration is what answer engines parse when someone asks ChatGPT or Perplexity what is happening in a city this weekend. One block of structured data serves both surfaces. If you are new to structured data generally, start with our walkthrough on how to add schema markup and come back; this page assumes you know where JSON-LD lives in a template.

A Complete, Valid Event JSON-LD Example

Here is a full Event object for a fictional in-person concert. It includes every required property plus the recommended set that Google's Event documentation asks for. Paste it into the Rich Results Test and it validates cleanly; swap in your own details and it will do the same on your site.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Harvest Nights: An Evening of Roots Music",
  "description": "A live roots and folk performance featuring two touring acts, doors at 7 pm, licensed patio open until close.",
  "startDate": "2026-09-12T19:00:00-04:00",
  "endDate": "2026-09-12T23:00:00-04:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "image": "https://example.com/events/harvest-nights/poster.jpg",
  "location": {
    "@type": "Place",
    "name": "The Granary Hall",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "112 Mill Street",
      "addressLocality": "Brantford",
      "addressRegion": "ON",
      "postalCode": "N3T 2A1",
      "addressCountry": "CA"
    }
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/events/harvest-nights/tickets",
    "price": "35.00",
    "priceCurrency": "CAD",
    "availability": "https://schema.org/InStock",
    "validFrom": "2026-07-15T09:00:00-04:00"
  },
  "performer": {
    "@type": "MusicGroup",
    "name": "The Long Field Ramblers"
  },
  "organizer": {
    "@type": "Organization",
    "name": "The Granary Hall",
    "url": "https://example.com"
  }
}
</script>

Every value shown in that block must also appear on the visible page. Google's structured data policies treat markup that describes content the visitor cannot see as a violation, and price mismatches between schema and page are one of the fastest routes to losing the rich result entirely.

Required Versus Recommended Properties

Google's minimum for eligibility is short: name, startDate, and location. The recommended list is where listings actually compete, because a result showing date, venue, price, and availability beats a result showing a name and nothing else.

Skipping the recommended set does not disqualify the page, but it hands the richer listing to whichever aggregator marked your event up more completely than you did. That is usually how Eventbrite ends up owning the enhanced result for a show happening in your own building.

Location: Place, VirtualLocation, and Hybrid Events

The location property carries more weight than most implementers give it. For a physical event, use a Place with a complete PostalAddress: street, city, region, postal code, country. A bare venue name without an address weakens both rich result eligibility and the local disambiguation that puts the event on the map card for the city. If the venue is the business itself, the address in the Event markup should match the address in your LocalBusiness schema character for character; conflicting addresses across a site's schema graph read as noise to the parser.

Online events replace Place with VirtualLocation, whose url property points at the stream or registration page, and set eventAttendanceMode to OnlineEventAttendanceMode. Hybrid events use MixedEventAttendanceMode and pass an array containing both a Place and a VirtualLocation. Since 2020 the attendance mode property has been the signal Google leans on to label listings correctly, so a webinar marked up without it is leaving a free clarity signal on the table.

Offers: Pricing, Availability, and the Visible-Content Rule

The offers property is where event markup most often goes wrong. It takes an Offer object with price, priceCurrency, availability, a validFrom date for when sales open, and a url pointing at the purchase path. Three rules keep it clean:

• The price in the schema must be the price on the page. If the early-bird rate ends, update both together.
• Free events declare a price of 0, not an omitted offers block. A declared zero price is machine-readable proof of a free event; an absent block is just missing data.
• Availability should track reality. InStock while tickets remain, SoldOut when they are gone. Stale SoldOut markup on an event with seats left actively suppresses your own sales.

Currency matters for Canadian venues: priceCurrency is CAD, not an assumed default. We have audited pages where American template code shipped USD on Ontario ticket prices, which misstates the cost to every searcher who sees the rich result.

eventStatus: Cancelling and Rescheduling Without Vanishing

Plans change, and the vocabulary anticipates that. The eventStatus property takes one of five values: EventScheduled, EventCancelled, EventPostponed, EventRescheduled, and EventMovedOnline. The counterintuitive part is what you do with the dates.

A cancelled event keeps its original startDate and changes only the status to EventCancelled. Google then annotates the listing as cancelled instead of quietly dropping it, which is the honest outcome for anyone who already bought tickets or planned a trip. A postponed event with no new date keeps the original startDate too, under EventPostponed, until a replacement date exists. Once the new date is set, switch to EventRescheduled, update startDate to the new date, and record the original in previousStartDate. An in-person event converted to a stream takes EventMovedOnline plus a VirtualLocation. Deleting the page or stripping the markup is the one move with no upside: cached and third-party listings persist, and now they point at a page that pretends the event never existed.

Recurring Events: One Object Per Occurrence

The weekly jazz night, the monthly paint class, the Friday wing special with a live act: recurring events are where implementers reach for a single markup block with a vague date range, and that is precisely what Google's guidance rules out. Each dated occurrence is a separate event to the parser. The clean pattern is one Event object per date, each with its own startDate, either on individual URLs or as multiple objects on one series page.

In practice, mark up the next six to twelve occurrences and roll the window forward on a schedule. Past-dated markup is dead weight; future-dated markup is inventory. Schema.org also offers eventSchedule with a Schedule object to describe the repetition pattern itself, and while Google's event documentation does not list it among the recommended properties, it is a legitimate additional signal for answer engines trying to understand that the series repeats weekly rather than treating each listing as unrelated.

What Rich Result Eligibility Actually Requires

Markup is necessary but not sufficient. Google's event experience has structural preconditions that sit outside the JSON-LD:

• Each event needs its own crawlable URL, or at minimum its own complete markup block. A calendar page with twenty shows and zero per-event detail pages is the single most common disqualifier we encounter.
• The markup must describe an event, not a promotion. Google explicitly excludes coupon-style listings dressed up as events.
• Schema must match visible content. Dates, prices, and venue details in the JSON-LD have to appear on the rendered page.
• Validation before deployment. The Rich Results Test shows exactly which properties parse and which warnings remain; treat warnings on recommended fields as a to-do list, not as noise.

Even a page that clears every bar is eligible rather than entitled. Google decides per query whether to render the enhancement. What the markup controls is whether you are in the draw at all.

Who Benefits Most: Venues, Studios, and Restaurants

The businesses with the strongest return on event markup are the ones whose calendar is a revenue line rather than a footnote.

Venues and halls live or die on per-show discovery. Every concert, comedy night, and community booking is a fresh page that can rank for its own name and feed the Things to do surface. Wedding and banquet venues sit in a related but distinct lane, where showcase events and open houses become structured-data assets; our GEO for wedding venues solution builds on exactly this markup layer.

Studios and class-based businesses, from yoga and pottery to martial arts, run recurring schedules that map directly onto the one-object-per-occurrence pattern. Workshops with fixed enrolment benefit doubly, because the offers block communicates scarcity honestly through availability.

Restaurants and bars with programming, live music, trivia, tastings, holiday dinners, are the least likely to have any markup at all, which makes the category unusually winnable. A restaurant whose Friday jazz night carries proper Event JSON-LD is frequently the only structured source in its market for that query.

Why Event Markup Matters More in AI Search

Answer engines have made the stakes larger than the rich result. When someone asks an assistant what is on in their city this weekend, the systems assembling that answer favour sources whose event data is explicit, dated, and attributable. Structured data is not a ranking requirement for generative results, and Google's own AI documentation says as much, but an Event object with a named organizer, an exact start time, and a real address gives an extraction pipeline everything it needs to quote you rather than an aggregator. The same discipline that earns the carousel earns the citation. This is the practical overlap between Vector 6, Structure, and Vector 4, Embed: write the answer, then declare it in vocabulary machines trust.

One caution in the other direction: do not generate near-duplicate event pages for every keyword variation of the same show. That pattern falls under scaled content abuse regardless of how clean the markup is. One event, one page, one declaration.

If you would rather hand the whole layer to a team that does this daily, our schema markup service covers Event alongside the rest of the graph, and the broader services overview shows where structured data sits in the full engagement. Curious where your current event pages stand? The audit form below will tell you within a business day, or reach us directly through the contact page.