Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
One of the Few Rich Results Left
Google has retired a long list of structured data types over the past three years. Events survived, with a dedicated experience that can show dates, location, and ticket information directly in results. That makes it one of the few markup investments with a clear, currently visible payoff.
The pattern across retirements is that types offering little differentiated value to searchers get withdrawn, while types that answer something a plain link cannot survive. Events fit the second category: when and where something happens, and whether tickets are available, is genuinely useful in the result itself.
Worth knowing who this applies to, because it is broader than conference organisers. Venues, restaurants running supper clubs, nonprofits with fundraisers, retailers with launches, gyms with classes, and anyone running workshops all publish events and mostly do not mark them up. The context on what else still earns a result is in structured data in 2026.
The Fields, and the Ones That Break
Name, start date, and location are the core requirement. The failures cluster in specific places: dates without timezone information, locations that are not real addresses, and offers declared in markup but invisible on the page.
| Field | What it needs | How it breaks |
|---|---|---|
| name | The event as people would search it | Internal codes, or a series name with no specifics |
| startDate | ISO 8601, including timezone offset | Date with no time or no offset, so it displays wrongly |
| endDate | Present for anything multi-day | Omitted, so a festival looks like a single day |
| location | Full address, or virtual location for online | A venue name with no address |
| offers | Price, currency, availability, and a URL | Declared in markup, not shown on the page |
| eventStatus | Updated if postponed or cancelled | Left as scheduled after a change, misleading people |
| image | Multiple aspect ratios | One small image, cropped badly |
The offers row is the most common failure and the easiest to avoid. If your markup says tickets are twenty pounds, the page must say tickets are twenty pounds. Organisers break this constantly because pricing lives on a third-party ticketing platform, and the fix is simply to show the price on your own page as well as linking out.
One Page Per Event
The markup describes a specific event, so it belongs on a page about that event. A listings page showing your whole programme is not the right home for it, and putting it there is why some organisers see nothing despite apparently valid markup.
This mirrors the rule for job postings, and for the same reason: a result for a specific event has to link somewhere that describes that event. If a visitor arriving from search lands on a list and has to find the thing they clicked, the result would be a poor one, which is why the requirement exists rather than being an arbitrary technical rule. The parallel case is in job posting markup.
Recurring events raise a related decision worth making early. A monthly class or an annual festival should keep one permanent URL that gets updated, rather than a new page each occurrence. New pages per instance split every reference across a series of near-identical documents and start from nothing each time, which is the same logic as the seasonal case in seasonal SEO.
Publishing Early Enough to Matter
An event page published a fortnight before the date has almost no time to be discovered, assessed, and shown. Events have a hard deadline that content generally does not, which makes lead time more consequential here than almost anywhere else.
Publish as soon as the date and venue are fixed, even if the programme is incomplete and tickets are not live. A page with confirmed essentials and a note that details follow is a page that exists and can start being discovered. Waiting for the full lineup means launching into the window where you needed to already be established.
Then update it rather than replacing it as details firm up. Each update is a genuine change to a page that is accumulating relevance, which is exactly the right pattern, and it avoids the common alternative of a placeholder page, a real page, and a ticketing page all competing for the same event.
After the Event, Which Nobody Plans For
Every event page has a guaranteed expiry, and most organisers decide what happens to it afterwards by not deciding. The result is either a growing archive of pages advertising things that already happened, or deletions that leave dead ends where references pointed.
For recurring events the answer is straightforward: the permanent URL rolls forward to the next occurrence, with past instances summarised rather than separately published. For genuine one-offs, keep the page with a clear statement that the event has passed, what happened, and what is next. That serves someone arriving late, retains any accumulated value, and turns an expired page into evidence you run things.
Update eventStatus honestly if something is postponed or cancelled, because markup that still says scheduled for an event that is not is actively misleading people about attending. That has consequences beyond search, and it is the reason status properties exist at all.
Questions Organisers Ask About Event SEO
- How do events appear in Google search results?
Through a dedicated event experience that can show dates, location, and ticket information directly in results for event-related queries. Eligibility comes from Event structured data on a page describing a specific event. There is no submission process; Google discovers eligible pages the same way it discovers any page.
- What fields does Event markup require?
At minimum the event name, a start date in ISO 8601 format including a timezone offset, and a location. Adding endDate, description, image, offers with ticket prices and availability, performer, and organizer materially improves what can be displayed, and incomplete markup limits the result to something less useful.
- Can online-only events get an event result?
Google supports online events through the attendance mode and virtual location properties, so an online event is describable in markup. Which visual treatment a given event receives is Google's decision and varies, so follow the current documentation rather than a blog claiming online events are excluded outright.
- Do ticket prices in markup have to appear on the page?
Yes. Google's structured data guidelines require that marked-up information be visible to users on the page. If your markup declares a price, that price must be shown. This is the most common way event markup fails review, usually when prices live on a separate ticketing platform.
- What should happen to a page after the event ends?
Decide before you publish. Recurring events should keep one permanent URL with updated dates so the page compounds across years. Genuinely one-off events should keep the page with a clear note that it has passed and a link to what comes next, rather than being deleted, which turns every past event into a dead end.
