AI 搜索时代，HTML 语义化还有用吗？

引子:一个开发者群里的争论

最近技术群里经常能看到类似的讨论:”现在都是 AI 直接总结网页内容给用户看了，谁还关心你用的是 <div> 还是 <article>？搜索引擎排名规则都快被 AI 摘要重构了，语义化 HTML 是不是可以放一放了？”

这个问题问得挺实在，也确实抓住了这几年 web 生态的一个大变化：越来越多用户不再是”打开搜索结果链接、自己阅读页面”，而是直接看 AI 搜索产品（比如各类 AI Overview、AI 问答助手、带浏览能力的对话式搜索）生成的一段总结。页面的”读者”，正在从人眼变成一层 AI 中间层。

那这是不是意味着语义化 HTML 的价值被稀释了？答案是：没有过时，但它的价值来源发生了转移。这篇文章想把这件事讲清楚。

先回顾一下：语义化 HTML 到底解决什么问题

在讨论”AI 时代还有没有用”之前，有必要先厘清语义化 HTML 原本承担的三类职责，因为这三类职责受 AI 搜索影响的程度完全不同。

第一，可访问性（Accessibility）。 屏幕阅读器、语音导航等辅助技术，依赖的是浏览器的可访问性树（accessibility tree），而这棵树很大程度上是从 HTML 的语义结构生成的。<nav> 让屏幕阅读器用户能一键跳到导航区，<button> 天然可以被识别为可交互控件并支持键盘操作，标题标签 h1~h6 的层级让视障用户能像”看目录”一样跳读页面。这一层价值和搜索引擎、AI 完全无关，它服务的是真实使用辅助技术的人。

第二，传统搜索引擎的抓取与理解。 早期搜索引擎爬虫本质上是基于规则和统计特征的程序，语义标签（以及后来的 schema.org 结构化数据、Open Graph 标签等）相当于开发者主动给爬虫”打标签”，帮它更准确地识别标题、正文、发布时间、面包屑导航等信息，从而影响收录和排名。

第三，开发体验与原生交互行为。 语义元素自带浏览器原生行为：<form> 的默认提交与校验、<button> 的键盘可达性、<label> 和表单控件的关联点击。这部分是纯粹的工程收益，跟”谁来读这个页面”没有任何关系。

理清这三类之后再看 AI 搜索的冲击，会发现它主要冲击的是第二类，而第一类和第三类几乎不受影响。

AI 搜索到底是怎么”读”网页的

关键问题来了：AI 搜索产品在生成摘要或回答之前，页面内容是怎么进入模型的？

答案并不神秘，大致分两步：抓取（fetch）和内容抽取（extraction）。抓取环节和传统爬虫没有本质区别，仍然是访问 URL、拿到 HTML 文本。真正体现差异的是抽取环节——如何从一整份夹杂着导航栏、广告位、相关推荐、页脚版权信息的 HTML 里，把”正文”干净地摘出来。

这一步大量依赖的正是基于 DOM 结构和语义特征的正文提取算法（业界比较知名的思路可以类比 Mozilla 的 Readability 算法），它会去识别 <article>、<main>、标题层级、段落密度等信号，从中判断哪一块是”人类真正想读的内容”。语义标签越清晰，这一步抽取的准确率越高、噪声越少。

再往后，被抽取出的正文才会作为上下文喂给大语言模型去做总结、问答或引用。这里有一个经常被忽视的细节：大语言模型的上下文是有成本和长度限制的。

如果抽取环节没能干净地剥离导航、广告、无关模块，模型拿到的就是一锅夹杂噪声的文本，这会直接影响它总结的准确度，甚至可能把导航栏文字或推荐位标题误当成正文内容去总结。

也就是说，语义化不清晰造成的伤害，在 AI 时代不是消失了，而是从”排名下降”变成了”被错误理解、被错误引用甚至完全抽取失败”。

语义化的价值发生了转移，而不是消失

把上面的分析归纳一下，可以得到一个更准确的结论：语义化 HTML 的意义正在从”讨好关键词爬虫”转向”降低机器理解内容的噪声成本”，而这个”机器”现在既包括传统搜索引擎，也包括各类 AI 抓取和总结系统。

举一个具体对比。假设有一段”文章列表”，不良写法可能是这样：

<div class="list">
  <div class="item" onclick="go(1)">
    <div class="t">如何优化首屏加载</div>
    <div class="d">2024-01-10</div>
  </div>
  <div class="item" onclick="go(2)">
    <div class="t">CSS Grid 实战</div>
    <div class="d">2024-01-08</div>
  </div>
</div>

而语义化的写法是：

<ul class="list">
  <li>
    <article>
      <h3><a href="/posts/1">如何优化首屏加载</a></h3>
      <time datetime="2024-01-10">2024年1月10日</time>
    </article>
  </li>
  <li>
    <article>
      <h3><a href="/posts/2">CSS Grid 实战</a></h3>
      <time datetime="2024-01-08">2024年1月8日</time>
    </article>
  </li>
</ul>

对人眼来说，这两种写法渲染出来可能一模一样。但对一个负责”抽取正文结构”的程序（无论它背后是传统搜索引擎还是 AI 摘要系统）来说，第二种写法把”这是一个列表””每一项是一篇独立文章””标题是什么””发布时间是什么”这些语义信息全部显式表达了出来，而第一种写法把这些信息全部藏在了没有语义的 div 和 onclick 里，只能靠猜。

AI 模型确实比十年前的爬虫更”聪明”、容错率更高，即使面对第一种写法也大概率能猜对，但”大概率能猜对”和”结构清晰、成本更低、几乎不会出错”之间，仍然是有价值差的，尤其是在页面结构复杂、内容层级多的真实场景里。

哪些语义化实践依然值得坚持

结合上面的分析，可以给出一些相对具体的判断，而不是笼统地说”语义化很重要”：

正文容器一定要用 <main> / <article>，标题层级要保持逻辑连贯，这直接决定了内容抽取算法能否准确框定”正文范围”，价值没有随 AI 搜索而下降，反而因为内容抽取更依赖结构信号而变得更重要。
表单、按钮、交互控件继续使用原生语义元素（<button>、<label>、<form> 而不是靠 <div> 模拟），这类收益本身就与搜索或 AI 无关，是纯粹的可访问性和工程收益，不该因为”AI 时代”的说法被动摇。
结构化数据（如 JSON-LD/schema.org）和语义 HTML 是互补关系，不是替代关系。 结构化数据提供的是机器可直接解析的元信息（比如明确标注”这是一篇文章，作者是谁，发布时间是什么”），语义 HTML 提供的是内容组织的骨架，两者一起使用，能让不同层次的机器读者（爬虫、Readability 类抽取算法、大模型）都拿到更干净、更少歧义的信息。
不必再执着于”关键词密度””标签堆砌”式的传统 SEO 技巧，这部分确实随着搜索排名机制向 AI 摘要和语义理解迁移而边际效益降低，用清晰、真实、结构良好的内容去写页面，比刻意堆砌关键词更有性价比。