Proposal: podcast:sortOrder for creator-defined episode ordering

[nathangathright]

At Podcast Movement 2023, Spotify announced their Best Place to Start feature, allowing podcasters to pin a single episode for new listeners. None of the prior RSS-based proposals in this vein found traction, so I wanted to outline an alternative approach and see if it would resonate more.

Purpose

Podcast apps typically sort episodes by publish date, season/episode number, and in some cases, by title or duration. Podcasters have no way to express other orderings (popularity, "greatest hits," "start here", editorial curation) in their feed. The workaround today is changing publish dates, which breaks chronological sort for everyone.

This tag lets podcasters define named sort dimensions at the item level. Supporting apps offer these as additional sort options. Non-supporting apps ignore them.

Relationship to <podcast:pinned> (#570)

#570 proposed a channel-level <podcast:pinned> tag (implemented by TrueFans) for surfacing featured episodes. This proposal generalizes that idea: pinning is the simplest case, adding this tag to a few episodes, with all other episodes falling back to publish date.

Specification

Tag: <podcast:sortOrder>
Parent: <item>
Count: Multiple (one per label)

Attributes

Attribute	Required	Type	Description
label	yes	string	Name for this sort dimension, displayed as a sort option. Max 128 characters.
rank	yes	float	Position within this label. Lower values sort first. Need not be contiguous.

Sorting rules

• Lower rank = appears first, matching leaderboards, priority queues, and <itunes:episode>. No direction attribute.
• Ties broken by <pubDate> descending.
• Unranked episodes appear after all ranked episodes, in publish-date order.

That last rule is what makes this work for pin-only feeds: a podcaster who wants to pin 3 episodes out of 500 adds the tag to 3 items. The other 497 flow naturally below.

Examples

Pin a couple of episodes (simplest case)

A show with 200 episodes wants new subscribers to see two entry points at the top. No tag needed on the other 198 episodes.

<item>
  <title>Welcome — Start Here!</title>
  <guid>ep-000-welcome</guid>
  <enclosure url="https://example.com/ep000.mp3" type="audio/mpeg" length="12345678" />
  <pubDate>Tue, 03 Jan 2023 12:00:00 GMT</pubDate>
  <podcast:sortOrder label="Start Here" rank="1" />
</item>

<item>
  <title>The Interview That Changed Everything (Ep. 42)</title>
  <guid>ep-042-interview</guid>
  <enclosure url="https://example.com/ep042.mp3" type="audio/mpeg" length="23456789" />
  <pubDate>Wed, 18 Oct 2023 12:00:00 GMT</pubDate>
  <podcast:sortOrder label="Start Here" rank="2" />
</item>

Popularity ranking

<item>
  <title>Interview with Jane Doe</title>
  <guid>ep-042</guid>
  <enclosure url="https://example.com/ep042.mp3" type="audio/mpeg" length="23456789" />
  <podcast:sortOrder label="Most Popular" rank="1" />
</item>

<item>
  <title>Our Origin Story</title>
  <guid>ep-001</guid>
  <enclosure url="https://example.com/ep001.mp3" type="audio/mpeg" length="12345678" />
  <podcast:sortOrder label="Most Popular" rank="2" />
</item>

Multiple dimensions on one episode

<item>
  <title>Deep Dive: Quantum Computing</title>
  <guid>ep-037</guid>
  <enclosure url="https://example.com/ep037.mp3" type="audio/mpeg" length="34567890" />
  <podcast:sortOrder label="Most Popular" rank="12" />
  <podcast:sortOrder label="Beginner Friendly" rank="3" />
</item>

Design Notes

Tag flexibility does not dictate UX. Hosts and apps have no obligation to expose the full flexibility of any tag. Hosts may choose to present a UX to their users that matches Spotify for Creators and handle the RSS details behind the scenes. Apps may choose to limit the number of episodes or dimensions they support to avoid overwhelming the user. Please remember that you are always the final vote on the best experience for your users, and the shape of an RSS tag is an entirely separate matter.

Item-level, not channel-level. The metadata lives next to the episode it describes (like <itunes:episode>, <podcast:person>). Hosting platforms can add rank fields to their existing episode editor. No separate GUID list to maintain or fall out of sync. The tradeoff: clients must scan items to discover available labels, the same pattern as <itunes:season>.

No direction attribute. "Rank 1 = first" is unambiguous. With a direction attribute, does ascending describe the rank interpretation or the display order? Not worth the confusion. Clients can offer a flip toggle on their end.

Float, not integer. Allows insertion without renumbering (1, 1.5, 2). Useful for drag-and-drop reordering in hosting UIs. Plain integers work fine too.

Non-contiguous ranks are fine. Ranks of 1, 5, 10, 100 leave room for future insertions.

Prior Art

• <podcast:pinned> (#570): predecessor, implemented by TrueFans
• #305, #281, #385: earlier pinning/featuring discussions
• <itunes:episode>: item-level numeric ordering (serial), the pattern this mirrors
• Common app sort options (Publish Date, Title, Length, Serial): existing app-side sort this would extend

[Marzal]

I like more this proposal than #570.

Tag adoption it's slow/difficult. I think this one has a good balance between functionality and difficulty to implement.

Do the label attribute has to be Required? I can see use cases that don't really need it.

[Marzal]

For a single episode pin:

<item>
  <title>Welcome — Start Here!</title>
  <guid>ep-000-welcome</guid>
  <enclosure url="https://example.com/ep000.mp3" type="audio/mpeg" length="12345678" />
  <pubDate>Tue, 03 Jan 2023 12:00:00 GMT</pubDate>
  <podcast:sortOrder rank="1" />
</item>

Or just to promote 2 episodes

<item>
  <title>Welcome — Start Here!</title>
  <guid>ep-000-welcome</guid>
  <enclosure url="https://example.com/ep000.mp3" type="audio/mpeg" length="12345678" />
  <pubDate>Tue, 03 Jan 2023 12:00:00 GMT</pubDate>
  <podcast:sortOrder rank="1" />
</item>

<item>
  <title>The Interview That Changed Everything (Ep. 42)</title>
  <guid>ep-042-interview</guid>
  <enclosure url="https://example.com/ep042.mp3" type="audio/mpeg" length="23456789" />
  <pubDate>Wed, 18 Oct 2023 12:00:00 GMT</pubDate>
  <podcast:sortOrder rank="2" />
</item>

In these 2 cases, without the label (I agree is better to have it) the App could just use "Featured episodes" or something similar. So in my view, label is better but not a hard requirement.

[nathangathright]

Gotcha. If I'm following, the apps would not be expected to include these unlabeled sortOrder dimensions in their list of potential ways to sort all the episodes. So these pinned episodes would be pinned at the top regardless of whatever other sorting options the listener has enabled? I'd be curious if apps think that's a good user experience.

[Marzal]

It's not that what Spotify does? Allow you pin a single episode that will always be the first. For that you don't need the label tag.
It would be the simplest case.

No label = just pin. Label = sort option.

[nathangathright]

No, Spotify drops this recommendation a separate About tab.

CleanShot.2026-03-02.at.14.46.22.mp4

[Marzal]

Thanks, I thought Spotify would show it similar to the trailer

But no info no the web player at all:

Maybe it's because the best place to start it's the latest one...

I changed it on my podcast, will see in a few days/week

[samsethi]

Hi

TrueFans offers a sort order for podcast episodes and we also auto label the 'most popular' based on user activity i.e total time listened.

[Marzal]

Do you have already coded some tag ingestion support for this? or it's for now just TF related?

Would you implement podcast:sortOrder ?

[samsethi]

Its only TrueFans but we coded this so others can see how it works and then give feedback before adoption.

[Marzal]

Perfect, so no problem in taking the time to compare #570 with this proposal.

[samsethi]

Podcast Pinned is what we do already. We call it featured. We automatically feature the trailer at the top of the podcast page unless the podcaster picks another episode to be featured in their admin dashboard.

I am not bothered whether the tag is called pinned or featured.

This is separate to the sort option. We provide a sort option drop down for latest or most popular. Our default sort order is latest. We also auto label the 'most popular' episode based on activity.

Are you suggesting we should add this sort order to the RSS feed? I am not sure that is needed? Equally the most popular will differ in each app based on user activity.

[Marzal]

The pinned functionality can be achieved with the simpler #570 or with this tag.

But this tag also brings the option of sorting proposed by the podcaster.

So we need to see if there it's a substantial benefit and usefulness to pick this approach instead of the simple one.

I'm in general (and now) in favor of tags with more possibilities even if the initial implementation it's only for a single simpler use case.