结论是：用<header>、<nav>、<main>、<article>、<aside>、<footer>替换无语义div，是修复爬虫识别、屏幕阅读器导航和团队协作失能的基础工程；需聚焦三类语义黑洞——含header/nav/main/sidebar类名的div、包裹独立内容且带标题的div、仅承载补充信息的div，并严守<main>唯一性、<nav>专一性及<section>须带标题等核心规则。
直接说结论：用 <header>、<nav>、<main>、<article>、<aside>、<footer> 替换掉满屏的 <div class="header"> 和 <div id="content">，不是“锦上添花”，而是修复页面在爬虫、屏幕阅读器和团队协作中的基础失能。
怎么识别旧页面里哪些 <div> 该被替换
别通读全文，先盯三类高频“语义黑洞”：
- 所有带
class="header"、class="nav"、class="main"、class="sidebar"的<div>—— 这些就是现成的语义化入口，直接换标签，删 class - 包裹整段独立内容（如一篇博客、一条商品卡片、一则新闻）的
<div>，只要它有标题（<h1>–<h6>），就该换成<article> -
<div>里只放广告、相关推荐、作者简介这类“可移除不影响主干”的内容？那就是<aside>的典型场景
注意：<section> 不是万能容器。它必须有明确主题且自带标题（比如“用户评价”“技术参数”），纯为布局或样式而设的 <div> 换成 <section> 反而稀释语义。
<main> 只能出现一次，但很多人误用
常见错误是把每个子页面、每个弹窗、甚至轮播图都包进单独的 <main>。这会让屏幕阅读器反复播报“主内容开始”，造成导航混乱。
立即学习“前端免费学习笔记（深入）”；
- 一个 HTML 文档中，
<main>必须且只能有一个，且应直接包裹页面最核心、不可替代的内容区块（比如搜索框+结果列表、文章正文、商品详情） - 如果页面是多 tab 切换结构（如“基本信息/规格参数/用户评价”），
<main>应包裹整个 tab 容器，而不是每个 tab panel 单独套一个 - 嵌套在
<article>或<section>里的内容，不需要再加<main>—— 它们自身已具备内容独立性
浏览器 DevTools 里检查 <main> 出现次数，超过一次就说明结构出问题了。
为什么 <nav> 不能随便套链接组
把页脚所有链接、面包屑、分页按钮、甚至“返回顶部”都塞进同一个 <nav>，等于告诉爬虫“这些链接同等重要”，反而稀释主导航权重。
-
<nav>应仅用于主要导航路径：顶部主导航栏、左侧菜单、页脚站点地图（sitemap） - 面包屑用
<nav aria-label="面包屑导航">，分页控件建议用<nav aria-label="文章分页">—— 加aria-label是为了区分用途，避免语义混淆 - “登录/注册”这种功能链接、社交图标链接组，不属于导航范畴，用
<div role="group">或普通<div>更准确
搜索引擎对 <nav> 内链接的抓取优先级明显高于其他区域，滥用会导致关键链接被淹没。
重构后必须验证的两个盲点
改完标签不等于完成，机器可读性是否真正提升，得靠真实工具验证：
- 用 Chrome 的 Lighthouse 跑一次 Accessibility 审计，重点看 “
document.hasFocusableElements” 和 “heading-levels” 是否报错 —— 前者暴露 tabindex 混乱，后者常因<article>里没标题或跳级使用<h3>触发 - 用 VoiceOver（macOS）或 NVDA（Windows）朗读页面，听它是否能自然停顿在
<header>、跳过<aside>、把<article>当作独立单元播报 —— 如果仍读成“div div div”，说明某些父容器还残留 class 控制布局，或 JS 动态插入的内容没同步更新语义结构
语义化不是改完标签就一劳永逸的事；它要求每次新增模块、每次 JS 渲染新内容时，都延续同一套语义契约。否则，一个 <div class="card"> 就可能让前面所有努力失效。
