适用读者：在线教育平台后端与前端工程师、课程站 SEO 负责人

九月初，一个做职业考证课程的站长给我发来一张截图：DeepSeek 回答"XX 证书考试培训哪家讲得细"时，引用了他们课程详情页的正文，却完全没提页面上那个两分钟试听视频——而那正是全页最有说服力的内容，讲师出镜、真题带讲。顺着这条线往下查，发现试听视频上线两周，AI 爬虫和搜索引擎的视频收录里都没有它的踪影。原因不复杂：视频是后期加进页面的，前端只嵌了一个播放器组件，页面里没有任何一段机器可读的视频元数据。

这篇复盘把排查、修复到验证的完整过程写出来，核心是 VideoObject 结构化数据与视频站点地图两件套的落地细节。给所有正在往课程页里塞视频、又没管过"AI 能不能看见视频"的团队提个醒。

排查路径：两周前埋的雷是怎么找到的

排查从三个证据源交叉入手，每一步都验证一个假设：

第一步，看页面源码。试听视频区域在 DOM 里只有一个 <div id="player">，视频地址、封面、时长全靠播放器 JS 运行时注入——和之前案例里"正文在客户端渲染"是同一类病的不同部位：这次正文是服务端出的，视频元数据不是。

第二步，看收录情况。Google Search Console 的视频报告里这个页面显示"未检测到视频"， Bing 站长平台的媒体抓取日志里也没有视频文件的请求记录。两边的证据指向同一个结论：视频在机器视角不存在。

第三步，反向验证一个假设——是不是视频文件本身不可访问？直接 curl 视频地址，200，且响应头带 Content-Type: video/mp4。文件没问题，问题在"没人告诉爬虫这里有个视频"。

结论：视频内容的可发现性（Discoverability）为零，修复方向是补机器可读的视频元数据声明。

原理剖析：视频被引用前要过的三道闸

视频和图文内容走的是不同的消费管线，多出三道专门针对视频的关卡：

flowchart LR
    A[爬虫到达课程页] --> B{页内有无视频声明?}
    B -- VideoObject / 视频站点地图 --> C[提取视频元数据<br/>缩略图/时长/标题]
    B -- 仅播放器组件 --> Z[管线终止<br/>视频不存在]
    C --> D{缩略图与视频文件<br/>可访问?}
    D -- 是 --> E[视频收录入索引]
    D -- 否/慢 --> F[收录失败或延迟]
    E --> G[用户提问命中视频内容]
    G --> H[回答中引用视频<br/>带缩略图或时间戳]

第一道闸是声明。爬虫不会运行播放器去"发现"视频，它依赖两种声明方式：页面内的 VideoObject 结构化数据（schema.org 的视频类型），或者视频站点地图（Video Sitemap，Google 定义的 sitemap 扩展，专用于提交视频条目）。两件套理论上二选一即可，实践中我们都上——不同引擎的解析器对两种通道的支持成熟度不一样，双通道冗余成本极低。

第二道闸是资源可达性。声明里的缩略图（thumbnailUrl）和内容地址（contentUrl）会被单独抓取验证：缩略图必须可公网访问且分辨率达标（Google 要求 1200x675 以上，16:9），视频文件所在域名不能被 robots 意外屏蔽。见过不止一个站把视频放在鉴权 CDN 后面，声明写得再标准也过不了这道闸。

第三道闸才是内容本身。引擎在视频索引里做的是"页面 + 视频"联合召回，VideoObject 里的 name 和 description 会进向量库，试听视频讲的知识点能不能被召回，取决于这段描述写的是不是内容本身而非营销话术。

把双通道的分工画成一张架构图，两条路各自独立、互为备份：

flowchart TD
    subgraph 通道A[页面内声明]
        A1[课程页服务端渲染] --> A2[VideoObject JSON-LD<br/>写入 head]
    end
    subgraph 通道B[站点地图声明]
        B1[课程媒体表定时扫描] --> B2[video sitemap 分片生成<br/>按课程切文件]
    end
    A2 --> C[解析器提取视频元数据]
    B2 --> C
    C --> D[缩略图与视频文件可达性校验]
    D --> E[视频索引入库<br/>标题/描述向量化]
    E --> F[页面 + 视频联合召回]

修复落地：VideoObject 与视频站点地图双通道

通道一：页面内 VideoObject JSON-LD

课程详情页是服务端渲染的，视频元数据从课程的媒体表读出来，随页面一起输出：

// 环境：.NET 8 / ASP.NET Core Razor Pages
// 依赖：System.Text.Json（内置）
public string BuildVideoObjectJsonLd(Course course, Lesson trial)
{
    var ld = new
    {
        _context = "https://schema.org",
        _type = "VideoObject",
        name = trial.VideoTitle,              // 讲内容：如"第三章 真题精讲：合同效力"
        // 描述写视频实际讲的知识点，不写"精彩试听"这类营销词
        description = trial.VideoDigest,      // 由讲师确认的两三句内容摘要
        thumbnailUrl = new[] { trial.CoverUrl }, // 1200x675 起，16:9
        uploadDate = trial.PublishedAt.ToString("yyyy-MM-ddTHH:mm:sszzz"),
        contentUrl = trial.VideoUrl,          // 视频文件直链，须公网可访问
        embedUrl = trial.EmbedUrl,            // 播放器页地址，两种给一种也行
        duration = FormatIso8601(trial.DurationSeconds), // ISO 8601：PT2M15S
        isFamilyFriendly = true,
        // 试听片段标记：告诉引擎这是课程的一部分而非完整课
        partOfSeries = new { _type = "Course", name = course.Title }
    };
    return JsonSerializer.Serialize(ld, JsonLdOptions);
}

// 秒数转 ISO 8601 时长格式，duration 字段必须是 PT#H#M#S 形式
private static string FormatIso8601(int seconds)
{
    var h = seconds / 3600;
    var m = seconds % 3600 / 60;
    var s = seconds % 60;
    return $"PT{(h > 0 ? h + "H" : "")}{m}M{s}S"; // 135 秒 → PT2M15S
}

duration 的 ISO 8601 格式是最常翻车的字段，手写成"2:15"或"135"都会被解析器丢弃，工具函数统一转格式最稳。另外 name 和 description 我们强制走讲师确认流程——这是要进引擎索引的元数据，写歪了比不写还伤。

通道二：视频站点地图

视频站点地图在普通 sitemap 的 url 节点里加 video 扩展，我们按课程分片生成：

<!-- 视频站点地图分片：video-sitemap-course-123.xml -->
<!-- 声明命名空间后，url 节点内嵌 video:video 扩展 -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
  <url>
    <loc>https://www.example.com/courses/legal-exam</loc>
    <video:video>
      <video:thumbnail_loc>https://cdn.example.com/covers/legal-01.jpg</video:thumbnail_loc>
      <video:title>第三章 真题精讲：合同效力</video:title>
      <video:description>以三道历年真题演示合同效力要件的判断路径，覆盖无效与可撤销情形</video:description>
      <video:content_loc>https://cdn.example.com/v/trial-legal-01.mp4</video:content_loc>
      <video:duration>135</video:duration>   <!-- 注意：此处用秒数，非 ISO 8601 -->
      <video:publication_date>2026-08-20T10:00:00+08:00</video:publication_date>
      <video:family_friendly>yes</video:family_friendly>
    </video:video>
  </url>
</urlset>

一个易混点专门标出来：VideoObject 的 duration 用 ISO 8601 格式，视频站点地图的 video:duration 用纯秒数，两套规范恰好在这一个字段上不一致，复制粘贴时最容易错。

前端补一刀：语义容器

元数据是给爬虫的，页面语义也别落下。播放器外层包 <figure>，配 <figcaption> 写视频标题，紧跟着放一段文字版要点（带时间戳锚点）。文字版要点后来被证明是引用的主力，这是当初没料到的。

文字版要点的生产方式说一下，这块后来被做成了固定流程：讲师录完试听视频，按脚本模板把每个知识点的时间和一句话总结填进后台，前端按时间顺序渲染成"要点时间轴"，每条要点锚点直接挂在播放器上，点击跳转。别小看这个模板约束——要点写法统一之后，引擎转述时抓到的信息密度明显比早期随手写的版本高，第 14 天那两次引用转述的句子几乎就是要点原文的压缩版。

验证与两周数据

修复只有一个课程页出了问题，但我们把全站 12 个课程的试听视频一次性过了遍体检，又抓出 5 个同病页（视频后补、元数据没跟上）。修复脚本按课程媒体表批量生成 VideoObject 和视频站点地图条目，一条命令全站补齐。经验写进了发布清单：任何页面新增富媒体，元数据声明必须和内容同一次发布上线，靠事后想起来补的，必有漏网。

修复上线后的验证节奏和数据：

第 14 天的两次引用都来自"文字版要点"段落：一次回答里引擎转述了时间戳 01:40 起的考点总结，并在来源列表里给了课程页链接。视频本体没有被"播放"式引用，但它的内容借着文字版进了回答——视频引用目前的实际形态是"视频内容被转述，页面被署名"，这对课程站的转化已经够用：用户带着"AI 说这家讲真题讲得细"的印象点进来，试听视频负责临门一脚。

还有个附带收益：Search Console 视频面板恢复后，视频在传统搜索的视频垂直结果里也重新出现，带来约 15% 的试听播放增量。机器可读性这件事的收益从来不止 AI 一端。

补一个资源侧的提醒，这次排查里差点被它带偏：视频文件当时的 CDN 域名刚迁过一次，迁移动作把老域名的 301 只配了三个月有效期。如果元数据修复晚于 301 失效，contentUrl 指向的地址会变成 404，前功尽弃。富媒体改造上线前，把视频文件、缩略图、播放器页三类 URL 各 curl 一遍确认状态码，这个清单动作只花两分钟，能挡住一类很难从日志里反推的事故。

误区澄清与趋势判断

误区一："视频上了播放器就等于可被引用。"播放器是给人用的，声明才是给机器的，两套通道缺一不可。

误区二："VideoObject 描述随便写写就行。"name 和 description 是视频进索引的身份证，营销词堆砌等于主动放弃召回，描述要写内容本身。

趋势判断：多模态召回正在快速进化，视频内容的"被听懂"（语音转写后进索引）已经在部分引擎落地。到那个阶段，试听视频里讲师的口播要点会直接成为引用素材，视频从"配图"升级成"正文"。建议课程团队现在就把试听视频的转写字幕做起来，管线早晚要用。

从排查到修复，这个案例的通用性很强：任何"后期加进页面的富媒体"都可能是下一个盲区。你们的课程页视频被 AI 引用了吗？评论区交流下各家引擎的表现差异。

关键词：VideoObject、视频站点地图（Video Sitemap）、课程 SEO、GEO、AI优化AIO、多模态检索、ISO 8601、生成式引擎优化（Generative Engine Optimization）、JSON-LD

参考与延伸

• schema.org VideoObject 类型定义
• Google Search Central：视频站点地图与视频 SEO 最佳实践
• Google Search Central：Video 结构化数据
• Microsoft Learn：ASP.NET Core Razor Pages