Beware these 7 deadly sins in podcast hosting providers.

Thank you for joining me for The Audacity to Podcast.

I'm Daniel J.

Lewis.

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 those providers or impair your podcast performance.

I won't shame any hosting providers in this episode because although some of them are doing things wrongly at the time of publishing this episode, they might fix these problems later, maybe even by the time you're hearing this episode.

But I will praise some companies that do things correctly.

And keep in mind that just because I don't praise a particular company doesn't necessarily mean they're doing it wrong.

If you'd like to follow along in the notes for this episode, they are a simple tap or swipe away or at the idacityto podcast.com/hostingsins.

Sin number 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, and this must be a 3 0 1 permanent redirect.

Ideally, it should remain redirecting forever and ever, forever, and ever.

Hallelujah.

Yes.

Hallelujah.

If they redirect it forever, at least they should redirect it for a year, but really forever.

And you can learn more about redirects and how to use redirects in podcasting in my episode 280.

I've got the link to that in the notes.

Tap or swipe away or at the audacitytopodcast.com/hostingsins.

In short, they're like a change of address when you use a 3 0 1 redirect or any kind of redirect.

Kind of like you would use with your local postal provider.

When you do that at the local post office, for example, you're asking for everything to forward to your new address.

And sometimes you even have a special service that notifies everyone sending mail to your old address so they know that you've permanently moved and where they should send the mail from now on.

3 0 1 permanent redirects work that same way.

And by permanent, that doesn't mean forever in this case.

Even though the redirect should stay there forever, the meaning isn't necessarily forever.

But it means it's never going to use that old URL again.

A 3 0 1 redirect will then immediately forward any request for your RSS feed to the new feed URL without even loading any content from that old feed.

There doesn't even have to be content there.

It can simply be a URL that's redirecting.

So whatever is in that old RSS feed doesn't matter if it's redirecting through any kind of standard redirect.

But a 3 0 2 and a 3 0 7 redirect are both temporary redirects that can do the same thing, but the main difference is that 3 0 1 part and the 3 0 2 and the 3 0 7.

Those are technical computer codes that send that code back to the apps, telling them, in the case of a 3 0 1, that the feed URL has permanently changed.

It will never be at that old URL again, and thus, the app should stop looking at that old URL and look only at the new URL.

At least, that's how smartly developed apps are supposed to handle it.

I think there are some apps out there that don't do that.

When they see a 3 0 1 redirect, they'll just check it every time and forward to the new feed.

But what they should do is they check it once and they see, oh, it's a 3 0 1 redirect.

I should never check this ever again.

And instead, I should get the feed from whatever this redirect is pointing me to.

That's the way the app should work.

And shame on those apps that don't work that way.

If you can't forward your old feed URL to your new 1, 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, whether that's Libsyn or Captivate or even FeedBurn or anything like that.

Whatever brand is in that URL, whatever it says does not matter.

Whatever the slug is does not matter.

What matters is that you have the control to point that URL where you want it to go if you ever need it to go somewhere else.

But it's a good thing that most hosting providers, and certainly all the ones that I recommend, do offer feed redirects as an option.

Years ago, Libsyn used to charge a 1 time fee to create that permanent redirect for your feed, but they stopped charging for that 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 in its very raw vanilla state to protect your feed URL so that if you ever need to change, you can just switch that in that third party service.

But ideally, you shouldn't have to use that because you should just be using whatever feed performs the best from your feed hosting provider, and that would redirect if you ever need to move from that.

Whether that's a feed hosting provider, a podcast hosting provider, your own website, your own domain, whatever it is, you need to be able to redirect that.

And ideally, that redirect should remain in place for forever and ever.

Hallelujah.

Hallelujah.

Send number 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, httpscolon//traffic.libsyn.com/noodlemx.

Yes.

My old network name is still in there, but that doesn't matter.

Did you even know that was in my URL for my media?

So it's /noodlemx/tap411.mpthree.

And that tap 411DotMP3, that's the filename of my episode.

That's how I save it on my computer.

That's how I upload it to Libsyn, and it's still there in the URL.

And that is the actual m p3 URL for this very episode, and I knew it would be that exact URL before publishing this episode because it's 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.

So for episode 4 12, it will be that exact same URL, but the filename will be tap 4 12 dot m p 3.

Blubrry and a few other providers also work this way too, and that's fantastic that they do.

But some hosting providers use seemingly random characters in the media URLs.

For example, 1 provider would make my episode URL look like httpscolon//provider.com, whatever that provider is, /mediaslash, and then a string of completely random characters /tap411.mpthree.

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 Blueberry, the only part that changes per episode would be the filename for each episode.

And you would know that filename because you made it and you uploaded it.

But that's not how those other providers work.

In fact, some that I really like don't work this way.

Those random characters are different for every episode.

So that URL for the m p 3 file is completely unpredictable because that string of random characters changes every time.

This is bad because it makes it extremely cumbersome to migrate to that hosting provider.

You'd think they'd make this easier for people to migrate to them.

It's hard when you have embedded episodes on your website, whether you've embedded a built in player through a WordPress plugin or something like that that your provider for your website offers you, or if you're using your hosting provider's player, like from Captivate or Libsyn or whoever.

So when you're doing that and you're trying to migrate to 1 of these hosting providers that does not use a predictable URL, you can't run any kind of find and replace operation on your website database to replace all them old media URLs or embed codes with the new ones because the new URLs contain a string of characters that's different for each episode.

Not even regular expressions would help here if you're familiar with how to do regular expressions, wildcards, and all kinds of fancy things like that.

However, regular expressions could help you migrate away from such a hosting provider because you could use a wildcard for that random string.

So you're searching for hostingprovider.com/media/wildcard/ and replacing that with whatever your new URL is, leaving the filename the same.

That is as long as your episode filenames stay the same between your hosting providers.

And that's the other way some providers commit this sin.

I was trying to help my friend Jessica Rhodes from Interview Connections facing this 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.

That's everything except the file name, but they replaced the filenames with something random and completely unpredictable.

So absolutely no systematic find and replace operation could migrate to or from that, even with regular expressions.

Shame.

Shame on you.

The only way to change all the past embedded episodes then is to update them all manually.

And ain't nobody got time for that.

If you're looking at a new hosting provider, check the media URLs for multiple episodes of another show hosted with that same provider and see if those URLs follow predictable patterns.

Don't just see random characters and think, oh, no.

That's bad.

Look for if those random characters change for every episode.

Too many providers do it this way, and they don't have to.

Frankly, I think they do it because either they're ignorant of the problems they're creating or worse, they're apathetic and lazy.

And an aside to this, this is something I knew I wanted to avoid with a feature that I built into PodChapters that helps you create chapters for your podcast and can even host your chapters and your transcript by giving you URLs for those things.

So that's where this comes into play.

Although the URLs from PodChapters look random, the randomized part of each URL is actually an account wide string that never changes.

So for each episode, the only thing that changes is the name of that episode file, which is based on whatever you upload.

So if you know the name of the file you're uploading, you can predict what the URL will be.

For example, I already know that the transcript URL for this very episode will be httpscolon//storage.podchapters.com/j973bkwgxk3jpd4j3mw02g6b717p8s52/tap411/transcript.vtt.

With only that tap 4 1 1 part being unique but predictable for each of my episodes, that whole random string of characters that I read off to you, and that is exactly what it would be.

I think I got all of those right.

It is the same for every episode because that is an account wide stream.

So that this is I kind of called this the Adam Curry feature in my planning for this because something that Adam does when he publishes an episode of any of his podcasts is he publishes the episode first because he wants to get it out there to his audience as quickly as possible.

He goes back and adds the chapters later or someone does that for him.

So he wants to be able to link to the chapters and the transcript right away.

So he needs a predictable URL even if there's nothing at that URL yet or it's empty.

That's something that you can do with a predictable URL like that.

And that's why I built that into PodChapters that way, because I I wanted it to be predictable so that podcasters could put that in and simply replace that 1 little part with what they already know it should contain.

But if your media URLs with your hosting provider change and have random characters that change for each episode, you have no predictable pattern that makes it very difficult to migrate to them and also migrate from them.

You would think that if it made it harder to migrate away from them, that that would at least justify why they might be not so interested in enabling that, but they're also might making it even harder to migrate to them because of this problem.

And if you're facing the same problem, please let the new hosting provider know because some of them think this is not a problem.

If it is a problem for you, please let them know that it's a problem so that they can fix it.

Send number 3, changing your GUIDs.

GUID stands for globally unique identifier, and there are 2 types in podcasting.

1 for each episode and 1 for your whole podcast.

The podcast GUID was born from podcasting 2.

Even though it will be generated based on your feed URL when the GUID is first generated, that GUID should never change after that, even if your feed URL changes.

Because you can't reverse decode the GUID to figure out the feed URL.

It's just we're giving you this ID at this moment, and no matter what your feed URL is after this, that GUID should never change.

Any good hosting provider should automatically inherit the same podcast GUID when you migrate your feed.

Blubrry, Buzzsprout, and I think Captivate, several other providers do this properly for you when you're migrating your feed to them.

Your episode GUIDs are actually 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 ID number in a URL so that doesn't change even if you change the friendly or SEO friendly URL, but it's using a post ID that is hard coded into the database and you can't change that post ID number.

But that's being used inside of your WordPress site.

So for example, for The Audacity to Podcast, 1 of the GUIDs might be h t t p colon slash / the audacitytopodcast.com/ question mark p equals 7 3 7.

I I don't know what's a 7 3 7, but that's an example of a GUID.

Now even though it looks like a URL, it's not treated like a URL.

Some publishing tools make it a completely random string of characters, and either of these are perfectly acceptable because what's in the GUID is not what's important.

What is important is that they never change.

So the SYN is when those GUIDs or some people pronounce them GUIDs are changed either when you migrate to that provider or publishing tool or if they have to change something in their back end and that might change your GUIDs.

This might be a problem that you run into if you do some kind of find and replace on your own WordPress database, and your WordPress site is creating your RSS feed.

Make sure that any kind of find and replace operation does not affect the post GUIDs.

And you can run into this also, for example, if you're changing from HTTP to HTTPS.

The GUIDs should not change.

And what's in them, again, does not actually matter.

What matters that is that they not change because they are treated as IDs, identifiers, not as actual URLs.

Although there is a technical thing that can treat them like URLs, but generally, they're not considered to be URLs.

Nearly all podcast apps use the GUIDs to track which episodes have been played, which have been downloaded, which have been ignored and such.

That's why the GUIDs are so important.

That's how the apps know which episode is which and what you've done with those episodes.

If an episode's GUID is changed, like, everything else could remain exactly the same about the episode in your RSS feed, even the media file and its URL don't change at all.

But if the GUID is changed, nearly all podcast apps will think it's a new episode and redownload it.

And that will then mess up your stats and probably confuse and maybe even frustrate your audience.

Just don't do that.

Don't let that be done to your podcast either.

Most podcast hosting providers properly migrate the episode GUIDs on migration to them, but some might not.

So if you're migrating your podcast to a lesser known, less popular hosting provider, then definitely ask them.

Check with them.

Even check your own RSS feed.

Look at your old RSS feed.

Look at the new 1 after they've completed their migration, and look for the GUID tag.

It will be all lowercase, GUID, and check it for a few episodes and make sure they are exactly the same.

Same capitalization even might matter in some cases.

They should be exactly the same, not a single character or capitalization off, not 1 jot or tittle off.

Sin number 4, improperly constructing your RSS feed.

We're finally moving away from some of these migration related sins.

Some hosting providers and publishing tools do bad things inside your RSS feed.

Sometimes it's for some concern for compatibility, maybe, but it seems to usually be from ignorance or oversight.

Here are some examples.

And again, I am not going to name who makes these mistakes because they might fix these problems, especially if they get a hold of this episode.

And if you know who those hosting providers are, feel free to send them this episode, but I am not going to throw anyone under the bus, at least not yet.

Here are some examples for this.

A popular podcast hosting provider puts the same text in 3 separate RSS tags on the same episode, and those tags are content encoded, description, and even the deprecated iTunes summary.

So it's the same exact text in 3 places for that episode.

And then 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 to have all of those populated.

I think all podcast apps will fall back to the description tag if nothing else is populated there for your show notes or the description of the episode.

So it's really not necessary to have all 3 of them there, especially not necessary for all 3 of them to contain the exact same text.

That same hosting provider is guilty of another example here, and a few others make this mistake, and that is the enclosure tag.

This is what turns an RSS feed into a podcast feed, is the enclosure.

That's where your m p 3 file or other media file is linked.

It's supposed to have an attribute to it called length, and that is supposed to be set to the size of the file, the actual file size in bytes, not kilobytes, megabytes, or anything like that.

And some of these hosting providers, the same 1 that I just gave an example from, put the number 0 in there.

So link equals 0.

No.

You should not do that.

You should put in there the file size in bytes.

A different problem is that a few popular hosting providers incorrectly populate your episodes iTunes title and normal title tags with the exact same text.

That's unnecessary for them to be the same, and it's redundant.

But it's even worse if your podcast needs episode numbers because some of these places that do this where they're putting the same title text in both title fields, which is unnecessary to do, they let you put in an episode number, and they put that episode number in the iTunes episode tag, and that is the right place for the episode number, but they don't do anything else with that episode number.

And that's the whole reason the iTunes title tag exists is so that you can put a title in there without an episode number in it.

So you can split the episode number into that iTunes episode tag.

But then the regular title tag should still contain the episode number.

And this is if episode numbers are important for your podcast.

And I'm going to do an episode coming up soon about episode numbers again because I've changed my mind on when it is important for your episode to have and use episode numbers.

But if you're using episode numbers and if you want your audience to see those episode numbers, then for full compatibility, they need to be in the normal title tag, and they should not be in the iTunes title tag.

There's some misunderstanding and misinformation out there about how these tags are supposed to be used, but this is the way it's supposed to be, is that the title tag is what nearly all podcast apps support.

Only a few podcast apps support iTunes title and iTunes episode.

So they would then display the episode numbers separately.

I think Fireside is the only hosting provider that does this in a smart way.

And rss.com might be changing to this similar because they asked me a whole lot of questions about this.

I got to demonstrate to them this is how this is working.

These are some ways that you could work with this to make this better.

But Captivate, PowerPress, Libsyn, and some others do allow you to manually edit these separate title tags separately so that 1 can contain an episode number in it.

That would be your normal title.

And the iTunes or Apple title would not contain the episode number because you would put that episode number in the episode field.

But the smartest way to do this is, I think, what Fireside does, and I've built this into a plug in for PowerPress that I hope to release to the public someday, where you can populate that episode number field, and then it automatically adds that to the normal title field at the beginning.

So it'd be, like, 5 period space and then the rest of your episode title, but it excludes it from the iTunes title tag.

And someday when there's a podcast colon title tag, it would exclude it from there too.

That's the smart way to do it.

The next best way to do it is what some of these other providers do, that is they let you have an additional field where you can enter these titles separately.

That's not exactly the best way to do it, but it at least it does give you full control to do it exactly the way you want it to be.

Moving on, some providers and publishing tools ignore the iTunes colon 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.

Okay.

Yeah.

But they're also saying that something like minutes colon seconds could work if you're putting that format in there.

I wish they would just say, this is the way it should be done and only this way.

But some publishing tools don't put that in there at all.

And so if your feed doesn't have that, then some podcast apps might not be able to display to the user how long the episode actually is unless those podcast apps start downloading the file and then pull information from the file itself.

Another example of something that these publishing tools and providers do is that some providers incorrectly format the episode's pub date tag.

That's supposed to be, as you could probably guess, the date of publication, and it's supposed to follow a very specific date format, which unfortunately not all providers respect.

Surprisingly, Hubbell makes this tag only recommended instead of required.

Moving on, some providers don't let you change the link URL for your episodes.

This is crucial when your episode web page is somewhere other than on the website your podcast hosting provider gives you.

Libsyn, Captivate, and Buzzsprout all let you edit this link.

PowerPress doesn't really need to let you edit 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 web page for that episode.

That's why you don't need to edit it if you're using PowerPress.

But if you're using some other publishing tool and you're using that separate from your website, you need to be able to set that link to the web page for your episode because many podcast apps will let the audience member tap on a link to visit the web page for the episode.

And you don't want them going to some ugly looking website that you haven't done any branding on.

You want them to go to your website.

So you need to be able to set that link, and some providers don't let you set that.

Some of these examples I've given, you might uncover by looking at the raw XML code for a podcast RSS feed from each provider.

Now that's a lot of letters I just said, so that might scare you a bit.

But for example, you might see enclosure with length equals quotation 0 quotation.

If you see that in the feed, then you can know they're doing it wrong.

Some of these other things, like how they're handling the link tag or description or content encoded and some of this other stuff might be an oversight on the podcaster's part and not the fault of the hosting provider.

Unfortunately, some of these things you might just not discover until you actually start using that podcast hosting provider.

That's what I ran into a few months ago when I was considering moving my hosting provider and how I was generating my RSS feed.

There are several hosting providers I really like.

But for myself, not for you necessarily that I would recommend that you do some of these things, but for myself, there were some very, very specific things that I wanted to do with my podcast RSS feed and certain ways I wanted it to behave.

And it wasn't until I actually started using some of these providers that I discovered, oh, they don't do this right.

Or at least how I create my podcast.

They're not handling this particular thing in the right way.

Like, the iTunes title thing is 1 of those things that couple of hosting providers that I tried didn't handle that properly.

Or there were a couple of other things where I didn't have the control that I wanted, and so I ended up just deciding to stick with PowerPress and making an extension to PowerPress that would make certain things behave exactly how I want them to behave, as well as some other cool things too to support some cutting edge features.

I'd love to release that plug in for free in the future.

We'll see if I can do that.

There are just some legal issues I need to work through.

Not that I'm in trouble.

I want to make sure I respect certain trademarks and such.

So I'm talking to the trademark owners to make sure that I do this respectfully in a way that they're okay with.

You can watch for that.

I'll let you know when I release that.

Moving on to sin number 5, stripping important data from your episodes.

M p threes can hold a lot of important pieces of data that are good for compatibility and sometimes vital for certain functionality and workflows in your podcasting.

For example, you can add your episode artwork to the m p 3, and your hosting provider might automatically read that image and save it to the RSS feed for the iTunes image and maybe even the podcast image for podcasting 2, and maybe embed it on the web page for that episode.

Captivate, Buzzsprout, Blubrry, and many other providers either use that image conveniently or in the least, they keep the image in the m p 3, and they don't strip it out or do anything bad to it.

Before you think it's unnecessary for that image to be in the m p 3, regardless of the workflow aspects of this, there are some podcast apps that actually use that image for the episode image.

So if episode specific images are important to you, then you need to make sure that your hosting provider is not committing this sin.

Overcast, for example, still gets its image for your episode from the m p 3 file.

And if there isn't an image in your m p 3 file, then Overcast will fall back to your top level podcast cover art to display for that episode.

And there's nothing wrong with that.

But if you want episode specific artwork, then you have to put it in your m p 3 file, and your hosting provider has to keep that image there in the m p 3 file, as well as put it in other places for optimal compatibility.

The other important data in your episode could be legacy chapters embedded in the m p 3.

Pod chapters exports chapters in your m p 3 and as JSON code for podcasting 2 and as XML code for PodLove simple chapters as well as some other formats that exports that you can use in different ways.

So try it out.

Try PodChapters free for 7 days over at podchapters.com.

But even if your hosting provider doesn't support modern chapters like Podcasting 2 or even PodLove simple chapters, which aren't the most modern, but they're still more modern than the legacy m 3 chapters.

Or even if they don't give you the option to paste in a URL for your Podcasting 2 chapters, like what PodChapters can host for you, they should at least still read the chapters from the m p 3 file and keep them there.

What would be better is that they read those chapters from the m p 3 data and then copy them to the other formats.

This is why PodChapters is still useful and likely much better than the tools that you get with your podcast hosting provider for making chapters.

Because you can create your chapters with PodChapters, embed them in the m p 3, and then upload them to some of these publishing tools and hosting providers, and they will read those chapters and copy them to the other places.

For example, Buzzsprout does this really well, where when you upload your m p 3 that already has chapters in it, even though you can't give Buzzsprout your podcasting 2 chapters, if your m p 3 file has chapters in it, Buzzsprout will copy those chapters to podcasting 2 format and Podlove simple chapters.

So, again, it's about the workflow in this case, not just the compatibility, but the workflow is there to go from 1 format to the other because your hosting provider is doing that for you.

Captivate, Buzzsprout, Blubrry, and Libsyn all keep your m p threes embedded chapters untouched, unless you use their chapter tools to change those chapters.

Then, of course, they're going to edit the chapters.

But if you upload chapters just the way you want them, then those providers will not change those chapters.

But some providers won't copy all the chapter data, or they actually completely remove your chapters.

For example, 1 popular provider will properly read your chapter titles and time stamps, and that might be enough for you.

But chapters can also contain links and images.

But this provider that I'm referring to doesn't copy those links and images into the other chapters.

Even though they'll copy your titles and the correct time stamps into your podcasting 2 chapters, they won't copy any links you have or any images you have.

You'll have to re add those in their system.

That's something they're aware of, this particular provider I'm thinking of, and it's something I would love to see them fix.

So if you're using PodChapters and you're using this other provider and you know who they are and you know the shortcoming that they have, please kindly request that they fix it.

Sin number 6, not optimizing your media.

There are, unfortunately, still several technical standards podcasters need to know about.

But I would love to see these be unnecessary for you to ever think about because your hosting provider and publishing tools optimize those things appropriately for you.

For example, Buzzsprout's base plan will re encode your podcast audio down to 96 kilobits per second 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 what they call magic mastering, so they fix your loudness levels automatically and even let you publish in stereo.

Those are both really smart features that they support.

Yeah.

At an additional cost, but that might be worth it to you if you don't want to do that stuff like the magic mastering and the loudness levels and stuff.

If you don't want to manage that before you upload, they can fix that for you after you upload.

Or do it yourself, and you don't have to pay for that upgrade.

But they do a really good job at it.

But some hosting providers will let you upload anything, even an uncompressed WAV file that could be a 100 times bigger than it should be, or another audio file format that most podcast apps don't support.

And they'll just let you publish your episode like that.

And you might never realize it's broken until your audience says, hey, your episode doesn't play, and you're trying to figure out why is it broken, why isn't it working.

You're going back and forth.

I uploaded this audio file.

The audio file plays perfectly on my computer.

I upload it again.

It still plays perfectly.

Why isn't it working in my RSS feed?

And you might realize then or maybe the hosting provider points out to you, oh, hey, you uploaded an uncompressed WAV file and yet filled up your account, and don't do that.

You shouldn't publish WAV files.

You need to publish an m p 3 or another popular audio or video format depending on what you're publishing.

Their system should do that for you automatically.

It should convert it from WAV to m p 3 in the correct format for you if you're uploading the wrong format.

But if you upload the right format, they shouldn't convert it.

That you shouldn't have to worry about it.

Either way, you should just be able to upload your audio and know that it will publish in the correct format.

Images are another thing related to this.

Some providers let you upload any kind of image, even Photoshop files.

But they might let you upload an image that's too big or too small, that's in file size or pixel dimensions, or maybe it's the wrong shape, like it's rectangular instead of square, or its other technical specs are incorrect.

Ideally, the publishing tool should warn you when you're uploading something with the wrong specs and potentially and optimally provide the tools to fix that.

Like if it's too big, file size or dimensions, it could pop up a little warning that says, hey, this file is too big.

Click here and we'll optimize it.

Or hey, this is too big.

We've automatically optimized it for you without compromising the visual quality of it.

Anything like that would be really cool.

On Pod chapters, I'm working to make it do some of this optimization automatically or with a simple press of a button.

For example, although some of these chapter images can be in your MP 3 file, they really shouldn't be big images by pixel size and especially by file size.

So what could happen is that when you upload an image that's too big for a chapter, Pod chapters could automatically downscale that image for the embedded chapters, where a small size is really important, and then do different optimizations for the Podcasting 2 and PodLove chapters.

That way, you don't have to think about it.

It just does it automatically for you and does it the correct way so that you don't have to worry at all.

The same could go for text data too.

Publishing tools should strip out unnecessary HTML code or weird formatting like you might frequently get, and maybe you've even run into this in the past when you're pasting from a document editing app like Microsoft Word or Google Docs or even sometimes Notepad or a Notes app can have certain hidden formatting in it that starts to just make stuff look weird or function weirdly inside your podcast app or it breaks something weird.

And speaking of breaking things, they should also automatically validate your RSS feed.

Now if they're not doing these optimizations, this isn't necessarily the worst sin.

That's why this is farther down the list.

Not necessarily.

It's probably the lowest priority, but I've got this in this particular order because of the flow.

And of course, many of these things shouldn't really matter if you do things right on your side.

Like the whole uploading a WAV file and having the hosting provider convert it to an m p 3 file for you.

That shouldn't matter if you're giving an m p 3 file that is already in the correct format.

But I believe that podcasters shouldn't have to know these technical things like bit rates and loudness levels and image compression and image formats and dimensions and file sizes and all of that stuff.

I want podcasting to just work so you can focus more on your content and your audience.

And that's why many of the tools that I create now, especially the 2 biggest tools I have, Podgagement and PodChapters, there are a lot of things that I've put into this with deep love and passion for podcasting.

Certain things that I want it to just work so you don't have to think about it.

Just throwing out another example here.

In Podgagement, you get multiple landing pages, like a followthepodcast.com and lovethepodcast.com that can display links to your podcast in different apps.

Those pages automatically, smartly show and hide certain apps based on what kind of device is visiting the page.

So if someone is on Android, for example, they won't see an Apple Podcast link or an Overcast link because those are for Apple products generally.

If someone is on Windows, they will see an iTunes link because it is still iTunes on Windows, and they'll see that instead of Apple Podcasts.

And if someone is on an Apple device, they won't see, for example, a Podcast Addict link because Podcast Addict is only for Android.

So they shouldn't see Android apps.

That kind of thing, the landing pages just do that automatically.

You shouldn't have to think about it.

You should just know, I send people to this page.

They'll see links that can work on their devices, so you don't have to think about it.

And so, certainly, you don't have to try and code that information yourself.

So right after saying sin number 6 is not optimizing your media, sin number 7 is 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 in that process.

1 of those discoveries was that some hosting providers would forcefully re encode your m p threes even if you had already encoded them to the spec perfectly.

1 provider actually re encoded up to a higher level.

So if you uploaded a 64 kilobit per second mono file, they might re encode it up to, we'll just say, 128 kilobits per second stereo.

There was no need for them to do that.

Or if they were even going up to 96 or 1 20 or 1 60 or any higher number, there's no need for them to do that.

It's not improving the audio quality.

It's only wasting space and bandwidth and processing time.

Some providers don't re encode your media no matter what and see SIN number 6 for that.

But I like the way Buzzsprout handles this.

They will only re encode down if your media file is above their spec.

But if you upload an m p 3 file that's already at or below their spec, they won't re encode it.

So if you upload 96 kilobits per second mono, Buzzsprout does not re encode it.

If you upload 64 kilobits per second mono, Buzzsprout does not re encode it.

Similarly, with Captivate and Blubrry and Libsyn and several other podcast hosting providers, they will not unnecessarily re encode your media.

And that's good that they don't re encode it when it shouldn't be re encoded Because some of these platforms are just trusting that you know what you're doing and that you encoded it properly or whatever publishing tool you're using to create the m p 3 file did it correctly for you.

But hosting providers should not re encode it if it doesn't have to be re encoded.

There's 1 particular provider that's been on multiple of these naughty lists and things I've mentioned in here.

They're committing multiple sins.

And what they do is they forcefully re encode the file even at the exact same encoding specs.

But for some reason, their re encoded version ends up bigger than what the podcaster uploaded, and they stripped the chapters completely from it.

And 1 of my listeners knows exactly what I'm talking about because they signed up for PodChapters.

They were so excited to use PodChapters to create chapters for their podcast.

They added all these great chapters.

They loved how PodChapters work.

They uploaded it to their podcast hosting provider that their podcast network uses, and they couldn't figure out why their chapters weren't working.

And the reason is their hosting provider stripped the chapters and metadata from the file, reencoded it unnecessarily, and that's probably why all the metadata was stripped from it, losing all of those chapters.

And they served that reencoded version even though their reencoded version was at the exact same encoding specs as what the podcaster uploaded, but the hosting provider's version was a bigger file.

Make it make sense.

They're certainly not doing it correctly.

Shame on them.

Shame.

Shame.

A similar thing can happen with images.

Maybe you upload a perfectly compressed image that is optimized to whatever pixel level degree that you want.

And it maybe it's only 20 kilobytes in size.

But the publishing tool then automatically converts that image to a different format, possibly making the file size 10 times larger than it needs to be, or maybe even making the image look worse depending on the compression method that they're using for that image.

Just for example here, PNG is really good for images that contain a lot of solid color, Like The Audacity to Podcast cover art is great in PNG.

And most of the episode images that I make work really well in PNG.

And that's why I save them as PNG because they have a lot of solid colors, and they're not very varied in colors.

They're not photographs or anything.

They're illustrations.

They look like vector while they're made from vector art, which is scalable.

So they work really well as PNGs.

Convert the same image to a JPEG, and it's going to be a much bigger file if you try to maintain the same crispness.

If you try to get its file size down to the same size as the PNG, then it starts getting blocky and blurry.

I don't want any system that does that, that unnecessarily tries to optimize my file by converting it to JPEG when I wanted it to stay as PNG because the PNG I gave is the proper format.

So these 7 deadly sins that podcast hosting providers might be committing are number 1, not redirecting your RSS feed.

Number 2, using unpredictable media URLs.

Number 3, changing your GUIDs.

Number 4, improperly constructing your RSS feed.

Number 5, stripping important data from your episodes.

Number 6, not optimizing your media.

And number 7, unnecessarily optimizing your media.

If you catch your hosting provider committing 1 of these sins, feel free to send them this episode.

And know that I have not put anyone under the bus here.

Although, some providers, I think, kinda deserve it, but I'm not going to do that because I want to give them the chance to improve things.

And you can send them this episode to point out to them, this is why this matters.

Here's more information about this.

This is really important to me, and I think maybe some other podcasters, please change this.

So if you send anything to your podcast hosting provider, if you complain, please do it kindly and give them the chance to make things right.

And if they won't, then you could consider switching.

And if you need help, let me know who you're looking at and what particular features are most important to you, and I can help you pick the right hosting provider for you.

Because I don't recommend just 1 particular provider.

And by the way, if you look at the notes for this episode, some of my links will be affiliate links.

And that's because many of these providers, I do recommend in certain context for certain uses.

So depending on what you need, I'll recommend the hosting provider for you.

The links for all of this that I shared, some of these past episodes and other references are at the audacity to podcast.com/hostingsends.

Special thanks to Lindsay Phillips who had me on her podcast as a guest.

Her podcast is leverage your podcast, and she had me on to talk about engaging your podcast audience.

It was a really fun conversation.

We did talk a lot about Podgagement in that episode, but also just about engaging your audience in general because that's what Podgagement was designed to help you do.

So please go listen to that episode from Lindsay Phillips.

I've got the link to that in the notes.

And thanks to Podfest Multimedia Expo for accepting my session proposal for Podfest 20 26.

I'm thrilled to be sharing what you need to know about podcasting 2 at Podfest, so I would love to have you there in the audience.

Please join me at Podfest January in Orlando, Florida.

I've got the link to podfestexpo.com in the notes or, hey, I just mentioned the URL for you.

And those notes are once again at the audacitytopodcast.com/hostingsins.

Now that I've given you some of the guts and taught you some of the tools, it's time for you to go start and grow your own podcast for passion and profit.

Please check out my new product, podchapters.com, now available with a free 7 day trial over at podchapters.com.

I'm Daniel J.

Lewis from theaudacitytopodcast.com.

Thanks for listening.