结论先说:不要按“旧文章有没有提到被改掉的功能名”来决定,而要按引用是否还承担着“把读者送到正确下一步”的职责来决定。产品文档改版后,旧文章里的引用分三类——指向已废止页面的、指向内容已迁移但语义变了的、以及仅作为背景提及的。前两类必须处理,第三类可以不动。判断顺序是:先确认被引用页面的当前状态,再看旧文章里这个引用是“行动路径”还是“补充说明”,最后决定改链、改文案还是保留。
把旧文章里所有指向站内或站外的引用列出来,逐个打开,记录它现在落在哪里。你会遇到三种状态,处理代价完全不同。
注意,抓取工具报告“链接正常”只能说明目标可达,不能说明引用仍然成立。软迁移和语义漂移恰恰是链接检查器查不出来的,必须人工读一遍目标页面的对应段落。这一步做完,你手上会有一张按状态分组的引用清单,而不是笼统的“待更新列表”。
同样是失效链接,处理优先级取决于它在原文里的功能。问自己一个问题:如果删掉这个引用,读者还能不能完成这篇文章承诺的事?
如果引用是行动路径——比如“按这里完成安装”“在此处提交申请”“参考该页配置参数”——它承担的是读者下一步动作,必须更新,且要更新到能真正完成动作的页面。如果引用是补充说明——比如“关于该概念的背景可参见另一篇”——它只是延伸阅读,可以降级为纯文本、替换成新页面,或直接删除而不影响主线。
这里有个常见误判:编辑看到旧文章里出现已下线功能的名称,就急着改文案。但如果那段文字只是历史背景,读者读完并不需要跳转,改文案反而可能破坏上下文。先看引用是不是行动路径,再决定动不动它。
面对几十上百篇旧文章,通常有两种做法,各有成立条件。
做法一:批量替换链接。适用于被引用页面发生了整体迁移、新旧页面一一对应、且旧文章里的引用上下文不需要改的情况。代价是批量脚本无法识别软迁移——如果新页面只是地址变了、内容对象也变了,批量替换会把读者送到一个“看起来对、实际答非所问”的页面。所以批量替换前,必须抽样人工验证至少覆盖每一类被引用页面。
做法二:逐篇重写引用段落。适用于引用是行动路径、且新旧页面语义不一致的情况。代价是慢,但能保证读者到达后能找到原文承诺的内容。一个折中做法是:先批量替换硬失效链接,把软迁移和语义漂移单独列出人工处理。
选择条件可以这样判断:如果被引用页面只是换了地址、内容和结构不变,批量替换成立;如果被引用页面的对象、术语或步骤变了,逐篇重写成立。两者不是互斥的,同一批旧文章里可以混用。
假设你手上有一篇旧教程,正文里有一句“在控制台的网络设置页填写回调地址”,链接指向旧版控制台文档。产品改版后,控制台拆成了两个页面,回调地址配置移到了“集成设置”下。
按前面的顺序处理:第一步,打开旧链接,发现它跳转到新版控制台首页——这是硬失效。第二步,判断这个引用是行动路径还是补充说明:读者需要按它去完成配置,属于行动路径。第三步,找新页面里真正讲回调地址配置的小节,把链接换成该小节,同时把原文“网络设置页”改成“集成设置”。
如果只做批量替换、把链接指向新版控制台首页,读者到达后还要自己找配置入口,原文承诺的“填写回调地址”就没有兑现。这个动作的结果会直接影响下一步:改完之后,你需要在旧文章里再检查一遍,是否还有别处提到“网络设置页”这个旧术语。如果有,它们可能同样需要改;如果没有,这篇就处理完了。这个检查结果决定了你是继续处理下一篇,还是先回头修正批量替换规则。
改完不等于到位。验证时不要只看链接能不能打开,要模拟读者的动作路径:从旧文章出发,点进引用,看能否在目标页面找到原文提到的具体内容。找不到,说明引用仍然不成立。
另外,把这次处理过的引用记下来,包括旧地址、新地址、处理方式和处理日期。下次产品文档再改版时,这份记录能帮你快速判断哪些旧文章受影响,而不必从零排查。记录本身不需要复杂工具,一张表就够,关键是字段要能回答“这个引用当初为什么这样改”。
最后提醒一点:旧文章里的引用更新完之后,如果发现某篇文章的行动路径已经整体失效、且没有对应的新页面可指,那么要做的可能不是改引用,而是给这篇文章加一个说明或安排下线。引用更新只是手段,读者能完成下一步才是目的。