📍 WDQWDWQD987AAAAA:216.73.217.24
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad4d0391cb5c.html
📄

301重定向检查前需要准备哪些信息：两份方案对比与执行清单

检查301重定向之前，至少要准备四类信息：旧URL与目标URL的完整清单、服务器或CDN的控制权限、当前重定向链路与状态码的抓取记录，以及本次改动的生效范围与回滚方式。缺少其中任何一项，检查都会变成“看到什么算什么”，无法判断重定向是否按预期工作。最关键的一步是先固定旧URL清单，因为后续所有验证都以它为基准。

准备阶段：先确定要检查哪些URL

不要凭印象挑几个页面就开始测。先从可导出的来源整理旧URL：服务器访问日志、XML站点地图、站内搜索结果、数据库里的文章表、以及外部链接报告。把结果合并去重，形成一张表，至少包含三列：旧URL、预期目标URL、处理方式（301、302、410或保留）。

这张表决定了检查范围。如果只改栏目结构，范围是受影响的栏目页和其下内容页；如果整站换域名，范围是全部可访问URL加上历史遗留的旧路径。范围没定清楚，后面测一百个URL也不能说明问题。

实施前要拿到的权限与配置信息

检查301不能只看浏览器地址栏。你需要能读取服务器配置或CDN规则，才能确认重定向写在哪一层。准备以下内容：

• 服务器类型与配置文件位置，例如Nginx、Apache或应用路由层；
• CDN或反向代理是否也配置了跳转规则，避免两层规则互相覆盖；
• HTTPS证书覆盖的域名列表，确认新旧域名都能正常握手；
• 回滚方式：保留旧配置副本，明确多长时间内可以撤回。

如果只有后台编辑权限、拿不到服务器配置，检查就只能停留在“请求结果”层面，无法定位规则来源。这种情况下应先向运维或主机方索取配置读取权限，或请对方导出当前规则。

两种处理方案的对比与适用条件

常见的两种做法是“逐条精确重定向”和“规则批量重定向”。它们不是哪个更好，而是适用条件不同。

逐条精确重定向：为每个旧URL单独写一条规则。优点是目标明确，不会把无关路径带到错误页面；缺点是URL数量多时维护成本高。适合旧URL数量少、目标页面并非一一对应、或需要按业务判断跳转目标的情况。

规则批量重定向：用模式匹配把一批路径统一映射到新结构。优点是配置短、新增页面容易覆盖；缺点是模式写错会误伤，例如把本应保留的路径也跳走。适合新旧URL存在稳定对应关系、路径规律清晰的情况。

判断依据可以这样用：如果旧URL与新URL能用一条可读的映射规则描述，优先考虑批量；如果映射关系零散、需要人工决定，选逐条。两种方案也可以混用，但必须明确优先级，避免同一URL被两条规则同时命中。

验证阶段：状态码、链路与内容一致性

验证时至少检查三项，缺一项结论都不完整。

1. 状态码：请求旧URL，确认返回301而不是302、307或200。302是临时跳转，不会传递与301相同的信号，若本意是永久迁移却返回302，需要修正。
2. 跳转链路：确认是否一次跳到最终目标。旧URL跳到中间页、中间页再跳一次，会拉长链路，也可能在某一环断掉。用curl -I或浏览器开发者工具的Network面板逐跳查看Location响应头。
3. 内容一致性：最终落地页的主题应与旧URL原本的内容相关。旧文章跳到首页或无关分类，属于软404式的错配，用户和抓取都会困惑。

假设有一个旧地址 /old-guide 应指向 /new-guide。请求后若返回301且Location直接是/new-guide，链路正常；若Location先指向/category，再由该页跳转，就需要合并规则，减少一跳。

维护阶段要记录什么

检查通过不等于可以不管。保留一份重定向映射表，记录每条规则的添加时间、来源、目标和负责人。新增内容时先查这张表，避免新旧规则冲突。定期抽查高流量旧URL和外部链接指向的旧URL，确认它们仍然返回301且目标有效。目标页面被删除或再次改版时，要同步更新映射，否则重定向会指向404。

下一步可以直接做一件事：把你手头能导出的旧URL整理成三列表格，先填满“旧URL”和“预期目标”两列，再决定哪些走逐条、哪些走批量。这张表就是后续实施和验证的共同依据。