En France, « podcast seo » pèse 90 recherches par mois et « transcription podcast » 90 également. Ce sont deux intentions très différentes, et la première page de résultats le montre bien : sur « podcast seo », sept des huit résultats organiques sont des classements de podcasts SEO à écouter ou des fiches de podcast, de Codeur à Paul Vengeons en passant par la page Spotify d'une émission. Le huitième est un fil Reddit en anglais. Aucune page française n'y traite la question inverse, celle de savoir comment un podcast se fait citer par un moteur génératif.
Hier, j'ai mesuré ce qu'une page de vidéo YouTube donne à lire à un robot, et la réponse était brutale : le chemin vers la transcription est déclaré puis interdit par le site lui-même. Je m'attendais à retrouver le même verrou côté audio. Les plateformes de podcast sont des jardins fermés au moins autant que YouTube, et l'audio est encore moins lisible qu'une vidéo.
La mesure dit exactement le contraire. Pour le podcast, la chaîne d'accès est ouverte de bout en bout. Le verrou n'est pas chez les plateformes. Il est chez les producteurs, et il tient en un chiffre.
Ce que j'ai mesuré le 25 août 2026. J'ai récupéré neuf flux RSS de podcasts francophones réels, à travers six hébergeurs différents, et compté dans chacun le nombre d'épisodes et le nombre de balises <podcast:transcript>. J'ai relevé les fichiers robots.txt d'Apple Podcasts, de Spotify, de Deezer, d'Ausha, d'Acast et d'un site de podcasteur. J'ai demandé cinq pages réelles avec l'agent utilisateur de PerplexityBot, le seul robot génératif que les fichiers robots.txt concernés laissent passer partout, pour compter le texte lisible sans JavaScript. J'ai téléchargé les fichiers de transcription effectivement déclarés pour vérifier leur format et leur type MIME. J'ai lu la spécification du tag dans le dépôt Podcast Index. J'ai vérifié le statut de la documentation Google sur les données structurées de podcast. Et j'ai posé à ChatGPT, en recherche web activée, une question construite mot pour mot sur une phrase publiquement lisible dans une de ces transcriptions, pour voir qui serait cité.
Aucune plateforme de podcast ne ferme la porte aux robots IA
Le point de départ d'un podcast n'est pas une page, c'est un fichier XML. Le flux RSS est servi en direct, sans JavaScript, sans authentification, et c'est lui qui alimente Apple, Spotify, Deezer et tous les lecteurs. Un robot qui sait lire du XML lit un catalogue complet d'épisodes avec titres, descriptions et dates.
Ensuite viennent les plateformes. Le fichier robots.txt d'Apple Podcasts tient en dix lignes utiles, les voici toutes :
User-agent: *
Disallow: /WebObjects/*
Disallow: /api/*
Disallow: /includes/*
Disallow: /v1/*
Sitemap: .../sitemaps_podcasts_index_podcast_1.xml
Sitemap: .../sitemaps_podcasts_index_podcast-episode_1.xml
Sitemap: .../sitemaps_podcasts_index_podcast-channel_1.xml
Sitemap: .../sitemaps_podcasts_index_staticUrl_1.xml
Sitemap: .../sitemaps_podcasts_index_genre_1.xml
Une ligne d'agent, quatre interdictions toutes techniques, cinq sitemaps, et aucun robot d'intelligence artificielle nommé. Ni GPTBot, ni ClaudeBot, ni PerplexityBot, ni CCBot, ni Google-Extended. Et Apple ne se contente pas de laisser passer : il publie un index de sitemaps dédié aux épisodes. Cet index référence 300 fichiers. J'en ai décompressé un au hasard, sitemaps_podcasts_podcast-episode_42_3.xml.gz, qui pèse 545 kilooctets compressés, 21 mégaoctets une fois ouvert, et contient 12 601 adresses d'épisodes. L'ordre de grandeur de ce qui est explicitement offert au crawl se compte donc en millions de pages.
Spotify est le seul à poser une limite, et elle est intéressante à lire dans le détail :
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: ClaudeBot
Disallow: /
La liste continue avec Applebot-Extended, anthropic-ai, Claude-Web, cohere-ai, Meta-ExternalAgent, FacebookBot et Bytespider. Un commentaire du fichier annonce l'intention : ces robots sont bloqués pour éviter d'alimenter des poids de modèle avec le graphe du catalogue. Ce sont tous des robots d'entraînement ou d'archivage. Aucun robot de recherche ni aucun robot déclenché par un utilisateur n'y figure : OAI-SearchBot, ChatGPT-User, PerplexityBot et Claude-User passent. Spotify ne se ferme donc pas aux réponses génératives, il se ferme à l'apprentissage. C'est exactement la distinction détaillée dans notre article sur les user-agents des crawlers IA, et il est rare de la voir appliquée avec cette netteté.
Restent les hébergeurs et les sites. Ausha répond User-agent: * suivi d'un Disallow: vide, ce qui autorise tout. Acast répond User-agent: * puis Allow: /. Le site de Génération Do It Yourself n'interdit que /wp-admin/. Deezer, de son côté, énumère nommément une vingtaine d'agents génératifs pour leur appliquer les mêmes exclusions de chemin qu'à tout le monde, ce qui revient à les traiter comme des visiteurs ordinaires.
Bilan de la chaîne : le flux est ouvert, le catalogue est ouvert, les fiches sont ouvertes, le site du podcasteur est ouvert. Contrairement à la vidéo, où le chemin vers la transcription est explicitement interdit, rien ici n'empêche un moteur d'aller lire. La question devient donc : qu'y a-t-il à lire.
Trois heures de conversation, 704 mots sur la page
J'ai demandé cinq pages réelles avec un agent utilisateur de navigateur ordinaire, retiré les balises script et style, retiré les balises restantes, et compté les mots.
Domaine servi Duree Mots lisibles Transcription
------------------ ------ ------------- -------------
open.spotify.com serie 9 non
podcasts.apple.com 1 h 01 796 non
www.gdiy.fr 3 h 02 704 non
shows.acast.com 2 h 08 2 256 champ vide
podcast.ausha.co 1 h 17 64 080 oui, 14 914
Les cinq répondent HTTP 200 au robot de Perplexity, sans blocage ni page d'avertissement.
La première ligne est la plus spectaculaire, et elle demande une précision. Une page de série sur Spotify pèse 167 kilooctets de HTML et sert neuf mots au robot de Perplexity : le titre de l'émission, rien d'autre. J'ai refait la mesure avec cinq agents utilisateurs différents, deux fois chacun, et les résultats sont stables : neuf mots pour PerplexityBot, neuf pour OAI-SearchBot, neuf pour ClaudeBot, neuf pour Googlebot, quatre pour un Chrome récent. Un seul cas sort du lot, celui d'un curl qui ne se déclare pas du tout : il reçoit 1 726 mots, avec la description de l'émission et la liste des épisodes. Autrement dit, la page complète existe côté serveur, et tout agent qui s'annonce, robot de recherche compris, reçoit la coquille vide construite par JavaScript. C'est le mécanisme documenté par l'étude Vercel et Merj sur 569 millions de requêtes GPTBot, repris dans notre article sur le rendu JavaScript et les crawlers IA.
La deuxième ligne est plus subtile. Une fiche d'épisode Apple Podcasts sert 796 mots pour un épisode d'une heure. Celle que j'ai mesurée est podcasts.apple.com/fr/podcast/i-was-758/id1441824608?i=1000664698421, tirée au hasard d'un des sitemaps d'épisodes cités plus haut. Ce sont le titre, la description, quelques liens de navigation. Le mot « transcript » n'apparaît pas une seule fois dans le HTML, à aucune casse. Or Apple produit ce texte. Son communiqué du 5 mars 2024 annonce les transcriptions automatiques dans l'application, disponibles avec iOS 17.4 pour les podcasts en anglais, en français, en espagnol et en allemand, dans plus de 170 pays, et générées « shortly after episodes are published ». Le même communiqué précise que les producteurs peuvent fournir la leur, verbatim : « Creators who prefer to provide their own transcripts can do so through RSS tags or in Apple Podcasts Connect for subscriber episodes. » Apple transcrit donc, affiche à ses utilisateurs, invite les producteurs à passer par le flux RSS, et ne publie rien de tout cela sur le web. Le texte existe et reste dans l'application.
La troisième ligne est celle qui devrait faire réfléchir tout producteur de podcast. www.gdiy.fr est le site officiel de Génération Do It Yourself, l'un des plus gros podcasts d'entretien francophones. La page de l'épisode avec Yaël Braun-Pivet correspond à trois heures et deux minutes d'enregistrement. Elle sert 704 mots lisibles. Sur son propre domaine, où il contrôle tout, l'éditeur publie l'équivalent d'une page et demie de texte pour trois heures de conversation avec la présidente de l'Assemblée nationale. La page porte pourtant un balisage PodcastEpisode en JSON-LD de 1 252 caractères, plus un bloc CreativeWorkSeries. Le vocabulaire est propre. Il décrit un contenu qui n'est pas là.
La quatrième ligne apporte la variante la plus parlante. La page Acast d'un épisode de deux heures huit sert 2 256 mots, ce qui est déjà mieux, et son objet de données interne contient un champ dédié :
"status":"published","transcript":{},"_id":"6a53b6b7a410914b580f6dca"
J'ai compté ce champ sur la page entière : dix occurrences, pour les dix épisodes listés, et les dix sont des objets vides. Acast a prévu la place. Personne ne la remplit. C'est une image assez juste de l'état du sujet : l'infrastructure est prête, le contenu manque.
La cinquième ligne montre à quoi ressemble le cas favorable. Sur la page Ausha de l'épisode de Trench Tech avec Yann Ferguson, un élément <article class="Transcript-module..."> est rendu côté serveur et contient 234 éléments de liste, chacun avec une étiquette de locuteur et un paragraphe de texte. Ce bloc pèse 14 914 mots. Il est dans le HTML, sans JavaScript, lisible par n'importe quel robot. C'est vingt fois ce que sert la page de GDIY pour un épisode deux fois plus long.
Un détail au passage, qui n'est pas anodin : ce bloc est présent quatre fois dans le même document. J'ai compté 936 éléments de liste au total, soit exactement quatre fois 234, et quatre conteneurs Transcript-module. La page rend la même transcription en quatre exemplaires, sans doute pour des variantes d'affichage. Cela explique les 64 080 mots de la ligne du tableau, et cela dilue mécaniquement le rapport signal sur bruit de la page.
Neuf flux, 4 904 épisodes, dix balises de transcription
Reste la question de l'échelle. La transcription d'Ausha est-elle l'exception ou la règle ? Le format RSS permet de le savoir sans deviner, parce que la déclaration passe par un tag normalisé.
J'ai téléchargé neuf flux de podcasts francophones réels, répartis sur Audiomeans, Ausha, Acast, Libsyn, Simplecast et Spotify for Creators, et compté.
Flux Episodes transcript ns podcast
-------------------------- -------- ---------- ----------
Génération Do It Yourself 1047 0 oui
Silence on joue ! 939 0 non
Le Podcast de Pauline Laig 857 0 oui
Vlan! 659 0 oui
Trends-Tendances 600 0 oui
Trench Tech 349 10 oui
Scrum Master Toolbox Podca 200 0 oui
MVP → LE Podcast SEO / GEO 153 0 oui
Sans Permission 100 0 oui
-------------------------- -------- ---------- ----------
Total 4904 10
Quatre mille neuf cent quatre épisodes. Dix balises <podcast:transcript>. Toutes dans un seul flux sur neuf.
La colonne de droite rend le résultat plus sévère encore. Huit flux sur neuf déclarent l'espace de noms xmlns:podcast="https://podcastindex.org/namespace/1.0" dans leur balise racine. Le vocabulaire est donc disponible dans presque tous les flux, prêt à l'emploi, ajouté par défaut par les hébergeurs. Il n'est utilisé nulle part, sauf une fois.
Et même dans ce cas unique, la couverture reste marginale : dix épisodes sur 349, soit moins de trois pour cent du flux. J'ai regardé lesquels. Huit des dix portent sur des chroniques de trois à cinq minutes. Deux seulement portent sur des entretiens longs, d'une heure quatre et d'une heure dix-sept. Ces deux fichiers-là contiennent respectivement 11 005 et 14 443 mots, donc la matière est bien réelle quand elle est produite. Elle l'est presque toujours pour les formats courts, presque jamais pour les formats longs, c'est-à-dire exactement là où le texte aurait le plus de valeur.
La spécification propose du HTML, tout le monde livre du VTT
La spécification du tag, dans le dépôt Podcast Index, est courte et sans ambiguïté. Le parent est <item>, les attributs url et type sont obligatoires, language et rel sont optionnels, et le tag peut être répété pour plusieurs formats. Les types cités sont text/plain, text/html, text/vtt, application/json et application/x-subrip.
Le premier exemple donné par la spécification est celui-ci :
<podcast:transcript url="https://example.com/episode1/transcript.html"
type="text/html" />
Autrement dit, la norme invite d'emblée à pointer vers une page HTML. Sur les dix balises que j'ai trouvées, dix sont en type="text/vtt". Zéro en text/html.
J'ai téléchargé les fichiers. Ils répondent bien en HTTP 200, servis par un CDN, avec un en-tête access-control-allow-origin: *. Sur ce point, rien à redire, ils sont publics. Mais leur type MIME annoncé est application/octet-stream, pas text/vtt. Un robot qui applique une règle simple, du genre « je n'analyse que ce qui est annoncé comme du texte », passe à côté sans même ouvrir le fichier.
Reste le format lui-même. Voici le début brut d'un de ces fichiers :
WEBVTT
1
00:00:00.684 --> 00:00:06.266
La très grande majorité des usages professionnels de l'IA
sont des initiatives d'employés.
2
00:00:06.786 --> 00:00:08.126
On utilise un outil qu'on ne comprend pas,
Une phrase par bloc numéroté, encadrée de codes temporels. Sur un fichier de 14 443 mots, cela fait plusieurs centaines de fragments. Aucun de ces fragments n'a d'existence autonome : le bloc 2 ne se comprend pas sans le bloc 1, et aucun ne porte de titre. C'est le défaut exact que sanctionne le découpage en passages décrit dans notre article sur le fan-out de requêtes, et l'inverse de ce que produit un texte structuré par des titres de section qui servent d'ancres.
La comparaison est directe : le même contenu existe en deux versions, un fichier VTT de plusieurs centaines de cues, et 234 paragraphes attribués rendus en HTML sur la page Ausha. Le premier est une piste de sous-titres. Le second est du texte. Seul le second ressemble à quelque chose qu'un moteur peut extraire et citer.
Le test : la phrase est en ligne, le moteur cite Microsoft
Restait à savoir ce qui se passe en pratique. J'ai pris une phrase verbatim de la transcription publiée sur podcast.ausha.co, celle de Yann Ferguson sur le travail et l'IA, et j'ai construit une question autour de ses termes exacts : le Shadow AI, le Bring Your Own AI, et l'idée que les usages professionnels de l'IA sont surtout des initiatives d'employés. Puis j'ai posé cette question à ChatGPT en France, en français, avec la recherche web forcée.
La réponse est longue, structurée, et elle reprend précisément les notions de l'épisode. Elle cite sept sources :
microsoft.com 3 citations
blogs.microsoft.com 1
news.microsoft.com 1
cmvrh.developpement-durable.gouv.fr 1
mckinsey.com 1
Aucun podcast. Ni la page Ausha, ni le site de Trench Tech, ni aucune fiche Apple ou Spotify. Le moteur est allé chercher une étude Microsoft de mai 2024, un rapport McKinsey de mars 2025 et une étude ministérielle de septembre 2025.
Ce test est un test unique, sur un moteur, un jour donné, avec une formulation donnée. Il ne prouve pas qu'un podcast ne peut jamais être cité, et je ne le présente pas comme tel. Mais il suffit à écarter une idée confortable : le fait qu'une transcription soit publique, complète, rendue en HTML et accessible aux robots ne suffit pas à en faire une source citée. Elle entre en concurrence avec des documents qui ont une adresse stable, un auteur institutionnel, un titre qui annonce le sujet et une structure de rapport. Une page d'épisode, même bien remplie, n'a rien de tout cela.
Et il faut ajouter la question de propriété. Si cette page avait été citée, le domaine cité aurait été podcast.ausha.co, pas celui de Trench Tech. C'est la même leçon que celle tirée de la place de Reddit et de Wikipédia dans les réponses génératives : héberger sa matière chez un tiers, c'est lui prêter la citation.
Google n'a plus de type podcast du tout
Un dernier point mérite d'être vérifié plutôt que supposé, parce qu'il circule beaucoup de conseils sur le balisage de podcast.
La page developers.google.com/search/docs/appearance/structured-data/podcast répond 404. Elle n'existe plus.
J'ai ensuite pris la galerie complète des données structurées prises en charge par Google, search-gallery, et compté le vocabulaire. La page fait 1 965 mots. Le mot « audio » y apparaît zéro fois. Le mot « transcript » zéro fois. Le mot « podcast » y apparaît trois fois, et j'ai imprimé le contexte de chacune : la première est dans le menu de navigation de Search Central, « Recent podcast episodes », la deuxième dans le même menu déplié, la troisième dans le pied de page, « Podcast, Listen to Search Off the Record ». Aucune des trois ne vient de la liste des types pris en charge.
Autrement dit, il n'existe aujourd'hui aucun type de données structurées podcast ou audio reconnu par Google pour un résultat enrichi. Cela ne rend pas le balisage PodcastEpisode nuisible, et GDIY a raison de le poser. Cela signifie simplement qu'il ne faut rien en attendre du côté de l'affichage, et surtout qu'il ne remplace pas le texte. Comme nous l'écrivions à propos de schema.org et du GEO, un balisage décrit un contenu, il ne le fournit pas.
Ce qu'il faut faire à la place
Le diagnostic est simple : dans le podcast, tout est ouvert et presque rien n'est écrit. Voici l'ordre dans lequel je traiterais le chantier.
Publier la transcription sur votre domaine, pas seulement chez l'hébergeur. C'est le geste qui change tout, et il est à votre portée immédiate puisque votre site n'a aucune restriction à lever. Une page par épisode, sur votre nom de domaine, avec le texte complet. La page Ausha prouve qu'un bloc de 14 914 mots rendu côté serveur passe sans difficulté. Si un hébergeur sait le faire, votre CMS aussi.
Transformer la piste de sous-titres en texte lisible. Ne publiez pas le VTT tel quel. Retirez les codes temporels, regroupez les cues en paragraphes, attribuez les prises de parole, corrigez les noms propres et les termes techniques que la reconnaissance vocale écorche systématiquement. Puis ajoutez ce qu'aucune transcription automatique ne produit : des titres de section qui annoncent le sujet traité. Un entretien de trois heures contient facilement quinze sujets distincts, et chacun mérite son ancre.
Renseigner <podcast:transcript> en pointant vers cette page. La spécification autorise plusieurs balises par épisode et son premier exemple est type="text/html". Vous pouvez donc déclarer à la fois votre fichier VTT pour les lecteurs et votre page HTML pour tout le reste. Le tag est gratuit, il est normalisé, votre flux déclare probablement déjà l'espace de noms, et vous seriez parmi les rares à l'utiliser pour ce qu'il permet.
Régler la question du doublon avant qu'elle se pose. Si votre transcription vit à la fois sur votre site et chez votre hébergeur, vous avez deux adresses pour un même texte. Choisissez laquelle doit compter, posez la balise canonique en conséquence, et faites pointer la fiche de l'hébergeur vers votre page. Le raisonnement complet est dans notre article sur le contenu dupliqué face aux moteurs IA. Et évitez de rendre le même bloc plusieurs fois dans une même page, comme le fait la fiche Ausha mesurée plus haut.
Vérifier ce que le robot reçoit, pas ce que l'écran affiche. La commande suivante compte les mots réellement lisibles sans JavaScript sur une adresse donnée. Passez-y votre page d'épisode avant de la considérer publiée.
curl -sL -A "Mozilla/5.0 (compatible; PerplexityBot/1.0; \
+https://perplexity.ai/perplexitybot)" \
"https://votresite.fr/podcast/episode-12/" \
| python3 -c "import sys,re; t=sys.stdin.read(); \
t=re.sub(r'(?is)<(script|style)[^>]*>.*?</\1>',' ',t); \
print(len(re.sub(r'(?s)<[^>]+>',' ',t).split()))"
L'agent utilisateur compte, et le cas Spotify le prouve : la même adresse rend 1 726 mots à un curl anonyme et neuf à un robot déclaré. Mesurez donc avec l'agent du robot que vous visez, pas avec celui de votre navigateur.
Si le résultat ressemble aux 704 mots de GDIY pour un épisode de trois heures, le problème n'est ni Google, ni les moteurs génératifs, ni le format audio.
Ne pas attendre la citation de la seule transcription. Le test ci-dessus montre qu'un texte accessible n'est pas automatiquement un texte cité. Une transcription est une matière première : elle vous donne le vocabulaire réel de vos invités, les questions posées telles qu'elles se posent, et des dizaines de passages exploitables. La citation viendra plus vraisemblablement d'une page qui reprend un de ces passages sous une forme documentaire, avec un titre qui annonce la réponse, que de la transcription brute elle-même.
Ce que cet article n'établit pas
Trois limites, et elles comptent.
L'échantillon est de neuf flux et 4 904 épisodes, choisis parmi des podcasts francophones connus et répartis sur six hébergeurs. C'est assez pour établir un ordre de grandeur, ce n'est pas un recensement. Un échantillon plus large ferait certainement remonter d'autres usages du tag, en particulier côté anglophone où l'adoption est plus ancienne. La conclusion qui tient est celle du rapport, pas celle du zéro absolu.
Les comptages de mots dépendent de l'agent utilisateur déclaré, comme le montre l'écart de 1 726 à neuf mots sur une même adresse Spotify. Les cinq lignes du tableau sont mesurées avec le même agent, celui de PerplexityBot, ce qui les rend comparables entre elles, mais un autre robot peut recevoir autre chose. Je n'ai pas mesuré ce que reçoivent les robots depuis leurs propres adresses IP, seulement ce que le serveur répond à un agent qui se déclare comme eux.
Le test de citation est un test unique. Une question, un moteur, une date. Il montre ce qui s'est produit, pas ce qui se produit toujours. Un protocole sérieux demanderait un jeu de questions figé, plusieurs moteurs et un groupe témoin, exactement ce que décrit notre article sur le test A/B en GEO.
Enfin, je n'ai pas mesuré l'effet de la publication d'une transcription. Rien ici ne compare le taux de citation d'une page d'épisode avec transcription à celui de la même page sans. Ce que j'établis, c'est l'écart entre ce qui est accessible et ce qui est écrit, pas le rendement du geste qui le comblerait. Pour instrumenter la suite, l'analyse des logs dit qui vient lire, et le suivi des citations dit qui vous reprend.
Ce qu'il faut retenir
Le podcast est le format le plus ouvert que j'aie mesuré jusqu'ici. Le flux RSS est un fichier XML public. Apple Podcasts ne bloque aucun robot IA et publie 300 fichiers de sitemap rien que pour ses épisodes. Ausha et Acast laissent tout passer. Spotify ne bloque que l'entraînement. Aucun site de podcasteur ne se ferme.
Et sur 4 904 épisodes, dix déclarent une transcription.
C'est un renversement complet par rapport à la vidéo, où le contenu textuel existe et où la plateforme en interdit le chemin. Ici, personne n'interdit rien. Le texte n'est simplement jamais produit, ou il reste dans l'application d'Apple, ou il finit dans un fichier de sous-titres servi en application/octet-stream que personne n'ira lire.
Un entretien de trois heures, c'est de l'ordre de vingt mille mots d'expertise, tenue par une personne nommée, sur un sujet précis. C'est le contenu le plus dense qu'une entreprise produit, et le plus systématiquement perdu. Le convertir en pages lisibles n'est pas un travail de référencement, c'est un travail d'édition, et c'est probablement le meilleur rapport effort sur matière disponible aujourd'hui.
C'est ce genre d'inventaire, entre ce que vous produisez et ce qui en reste de lisible, que nous ouvrons chaque audit GEO, et le vocabulaire de ces sujets est détaillé dans notre glossaire. La question de départ est toujours la même : combien d'heures de parole avez-vous enregistrées que personne ne peut citer ?