汀上飘的云一个页面里最容易被低估的 HTML 结构，大概就是 h1 到 h6 这一组标题标签。我做前端重构时经常碰到这样的情况：设计师给的稿子上，一个区域明明很抢眼，代码里却用一个 h4 去承载；又或者是文章详情页从 h1 直接跳到 h3，问起来对方会说“因为 h3 样式比较好看”。页面渲染出来确实没区别，但搜索引擎和屏幕阅读器读取页面结构时，这套标题层级就是一团乱麻。
所谓“标题跳级”，指的是在 h1~h6 的连续层级中，从较高级别直接跳到了更低级别，比如 h1 之后接 h3，或者 h2 之后接 h4，把中间的 h2、h3 给“吃掉了”。这个问题既牵扯 SEO 对页面主题的理解，也关系到依赖辅助技术的用户能不能顺畅浏览。这篇内容我会结合真实站点案例、可访问性规范和可执行的排查工具，讲清楚标题跳级为什么不行，以及怎么从源头和代码层面把它稳住。
1. 我们常说的“标题跳级”，到底是怎样的结构问题
1.1 从一次真实的页面改版开始
之前我接手过一个企业官网改版。原首页的结构是：主视觉区域用了一个 h1 放品牌 Slogan，下面服务介绍区块的标题是 h2，每个服务项的子标题是 h3。本来结构挺清晰，但改版后设计师觉得 h2 的默认字重太粗，视觉上抢了主视觉的风头，于是开发就直接把服务介绍区块的 h2 标签改成了 h4，子标题继续用 h3。
结果很有意思：页面上用浏览器打开，视觉没毛病，但用 HTML 大纲工具一看，标题序列变成了 h1 -> h4 -> h3。H3 出现在 h4 后面，不仅“跳级”，而且层级倒挂。屏幕阅读器用户打开页面的标题列表时，听到的是“标题一”之后直接蹦出“标题四”，那个“服务介绍”在哪儿、子标题归属于谁，完全没法从结构上理解。
这就是标题跳级最常见的成因：拿标题标签当样式工具。很多人以为 h 系列标签和 font-size 差不多，大就选 h2，小就选 h4。但 HTML 标题的价值不在“字号”上，而在“语义层级”上。
1.2 跳级和“样式不好看”是两码事
如果把标题跳级单纯理解成“层级序号不连续”，其实还没抓到要害。它真正的危害是破坏了页面大纲的嵌套关系。页面大纲就像一本书的目录，正常来说应该是：
- 第一章
- 第一节
- 第二节
- 第二章
如果一本书的目录写着“第一章 -> 1.1 -> 1.2 -> 第二章 -> 2.2.1”，即便排版没问题，读者也会觉得这个目录逻辑很怪。页面标题也一样，h3 天然表示它是 h2 区块下的子内容，h4 天然表示它是 h3 区块下的子内容。你将标题中间层抽掉，等于让内容的“父子关系”直接断裂。跳过的层越多，这种断裂越明显。
另一种常见认知误区是：“只要我在视觉上用缩进、字重做了层级，代码里是不是可以随便选？”不行，你在浏览器里看到的“标题层级”，是根据标签语义推算出来的；缩进和字体只是视觉装饰，替换不了结构。CSS 能把任何元素改成大标题的样子，但它不能把一个 div 变成一个真正的标题。
1.3 HTML 大纲是页面里唯一可被解析的目录
HTML 规范里对 h1~h6 的定位很早就有明确说明：这些元素表示页面或区块的标题，用于描述内容的主题和次级主题。浏览器默认样式让 h1 最大、h6 最小，只是视觉上方便人们识别，并不是说 h 标签存在的意义是控制字号。搜索引擎爬虫会解析 DOM，从 h 标签序列里推断页面哪些部分是互相独立的内容块；读屏软件同样利用这些标题构建“快捷导航菜单”。
你可以简单地把页面大纲当成站点给机器看的那份目录。如果这份目录出现跳级，就等于在这份目录里少了几个章节，或章节归属混乱。对于普通用户来说，页面视觉上没有洞；对于机器或依靠标题导航的用户，页面逻辑上就真的“少了一章”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 跳级对 SEO 的影响：内容权重与主题结构如何被打散
2.1 搜索引擎怎么“消费”标题标签？
搜索引擎对待标题标签，不能简单理解成“把标题里的关键词抓出来，排名加分”。更接近实际的是：爬虫拿到一个页面后，会先构建 DOM 骨架，然后通过 h1~h6 的结构去判断页面先后出现了哪些主题块，各主题块下面的副主题又是什么。H2 通常是围绕 H1 展开的子主题，H3 又继续细化 H2 的内容。这种树形结构对搜索引擎理解文档很有帮助，尤其对于长文、专题页、帮助中心这类内容密集的页面，标题层级几乎是主题大纲的代名词。
跳级本身很少会直接触发什么“惩罚”，但会带来三个很实际的问题：
- 主题归属不清晰：当 h2 区块下直接出现 h4 时，爬虫需要花费更多力气判断 h4 到底是不是 h2 的下级。没有中间的 h3，h4 内容归属于哪一层就变成“靠猜”。
- 关键词层级被打乱：如果你希望用 h2 做技能类关键词，用 h3 做问题类长尾词，结果正文里 h3 没出现，h4 直接上阵，长尾词可能在 HTML 大纲里失去了应有的分支位置。
- 结构化语义减弱：很多 SEO 工具和性能分析工具会根据标题标签生成内容结构图，跳级会让结构图看起来像被人随意剪过。
2.2 跳级让主题关键词失去“从属关系”
举一个真实的关键词规划例子。你写一篇《家用咖啡机选购指南》，理想结构是：
- H1：家用咖啡机选购指南
- H2：意式咖啡机怎么选
- H3：加热方式对萃取的影响
- H3：泵压参数怎么看
- H2：美式滴滤咖啡机怎么选
- H3：水箱容量参考
- H3：滤网和保温设计
- H2：意式咖啡机怎么选
这里的“意式咖啡机怎么选”是典型的二级主题，“加热方式对萃取的影响”是它的细分。搜索引擎看到 H2 和 H3 的嵌套，能比较自然地建立起“意式咖啡机选型”下的延伸话题关系。如果正文为了视觉控制，直接把“加热方式对萃取的影响”写成 H4，那 H2 到 H4 之间缺了 H3，从大纲角度就成了“咖啡机怎么选”之下直接挂着 H4，可读性会变差。你原本用于承接和细化的关键词，就丢失了一级位置。
不是说 H4 不能用来优化关键词，而是标题的每一级都代表一定的内容深度。跳过一个层级，会让内容颗粒度跳变太大，机器反而不容易捕捉到你的主题递进关系。保持层级完整，本质上是在帮搜索引擎搭一条清晰的主题路径。
2.3 SEO 视角的正确姿势：树形结构而不是线性编号
有些内容后台会自动套用“标题一”“标题二”这种命名，编辑在写作时会顺手把层级按“我需要在视觉上多大”去选择，比如列表里觉得“标题三”有点小，就硬选“标题二”。这就是把自己带进坑的开始。
我们可以把整个页面标题看成一颗树，而不是一排编号。树根通常是唯一的一个 H1，其下若干 H2 作为一级分支，H3 继续作为分分支。如果某分支没有下一级内容，就没有必要硬接一个 H4。
从 SEO 实操角度，我建议在页面设计阶段就确定每一块内容在第几层。比如博客详情页中，文章标题用 H1，文章内每个大段落用 H2，大段落里的小点用 H3。如果文章本身没有二级阶段，就不要随便给一个 H3 让它孤零零出现。页面底部的那一堆“相关推荐”“热门文章”板块，如果它们在语义上和正文不是从属关系，通常不建议排到 H2 内部，而是可以用 aside、div 配合内部自己的 H 层级 处理。最稳妥的办法是，给这类辅助模块一个独立的 H2 当作模块标题，然后再往下细分，不要随手拿 H4 作为整个辅助模块的第一级标题，这样很容易造成页面主区域和辅助区块之间的混乱。
3. 屏幕阅读器与键盘用户的真实体验：跳级比想象中更伤
3.1 屏幕阅读器用户如何用标题导航
你可能没想过，很多视障用户打开一个页面，第一件事不是从头开始听，而是打开“标题列表”，像用目录一样挑选自己想看的内容。
以我测试过的 NVDA 和 VoiceOver 为例，用户按快捷键 H 可以在标题之间跳转，或者在虚拟光标下打开元素列表，选择按标题浏览。这时页面里的每一个 h1~h6 都会单独列出一行，并且表示出级别。对用户而言，标题就是页面的路标。他们听到的是类似“标题一级，某某网站首页”“标题二级，服务项目”“标题三级，网站建设详情”这样的组合。
如果页面标题层级跳级，屏幕上看到的标题列表就会出现断档。比如标题序列是“H2: 产品优势 -> H4: 售后服务流程”，用户会觉得奇怪：这个 H4 是在 H3 下面的内容吧？可 H3 不见了。我有没有错过什么？是要回过头去找那个 H3，还是这个 H4 就属于 H2？在辅助技术的上下文里，这个“H3 缺位”会产生实际的信息判断障碍。
3.2 一次跳级的实际朗读体验
想象一下，你使用读屏软件打开这样一篇文章，开头顺序大概是：
- 标题一级：新手做跨境电商应该如何起步
- 标题二级：店铺定位之前必须先想清楚的问题
- 标题四级：平台规则是定位的一部分
- 标题二级：资金准备阶段要避免的坑
第一次听到“标题四级”出现在“标题二级”之后时，你可能第一反应是“这页面的结构坏了吗？”，然后你会试图从标题列表里找那个缺失的“标题三级”。如果全文标题很多，这种跳级会反复打断用户的导航逻辑。辅助技术并不会自动帮你补上一个中间层，它只会照实朗读你代码里给出的层级编号。
还有一个很容易被忽略的细节：语音助手操作页面时会用标题级别来决定如何表述位置。比如用户在页面里说“回到上一节”，如果上一节是 H2、再上一节也是 H2，中间的 H4 并不构成一个“节”的概念，导航很容易变得不可预期。
3.3 WCAG 关于标题的建议到底是什么
Web 内容无障碍指南（WCAG）里没有单独一条“禁止标题跳级”，但它有几个非常核心的准则和标题相关。
- 1.3.1 Info and Relationships：信息、结构以及与其他信息之间的关系，要能通过程序化方式确定。标题层级就是一种结构关系。如果 H2 下面直接跟 H4，而非 H3，用户程序很难推导出这个 H4 属于 H2 之下的哪个层级，结构关联就不够明确。
- 2.4.6 Headings and Labels：建议标题要能够描述主题或目的。这说的是标题质量，不是级别连续性。
- 2.4.10 Section Headings：建议只要有可能，就用标题来组织页面内容。
W3C 在无障碍最佳实践文档里，关于标题写的示例通常会包括：用 h1 表示页面主标题，h2 表示主要区域标题，h3 表示主要区域下的子区段标题，不跳过标题层级。在 G141 这个“用标题组织页面”的充足技巧中，也有一段说明：确保标题层级不要跳级，提供一个描述性标题……虽然“跳级”有时候不会直接判为失败，但很多第三方无障碍审计工具会把“跳过标题层级”作为 best practice 型问题提醒你修复。
所以与其卡在“我有没有违反 WCAG”的边界上，不如养成不跳级的好习惯。无障碍不是考试，不用等达到及格线就万事大吉，它是让结构更接近人的预期。
4. 怎样从源头避免标题跳级：内容规划与 HTML 写作规范
4.1 写内容前先画“标题大纲”
大多数标题跳级不是发生在编码阶段，而是发生在内容大纲没想清楚就开写的阶段。你可以先拿出一张纸，或直接在文档工具里把标题关系写出来。我自己的习惯是在每次做页面内容规划时，先画这样一棵树：
- H1：页面主标题，一般一个页面只保留一个。哪怕是官网首页，最终 H1 也只会落在品牌或首要主题上。
- H2：页面中的主要分区。比如“核心服务”“成功案例”“行业解决方案”“关于我们”。
- H3：每个 H2 分区内部的分组。比如“核心服务”下面按服务类型拆分。
- H4~H6：尽量少用。它们一般只出现在非常深的内容结构里，例如长长的帮助文档、法律条款结构或教程子步骤。
这个大纲不是写给开发看的，是写给整个内容协作链路看的。编辑写正文时根据大纲选用对应的标题级别，前端根据页面最终大纲选择语义标签。如果 CMS 支持富文本编辑器，在工具栏上只显示当前可用的标题级别，也会减少误用。
4.2 内容写作与标题填充的正确顺序
很多编辑习惯先把所有文字的视觉样式做完，最后再统一套标题，这时候很容易出现“这个标题应该大一些”的临时判断。真正稳定的流程应该是：
- 先把每个内容块按逻辑层级写出来，不纠结字号；
- 将每个内容块的主题提炼成标题；
- 给每个标题标记层级，检查相邻标题是否连续；
- 最后再做视觉样式。
比如你要写一个客户案例页，大纲是：
- H1：某连锁门店数字化转型案例
- H2：客户背景
- H2：核心痛点
- H3：门店管理效率低
- H3：数据割裂严重
- H2：改造方案
- H3：后台系统统一
- H3：管理看板实施
- H2：改造结果
这样在写作前就确定了“门店管理效率低”和“数据割裂严重”同属“核心痛点”的 H3，而不是在正文写到一半临时想到就插一个 H4。如果某个痛点下还需要更小点，例如“门店管理效率低”下面还有“排班耗时”和“物料损耗高”，那就为“排班耗时”“物料损耗高”提供 H4，形成完整链路。
4.3 视觉样式和 HTML 层级冲突时怎么处理
现在到了很多人真正卡住的地方：开发时发现页面上“核心痛点”的字号希望是 24px，而正文字号 16px，但“改造方案”也是 24px。既然它们都是 H2，默认样式会一致。这时不该做的是：为了让某个区域标题看起来小一点，就把 H2 临时改成 H4，又为了填补 H4 和 H2 之间的空档，硬造一个 H3 但里面没有内容的标题。
正确做法是先保留 H2 的语义，再用 CSS 覆盖样式：
css复制/* 如果 24px 太大，重新定义 h2 的视觉尺寸 */
.section-title {
font-size: 20px;
}
但更好的方式是给 h2 本身写一个基础样式类，而不是在 HTML 里根据视觉去调整 h 标签级别：
css复制.page-module h2 {
font-size: 1.25rem;
}
标题样式和标题层级可以分离。你想让页面上同一个层级的标题体现不同视觉——主内容区 h2 大一些，侧边栏 h2 小一些——完全可以通过作用域类控制。要解决的永远是“这个内容在页面结构中属于哪一层”，而不是“我希望它显示多大”。
如果视觉设计师强烈要求某个模块看起来像 H4 风格，而你在结构上判断它就是 H2，那就把设计师的字号和字重视为一种样式需求，用 CSS 去匹配，别污染语义。如果视觉设计稿里将模块标题排得比 H2 小，但没有真正的子结构，我会选择“视觉上更大、字重更重的一个标题”，通过改变样式而不是降低层级来达成设计目标。
5. 用一套可复用的排查方案，找出站内所有跳级标题
5.1 浏览器扩展与在线检测工具的取舍
在代码里一个个数标题太累，而且容易遗漏。排查标题结构，我常用的几种工具是：
- WAVE：网页可访问性评估工具，可以高亮页面标题，并给出标题层级列表，判断是否存在跳级和不合理顺序。
- aXe DevTools：针对 WCAG 的自动检测工具，它把 heading-order 作为自动化规则，页面如果出现 h1 之后直接跳 h3，会明确提示“Headings are not ordered”。
- Lighthouse：Chrome 内置审计中，有 SEO 和无障碍板块，也会在部分版本提示标题层级相关问题。
- HTML Outliner：浏览器扩展，能基于页面 h1~h6 生成目录大纲，拿来模拟搜索引擎看到的结构。
这些工具的定位存在差异。WAVE 和 aXe 偏重可访问性，对“跳级”非常敏感；HTML Outliner 是帮助你感知结构层级；Lighthouse 则会将 SEO 和无障碍一起审查，更像一个综合提醒。建议组合使用：日常开发用 aXe 快速检查，改版前用 WAVE 整体扫描，最后用浏览器扩展肉眼过一遍大纲。
5.2 控制台脚本输出当前页面标题骨架
工具之外，还可以在浏览器控制台执行一段 JavaScript，直接把当前页面所有标题按出现顺序打印出来。我以前在项目排查时用的脚本大概是这样的：
javascript复制const headings = Array.from(document.querySelectorAll('h1, h2, h3, h4, h5, h6'));
const levels = { h1: 1, h2: 2, h3: 3, h4: 4, h5: 5, h6: 6 };
const outline = headings.map((el) => {
const tag = el.tagName.toLowerCase();
const text = el.textContent.trim().replace(/\s+/g, ' ').slice(0, 60);
return `${' '.repeat(levels[tag] - 1)}${tag}: ${text}`;
});
console.log(outline.join('\n'));
运行后你会看到类似：
code复制h1: 某某官网
h2: 核心服务
h3: 企业建站
h3: 移动端开发
h2: 成功案例
h4: 某连锁门店系统
注意末尾 h2 后面直接跟 h4，这里缺少 h3。把这种肉眼判断变成自动告警，可以加一段逻辑：
javascript复制const headings = Array.from(document.querySelectorAll('h1, h2, h3, h4, h5, h6'));
const lv = { h1: 1, h2: 2, h3: 3, h4: 4, h5: 5, h6: 6 };
const issues = [];
headings.forEach((el, i) => {
if (i === 0) return;
const prev = headings[i - 1];
const currentLevel = lv[el.tagName.toLowerCase()];
const prevLevel = lv[prev.tagName.toLowerCase()];
// 当前级别比上一级别深，且超过一级，说明跳级
if (currentLevel > prevLevel + 1) {
issues.push(`第 ${i} 个标题：<${prev.tagName.toLowerCase()}> 到 <${el.tagName.toLowerCase()}> 跳过了 h${prevLevel + 1} 层级`);
}
});
console.log(issues.length ? issues.join('\n') : '未发现标题跳级');
这段脚本只检测“更深且超过一级”的情况，比较贴合常见跳级定义。如果页面结构是从 H2 回到 H1 再开启一个新章节，不会误报；如果 H2 后面紧跟 H4，会第一时间抓到。
5.3 从单页排查走向整站审计
单页排查只能解决单个模板问题，做整站标题层级审计时，还需要考虑模板和后台内容的叠加。一个内容页模板可能本身标题层级是好的，但后台富文本允许编辑自己选择 h4 标题样式，插入到了 h2 区块下方，就可能在带动态内容的页面上出现跳级。
实际做法是：先抓取整站内容页 URL，用 Puppeteer 或 Playwright 访问每个页面，在执行完页面脚本后，运行上面提供的检测脚本，把存在问题的 URL 和标题序列收集起来。批量环境下，我会输出成一份 CSV：URL、原标题级别、前一个标题级别、标题文本，然后发给内容团队逐个确认。
如果你只想快速看几个主要页面，也可以减少批量自动化。但要注意，标题跳级通常不是每个页面都出现，它更容易出现在：
- 文章详情页（编辑自由使用标题）
- 企业产品详情页（各模块由不同组件拼装）
- 帮助中心或文档站（内容结构复杂）
- 同一页面内嵌入了多个小组件
所以全站审计有必要。否则一个模板修好，另一个内容模板里的编辑还是能跳出 h4 来。
6. 常见伪标题与坑位：为什么 div+css 和图片“更像标题”但更危险
6.1 使用 div 和 span 冒充标题
之前看到有团队为了避免跳级，干脆不用 h3，而是把一个 div 拖出来画成标题样式。这样页面不管从 h2 到任意 div 再到 h3，视觉上都“不错”，因为机器根本分不出那个 div 是标题，所以也不会觉得“跳级”。
但这不是在解决问题，而是把标题跳级换成了“没有标题”。aXe 和 WAVE 这类工具不会告诉你 div 样式“标题”产生跳级，因为它们根本不把它当标题。真正的后果是：搜索引擎从页面里少提取了一个主题信号，屏幕阅读器的标题列表里也不会有这个伪标题。用户从 H2 往下找子内容，读到的可能直接是一段正文，接下来才看到一个 H3，造成更大的导航断层。
HTML 的标题语义是被辅助技术硬编码支持的。div 就是 div，加再多 class 也没办法变成标题。别用视觉去判断一个元素“看起来像不像标题”，要看它是否承载了“区块标题”的语义职责。
6.2 图片代替文字标题
图片代替标题，在很多老网站上还能看到，比如用一张“公司产品介绍”的图片放在区块顶部。这张图如果确实需要作为标题语义，通常给 img 加 alt 文本，可它不是标题元素，就不会出现在标题导航中。
同时，图片标题受加载、缓存和 alt 文本质量影响。图片延迟加载时，搜索引擎和辅助技术可能暂时看不到这个标题；alt 写得过于简短或者完全缺失，就相当于页面大标题消失。除非是 Logo 这类品牌元素，我不建议用图片承载结构化标题。如果一定要用图片，可以在同一区块内增加一个视觉隐藏的 h2 或 h3，从而保证大纲完整，再用 CSS 把图片定位到标题之上作为视觉呈现。
6.3 隐藏标题的正确做法：保留可见文本还是 clip？
还有一种常见场景：区块标题希望只在视觉上不直接显示，比如页面主视觉上已经有超大文字，但为了结构完整性，还是需要一个 h1。很多人为了避免重复，会把这个 h1 用 display: none 藏起来。这样做在可访问性上并不安全，因为 display: none 会把元素从可访问性树中彻底移除，屏幕阅读器用户也看不到它，等于标题还是缺了。
更稳妥的做法是用“视觉隐藏类”，让元素仍然存在于屏幕阅读器可访问树中，但视觉上被裁剪。一个常见实现是：
css复制.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
应用到一个带真实文本的 h1 上，可以同时兼顾视觉干净和结构完整。利用这种方案，能比较安全地处理辅助模块标题、Logo 标题、图表标题等边界情况，而不是粗暴地把它藏起来。
7. 有没有可以破例的场景？标题层级与视觉层级的辩证关系
7.1 HTML5 section 分区带来的变化
讨论标题跳级时，很多人会提到 HTML5 的 section 元素和“分区根节点”概念。早期的 HTML5 规范里，section 内部可以重新开始一个 h1，并允许各个分区都有自己的大纲级别，浏览器再基于分区根节点重新计算。但这里有一个巨大的现实问题：至今浏览器和屏幕阅读器对“HTML5 outline algorithm”的支持并不完整，实际辅助技术仍然按照老式的 h1~h6 嵌套顺序来理解标题。因此你不能指望把一个 h4 扔在 section 里让读屏软件自动把它“当作” h3。业界的主流看法是：继续把 section 作为普通的分区元素使用，并老老实实地用 h1~h6 表达内容嵌套关系。
7.2 独立组件内是否允许使用 h4 直接跟在 h2 后
在实践中，确实会有“这里只是一个侧边栏小组件，没有更多子结构，但我不想用 h3，因为觉得它太大了”的诉求。例如一个叫做“最新资讯”的侧边栏，前面页面主内容已经有 h2 了，侧边栏想要展示三条资讯。如果不加思考，可能有人会给侧边栏板块用一个 h4，但页面大纲会是 H2->H4。这算不算合理？
我的处理方式是先改变思考维度：侧边栏不是主内容的一部分，它是在主内容旁边的一个独立区块，应该寻找合适的 section 或 aside 边界。如果侧边栏包含在主导区域 DOM 里，直接给 h4 确实会跳级；如果用一个带 aside 标记的独立分组，组内第一个标题其实可以考虑恢复到 h2 作为模块标题，但实际上一页里会有两个 h2。现代页面完全可以有多个 h2，只要它们不相互混淆。比如：
html复制<main>
<h1>活动详情</h1>
<h2>活动日程</h2>
</main>
<aside>
<h2>报名方式</h2>
</aside>
这样虽然页面出现两个 h2，但一个属于主区域，一个属于辅助区域，大纲仍然可以理解。如果担心视觉上侧边栏的 h2 太大，就给它套一个模块类缩小字号。这是解决“跨区域不起冲突”的常见策略。
7.3 我个人的处理偏好和项目实践
我自己参与过的项目里，通常会把“独立组件内部的标题”规划成可以从 h2 重新开始，但前提是组件确实从语义上独立于前面内容。比如商品详情页的“规格参数”“售后说明”“商品评价”都可以是独立的 h2；这些模块内部再按 h3 或 h4 安排细节。如果是一个无法独立成模块的连续正文，我坚决要求 h1~h6 顺序连续。
至于“破例”是否允许，我倾向于这样界定：只要页面内容在逻辑上是同一条文章流，就不要跳级；如果是紧挨着的、互相独立的页面区块，则可以认为每个区块或组件是独立的“迷你页面”，允许各自内部从 h2 重新开始标题层级，但前提是不跟前后区块混淆，同时组件标题尽量不要随便落在 h4 这种过深层级上。不要把 h4 当作“小号标题”工具来避免某个视觉冲突，那只会让机器和辅助技术更难判断。
在团队协作上，我会直接把标题层级要求写进代码规范：页面主内容至少有一级标题；模板内的动态标题只能读取内容字段中预设的级别；前端开发不得因为样式需要修改 h 标签。后台编辑器即使提供了“标题”下拉框，也要在样式里限制为 h2、h3、h4，并默认从 h2 开始。用一套系统化的规范，比每次靠代码 review 去人肉抓跳级可靠得多。
检查完后，除了修复当前页面，还有一个小经验值得分享：不要只把目光放在 h1 和 h2 上，那些隐藏在长文底部、帮助中心文档内层、FAQ 折叠面板里的标题，往往才是跳级重灾区。因为这些内容经常由多套模板拼接，开发改了一个区域的层级，另外一个区域的层级沿用旧结构，新的拼接页面就容易出错。把标题结构验证加进自动测试里，或者至少在发布前跑一次大纲审计，比事后被用户或 SEO 工具提醒要舒服得多。