What the tag is, and what we counted
The Podcasting 2.0 namespace defines a podcast:transcript tag whose stated purpose is "to link to a transcript or closed captions file". It takes a required url and a required type, with optional language and rel attributes, and supports five content types: plain text, HTML, VTT, JSON and SubRip.
That tag is the only machine-readable declaration in an RSS feed that says a transcript exists and where to get it. Anything reading the feed can follow it; anything not reading it has to guess.
We retrieved 52 real podcast feeds in September 2026, spanning technology, business, news, interview and general-interest shows, and counted transcript declarations. Ten feeds declared them. Forty-two did not.
Then we followed the declarations. Every transcript file we tested returned successfully, ranging from 7KB to 206KB. Changelog and JS Party publish HTML, Practical AI publishes each episode three times over in VTT, SRT and JSON, Darknet Diaries and the two Python shows use VTT, and Acquired uses plain text.
One limitation of the tag is worth stating at the outset. Its absence does not prove a transcript does not exist. Several shows in our sample publish transcripts on their websites without declaring them in the feed — Lex Fridman's site returned a 22,513-word transcript page for a recent episode despite the feed declaring none. The tag measures whether a transcript is machine-discoverable from the feed, which is a narrower and more useful question than whether one was ever produced.
The five supported content types are worth noting for anyone building on this: plain text and HTML are readable by any crawler without special handling, while VTT, SRT and JSON carry timing information that a player can sync but a simple text extractor may choke on. A transcript published only as a timed caption file is machine-readable in principle and awkward in practice.
podcast:transcript tags in the feed, September 2026
Source: Media Morpheus original measurement of 52 podcast RSS feeds, September 2026.
Security Now and TWiT also declared transcripts but expose only ten episodes in-feed, so their counts are not comparable.
The finding we did not expect
The two feeds with the most transcript declarations publish them on a domain that no crawler is allowed to read.
All 777 of Changelog's declarations and all 352 of JS Party's point at changelog.com. That domain's entire robots.txt is two lines: user-agent: * followed by disallow: /.
The files themselves are real. They fetch, they contain the conversation, and they are correctly declared in the feed. But as Google's robots.txt documentation sets out, a disallow rule governs fetching, and a compliant crawler will not retrieve them.
So 1,129 machine-readable transcripts — the largest concentration in our sample — are simultaneously the most carefully published and the least reachable. A publisher can do everything the transcript advocates recommend and still be invisible to the systems the advice is aimed at.
The publisher may have entirely sound reasons for it, and we are not suggesting otherwise.
A correction worth recording
Our first pass reported four affected feeds rather than two, and the error is instructive.
We had checked each show's homepage domain rather than the host actually serving its transcript files. On that basis Practical AI appeared blocked, because it is published by the same organisation as Changelog, and Diary of a CEO appeared blocked because we tested its hosting platform.
Checking the file host instead corrected both. Practical AI's 340 transcripts are served from share.transistor.fm, which is open; Diary of a CEO's 153 come from rss.flightcast.com, which carries only partial rules.
The finding halved. We report it that way because the smaller number is the true one, and because the mistake illustrates the same distinction the whole report is about: where a file actually lives determines whether anything can read it, and the brand on the show is no guide at all.
Every major platform already generates transcripts
Which raises an obvious question about why the feed tag matters at all.
Apple states it "automatically generates transcripts after a new episode is published", labels them "Automatically generated" in the app, accepts creator-supplied VTT or SRT files, supports eleven languages and is available in over 170 countries.
Spotify generates transcripts for some shows, lets creators toggle them per episode or show-wide, and accepts uploads of VTT or SRT under 5MB — though "if you upload your own transcript, it'll be replaced if you enable auto-generated ones".
YouTube produces automatic captions in more than sixty languages while warning they "might misrepresent the spoken content due to mispronunciations, accents, dialects, or background noise".
The distinction is where the text lives. A platform-generated transcript exists inside that platform's application. A transcript declared in the feed, or published on a crawlable episode page, exists on the open web where a search engine or an AI retrieval system can reach it. Those are different assets, and only the second one is addressable.
There is also an override worth knowing about if you supply your own. Spotify states that an uploaded transcript "will be replaced if you enable auto-generated ones", and that transcripts cannot be edited directly in its creator tools. A show that carefully produces an accurate transcript can have it silently superseded by machine output.
What none of the platforms claim
That transcripts help you be found.
We read the transcript documentation from all three platforms specifically looking for a discovery claim. Apple's makes no statement about transcripts affecting discovery or search ranking. Spotify's addresses none. YouTube's guidance on automatic captions covers accuracy and language support and is silent on discoverability.
That silence is worth weighing against the practitioner claim that transcript accessibility materially affects citation opportunities. The claim is plausible — a transcript turns an hour of audio into thousands of words of indexable text, and Google's condition for AI feature eligibility is that a page be indexed and snippet-eligible.
But plausible is not measured. No platform operator has published a figure, and neither have we: this report counts what exists and what is reachable, which is a different question from what gets cited.
It is worth separating two claims that get merged. That a transcript makes an episode legible to machines is close to definitional — text is readable and audio is not. That producing one raises the odds of being cited by a particular AI system is an empirical claim about undocumented selection processes, and as reported elsewhere in this series, no operator publishes how sources are chosen. The first is safe to act on; the second is not safe to sell.
What this means for anyone booking appearances
Ask whether a transcript will be published, and where it will live. A transcript inside Apple's app is not a transcript on a crawlable page, and only the second is an asset you can point anyone at.
Check the host's robots.txt before assuming anything is readable. It takes seconds, and in our sample the single most transcript-rich publisher blocks everything.
Notice which shows do this at all. Among the business and interview shows a guest is typically booked on, only Diary of a CEO declared transcripts. SmartLess, Tim Ferriss, My First Million, Invest Like the Best, 20VC, Lenny's Podcast, Founders and No Priors declared none. The practice is overwhelmingly a technology-podcast habit.
And publish your own. Where a show will not produce a transcript, a guest can put one on a domain they control, with the episode linked from it. Media Morpheus books podcast appearances, and this is the part of the outcome a guest can actually determine — the host decides whether the episode becomes text, and you decide whether you do anything about it.
The asymmetry in who benefits is worth noticing too. A host bears the cost of producing transcripts and the guest captures much of the discoverability benefit, which may explain why adoption clusters among shows whose audiences actively search technical terms rather than among interview shows where guests rotate weekly.
Methodology and limitations
This is an original measurement conducted in September 2026. We retrieved 52 podcast RSS feeds selected purposively across technology, business, news, interview and general-interest categories, counted podcast:transcript declarations, extracted every declared transcript URL, and identified the host serving each file. We fetched a sample transcript per declaring feed to confirm it resolved, and retrieved and parsed the robots.txt of each transcript host by grouping consecutive user-agent lines. Seven limits apply. First, the sample is purposive and not representative; the rates here describe these 52 feeds and should not be read as an industry figure. Second, the unit is the feed rather than the show, and one show can publish several feeds with different contents. Third, Security Now and TWiT expose only ten episodes in-feed, so their declaration counts are not comparable with full archives. Fourth, the absence of a podcast:transcript tag does not mean no transcript exists: several shows without the tag publish transcripts on their websites, which we verified in at least one case. Fifth, robots.txt records stated permission rather than crawler behaviour. Sixth, an earlier pass of this analysis checked show homepage domains rather than transcript file hosts and overstated the blocked count; that error is described in the report and the corrected figure is used throughout. Seventh, figures describe a single moment.
Conclusion
Transcripts plausibly matter more to machines than the audio does, for the straightforward reason that machines read text and audio is opaque to anything that does not transcribe it. What our measurement adds is how rarely the work is done in a form anything can use. Ten of 52 feeds declare a machine-readable transcript, the practice is almost entirely confined to technology shows, and the single largest concentration — 1,129 declarations across two feeds — sits on a domain that instructs every crawler to stay away. Meanwhile Apple, Spotify and YouTube all generate transcripts automatically and none of them claims it helps you be found. The gap between producing a transcript and publishing one anything can reach is where this subject actually lives, and almost nobody is measuring it.
Frequently Asked Questions
How many podcasts publish machine-readable transcripts?
In our sample of 52 feeds, ten declared them using the podcast:transcript tag and 42 did not. The practice was almost entirely confined to technology shows.
What is the podcast:transcript tag?
A Podcasting 2.0 namespace element whose stated purpose is "to link to a transcript or closed captions file", with a required url and type, supporting plain text, HTML, VTT, JSON and SubRip.
Do platform transcripts count?
Apple, Spotify and YouTube all generate them automatically, but those live inside each platform's application. A transcript on a crawlable web page is a different and more addressable asset.
Do transcripts improve AI citation?
No platform claims so. Apple, Spotify and YouTube's transcript documentation makes no discovery or ranking claim, and we have measured what exists rather than what gets cited.
Can a transcript exist but be unreadable?
Yes. Two feeds in our sample serve all 1,129 of their declared transcripts from a domain whose robots.txt forbids every compliant crawler.
What should a guest do?
Ask whether a transcript will be published and where it will live, check the host's robots.txt, and publish your own transcript on a domain you control if the show will not.
Sources
- vendor research Media Morpheus, September 2026. Original measurement of 52 podcast RSS feeds, transcript declarations, transcript file hosts and robots.txt. Method and limitations stated above.
- official Apple. Transcripts on Apple Podcasts, for automatic generation, creator uploads and language support.
- official Spotify. Managing episode transcripts on Spotify, for auto-generation, upload formats and the override behaviour.
- official YouTube Help. Automatic captions, for language support and the accuracy warning.