Spotify or YouTube for a Guest: The Test, and What We Already Know

The part that is already measured

We ran this comparison in September 2026 rather than reasoning about it, and the result was lopsided enough that half the question no longer needs an experiment.

Spotify show pages returned four words of server-rendered text. Not four hundred. We tested four separate shows and got the same figure each time, because Spotify renders its pages client-side — a browser executing JavaScript sees a complete page, and a crawler reading raw HTML receives almost nothing.

YouTube channel pages returned roughly 1,800 to 2,000 words for the same shows. More importantly, YouTube states that it creates a video for each episode delivered by RSS, and generates automatic captions in more than sixty languages.

That caption layer is the decisive difference. An audio-only show that publishes no transcript still acquires machine-readable text of the conversation on YouTube, on a general-purpose search surface, without the host doing anything.

It is worth being careful about what this does not say. Spotify is not failing at anything it set out to do: it is a listening application whose pages happen to have URLs, and it serves listeners extremely well. The measurement describes what arrives in a raw HTML response, which is the material available to systems that do not run a browser, and says nothing about the product's quality or its share of actual listening.

The consistency is what makes the figure worth reporting. Four words is not a rounding artefact or an unlucky page: the same number came back from every show we tested, which is the signature of a rendering architecture rather than a content decision about any particular show.

Why that does not settle everything

Because readable text is a precondition for discovery, not a measure of it.

Google's condition for appearing in AI features is that a page be indexed and snippet-eligible — which a four-word page technically can be, while having almost nothing to match against a query. Passing the threshold and being useful are different things.

And a guest does not choose between these platforms in any case. A show publishes to both, or to neither, and the guest inherits whatever the host has connected. The practical question is not which to pick but which to point people at, and which to check after publication.

There is also the possibility that Spotify's rendering changes, or that crawlers capable of executing JavaScript become the norm. A measurement taken in one month describes that month.

There is also a question of where attention actually goes. As reported elsewhere in this series, listening is concentrated in the days after publication while indexed text keeps working for as long as it remains reachable. A platform that dominates the first window and contributes nothing to the second is not losing a contest so much as competing in a different one, and a guest generally wants both.

It is also worth holding the finding loosely for a technical reason. Rendering behaviour is a product decision that can change without announcement, and crawlers that execute JavaScript are becoming more common rather than less. A measurement of raw HTML describes the floor — what any system can read without effort — rather than a permanent ceiling.

The experiment worth running

Not which platform machines prefer — we measured that — but which surface a human actually reaches when searching a guest's name.

For a set of guests with appearances on shows published to both platforms, record what a name search returns at 30, 60 and 90 days: whether the YouTube episode appears, whether the Spotify listing appears, whether the show's own episode page appears, and in what order.

The prediction is that YouTube results will appear and Spotify listings will not, and that neither will outrank the show's own page when that page carries a transcript. If the third clause holds, it reframes the entire platform question as secondary to the episode page.

Measurement uses Search Console impressions where the guest controls a property, plus captured results pages, rather than assistant screenshots — for the reasons set out in the other protocols in this series.

Guest selection matters more than sample size here. People with common names will return results dominated by namesakes regardless of any appearance, and people with existing heavy coverage will show no movement because the first page is already full. The design wants subjects with distinctive names and thin existing footprints, which is also the population most likely to be buying placement in the first place.

The control condition matters as much as the treatment. A guest with no new appearances should be searched on the same schedule, because name-search results move on their own as other people publish, change jobs or share surnames. Without that comparison, ordinary churn in a results page reads as an effect of the campaign.

The caption accuracy problem

YouTube's text layer is machine-generated, and the platform says so plainly.

Its guidance warns that automatic captions "might misrepresent the spoken content due to mispronunciations, accents, dialects, or background noise", and instructs creators to "always review automatic captions and edit any parts that haven't been properly transcribed".

For a guest this is the single most actionable finding in the whole comparison, because it is checkable within days. Open the episode on YouTube, show the transcript, and search it for your name and your company. If either is mangled, the searchable text asserts something wrong about you on a page you do not control.

A host can correct captions. Most will if asked and few will notice unprompted, which makes this a reasonable thing to raise immediately after publication rather than months later.

The asymmetry of who notices is the real issue. A host reviews captions for their own name and their show's name, both of which the model handles well because they recur. A guest's surname and company appear once, in an unfamiliar context, and are exactly what speech recognition gets wrong — so the errors cluster on precisely the terms the guest cares about and nobody else is checking.

Checking costs nothing and can be done the week an episode drops. Open the video, expand the description, show the transcript, and search it for your surname and your company. Two searches settle whether the only full-text record of your appearance says what you actually said.

What this means for anyone booking appearances

Ask whether the show publishes to YouTube, because for an audio-only show that is often where the only full-text record of the conversation will exist.

Do not count a Spotify listing as discoverability. It is a major listening destination and, on our measurement, contributes four words to anything reading raw HTML while separately blocking GPTBot.

Check the captions after publication and ask for corrections where your name or company is wrong.

And keep the ordering straight. Media Morpheus books podcast appearances, and the evidence we have says the episode page matters more than the platform, the platform matters more than the directory count, and the audio — the thing everyone actually discusses when booking — matters least of all to anything that reads.

The ordering also tells you where to spend attention when time is short: one question to the host about transcripts outranks any amount of deliberation about which platform to promote.

The broader point is that none of these decisions belong to the guest, which is precisely why they are worth asking about before agreeing to record rather than discovering afterwards.

Methodology and limitations

This report combines an original measurement with a protocol not yet executed. The measurement retrieved podcast platform pages in September 2026 with a desktop browser user agent, removed script and style blocks, and counted remaining words; URLs were discovered rather than constructed. Five limits apply. First, word counts describe server-rendered HTML: Spotify renders client-side, so the figure states what raw HTML contains rather than what a person sees. Second, the sample is purposive and describes the shows tested. Third, the comparative search experiment is published in advance of execution and no results from it are reported. Fourth, platform rendering and robots.txt rules change without notice. Fifth, as no operator publishes how sources are selected for citation, nothing here attributes retrieval outcomes to a mechanism.

Conclusion

Half of this question is already answered and the answer is stark: Spotify returned four words of crawler-readable text on every show we tested and blocks GPTBot by name, while YouTube returned around two thousand and manufactures a caption track for audio that had none. For machine discoverability that is not close. The half still worth testing is human — which surface a person actually lands on when they search a guest's name — and the prediction worth recording is that the show's own episode page beats both when it carries a transcript. If that holds, the platform argument is a distraction from the page, which is where this series' podcast measurements keep pointing.

Frequently Asked Questions

Sources

1. vendor research Media Morpheus, September 2026. Original measurement of podcast platform pages and robots.txt. Method and limitations stated above.
2. official YouTube Help. Deliver podcasts using an RSS feed, for episode-to-video conversion.
3. official YouTube Help. Automatic captions, for language coverage and the accuracy warning.