事实层的两种失败：一是该藏的漏出去（供应商名、出厂价通过公开仓库、Git 历史、前端 bundle、图片 EXIF、PDF 属性等路径泄露），判据是"客户拿到这条信息能不能绕过你"；二是该更新的放过期（证书失效、报价过期、型号停产）。共同解法是用架构代替纪律——靠记性维持的规则必然失守，要让内部数据物理上不在能被发布的位置，并把"页面与事实层不一致"定性成 bug。

事实层的两种死法：漏出去，和放过期

建一个产品事实层不难。难的是它半年后还准不准、还安全不安全。

从结果看，事实层只有两种死法：

• 漏出去：本该只在内部的东西跟着上线了
• 放过期：本该更新的东西没更新，页面上挂着已经不成立的信息

这两件事看起来一个是安全问题、一个是运维问题，但它们的解法是同一条：

**用架构代替纪律。**凡是靠“记得别写进去”“记得去更新”维持的规则，时间长了一定失守。

第一种死法：漏出去

为什么这件事在静态站上特别反直觉

先说风险有多实。你的事实层里有两样东西是生意的命门：

• 供应商名和工厂地址：客户拿到，可以直接找厂谈，绕过你
• 出厂价：客户拿到，你的议价空间归零

大部分人的防线是“我没把这些放到页面上啊”。问题是发布路径不只有页面这一条。

这八条的共同特征是：它们都不在你正在编辑的那个页面里。 所以任何形式的“发布前看一眼页面”都发现不了。

判据：客户拿到这条信息，能不能绕过你

要决定一条信息该不该藏，不需要一份分级清单，问这一句就够：

客户拿到这条信息，能不能绕过你？

这条判据比字段清单好用的地方在于：碰到清单上没有的新信息，你自己能判断。

比如“我们合作的工厂通过了 ISO 9001”——工厂名不能说，但“合作产线通过 ISO 9001”这句话本身客户绕不过你，而且有说服力，属于该公开的。

用架构代替纪律

知道该藏什么之后，问题变成怎么保证藏得住。这里有三个层次，前两个都不够。

层次一：靠记性。 “我记得不要把供应商名写进公开文件。” 这个在你一个人、每周上一两个产品的时候有效。等到某天赶一批货、同时上十个型号、还让 AI 帮着批量填数据，它就失效了。任何靠记性维持的规则，都会在最忙的那一天失守——而那天恰恰是出错代价最高的一天。

层次二：发布前过滤。 写个函数，把不该公开的字段过滤掉。这比靠记性好，但有个隐患：新增字段默认是被过滤掉还是被放出去？

这是个架构选择，两种写法差别巨大：

❌ 黑名单：删掉 supplier_name、cost、moq 这几个字段
   → 明天新增一个 factory_contact 字段，它默认被公开

✅ 白名单：只输出 model、specs、certs、images 这几个字段
   → 明天新增任何字段，默认不公开

黑名单要求你每次新增字段时都记得去更新黑名单——又回到靠记性了。白名单让“忘记”这个行为的默认结果是安全的。

这是本篇最该带走的一条设计原则：让默认行为是安全的，而不是让正确行为依赖记性。

层次三：物理隔离 + 自动闸门。 这才是能长期成立的做法：

1. 内部数据不放在构建能读到的地方。 单独目录、不进公开仓库（或放独立的私有仓库）。这样“不小心引用到”在物理上就不可能发生
2. 公开视图用白名单生成，只显式列出可公开字段
3. 发布前扫成品：在最终产物里搜一遍内部标识（内部编号前缀、几家供应商名、成本字段名），命中就让发布失败

第 3 条是关键的兜底。前两条防的是“写错”，第 3 条防的是“通过你没想到的路径漏出去”——包括被打进 bundle、被序列化进 HTML 这些你不可能靠肉眼发现的路径。

关于 Git 历史：如果内部数据已经进过公开仓库，改掉当前版本是没用的，历史里还在。这种情况只能重写历史或者换仓库，而且要假设已经泄露过。这也是为什么内部数据从第一天起就不该进公开仓库——这个错误是不可逆的。

反过来的平衡：藏关系不藏能力

讲到这里有个风险：读者会走向另一个极端，把什么都藏起来。什么都不说的产品页，客户不信，Google 也不信。

平衡点是一句话：藏关系，不藏能力。

“不说是哪一家”和“把产线情况讲得很具体”完全不矛盾。你可以写“我们对接的产线具备 SS316 与双相钢铸造能力，出厂前按 ISO 9906 Grade 2 做水力性能测试”——这段话信息量很足，专业买家看得懂，但里面没有一个字能让他绕过你。

这一点和信任体系建设、EEAT 与知识图谱讲的是同一件事：透明度要花在能力上，不是花在供应链上。

别忽略最新的一条泄露路径

现在多了一条以前不存在的路径：把整份内部资料贴给云端模型。

图省事的做法：把含成本和供应商名的整张表格贴进对话，让 AI 帮你整理成产品页。数据就这样出去了。

这件事不需要一刀切禁止，但要事先想清楚界在哪：

• 可以给：产品参数、认证、公开的技术资料（这些本来就要公开）
• 给之前先脱敏：需要 AI 处理但含内部字段的表格，先把成本和供应商名换成代号
• 不要给：完整的供货关系表、报价单原件

用代号是个很省事的办法：AI 只看到 SUP-A、SUP-B，它照样能帮你做对比和整理，而它拿到的信息里没有一个真实厂名。

第二种死法：放过期

三类腐烂，后果完全不同

第二种死法更常见，也更容易被容忍——因为它不会突然爆，只是慢慢让整个事实层变得不能信。

优先级最高的是第一类。参数写错了是商业纠纷，证书过期还在宣称合规是另一个性质的问题——它在欧盟属于虚假合规声明，可能触发市场监管，而且这种事一旦被竞争对手举报，处理起来非常被动。

维护节奏按腐烂速度定，不按日历定

大部分人的维护计划是“每月检查一遍”。这种计划的寿命是两个月。

第一个月你认真查了，发现基本没变化；第二个月草草扫一遍；第三个月就跳过了。原因很简单：每月全量检查里，绝大部分是在检查根本没变的东西（参数三年不变，你每个月看它一次）。做无效劳动的流程一定会被放弃。

正确的做法是让每一类信息按自己的腐烂速度触发：

这样一来你每个月真正要处理的只有几条，而不是几百条。能被坚持下来的维护流程，特征是它只让你处理真的变了的东西。

这套东西怎么自动化成定期任务，可以接SEO/GEO 运营自动化那篇的做法。

把「页面和事实层不一致」当 bug，不当瑕疵

事实层建起来之后，会出现一种新的错误类型：两边不一致。有四种：

关键不在于列出这四种，而在于怎么定性它们。

如果你把它们叫做“资料没同步”，它会永远排在待办清单最后一行——因为听起来不紧急。如果你把它们叫做 bug，性质就变了：bug 是要修的，bug 是可以被自动检出的，bug 数量是可以被追踪的。

同一件事，定性不同，命运完全不同。这不是文字游戏，是让一件本来没人负责的事变成有人负责。

第三种错配值得多说一句：发现页面被手改过之后，只把数据改回来是不够的。要问为什么有人绕过事实层直接改页面——通常答案是“走事实层太麻烦”。那就是流程问题，不修流程的话下个月还会发生。

停产不等于删页面

最后一个具体但很容易做错的动作。

一个型号停产了，直觉反应是把页面删掉。别删。

那个页面可能已经积累了几个月的排名、几条外链、若干进站流量。这些是资产，删掉页面等于把资产扔了，而且会给访客留下 404。

正确的下线动作是三步：

1. 在页面上明确标注停产，别让客户询价之后才知道
2. 给出替代型号，链接过去。停产型号的搜索流量是真实需求，把它导到能卖的东西上
3. 把地址导向新页面（301 永久跳转），让积累的权重转移过去

跳转目标的选择：有对应替代型号就跳型号页，没有就跳所属品类页。这一步的权重传递逻辑和内链架构、权重回流那两篇是一致的。

顺带一提，这也是为什么事实层里的型号状态要有“停产”这个值，而不是把记录删掉。记录删了，你就不知道站上那个页面对应的东西已经不存在了——第二种错配也就永远检不出来。

落地要点

• 内部数据放在构建读不到的位置，从第一天起就不进公开仓库（这个错误不可逆）
• 公开视图用白名单生成，让“忘记更新规则”的默认结果是安全的
• 发布前扫最终产物里的内部标识，命中即失败
• 图片清掉拍摄信息，文件名别带厂名；规格书 PDF 出公开版，改掉属性里的作者
• 给云端模型看内部表格前，先把厂名和成本换成代号
• 每类信息按自己的到期日触发提醒，不做每月全量检查
• 四种错配定性成 bug，做成可自动检出的对账
• 停产走「标注 + 替代型号 + 301」，不删页面

隔离目录结构、白名单投影写法、发布前自查脚本、一致性对账清单、按腐烂速度排的维护日历，都在产品事实层工具箱里。这一篇还可以接网站安全维护那篇的巡检清单一起做。

小结

漏出去

• 泄露路径大多不在你正在编辑的页面里：公开仓库、Git 历史、前端 bundle、组件属性、站点地图、图片 EXIF、PDF 属性、贴给云端模型
• 判据：客户拿到这条信息，能不能绕过你？
• 三个层次里只有第三个成立：靠记性 ❌ → 发布前过滤（黑名单仍靠记性）⚠️ → 物理隔离 + 白名单 + 自动扫产物 ✅
• 核心原则：让默认行为是安全的，而不是让正确行为依赖记性
• 平衡点：藏关系，不藏能力。透明度花在能力上，不是花在供应链上

放过期

• 三类腐烂：过期（合规风险，最严重）/ 失效（亏钱失信）/ 消失（询盘白跑）
• 维护节奏按腐烂速度定，不按日历定。每月全量检查的流程活不过两个月
• 四种错配要定性成 bug，不是“资料没同步”；参数被手改过是流程问题，不只是数据问题
• 停产不删页面：标注 + 替代型号 + 301，权重是资产
• 事实层的价值不在建起来那天，在半年后它还准不准

→ 配套资源：产品事实层工具箱（Schema + 提示词 + 脚本 + 清单）