Take this with you
- Keep episode identity separate from media location.
- Validate real hosted files as well as XML syntax.
- Use explicit delivery paths for public and member content.
Understand the show and episode layers
RSS 2.0 uses a channel for information about the publication and items for its entries. The base specification requires a channel title, link, and description. Podcast directories add their own requirements, so passing a general XML check is only the beginning of a publishing review. [1]
Create a metadata worksheet before building the feed. Keep the show name, description, language, artwork, category, author display, and contact information consistent. For each episode, record a descriptive title, summary, publication time, explicit-content status, and the final audio location. Review these as editorial content.
Point the enclosure at the real media
The RSS enclosure identifies the media URL, its length in bytes, and its MIME type. These fields describe the actual downloadable file, not a web page with a player. Populate them from the final exported media rather than from an estimate or the duration displayed in an editor. [1]
Open the enclosure URL from a clean browser session and retrieve the file. Check that it contains the intended episode and that the server returns it without an account prompt. If you replace the audio, repeat this check; a correct feed cannot compensate for a missing or incorrect media file.
Keep episode identity stable
Apple requires each episode to have a GUID that never changes, and each episode enclosure must have a unique URL. Preserve the GUID when correcting a title or moving a show. Treat it as the identity of the episode, separate from the location where the audio happens to live. [2]
Add the identifier to your production tracker and exports. When migrating, compare the old and new lists before publishing the replacement feed. Review changes as a set: missing items, duplicated identities, unexpected dates, or a truncated archive can be easier to notice in a comparison than in raw XML.
Add helpful metadata in layers
The podcast namespace offers a transcript element that points to a transcript resource and describes its type. Supporting clients can use this metadata, but actual presentation depends on the application. Publish a readable transcript on the episode page as well so your accessibility plan has a direct path for listeners. [3]
Add chapters, contributor information, or other supported features only when you can maintain them. Keep a small compatibility record showing where you tested each enhancement. Every additional field creates an editorial responsibility: a chapter needs the right timestamp, and a contributor should be credited accurately.
Keep public and member feeds deliberate
A public feed is designed for discovery and sharing. Apple requires public directory feeds to be reachable without password protection. A private member feed therefore needs its own provider-supported delivery and account experience; do not quietly substitute restricted URLs into the public program and expect every app to adapt. [2]
Document the handoff from checkout to access. A listener should know where the feed link appears, which apps are supported, whether links are personal, and how to recover access. If the design uses a token credential, distinguish the ownership check from the actual media authorization process.
Validate the published result
Review the feed after upload, using the public address listeners and directories will request. Check XML syntax, escaped characters, actual media sizes, reachable images, dates, and required podcast fields. Then test it with the directory's validation tools and a listening application. Each step answers a different question.
Check a new episode and an older episode. Seek through the audio, compare the title to the recording, and open the transcript. Do not manufacture sample episodes or enclosures merely to make a validator pass. A real submission needs real media and accurate metadata for the show being offered.
Create a calm publishing routine
Make a release checklist that records the final media filename, episode GUID, scheduled time and timezone, source approvals, artwork, transcript, and page link. Assign one person to confirm the live result. This takes the most fragile details out of memory and makes a weekly release easier to hand over.
Retain the previous working feed and record material changes. If something breaks, compare the smallest relevant difference before rewriting the entire file. A deliberate correction is easier to explain to collaborators and less likely to disturb older episodes that listeners have already saved or downloaded.
Sources & further reading
Primary references for this guide. Standards and service requirements may change; check the current source before publishing.