How Not to Get Shafted by a Hosted Podcast Service

It’s every podcaster’s nightmare: You create a podcast, produce episodes, build a loyal audience… then suddenly, without warning, your hosting service folds. Not only can your listeners not find you – you can’t even access your own content!

Sadly, it happens. It happened recently to the customers of Purecast. But it doesn’t have to happen to you.

Over at Multidimensional Me today, Koan Bremner has published a thorough, plain-language tutorial every current or would-be podcaster should read. See “Learning the Lessons of Purecast.

Here’s what she covers…

Koan’s rules are:

  1. Buy a domain name, and use it.
  2. Own the rights to your web feed. (Feedburner customers, pay close attention to this one.)
  3. Have a local, platform-neutral copy of your site’s contents.
  4. Use a tool which outputs the simplest HTML code possible
  5. Keep your site content separate from your media content
  6. If you use any web service (paid or free) – have an exit plan

…Of course, those are just the headlines. Go read her tutorial for the details.

Many thanks to Koan for writing a much-needed and extremely cogent tutorial. Well done!

7 thoughts on How Not to Get Shafted by a Hosted Podcast Service

  1. Prudent advice, but I have to wonder wether it’s really realistic to always have an exite plan for every web service we use. I presume you don’t mean just for podcasts. How many do you use? I use too many for that to be realistic. Perhaps mission critical ones should be focused on. So what are those? Podcast hosting, social bookmarking archives, RSS feed readers and blog archives?

  2. Every podcast deserves to be treated as a professional work.
    [1] Create your podcast
    [2] License your podcast, specifically for use on the Internet
    [2](a) Upload your podcast to a reputable repository, by creating an account on that repository of choice
    [2](b) Choose a license that identifies what options/rights you declare
    [2](c) Check and update your repository account to reflect the license once you’ve registered it
    [3] Develop a search engine registration strategy *

    Using the above steps, you will always have your work residing in a reputable repository that will be available for the foreseeable generations to come.

    Use the license options available with the Creative Commons project, and your work will automatically be identified through “tagging” by search engines, e.g., Google’s Creative Commons search.

    Use the Internet Archive at .

    * Include setting up a free online store account with sites such as, or , and offer deluxe versions, compilations, and gear for your podcasts.

    * music is freely available from independent artists who follow the above steps, and can be found at sites such as SONG STORM, and other sites. Might as well add a theme and make all your podcasts ready-to-go radio shows. For more free help with this aspect, just reach out to Open Studios,

    Disclaimer: I work with Open Studios and SONG STORM, both nonprofit projects where all services are free. Our mission is to replenish our public domain, but don’t let that stop you. We try not to interfere with copyright holders who want to make money. 🙂

  3. Marshall – you make a fair point, in my opinion – maybe an exit plan is not feasible for every web service (maybe there is no direct equivalent service, or combination of services, for example). But if not an exit plan, then at least an *impact* plan – i.e. “how will it affect my blog / podcast / videoblog if service X is unavailable for a period – what (if anything) would I need to do to mitigate any loss of service to my subscribers?” I wasn’t focusing on web services from the perspective of general use (I use many as an individual) – I was focusing on those that potentially “make or break” the delivery of a blog / podcast / videoblog to subscribers.

    Tom – excellent points – I wasn’t trying to write a comprehensive “how to produce a professional podcast” post, I was trying to write a “how not to get caught out by a service going belly up post”. You mention the Internet Archive – OurMedia uses the Internet Archive’s infrastructure, and as I mentioned in my post, in my experience, it can take weeks for files to appear on OurMedia, and some never do.

  4. For free and open tunes see also

    That’s a project of the Podshow Network, and I think they will probably be offering a storage service soon too. I imagine that will be more trustworthy than many other options. It’ll probably be more reliable than Libsyn, which in my limited experience seems to go down with greater frequency than I am comfortable.

  5. Also, I’d like to know a little more about your concerns re Feedburner. I understand the principle of owning your own feeds, but I LOVE Feedburner! Also, if Feedburner is just republishing a feed that comes out of my blogging software, don’t I still own that original feed? So what would I be missing, my subscribers…ok, that would be a concern. Maybe I’m being foolish to be so in love with Feedburner, but I don’t think so.

  6. Great comments folks. I’d just like to remind everyone that if you have specific questions or comments about Koan’s tutorial, you should probably raise those points in comments to her blog posting which contains her tutorial.


    – Amy Gahran

  7. Marshall – my concern isn’t with what FeedBurner does – it’s with what happens to your subscribers if the domain goes offline (and, yes, it *has* gone offline in the past). If your blog publishes a feed, say – and you use FeedBurner to reburn it as – sure, you still own *your* version of the feed. But your subscribers are subscribed to a feed that is coming from another domain than yours. If there’s an outage at the domain, your blog can merrily carry on pushing out new posts, and populating your version of your feed – but your subscribers won’t know, because *they’re* accessing a version of the feed on a server that isn’t serving.

    My recommendation, if you want to use FeedBurner, is to alias *their* version of your feed with something under *your* control – for example, create a DNS alias that points to – and have your subscribers subscribe to – that way, if goes down for an extended period (or permanently) you can point the thing that they’re subscribing to to a different feed burning service, or back to your base feed, or to a static file that explains what’s happening, or… anything you like – because *you’re* in control.

    Or, if you control your web server’s configuration, create a symbolic link, e.g. so that points to – then if goes offline, point to something else.

    Bottom line – *you* control – you *don’t* control – but you hand over availability of your content to them, if your subscribers subscribe to a feed with their domain name. If that’s not a concern for you, cool! I’m sure the customers of Purecast thought it was cool to have their subscribers point to a feed on – right up until the point when went off the air, permanently. And left those customers with no way to tell their subscribers where their new home would be.

Leave a Reply

Your email address will not be published. Required fields are marked *