网站建设策划书，历史地址没有一一对应新页时怎样设计映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0737aad60c57.html
📄
网站建设策划书，历史地址没有一一对应新页时怎样设计映射
结论先行：只有当旧地址集合能按“内容主题”或“参数规律”聚成有限类别时，才适合在策划书里写一一映射；如果旧地址是散乱、无规律、且与新页没有稳定语义对应，强行逐条映射会把策划书变成无法验收的清单，此时应改为“规则映射＋例外清单＋可核对证据”的写法。
先判断旧地址能不能聚成有限类别
策划书里最常见的分歧是：技术角色认为每个旧地址都该有目标页，内容角色认为很多旧地址本来就没有对应内容。把分歧转成可核对项目，第一步是抽样而不是全量争论。抽取旧地址样本，按路径结构、参数、标题主题三个维度分类，看是否能形成稳定分组。
- 能聚类的信号：路径前缀一致，如
/product/old-a、/product/old-b都指向同一产品线；或参数只影响排序、分页、会话，不影响主体内容。 - 不能聚类的信号：同一前缀下混合了文章、下载、活动页；参数含义在不同栏目里完全不同；旧标题与新页主题只能靠人工猜测关联。
如果抽样后超过一半的旧地址无法归入任何稳定分组，就不应继续写逐条映射表。这个判断会直接改变下一步：从“补全映射表”转为“定义规则和例外”。
两种写法成立的条件不同
逐条映射成立的条件：旧地址数量有限，且每个旧地址都能在新站找到唯一且语义一致的目标页。此时策划书应给出旧地址、目标地址、映射依据三列，并注明由谁核对。它的好处是可逐条验收，坏处是维护成本高，新站结构调整后容易过期。
规则映射成立的条件：旧地址能按前缀、参数或内容类型分组，每组有统一处理方式。此时策划书应写清规则优先级和例外处理，而不是罗列全部地址。例如假设旧站有 200 个带 ?page= 参数的列表页，可以约定参数页统一指向对应栏目首页，再单独列出少数必须指向具体文章的例外。这个例子只用于说明比较方法，不代表真实项目数量。
两种写法不是优劣关系，而是适用条件不同。判断依据是旧地址能否稳定聚类，而不是团队偏好。
会使结论失效的反例
有一种情况会让“规则映射”也失效：旧地址看似有规律，但规律背后对应的是不同业务含义。例如 /news/2023/ 和 /news/2024/ 表面都是年份归档，但前者可能是已下架的活动通知，后者是仍需保留的公告。如果只按年份前缀统一指向新闻首页，会把仍有价值的公告页也降级为栏目页。
识别这种反例的动作是：在抽样分类后，再按“内容是否仍需被用户直接访问”二次核对。若同一规则组内出现两种以上业务含义，就不能用单一规则覆盖，必须拆组或列入例外清单。这一步的结果会决定策划书里规则的数量，而不是让规则越少越好。
把分歧转成可核对的项目
策划书不必裁决谁对谁错，而应把争议点变成可核对的条目。建议在策划书中加入一张核对表，包含：旧地址样本、归类依据、拟用规则、例外原因、核对人、核对结果。每个条目只回答“这个地址为什么这样处理”，不写泛泛的优化目标。
实际动作：先让技术角色按路径和参数输出候选分组，再让内容角色逐组确认业务含义，最后由策划书汇总为规则加例外。这个动作的结果是：如果某组无法确认业务含义，就标记为待定，而不是默认套用规则。待定项会影响后续开发排期，因此必须在策划书里显式列出，不能藏在附录。
下一步动作与验收方式
完成分类和规则定义后，下一步不是立刻全量实施，而是用抽样验证规则。从每个规则组抽取若干旧地址，检查按规则得到的目标页是否与用户预期一致。若抽样中出现明显不匹配，回到分组阶段调整，而不是在实施阶段逐条打补丁。
验收时看两件事：规则是否覆盖了已确认的类别，例外清单是否都有明确原因和核对人。不要用“抓取量下降”或“请求量归零”单独证明映射正确，因为这些现象也可能由缓存、屏蔽、访问路径变化等原因造成。策划书应把验收标准写成可复核的对应关系，而不是单一指标。
