html语义化直接决定屏幕阅读器朗读准确性、键盘跳转合理性及浏览器文档大纲推导可靠性；套导致辅助技术“失明”，因无隐含aria role，无法识别导航、主内容等区域，而等标签自带role与内置行为，且标题层级必须严格嵌套以保障大纲生成。

HTML语义化不是“加几个 <article></article> 就完事”的装饰活，它直接决定屏幕阅读器能否正确朗读、键盘用户能否合理跳转、浏览器能否可靠推导文档大纲——这些事出问题，SEO 反而是次要的副作用。

为什么 <div> 套 <code><div> 会让辅助技术“失明” <p>当所有区块都用 <code><div>，屏幕阅读器只能识别为“无名容器”，无法告知用户“这是导航栏”“这是主内容区”“这是侧边推荐”。它不会主动猜测你写在 <code>class="header" 里的其实是页眉。

• <header></header>、<nav></nav>、<main></main>、<aside></aside>、<footer></footer> 这些标签自带隐含的 ARIA role（如 banner、navigation、main），浏览器和读屏软件直接信任并暴露给用户
• 手动加 role="navigation" 不等于替代 <nav></nav>：前者只是“声称”，后者是“声明+默认属性+内置行为”（比如部分浏览器对 <main></main> 自动赋予 tabindex="-1" 以便聚焦）
• 错误示范：<div class="card"><div class="card-title">标题</div></div> → 正确应为：<article><h2>标题</h2></article>，因为 <h2></h2> 提供层级语义，<article></article> 表明独立内容单元

<h1></h1> 到 <h6></h6> 的嵌套不是格式问题，是大纲生成逻辑

浏览器（以及 NVDA、VoiceOver）会依据标题标签自动生成文档大纲（Document Outline），这个大纲不看 CSS 字体大小，只看标签层级与嵌套关系。错用会导致键盘用户按 H 键跳过时漏掉章节，或语音导航直接“跳段”。

在SEO发布前，从路由清单生成XML网站地图和robots.txt

当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。

下载

• 必须遵循层级顺序：不能 <h1></h1> 后直接 <h3></h3>，中间缺 <h2></h2> 会导致大纲断裂
• <section></section> 或 <article></article> 内部可重置标题层级（即允许子 <h1></h1>），但实际中建议统一用 <h2></h2>~<h6></h6> 避免混淆
• Chrome DevTools > Elements > 右键节点 > “Show outline” 可实时查看当前页面大纲结构，比肉眼检查更可靠

哪些语义标签容易被误用或忽略

有些标签看似冷门，但在特定场景下不可替代；而另一些则常因“看起来像 div”被弃用。

• <time datetime="2024-05-20">5月20日</time>：提供机器可读的时间值，搜索引擎和日历工具能提取解析，纯文本“5月20日”无法被可靠识别
• <address></address>：仅用于最近的 <article></article> 或 的联系信息，不是所有地址都该用它；误用会干扰联系方式提取逻辑
• <figure></figure> + <figcaption></figcaption>：图片/图表与其说明文字的强绑定关系，比 <div> 包裹更利于无障碍导航（读屏会把图和说明当一个单元播报） <li> <code><details></details> / <summary></summary>：原生可展开组件，自带键盘交互（空格/回车切换）、焦点管理、状态提示（自动加 aria-expanded），比手写 div + JS 更轻量且健壮

真正难的不是记住所有标签名，而是判断“这个内容在信息架构里扮演什么角色”——是独立可引用的单元？是操作入口？是时间戳？是补充说明？一旦角色明确，语义标签就自然浮现。否则，再多的 SEO 工具也救不了一个结构混乱的 DOM 树。