A Practical Guide to Podcast RSS Feeds

Podcast RSS feeds are the plain text files that tell every podcast app what your show is, which episodes exist, where the audio lives and how the listing should look. Apple Podcasts, Spotify, Overcast, Pocket Casts and dozens of smaller apps all read the same feed. When you publish an episode, you are not really uploading it to those apps; you are adding a new item to a file they check on a schedule. If that file is correct, episodes appear everywhere within minutes to hours. If it is wrong, episodes go missing, duplicate themselves, show the wrong artwork or disappear from a directory altogether.

This guide is for the people who carry that risk: business owners running a branded show, marketers who inherited a podcast from an agency, in-house producers switching hosting platforms, and editors who want to understand what happens to their files after export. It is organized as a checklist. The master list comes first, and each section after it explains why an item matters, what "done well" looks like and where teams usually slip.

You do not need to hand-write XML to follow along. Most shows use a hosting platform that generates the feed for them. But you do need to know what the platform is producing on your behalf, because the host only writes what you type into it, and a handful of feed decisions, especially around episode identifiers and host migrations, are very hard to undo once apps have cached them.

What a Podcast RSS Feed Actually Contains

A podcast feed is an RSS 2.0 document with extra, podcast-specific tags layered on top. The outer channel element describes the show as a whole. Inside it, each item element describes one episode. The standard RSS tags cover the basics, such as title, link, description, publish date and a unique identifier. The additional tags come from namespaces, which are vocabularies declared at the top of the file. The most important one is the itunes namespace, originally defined by Apple, which carries categories, explicit content flags, artwork, episode numbers, show type and several other fields that most podcast apps now read, not only Apple's.

Three elements do most of the heavy lifting. The enclosure element on each item points to the episode's audio file and states its size in bytes and its MIME type, which is how an app knows what to download. The guid element gives each episode a unique identifier that apps use to recognize it on every future check of the feed. And the channel-level itunes:image element points to the show artwork that appears in every directory listing.

Apps do not stream your feed live. They fetch it periodically, compare it with the copy they stored last time, and update their own databases. That caching behavior explains most feed problems. A change you make today is interpreted against what the app already believes about your show, which is why some mistakes, like changing identifiers, cause visible damage even after you correct them.

Where the feed lives

Your feed has a URL, usually on your hosting platform's domain or on a custom domain the host lets you point at it. That URL is what you submit to Apple Podcasts, Spotify and other directories. Once submitted, it becomes the permanent address of your show in their systems. Treat it the way you would treat a domain name: something you control, document and never let lapse. Record the feed URL, the account that owns it and the login details for each directory in the same place your team keeps other critical credentials.

The official requirements change over time, so bookmark the primary documentation rather than relying on blog summaries. Apple publishes its current feed and artwork rules through Apple Podcasts for Creators, and Spotify documents its delivery specifications through Spotify for Creators. When a third-party guide, including this one, disagrees with those pages, the platform's own documentation wins.

Checklist Item 1: Choose a Host That Generates a Clean Feed

For almost every organization, the right answer is a dedicated podcast hosting platform that generates the feed automatically. The host stores your audio, serves it quickly to listeners around the world, writes the RSS for you, and usually adds analytics and distribution shortcuts. The alternative is to host audio files on your own server or a general cloud storage bucket and maintain the feed yourself, either by hand or through a website plugin.

Before you commit to a host, check five things. First, whether the feed it produces declares the itunes namespace and fills in the tags Apple and Spotify expect. Second, whether it lets you set the fields covered in this checklist, including episode type, season numbers and per-episode explicit flags, rather than hiding them. Third, whether it supports a permanent 301 redirect and the itunes:new-feed-url tag when you leave, which is the single most important exit feature. Fourth, whether you can export all your audio and metadata in bulk. Fifth, whether its media servers support HTTPS and byte-range requests, which Apple's documentation lists as a requirement so that apps can seek within an episode and resume partial downloads.

If your show runs ads, check how the host handles dynamic insertion too. Hosts that stitch ads into the audio at download time change the file each listener receives, which affects file size reporting and how you plan break points. We cover that trade-off in detail in our guide to dynamic ad insertion in podcasts, done properly.

The pros and cons above are framed as managed hosting versus self-hosting because that is the real decision most teams face. Self-hosting makes sense for organizations with an engineering team that already runs media infrastructure and wants custom feed logic, such as private feeds per subscriber. For everyone else, the managed route removes a whole category of failure. If measurement matters to you, read podcast measurement standards and the decisions that matter before choosing, because the way a host counts downloads shapes every report you will produce afterward.

Checklist Item 2: Complete Every Show-Level Field

Show-level metadata lives in the channel element and controls how your podcast appears in directory listings, search results and category charts. Hosts usually present these as a "show settings" page. Incomplete fields rarely cause outright rejection, but they cost you discoverability and can trigger warnings or delays during directory review. Fill in all of them, and fill them in deliberately.

The fields that matter most

• Title. The show's name, exactly as you want it displayed. Do not stuff keywords into it; Apple's guidelines discourage titles padded with search terms, and it reads as spam to listeners.
• Description. A plain, specific explanation of what the show covers, who hosts it and how often episodes come out. Apple caps show descriptions at 4,000 characters, but the first two or three sentences do almost all the work because apps truncate the rest.
• Language. An ISO language code such as en-us. Apps use it for regional search and recommendations.
• Author and owner. The author is the public name shown under the title. The owner name and email are used by directories to verify you control the show, and hosts often hide the owner email from the public feed on request. Use a shared team address, not one person's inbox.
• Category. One primary category and, where it fits, a subcategory, chosen from Apple's published list. Custom categories are ignored.
• Explicit flag. A true or false value for the show as a whole, covered in detail in item 6.
• Show type. Episodic (newest first, for shows that can be heard in any order) or serial (oldest first, for shows that tell a story across episodes). Choosing the wrong one changes the order new listeners encounter your episodes.
• Artwork. A square image referenced by itunes:image, discussed below.

Artwork is a feed field, not just a design file

Artwork problems are some of the most common reasons a new show is held up in review. Apple's current specification calls for square artwork between 1400 x 1400 and 3000 x 3000 pixels, in JPEG or PNG, in the RGB color space. The feed only contains a URL to the image, so the hosted file itself must meet the specification and stay available at that address. If you replace artwork, many apps will only pick up the change when the URL changes, so upload the new file rather than overwriting the old one in place. For the design decisions behind the image, including legibility at thumbnail size, see podcast artwork requirements and the decisions that matter.

Checklist Item 3: Fill In Episode Metadata Properly

Each item in the feed carries its own metadata, and this is where rushed publishing shows. An episode with a vague title, an empty description or a missing duration still plays, but it looks unfinished in apps and gives search engines within those apps nothing to work with.

• Title. The episode's own name, without the show name or episode number prefixed. Apple asks creators to keep numbers in the dedicated episode-number field rather than the title, and apps display the number separately.
• Description or show notes. A summary plus useful links. Most apps render a limited set of HTML, such as paragraphs, lists and links, when the host wraps the text correctly. Keep formatting simple.
• Publish date. The pubDate element in the RFC 2822 date format. Hosts set this automatically, but check it when you schedule episodes or import an archive, because an incorrect date can sort a new episode below old ones.
• Duration. itunes:duration, in seconds or as hours, minutes and seconds. Apps show it in listings.
• Episode and season numbers. itunes:episode and itunes:season. Required for serial shows to order correctly, and helpful for episodic shows with seasons.
• Episode type. itunes:episodeType set to full, trailer or bonus. A trailer tagged correctly can be surfaced as the show's preview; a bonus episode tagged correctly will not break your numbering.
• Episode artwork. Optional per-episode itunes:image. Useful for guest-led shows, but it must meet the same specification as show artwork.

The trailer point deserves emphasis. A short trailer marked with the trailer episode type gives new listeners a way into your show before they commit to a full episode. If you are planning one, our guide to podcast trailers and what actually works covers length, structure and when to replace it. For chapter markers, episode art and the finer points of episode fields, see how to get podcast chapters and episode metadata right.

Consistency beats perfection

A show with 80 episodes where half have numbers and half do not looks disorganized. Decide on a title convention, a show-notes template and a numbering rule once, write them into a one-page style sheet, and apply it to every episode. The same discipline that keeps loudness and intro music consistent across episodes applies to metadata; our piece on episode-to-episode consistency treats both as part of the same production system.

Checklist Item 4: Prepare Audio Files and Enclosures That Download Cleanly

The enclosure element carries three attributes: the URL of the audio file, its length in bytes and its MIME type, such as audio/mpeg for MP3 or audio/x-m4a for AAC in an M4A container. Apps rely on those values to decide how to download and play the file. A mismatch between the stated length and the real file size, or a wrong MIME type, can cause failed downloads, incorrect progress bars or episodes that refuse to play in some apps.

Hosts fill in these attributes automatically when you upload through them, which is another argument for managed hosting. The part that remains your responsibility is the file itself. Large, unoptimized audio files waste listeners' mobile data, take longer to start, fail more often on weak connections and, on some hosts, count against storage or bandwidth limits. Uploading a mastered WAV to a podcast host is a common mistake; even when the host transcodes it, you lose control over the final encoding.

Choosing a bitrate

MP3 remains the most broadly compatible delivery format. File size is simply bitrate multiplied by duration, so the arithmetic is predictable. At 128 kbps, one hour of audio is 128,000 bits per second times 3,600 seconds, or 460.8 million bits, which is about 57.6 MB. At 64 kbps it is about 28.8 MB, and at 192 kbps about 86.4 MB. For spoken-word shows, a mono file in the 64 to 96 kbps range is widely used and sounds clean on phones and earbuds; stereo at 128 kbps is a common choice when music or sound design carries weight. Beyond that, extra bitrate is rarely audible to podcast listeners and mostly adds download time.

Beyond bitrate, three details keep enclosures healthy. Embed basic ID3 tags, such as title, show name and artwork, in the MP3 so the file is identifiable when downloaded outside an app. Normalize loudness consistently in the master before export so listeners do not reach for the volume control between episodes; many producers target an integrated loudness around -16 LUFS for stereo podcast delivery, and you should confirm any platform-specific guidance in the documentation linked earlier. And keep filenames simple, with lowercase letters, numbers and hyphens, because spaces and special characters in URLs are a quiet source of broken downloads.

If your team edits in-house and exports its own masters, these settings belong in your export preset, not in someone's memory. Our podcast editing service delivers files to an agreed specification for exactly this reason: the enclosure is only as good as the file behind it.

Checklist Item 5: Keep Episode GUIDs Stable Forever

If you remember only one rule from this guide, make it this one. Each item's guid is the identifier apps use to decide whether an episode is new or one they already know about. When an app fetches your feed, it compares GUIDs against its database. A GUID it has not seen before means a new episode. A GUID it already has means an existing episode that may have updated details.

Change a GUID, and the app concludes the old episode vanished and a brand new one appeared. Listeners subscribed to your show may see a duplicate, may get the episode downloaded again as if it were fresh, or may see an old episode jump to the top of their queue. Change the GUIDs of your whole archive, which is what happens when a careless migration regenerates them, and subscribers can be hit with dozens of "new" episodes at once. That erodes trust and inflates download numbers in ways that are hard to explain later.

How GUIDs get changed by accident

• Deleting an episode and re-uploading it to fix a mistake, rather than editing the existing episode.
• Importing an archive into a new host that generates fresh GUIDs instead of preserving the originals.
• Self-hosted feeds that use the episode's URL as its GUID, then change URLs during a website redesign.
• Duplicating a show on a host to create a "clean" version and pointing directories at the copy.

The fix is procedural. Always edit rather than delete-and-recreate. When migrating, confirm in writing that the new host imports and preserves existing GUIDs, then check a sample of old and new feed items side by side before switching anything over. If you run a self-hosted feed, generate GUIDs as opaque unique strings, mark them with isPermaLink="false", and store them in your database so that nothing about your website structure can alter them.

The Podcasting 2.0 project defines an additional podcast:guid tag at the channel level, a stable identifier for the show itself that is meant to survive feed URL changes. Some hosts add it automatically. It does not replace episode GUIDs, and not every app reads it yet, but it does no harm and is worth enabling where your host supports it.

A simple safeguard backs all of this up: once a quarter, save a copy of your raw feed file with the date in its name. If a platform change or migration ever corrupts your identifiers, that archive tells you exactly what every GUID used to be, and gives your host something concrete to restore from.

Checklist Item 6: Set Explicit Content Tags Deliberately

The itunes:explicit tag tells directories whether your show or episode contains content that should be flagged for listeners, such as strong language or adult themes. Apple uses true and false as values today. The tag exists at both channel and item level: set the show-level value to describe the show overall, then override it on individual episodes where necessary.

Missing explicit tags are a common error and, for Apple Podcasts in particular, a reason a submission can be flagged during review. Getting the value wrong has consequences in both directions. A show marked clean that contains explicit material risks being removed or restricted after listener reports, and may reach audiences, such as younger listeners on managed family accounts, it should not. A show marked explicit that is actually clean can be filtered out by listeners and devices with content restrictions switched on, which shrinks its audience for no reason.

For branded and corporate shows, the practical rule is to set the show to false and to make one editor responsible for checking each episode before release. If a guest swears once in a 50-minute conversation, you have two options: bleep or cut the word in the edit, or mark that single episode as explicit. Decide the policy before recording, and brief guests accordingly; a good pre-interview briefing includes language expectations in the pre-interview briefing for this reason.

Checklist Item 7: Validate the Feed After Every Change

Validation means running your feed through a checker that parses the XML and compares it against podcast requirements. It catches malformed characters, missing required tags, unreachable artwork, wrong enclosure types and broken URLs before an app discovers them. Apple Podcasts Connect validates feeds as part of submission and flags problems on existing shows; many hosts include their own validators; and independent podcast feed validators are freely available online.

Validate after anything structural: a new show, a host migration, an artwork change, a custom domain for the feed, a change of category, or an import of an archive. Routine episode publishing through a reputable host rarely needs formal validation, but a quick spot check still pays off.

Warnings deserve judgment. A missing optional tag may be fine. A warning that your artwork is below the minimum size or that an enclosure returned an error is not optional in practice, because it will surface as a visible problem in some app sooner or later. Special characters are another frequent cause of validation failures: an unescaped ampersand in an episode title or show notes can break the XML for the whole feed. Good hosts escape these automatically, but self-hosted feeds and custom templates often do not.

Checklist Item 8: Redirect the Feed Properly When You Change Hosts

Changing podcast hosts is the highest-risk moment in a feed's life. Directories know your show by its feed URL. If you set up the show on a new host, the new host gives you a new feed URL. Unless the old URL points every app to the new one, subscribers stay attached to a feed that stops updating, and your new episodes never reach them.

A proper migration uses two mechanisms together. The first is a permanent HTTP 301 redirect from the old feed URL to the new one, set in your old host's settings. The second is the itunes:new-feed-url tag, added to the old feed, which tells Apple Podcasts and other apps that read it to update the stored URL. Most reputable hosts offer both as a single "redirect" option when you leave. Keep the redirect in place for as long as you possibly can. Apple's creator documentation asks that the redirect remain active for a set minimum period, but some apps check feeds only occasionally, and listeners who have not opened an app for months still need to be carried across. Treat the redirect as permanent, and budget to keep a minimal plan on the old host if that is what it takes.

Worked example: migrating a weekly interview show

The following is an illustrative scenario, not a client case. A company runs a weekly 45-minute interview show with 120 published episodes. Its current host is being retired, and it wants to move to a new host with better analytics. The audio is 96 kbps mono MP3, so each episode is about 32.4 MB (96,000 bits per second times 2,700 seconds, divided by 8 bits per byte). The full archive is roughly 3.9 GB, which matters because the import will pull every file across.

Two details in the example are easy to miss. Publishing is paused between the import and the redirect, so no episode exists on only one host. And GUID checks happen before the redirect, when mistakes are still free to fix. Once apps have followed the redirect and ingested regenerated GUIDs, the duplicates are already on listeners' devices. If you are switching hosts for a show that matters commercially, this is one of the two moments the reference material singles out for bringing in help; our podcast production team handles migrations as a planned project rather than an afternoon task.

Some hosts also support the Podcasting 2.0 podcast:locked tag, which signals to other hosting platforms that your feed should not be imported without your permission. Unlock it on the old host before migrating, and consider locking it again on the new one afterward.

Checklist Item 9: Know the Troubleshooting Order When Episodes Stop Appearing

"The new episode isn't showing up" is the most common feed support request, and it usually has a boring cause. Work through the chain in order, from your feed outward, rather than starting with the app that is complaining.

1. Is the episode in the feed? Open the raw feed URL. If the item is missing, the problem is at the host: the episode may be scheduled, saved as a draft or attached to the wrong show.
2. Is the publish date correct? A date in the future, or a year typo that puts it in the past, can hide or mis-sort the episode.
3. Does the enclosure work? Open the audio URL directly. A 404, a redirect loop or a login page means apps cannot fetch it either.
4. Is the feed still valid? One unescaped character in new show notes can break parsing for the entire feed. Run a validator.
5. Has the feed URL changed? A custom domain that lapsed, a changed DNS record or a website redesign can leave directories polling a dead address.
6. Is it just cache timing? Directories refresh on their own schedules. If everything above checks out, allow a few hours, then use the refresh option in Apple Podcasts Connect or the relevant creator dashboard.
7. Is the show flagged? Check the directory dashboards for messages about content, artwork or ownership that may be holding the listing.

If episodes appear twice, look at GUIDs first: compare the duplicate items in the raw feed, and if their GUIDs differ, you have found the cause. If the wrong artwork shows, check whether the image URL changed and whether the old image is still cached; a new filename usually forces a refresh. If a video version of your show behaves differently from the audio feed, remember that video podcasts often have separate feeds or platform-specific uploads with their own rules, covered in our practical guide to video podcast production.

If episodes have stopped appearing across several apps and you cannot find the cause within an hour using this list, that is the second moment the reference material names for bringing in help. Waiting rarely fixes a structural feed problem, and every missed episode is a gap in your subscribers' queues.

Checklist Item 10: A Maintenance Routine and a Podcast RSS Feed Verdict

Podcast RSS feeds do not need constant attention, but they do need an owner. The most reliable teams treat the feed as a production asset with a short routine attached to it, rather than something that only gets looked at when an episode goes missing.

Per episode

• Check the title, description, episode number, episode type and explicit value against your style sheet before publishing.
• Confirm the audio was exported to your agreed specification and uploaded through the host's interface.
• After publishing, open the raw feed and confirm the new item is there, then check one app.

Quarterly

• Run a full validation and save a dated copy of the feed.
• Re-read Apple's and Spotify's creator documentation for requirement changes, especially around artwork and metadata.
• Confirm the owner email still reaches someone, the feed domain is renewed and team access to the host is current.
• Review whether your category and show description still describe the show accurately.

Before any major change

• Changing hosts, feed URL, show type, category or artwork: validate before and after, and follow the migration sequence in item 8.
• Restructuring the archive, such as renumbering seasons: test on a copy, and never delete and re-create episodes to do it.

Most of this work sits naturally alongside editing. The person who checks loudness and edits out false starts is well placed to check metadata too, which is why editorial decisions and feed hygiene belong in the same workflow. Our guide to podcast editing and the decisions that matter shows where those checks fit in a typical production pass.

A feed that is set up correctly becomes almost invisible: episodes simply appear, artwork stays sharp and subscribers never notice the machinery. That invisibility is the goal. Put an owner's name next to the feed, keep a copy of it, and revisit the checklist at the top of this page whenever something about your show changes.

Where this comes from

• Apple Podcasts for Creators — Podcast RSS feed requirements
• Spotify for Creators — Podcast delivery specifications

The figures and practices above come from the sources listed.

Working on something like this?

We take on Audio Editing & Production work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• Podcast Artwork Requirements: The Decisions That Matter
• How to Get Podcast Chapters and Episode Metadata Right