应仅在主要导航区块使用<nav>标签，即站点内核心跳转路径；可有多个但需明确作用域并标注aria-label，避免与<footer><aside>混用或嵌套。
<nav> 标签不是只能放“传统导航栏”，但也不是随便什么链接集合都能套用。
什么时候该用 <nav>？看是否属于“主要导航区块”
HTML5 规范明确说：<nav> 应用于页面中**主要的导航链接部分**，即用户用来在站点内跳转的核心路径集合。它不强制要求是顶部横条或侧边菜单，但必须满足“导航功能主导”这一语义本质。
- ✅ 适合：页眉里的主导航、底部的站点地图链接、文章页的“上一篇/下一篇”（若为固定导航模式）
- ❌ 不适合：评论区的作者主页链接、文章内带
<a>的普通关键词、搜索结果页的“相关推荐”列表（除非该列表是站点级固定导航入口） - ⚠️ 边界情况：分页控件（
<nav aria-label="pagination">）可加<nav>，但需配合aria-label明确用途，否则屏幕阅读器可能误判为全局导航
<nav> 和 <aside>、<footer> 混用常见误区
很多人把页脚里一堆链接直接包进 <nav>，其实页脚链接更倾向归入 <footer> 本身 —— 它天然具备“站点元信息+辅助导航”的语义包容性。只有当页脚存在**独立、结构化、高频使用的导航子集**（如“法律条款｜隐私政策｜联系我们”三连入口），才考虑额外套一层 <nav>。
-
<aside>里的链接（如“相关文章”侧边栏）一般不用<nav>，除非该侧栏是跨栏目通用的导航枢纽（例如后台管理系统的模块快捷入口） - 一个页面可以有多个
<nav>，但建议不超过 3 个，且每个都应有明确作用域（用aria-label或id区分） - 嵌套使用极少必要：
<nav>内再套<nav>容易让辅助技术困惑，优先用<ul>+ 子菜单逻辑处理层级
SEO 和无障碍的实际影响比你想象的小
搜索引擎不会因为用了 <nav> 就给权重加成，也不会因没用就降权。它的价值集中在两点：一是帮助屏幕阅读器用户快速定位导航区域（通过 role="navigation" 自动映射），二是为 CSS/JS 提供更精准的语义钩子（比如 nav a:not([href^='/admin']) 这类选择器）。
立即学习“前端免费学习笔记（深入）”；
- 不加
<nav>不影响 SEO 排名，但缺失aria-label可能让语音导航用户无法区分多个导航区 - 某些旧版 JAWS 版本对无
aria-label的<nav>会朗读为“导航”，而非内容意图，所以务必标注 - CSS 中
nav选择器优先级和div一样，别指望它自带样式，也别为它写过度特化的样式规则
<nav aria-label="主站导航">
<ul>
<li><a href="/">首页</a></li>
<li><a href="/products">产品</a></li>
<li><a href="/contact">联系</a></li>
</ul>
</nav>
<nav aria-label="文章内导航">
<a href="/post/123">上一篇</a>
<a href="/post/125">下一篇</a>
</nav>
真正容易被忽略的是：语义标签的价值不在“用了没”，而在“用得是否一致”。同一个项目里，如果首页用 <nav> 包页脚链接，而内页又不用，反而会破坏辅助技术的预期逻辑。
