Understanding How Audio RSS Feeds Work

An audio RSS feed is an XML file that serves as the central distribution hub for your podcast. It contains metadata about your show and each episode, including titles, descriptions, publish dates, and, most critically, the audio file URLs. Podcast directories like Apple Podcasts, Spotify, and Google Podcasts periodically fetch this feed to discover new episodes. The feed must conform to the RSS 2.0 specification, with additional namespace tags defined by Apple (iTunes) and other platforms. Even a minor deviation—such as a missing required tag, an unescaped ampersand, or a malformed enclosure URL—can cause the feed to be rejected, leading to missing episodes, broken playback, or complete removal from directories.

Key technical components of the RSS feed include the <channel> element that defines the podcast, and one or more <item> elements for each episode. Each item must contain an <enclosure> tag with a url, length (in bytes), and type (MIME) attribute. The <guid> tag uniquely identifies each episode across updates. Without a stable GUID, directories may treat episodes as duplicates or miss them entirely. Understanding this structure is the first step to diagnosing feed issues.

1. Feed Not Updating When New Episodes Are Published

You publish a new episode on your hosting platform, but hours later it still hasn't appeared in Apple Podcasts or Spotify. This delay is almost always due to caching at multiple levels.

CDN and Host-Level Caching

Most podcast hosting providers use Content Delivery Networks (CDNs) to serve feeds quickly and reduce server load. CDNs cache the feed file for a set period, known as the Time To Live (TTL). If your host caches the feed for several hours, a newly published episode won't be visible to directories until the cache expires. To mitigate this, check your host's documentation for manual cache purge options or a "regenerate feed" feature. Some platforms (e.g., Transistor, Buzzsprout) let you force a feed refresh after publishing. If your host does not offer this, consider switching to one that does.

RSS Client Caching

Podcast apps (Apple Podcasts, Overcast, Pocket Casts) cache feed data to reduce bandwidth and improve performance. They typically refresh every 6 to 24 hours, depending on app settings and network conditions. To force a refresh for testing, most apps have a "Refresh Feed" button, often hidden in the podcast settings page. However, for your listeners, this caching is normal and unavoidable. What you can control is ensuring your feed is technically correct so that when the app does fetch it, the new episode is presented without errors.

Incorrect Episode Timestamps

The <pubDate> tag tells directories when an episode was published. If the timestamp is in the future, directories may skip the episode or delay its appearance until the date arrives. If the format is wrong (e.g., 2024-05-20 instead of RFC 2822: Mon, 20 May 2024 10:00:00 GMT), the feed may fail validation entirely. Always ensure your hosting platform automatically generates the correct timestamp. If you are manually editing the feed, use tools like Feed Validator to check the date format. Additionally, verify that your server's clock is accurate—an incorrect system time can throw off timestamps.

Listeners press play and receive an error—or the episode never loads. The problem often lies in the enclosure URL.

Misconfigured File Permissions or Hotlinking Protection

Audio files must be publicly accessible without authentication. If you host files on your own server, folder permissions (e.g., 755 for directories, 644 for files) are typically sufficient. However, some web hosts apply strict access controls that block direct downloads. Hotlinking protection (often enabled via .htaccess) can also block podcast apps because they use user-agent strings that differ from browsers. Disable hotlinking protection for your audio directory, or whitelist common podcast app user agents (e.g., "AppleCoreMedia", "Podcast/", "Overcast"). To test, copy the enclosure URL into a browser—if it downloads, permissions are fine; if you get a 403 or 404, adjust your server configuration.

CDN Expiration and Missing Files

If you move or rename an audio file, the old URL in the feed becomes a dead link. Always use permanent, unchanging URLs for audio files. If you must change a file location, set up a 301 redirect from the old URL to the new one. Additionally, ensure your CDN does not expire audio files too quickly—some CDNs automatically purge files after a set number of days, causing intermittent 404 errors for older episodes. Set a long cache expiry (e.g., one year) for audio files, and test all enclosure URLs regularly using a service like W3C Feed Validation Service.

Enclosure MIME Type Errors

The <enclosure> tag requires a type attribute that specifies the MIME type of the audio file. Common values are audio/mpeg for MP3 files, audio/x-m4a for AAC, and audio/ogg for Ogg Vorbis. If the MIME type is incorrect or missing, some players will reject the file. For example, a common error is using audio/mp3 instead of audio/mpeg. Always double-check the type for each episode. A tip: use a tool like file --mime-type on the command line to verify the actual MIME type of your audio file, then ensure the feed matches.

3. XML Formatting Errors That Break the Feed

RSS is strict XML. A single unescaped character can make the entire feed unparseable, and directories will treat the feed as missing or corrupt.

Common XML Pitfalls

  • Ampersands: Always write &amp; instead of & in descriptions and titles. A bare ampersand (like in "Tom & Jerry") will break the XML parser.
  • Angle brackets: Use &lt; and &gt; for < and >. This is common when including HTML snippets in descriptions.
  • Quotation marks inside attributes: If an attribute value contains double quotes, use &quot; or wrap the value in single quotes.
  • CDATA sections: For long descriptions that contain multiple HTML tags, wrap the content in <![CDATA[ ... ]]> to avoid escaping every character. Note that CDATA sections must not contain the literal string "]]>".

Missing Required Tags

Apple Podcasts and most directories enforce strict rules beyond basic RSS. At the channel level, you must include <title>, <link>, <description>, <language>, and at least one <item>. Within each <item>, you need <title>, <enclosure>, <guid>, and <pubDate>. The <guid> must be a permanent, unique identifier; avoid using the episode URL if you plan to change domains later. Use a stable UUID or the episode's permalink. A missing <guid> can cause episodes to appear as repeats or to disappear after updates. Validate your feed using the Apple Podcasts Feed Validator to catch these issues.

Namespace Prefix Issues

Apple's iTunes tags (e.g., <itunes:author>, <itunes:image>) require proper namespace declaration at the top of the feed: xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd". If this declaration is missing, all iTunes tags are ignored, leading to missing artwork, categories, and explicit flags. Similarly, Google Podcasts uses a googleplay namespace. Always ensure namespace declarations are present and correctly spelled.

4. Episodes Not Appearing on Specific Directories

Sometimes your feed works perfectly in Apple Podcasts but is empty on Spotify, or vice versa. Directory-specific requirements are often the cause.

Directory-Specific Tags

Apple Podcasts relies heavily on the iTunes namespace. If <itunes:author> is missing, your podcast may appear with no author name. If <itunes:image> is missing or the URL is a 404, the artwork will not display. The <itunes:category> tag is required for proper listing in the directory. Spotify uses the same RSS feed but interprets it differently; for example, Spotify prefers <itunes:explicit>yes</itunes:explicit> to label explicit content, and some podcasts have been hidden because the explicit flag was incorrectly set to "no" for explicit content.

Image Requirements

All major directories require podcast artwork images between 1400x1400 and 3000x3000 pixels in JPEG or PNG format. If the image URL in the feed is a 404, or the image dimensions are out of spec, the feed may be rejected or the artwork may not appear. Additionally, the image must be hosted on a publicly accessible server with proper CORS headers. Check your image URL by opening it in a browser, and verify dimensions using an image editor or identify command.

5. Feed Authentication and Access Restrictions

Private podcasts protected by HTTP authentication (username/password) or IP whitelisting will not be accessible to public directories. If you accidentally leave authentication enabled on a feed meant for public distribution, directories will receive a 401 Unauthorized response and will stop fetching the feed. This can remain unnoticed for weeks. To troubleshoot, check server logs for 401 or 403 status codes on the feed URL. For public feeds, ensure no .htaccess or Nginx rules block access. If you use a password-protected staging site, do not submit that feed URL to directories.

6. Episode GUID Conflicts and Duplicate Episodes

The <guid> element uniquely identifies an episode across feed updates. If you change the GUID for an episode (e.g., when moving hosts), directories may treat the old and new GUIDs as separate episodes, creating duplicates. Conversely, if you reuse a GUID (e.g., by mistakenly assigning the same GUID to another episode), the new episode will never appear—it will be considered an update of the old one. Best practice is to generate a unique, permanent GUID for each episode, such as a UUID, and never change it. If you need to replace an episode file, keep the same GUID to avoid duplication.

7. Silent Feed Failures: No Errors but No New Episodes

Occasionally, the feed loads without errors in a validator, but directories still do not show new episodes. This can happen when the feed file is large (many episodes) and directories time out while downloading it. The solution is to limit the number of episodes in the feed (most hosts cap at 200-300) or enable pagination if the directory supports it (most do not). Another cause is a missing or incorrect <lastBuildDate> tag—some directories use this to determine if the feed has changed. Ensure this tag is present and updated each time you publish.

Troubleshooting Workflow: Step by Step

  1. Validate your feed using the W3C Feed Validation Service and the Apple Podcasts Feed Validator. Fix all errors and warnings—even warnings can cause issues with specific directories.
  2. Test in a barebones reader such as a web browser (open the feed XML directly) to see if the file loads without XML parsing errors. If the browser displays the XML tree, the feed is syntactically valid.
  3. Check audio file URLs by copying the enclosure URL into a browser. You should see a download prompt or hear audio. If you get a 404, 403, or a redirect to a login page, fix the permissions or URL.
  4. Inspect HTTP headers for enclosure URLs using curl -I <URL> to ensure the response is 200 OK and the Content-Type header matches the MIME type in the feed (e.g., audio/mpeg).
  5. Look at server logs for requests to the feed file. Check for 404s (feed not found), 500s (server error), or unusually long response times (potential timeouts).
  6. Clear all caches on your hosting platform. If possible, manually regenerate the feed. Some providers let you purge CDN cache for the feed URL.
  7. Ping directories manually if your host supports it. Submitting the feed URL again to Apple Podcasts or Google Podcasts can force a refresh. Note that this does not guarantee immediate fetch; it merely places the feed back in the queue.
  8. Test with multiple podcast clients (e.g., Pocket Casts, Overcast, iTunes, Spotify) to see if the issue is app-specific. If only one app fails, the problem is likely a directory-specific tag or a client cache issue.
  9. Check your DNS and domain configuration if the feed URL is a custom domain. Ensure the domain resolves correctly and has a valid SSL certificate; many directories reject feeds served over HTTP.

Preventive Best Practices

  • Use a dedicated podcast hosting service rather than a generic web host. They handle RSS generation, CDN delivery, cache management, and directory submission. This eliminates many common issues.
  • Always validate after every episode publish. Make it a habit to run the feed through both W3C and Apple validators right after publication. Automate this with a CI/CD pipeline if you have the capability.
  • Set your feed's TTL to a reasonable value. A TTL of 60 minutes balances freshness with server load. Avoid setting it too high (e.g., 24 hours) or too low (0 minutes), which can cause excessive fetches.
  • Monitor feed uptime and health with a service like Podchaser or built-in analytics from your host. Watch for sudden drops in subscriber counts, which may indicate feed problems.
  • Keep your publishing platform up to date; plugin or software updates often fix feed-related bugs. If you use a self-hosted solution like WordPress with PowerPress, update regularly.
  • Use proper file naming conventions to avoid spaces and special characters in audio file names. Use hyphens or underscores instead of spaces, and avoid characters like & # %.
  • Document your feed structure and keep a list of all important URLs (feed, artwork, hosts) for quick reference during troubleshooting.

Conclusion

An audio RSS feed is the lifeline of your podcast—it's how your episodes travel from your recording studio to listeners' ears across the globe. While the technology is simple, the ecosystem of directories, apps, and caching introduces many failure points. Most issues stem from a handful of common causes: caching delays, broken audio file links, XML errors, missing required tags, or directory-specific requirements. By establishing a routine of validation after every publication, understanding the RSS specification thoroughly, and monitoring your feed's health proactively, you can dramatically reduce downtime and ensure your audience never misses an episode.

When problems do arise, work through the troubleshooting workflow systematically. Use the official validators, inspect HTTP responses, and test across multiple clients. And when in doubt, consult the documentation of your hosting provider or the podcast directories themselves. A healthy feed is the foundation of a successful podcast strategy. Invest the time to keep it robust.