There are plenty of great podcast-hosting providers, but some of them are committing podcasting sins that could make it harder for you to use them, or impair your podcast's performance.
I will not shame any hosting providers in this episode because they although some of them are doing these things wrongly at the time of publishing this episode, they might fix these problems later—maybe even by the time you're reading or listening to this! But I will praise some companies that do these things correctly. And keep in mind that just because I don't praise a particular company doesn't mean they're doing it wrong!
(I earn from qualified purchased through my affiliate links in this post, but I recommend things I truly believe in, regardless of earnings.)
Sin 1: not redirecting your podcast RSS feed
If you use your podcast-hosting provider's RSS feed for publishing your podcast, what happens if you ever want to leave that provider? You need to take your audience with you and not cause any interruption in their consumption of your podcast.
What hosting providers should do is allow you to permanently redirect their feed URL for your podcast to your new feed URL. This must be a 301 “permanent” redirect! And, ideally, it should remain redirecting forever, or at least for a year.
Learn more about redirects and how to use them in episode 280. In short, they're like a “change of address” you would file with your local postal provider. When you do that, you're asking for everything to forward to your new address. And you can get a service that notifies everyone sending mail to your old address that you've permanently moved and where they should send the mail from now on.
301 permanent redirects work that same way. By “permanent,” it doesn't mean “forever,” but it means it's never going to use that old URL again. A 301 redirect will immediately forward any request for your RSS feed to the new URL without even loading any content from your old feed. 302 and 307 temporary redirects do that, too. But the main difference is that the “301” code sent back to the apps tells them that the feed URL has permanently changed, it will never be at that old URL again, and thus the apps should stop looking at the old URL and look only at the new URL. At least that's how smartly developed apps are supposed to handle it!
If you can't forward your old feed URL to your need one, then you effectively lose almost your entire audience when you switch hosting providers. That's why it's so important to have this control, even if you don't own the actual URL. (And whatever “brand” is in the feed URL doesn't actually matter.)
But it's a good thing that most hosting providers (certainly all the ones I recommend) do offer feed redirects as an option. Libsyn used to charge a one-time fee for this, but they stopped charging for it several years ago.
If you absolutely must use a hosting provider that does not offer feed redirects, then use a third-party service—like Blubrry's Podcast Mirror or even FeedBurner—to protect your feed URL.
Sin 2: using unpredictable media URLs
Each episode of your podcast has its own unique URL for the media file. For example, my episode URLs on Libsyn are structured like this:
https://traffic.libsyn.com/noodlemx/tap411.mp3
That's actually the MP3 URL for this very episode, and I knew it would be that exact URL before publishing because its completely predictable! I know that for each episode, the only thing that will change is the filename, and that will be the same filename as what I upload. Blubrry and a few other provider also work this way.
But some hosting providers use seemingly random characters in the media URLs. For example, one provider would make my episode URL like https://provider.com/media/g438tgsh4ituh3tsdg4/tap411.mp3.
That would be okay if that string of random characters was unique to your podcast and repeated across all your episodes so that, like Libsyn and Blubrry, the only part that changes per episode would be the filename for each episode. But that's not how those other providers work. Those random characters are different for every episode. So the URL is completely unpredictable.
This is bad because it makes it extremely cumbersome to migrate to that hosting provider if you've embedded episodes on your website (whether through a built-in player or using your hosting provider's player). You can't run a find-and-replace operation on your website's database to replace all the old media URLs or embed codes with the new ones because the new URLs contain a string of character that's different for each episode. Not even regular expressions would help here! However, regular expressions could help you migrate away from such a hosting provider, because you could use a wildcard for the random string. That is, as long as your episode filenames stay the same!
And that's the other way some providers commit this sin. I was trying to help my friend Jessica Rhodes from Interview Connections facing the even worse version of this issue (and thanks to Jessica for inspiring this episode!). She was working with a provider that did actually keep the same path for the media URLs, but they replaced the filenames with something random and unpredictable! So absolutely no systematic find-and-replace operation could migrate to or from that—even with regular expressions!
The only way to change all the past embedded episodes is to update them all manually.
So if you're looking at a new hosting provider, check the media URLs for multiple episodes of other another show hosted with them and see if the URLs follow predictable patterns, or are randomized for each episode. Too many providers do it this way! And, frankly, I think it's probably because of ignorance, or worse, apathy and laziness.
Aside: this is something I knew I wanted to avoid with the chapter- and transcript-hosting that PodChapters provides. Although the URLs might look random, the randomized part of each URL is actually an account-wide string that never changes. For example, I already know that the transcript URL for this episode will be https://storage.podchapters.com/j973bkwgxk3jpd4j3mw02g6b717p8s52/tap411/transcript.vtt, with only the tap411 part being unique but predictable for each of my episodes.
Sin 3: changing your GUIDs
“GUID” stands for “globally unique identifier.” There are two types in podcasting: one for each episode, and one for your whole podcast.
The podcast GUID was born from Podcasting 2.0. Even though it will be generated based on your feed URL when the GUID is first generated, it should never change after that, even if your feed URL changes. So any good hosting provider should automatically inherit the same GUID when you migrate your feed. Blubrry, Buzzsprout, and I think Captivate and several other providers do this properly.
Your episode GUIDs are even more important. What is in the episode GUID doesn't actually matter. For example, any feed generated with WordPress usually uses your WordPress post's ID number in a URL (so it doesn't change if the friendly URL changes). For example, this post's GUID is https://theaudacitytopodcast.com/?p=37412. Some publishing tools make it a random string of characters. Either is perfectly acceptable. So the sin is when those GUIDs are changed either when you migrate to that provider or publishing tool, or if they have to change something in their backend. For example, even if the episode URLs change from “HTTP” to “HTTPS,” the GUIDs should not change; they are used as IDs, not as URLs.
Nearly all podcast apps use the GUIDs to track which episodes have been played, downloaded, ignored, and such. So if an episode's GUID is changed, nearly all podcast apps will think it's a new episode and redownload it, which will mess up your stats and probably confuse and even frustrate your audience.
Most podcast-hosting providers properly migrate the episode GUIDs on migration. But some don't.
Sin 4: improperly constructing your RSS feed
Finally moving away from migration-related sins, some hosting providers and publishing tools do bad things inside your RSS feed. Sometimes, it's for some concern for compatibility, but it seems to usually be from ignorance or oversight.
Here are some examples:
- A popular hosting provider puts the same text in three separate RSS tags on an episode:
<content:encoded>,<description>, and even deprecated<itunes:summary>. Multiply that by how many episodes are in your feed and that's a lot of wasted space, and it's really not even necessary! - That same hosting provider, and a few others, set the
<enclosure>tag'slengthattribute to 0 instead of setting the size of the media file in bytes. - A few popular hosting providers incorrectly populate your episode's
<itunes:title>and<title>tags with the exact same text. That's unnecessary and redundant, but it's even worse if you need episode numbers because they will put them in only<itunes:episode>tag but not in the more widely used<title>tag! I think Fireside handles this the smartest way; RSS.com might be doing similar soon; and Captivate, PowerPress, and Libsyn allow you to manually edit these separate title tags separately. - Some providers and publishing tools ignore the
<itunes:duration>tag. It is optional, but it's very helpful for podcast apps. Unfortunately, Apple says, “Different duration formats are accepted however it is recommended to convert the length of the episode into seconds.” - Some providers incorrectly format the episode's
<pubDate>tag, which is supposed to be the date of publication and it's supposed to follow a very specific date format, which not all providers respect. Surprisingly, Apple makes this tag only “recommended” instead of required. - Some providers don't let you change the
<link>URL for your episodes. This is crucial when your episode webpage is somewhere other than on the website your hosting provider gives you. Libsyn, Captivate, and Buzzsprout all let you edit this. PowerPress doesn't really need it because the primary usage of PowerPress is making a podcast feed from your own site. So the episode links are already pointing to your own webpage for that episode.
Some of these things you might uncover by looking at the raw XML code for a podcast's RSS feed from each provider. For example, if you see <enclosure length="0" …>, then you can know they're doing it wrong. But some of these other things, like the <link> tag might be an oversight on the podcaster's part and not the fault of the hosting provider.
Sin 5: stripping important data from your episodes
MP3s can hold a lot of important pieces of data that are good for compatibility, and sometimes vital for certain functionality and workflows.
For example, you can add your episode artwork to the MP3, and your hosting provider might automatically read that image and save it to the RSS feed and webpage for that episode. Captivate, Buzzsprout, Blubrry, Libsyn, and many other providers either use this image conveniently, or they keep the image in the MP3. Before you think this is unnecessary, this is actually how Overcast gets its image for your episode before falling back to your top-level podcast cover art.
The other important data in your episode could be legacy chapters embedded in the MP3. PodChapters exports chapters in your MP3, as JSON code for Podcasting 2.0, and as XML code for PodLove Simple Chapters. But even if your hosting provider doesn't support modern chapters, or they don't let you give your own chapters URL, your provider should still read the chapters from the MP3 data, keeping them there and even copying them to the other formats. This is why PodChapters is still useful (and likely better) if you host with a provider that offers their own chaptering tool.
Captivate, Buzzsprout, Blubrry, and Libsyn all keep your MP3's embedded chapters untouched unless you use their chapter tools to change the chapters. But some providers won't copy all the chapter data, or they actually remove your chapters! For example, one popular provider will properly read your chapter titles and timestamps, but then they ignore any links or images in your chapters.
Sin 6: not optimizing your media
There are, unfortunately, still several technical standards podcasters need to know. But I would love to see these be unnecessary for podcasters to think about because their hosting providers and publishing tools optimize these things appropriately.
For example, Buzzsprout's base plans will re-encode your podcast audio down to 96 kbps mono only if you upload something higher than that. This ensures you're publishing the right format of media and at an optimal quality level. You could also upgrade your Buzzsprout account to include “Magic Mastering,” so they fix your loudness levels automatically and let you publish in stereo. That's a smart feature!
But some hosting providers will let you upload anything—even an uncompressed WAV file that could be 100× bigger than it should be or other audio file formats that most podcast apps don't support.
Images are another thing. Some providers let you upload any kind of image, even if it's too big, too small, the wrong shape, or its other technical specs are incorrect. Ideally, the publishing tools should warn you when you're uploading something with the wrong specs, and potentially provide the tools to fix it.
On PodChapters, I'm working to make it do some of this optimization automatically, or with a simple button. For example, if you upload an image that's too big for a chapter (by file size or pixel dimensions), PodChapters could automatically downscale that image for the embedded chapters (where a small size is very important), and then do different optimizations for the Podcasting 2.0 and PodLove chapters.
The same could go for text data, too. Publishing tools should strip out unnecessary HTML code (like you might frequently get when pasting from a document-editing app such as Google Docs or Microsoft Word) and they should automatically-validate your RSS feed whenever you publish.
Of course, this shouldn't really matter if you do things right on your side. But I believe that podcasters shouldn't have to know technical things like bitrates and loudness levels. I want podcasting to “just work” so you can focus more on your content and your audience.
Sin 7: unnecessarily optimizing your media
Yes, sometimes your media should not be optimized!
Years ago, I stumbled into running multiple performance tests on podcast-hosting providers and I made some interesting additional discoveries. One of those discoveries was that some hosting providers would forcefully re-encode your MP3s, even if you had already encoded them perfectly to the spec! One provider re-encoded up to a higher level, which didn't actually improve the audio quality and only wasted space, bandwidth, and processing time. Some providers don't re-encode your media no matter what (see sin #6 for that!), but I like the way Buzzsprout handles it: they will only re-encode down if your media file is above their spec. But if you upload an MP3 that's already at or below their spec, they won't re-encode it.
A similar thing could happen with images. Maybe you upload a perfectly compressed image that's only 20 KB, but the publishing tool converts that image to a different format, possibly making the file size 10× larger than it needs to be, and maybe even making the image look worse.
Need help picking a podcast-hosting provider? I still regularly recommend Captivate, Buzzsprout, Blubrry, and Libsyn!
Special thanks
- Lyndsay Phillips had me as a guest on Leverage Your Podcast to talk about engaging your podcast audience. Go listen to it!
- Podfest Multimedia Expo accepted my session proposal, so I will be sharing “What You Need to Know About Podcasting 2.0” at Podfest! Please join me at Podfest, January 15–18, in Orlando, Florida!
If you love The Audacity to Podcast and value the podcasting inspiration and education I provide, would you please consider giving back what it's worth to you?
Supercharge your podcast engagement and grow your podcast!
Do you ever feel like your podcast is stuck? Like you're pouring your heart into your podcast but it seems like no one is listening?
Try Podgagement to help you supercharge your podcast endgagement!
Get speakable pages to simplify engaging with your audience, accept voicemail feedback (with automatic transcripts), see and share your ratings and reviews from nearly 200 places, follow your podcast rankings across nearly 34,000 global charts, discover networking opportunities, and more!
Ask your questions or share your feedback
- Comment on the episode
- Send a written or voicemail message here
Follow The Audacity to Podcast
- Apple Podcasts, Spotify, other Android apps, or in your favorite podcast app.
- Subscribe on YouTube for Podcasting Videos by The Audacity to Podcast
- Follow @theDanielJLewis on X-Twitter
Disclosure
This post may contain links to products or services with which I have an affiliate relationship. I may receive compensation from your actions through such links. However, I don't let that corrupt my perspective and I don't recommend only affiliates.
Related Content
