先给结论:不能把某一个设备或某一种登录状态下看到的页面当作唯一事实,而要把同一地址在不同请求条件下返回的内容分别留存,再判断差异属于模板、权限还是缓存,最后决定内链应该指向哪个版本。下面用一个假设情境说明整个对照与决策过程,并标出不能直接照搬到全站的地方。
假设某站点有一篇介绍产品分类的页面,地址为 /category/guide。桌面端未登录访问时,页面正文包含一段完整的分类说明,并在其中自然链向三个子分类页。移动端访问时,同一地址只显示精简摘要和“展开更多”按钮,正文里的三个链接被折叠进交互组件。登录后访问,页面顶部多出一块“最近浏览”,正文链接仍在,但顺序被推荐模块挤到下方。
此时如果只检查桌面未登录状态,会得出“内链正常”的结论;如果只检查移动端,会误判为“链接缺失”。两种判断都不完整,因为差异来自渲染方式和登录态,而不是链接本身被删除。
要做出可复查的对照,至少需要固定以下条件,并逐项记录:
把这几项写成一张对照清单,每个组合只改一个变量。如果同时换设备又换登录状态,出现差异时无法判断是哪一项造成的,后续修复方向也会跟着错。
同一地址返回不同内容,常见来源有三类,处理方式并不相同。
移动端折叠、懒加载或组件化渲染导致链接在初始响应中不出现,但在交互后出现。判断依据是查看初始响应内容与交互后内容是否一致。若链接确实存在于交互后的结构里,问题更偏向可发现性,而不是链接被移除。此时应确认内链所指向的目标地址是否仍然有效,而不是急着改链接本身。
登录后内容变化,通常是因为页面按角色输出不同模块。需要确认登录态下新增或隐藏的链接是否属于同一套导航逻辑。如果登录后才出现的链接指向只有登录用户才能访问的页面,那么把这条内链放到未登录版本中就是不成立的,反之亦然。
同一地址在不同设备上返回不同内容,也可能是缓存把某个版本分发给了另一类请求。判断方法是绕过缓存重新请求,观察差异是否消失。若消失,说明需要先处理缓存键或缓存策略,再谈内链调整。
实际动作可以这样安排:先以桌面未登录状态请求目标地址,保存返回内容;再以移动端未登录状态请求同一地址,保存返回内容;最后以登录状态请求一次,保存返回内容。三份内容都按同一地址归档,并标注请求条件。
对照结果会直接决定下一步。如果三份内容里的正文链接指向一致,只是展示位置不同,那么内链结构本身不需要改,重点转向确保移动端交互后链接可被访问。如果登录版本多出一条指向会员页的链接,而未登录版本没有,那么这条链接不应被当作全站通用内链来对待。如果差异在绕过缓存后消失,那么优先处理缓存,而不是修改页面模板。
这套做法适用于个别样本先成立、再判断能否扩展到更多地址的场景。规模化时会遇到例外,需要提前划清边界。
另外,robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录。对照过程中如果发现某个版本没有被抓取,不能仅凭这一点就断定处理正确,还需要排查该版本是否被其他合理原因排除,例如权限、缓存或链接入口缺失。
完成对照后,内链该指向哪个版本,取决于哪个版本是稳定、可访问且对目标读者成立的。若移动端与桌面端最终都能到达同一目标地址,那么内链可以保持一份,重点放在确保链接在初始或交互后可达。若登录状态改变了可访问范围,那么内链应分别按角色设计,而不是用一条链接覆盖所有情况。若差异来自缓存,那么先解决缓存一致性,再验证内链,否则每次对照都会得到不同结果。
把每次对照的请求条件、保存内容和结论一起归档,下一次遇到类似地址时就能直接复用判断路径,而不是重新从某一个设备上的观感开始猜。