What the Event Schema Generator does
This tool builds Event structured data in JSON-LD, the markup that tells Google and other engines a page is about a specific happening with a date, a place, and a way to attend. You enter the event name, when it starts and ends, where it takes place, who is organizing it, and how tickets work, and the generator returns a clean code block you paste into the page. With that block in place, your event becomes eligible for the event rich result and, more importantly, for Google's dedicated event experiences: the "events near me" listings, the event pack in regular search, and the date-and-location cards that appear when someone searches a concert, conference, workshop, or festival by name.
Event schema is unusual among schema types because Google aggregates it. A single well-marked-up event page can be pulled into Google's broader event discovery surface alongside listings from ticketing platforms and venues, which means correct markup is often what gets a small organizer's event seen next to the big players. The data is also time-sensitive in a way most schema is not: an event has a start, an end, and a status that changes, so the markup has to stay accurate right up to and through the event date.
The required properties Event must have
Google requires four things for an event to be eligible: name, startDate, location, and a valid event structure. The name is the title of the event as a human would read it. startDate is the moment it begins, written in ISO 8601 format and, crucially, including a timezone offset, for example 2026-09-12T19:00:00-04:00. Omitting the timezone is one of the most common reasons event times display incorrectly, because Google cannot know whether 7pm means Eastern, Pacific, or somewhere in Europe.
location is where the requirements branch depending on the kind of event. For an in-person event, location is a Place object with a name and a postalAddress containing street, city, region, postal code, and country. For a fully online event, location is a VirtualLocation object whose url points at the page where attendees join. For a hybrid event, you supply both as an array. Getting the location type right is essential because it feeds directly into how and where Google surfaces the listing, and a physical address on an online-only event is a validation error.
Dates, status, and attendance mode
endDate, while not strictly required, should almost always be supplied so Google knows when the event concludes and can stop showing it as upcoming. Multi-day events especially need a correct endDate. Two properties became essential during the era of disrupted events and remain important: eventStatus and eventAttendanceMode. eventStatus takes values like EventScheduled, EventCancelled, EventPostponed, EventRescheduled, or EventMovedOnline. If an event is cancelled or moved, updating eventStatus is what lets Google show the change to people who already saw the listing, rather than sending them to a locked door.
eventAttendanceMode declares whether attendance is OfflineEventAttendanceMode, OnlineEventAttendanceMode, or MixedEventAttendanceMode. This must agree with your location type: an online attendance mode with a physical-only location, or vice versa, is contradictory and undermines the markup. Setting these two properties correctly is what makes your event resilient to last-minute changes and clearly classified, which is exactly what the event discovery surface rewards.
Offers, performers, and organizer
The offers property describes how to get in. It is an Offer object (or an array of them for multiple ticket tiers) with price, priceCurrency, a url pointing at the ticket or registration page, availability such as InStock or SoldOut, and a validFrom date marking when tickets go on sale. Including offers makes the listing far more actionable because Google can show a price and a buy path. For free events, set price to 0 and supply the currency anyway. An accurate availability value also lets the listing reflect a sold-out state rather than sending disappointed clicks to a dead ticket page.
performer names the act, speaker, or team appearing, as a Person or PerformingGroup object, which is what powers the artist and lineup connections in music and entertainment search. organizer is the entity running the event, as an Organization or Person with a name and url, and it is an important trust signal that ties the event back to a credible host. image, while listed as recommended rather than required, is what gives the listing a visual and should be a high-quality, event-specific photo or poster at least 1200 pixels wide.
Choosing a precise subtype sharpens classification when one fits. A concert should use MusicEvent, a conference or trade show BusinessEvent, a class or seminar EducationEvent, a play or screening TheaterEvent, and a match or tournament SportsEvent. Each subtype inherits all the standard Event properties, so you lose nothing by being specific, and you gain a clearer signal about what kind of happening this is. For festivals and conferences that span several days with their own sub-sessions, the cleanest pattern is a parent Event for the overall happening plus individual Event entries for the notable sessions, each with its own start time, rather than trying to express a packed agenda inside a single block.
How to read the generated output
The output is a single script block with type application/ld+json holding one object whose @context is schema.org and @type is Event (or a more specific subtype such as MusicEvent, BusinessEvent, or EducationEvent if you chose one). Read it and confirm the startDate carries a timezone, the location object matches the attendance mode, and any offers have both a price and a currency. The most important sanity check is that every date and price in the markup exactly matches what a human sees on the page, because Google compares the two and distrusts schema that disagrees with visible content.
If you marked the event as online, verify the VirtualLocation url is the real join link and not just your homepage. If in-person, verify the postalAddress is complete down to the country, since a missing country or region is a frequent validation warning. For recurring events, remember that each occurrence is its own Event with its own dates; do not try to cram a weekly series into a single block with one start date.
Common mistakes specific to Event schema
The number one Event-specific error is the missing or wrong timezone on startDate, which makes the displayed time meaningless for anyone outside your local zone. A close second is marking up a page that lists many events with a single Event block; a listings or calendar page should mark up each event individually, or use an ItemList, not pretend to be one event. Third is the location and attendanceMode mismatch described above, where the two contradict each other and confuse classification.
Another common trap is stale markup. Because events are time-bound, an Event whose date has long passed but whose page still claims it is EventScheduled and InStock is misleading; once an event is over, the markup should reflect that, and cancelled events must have eventStatus updated rather than simply being deleted, so people who saved the listing learn it is off. Finally, organizers sometimes invent an aggregateRating or fabricate offers; ratings on events are rarely appropriate, and fake ticket prices that do not match the real ticketing page are a policy violation that risks the whole listing.
Event schema in 2026 and AI-driven discovery
Event data is increasingly consumed by more than the classic rich result. AI assistants and AI Overviews answer questions like "what concerts are happening this weekend near me" or "is the conference still on", and they lean on structured event data with explicit dates, locations, statuses, and ticket links because that information is unambiguous and easy to verify. An event marked up with a precise timezone-aware date, a clear attendance mode, a current status, and a working ticket offer is exactly the kind of source these systems can quote and act on without guessing.
The premium on accuracy is higher than ever because the cost of being wrong is visible. If an AI surface tells someone an event is on when it was cancelled, that reflects on your brand, so keeping eventStatus and availability current is not just good schema hygiene but reputation management. Clean, truthful Event markup is the most reliable way to make your event legible to both Google's discovery surfaces and the AI tools people now ask for plans.
What to do after you generate it
Paste the generated block into the head of the individual event page, one block per event, then validate it with Google's Rich Results Test to confirm it is detected as a valid Event and that there are no errors on the date, location, or offer fields. The test will tell you precisely which property is malformed if anything fails, which usually comes down to a date format or an incomplete address.
After it is live, monitor the Events report in Search Console's Enhancements section to confirm Google has parsed your events and to catch any errors across many event pages at once. Then keep the markup alive: update eventStatus the moment anything changes, flip availability to SoldOut when tickets run out, and make sure passed events no longer present themselves as upcoming. Event schema is one of the few types where ongoing maintenance is part of the job, and the listings reward keeping it honest right through the event date.