（对于React项目，使用命令：grep -rn "；Vue项目中则使用.vue文件进行搜索。）

`标签并不符合语义规范，而赋予其ARIA角色则是一种额外的考虑，目的是为了满足那些已经习惯通过标题进行导航的屏幕阅读器用户的需求。

以下是我对`BlogCard.svelte`文件所做的实际修改内容，除了代码格式上的调整外，其他部分都没有变化：

-

  {post.title}

+

  text-[var(--color-text-primary)]
  group-hover:text-[var(--color-primary)]
  transition-colors line-clamp-2">
  {post.title}

哪些内容发生了变化，哪些没有变化呢？

• 辅助技术会识别出相同的结构。`role="heading"`加上`aria-level="3"`，正好符合ARIA标准中`

  `标签的作用。那些依靠标题进行导航的屏幕阅读器仍然会在这里停下来，并正确地读取这个标题的级别。

• 视觉样式没有发生任何变化。所有的CSS类依然保留在了原来的元素上，没有任何位置的代码被移动或调整。

• 内容本身也没有任何改变。这个修改并没有删除任何文字；因为大多数关于数据提取的建议都会建议用户重新编写代码，但这种类型的错误其实根本不需要重新编写代码就能解决。

• HTML标签解析器也不会再把这类元素计算在内了。数据提取工具会按照`

  `、`

  `、`

  `等标签类型来划分内容。这样一来，那些被标记为“卡片标题”的元素就不再会被计入统计范围了，你原本设置的标题级别也会重新恢复正常，从而保证各种比例计算的正确性。

在你们列出的需要修改的页面上，都应用这一条相同的修改即可。在我的例子中，只需要一次代码提交，就能影响到五个组件中的六个地方。

之后重新部署网站，并再次进行第2步的检查。在我的主页上，数据提取的可读性分数从65分提高到了100分；其中，以问题形式呈现的标题的可读性比例也从26.7%上升到了超过50%。这是因为我在页面中设置的四个问题标题，成为了该页面上唯一的H2/H3级别的标题。

验证结果：在检查后的截图旁边，会显示终端输出的结果。现在，标题统计列表中应该只包含那些你故意添加的标题了。

第6步：在持续集成系统中应用这些修改

关于数据提取分数，有一个不容忽视的事实：这些分数会发生变化。内容被修改了，新的组件被添加了，或者页面进行了重新设计，都会导致这些分数发生变化。

在我编写这篇教程的时候（7月21日），我的主页再次接受了检查，目前的得分是80分——仍然属于“可提取”的范围，但已经低于修改后的100分了。这是因为在这段时间里，我的主页进行了重新设计，页面的结构再次发生了变化。不过，博客索引和主题中心部分的得分依然保持在100分。

正是这种渐进式的变化，导致本教程所提供的解决方案并不能彻底解决问题。实际上，真正关键的是“回归检测机制”。如果没有这个机制，下一个被开发出来的组件可能会引入新的 `

` 标签，从而导致整体得分逐渐下降。由于没有任何明显的错误出现，因此这些变更也不会在审查过程中被发现。

在我的系统中，这个检测流程是通过 GitHub Actions 工作流来执行的。每当一次生产环境的部署成功完成时，这个流程就会自动运行；如果有任何被审计的 URL 的可提取性指标低于预设阈值，那么整个流程就会立即失败：

name: 部署后的可提取性审计 on: deployment_status: jobs: audit: if: | github.event.deployment_status.state == 'success' && github.event.deployment.environment == 'Production' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.13" - run: pip install requests beautifulsoup4 - name: 在实际网站地址上检测可提取性 run: | for url in "https://yoursite.com/" "https://yoursite.com/blog"; do python3 scripts/extract_audit.py "$url" --min-score 75 || exit 1 done

为了让这个检测脚本能够适应持续集成流程，只需在步骤 2 的脚本中添加一个 `--min-score` 参数即可。这样，当检测结果低于阈值时，脚本就会立即退出并返回错误代码。这种修改只需要对代码进行五行左右的修改而已。

在我的系统中，生产环境版本的检测流程会同时检查五个 URL，并将这些URL的可提取性指标与 Lighthouse 的可访问性标准进行对比。这样，步骤 5 中规定的 ARIA 规范就能得到有效执行：可提取性指标不能低于 75，可访问性指标也不能低于 95。这种双重约束机制能够确保各项指标始终处于合格范围内。

测试示例：在 GitHub Actions 的设置中，如果将 `--min-score` 参数设置为 101，那么检测流程就会失败；而当阈值设为 75 时，检测流程则会正常通过。

实际发生了哪些变化

这是我三个页面的可提取性得分对比表，所有数据都来自同一检测工具：

页面	修复前得分	修复后得分	7月21日实时审计得分
首页	65分（部分内容可提取)	100分（全部内容可提取)	80分（部分内容可提取)
博客索引页	低于最低阈值	100分（全部内容可提取)	100分（全部内容可提取)
主题中心页面	低于最低阈值	100分（全部内容可提取)	100分（全部内容可提取)

审计所起的作用，就在于为后续的指标分析提供依据：Bing Webmaster Tools中的AI性能报告是目前唯一一个由第一方提供的、专门用于监测AI引用的仪表盘。你可以在“BWT”设置中的“搜索性能”板块找到这个报告。根据该报告，在截至7月19日的90天内，我的网站通过Microsoft Copilot及其合作伙伴提供的辅助工具，在33个页面上获得了1,600次AI引用。而在4月底，也就是开始进行这些优化工作的时候，这一数字还为671次；到了6月底，这一数字已经增加到了约1,500次。

需要说明的是，这里存在因果关系判断上的复杂性——因为通常人们会高估AI技术对内容可见性的提升作用：引用的增加确实与相关优化工作有关，但并不能完全将其归因于这些优化措施。在同样的时间段内，我还发布了新的内容、解决了数据检索方面存在的问题，并且常规搜索流量也有所增加。

我可以肯定的是，审计结果所反映的效应确实是具有因果关系的——因为使用的是相同的评估工具，在进行优化前后所获得的结果确实存在差异；这种优化的机制也是引擎的官方行为规范（即通过标题来进行内容分割）；而且，在问题得到解决之后，引用的次数仍然在持续增加。不过，我无法为你提供一个能够专门针对六种不同的标题标签进行控制的实验来验证这一因果关系……其实，根本没有人能够做到这一点。

我拒绝了哪些优化措施，以及原因

像这样的教程往往容易受到选择偏差的影响，因此以下是我考虑过但最终没有采纳的一些优化方案：

• 重新编写页面内容：这本来是标准的优化建议。但我拒绝了这个方案，因为统计分析结果显示存在的问题在于页面的结构设计，而非文字表达本身。我自己编写的内容已经通过了评估标准，重新编写内容只会浪费时间，还会影响评估结果的准确性。

• 直接删除/

  标签对，同时不使用ARIA属性：这样做会减少每个元素所包含的属性数量。但我拒绝了这个方案，因为这会破坏屏幕阅读器用户能够使用的导航结构。虽然审计工具可能检测不出这种变化，但用户肯定会察觉到。

• 在每一页上都添加FAQ相关的元数据：虽然这样做可以提升评分，但JSON-LD格式的元数据成本相对较低。但我还是首先放弃了这个方案，因为这种做法只是治标不治本——它只是用元数据来改善页面的表现形式，而页面的实际结构问题并没有得到解决。

• 对站点地图中的每一页都进行审计：追求完整性确实很容易让人产生冲动。但我拒绝了这个方案，因为很多优化措施实际上会提升数据的检索效率，而对于那些检索效率本来就不高的页面来说，这种优化效果并不明显。因此，只需对三个索引页面进行优化，就能达到预期的效果。

• 将得分目标定在100分：在我观察到自己的首页得分从100分降到了80分之后——尽管这次设计变更与搜索引擎排名并无直接关系——我最终将持续集成测试的合格标准设定在了75分，而不是100分。如果把完美作为唯一的目标，那么每一次内容优化尝试都可能会以失败告终，而且还会让团队忽略真正重要的评估标准。

常见问题解答

降低标题的层级会影响我的常规SEO表现吗？

对于搜索来说，真正重要的标题是那些能够描述文档自身结构的标题，这些标题应该保持原样不变。你需要删除的，只是那些将“其他文档”的标题标示为文档大纲的标记内容。 在问题得到解决后的几个月里，我的自然搜索展示次数确实有所增加。谷歌的任何指导方针中，都没有要求卡片标题必须使用标题元素来表示。

这个只是关于游戏的一个审计脚本吗？

这五种检查方法实际上反映了检索增强系统是如何处理页面内容的：它们会按照标题将页面内容分块处理，提取相关内容，并选取匹配内容的开头句子。如果使用了错误的标题结构，无论使用哪种评估工具，都会影响整个处理流程。你所做的并不是在为某个特定的审计工具进行优化，而是在修改所有解析器都能看到的DOM结构。评分结果只是一个参考指标，正因为如此，第6步才会根据这个评分来决定是否通过审核，而不是依据具体的数字。

我使用的是React或Vue，而不是Svelte。这会有什么影响吗？

没有任何结构上的变化。这个错误在JSX和SFC模板中表现是一样的（在Card.tsx文件中，都是使用

{title}

这种格式），第4步中的grep工具能够检测到这个问题，而role="heading"与aria-level的组合在所有框架中都是有效的，因为它们本质上就是普通的HTML代码。

那么我文章中的标题该怎么办呢？

把它们保留为真正的

/

元素吧。文章正文中的标题本身就是文档结构的重要组成部分，它们理应被包含在统计分析中。只有那些用于显示“其他”页面标题的组件，比如卡片、预告内容、相关文章插件以及导航面板，才需要调整其标题设置。

我应该多久重新进行一次审计呢？

应该持续地进行审计，第6步正是为了实现这一点：持续集成系统会在每次生产环境部署时自动重新进行审计，这样你就再也不用手动进行审计了。 如果你跳过了这个自动审核流程，那么就需要每月运行一次第2步中的脚本，并且在布局组件、导航结构或模板有任何更改时也要及时重新执行审计。页面内容本身的修改很少会导致评分有显著变化，真正能改变评分结果的是组件和模板的改动，而这些改动往往不会被人们想到需要重新进行评估。我自己的首页评分从100降到了80，就是因为进行了设计上的调整，而不是因为添加了新的内容。

我的评分很低，而且我没有使用任何卡片组件。现在该怎么办呢？

如果出现这种情况，问题通常出在代码的编写方式上，而不是结构本身：可能是声明性的标题被改成了用户可能会输入的问题形式，也可能是开头句子的字数超出了40到60字的范围，又或者是缺少了FAQ板块。第2步中的统计分析会告诉你具体是哪个方面出了问题，相应的修复工作也需要通过修改代码来完成，而不是调整组件结构。

你所取得的成果

你成功地测量到了很多网站所有者都从未注意过的信息：你的组件实际生成的标题结构，以及由此计算出的可提取性评分。<您找出了导致分数较低的具体原因，采用了一种既能满足提取解析工具的要求，也能让屏幕阅读器正常工作的优化方案，并设置了相应的监控机制，以确保分数不会再出现下降的情况。

<从本系列的前两篇指南中，我们可以了解到更广泛的背景信息：如何衡量你的AI在各种引擎中的被引用率可以帮助你了解自己的内容是否真的被他人所引用；而使用WebMCP为交互式应用开发用户界面则能帮助你的网站更好地适应那些需要与系统进行互动而非仅仅阅读内容的用户。

<本教程正好填补了这一环节中的空白——它帮助你让已经存在的内容具备被有效利用的条件。信息检索机制决定了各种引擎是否会注意到你的内容；归属判定机制决定了它们是否会提及你的名称；而你刚刚审核过的提取过程，则决定了这些内容是否足够规范、适合被他人引用。

<这周，请对你网站中排名前三的页面进行一次检查。如果你的各个组件确实起到了应有的作用，那么你现在就应该知道如何让这些组件的效果得到更好的发挥了。