What a podcast website has to do that the app cannot
Your listeners already have an app. The site's job is one page per episode: the audio, the show notes written as text, a transcript and a subscribe row, plus a feed address you never move.
You will not win listeners by having a website. They listen in an app that is already on their phone, on a commute or while doing the washing up. They find you somewhere else: a forum thread, a search result, a message from a friend. The website is what they open when they go looking for you afterwards, and it has to do the things the app cannot do.
The feed is the part that actually matters
Before you choose a layout, there is the feed: one RSS file that lists your show and every episode inside it. Podcast directories read that file, and they keep reading it after your show is accepted. Apple's published requirements ask for a feed in RSS 2.0 that anyone can reach, with one unique <enclosure> tag per episode giving the audio file's address, length and type, and a unique identifier for each episode that must never change.
Get your feed address from your host and store it somewhere you will still find in two years. Directories can be pointed at a new feed address later, but every one that holds the old address has to be updated, along with anyone who pasted it into a player by hand. That is why your feed must not be a side effect of a website rebuild. Ask where it lives on day one, and keep it there.
One page per episode, not one page for the show
The usual mistake is a single page listing forty episodes as titles that link out to a player. Most of those episodes then have nowhere of their own to land: nothing to share, nothing to search, nothing to link to when a friend asks which one it was.
Every episode gets its own page. On it:
- the episode title as the page heading, phrased the way someone would search for the subject
- an audio player near the top, above any long text
- the publication date and the running time as plain numbers
- who is on the episode, and what they do
- links to anything mentioned, written as real links
Show notes are text, not a wall of links
Ask what a deaf reader learns from the page. If the answer is only "there is an episode", the notes are not written yet. A guest's name that exists solely inside the audio cannot be found by anyone searching that name, and a book recommended at minute nineteen is lost to everyone who stops at minute five.
Write the names, places, tools and titles as text on the page. Short is fine. Invisible is not.
A transcript earns more than the effort you think
The W3C's accessibility guidance expects prerecorded audio-only content to carry a text alternative, because text can be read, enlarged, searched and translated. Automatic transcription gets you most of the way there, and it is wrong in exactly the places that matter: names, jargon, place names. Fix those by hand and put the transcript below the player, collapsed if you prefer, with the speaker names kept in.
A subscribe row, in two places
Give people one row with the two or three apps that matter, plus your own feed address for anyone who uses something else, plus a way to hear about the next episode by email. Put that row under the player, and again at the end of the page. A single listen link in the footer is a link most people never reach.
What to leave off
- an autoplaying player on the home page, because sound starts before the listener has chosen it and stopping it is not always obvious
- a badge counting episodes, because nobody picks a show by episode count
- a page for an episode that is not published yet
A twenty-minute pass you can do today
Open one episode page on your phone using mobile data rather than wifi, and count the taps between landing and hearing sound.
Then turn the sound off and read the page. If you learn nothing about the episode, rewrite the notes.
Search the full name of your most recent guest. If your page does not come up, that name is not on the page as text.
Run your feed address through a validator. Your host will have one, and Apple publishes its own checks. A feed that has lost an enclosure can take one episode out of every app at the same time.
Finally, hand the page to someone who has never heard the show and time how long it takes them to find the subscribe row. Anything past five seconds is a layout problem, not a listener problem.
Sitewright, the product this blog belongs to, is still being built. There is no builder to try yet, and the waitlist on the home page is the only thing open.