Podcast back catalog: the episodes nobody plays, and what to do with them

There are 132,505,257 podcast episodes sitting in RSS feeds right now, according to Podcast Industry Insights, the tracking site published by Daniel J. Lewis, which says its data is "collected independently and updated nightly." Spread across the 3,156,842 shows it counts in Apple Podcasts, that works out to roughly 42 episodes per show. Almost all of them will never be played again by anyone.

If you have been publishing for two or three years, your podcast back catalog is the largest asset your show owns and the one you have the least control over. You paid for every hour of it. You can see, in your host's stats, that episode 14 has not been downloaded since the week it came out. The instinct is to assume the old episodes are simply worse, or that listeners who want them will find them. Neither assumption survives much contact with how the apps are built.

The feed behaves like a stack

A podcast RSS feed is ordered, and the order is a setting. The podcast de facto standard documentation at podcast-standard.org defines the itunes:type tag as one that "can be episodic or serial," and says it "determines how the episodes are ordered, default is episodic where the latest episode is on top." Most shows never touch that tag, so they inherit episodic by default, and every app presents the newest episode first to every person who arrives.

That is a reasonable default for a talk show and a poor one for a 40-part series. It also means the practical visibility of episode 14 is whatever a listener finds after scrolling past 80 newer entries, on a phone, in a list with no filter and usually no search inside the show.

Then there is the part most hosts do not realize they switched on. Buzzsprout, to take one host with public documentation, offers an episode limit, and its help page is explicit about the reach of it: the setting "will limit the number of episodes that are shown in your: RSS Feed, Directory listings (Spotify, Apple, Google, etc.), Buzzsprout public website." That is not a display preference. Episodes outside the limit stop existing as far as the directories are concerned. Buzzsprout notes that "it might take up to 24 hours to see the change show in your directory listings," which cuts both ways, so raising the limit does not restore the archive instantly either. Before you spend a weekend on your old episodes, open your host's feed settings and confirm the old episodes are still in the feed at all.

What Apple actually reads

Apple Podcasts publishes how its search works, and the list of what gets indexed is shorter than most promotion advice assumes. The support page names the inputs as "Metadata: this includes the show name, channel name, and episode title," alongside "Popularity: podcasts with large followers and plays" and "User Behavior: podcasts with high engagement, such as those that are played or followed from search results." Apple states plainly that while ratings, reviews, and shares "help indicate a podcast's newness, popularity, and quality, they are not factored into Search results."

Read that against a three-year archive and the arithmetic is uncomfortable. Your show name is fixed. Popularity and listener behavior are mostly driven by your recent episodes, since those are what anyone sees. The only lever that belongs to episode 14 specifically is its title. Apple's own guidance on the same page tells creators to avoid "emojis and repeated episode titles" and to make titles "specific and unique so they may appear in relevant searches."

So an archive titled "Episode 14," "Episode 15," "Episode 16" is an archive with no searchable surface inside Apple Podcasts. An archive titled "Episode 14: how a contractor prices a kitchen renovation" has one. Retitling is the cheapest work available to you, it takes an afternoon for 50 episodes, and the only hard constraint is accuracy: Apple's content guidelines require that "podcast metadata (for example, titles, descriptions, language, etc.) must always accurately represent the corresponding content that is distributed."

If you are rewriting titles, read our piece on podcast show notes first, because the description field plays by different rules than the title and the two jobs are easy to confuse.

The trick with the publication date

The most common piece of back catalog advice circulating in podcast groups is to change an old episode's publication date so it jumps back to the top of the feed. The mechanics work. Apple's feed requirements accept a pubDate conforming to RFC 2822, Apple's metadata support page says "our system will automatically detect and update it on Apple Podcasts within 24 hours," and the episode reappears at the top of every subscriber's list.

What you should know before doing it. Apple's feed requirements state that "all episodes must contain a globally unique identifier (GUID), which never changes," so the republished episode is the same episode, not a new one, and your stats will blend the two runs. Apple also "will ignore duplicate <enclosure> URLs," which rules out the workaround of posting the same audio file as a fresh entry. And the content guidelines prohibit podcasts "designed to mislead audiences by mimicking, copying, or duplicating other content or search terms," with remedies that include Apple taking "action to label or remove the content from Apple Podcasts, suspend the sale of subscriptions, and/or suspend or terminate your account."

A single honest re-release, labeled as one in the title, is ordinary practice and nobody's enforcement problem. A rotation that recycles the same twelve episodes every quarter to manufacture a publishing schedule is a different thing, and it trains your subscribers to ignore your notifications, which is the expensive part long before Apple ever notices.

Shows that begin at the beginning

If your show is a narrative series, a course, or anything where episode 1 is the correct entry point, the back catalog problem is a tagging problem rather than a marketing problem. The standard gives you three tools. Setting itunes:type to serial changes the ordering so the sequence reads forward instead of backward. itunes:season and itunes:episode each take "a positive integer," which lets apps group and sort a multi-year archive into something a newcomer can enter. And itunes:episodeType "can be full, trailer or bonus," which is how you mark a short orientation episode as a trailer so it sits apart from the run.

Shows that get this wrong lose listeners at the first tap, because the newest installment of a story is the worst possible first impression. Shows that get it right do not need an archive campaign at all. The feed does the sorting.

Two markets for the same episode

Inside the podcast apps, your archive is dead stock. There is no browse surface for it, one indexed field, and a default sort order working against it. On the open web, the same archive is an inventory of answers to questions people type into Google every day, and the audio stops being the product. The text becomes the product, and the audio becomes the proof.

This is the whole argument for treating transcripts as a publishing asset rather than an accessibility checkbox, which we covered in podcast transcripts and SEO. It is also why getting your podcast onto Google is a separate project from getting it into the podcast directories, with different mechanics and a different payoff curve. Our podcast SEO guide covers the structural side, and how to promote a podcast sorts the channels that compound from the ones that spike.

The reason this favors old episodes specifically is that search demand does not care when you recorded something. A 2023 conversation about how a dentist prices a crown answers the same question a listener types in 2026. Your newest episode has a publication date advantage inside the apps and no advantage at all on Google, where the page that answers the question best wins regardless of age.

Sorting the archive

Download counts are the wrong sort key for this job. An episode that did poorly on release may have done poorly because you published it in late December, not because its content is weak. Rank by question instead.

Pull a list of every episode. For each one, write down the single question a stranger would type into a search box to end up at that episode. If you cannot write the question in under ten words, the episode is not a candidate, and most interview episodes with a loose structure will fail this test. Expect 15 to 25 percent of a 100-episode archive to pass, which is a useful number: it means a three-year show usually has 20 or so pieces of genuinely evergreen material and 80 that are of their moment.

Then do three things with the ones that pass, in this order. Retitle the episode so the question is visible in the title. Give it a page of its own on your site that answers the question in text, with the relevant stretch of transcript quoted and the player embedded. Link to that page from your two or three most recent episodes, where the traffic actually is.

Only the first of those happens in the feed. The other two happen on your own site, which is the part of your publishing operation you control completely and the part most shows neglect entirely. Our benchmark piece on download numbers is worth reading alongside this, because a back catalog that earns search traffic shows up in your numbers as a slow rising floor rather than a spike, and that pattern is easy to miss if you only look at per-episode charts.

A note on format if you are doing the page work yourself. Spotify's documentation on show notes warns that "we send your HTML formatted text exactly as it appears to all listening platforms" and that it "only support https links (not http)," so anything you write into the feed description travels unpredictably. Write for your own pages and keep the feed copy plain.

If video is part of your plan for the archive, how to put your podcast on YouTube covers the RSS delivery route, and podcast categories explains the two taxonomy slots that affect where a show surfaces.

What nobody publishes

Apple does not release figures for what share of listening comes from episodes older than 30 days. Spotify does not either. No platform publishes a decay curve for episode downloads, and the hosting companies that could publish one mostly do not break it out. Any blog post that gives you a precise percentage for how much of a typical show's listening comes from its archive is making the number up or inferring it from a sample nobody has audited.

What is verifiable is the structural case: one indexed field per episode, a default sort that buries the archive, host settings that can remove it from the feed outright, and a search engine that weights relevance over recency. That is enough to act on without a statistic.

The version of this that someone else does

PodAnswer exists because the page-per-question work above is mechanical, it takes two or three hours per episode done properly, and almost nobody with a podcast has that time in a week where they also have to record. We take an episode, find the questions it genuinely answers, and publish an article that answers each one in text with the real transcript excerpts quoted and timestamped, linking back to your show.

Growth is $149 a month for four articles, which comes to 48 articles over a year. Network is $349 a month for twelve articles, which is the plan shows pick when they want the evergreen part of a long archive covered inside a year rather than across three. The pricing page has both plans, and the page for podcasters explains how the articles are built and what we need from your feed to start.

Either way, start with the retitling. It costs nothing, it is the only field Apple indexes, and it is the one piece of this you should not outsource, because you are the only person who knows what your episode 14 was actually about.

Sources cited in this piece: Podcast Industry Insights, published by Daniel J. Lewis, for podcast and episode totals. The podcast de facto standard documentation at podcast-standard.org for the itunes:type, itunes:season, itunes:episode and itunes:episodeType tag definitions. Apple Podcasts for Creators for the search support page, the podcast feed requirements including the GUID and enclosure rules, the metadata update window, and the content and subscription guidelines. Buzzsprout's help documentation for the episode limit setting. Spotify's creator support documentation for show notes formatting.