先给有条件的结论:如果旧说明只在少数页面出现、且这些页面本身仍能承接用户需求,优先在原页更新地点信息并保留可访问状态;只有当旧地点是页面核心主题、更新后会造成内容与标题明显错位时,才考虑合并或重定向。这个判断在小样本上通常成立,但规模化后会遇到例外。
处理方式取决于旧页面与活动的绑定程度。信息过期指页面主题仍是同一项活动,只是地点变了;主题失效指页面存在的理由就是那个旧地点,换掉地点后整页失去意义。前者适合就地更新,后者适合合并或重定向。
判断依据不是“页面多不多”,而是“用户到这个页面想解决什么”。如果用户想找的是这场活动,地点只是其中一个条件,更新即可;如果用户想找的是“在某个地点举办的活动”,换地点后需求已经不匹配。
假设你只有三个页面写错了地点,逐个手动更新,成本低、可控。但当同类旧说明有几十上百条,分散在列表页、详情页、栏目页时,直接套用“逐页更新”会暴露两个问题:一是同一地点在不同页面出现多次,漏改一处就会自相矛盾;二是部分页面本来就没有独立价值,逐页维护只是延续了重复内容。
反例出现在这里:当旧页面已经被外部引用、且这些引用带来的访问仍在持续时,简单重定向可能让用户落到一个主题不完全对应的新页,体验反而变差。此时更稳妥的是保留旧页并明确标注“活动已移至新地点”,再给出新页入口。这个反例说明,页面数量和外部引用情况会改变处理顺序。
这个顺序的关键动作是第一步的标记。标记结果直接决定后面走更新、合并还是保留,跳过标记直接批量改,容易把仍有价值的页面误删或误并。
地点变更后,旧页面上的时间、报名方式、主办信息也可能一起过期。只改地点不改这些信息,用户仍会得到错误预期。另外,如果旧地点本身就是用户搜索这项活动的主要理由,那么更新后的页面需要重新评估它是否还能满足原有查询,而不是默认保留原状。
下一步动作可以很小:先挑出引用最多和访问最集中的那几页,按上面的顺序处理一遍,观察用户是否还需要旧地点信息,再决定其余页面是批量更新还是批量合并。