Podcast RSS com Transcrições: Adicione a Tag Certa

A Tag Que Importa

O elemento podcast:transcript permite que apps de podcast exibam sua transcrição sem precisar fazer scraping ou adivinhar. Você hospeda o arquivo, adiciona uma tag dentro do bloco item do seu feed RSS, e qualquer cliente que suporte o namespace Podcasting 2.0 consegue captá-lo. Este post cobre a especificação exata, o panorama de suporte dos apps em meados de 2026, qual formato usar, e os erros comuns que quebram a exibição silenciosamente.

O Que a Especificação Realmente Parece

O elemento vive no namespace Podcasting 2.0, mantido pelo projeto Podcast Index. O elemento channel do seu feed precisa da declaração de namespace, e cada item recebe sua própria tag de transcrição.

<rss version="2.0" xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <item>
      <title>Episódio 42: O Futuro do Áudio ao Vivo</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="pt"/>
    </item>
  </channel>
</rss>

Os quatro atributos:

• url: Link direto para o arquivo de transcrição. Precisa ser HTTPS, sem autenticação.
• type: Tipo MIME. A especificação aceita text/vtt, application/x-subrip (SRT), text/html, text/plain e application/json (o formato JSON do PodcastIndex).
• language: Código BCP 47 como pt ou fr. Opcional quando o atributo de idioma no nível do canal já cobre isso.
• rel: Opcional. Defina como rel="captions" se o arquivo for uma trilha de legendas ao vivo em vez de uma transcrição completa.

Você pode incluir várias tags podcast:transcript por episódio, uma para cada formato ou idioma.

Quem Realmente Lê Sua Tag RSS

É aqui que o quadro fica mais sutil do que a maioria dos guias admite. Existe uma distinção importante entre apps que leem o arquivo vinculado ao seu RSS e apps que geram a própria transcrição de forma independente.

Minha opinião: o enquadramento de "três dos cinco maiores clientes" subestima o que já está no ar. A lacuna real está entre as grandes plataformas de streaming (Spotify, Amazon) e os clientes nativos de podcast. Todo cliente sério de podcast fora dos gigantes de streaming ou já lê sua tag de transcrição ou anunciou que vai ler.

VTT vs SRT vs JSON: Qual Publicar

A spec aceita cinco tipos MIME, mas três formatos fazem o trabalho pesado.

VTT (text/vtt) é o padrão mais forte. Nativo dos navegadores web, suportado por Apple Podcasts, Pocket Casts, Castro, AntennaPod e a maioria dos outros clientes que reconhecem namespaces. Ele suporta nativamente rótulos de falante via identificadores de cue, o que importa para programas de entrevista e co-apresentação. Se você só pode gerar um arquivo, faça VTT.

SRT (application/x-subrip) é mais antigo e mais simples. Sem rótulos de falante nativos (você coloca eles inline no texto do cue), mas reconhecimento quase universal. Use SRT se você também enviar o mesmo arquivo como legendas do YouTube, ou se uma ferramenta downstream exigir. Note que o tipo MIME correto para a tag RSS é application/x-subrip, não application/srt.

JSON (application/json) segue o esquema de transcrição JSON do PodcastIndex com um campo version, um array segments e campos por segmento speaker, startTime, endTime e body. Ele permite timing em nível de palavra e frase, que os apps podem usar para reprodução destacada. O Spotify não pega isso do seu feed RSS, mas clientes como Pocket Casts e Fountain usam para reprodução com rolagem suave.

A maioria dos programas que fazem isso bem publica VTT para a tag RSS e mantém JSON disponível na página do episódio para experiências mais ricas no navegador. Ambos os arquivos são pequenos, bem abaixo de algumas centenas de kilobytes por hora de áudio, então o custo de armazenamento não é um fator. Para gerar qualquer um dos formatos a partir do seu áudio editado, a ferramenta de áudio para texto exporta ambos, e o gerador de legendas permite converter entre eles.

Gerando o Arquivo de Transcrição

Envie o áudio final editado, não a gravação crua. Ferramentas de transcrição com IA lidam muito melhor com áudio pós-edição: vinhetas musicais e sobreposição de falas de takes não editados introduzem erros que acabam no arquivo publicado.

Um fluxo de trabalho típico para um episódio de 45 minutos:

1. Envie o MP3 final para uma ferramenta de transcrição com diarização de falantes ativada.
2. Exporte como VTT. Se o seu host ou fluxo de trabalho suportar JSON, exporte também.
3. Confira os primeiros e últimos dois minutos, além de nomes próprios, termos técnicos ou nomes de convidados.
4. Corrija os rótulos de falante se o diarizador atribuiu "Speaker 1" genérico.
5. Envie os dois arquivos para o seu local de hospedagem.
6. Adicione a tag podcast:transcript ao item do RSS.

O trabalho ativo por episódio é de cerca de dez minutos depois que o áudio está final. Para episódios em que você também gera notas do programa, a transcrição alimenta esse processo diretamente.

Se você precisar de transcrições para dezenas de episódios do catálogo antigo de uma vez, o ConvertAudioToText aceita envio de URLs em lote, então você não fica carregando arquivos um a um.

Onde Hospedar o Arquivo

A URL da transcrição precisa ser publicamente acessível via HTTPS, sem login. Suas opções, mais ou menos em ordem de conveniência:

Seu host de podcast. Buzzsprout, Transistor, Captivate, RSS.com e Fireside aceitam uploads de transcrição por episódio e escrevem a tag do RSS automaticamente. Se o seu host suportar isso, use: eles cuidam dos tipos MIME, CORS e da injeção da tag.

Sua página de episódio ou CMS. Se você publica páginas de episódio no seu próprio site, coloque o arquivo VTT no mesmo diretório e linke-o no feed. Isso também o torna rastreável por mecanismos de busca.

Armazenamento de objetos. Cloudflare R2, AWS S3 e Backblaze B2 servem arquivos estáticos por frações de centavo por gigabyte. Defina o cabeçalho Content-Type: text/vtt explicitamente; a maioria dos CDNs define extensões desconhecidas como application/octet-stream, o que quebra a renderização nos apps.

GitHub Pages. Grátis e suficiente para programas pequenos. Adicione um arquivo _headers para definir o tipo de conteúdo correto.

Cabeçalhos CORS não são necessários, já que os apps buscam o arquivo diretamente, não de um contexto de origem cruzada do navegador. Mas se você configurar CORS, Access-Control-Allow-Origin: * é apropriado para arquivos de transcrição.

Erros Que Quebram a Exibição Silenciosamente

Esses falham sem nenhum erro no cliente de podcast, o que dificulta o diagnóstico:

HTTP em vez de HTTPS. O Apple Podcasts pula silenciosamente qualquer URL de transcrição que não use TLS. Comece com HTTPS e não faça redirecionamento.

Tipo MIME errado. O mais comum. Defina Content-Type: text/vtt no servidor ou na camada de CDN, não apenas no atributo do RSS. Alguns clientes confiam mais no cabeçalho Content-Type do que no tipo declarado.

Tipo MIME errado de SRT na tag. O valor da especificação é application/x-subrip. Usar application/srt (uma variante comum, mas não oficial) faz alguns clientes pularem o arquivo.

Incompatibilidade no atributo de idioma. Se o seu canal diz en mas a tag de transcrição diz en-US, alguns apps se recusam a exibir. Use o mesmo formato do seu feed, ou omita o atributo por completo quando ele duplicar o idioma do nível do canal.

Cues vazias. Transcrições geradas automaticamente costumam emitir cues em branco em silêncios. Remova-as antes de publicar; alguns clientes dão erro silencioso em blocos de cue malformados.

Rótulos de falante ausentes em programas com múltiplos falantes. O Apple mostra um fallback genérico quando os rótulos não existem. Reetiquete na pós-produção antes de publicar. Para entender como a diarização funciona e o que esperar da rotulagem automática, veja diarização de falantes explicada.

Publicação em Vários Idiomas

O elemento podcast:transcript pode aparecer várias vezes por item, uma para cada idioma. Aponte cada um para o arquivo correto com o atributo language correspondente:

<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 oferece suporte a transcrições em inglês, dinamarquês, holandês, finlandês, francês, alemão, italiano, norueguês, português, espanhol e sueco. Episódios com mais de 10 horas não são transcritos pela Apple, e letras de música ficam de fora da renderização da Apple.

Perguntas Frequentes

O Spotify lê a tag podcast:transcript do meu feed RSS?

Não, não diretamente. O Spotify gera suas próprias transcrições para programas selecionados e as exibe na visualização "Now Playing" e nas páginas dos episódios. O que o Spotify suporta é exportar sua transcrição para fora via RSS, para outras plataformas: se você enviar um arquivo VTT ou SRT no Spotify for Creators (em Configurações, depois Transcrições), o Spotify pode distribuí-lo no seu feed RSS para outros apps lerem. O fluxo é do Spotify para outros, não de outros para o Spotify.

Qual formato de arquivo devo publicar no meu feed RSS?

VTT é a escolha mais segura, se você puder escolher só um. Ele é suportado pelo Apple Podcasts (para substituição de transcrição personalizada), Pocket Casts, Castro, AntennaPod, Podcast Addict e outros clientes que reconhecem namespaces. SRT vem logo em seguida. JSON agrega valor para apps que conseguem destacar palavras durante a reprodução, mas funciona melhor como um segundo arquivo na página do episódio, não como o único formato vinculado ao RSS.

Qual tipo MIME devo usar para arquivos SRT?

A especificação Podcasting 2.0 usa application/x-subrip para SRT. Usar application/srt (uma variante informal comum) pode fazer alguns clientes pularem o arquivo. Configure seu CDN ou servidor para servir o arquivo com Content-Type: application/x-subrip e use o mesmo valor no atributo type da sua tag RSS.

Preciso da transcrição também na página do episódio, ou a tag RSS é suficiente?

A tag RSS cuida da exibição dentro dos aplicativos. Publicar o texto da transcrição na página do seu episódio é um passo separado e que vale a pena: áudio não é indexável pelos mecanismos de busca, mas o texto da transcrição é. O post sobre transcrições de acessibilidade em podcasts aborda o caso de SEO e acessibilidade para transcrições na página. Você deve fazer os dois: a tag RSS para os ouvintes nos apps, e a página para descoberta e acesso por leitores de tela.

Fontes

• Especificação do elemento de transcrição do Podcasting 2.0: https://podcasting2.org/docs/podcast-namespace/tags/transcript
• Exemplos de transcrições no namespace do PodcastIndex: https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/transcripts/transcripts.md
• Transcrições no Apple Podcasts para criadores: https://podcasters.apple.com/support/5316-transcripts-on-apple-podcasts
• Gerenciamento de transcrições no Spotify para criadores: https://support.spotify.com/us/creators/article/managing-episode-transcripts-on-spotify/
• Transcrições de episódios no Pocket Casts: https://support.pocketcasts.com/knowledge-base/episode-transcripts/
• Lançamento da tag de transcrição no Castro (fev 2025): https://castro.fm/blog/transcript-tag-release
• Lançamento das transcrições no Overcast (abr 2026): https://9to5mac.com/2026/04/08/overcast-launches-podcast-transcripts-in-new-app-update-for-iphone/
• Quais apps de podcast suportam transcrições (Transistor): https://support.transistor.fm/en/article/which-podcast-apps-support-transcripts-qphklp/