For organizers and partners

Make your website easy for calendars to read

Publish a feed once and stop submitting forever. This is the one that pays you back every month.

The video for this one is not shot yet. The written walkthrough below is the whole thing, not a summary of it.

This is the one that pays you back. Everything else on this page is about sending us an event. This is about setting your own site up so you never have to send us anything again, and so every other calendar, search engine and assistant in the world can read you too.

It is a one time job, usually an afternoon, often a checkbox in software you already pay for. Then it runs on its own.

Publish a calendar feed

An ICS feed is the calendar file format that Google Calendar, Outlook and Apple Calendar all speak. If you have a feed URL, we can point a scraper at it and pull your events every night, automatically, forever. You update your site and we update within a day. Nobody emails anybody.

You may already have one and not know it.

  • WordPress with The Events Calendar publishes one out of the box, usually at yoursite.com/events/?ical=1.
  • Google Calendar will give you a public ICS address in the calendar settings, under integrations.
  • Squarespace and Wix events, most library and parks systems, and most ticketing platforms have one somewhere in the settings.
  • Eventbrite and similar platforms are readable to us too, so if that is where your events live, tell us and we will hook into it.

Ask whoever built your site whether there is an ICS or iCal feed. It is a five word question and the answer is yes more often than people expect.

Or mark up your event pages

If a feed is not available, the other option is structured data. Schema.org Event markup is a small block of JSON in the page that spells out the name, the start time, the location and the ticket link in a format machines read exactly. Google uses it for event results, and so do we.

Most site builders have a plugin for this. The important part is that the marked up values match what a human sees on the page. Do not put a different time in the markup than the one in your copy.

Keep your IDs stable

This is the technical detail that causes the most trouble, and almost nobody thinks about it.

Every event on your site has some identifier: a UID in an ICS feed, or just the URL of its page. We use that to recognize an event we have seen before. When the identifier stays the same, an edit on your side is an update on ours. When it changes, we have no way to know it is the same event, so it comes through as a new one and now there are two of you on the calendar.

Some systems generate a fresh ID every time the page is republished. That produces a duplicate every single night, which is the worst version of this problem. If you see your events doubling up anywhere, that is usually the cause and it is worth asking your developer about.

Have one canonical page per event

Pick one page that is the real listing for each event and keep it stable. Everything else, the Facebook event, the Instagram post, the ticketing page, should point at it.

When four half copies of an event exist in four places, all of them drift. The time gets fixed in one and not the others, and eventually someone shows up at the wrong hour holding a screenshot. One page you actually maintain beats four you do not.

A word about Facebook only

If your event exists only as a Facebook event, it is close to invisible outside Facebook. We cannot read it, other calendars cannot read it, and it does not show up in search. Neither can anybody who does not have an account, which is a growing number of people and skews older and lower income, which may be exactly who you are trying to reach.

Keep using Facebook. Just make it the second place the event lives rather than the only one. Even a plain page on your own site with the name, the date, the address and a paragraph is enough for the rest of the internet to find you.

What good looks like

  1. Every event has a page on your own site with a stable URL.
  2. The site publishes an ICS feed, or the pages carry Event markup.
  3. IDs do not change when you edit.
  4. Times and addresses on the page are the real ones.
  5. You tell us the feed URL once and stop thinking about us entirely.

Send the feed to intake@akronpulse.com and we will take it from there. If you are not sure whether what you have counts, send us the link to your events page and we will tell you what we can see.

The other half of feed hygiene is what happens when events repeat or change, which is the next guide.

Still stuck, or think this guide is wrong about something? Email byron@akronpulse.com, or head back to all the guides.