网站内链建设，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1ac0332554f0.html
📄
网站内链建设，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回的内链结构正常、但边缘节点返回的 HTML 出现链接缺失、指向错误或缓存了旧版本时，要保留的证据不是“源站没问题”这句话，而是能同时证明源站输出与边缘输出差异的三组材料——带时间戳的源站响应、同一时刻的边缘响应、以及两者之间的请求标识与缓存状态。缺少任何一组，后续排查都会退回到猜测。
下面用一个假设情境串起整个判断过程。假设某站点把内链模块放在服务端模板里，源站直连时每个栏目页都带齐了相关阅读链接；但通过 CDN 访问时，部分区域的页面只剩主导航，相关阅读整块消失。常规做法（清理站点缓存、重新提交站点地图、检查 robots.txt）都做过了，问题仍在。这时要处理的遗漏条件，是“边缘节点返回的 HTML 与源站不一致”，而不是内链规则本身。
第一步：把源站响应固定成可对比的基线
源站正常不等于源站输出已被记录。要在同一时间窗口内，分别向源站和边缘发起请求，并保存完整响应，而不是只截图页面。需要留下的字段包括：请求的完整 URL、请求时间（精确到秒）、响应状态码、响应头中的缓存相关字段、以及响应体的原始 HTML。
关键动作是：对同一个 URL，先绕过边缘直连源站取一份 HTML，再经边缘取一份 HTML，两份都存成文件。结果如何影响下一步——如果两份 HTML 的链接部分逐字一致，说明问题不在边缘返回内容，应转向检查边缘是否对特定地区或特定 UA 返回了不同版本；如果不一致，就进入下一步，对比差异具体落在哪些链接上。
这一步的证据价值在于：它把“源站正常”从一句判断变成了可复现的文件对比。没有这两份文件，后面所有关于缓存、回源、节点分发的讨论都没有锚点。
第二步：保留能区分“缓存旧版”与“节点改写”的证据
边缘异常有两种常见成因，需要靠证据区分，而不是靠感觉。第一种是边缘缓存了旧版本的 HTML，源站早已更新；第二种是边缘节点对响应做了改写或拼接，导致链接被剥离。两者的处理方向完全不同。
- 如果是缓存旧版：边缘响应的 HTML 会与源站历史版本一致，且响应头里通常带有能反映缓存命中与年龄的字段。此时要保留的是响应头原文和响应体哈希，用来证明“这份 HTML 不是当前源站输出”。
- 如果是节点改写：边缘响应里会出现源站从未输出过的结构，比如链接被替换、属性被删除、或注入了额外脚本。此时要保留的是源站响应体与边缘响应体的逐段差异，标出被改动的具体链接。
可区分原因的证据是：把源站当前 HTML、源站历史 HTML、边缘当前 HTML 三者放在一起。如果边缘 HTML 等于源站历史版本，倾向缓存问题；如果边缘 HTML 不等于任何一个源站版本，倾向改写问题。这一步的结论直接决定下一步是去调整缓存刷新策略，还是去核查边缘的转换规则。
第三步：记录请求标识，让证据可被第三方复查
只有两份 HTML 还不够，因为对方可能无法确认这两份响应来自同一次请求链路。要保留能让别人复现同一路径的标识：请求 ID、边缘节点标识（如果响应头中提供）、以及发起请求时使用的 UA 与地区信息。
实际操作是：在发起源站请求和边缘请求时，使用相同的 URL 和相同的 UA，并记录两次请求各自返回的请求标识。如果响应头中带有可用于追踪的 ID，把它一并保存。结果如何影响下一步——如果边缘响应的请求标识与源站响应的标识无法对应，说明两次请求可能走了不同链路，需要重新在同一链路条件下取样，否则对比结论不成立。
这一组证据的作用是让“我这边看是好的”这类争论变成可核对的事实。它不保证问题立刻解决，但能避免排查在“谁看到的才是真的”上打转。
第四步：把内链差异落到具体链接和具体路径
内链异常的证据必须落到链接级别，而不是“页面少了几个链接”。要输出一份差异清单，逐条列出：源站有而边缘没有的链接、边缘有而源站没有的链接、以及两边都有但指向不同的链接。每条都要带它在页面中的位置（例如某个容器或某个区块）。
假设情境中，差异清单可能显示：源站的相关阅读区块包含 6 条内链，边缘返回的同一区块只包含 2 条，且这 2 条的 href 指向了旧路径。这份清单的价值在于，它把问题范围从“内链建设异常”缩小到“某个区块在边缘被截断或替换”。下一步就可以只针对这个区块的渲染与缓存规则取证，而不必重新检查全站内链。
这里要说明一个适用条件：如果差异清单显示缺失的链接分散在多个不相关区块，且没有共同容器，那么更可能是整页 HTML 被替换，而不是某个模块被改写，排查方向应转向整页缓存与版本比对。
第五步：判断哪些现象不能单独作为结论
在收集证据时，有几类现象容易被误读，需要明确它们不能单独证明处理正确。
- 边缘请求量或抓取量归零，不能单独证明边缘已恢复正常。它也可能是采集方式改变、请求被限流、或统计口径变化造成的。
- robots.txt 中的抓取限制不等于可靠的索引移除。即使限制了抓取，已收录的旧链接仍可能在一段时间内出现，不能据此判断内链异常已消除。
- 站点地图不保证收录。提交或更新站点地图，不能作为边缘返回内容已修复的证据。
- HTTPS 不保证安全无漏洞或排名。边缘异常与协议是否启用没有直接因果关系，不应把排查引向证书层面。
这些现象可以作为辅助线索，但结论必须回到源站与边缘的 HTML 对比、请求标识和差异清单上。不同搜索引擎对边缘返回内容的处理方式需要分别核查，不能用一个平台的表现推断另一个平台。
证据保留的最小集合与后续动作
如果只能保留最少的东西，按这个顺序留：同一 URL 在同一时间窗口的源站响应体与边缘响应体、两份响应的完整响应头、能对应两次请求的请求标识、以及逐条链接差异清单。这四样齐了，后续无论是找边缘服务方核查，还是调整缓存策略，都有可复查的起点。
下一步动作取决于第二步的区分结果：若倾向缓存旧版，先针对具体路径做缓存刷新并重新取样对比；若倾向节点改写，先固定改写规则的作用范围，再决定是关闭该规则还是调整内链输出方式。无论走哪条路，重新取样后都要用同一套对比方法验证，而不是凭页面看起来正常就结束。
