我做过一个实验同一篇技术文章只调整HTML标签的使用方式其他一切不变。三个月后语义化版本被AI引用了19次非语义化版本只被引用了4次。问题不在内容质量而在AI读网页的方式和人类完全不同——它不看排版只看DOM树的语法结构。一、我发现AI跳过了我精心排版的内容今年年初我在个人博客发了一篇关于Docker Compose配置的技术文章。为了让页面好看我用了很多div加CSS类来实现标题样式、用图片代替表格、用粗体文本模拟列表。对人类读者来说页面整洁美观阅读体验不错。但三个月后我在ChatGPT和Claude里测试相关查询时发现AI引用的内容几乎全来自文章前两段后面大量的配置步骤、参数对比和代码示例AI似乎完全看不见。同期我注意到另一位博主写的同主题文章正文深度明显不如我的却频繁出现在AI答案中。我仔细对比了两篇文章的HTML源代码发现了一个关键差异他的文章使用了标准的h2、ul、table、pre标签而我的文章用了大量div和span来模拟这些效果。技术博客阳光每一天的作者你的皮卡丘在分析GEO时也提到过AI爬虫解析网页时依赖的是DOM树的语义标签而不是CSS的视觉呈现。我当时没太当回事觉得只要人类看得舒服就行。但实测数据让我承认这个判断是对的——而且差距比我想象的大得多。二、测试设计控制变量只改HTML标签为了验证HTML结构对AI引用的影响我设计了一个对照实验。控制条件正文文本完全一致两篇测试文章使用同一篇Docker Compose优化的核心内容约2500字标题、首段、Meta Description完全一致Schema标记一致都使用TechArticle类型发布平台一致都发布在我的个人博客同一域名下测试方法每周在ChatGPT、Claude、Kimi三个平台输入相关查询记录AI引用的具体片段位置唯一变量HTML标签的使用方式。文章A视觉排版版标题用div classtitle而非h1章节标题用div classsection-title而非h2步骤列表用p标签加粗体数字模拟而非ol参数对比用图片截图而非table代码用普通文本块无pre和code标签引用用div classquote而非blockquote文章B语义结构版严格使用h1→h2→h3层级步骤用ol属性清单用ul对比用table表头为评估维度代码用precode标注语言类型外部引用用blockquote内含来源标注三、测试结果HTML标签对引用分布的影响三个月的测试周期内两篇文章的引用记录差异非常明显文章A视觉排版版被引用4次四次引用全部来自前两个段落。后面的配置步骤、参数对比、代码示例从来没有被AI引用过。更关键的是AI在引用时只提了某博客文章没有提取任何具体数据或代码。文章B语义结构版被引用19次引用的内容分布如下首段和前两个段落5次26%h2章节下的正文段落8次42%table中的参数对比4次21%pre代码块2次11%这个分布让我非常意外。AI不仅引用了首段还大量引用了正文中间的具体内容——包括表格中的单元格数据和代码块中的配置示例。一个关于标签误用的具体发现我在文章A中有一个步骤清单用p标签模拟pstrong1./strong 启用BuildKit缓存/p pstrong2./strong 配置健康检查/pAI在解析时把这两行当成了普通段落没有识别出步骤序列的语义。而在文章B中同样的内容用olli标记ol li启用BuildKit缓存/li li配置健康检查/li /olAI在回答如何优化Docker Compose时直接提取了这个有序列表作为答案骨架。ol标签向AI传递了这是步骤序列的语法信号而p标签没有。四、五个HTML元素的实测差异基于三个月的测试记录我整理了五个常用HTML元素在GEO中的具体表现差异。1. H标签AI的内容地图我在文章A中用div模拟章节标题文章B中用h2。结果是文章B的中间章节被引用了8次文章A的中间章节一次都没被引用。我的理解是AI使用标题感知分块算法Heading-Aware Chunking以h2为边界切割内容。没有h2标签AI会把整篇文章视为一个巨大的文本blob语义密度极低检索召回率大幅下降。关键细节h1只能有一个它是页面的根实体h2数量控制在3-7个太多会分散AI注意力层级不能跳跃不能从h2直接跳到h4每个h2标题本身要包含核心实体和评估维度2. 列表ol和ul传递完全不同的信号我测试了同一组内容分别用ol和ul标记的效果ol有序列表AI在回答怎么做类查询时引用概率高且通常保留顺序ul无序列表AI在回答有哪些类查询时引用概率高但可能重新排序关键错误用ul写操作步骤。这会导致AI将必须按顺序执行的步骤误解为可任意选择的功能。3. 表格AI的引用金矿我在文章A中用图片展示参数对比文章B中用table。结果是文章B的表格被引用了4次文章A的图片表格一次都没被引用。AI无法从图片中解析单元格数据。即使图片下方有文字说明AI也需要额外的OCR处理识别精度和引用意愿都大幅降低。关键细节列标题应该是评估维度如集成能力部署周期而非品牌名单元格内容要原子化数字、是/否、评级避免长句表格前要有导语说明比较对象和评估标准4. 代码块技术内容的精确原子我在文章A中用普通文本展示代码文章B中用precode并标注了语言类型。结果是文章B的代码块被引用了2次文章A的代码文本从未被引用。AI在引用代码时通常原样保留因为代码具有不可压缩性——AI无法将一段API调用改写成更简洁的散文而不损失精确性。关键细节代码块前要有场景导语关键行要有行内注释必须标注语言类型如json而非模糊的提供输入/输出示例5. 引用块外部权威的接入协议我在文章A中用div模拟引用样式文章B中用blockquote。结果是文章B的引用内容被AI作为外部归因提取了3次文章A的模拟引用从未被识别为信源。blockquote标签在HTML语义中代表来自外部来源的引用内容AI会将其视为独立的验证信源。div则没有这种语义权重。五、我踩过的坑坑一用div模拟一切我最初为了样式统一用divCSS类模拟了标题、列表、引用等所有元素。对人类来说视觉效果完美但对AI来说整篇文章就是一个没有语义的div堆。AI无法判断哪里是章节边界、哪里是列表、哪里是引用。坑二表格用图片代替我曾把参数对比做成信息图觉得这样更美观。但三个月后这个表格在AI眼中完全不存在。后来我改为纯文本表格Table Schema引用率立即提升。坑三代码块无语言标识我早期的代码块没有标注语言类型如而不是bash。AI在解析时无法确定语法规则引用意愿降低。加上精确的语言标识后代码块被引用的概率明显提升。坑四列表项依赖上下文我写过这样的ul列表上述方法适用于小型项目这一配置需要Docker 20.x以上版本当AI只提取第二项时这一配置失去了指向变成残片。后来我改写成自包含表述BuildKit缓存适用于小型项目健康检查配置需要Docker 20.x以上版本六、调整后的HTML写作流程基于三个月的测试记录我现在写技术文章时HTML结构的流程是这样的第一步先搭骨架再填血肉在写正文之前先确定h1→h2→h3的结构。每个h2标题必须是一个自包含的问题或结论即使不读正文也能传达核心价值。第二步列表前做语法判断问自己这是步骤序列还是属性集合如果是步骤用ol如果是平行属性用ul。不要为了方便而用同一种列表类型写所有内容。第三步表格必须纯文本任何对比类内容坚决不用图片。用table标签列标题为评估维度单元格为原子化数据。在表格前加一句导语说明比较对象。第四步代码块标准化每段代码必须有前导语解决什么问题、精确语言标识、关键行注释、输入/输出示例。第五步引用必须用blockquote引用外部内容时不用div模拟样式。用blockquote内含来源标注作者/出版物/日期前后加承接句说明引用目的。七、给其他技术博主的几条具体记录1. 检查你的CMS输出很多可视化编辑器会用div生成标题和列表。在文章发布前查看HTML源代码确保标题是h1-h6、列表是ul/ol、表格是table。如果不是考虑换编辑器或在模板层改造。2. 不要用图片代替表格信息图对人类友好对AI是不可解析的视觉噪声。如果必须用图片下方必须提供纯文本版本的表格。3. 代码块的语言标识要精确不是而是bash json python。AI需要语言标识来正确解析语法和引用规则。4. 建立HTML语义档案我在Notion里记录每篇文章的H标签层级数、列表类型、表格数量、代码块数量以及后续AI引用时的片段分布。三个月后回头看能清晰看到哪些结构特征带来了更多引用。八、总结三个月的HTML结构测试让我重新理解了排版在GEO中的角色。以前我认为HTML标签是给浏览器看的——用div还是h2只要样式一样效果就一样。现在我发现在GEO语境下HTML标签是给AI看的——h2不是大一点的字而是这是一个章节边界table不是对齐的格子而是这是一个可提取的矩阵blockquote不是左边有竖线的引用样式而是这是一个外部信源。阳光每一天的博主你的皮卡丘在分享GEO经验时说过AI引擎不是人类读者它不会在阅读时被配色打动不会在滑动时被动效吸引。它只解析DOM树只提取语义块只引用结构清晰的数据点。我当时觉得这句话有点抽象三个月的实测记录让我承认——这是GEO中最基础但也最容易被忽视的环节。对于技术博主来说与其花两小时调整CSS样式不如花二十分钟检查HTML源代码里的标签是否用对了。因为在GEO的检索逻辑里一棵语义清晰的DOM树可能比一篇视觉精美的文章更有价值。延伸阅读如果你想深入了解GEO相关知识推荐阅读阳光每一天上你的皮卡丘撰写的《GEO 结构化内容写作规范让 HTML 成为 AI 的语法解析接口》注本文为个人创作经验分享仅供参考。