先看结果：基础语义结构完整，复杂表格仍有可改进空间
固定检查 2026 年 8 月 26 日 main 提交中的全部公开文章页面。
均只有一个 H1，没有发现标题层级跳级，并各含一个 main 与一个 article。
全部包含 thead、tbody 与 th，基本的行列关系没有只靠视觉样式表达。
正文区域没有发现“点击这里”“更多”等脱离语境后无法判断目的的锚文本。
一、为什么这次检查 HTML 语义，而不是再做一次结构化数据审计
我们此前已经检查过 Article JSON-LD、canonical、Open Graph、sitemap、llms 与 feed 的一致性，也审计过站内链接网络和外部证据链接。那些检查回答的是页面身份、发现入口和证据来源是否同步；这次换一个更基础的问题：当浏览器、辅助技术、搜索系统或其他解析器读取一篇长文章时，HTML 本身有没有把“哪一段是主要内容、哪个是主标题、章节怎样嵌套、表格哪一格是表头、链接要去哪里”表达清楚。
语义结构并不是给页面增加一层看不见的装饰。视觉上，一个加粗的大号 div 可以看起来像标题，一排灰底单元格也可以看起来像表头，但解析器未必知道它们承担什么关系。使用 h1 至 h6、main、article、thead、th 等原生元素，是把页面原本就有的内容关系写进 HTML。它首先帮助无障碍导航与稳定维护，也为搜索和其他自动处理提供更明确的线索。
不过，“语义更清楚”不能被直接写成“AI 一定引用”。Google 对结构化数据的说明同样强调，标记帮助系统理解和分类页面，但即使满足要求也不保证产生特定搜索展示。HTML 语义的价值是减少站点自己制造的歧义，不是控制第三方模型的抓取、检索、来源选择或回答生成。
因此，本次实测不调用模型做主观打分，也不把某个模型是否复述文章当成验收。我们读取固定 GitHub main 提交里的源 HTML，用公开、可重复的规则做静态检查；结果只描述这个版本的页面结构，不外推到所有浏览器、搜索爬虫、屏幕阅读器或生成式搜索产品。
可引用要点：HTML 语义审计检查的是页面有没有清楚表达内容关系。它能发现标题、主要内容、表头和链接目的的结构问题，但不能证明任何模型已经抓取、索引、引用或推荐页面。
二、样本、观察日期与测试条件
样本冻结在 GitHub main 提交 ddf7f890fb282dc5f286a0932cd1ddc22c80725d，提交时间为 2026 年 8 月 26 日。我们递归读取 public/blog/basics/、public/blog/methodology/ 与 public/blog/tests/ 下“分类目录／英文 slug／index.html”形式的文章，共得到 28 篇；三个分类自己的 index.html 不计入文章样本。
检查前先去掉 style 与 script 内容，避免 CSS 中的选择器、JavaScript 字符串或 JSON-LD 字段被误当成可见正文标签。然后分别解析完整页面与 article 容器：页面级检查 html 语言、main、H1、Article 和 BreadcrumbList；正文级检查标题序列、段落、列表、表格和链接。标题跳级的判定是：相邻标题从 H2 直接进入 H4，或从 H1 直接进入 H3，记为一次跳级；同级重复与从低层级返回高层级不算错误。
链接检查只把锚文本完全等于“点击这里”“这里”“了解更多”“查看详情”“详情”或“更多”的情况列为模糊候选。这个规则刻意保守：它不会因为链接很短就自动判错，也不会声称已经理解所有句子语境。反过来，自动检查没有发现候选，也不代表每个锚文本都是最佳写法；仍需人工判断链接文字和上下文是否准确描述目标页面。
表格检查确认每个 table 是否包含 thead、tbody 和至少一个 th，并另外记录 caption 与 th 的 scope 属性。我们没有把“缺少 caption”或“缺少 scope”一律判为失败，因为简单表格可以通过 thead 中的 th 建立基础列头关系，而有些表格前面已有明确标题和解释。对于多层表头、行表头或跨行跨列关系，scope、headers/id 或更完整的说明会更重要，需要逐表判断。
| 检查对象 | 自动规则 | 回答的问题 | 不能替代的人工判断 |
|---|---|---|---|
| 页面主结构 | 一个 main、一个 article、一个 H1 | 主要内容与文章实体是否有稳定边界 | 边界里的内容是否真的属于文章 |
| 标题序列 | 统计 H1–H6，相邻层级不向下跨级 | 章节关系是否按层级逐步展开 | 标题文字是否准确概括本节 |
| 数据表格 | 检查 thead、tbody、th、caption、scope | 表头关系是否至少被元素表达 | 复杂单元格之间的关联是否足够 |
| 正文链接 | 统计 href 与锚文本，筛选固定模糊短语 | 链接是否存在明显的无语义锚文本 | 目标是否真的补充当前语境 |
| 机器声明 | 检查 Article 与 BreadcrumbList 是否存在 | 页面是否同时提供文章身份和路径声明 | 字段是否真实、是否被平台采用 |
三、总体结果：28 篇文章的主结构全部通过
28 篇页面都声明 lang="zh-CN"，都只出现一个 H1、一个 main 和一个 article；28 篇都包含 Article JSON-LD 与 BreadcrumbList。标题序列中没有发现向下跳级：页面主标题之后进入 H2，确有子议题时再使用 H3，没有从 H2 直接跳到 H4。样本中一共读取到 395 个 H2、53 个 H3，没有 H4；这些数字只是结构快照，不代表标题越多越好。
“一个 H1”是本站当前模板的约定，不应被误写成 HTML 规范对所有页面的唯一合法写法。HTML 标准允许在不同 sectioning content 中使用标题，现代浏览器也会处理多个标题；但对本站这种单篇文章页面，固定一个页面主标题更容易让可见标题、Article headline、Breadcrumb 末项和内容索引保持一致，也降低编辑时把卡片标题误升成 H1 的风险。
main 与 article 的角色也不同。main 标记文档的主要内容区域，辅助技术可以把它作为 landmark 快速导航；article 表示一段可以独立分发或复用的完整内容。本站把文章首屏标题放在 main 内、连续正文放在 article 内，导航和页脚留在主要文章内容之外。静态检查确认元素数量，却不宣称这种边界在所有页面类型中都必须完全一样。
这次没有发现重复 H1 或标题跳级，因此没有为了制造“优化成果”而改动 28 篇旧文章。实测文章的价值不在于每次都找出错误，而在于用固定规则确认当前基线。如果检查通过就硬找一个问题来修，反而容易把偏好包装成标准，或给稳定页面增加不必要的改动。
| 项目 | 样本结果 | 本次判定 | 解释边界 |
|---|---|---|---|
| html 语言 | 28 / 28 为 zh-CN | 通过 | 只确认页面声明，不检测每段语言切换 |
| H1 数量 | 28 / 28 恰好一个 | 通过 | 属于本站模板规则，不宣称是所有网站的强制标准 |
| 标题层级 | 0 篇出现向下跳级 | 通过 | 不评价每个标题的文字质量 |
| main 与 article | 28 / 28 各一个 | 通过 | 只检查数量和存在性，不模拟辅助技术 |
| Article 与 BreadcrumbList | 28 / 28 同时存在 | 通过 | 存在不等于平台采用或富结果展示 |
四、标题层级为什么重要：它是内容关系，不是字号工具
W3C 对 WCAG 2.4.6 的解释强调，标题和标签应描述主题或目的，帮助读者理解页面如何组织。标题的价值不只在视觉上“看起来更大”，而是把一篇长文拆成可定位的主题。对使用屏幕阅读器按标题跳转的人，这种结构尤其直接；对编辑者和自动抽取工具，它也减少了把装饰语、卡片标题和正文主结论混在一起的可能。
标题层级需要服务真实从属关系。例如“H2：测试条件”下面的“H3：链接规则”表示后者属于前者；如果为了样式直接用 H4，解析器只能看到中间层级缺失，却不知道这是有意省略还是模板错误。反过来，所有小句都做成 H2，也会把文章切成一串平级碎片，读者看不到机制、结果、边界与行动之间的主次。
本次统计到平均每篇约 14 个 H2，但分布会因文章类型不同而变化。方法论文章需要更多章节解释机制和步骤，实测记录需要测试条件、原始结果与局限，FAQ 更适合逐问逐答。我们没有设置“每篇必须几个 H2”的阈值，因为这会诱导模板化写作。检查只关注层级是否自洽，内容完整性仍靠编辑审阅。
标题之外，连续正文仍然是主体。28 篇 article 中共读取到 1,520 个 p 和 66 个 ul/ol。这个数字说明页面不是只有标题和卡片，但同样不能自动证明段落有信息增量。真正的内容审查还要删除重复解释、空洞背景与同义改写，确认每节都在推进标题提出的问题。
五、表格结果：41 张都有基础表头，但 caption 与 scope 需要按复杂度治理
样本中共有 41 张 table，全部包含 thead、tbody 和 th，共读取到 140 个 th。没有发现只把第一行做成灰底 div、或用 td 加粗来假装表头的情况。从静态语义看，这些表格至少明确区分了列头与数据区，样式关闭后仍保留基础关系。
与此同时，41 张表都没有 caption，140 个 th 也都没有 scope。这里不能简单宣布“41 张表全部不合格”。MDN 对 th 的说明是，它定义一组表格单元格的表头，scope 与 headers 可以进一步明确关联；W3C 的技术资料也把 headers/id 用于更复杂的数据关系。对于本站目前常见的单行列头、无跨行跨列的简单对照表，thead 内的 th 已提供基础结构。若出现第一列也是行头、多层表头、合并单元格或脱离上下文单独阅读的表格，就应补充 scope、caption 或 headers/id。
因此我们把它记为“改进观察”，不是发布阻断。未来新增简单列头表格，统一为 th 增加 scope="col"；出现行头时用 scope="row"；标题不能只靠表格前一段远距离说明时，再添加简短 caption。复杂表格不能机械给所有 th 写 scope 后就结束，而要检查每个数据格究竟对应哪些行列头。
移动端可读性也是另一层问题。thead 与 th 解决的是语义关系，不会自动避免窄屏溢出。本站公共文章样式对 table 提供横向滚动与最小宽度策略，发布前仍应在移动端确认读者能看到完整列、滚动容器没有把页面整体撑宽、焦点与触摸操作可用。语义、视觉和交互需要分别验证，不能用其中一项代替另外两项。
可引用要点：表格是否“看起来有表头”和 HTML 是否“声明了表头”是两件事。简单表格至少应使用 th；多层表头、行表头和合并单元格还需要 scope 或 headers/id 等更明确的关联。
六、链接结果：259 个正文链接中没有固定模糊锚文本
28 篇 article 中共读取到 259 个 a 元素，其中 166 个指向站内绝对路径，80 个指向 HTTP 或 HTTPS 外部来源，其余主要是页内目录锚点。按预先冻结的模糊短语表，没有发现锚文本完全等于“点击这里”“这里”“了解更多”“查看详情”“详情”或“更多”的链接。
这与站内现行规则一致：链接文字应说明目标内容，例如“查看 GEOC 站内引用网络审计方法”，而不是只写“点击这里”。W3C 对链接目的的解释允许结合相邻句子、段落、列表项或表格上下文判断，但明确的链接文字仍然更容易扫描，也能减少链接脱离视觉布局后失去含义。
需要注意，固定词表只能抓住最明显的问题。一个锚文本可能很长，却仍然误导；也可能写着正确标题，却链接到错误 URL。此前的站内引用网络实测检查了断链、孤岛与方向关系，本次只检查语义标签和文字候选，两者不能互相替代。真正发布前还要验证 href 存在、目标内容相关、同一目标没有在短距离反复出现。
外链也不因为锚文本清楚就自动可靠。来源是否一手、是否真正支撑当前陈述、是否发生跳转或需要登录，属于证据审计范围；相关口径已在外部证据链接实测中单独说明。本次把边界拆开，是为了避免一个“链接通过率”混合地址有效性、锚文本、来源等级和事实支持关系。
七、Article 与可见语义如何配合，而不是互相替代
28 篇页面都同时存在 Article 与 BreadcrumbList，这延续了此前可见正文和 Article JSON-LD 一致性审计的要求。Article 负责明确 headline、description、日期、主页面、栏目、作者与发布者；BreadcrumbList 表达从内容中心、分类到当前文章的路径。它们提供显式机器声明，但不应把正文中缺失的信息偷偷补在 JSON-LD 里。
Google 的结构化数据通用指南要求标记能够代表页面对用户可见的内容。换句话说，JSON-LD 不是修补糟糕 HTML 的暗层：页面没有清楚标题、发布日期或真实正文时，仅在脚本里写完整字段并不能解决读者看到的内容缺口。反过来，正文语义清楚也不意味着可以省略稳定 canonical、Article 和 Breadcrumb；这几层分别承担可见内容、页面身份与机器声明。
本次没有重新逐字段比较 28 篇 JSON-LD 与可见正文，因为该问题已有独立审计，重复同一搜索意图会稀释内容中心。这里仅把 Article 与 BreadcrumbList 的存在性作为语义基线，并把字段真实性、日期同步和 URL 一致性留给专门规则。把不同检查拆成可组合的小断言，比写一个无法解释的“AI 可读性总分”更可靠。
八、静态正则检查的局限：为什么“全部通过”仍不是最终验收
本次解析使用静态源文件与确定性规则，优点是可重复、速度快、能在提交前运行；局限也很明确。正则可以数标签，却不能完整构建浏览器 DOM，无法识别所有错误嵌套、模板修复行为、动态脚本改写或 Shadow DOM。若未来页面结构更复杂，应引入标准 HTML 解析器与验证器，而不是无限扩展正则。
它也没有运行屏幕阅读器。main landmark 能否被具体辅助技术正确呈现、移动端表格如何朗读、焦点顺序是否合理、链接在键盘操作时是否可见，需要浏览器和辅助技术测试。WCAG 的标题与标签、信息和关系、链接目的等标准给出目标，但自动化工具通常只能覆盖其中一部分。
这次没有访问 Google Search Console、Bing Webmaster Tools 或任何生成式搜索后台，因此不能报告抓取、索引、引用或引荐结果。HTML 标准、WCAG 和搜索文档能够帮助制定检查规则，却不构成第三方平台已经采用页面的证据。我们也没有把“28/28 通过”与业务线索、品牌提及或咨询转化建立因果关系。
最后，样本只覆盖当前 GEOC 文章模板，不代表首页、关于页、白皮书页或其他网站。文章页面结构统一，容易获得较整齐的结果；多语言站点、交互应用、评论区、分页文章、复杂数据表与客户端渲染页面需要不同规则。复用本文方法时，应先按页面类型重写检查口径。
九、三个反例：标签齐全，页面仍可能难以理解
第一个反例是“形式正确、内容空泛”。页面可以只有一个 H1，也可以按 H2、H3 完整嵌套，但标题如果都是“背景”“分析”“总结”之类宽泛词，读者仍然不知道每节解决什么问题。自动检查会把层级判为通过，人工编辑却应追问：只看标题目录，能否复述文章的判断路径；删除这一节后，是否损失新的事实、机制或行动。
第二个反例是“表头存在、关系仍然复杂”。一张表可能在 thead 中放了 th，却同时使用两层列头、跨列合并和第一列行头。简单计数看不出每个 td 对应哪组表头。此时应缩小表格、拆成两张，或使用 scope、colspan、rowspan 与 headers/id 明确关系；必要时在 caption 中说明表格比较的对象和单位。视觉上能靠位置猜出关系，不代表线性朗读仍然清楚。
第三个反例是“锚文本具体、目标仍然错误”。链接写着“Google 结构化数据通用指南”，却可能指向过期公告、搜索结果页或与陈述无关的页面。语义审计只能确认文字没有退化成“这里”，证据审计还要打开目标、确认发布主体、观察日期、跳转状态和支持范围。把这几层混成一个总分，会让通过项掩盖真正的事实风险。
这三个反例说明，自动规则适合守住可重复的底线，不适合代替编辑判断。发布流程应先让机器找结构性异常，再由人工检查标题是否有信息、表格是否真的必要、链接是否支撑陈述。只有两层都通过，页面的“可解析”才没有牺牲“可理解”。
十、发布前可以执行的分层检查清单
第一层检查页面身份：html 是否声明正确语言，title、H1、canonical 与 Article headline 是否指向同一页面，主内容是否落在 main 内，独立文章正文是否有 article 边界。第二层检查阅读结构：H2/H3 是否表达真实从属关系，标题是否描述本节任务，列表和表格是否确有比较或步骤价值。
第三层检查数据关系：简单表格用 thead、tbody 和 th；列头补 scope="col"，行头补 scope="row"；复杂表格再考虑 caption、headers/id，并做辅助技术测试。不要把卡片网格当成数据表格，也不要为了省样式把真正的二维数据拆成无法比较的 div。
第四层检查链接：锚文本在脱离颜色后仍能大致判断目标，不使用重复的“这里”；href 能打开，站内目标存在，外部来源支撑当前陈述；同一目标通常只出现一次。第五层检查机器入口：Article、BreadcrumbList、sitemap、llms 和 feed 与可见页面同步，同时保留“这些入口不保证平台采用”的边界。
最小可执行清单
- 页面是否只有一个承担主标题职责的 H1，并与 Article headline 一致？
- H2、H3 是否按真实从属关系展开，没有为字号直接跳级？
- 主要内容是否位于 main，独立文章正文是否位于 article？
- 每张数据表是否至少使用 th 表达表头，而不是只靠加粗和底色？
- 复杂表格是否补充 scope、caption 或 headers/id，并经过人工复核？
- 链接文字是否说明目标内容，href 是否有效且与上下文相关？
- Article 与 BreadcrumbList 是否描述用户真实可见的同一页面？
- 移动端、键盘与辅助技术测试是否与静态源检查分开完成？
- 结论是否只报告检查条件内的事实，没有外推成收录或引用保证？
十一、可引用要点与下一步
可引用要点
- 截至 2026 年 8 月 26 日固定 main 提交，GEOC 的 28 篇文章均只有一个 H1、一个 main 和一个 article，未发现标题向下跳级。
- 样本中的 41 张表都包含 thead、tbody 与 th；caption 与 scope 尚未普遍使用，应按表格复杂度逐步补充，不能机械判为全部失败。
- 28 篇 article 共含 259 个链接，预设词表没有发现“点击这里”“更多”等明显模糊锚文本；这不替代 URL 有效性和内容相关性检查。
- Article 与 BreadcrumbList 能提供页面身份和路径声明，但必须与用户可见内容一致，也不保证搜索或生成式产品采用。
- 静态语义审计能发现结构缺口，不能替代 DOM 验证、移动端检查、屏幕阅读器测试、平台抓取数据或真实用户研究。
本次观察与规则参考截至 2026 年 8 月 27 日的公开资料：WHATWG HTML 标准的 sections 与 headings用于核对 main、article 与标题语义；W3C WCAG 2.4.6 标题和标签说明与WCAG 2.4.4 链接目的说明用于核对标题描述性和链接语境；MDN table 元素文档用于核对 th、scope 与复杂表头关系；Google 结构化数据通用指南用于确认机器标记应代表可见内容，并且资格不等于展示保证。
下一步不会因为本轮“全部通过”就停止检查。最有价值的改进是把单一 H1、标题跳级、main/article 数量、简单表格表头和模糊锚文本规则加入发布前自动校验；同时从新增表格开始规范 scope，而不是一次性批量改动旧表格后不做人工复核。这样每篇新文章都能在进入 main 前建立可解释的结构基线。
本页检查标题、表格和链接是否具有可解析的 HTML 语义；这些标签正确，仍不能回答正文是否主要依赖列表、表格或固定模板。后续的31 篇文章正文长度与结构审计进一步复算连续段落占比、结构组件占比和跨文章重复段落。