建站风格选择：历史地址没有一一对应新页时怎样设计映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eee3bd3543d4.html
📄
建站风格选择：历史地址没有一一对应新页时怎样设计映射
先给结论：不要追求“每条旧地址都找到一条新地址”的完整映射。历史地址与新页没有一一对应时，映射设计的关键是分层：能确认继承关系的走单点跳转，无法确认继承关系的走分类归集或明确失效。判断依据不是旧地址数量，而是旧地址背后是否仍有稳定的访问意图，以及新页能否承接这个意图。样本量小时凭人工判断往往够用，一旦规模化，例外会迅速吞掉人工成本，这时必须把判断规则写进映射表，而不是继续加跳转。
两种条件下的不同选择
第一种条件：旧地址集合小、语义边界清楚，且新页结构已经稳定。这时适合逐条判断，把旧地址映射到最接近的新页，语义确实断裂的直接返回 410 或 404，而不是硬塞到首页。第二种条件：旧地址数量大、命名规则混乱，或新旧内容体系发生过重组。这时逐条判断不再成立，应改为按路径前缀、参数特征或旧栏目主题做批量归集，把一批旧地址指向一个主题聚合页，再对少数高价值地址做单独处理。
区分这两种条件的证据很具体：如果抽样一百条旧地址，其中超过八成能明确说出“它原来讲什么、现在哪一页讲同一件事”，逐条映射可行；如果抽样中大量地址连原始主题都无法还原，批量归集更现实。这里的比例只是假设例子，用于说明比较方法，不代表任何实际站点数据。
实施动作：先建映射表，再决定跳转类型
具体动作是建立一张映射表，至少包含四列：旧地址、判断结果、目标地址、跳转类型。判断结果只允许三种取值——继承、归集、失效。跳转类型对应 301、302 或 410/404。每填一行，都必须能回答“为什么这条旧地址属于这一类”。
- 继承：旧地址与新页讲同一主题，用 301，并确保目标页内容确实覆盖旧页的核心信息。
- 归集：旧地址属于某个已消失的栏目或批次，用 301 指向该主题的聚合页或栏目页，而不是首页。
- 失效：旧地址对应的是已不存在且无替代的服务、活动或临时页，用 410 或 404，保留其失效状态。
这一步的结果会直接影响下一步：如果映射表中“归集”占比很高，说明新站的信息架构与旧站差异较大，此时应优先检查聚合页是否真的能承接这些访问意图，而不是急着上线跳转。如果“失效”占比异常高，则要回头确认是旧地址本身无价值，还是新站缺失了对应的内容层。
不能直接照搬的边界
逐条映射的经验在小样本上成立，规模化后会出现三类例外，不能照搬。
- 旧地址带参数或会话标识：同一内容对应多个地址变体，逐条映射会成倍膨胀。此时应先做地址归一化，再对归一化后的地址建映射。
- 旧地址曾指向多个主题：一个旧页面历史上被改写过多次，无法对应单一新页。这种情况按当前最接近的主题归集，不要为历史版本各建一条跳转。
- 新页本身还会调整：如果新站结构尚未稳定，映射表应标注“待定”，先不上线跳转，避免目标地址再次变动造成二次失效。
需要说明的是，跳转上线后请求量或抓取量下降，不能单独证明映射正确。它也可能来自旧地址本身访问减少、爬虫重新评估或站点整体流量变化。判断映射是否合理，仍要回到映射表本身的分类依据，而不是只看某一条统计曲线的走向。
一个注明假设的短例子
假设某站旧结构为 /old/2019/spring/ 这类按年份和季节划分的路径，新站改为按主题划分，没有季节栏目。逐条映射找不到对应页，因为新站不存在“2019 春季”这个层级。此时合理做法是把这类地址归集到对应主题的聚合页，例如把多个年份的季节页指向同一主题页；只有当某个旧页确实对应一篇独立新文章时，才用 301 单独指向它。这个假设说明的是判断顺序：先看结构层级是否还存在，再看单页是否可继承。
映射设计的目标不是让每条旧地址都有去处，而是让每一类旧地址都有可解释的去处。把分类依据写清楚，例外才有地方安放，后续调整也有据可查。
