网站改版后重定向和 404 监控检查清单

重定向表只是计划。重定向和 404 监控，才是证明网站改版、Shopify 主题上线、WordPress 重建或 CMS 迁移在生产环境里真的正常的方法。它能发现漏掉的旧 URL、错误的新链接，以及在 staging 正常但生产异常的跳转规则。

这份清单适合上线后 24 小时、7 天和 30 天使用。商品 handle 修改、博客迁移、Collection 重构、服务页合并、多语言 URL 更新和平台迁移后，也建议执行。

先收集所有可能产生有价值错误的 URL 来源，不要只看重定向表。即使重定向表很干净，也可能漏掉旧活动 URL、外链、PDF 链接、内部搜索 URL、下架商品、本地化路径，或只出现在分析工具里的 URL。

把来源放进同一个表格或 issue tracker，确保每个发现都能分配、修复和复测。目标不是给每个奇怪 URL 都做跳转，而是保护有流量、链接、收入、线索价值或用户预期的 URL。

• 迁移计划里的重定向表，包括旧 URL、新目标页、状态和负责人。
• 生产 XML sitemap，以及新网站的最新 crawl 结果。
• Search Console 的索引示例、not found 示例和抓取统计。
• 过去 6 到 12 个月的分析落地页，特别是有转化或付费流量的 URL。
• 外链导出、活动 URL、二维码、邮件链接和合作伙伴链接，这些往往不会出现在 sitemap 里。

上线后立即用旧 URL 清单跑一次 crawl。每个重要旧 URL 都应该干净地 301 或 308 到最合适的新目标页。不要把所有内容都跳到首页，除非旧页面确实没有任何有用替代。

然后爬取生产站的优先新路径。这样可以发现内链指向已删除页面、slug 拼写错误、斜杠规则混乱、语言路径错误，以及内容迁移时改动过的商品或博客链接。

• 分批测试旧 URL，并记录最终目标页、最终状态、跳转次数和目标是否相关。
• 标记跳转链、循环跳转、临时跳转、JavaScript 跳转和跳到无关页面的规则。
• 爬取新 sitemap 和导航，在客户或搜索引擎持续访问前先发现内部 404。
• 如果移动端和桌面端渲染不同菜单、卡片或活动模块，要分别检查。
• 每个修复都用原始来源 URL 复测，不要只靠浏览器打开一次。

404 不一定都是坏事。有些删除的工具页、垃圾路径和随机探测 URL 可以继续保持 404。真正要判断的是，这个缺失 URL 是否曾经有流量、外链、内链、活动使用、商品需求或接近的替代页面。

建议用简单优先级模型。一级是影响收入、询盘、外链、搜索流量、付费活动或客服的 URL。二级是内部链接清理和替代页不够准确的问题。三级是需要观察但不值得过度处理的噪音。

• 一级：旧服务页、核心商品、高流量博客、被链接的 PDF、付费落地页和有外链的 URL。
• 二级：低流量但有内链的页面、重复的历史路径，以及有合理替代页的 URL。
• 三级：格式错误 URL、机器人探测、旧 query string、搜索结果路径和无关垃圾请求。
• 当内容已经删除、没有替代页、也没有明显流量或外链价值时，可以保留 404。
• 只有团队明确希望告诉搜索引擎内容永久消失时，才使用 410。

一个重定向即使状态码正确，也可能是错误的。目标页应该回应同样的用户意图，保留最接近的商品或服务上下文，不要把所有旧 URL 都送到宽泛的首页或泛分类页。

对电商和 B2B 网站来说，目标页质量经常决定迁移是否丢失价值。下架商品可能需要替代商品、分类页、购买指南或支持页。合并后的服务页，可能需要有对应旧意图的区块或锚点。

• 确认每个优先重定向都落到最相关的页面，而不只是任意 live 页面。
• 检查旧 URL 和新 URL 的语言对应关系，避免中文、英文或区域 URL 跳到错误语言。
• 确认重定向后的页面可收录，并使用预期 canonical URL。
• 不要为了避免 404，把下架商品跳到无关商品。
• 记录那些需要补内容的重定向，因为当前目标页只部分匹配旧意图。

Search Console 有延迟，分析工具会漏掉部分爬虫行为，服务器日志也会很嘈杂。要把它们放在一起看。同一个 URL 如果出现在多个来源里，尤其还有 impressions、sessions、外链或重复访问，通常值得处理。

上线第一周建议每天检查。第一周后，把它变成这个月剩余时间的每周修复队列。每次复查都应该产出动作：新增重定向、修复内链、更新 sitemap、修 canonical、恢复内容，或明确忽略低价值噪音。

• Search Console：not found 示例、已收录页面、重复和 canonical 报告、sitemap 处理和页面表现。
• 分析工具：有 sessions、转化、活动流量或上线后明显下跌的落地页。
• 日志或托管数据：重复 404、机器人高频路径、旧资源路径和跳转链模式。
• 外链工具：仍然有外部链接指向的旧 URL，不要轻易留空。
• CMS 或平台报告：Shopify handle、WordPress slug、媒体 URL、Collection 或分类路径的变化。

监控流程最后应该得到一个修复队列，而不是一堆混乱导出。每个问题都应该包含来源 URL、观察到的状态、最终目标、证据来源、优先级、负责人、计划修复和复测日期。

这样 SEO、开发、内容和维护工作才会对齐，也能避免同一个重定向问题在每次会议里被重新发现，却没有人真正负责。

• 用同一种 issue 格式记录重定向、404、软 404、错误 canonical 和内部断链。
• 能按规则模式合并的修复尽量合并，让开发一次解决一批 URL。
• 当缺失页面需要更好的目标页时，把内容决策和技术修复分开。
• 部署后用原始来源 URL 复测，并记录最终状态。
• 任何 URL 变化较多的上线，修复队列至少保留 30 天。