Astro 7重写全部页面，IndexNow改为按爬虫内容哈希

工具链升级让整站 HTML 逐字节变化，但页面内容一个字没改——这种情况下，IndexNow 该不该通知搜索引擎"全站更新"？NeuraGrowth 的答案是：不该。他们把 IndexNow 的判定逻辑从"文件字节哈希"换成了"爬虫可读内容哈希"，并记录了一次 Astro 7 升级引发的误报风波。

一次 Astro 7 升级，为何会触发 273 次误报

据 NeuraGrowth 技术日志，Astro 7 升级后重写了站点上每一个已构建页面，但页面文案没有任何变化。变化发生在构建产物层面：新的 scoped-style id、重新压缩的脚本，以及旧输出中的 & 被替换成了 &。同一天，共享 CSS 文件也因为新模块加入其 chunk 而被重命名。

这些改动对渲染结果几乎无感，却让文件的字节表示完全翻新。而当时 NeuraGrowth 的 IndexNow 脚本，正是通过哈希文件字节来判断哪些页面需要通知搜索引擎。按照这个逻辑，上述每一处构建层面的差异都会被判定为"页面已更新"，结果是全部 273 个页面都会被重新推送。

这正是脚本最初设计想要避免的"狼来了"场景：通知发得越频繁，搜索引擎对信号的信噪比评估就越低，真正的内容更新反而可能被淹没。据日志描述，这次 Astro 7 部署后，脚本状态不得不手工重新播种（reseeded by hand）。

IndexNow 是什么。 IndexNow 是一套由微软 Bing 与 Yandex 联合发起的开放协议，允许站长通过一个简单的 HTTP 请求，主动告知搜索引擎某个 URL 的内容已新增、更新或删除。相比传统的 sitemap 轮询或等待爬虫自然回访，它把"发现变更"的延迟从数天压缩到分钟级。协议本身对"如何判定内容变化"不作规定，只接收 URL 与一个校验用的 key，因此判定逻辑完全由站长一侧实现——这正是 NeuraGrowth 误报问题的根源所在：判断标准选错，通知就会失准。

为什么"哈希"被用来做变更检测。 哈希函数能把任意长度的输入压缩成固定长度的指纹，输入只要有一个字节不同，输出就会面目全非。工程上常用它来判断"两次构建之间某个文件是否变化"：把上一次的哈希存下来，下次构建后重新计算并比对，不同就说明文件变了。这种做法实现简单、成本极低，但代价是它衡量的是"字节表示"，而非"内容语义"。构建工具只要调整压缩策略、模块切分或转义方式，字节指纹就会全部刷新，而用户和爬虫看到的东西毫无二致。

新方案：只哈希爬虫真正读取的内容

2026 年 10 月 8 日，NeuraGrowthHTML 上线了一项改动：IndexNow 改用"爬虫可读内容"进行哈希，而不再哈希文件字节。

具体来说，新的摘要保留以下内容：正文文本、链接、HTML 属性、title、meta 标签以及 JSON-LD 结构化数据。被排除在外的包括：其他脚本、样式、scoped-style id、构建产物名、generator 标签，以及标签之间的空白字符。

这套取舍的核心判断标准是"这段差异会不会影响爬虫对页面的理解"。scoped-style id 和构建产物名属于实现细节，爬虫不会因为类名变化而认为页面主题变了；而 title、meta 和 JSON-LD 直接影响索引和富摘要，必须纳入摘要计算。据原文说明，这次改动累计涉及 3 个文件，新增 106 行、删除 7 行——体量不大，但解决了一个会随构建工具升级反复出现的问题。

代码改动之外，这次事件还给出了一个更普适的原则：

如果你要通知搜索引擎页面发生了变化，请哈希爬虫读取的内容，而不是文件字节，因为一次工具链升级可能重写每一页的每一个字节，却没有改动任何一个字。

JSON-LD 与结构化数据。 JSON-LD（JavaScript Object Notation for Linked Data）是一种用 JSON 语法表达 Schema.org 词汇表的格式，通常以 <script type="application/ld+json"> 内联在页面中。它用机器可读的方式描述"这个页面是什么"——是文章、产品、FAQ 还是活动，附带作者、发布时间、价格、评分等字段。搜索引擎据此生成富摘要（rich results），例如搜索结果里的星级评分、面包屑或问答折叠。由于它内嵌于 <script> 标签，粗看像是"脚本"，但它的内容直接决定索引展现，因此必须纳入摘要计算；而普通的业务脚本只影响交互，不影响爬虫理解页面主题，故被排除。这一区分是"爬虫可读内容"口径中最容易被误判的一处。

HTML 转义与实体编码。 原文提到的 & 与 & 之间的差异，属于 HTML 字符转义问题。& 是 HTML 实体，渲染后显示为一个 & 符号。转义层数不同会造成源码字节完全不同，但浏览器渲染结果一致。这类"源码变了、渲染没变"的情况，正是字节哈希容易踩坑、而内容哈希能自动免疫的典型例子。

这个思路对哪些场景有效

将哈希对象从"文件字节"切换到"语义内容"，本质上是把"变化检测"的粒度从构建层上移到内容层。

适用场景包括：使用 Astro、Next.js 等会重新生成静态产物的框架；站点启用了自动压缩、代码分割或 CSS 模块化；以及接入了任何以文件指纹为判断依据的增量通知流程。这些情况下，字节级差异几乎是必然事件，而非异常。

需要注意的是，这种做法的前提是"爬虫可读内容"的解析足够稳定。如果爬虫规范化 HTML 的方式与脚本自身的解析器不同，摘要结果可能出现偏差。此外，某些确实影响展现的变化——例如内联样式调整导致的视觉布局变化——在"只看爬虫可读内容"的口径下会被忽略，这属于有意为之的取舍，而非遗漏。

内容哈希需要先做规范化。 要让"爬虫可读内容哈希"稳定可复现，脚本必须先把 HTML 归一化：剥离被排除的标签与属性、合并连续空白、统一属性顺序与大小写。这本质上是在实现一个精简版的 HTML 规范化器，而它的行为需要与主流爬虫的解析方式大体对齐。若脚本与爬虫对同一份文档的解析结果不同——例如对隐式闭合标签、重复属性的处理存在分歧——哈希就可能与实际索引状态错位，导致该通知的没通知、不该通知的发了。因此这类方案的可靠性，取决于规范化规则是否覆盖了站点实际用到的语法特性。

一个单人工作室的工程取舍

NeuraGrowth 是一个单人运营的数字产品工作室，这篇日志本身就是其流水线的一部分。从这次改动可以看出一条务实的工程路线：不追求完美的变化检测，而是把判定标准对齐到真正影响下游系统（搜索引擎索引）的那部分内容。

这种做法也有边界。当站点内容由 CMS 驱动、构建产物稳定时，字节哈希与内容哈希的差异不大；只有当天平两端——构建噪声与内容信号——差距被工具链放大时，这种切换才体现出价值。NeuraGrowth 的案例说明，静态站点生成器的版本升级，正是这种差距被放大的典型时刻。