podsearch
Blog / For data buyers and researchers
For data buyers and researchers

Podcast trend analysis: tracking topics across millions of episodes

How to measure what podcasts are talking about over time: building topic time series from full-text search, normalizing for catalog growth, detecting emerging topics, and avoiding the classic traps.

Published by the PodSearch team

Podcasts are a running record of what people are discussing, in long form, across every niche and language. When a new technology, a health concern, a brand, a political idea or a cultural moment starts to matter, it shows up in episode titles and descriptions, often before it appears in mainstream coverage. For brands, investors, journalists, policy analysts and researchers, that makes podcasts a valuable trend signal.

This guide shows how to turn full-text podcast search into reliable trend data: how to build a topic time series, normalize it, compare topics, detect emerging ones, segment by language and category, and present results honestly. Examples use the podsearch.org API (ListenNotes-compatible, at https://podsearch.org/api/v2), which searches episodes from around 3.2 million active feeds in the open Podcast Index catalog.

What a podcast trend measures

A podcast trend is a count of episodes (or shows) that mention a topic in a time window. Each part of that sentence needs a decision.

Write these choices down. A trend chart without them cannot be interpreted.

Building a time series

The simplest series is a count of matching episodes per month. published_after and published_before bound each window in epoch milliseconds.

One important detail: the total field in a search response is a pagination hint, not a measured count, so do not use it as your metric. Count by retrieving the matching results instead. Every plan has a results-per-query limit (30 on Free, 300 on Pro), so keep each window narrow enough to stay under it, and split any window that reaches the limit into two halves:

from datetime import datetime, timezone

CAP = 300  # results per query on the Pro plan; 30 on Free

def bounds(y, m):
    a = datetime(y, m, 1, tzinfo=timezone.utc)
    b = datetime(y + (m == 12), m % 12 + 1, 1, tzinfo=timezone.utc)
    return int(a.timestamp() * 1000), int(b.timestamp() * 1000)

def count_window(q, a, b, **params):
    """Count matching episodes published in [a, b); split the window if it hits the cap."""
    ids, offset = set(), 0
    while True:
        r = api.get("/search", q=q, type="episode", sort_by_date=1, page_size=100,
                    published_after=a, published_before=b, offset=offset, **params)
        ids.update(e["id"] for e in r["results"])
        if r["next_offset"] in (-1, None) or not r["results"]:
            return len(ids)
        offset = r["next_offset"]
        if offset >= CAP and b - a > 3_600_000:
            mid = (a + b) // 2
            return count_window(q, a, mid, **params) + count_window(q, mid, b, **params)

def monthly_series(q, months, **params):
    return [((y, m), count_window(q, *bounds(y, m), **params)) for y, m in months]

months = [(2025, m) for m in range(1, 13)] + [(2026, m) for m in range(1, 10)]
series = monthly_series('"heat pump" OR "heat pumps"', months, syntax="dql")

Each page of up to 100 results is one request, so cost scales with the number of matches: a topic with 250 matches a month costs about three requests per month of history, and a busy topic that forces windows to split costs more. Start with narrow vocabularies and title-only matching while you calibrate your budget.

Counting shows, not just episodes

To count distinct shows, use unique_podcasts=1, which returns at most one episode per show, and page through the results:

def distinct_shows(q, a, b, cap=1000, **params):
    seen, offset = set(), 0
    while len(seen) < cap:
        r = api.get("/search", q=q, type="episode", unique_podcasts=1,
                    published_after=a, published_before=b, offset=offset, **params)
        seen.update(e["podcast"]["id"] for e in r["results"])
        if r["next_offset"] in (-1, None) or not r["results"]:
            break
        offset = r["next_offset"]
    return len(seen)

Paging costs one request per page of results, so use show counts for the topics and months that matter most.

Choosing the field

Restrict matching to titles when you want "episodes about X", using the episode: field in boolean syntax or fq_episode_title. Use descriptions for broader coverage. Use deep_search=1 or content: to include transcripts and episode content where feeds provide them, and remember that transcript availability itself changes over time, which can create an artificial upward trend.

Normalizing for catalog growth

Raw counts mislead. The number of episodes published every month changes over time, and the catalog's coverage of any period improves as feeds are discovered and crawled. A topic whose raw count rose 20% may simply be riding a 20% rise in total episodes.

Always compute a relative measure. Counting every episode published in a month is not practical through search, so the usual approach is a control basket: a set of ten to twenty stable topics you do not expect to change much (for example, everyday subjects such as "recipe", "weather" or "book review" in your language), counted with exactly the same method, fields and segment. Report your topic as a ratio to the basket's combined count. If the basket itself moves, coverage or publishing volume changed, not interest in your topic.

def share(topic_series, baseline_series):
    return [(k, t / b if b else None) for (k, t), (_, b) in zip(topic_series, baseline_series)]

Report the denominator you used. Two analysts with different baselines can draw opposite conclusions from the same raw counts.

Comparing topics

Trend analysis is most useful comparatively: brand A against brand B, one policy term against another, a new technology against the incumbent. When comparing:

Detecting emerging topics

Monitoring known topics is straightforward; discovering new ones is harder. Three practical approaches:

Seed-and-expand. Start with a list of terms in your domain. Each month, read a sample of matching episode titles and collect new phrases that recur. Add them to the list and track them.

Term growth ranking. For a fixed vocabulary of a few hundred candidate terms, compute this month's share and the share a year earlier, and rank by growth. Require a minimum count to avoid noise from tiny numbers.

def growth_rank(terms, now_window, then_window, min_count=50):
    rows = []
    for t in terms:
        now = count_window(f'"{t}"', *now_window, syntax="dql")
        then = count_window(f'"{t}"', *then_window, syntax="dql")
        if now >= min_count:
            rows.append((t, now, then, (now + 1) / (then + 1)))
    return sorted(rows, key=lambda r: -r[3])

Search-trend crossover. Compare podcast mentions with other public signals such as web search interest. Topics that rise in search before podcasts suggest an opportunity for creators; topics that rise in podcasts first can be a leading indicator for marketers.

The /trending_searches and /related_searches endpoints show what people are searching for on podsearch.org itself, which is a small but direct signal of listener curiosity.

A topic can be flat overall and booming in one segment. Useful cuts:

Segment results often carry the real story: "AI is discussed more in business podcasts" is obvious; "AI discussion in education podcasts doubled while business stayed flat" is a finding.

Event studies

For a specific event, such as a product launch, a court decision or a natural disaster, build a daily series from a few weeks before to a few weeks after. Use sort_by_date=1 and day-sized windows. Expect a lag: weekly shows will respond within a week, monthly shows later, and narrative series much later. Plot cumulative show counts to see how quickly a topic spreads across the medium.

Freshness matters for live monitoring. podsearch.org re-polls feeds within seconds to minutes when hosts send Podping notifications, and polls other feeds on an adaptive schedule, so a daily series is nearly complete within a day for active shows. Older windows are more complete still.

Pitfalls to avoid

Incomplete recent data. The last few days of any series are under-counted. Leave the current period out or mark it provisional.

Publish-date errors. Some feeds re-date old episodes, publish with future dates, or reset dates after migration. Large one-day spikes from a single show are usually this. Inspect them.

AI-generated volume. Machine-generated shows can publish hundreds of episodes on trending keywords, inflating counts. Use exclude_ai=true to drop shows that podsearch.org's LLM classifier has labelled "likely AI" (only at 0.9 confidence or higher). Coverage is partial and on-demand, so also check whether a few high-volume shows dominate a spike.

Ambiguous terms. Always validate with a random sample of matching titles. A precision below about 80% means your query needs work.

Over-interpreting small numbers. A rise from 4 to 12 episodes is a tripling and also noise. Report counts alongside percentages.

A trend chart people can trust shows:

Keep code and queries in version control. Re-running them next month should produce a comparable series, apart from improved coverage of recent periods.

A worked example

Suppose a home-energy company wants to know whether interest in heat pumps is growing in English-language podcasts, and where.

  1. Vocabulary. "heat pump", "heat pumps", "air source heat pump", "ground source heat pump", combined with OR, with NOT "heat pump dryer" to remove an unrelated appliance.
  2. Field. Titles and descriptions, not transcripts, so transcript adoption does not distort the series.
  3. Windows. Monthly, for 21 complete months, plus a provisional current month.
  4. Metrics. Episode count and distinct show count per month, with language=en.
  5. Control basket. Fifteen everyday topics counted the same way.
  6. Segments. Business, Technology, Leisure and News genres, using genre_ids.
  7. Validation. Read 50 random matching titles: if more than 40 are genuinely about heat pumps, precision is above 80% and the query is usable.

Suppose the result shows episode counts up sharply but show counts up only modestly, concentrated in Technology. That reads as "a handful of tech shows are covering heat pumps much more often", not "heat pumps have gone mainstream". The company might sponsor those tech shows now and re-check in six months for broader spread. Without the show count and the segment cut, the same raw episode chart would have suggested the opposite conclusion.

That is the general lesson: the decision usually depends less on the headline line than on who is driving it.

Building a recurring trend report

Many teams turn this into a monthly product: a fixed list of topics, a fixed method, and a short written commentary. A typical pipeline:

  1. A scheduled job runs each topic query for the last complete month and stores counts.
  2. A second job computes shares against the baseline and growth against the previous month and year.
  3. A third pulls five example episode titles for each top mover.
  4. An analyst writes three paragraphs on what changed and why.

With a fixed topic list of 50 terms of moderate volume, monthly counts typically cost a few hundred API requests a month, comfortably within the Pro plan's 5,000 included requests at $100 a month; very high-volume terms cost more because their windows split. For one-off historical studies with deep pagination, budget for metered usage at $0.80 per 1,000 requests up to 1 million.

Sharing trend data responsibly

Trend charts travel. Once a chart leaves your team, its caveats usually do not. Put the essentials on the chart itself: the query, the fields, the window, the metric and the pull date. Avoid y-axes that start far above zero for small changes, avoid smoothing that hides the provisional final period, and keep example episodes in an appendix so anyone can check what the counts represent. A modest, well-labelled chart is more persuasive in the long run than a dramatic one that falls apart under questioning.

Frequently asked questions

They can be an early signal, because creators respond quickly to what their audiences care about. Treat them as one indicator among several, validated against outcomes you care about.

Should I count episodes or shows?

Both. Episodes measure volume; shows measure breadth. A topic whose show count is rising is spreading; one whose episode count rises but show count does not is being discussed more by the same few shows.

Normalize against a basket of stable control topics counted the same way, and keep the query, fields and segments fixed.

Do transcripts change the results?

Yes. Including transcripts finds spoken mentions that titles and descriptions miss, but transcript availability grows over time, which can create artificial growth. Analyze transcript-based series separately.

How do I keep AI-generated shows from distorting counts?

Use exclude_ai=true, remembering that classifier coverage is partial, and check spikes for single-show dominance.

Summary

Podcast trend analysis is counting with care: decide what a mention is, count episodes and shows in fixed windows, normalize for catalog growth, compare like with like, segment for the real story, and validate with samples. Done carefully, it gives you a view of what millions of hours of conversation are about, and how that is changing month by month.

More for data buyers and researchers