Podcast-RSS mit Transkripten: Das richtige Tag hinzufügen

Der entscheidende Tag

Das podcast:transcript-Element ermöglicht Podcast-Apps, Ihr Transkript anzuzeigen, ohne zu scrapen oder zu raten. Sie hosten die Datei, fügen einen Tag im item-Block Ihres RSS-Feeds hinzu, und jeder Client, der den Podcasting-2.0-Namespace unterstützt, kann sie abrufen. Dieser Beitrag behandelt die genaue Spezifikation, den Stand der App-Unterstützung Mitte 2026, welches Format Sie verwenden sollten und die häufigen Fehler, die die Anzeige stillschweigend brechen.

Wie die Spezifikation tatsächlich aussieht

Das Element lebt im Podcasting-2.0-Namespace, der vom Podcast-Index-Projekt gepflegt wird. Das channel-Element Ihres Feeds benötigt die Namespace-Deklaration, und jedes item erhält seinen eigenen Transkript-Tag.

<rss version="2.0" xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <item>
      <title>Episode 42: The Future of Live Audio</title>
      <enclosure url="https://example.com/episodes/42.mp3" length="..." type="audio/mpeg"/>
      <podcast:transcript
        url="https://example.com/transcripts/42.vtt"
        type="text/vtt"
        language="en"/>
    </item>
  </channel>
</rss>

Die vier Attribute:

• url: Direkter Link zur Transkriptdatei. Muss HTTPS sein, keine Authentifizierung.
• type: MIME-Typ. Die Spezifikation akzeptiert text/vtt, application/x-subrip (SRT), text/html, text/plain und application/json (das PodcastIndex-JSON-Format).
• language: BCP-47-Code wie en oder fr. Optional, wenn Ihr sprachspezifisches Attribut auf Kanal-Ebene dies bereits abdeckt.
• rel: Optional. Setzen Sie rel="captions", wenn die Datei eine Live-Untertitelspur und kein vollständiges Transkript ist.

Sie können mehrere podcast:transcript-Tags pro Episode einfügen, einen pro Format oder Sprache.

Wer Ihren RSS-Tag tatsächlich liest

Hier wird das Bild nuancierter, als die meisten Anleitungen zugeben. Es gibt einen wichtigen Unterschied zwischen Apps, die deine eigene, per RSS verknüpfte Datei lesen, und Apps, die selbstständig ein eigenes Transkript erstellen.

Meine Einschätzung: Die Formulierung „drei der fünf größten Clients“ verkauft das, was tatsächlich live ist, unter Wert. Die eigentliche Kluft liegt zwischen den großen Streaming-Plattformen (Spotify, Amazon) und den Podcast-nativen Clients. Jeder ernsthafte Podcast-Client außerhalb der Streaming-Giganten liest dein Transkript-Tag bereits oder hat es angekündigt.

VTT vs. SRT vs. JSON: Was solltest du veröffentlichen?

Die Spezifikation akzeptiert fünf MIME-Typen, aber drei Formate leisten die eigentliche Arbeit.

VTT (text/vtt) ist der stärkste Standard. Nativ in Webbrowsern, unterstützt von Apple Podcasts, Pocket Casts, Castro, AntennaPod und den meisten anderen namespace-bewussten Clients. Es unterstützt nativ Sprecherlabels über Cue-Identifikatoren, was für Interviews und Shows mit mehreren Moderatoren wichtig ist. Wenn du nur eine Datei generieren kannst, mach es als VTT.

SRT (application/x-subrip) ist älter und einfacher. Keine nativen Sprecherlabels (du setzt sie inline in den Cue-Text), aber nahezu universelle Erkennung. Nutze SRT, wenn du dieselbe Datei auch als YouTube-Untertitel hochlädst oder ein nachgelagertes Tool es verlangt. Beachte, dass der korrekte MIME-Typ für das RSS-Tag application/x-subrip ist, nicht application/srt.

JSON (application/json) folgt dem PodcastIndex-JSON-Transkript-Schema mit einer version, einem segments-Array und den Feldern speaker, startTime, endTime und body pro Segment. Es ermöglicht Timing auf Wort- und Satzebene, das Apps für hervorgehobene Wiedergabe nutzen können. Spotify zieht das nicht aus deinem RSS-Feed, aber Clients wie Pocket Casts und Fountain verwenden es für flüssiges Scrollen während der Wiedergabe.

Die meisten Shows, die das gut machen, veröffentlichen VTT für das RSS-Tag und halten JSON auf der Episodenseite für reichhaltigere Browser-Erlebnisse bereit. Beide Dateien sind klein, weit unter ein paar hundert Kilobyte pro Stunde Audio, also spielen Speicherkosten keine Rolle. Zum Generieren beider Formate aus deinem bearbeiteten Audio exportiert das Audio-zu-Text-Tool beide, und der Untertitel-Generator ermöglicht die Konvertierung zwischen ihnen.

Generieren der Transkriptdatei

Lade das final bearbeitete Audio hoch, nicht die Rohaufnahme. KI-Transkriptionstools verarbeiten nachbearbeitetes Audio deutlich besser: Musik-Einwürfe und Übersprechen aus unbearbeiteten Takes führen zu Fehlern, die in der veröffentlichten Datei landen.

Ein typischer Workflow für eine 45-minütige Episode:

1. Lade die finale MP3 in ein Transkriptionstool mit aktivierter Sprecher-Diarisierung hoch.
2. Exportiere als VTT. Wenn dein Host oder Workflow JSON unterstützt, exportiere das ebenfalls.
3. Prüfe stichprobenartig die ersten und letzten zwei Minuten sowie Eigennamen, Fachbegriffe oder Gästenamen.
4. Korrigiere Sprecherlabels, falls der Diarisierer generische „Sprecher 1“-Labels vergeben hat.
5. Lade beide Dateien an deinen Hosting-Ort hoch.
6. Füge das podcast:transcript-Tag zum RSS-Item hinzu.

Die aktive Arbeit pro Episode beträgt nach der finalen Audiodatei etwa zehn Minuten. Bei Episoden, für die du auch Podcast-Show-Notes erstellst, speist das Transkript diesen Prozess direkt.

Wenn du Transkripte für Dutzende Back-Katalog-Episoden auf einmal brauchst, unterstützt ConvertAudioToText die Stapel-URL-Übermittlung, sodass du Dateien nicht einzeln hochladen musst.

Wo du die Datei hostest

Die Transkript-URL muss öffentlich über HTTPS ohne Login erreichbar sein. Deine Optionen, grob nach Bequemlichkeit geordnet:

Dein Podcast-Host. Buzzsprout, Transistor, Captivate, RSS.com und Fireside akzeptieren alle Transkript-Uploads pro Episode und schreiben das RSS-Tag automatisch für dich. Wenn dein Host das unterstützt, nutze es: Sie kümmern sich um MIME-Typen, CORS und Tag-Injektion.

Deine Episodenseite oder dein CMS. Wenn du Episodenseiten auf deiner eigenen Website veröffentlichst, lege die VTT-Datei in dasselbe Verzeichnis und verlinke sie aus dem Feed. Das macht sie auch für Suchmaschinen crawlfähig.

Objekt-Speicher. Cloudflare R2, AWS S3 und Backblaze B2 liefern statische Dateien für Bruchteile eines Cents pro Gigabyte. Setze explizit einen Content-Type: text/vtt-Header; die meisten CDNs setzen bei unbekannten Endungen standardmäßig application/octet-stream, was die App-Darstellung bricht.

GitHub Pages. Kostenlos und für kleine Shows ausreichend. Füge eine _headers-Datei hinzu, um den korrekten Content-Type zu setzen.

CORS-Header sind nicht erforderlich, da Apps die Datei direkt abrufen und nicht aus einem browserübergreifenden Kontext. Wenn Sie CORS aber konfigurieren, ist Access-Control-Allow-Origin: * für Transkriptdateien angemessen.

Fehler, die die Anzeige still brechen

Diese treten ohne Fehlermeldung im Podcast-Client auf und sind daher schwer zu diagnostizieren:

HTTP statt HTTPS. Apple Podcasts überspringt still jede Transkript-URL, die kein TLS verwendet. Beginnen Sie mit HTTPS und leiten Sie nicht um.

Falscher MIME-Typ. Der häufigste Fehler. Setzen Sie Content-Type: text/vtt auf Server- oder CDN-Ebene, nicht nur im RSS-Attribut. Einige Clients vertrauen dem Content-Type-Header mehr als dem deklarierten Typ.

Falscher SRT-MIME-Typ im Tag. Der Spezifikationswert ist application/x-subrip. Die Verwendung von application/srt (eine verbreitete, aber inoffizielle Variante) führt dazu, dass einige Clients die Datei überspringen.

Sprachattribut-Mismatch. Wenn Ihr Kanal en angibt, das Transkript-Tag aber en-US, verweigern einige Apps die Anzeige. Passen Sie das Format an Ihren Feed an oder lassen Sie das Attribut ganz weg, wenn es die Sprache auf Kanalebene duplizieren würde.

Leere Cues. Automatisch generierte Transkripte geben bei Stille oft leere Cues aus. Entfernen Sie diese vor der Veröffentlichung; einige Clients melden bei fehlerhaften Cue-Blöcken still einen Fehler.

Fehlende Sprecherlabels bei Shows mit mehreren Sprechern. Apple zeigt ein generisches Fallback, wenn Labels fehlen. Beschriften Sie in der Nachbearbeitung vor der Veröffentlichung neu. Wie Diarisierung funktioniert und was Sie von automatischer Beschriftung erwarten können, erklärt Sprecher-Diarisierung verständlich erklärt.

Veröffentlichung in mehreren Sprachen

Das podcast:transcript-Element kann pro item mehrfach vorkommen, einmal pro Sprache. Verweisen Sie jeweils auf die passende Datei mit dem passenden language-Attribut:

<podcast:transcript
  url="https://example.com/transcripts/42-en.vtt"
  type="text/vtt"
  language="en"/>
<podcast:transcript
  url="https://example.com/transcripts/42-fr.vtt"
  type="text/vtt"
  language="fr"/>

Apple Podcasts unterstützt Transkripte auf Englisch, Dänisch, Niederländisch, Finnisch, Französisch, Deutsch, Italienisch, Norwegisch, Portugiesisch, Spanisch und Schwedisch. Folgen über 10 Stunden werden von Apple nicht transkribiert, und Songtexte sind von Apples Darstellung ausgeschlossen.

Häufige Fragen

Liest Spotify das podcast:transcript-Tag aus meinem RSS-Feed?

Nein, nicht direkt. Spotify erstellt eigene Transkripte für ausgewählte Shows und zeigt sie in der Now-Playing-Ansicht sowie auf den Episodenseiten an. Was Spotify unterstützt, ist das Exportieren deines Transkripts über RSS an andere Plattformen: Wenn du eine VTT- oder SRT-Datei in Spotify for Creators hochlädst (Einstellungen, dann Transkripte), kann Spotify sie über deinen RSS-Feed an andere Apps verteilen. Der Fluss geht also von Spotify zu anderen, nicht von anderen zu Spotify.

Welches Dateiformat sollte ich in meinem RSS-Feed veröffentlichen?

VTT ist die sicherste Einzelwahl. Es wird von Apple Podcasts (für benutzerdefinierte Transkript-Überschreibung), Pocket Casts, Castro, AntennaPod, Podcast Addict und anderen namespace-bewussten Clients unterstützt. SRT ist ein enger Zweiter. JSON bietet Mehrwert für Apps, die Wörter während der Wiedergabe hervorheben können, funktioniert aber am besten als zweite Datei auf deiner Episodenseite, nicht als einziges RSS-verknüpftes Format.

Welchen MIME-Typ verwende ich für SRT-Dateien?

Die Podcasting-2.0-Spezifikation verwendet application/x-subrip für SRT. Die Verwendung von application/srt (eine gängige informelle Variante) kann dazu führen, dass einige Clients die Datei überspringen. Stelle deinen CDN oder Server so ein, dass die Datei mit Content-Type: application/x-subrip ausgeliefert wird, und gleiche das im type-Attribut deines RSS-Tags ab.

Brauche ich das Transkript auch auf meiner Episodenseite, oder reicht das RSS-Tag?

Der RSS-Tag übernimmt die Anzeige in der App. Den Transkripttext auf deiner Episodenseite zu veröffentlichen, ist ein separater, lohnender Schritt: Audio ist für Suchmaschinen nicht indexierbar, Transkripttext schon. Der Beitrag zu Podcast-Barrierefreiheit-Transkripten behandelt die SEO- und Barrierefreiheitsargumente für Transkripte auf der Seite. Du solltest beides tun: den RSS-Tag für Hörer in Apps, die Seite für Auffindbarkeit und Screenreader-Zugriff.

Quellen

• Podcasting 2.0 Transkript-Element-Spezifikation: https://podcasting2.org/docs/podcast-namespace/tags/transcript
• PodcastIndex-Namespace-Transkriptbeispiele: https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/transcripts/transcripts.md
• Apple Podcasts-Transkripte für Creator: https://podcasters.apple.com/support/5316-transcripts-on-apple-podcasts
• Spotify-Transkriptverwaltung für Creator: https://support.spotify.com/us/creators/article/managing-episode-transcripts-on-spotify/
• Pocket Casts-Episodentranskripte: https://support.pocketcasts.com/knowledge-base/episode-transcripts/
• Castro-Transkript-Tag-Veröffentlichung (Feb. 2025): https://castro.fm/blog/transcript-tag-release
• Overcast-Transkripte-Launch (Apr. 2026): https://9to5mac.com/2026/04/08/overcast-launches-podcast-transcripts-in-new-app-update-for-iphone/
• Welche Podcast-Apps unterstützen Transkripte (Transistor): https://support.transistor.fm/en/article/which-podcast-apps-support-transcripts-qphklp/