Structured Data for Overview and Single Pages of Events

Question

I'm working on a platform where you can post events, among other things. I would like them to be found on Google and displayed as rich search results.

Briefly about the structure of the site. According to Google, it is recommended that you only display one event per page. That's why I have an overview page where you can scroll through all the events. This page is also linked in the sitemap so that Google crawls and indexes it regularly. Then there is a separate page for each event, on which only the information for the respective event is stored. However, this page is not in the sitemap and should not be stored there.

I then tried to store a BreadcrumbList (https://developers.google.com/search/docs/appearance/structured-data/breadcrumb) on the overview page. I then always specified the entire Event (https://developers.google.com/search/docs/appearance/structured-data/event) with the URL for the individual view as the "Item".

I then stored the Event as structured data in the individual view.

I then also set up a Google Search Console and could see that Google found my events from the overview page. However, these are not yet displayed as rich search results. I assume this will take some time.

The problem I have now is that the individual views are found as duplicates of the overview page and Google therefore does not index these pages. Probably because the events then have the same ID.

How can I structure this better? My next thought would be that I only place the links to the individual views on the overview page and place the information about the event exclusively on the individual view.

Since indexing always takes a while, I wanted to get some advice before making the next adjustment. Do you have any better suggestions? Does it even make sense to use a BreadcrumbList on the overview page?

It is important that the structured data is set exclusively via the JSON-LD. In addition, the individual pages cannot be stored in the sitemap.

Answer 1

One page per event, Yes and No.

Yes you need one page for each event, and if there is enough trending on it then it shows up in the events panel in search. If numerous sites are selling tickets the algo picks what it considers the first or the biggest site to put into the panel. Keyword for events panel is events, or today, tomorrow, concert, et la.

No you are not limited to one schema on a page. But these URLs that show 3 events are not the event page. They are additional pages on your site linking to and promoting the event page. These can help the event page itself get into the panel.

IE if you have three event pages with schema and you add the schema for all of these events to your home page, when your home page shows up it will show links to the other three event pages as an enhancement. The more the event page is promoted the more likely it is to get into the panel.

11086-us-san-diego is not the event page for any of these events. Each event has its own page. But the 11086-us-san-diego page has the same schema used on the event detail pages. So when somebody searches for hskhkd concerts the concert page is optimized for that search and the events are promoted as examples.

---

The event page with the details of the event itself should have structured data for the event. And this detail page has one event. The target URL in the json should point to itself. This URL must be on your site. Google using address, time of day, etc to determine if the event you are promoting is also being promoted on a different web site, not a problem but only one site can get listed in the panel.

  “location”: { 

    “@type”: “VirtualLocation”, 

    “url”: “https://sample.streamurl.com/” 

    }, 

Other pages can also have the Structured data and the 3 upcoming or current events will be listed. These additional pages have a copy of the same schema that is on the actual event page with the URL pointing towards the event detail page.

You can have as many additional pages as you would like linking to the actual event detail page. So if you have 20 events this month. You need ...

20 event detail pages with 20 schemas.

You can then place all 20 of the schemas on your main page, and when an event finishes that event will be removed from Google enhanced listings automatically and the next event will be added to the queue so 3 remain.

Concert and ticket sites almost all code this way.

Both of these methods of coding work ... I generally use separate scripts if doing the coding by hand because of the risk that an invalid character breaks the json.

<script type="application/ld+json" id="event80123">
    {
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    }
</script>
<script type="application/ld+json" id="event80423">
    {
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    }
</script>
<script type="application/ld+json" id="event80323">
    {
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    }
</script>

or as an array. But if one of the elements in the array is wrong the entire array fails. If they are separate scripts then if one has an error the other two still work.

<script type="application/ld+json" id="event80323">
    [{
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    },{
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    },{
      "@context": "https://schema.org",
      "@type": "Event",
// ... 
    }]
</script>

Always use the validator to check the json https://validator.schema.org/