被找到、被引用

单靠一个音频或视频文件，搜索引擎或答案引擎几乎得不到任何可引用的证据。索引把每个单集变成服务端渲染的文档、结构化的知识图谱，以及能把一个论断精确定位到说出它那一刻的机器可读接口。

这对两种来源同样适用。YouTube 频道的视频在 YouTube 内部靠标题和缩略图竞争，但对话本身在变成结构化文本之前，对 Google 和答案引擎都是不可见的——下面这些界面正是让 YouTube 单集在 YouTube 之外也可被引用的东西，与它们对 RSS 订阅源的作用完全一样。

PodHood 创建的是符合条件的界面；没有任何产品能保证 Google、ChatGPT、Perplexity 或其它引擎一定会抓取、排名或引用某个特定单集。随着目录被索引、外部系统反复回访，覆盖面会逐步扩大。

已索引单集会发布什么

面向搜索引擎

• 一个规范的 HTML 单集页，包含摘要、问答、章节、关键时刻、发言人、实体和完整文字稿。
• 以 PodcastEpisode 为中心的 Schema.org JSON-LD，包含发言人/实体，以及章节和关键时刻对应的带时间戳 Clip 节点。
• 简报包含问答时，生成 FAQ 形式的结构化数据。
• 话题/人物/公司/产品主题页（Hub），聚合频道已发布的、关于某个主题的证据。
• 频道级 sitemap.xml 和可抓取的内部链接。

面向答案引擎与智能体

• 每个单集都有一个 Markdown 孪生版本：在 URL 末尾加 .md，或请求 Accept: text/markdown。
• 频道级 llms.txt，包含已发布目录和 MCP 端点。
• 匿名、只读的 MCP search 工具，返回有依据、带时间戳的原文引用。
• 需要凭证的创作者 REST API（附 OpenAPI 描述），供频道自己的工具使用。
• MCP 发现位于 /.well-known/mcp，API 发现位于 /.well-known/api-catalog。
• PodHood 平台源站上的可发现 Agent Skill 索引，位于 /.well-known/agent-skills/index.json。

面向精确引用

章节、关键时刻、文字稿匹配、MCP 结果和 REST 搜索结果都携带指向精确时间戳的 URL。这样引用能落在支撑它的那一刻，而不是把读者丢在一段两小时录音的开头。

知识图谱为什么重要

文字稿让文字可被抓取。简报和知识图谱则让内容可导航、可复用：

• 发言人身份告诉系统是谁提出了某个论断。
• 实体和话题把一个单集与整个存档连接起来。
• 主题页为每个主题提供稳定的页面。
• 问答以人们平常向助手提问的方式表述内容。
• 带时间戳的关键时刻提供自成一体、可引用的论断。

这就是团队在 Studio 中所做的修正对可发现性至关重要的原因。在推广某个主题页或测试引用之前，先修正高价值的发言人和实体错误。

上线前验证

选一个有代表性的单集，按以下顺序执行：

1. 公开 HTML：以未登录状态打开单集页，检查标题、摘要、章节、发言人、文字稿、问答和规范主机名。
2. 时间戳：复制一个关键时刻或文字稿链接，确认播放/阅读器焦点从预期的时刻开始。
3. Markdown：加上 .md，确认重要文本和时刻 URL 都在，而不依赖可视化界面。
4. 频道索引：打开 /llms.txt，确认该单集和 MCP 端点都出现在其中。
5. MCP：使用连接 AI，提一个真实的问题，并打开返回的某条引用。
6. 结构化数据：把单集 URL 放进 Google 的富媒体搜索结果测试，检查检测到的 PodcastEpisode/Clip 数据。
7. 站点地图：确认该单集或它的主题页出现在规范主机名的站点地图下。

再用一个有多位发言人的单集和一个包含高价值常见话题的单集各重复一遍。

上线之后

• 把规范的节目库主机名添加到 Google Search Console 并提交它的站点地图。
• 索引一组连贯的主题集群，而不只是零散的单集；证据积累得越多，主题页就越有用。
• 针对团队真正希望节目回答的问题，检查 MCP/搜索结果。
• 在 Studio 中修正归属错误的发言人和重复的实体。
• 对早于问答等较新简报字段的高价值旧单集重新索引。
• 把 Studio 的订阅者名单作为真人受众增长的另一个独立信号来关注。

新页面可能需要一段时间才会被抓取。发布后立刻失败的引用测试并不能证明页面有问题；请先直接验证 HTML、Markdown、llms.txt、站点地图和 MCP 这几条路径。