English Ceilidh events, Structured Data, Google, Bing, etc.
Note: Most of our pages are fine on smaller screens but this one is less so.
This is a rather technical document designed to help webmasters get their English Ceilidh events listed by Google and other "Search Engines". The simple way to achieve this is to use the tool we've already built at http://eceilidh.org.uk/cps/step1.php. Most readers should do that now.
Instead, if you want to understand how it all works, perhaps because you want to enhance your site or build a system for another sort of event, read on!
Complexity, Completeness and Practicality
If you study schema.org
which is basis of what we, Google and others have done, coding up events looks quite complex. However, if you code up every little detail, not only will it take you a lot of time, it's unlikely that anybody (or any robot) will be making use of all
your hard work. We've taken a more pragmatic approach. We've asked ourselves:
- What do people want to know about an English Ceilidh event? EG: Who is the band?
- What do they really need to know? EG: The date, time and place
- What information do the robots actually make use of - so far as we can tell?
We've made compromises based on our understanding of the English Ceilidh scene. EG: Bands often have websites that are worth providing links to. Callers don't often have a dedicated site so we don't give their URLs at all.
For comparison, it's worth looking at the way a ticket sales site such as Eventbrite has chosen to do their Structured Data. They do much more in the way of pricing information - "early bird" deals, etc. than we do.
One Event per Page
Google say they want each event to have its own web page. This is moderately annoying because many bands, ceilidh series, festivals, etc. are used to putting multiple events on one physical or web page. We've seen at least one attempt to code up a complete season of dances on one page but as far as we can tell, Google doesn't want to know. Our system at http://eceilidh.org.uk/cps/main.php
builds a page for each event and we strongly advise that anything you build does likewise.
This format has been used by Google for some time and Bing recently went over to it (although some of ther documentation hasn't caught up yet). Some of the other formats are OK although "microformats" interleave the structured data with the visible HTML in a way that needs a lot of care and makes maintenance harder.
As of March 2018, there are no other relavent "Search Engines" serving the UK. You will
see other names such as Yahoo but they are built with Google or Bing underneath. Yandex, Baidu, etc. are big in Russia and China respectively but not in the UK.
Below you'll find an example of how we code up a ceilidh event. You can insert code like this into the body of your web page. To understand the code, what we've done and why, click on the ℹ symbols to the left
The JSON-LD in detail:
We set this to an array of Event and DanceEvent. While DanceEvent is more specific, some of Google's "Search Console" tools extracts more detail from simple Event data. So we decided to use both
"name":"Dance to The Example Band with Mr A Caller presented by Anywhere Ceilidhs",
This is a short sentence describing the essence of the event. We also prefix it with SOLD OUT or CANCELLED if appropriate. Schema.org does have more formal ways of indicating such statuses but our reasoning is that it's better for such events to continue to show in exactly the same places as before but suitably changed. If a robot decided to take down a cancelled event, humans might think the disappearance was due to them not being able to find it rather than that it had been cancelled.
It's not necessary to specify the seconds. We specify the local time and take no account of time zones.
This detail is often not mentioned in more traditional media. In this example, we make the event finish at half -past midnight (the next day)
This could be anything from a single individual, a charity or an informal organisation. To simplify things, we always set the type to be an Organization (US spelling) even when it's actually a Person
The name of the organiser
This must be shown in full international format. You must have at least one phone number or a website
You must at least one phone number or a website
Although a number of types are available, this generic type is probably the best to use.
This is the home page of the organiser's site. Sometimes this page won't have anything about dancing on it. That's usually because the organisation's main activity is something else - EG: A charity that has put on a dance to raise money.
"name":"Anywhere Village Hall",
The location of the dance - which may not be the postal address of the organiser. This field will often be a building or festival name
"streetAddress":"123 High St, Anywhere",
The street address and (after a comma) a local district or village name
This will be a major geographic entity, often a large town nearby. The ceilidh might be many miles from this place, the intent is to give a rough location
Note that UK postcodes were invented by the Post Office to help them deliver letters. As guides to the location of dance halls they are OK but not perfect.
This will typically be a County or large metropilitan area such as "London". It's optional.
This works. We're not sure that (say) England would work better or at all.
"description":"A free text field describing the event. Can be several hundred characters long.",
This is the place to say how wonderful the event will be.
Strictly speaking, this should be a picture of the actual event - which is tricky because it hasn't happened yet. We suggest that it could be a picture of the band, caller, venue or shots of people dancing at previous events.
A listing of everone in the band plus the caller is over the top. We list the band as one performer and the caller as the second
"name":"The Example Band",
MusicGroup is as specific as you need to be
"name":"Mr A Caller"
Schema.org doesn't reccognise a role as specialised as a "dance caller" so we make do with Person. Most English Ceilid callers don't have a website or if they do, it's not particularly important information for people thinking of attending.
|Schema.org provides for very detailed pricing structures and sites like Eventbrite make use of it. We've opted for a simple text field. Google say the want to know the currency, etc. as a separeate field but we found that putting simply £5 does get picked up by them like this
So, you've created your page(s) and perhps sumitted them to Google but that's not necessarily a particulalry effective or efficient way of getting your events indexed and visited. Google, Webfeet and Bing have a preferred way of being kept up to date with events - sitemaps. These are not the pages you often see on websites called "Site Map", they are a macine readable file that's also not too hard for humans either.
Basically, they list the URLs of pages you want to be looked at together with information about changes. Here a fragment of one of ours
You can see the entirre file here
- You should also add a link to your sitemap file to your robots.txt file like this:
- Use Google's Search Console and Big's Webmaster Tools to tell it where to find your sitemap
- Write to Webfeet with similar infomation
- Ideally, everytime you add/change/delete an event, update your sitemap file and "ping" Google and Bing by visiting these addresses:
Getting rid of past events
Google often returns results for events that happened in the past. That's good if you're a historical researcher or like to show that your band has a track record. For the dancing public, it's less useful and we've discovered ways to stop it happening:
- Remove the event page and references to it as soon as the event is over. (The software on our server is set up to do this automatically)
- Tell Google that the page expires after the dance by putting a line like this in the head section of the page
<meta name="robots" content="unavailable_after: 21-Apr-2018 22:30:00 UTC">