小企业网站建设：历史地址没有一一对应新页时怎样设计映射
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fef6de95a361.html
📄
小企业网站建设：历史地址没有一一对应新页时怎样设计映射
先给结论：不要追求“一个旧地址必须对应一个新页面”。更稳的做法是按旧地址的价值分两档处理——仍有独立检索价值或外部链接的，映射到内容最接近的新页；纯参数、重复列表、已失效功能页，统一收拢到上一级主题页或返回 410。判断依据不是旧地址数量，而是它是否还能独立满足一个搜索意图，以及是否有站外链接或用户收藏指向它。
第一档：旧地址仍有独立意图，就做一对一或一对多映射
当旧页本身回答了一个具体问题，比如某款产品的安装说明、某项服务的适用条件，而新站把这类内容合并进一个总页，直接 301 到总页会让用户落地后找不到原信息，跳出率上升，后续内链和转化路径也断了。这时应优先把旧内容重新落成新页，再让旧地址 301 到该新页。
实施动作：先导出旧站所有返回 200 的地址，按标题和正文主题聚类。每个聚类里，选出访问量或外链最多的一条作为保留页，其余同主题旧地址 301 到它。结果：新站页面数量减少，但每个保留页承接了原本分散的权重，后续你只需维护这一条内容。
例外：如果旧页只有表单提交结果、登录后页面或带 session 参数的地址，它们不该出现在映射表里，直接 410 或 404 更干净，避免把爬虫和用户引向无内容页。
第二档：旧地址只是重复或已无价值，收拢到上级主题页
分页列表、标签聚合、排序参数页、已下架产品的详情页，通常没有独立检索价值。把它们逐条 301 到新站对应列表页即可。判断标准是：这个旧地址的标题在搜索里是否可能单独被点击？如果不会，就不必为它单独建新页。
实施动作：在服务器或 CDN 层写规则，把 /old-list?page=2 这类地址用正则收拢到 /new-list。结果：规则条数从几百条降到几条，后续新增旧地址也能被同一规则覆盖，减少手工维护映射表的成本。
例外：如果某个参数页有大量外链指向，即使内容重复，也应单独 301 到最相关的新页，而不是收拢到列表页，否则外链权重会落在泛列表上，传递效率下降。
映射表要带三列：旧地址、新地址、处理理由
只写“旧→新”两列，过几个月没人知道为什么这样跳。加一列理由，例如“独立意图保留”“重复收拢”“已失效 410”。这样当新站再次改版时，接手的人能判断哪些映射可以复用，哪些需要重新评估。
假设例子：旧站有 120 个地址，其中 18 个有站外链接，22 个是独立产品说明，其余 80 个是分页和标签页。按上述两档处理，最终产生 40 条 301 和 80 条收拢规则。上线后一周，观察服务器日志里 404 的来源，如果集中在某几个未覆盖的旧地址，再补规则；如果 404 总量很低，说明映射表已覆盖主要入口。
上线后验证：看日志和落地页，而不是只看规则条数
规则写完不等于映射正确。至少检查两件事：一是旧地址是否都返回 301 而非 302 或 404；二是落地页是否与旧页主题一致。如果用户从旧产品页跳到新站首页，即使状态码正确，体验也是错的。
动作与结果：抽 10 条有外链的旧地址，用 curl -I 查看状态码和 Location 头。若发现某条跳到了不相关页面，回到映射表调整目标页，并同步检查该目标页的内链是否指向下一步转化入口。这一步做完，才能判断是否需要为个别旧地址单独建页。
什么情况下不要做映射，直接让旧地址失效
旧系统退出后，某些地址对应的是已停止的服务、已终止的合作方页面，或涉及用户隐私的查询结果页。这类地址继续 301 到新站，会把用户引向无法兑现的承诺。更合适的处理是返回 410，并在新站相关位置说明服务已调整。
适用条件：只有当旧地址确实没有任何仍可满足的用户需求，且没有值得保留的外链时，才选择失效处理。若不确定，先保留 301 到最接近的主题页，观察一段时间日志再决定，而不是一次性全部 410。
