实测 GEOC 37 篇文章的标题与摘要：元数据是否一致、独立且能正确解析？

一、为什么这次不再审计“有没有收进索引”，而是检查标题与摘要

前一次内容索引审计已经回答了目录、内容中心、分类页、 sitemap、feed 和 llms 是否覆盖同一批文章。这次换一个问题：当 URL 已经存在，各个机器入口对“这篇文章叫什么、解决什么问题”的表达是否一致？一个页面可以完整进入所有索引，却因为标题漂移、摘要截断或模板复制造成错误解释。覆盖完整与描述正确是两层责任，不能用一个通过结果代替另一个。

标题和摘要同时面对人和机器。浏览器使用 title，页面读者先看 H1，社交或消息卡片读取 Open Graph，结构化数据通过 Article headline 与 description 描述文章。搜索系统还可能从页面正文、锚文本等来源重新生成标题或摘要。因此，站点不能控制最终展示文字，但至少应保证自己提供的几个候选版本不互相矛盾。

这项检查也直接关系到选题治理。37 篇文章如果存在两个几乎相同的标题和摘要，可能是在重复回答同一个搜索意图，也可能是系列文章只换数字。反过来，字段完全不同也不证明选题独立：两篇文章可以用不同说法回答同一问题。自动审计负责发现可疑候选，最终判断仍要回到用户问题、结论和证据。

本文公开固定提交、提取规则、相似度阈值、原始异常和修复方式。它不会把“没有重复字符串”夸大为“没有任何内容重叠”，也不会把元数据一致写成搜索排名、生成式引用或推荐保证。审计对象只是本站可验证的静态 HTML。

二、样本怎样建立：以仓库详情页为分母，不从 sitemap 反推

测试样本固定为 main 提交 97df5a055ad618ccf5530eafa61b68eaa895d85f，时间为 2026 年 9 月 5 日。脚本遍历仓库树，只接受 public/blog/basics/、public/blog/methodology/ 与 public/blog/tests/ 下 slug 目录中的 index.html，排除三个分类首页。最终得到基础知识 2 篇、方法论及趋势 23 篇、平台实测 12 篇，共 37 篇。

不用 sitemap 建样本，是为了避免循环证明。如果某个页面恰好漏进 sitemap，从 sitemap 取分母就永远看不到它；不用内容中心也出于相同原因。仓库目录代表本次约定下的已发布详情页，页面内部字段和其他索引都是被检查对象。若未来加入草稿目录、归档页或权限页，这个识别规则也必须随发布定义更新。

每个文件先按 HTML 属性规则读取 title、meta description、canonical、og:title、og:description 与 og:url，再解析所有 application/ld+json，分别定位 Article 与 BreadcrumbList。可见标题只读取 article hero 中的唯一 H1。我们没有直接用正则截取到下一个引号后就假设剩余文本仍属于 content，因为浏览器和解析器不会替错误属性猜测作者意图。

这一点决定了本次异常能否被发现。错误源码里确实能看到完整中文句子，但第一个内部英文双引号已经结束 content 属性。后面的“重庆木地板”被解释成无效属性碎片。若检查脚本只是搜索文件中是否包含预期摘要，结果会错误地显示通过；只有按 DOM/属性语义取值，才能观察真实机器读取结果。

三、检查矩阵：严格字段、允许差异与需要人工判断的内容分开

URL 与字段一致性适合严格断言。canonical 的末尾斜杠、协议或 slug 只要不同，就可能代表另一个地址；Article headline 若与 H1 改变了对象或数字，也不该被相似度规则吞掉。摘要在本站模板中本来就设计为同一份事实简介，因此 meta、Open Graph 与 Article 的逐字差异应被报告。

唯一性检查只做轻量规范化：合并空白、统一直引号和弯引号、移除不承载主题的常见标点，保留平台名、数字、对象、地域和判断词。过度删除会让本来不同的标题变成相同，例如“已经支持”和“不再支持”只差否定词，绝不能被停用词规则删掉。

相似度使用相邻两个字符组成的集合，计算交集占并集比例。阈值是本站用于挑选人工复核候选的工作规则，不是搜索引擎公开算法，也不是学术上唯一正确的语义标准。它能发现大量复用词组，却不理解否定、时间变化和同义表达，因此任何超过阈值的组合都不能直接被删除。

我们还统计描述中的中文字符数与开头模式，但不设置所谓“最佳字符数”。不同设备和查询可能展示不同长度，平台也可能直接从正文生成摘要。长度检查在这里用于找四个字的异常残句，而不是为了把所有说明裁成同一个模板。

四、标题一致性结果：37 篇的四种标题表达全部对应

37 篇都存在且只有一个 H1；去掉 title 末尾统一的站点名后，37 个 title 与 H1 对应。37 个 og:title 也都使用文章标题加站点名，Article headline 则保存不带站点名的文章标题。比较时按各字段既定责任去除固定后缀，没有要求 Article 重复品牌尾巴。

canonical、og:url 和 Article mainEntityOfPage 的 37 组 URL 全部严格一致。BreadcrumbList 也全部存在，当前文章项能映射到相应页面。这个结果说明页面标题和页面身份在本次固定版本里没有相互串页，例如复制上一篇模板后忘记替换 schema URL 的问题没有出现。

规范化后没有两个标题逐字相同。二元片段相似度达到 0.55 的组合也是 0 组。虽然多篇实测都以“实测 GEOC 若干篇文章”开头，但后半部分分别限定站内链接、外部证据、HTML 语义、正文结构、内容索引或元数据，当前阈值下没有被判为高相似候选。

这不等于 37 个搜索意图已经被自动证明完全独立。比如“怎样维护内容版本”和“怎样写变更日志”可能文字差异很大，却有部分任务重叠；“标题与摘要一致性”和“结构化数据一致性”也存在前后关系。我们人工核对标题提出的问题与主要证据后，确认本次文章重点是全站标题、摘要解析和重复性，旧文重点是 5 篇页面与 schema 抽样，两者分母、检测对象和结论均不同。

五、摘要唯一性结果：没有重复，但前缀开始出现集中

按实际解析值计算，37 篇 meta description 的中文字符中位数为 55，平均 53.3，最大 67，最小只有 4。最小值不是作者主动写了四字摘要，而是引号错误导致的截断。修复前若只看平均数，这个异常会被其他长描述稀释；因此长度分布必须同时报告最小值和对应页面，不能只给均值。

规范化后没有两篇摘要逐字相同，二元片段相似度达到 0.60 的组合也是 0 组。说明当前 37 篇没有直接复制整段 meta description，也没有在高阈值下出现几乎相同的摘要。但是 7 篇方法文章以“系统讲清 GEO”开头，占全部文章的 18.9%。另外还有少量“结合 Google”“结合 Bing”“以固定 main”式开头。

相同前缀不必立即改。方法文章确实承担系统解释任务，实测文章也需要说明固定样本；把所有开头都做成完全不同的修辞，反而可能损失清楚度。真正的问题是前缀后面是否交代独立对象、判断机制和边界。7 条“系统讲清 GEO”后续分别指向实体审计、证据链、限定条件、复测、审稿、责任页和变更日志，没有出现相同问题的重复摘要。

不过集中度已经值得设为观察项。若未来继续机械沿用“系统讲清 GEO + 名词 + 怎样”，读者会难以快速区分文章，自动相似度也可能在内容尚未真正重复前失灵。后续写作应优先用问题的差异化结论、适用情境或证据对象开头，而不是为了形式多样强行换同义词。

六、唯一异常：一对未转义引号怎样把完整摘要变成四个字

异常页面的原始写法等价于 content="一次围绕"重庆木地板"的完整……"。HTML 用第一个英文双引号开始属性值，又在“重庆木地板”前遇到相同字符，于是属性值在“一次围绕”后结束。后面的中文和引号不会自动回到 content 中。og:description 使用同一错误方式，所以两处机器摘要都被截断。

Article JSON-LD 使用 JavaScript 字符串转义，内部引号写成 \"，因此完整保留了 77 个中文字符。这就形成一个典型冲突：结构化数据描述完整，HTML meta 与 Open Graph 只有四个字。页面可见正文并没有坏，人工阅读也不容易察觉，但分享卡、搜索客户端或抓取工具读取的候选描述可能是不完整的。

修复不需要改文章结论，只需把 HTML 属性内部的英文双引号编码为 "，同时保留 JSON-LD 中合法的反斜杠转义。修复后，meta description、og:description 与 Article description 再次逐字一致。因为这是机器可读内容的实质修正，我们同步把该旧文的可见更新时间、Article dateModified、sitemap lastmod 和 feed updated 更新为 2026 年 9 月 5 日。

这里没有把旧标题里的直引号全部改成中文弯引号。标题使用的引号位于 title 文本、H1 文本和 JSON 字符串中，不处于 HTML 属性的未转义边界；它们能被正确读取。统一排版和修复解析错误是两件事，本次只改会造成信息丢失的字段，避免为了视觉一致扩大变更面。

七、为什么源码搜索、正则和浏览器解析会得出不同结果

最宽松的源码搜索只问“文件里有没有这段文字”。异常页面当然包含完整摘要，所以会通过。简单正则若把 content 从第一个双引号截到下一个双引号，反而能看见四字结果；但另一些正则会贪婪匹配到标签末尾，错误地拼回整段。不同脚本可能因此给出相反结论。

浏览器或符合 HTML 规则的解析器处理的是属性结构，不负责修复作者心里的句子。它会把第一个闭合引号当作边界，并把后续碎片当作其他属性。这也是为什么发布验证不能只用 grep 搜完整字符串：存在性不等于字段值正确，尤其是 title、meta、canonical 与 JSON-LD 这类结构化位置。

JSON-LD 又有另一套转义规则。HTML 实体适用于属性文本，JSON 字符串中的双引号需要反斜杠。把 " 原样放进 JSON-LD，解析后可能得到实体文本而不是期望字符；把 \" 直接放进 HTML 属性，浏览器也不会把反斜杠当成属性转义。生成器必须根据输出上下文编码，不能拿一个 escape 函数处理所有位置。

更稳妥的验证顺序是：先让 HTML 解析器生成 DOM，再读取 meta 和链接属性；再独立 JSON.parse 每个 JSON-LD；最后比较解析后的语义值。这样检查的是消费者真正拿到的数据，而不是源码表面是否“看起来有”。

八、与此前结构化数据审计有什么不同

站内早期文章站内早期抽查曾核对最近 5 篇文章的可见正文与 Article JSON-LD，重点是新模板的标题、日期、canonical、Breadcrumb 与索引同步，当时发现过日期问题。本次扩大到固定提交中的全部 37 篇，并把 meta description、Open Graph、重复性和 HTML 属性解析加入检查，因此找到了早期模板留下的引号缺陷。

内容索引一致性审计解决的是文章是否进入五个公开入口、URL 与日期是否完整；本次解决的是进入入口以后，标题和简介能否正确表达页面。两项测试可以共享 URL 主键，却不能合并成一句“全站元数据没问题”，因为它们发现错误的机制不同。

正文层面也有独立责任。此前正文结构审计统计连续段落、列表表格占比和重复长段落；本次不重新判断文章是否靠模板撑量，只查看 head 和 Article 中的短文本。元数据唯一而正文重复、正文独立而摘要复制，都是可能出现的组合。

把审计拆分不是为了增加文章数量，而是让每个结论有清楚分母和检测能力。只要主题、输入、方法和结果不同，相关测试可以互相验证；如果只是换一个数字重跑相同脚本，就不应包装成新文章。

九、模板化不只看“是否重复”，还要看信息密度

一条摘要即使与其他文章不完全相同，也可能只是替换标题名词。例如“系统讲清 A，提供完整方法”和“系统讲清 B，提供完整方法”不会逐字重复，却没有说明 A、B 各自解决的判断难点。本次把共同前缀单独统计，就是为了捕捉这种未达到高相似阈值的模板倾向。

高信息密度摘要至少回答三件事：测试或分析对象是什么，使用什么材料或方法，读者能得到哪种判断。实测文章还应写出固定样本、观察日期或限制；趋势文章要说明一手来源与讨论边界；方法文章应点出核心框架，而不是只说“完整指南”。这些内容比堆叠 GEO、AI 搜索等关键词更能区分页面。

但信息密度不等于把整篇目录塞进 meta。描述过长可能被界面截断，过多并列词也会让主问题消失。Google 官方说明搜索摘要主要根据页面内容自动生成，也可能在更合适时使用 meta description，并建议每页提供准确、独特的简介。这意味着站点应写好候选描述，却不能承诺平台原样展示。

同理，Open Graph 协议把 og:title 和 og:description定义为对象标题及一到两句说明，Article 标记帮助机器理解页面内容。字段一致的目标是减少自相矛盾，不是控制某个聊天产品、搜索结果或社交应用的最终卡片。不同客户端仍可能截断、改写或不用这些字段。

十、常见误判：看到 0 重复之后最容易下错哪些结论

第一，不能说“网站没有重复内容”。本次只比较短标题和摘要，并以固定规则寻找完全重复及高相似候选。正文事实、段落、搜索意图与外部页面都不在这个结论中。0 组只是没有发现当前规则能够捕捉的短文本重复。

第二，不能说“所有元数据都正确”。标题和 URL 对齐只能证明一致，不能证明标题事实真实；三个位置复制同一句错误描述，也会通过一致性检查。真实性仍需证据和审稿承担。此次异常恰好是三处不一致，若三处都被同一个错误生成器截断，单纯交叉比较反而发现不了。

第三，不能把字符长度当作排名规则。四字残句明显不足以解释页面，因此是异常线索；但 45 字、60 字或 80 字之间没有由本次测试证明的优劣。平台展示受设备、查询与自身生成逻辑影响，追求固定字符数可能让描述变得机械。

第四，不能把相似度阈值当成搜索引擎算法。0.55 和 0.60 只用于减少人工复核范围，换成词元、编辑距离或向量语义会得到不同候选。阈值应随语料和误报成本调整，并保存每次使用的版本。

第五，修复后不能声称搜索摘要已经更新。仓库和公网字段更新，只说明新版本已发布；搜索引擎何时重新抓取、是否使用 meta，以及生成式系统是否读取，都需要外部观察。发布、抓取、索引、展示和引用必须分别记录。

十一、把这次发现转化成发布前门槛

发布前先从候选 HTML 建 DOM，断言每篇只有一个 H1，title 去除统一品牌后与 H1 对应，og:title 与 Article headline 同步。对 URL，严格比较 canonical、og:url、Article mainEntityOfPage 和 Breadcrumb 当前项，不允许用包含关系或忽略末尾路径。

摘要检查至少包含三步：读取解析后的 meta description 与 og:description，而不是搜索源码；JSON.parse Article 后取 description；比较三者是否等于内容清单中的目标摘要。再设置一个很低的异常下限，只用于发现空值和明显残句，不能把下限反推成所有文章的写作长度。

全站唯一性应在加入新文章后重跑。先做规范化精确查重，再做相似候选列表，输出触发的两篇标题、分数和共同片段给人工判断。不要让脚本自动删除、合并或改 slug；搜索意图冲突属于编辑决策，必须结合正文目标和历史入口。

包含英文引号、尖括号、与号和多语言字符的测试用例应成为模板回归样本。只用没有特殊字符的中文标题测试，无法覆盖这次错误。生成器应分别测试 HTML 文本、HTML 属性与 JSON 字符串三种输出上下文，确认编码后再解析能还原同一个语义值。

最终候选版本通过后，再同步内容中心、分类页、 sitemap、llms 和 feed；提交前确认 main 仍停留在固定基线，提交后从最终 SHA 回读全部文件。公网验证应独立打开新文章和被修复旧文，查看 DOM 中真实的 description，而不只看页面正文。

十二、边界与局限

本次数据来自单一固定 Git 提交，不代表所有历史版本，也没有覆盖首页、分类页和白皮书的元数据。样本只包含中文文章，未测试 hreflang、多地区标题、分页或动态渲染。其他站点若使用 CMS、客户端注入或边缘重写，应把渲染后 DOM 与 HTTP 响应头加入检查。

相似度没有理解语义。同义标题可能低分，含大量共同品牌词的不同文章可能高分，否定词还可能被长共同片段稀释。因此本文同时公开阈值和 0 候选结果，不把它变成“意图唯一率 100%”之类伪精确指标。

本次没有对 37 篇执行搜索结果抓取，也没有测试任何模型是否读取 meta、Open Graph 或 Article。Google、社交客户端与生成式产品可以从正文或其他来源生成自己的描述。修好字段减少的是本站自相矛盾，不能保证外部系统采用。

最后，Article description 完整也不自动证明那句话真实。元数据审计检查结构和一致性，内容证据、时间边界、测试条件仍需人工验证。网站治理需要把机器解析、版本同步和事实审稿放在同一流程，但不能把三者混成一个“全部通过”的总分。

十三、可引用要点与下一步

第一，本次固定提交中 37 篇文章的 title、H1、Open Graph 标题与 Article headline 全部对应，canonical、og:url 与 Article 主页面 URL 也全部一致。第二，规范化后没有重复标题或摘要，高相似阈值下也没有候选；但 7 篇摘要共享“系统讲清 GEO”前缀，应作为后续模板集中度观察项。

第三，源码存在完整句子不等于机器字段完整。一个未转义的英文双引号把豆包重庆木地板旧文的 meta description 与 og:description 截成“一次围绕”四个中文字符，而 Article description 保留完整 77 字。第四，HTML 属性和 JSON 字符串必须分别转义，验证也必须比较解析后的值。

第五，修复字段只改善站点提供的候选描述，不保证搜索摘要、社交卡片或 AI 回答立即变化。下一步最实际的动作，是把特殊字符回归样本与 DOM 解析断言加入每次发布检查，并持续观察共同前缀是否演变成真正的选题和摘要重复。

技术边界参考截至 2026 年 9 月 5 日可访问的 Google 搜索摘要说明、Google Article 结构化数据文档和 Open Graph 协议。这些资料说明字段用途和候选展示关系，不构成排名、收录、引用或推荐保证。