What the feed actually is
A text file at a web address, generated by your host, that describes your show and lists every episode. Nothing more mysterious than that. Your title, your art, your description, and for each episode a title, a summary, and a link to the audio file sitting on your host's server.
Your host generates it. You do not write it by hand and you should never need to edit it. When you upload an episode and hit publish, the host rewrites the file to include the new entry. That is the whole automation, and it is why the feed address never changes even though its contents change every week.
Open one sometime, ideally your own. It looks like a wall of tags, but you can read it. There is a block near the top describing the show, then a repeating block for each episode. Under every episode there is a link pointing at an audio file. That link is what a listener's app downloads when they press play.
Your host stores the audio, the feed only points at it
This is the part that catches people. The feed is not the audio. It is a list of addresses where the audio lives. Delete an MP3 from your host and the entry stays in the feed while the app finds nothing at the other end, which is why moving files around without moving the feed breaks episodes that used to work.
Why every app reads it and none of them keep it
Apple Podcasts, Spotify, YouTube Music, Amazon Music, Pocket Casts, and Overcast are readers, not vaults. None of them store your show. They store your feed address, check it on their own schedule, and display whatever they find there. Change something in your host and the change reaches all of them.
Three consequences follow, and they are the reason this piece exists. You fix a typo in an episode title once, in your host, and it corrects everywhere. You swap your cover art once and every app picks up the new one. And when a directory shows something stale, the problem is almost never the directory. It is the feed, or it is timing.
You submit once per directory, then never again
Submission is a one-time act. You give each directory the feed URL, it verifies that you own the show, and from then on it checks the feed on its own. New episodes appear because the app re-read the file, not because you told anyone. There is no per-episode submission step.
Most hosts have a submit or distribute screen that handles the major directories with a click, and using it saves you from pasting the same URL into six different sign-in flows. Apple asks you to sign in to Apple Podcasts Connect and either submit a feed hosted somewhere else or create the show there, and it reviews shows before they go live. That is Apple's own description of the process on its podcaster support site.
Verification is usually one of two things. The directory emails the address published in your feed and asks you to confirm, or it asks you to sign in to an account you already own. Both are checking the same fact, that the person submitting the show is the person who runs it.
What to have ready before you submit
Four things, and all four live in your host rather than in the directory. Cover art that meets the platform spec, a real description, at least one published episode, and a working email address in the feed. Directories reject empty and incomplete feeds, so assemble these first.
- Cover art that meets the spec. Apple publishes artwork policies and templates, and your host will tell you the dimensions it expects. Art that fails the spec is one of the ordinary reasons a submission bounces.
- A real show description. Not a placeholder, not a sentence you plan to replace later. Some of that text is the first thing a stranger reads before deciding whether to press play.
- At least one published episode. Most directories will not accept a feed with nothing in it. If you are not ready to release episode one, publish the trailer and submit on that.
- A working email address in the feed. This is the address a directory uses to verify you, and often the address a guest or a sponsor uses to reach you. If it bounces, verification fails and nobody tells you why.
- A feed that validates. Apple says outright to test your show's feed before submitting it for review. Run it through a validator, fix whatever it flags, then submit.
Why a submission gets rejected
Almost always something mechanical rather than editorial. An empty feed, art that misses the spec, an email address nobody can reach, or a required tag your host left blank. Directories are not judging your idea at this stage. They are checking that the file is complete and the show is real.
Which is good news, because mechanical problems have mechanical fixes. Read the rejection, go back to your host settings rather than to the directory, correct the one field, and resubmit. Hosts leave fields blank when you skip a step during setup, so the fix is usually sitting in a settings screen you clicked past on your first day.
When an episode does not show up
Resist resubmitting the feed. That is not what fixes it, and it can create a duplicate listing you then have to get removed. Work through three checks instead, in order, because the answer is almost always one of them and only the last one requires patience.
- Confirm the episode is genuinely published and public. Scheduled, draft, and private all look close enough to published from inside your host when you are moving fast.
- Confirm the feed validates and the episode is in it. Open the feed URL and look for the title. If it is not in the file, no app can see it, and the problem is in your host.
- Then wait. Apps re-read feeds on their own schedule, and Apple's guidance when changes have not appeared is to refresh the feed rather than to resubmit the show. Give that a chance to run before you conclude something is broken.
What else reads your feed
Directories are not the only readers. Because the feed is public, anything can parse it: analytics tools, transcript services, a promo swap partner checking your cadence, a sponsor deciding whether the show is still active. Your feed is the public record of everything you have made.
That works in your favor more than most hosts realize. Pod Green Room reads your public feed to build back-catalog show memory, which means it learns what your show has already covered and who has already been on it, and then uses that as the ground truth for guest tracking and vetting instead of a show description you typed once and forgot.
The practical version: point Pod Green Room at the feed once, and the catalog becomes an input to your guest pipeline, so a name you already interviewed in season one does not quietly resurface as a fresh booking idea in season three. The free guide to booking podcast guests covers the outreach side once that shortlist is real.
Portability is the whole point
Because the feed is a file you can move, your show is portable. Change hosts and you take the audience with you, as long as the feed address keeps working. That is the entire reason to care about a technical detail this small.
The way you protect it is to own the address. If your feed lives at a URL on your own domain and your host publishes to that address, you can leave the host and your subscribers never notice anything happened. If the feed lives entirely on the host's domain, moving means asking that host to redirect the old address to the new one, and hosts vary in how gracefully they do it.
Set that up on day one if you can, and if you cannot, at least know which of the two situations you are in. Everything else about your show is replaceable. The equipment, the artwork, the format, the name if you really must. The feed and the people subscribed through it are the asset.
Nobody can take a feed from you. They can only make it inconvenient to move. Owning the address is what removes the inconvenience.
Once the feed is live and episodes are landing, the question stops being distribution and starts being whether the show is ready to be pitched. The free sponsor readiness grader will tell you what is missing before a sponsor does, and the template library has the emails for what comes after.