A new episode is not always the best match for a query. A highly relevant episode is not always recent enough for a topic that changes every week. Search ordering should make this choice visible.
For a query such as “history of paper,” relevance is a sensible starting point. For “this week's market update,” date may matter more. Your app can support both without claiming that one list is universally better.
Name the sort honestly
Use labels such as “Best match” and “Newest” when they reflect the API's documented options. Avoid calling a list “Popular” unless you actually have a supported popularity signal. Relevance ranking alone does not prove audience size.
When the listener changes the order, clear the old pagination state and load a new first page. Keep the search text and filters intact. The title above the list should show the current order so a person returning from an episode remembers what they are browsing.
Do not reorder already loaded pages in the client and present them as a complete newest list. Sorting one small page cannot place it correctly against episodes that have not been fetched.
Handle missing dates
Some catalog records have incomplete dates. Give them an understandable fallback label. Do not invent a date from the time your app first saw the record, because that makes old content look newly published.
Test a fixed query under both orders. Include an old exact-title match, a new loose match, and a record without a date. The results and labels should tell the same story. A visible, consistent sort rule helps listeners trust discovery even when the catalog is large.