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

301重定向，改版或迁移时应核对什么

改版或迁移时核对301重定向，核心是确认三件事：旧URL是否都能到达最合适的新URL、跳转是否保持一对一且不经过多余中转、以及上线后旧地址是否真的返回301而不是404或302。时间和人手有限时，优先处理有搜索流量和外部链接的旧URL，再处理长尾页面。

先观察：旧URL现在返回什么状态

不要凭印象判断，直接抓取旧地址看响应。可以用命令行工具批量检查，例如：

curl -I https://example.com/old-page

重点看状态码和Location响应头。判断结果如下：

• 返回301且Location指向新页面：符合预期，继续核对目标是否准确。
• 返回302或307：属于临时跳转，搜索引擎通常不会把旧URL的权重信号转移到新URL，应改为301。
• 返回404：旧页面没有建立跳转，需要补上规则。
• 返回200：旧URL仍在直接输出内容，可能是规则未生效或缓存未刷新。

如果站点页面数量多，先导出旧站URL清单，按是否有外链、是否有自然流量排序，把这两类放在第一批核对。

判断跳转目标是否一对一且相关

301重定向应尽量把每个旧URL指向内容最接近的新URL，而不是全部指向首页。全部指向首页会让用户和搜索引擎都难以判断新页面与原内容的对应关系，也容易让原本分散的入口信号集中到一个不相关的页面上。

核对时逐条检查：

1. 旧栏目页是否指向新栏目页，而不是新站首页。
2. 旧文章页是否指向同一主题的新文章页；如果内容已删除，指向最相关的上级栏目页比指向首页更合理。
3. 旧URL是否有多层跳转，例如旧A跳到旧B再跳到新C。应合并为旧A直接跳到新C，减少中转。
4. 跳转链中是否出现循环，例如A跳B、B又跳A。循环会导致页面无法到达。

假设旧站有一个产品分类页/product/a/，新站对应分类是/products/a/，就应直接建立这两者之间的301；如果图省事把它跳到/products/总览页，用户需要再点一次才能找到原分类内容，这属于目标不够精确的情况。

处理：规则写在哪里、怎么验证

301重定向可以配置在服务器层，例如Nginx、Apache，也可以由应用层或CDN规则实现。选择哪种方式取决于你能否修改服务器配置、是否需要按路径批量匹配，以及团队后续维护成本。人手有限时，优先用能集中管理、便于批量修改的方式，避免把大量规则散落在页面代码里。

配置完成后不要只看一条规则是否生效，要按下面顺序复查：

• 用curl -I检查状态码是否为301，Location是否为预期的新URL。
• 在浏览器中访问旧URL，确认最终落地页与预期一致，且地址栏显示的是新URL。
• 检查跳转后的新页面本身是否返回200，而不是又跳到别处或返回404。
• 核对站内链接、站点地图和导航是否已更新为新URL，避免站内还在指向旧地址。

需要区分的是：robots.txt的抓取限制不等于可靠的索引移除，它只能阻止抓取，不能替代301把旧URL指向新地址。站点地图提交也不保证收录，它只是帮助发现URL。HTTPS同样不保证安全无漏洞或排名提升，它和301是两件独立的事。

复查：上线后过一段时间再看

301生效后，搜索引擎需要时间重新抓取和处理旧URL。复查时重点看：旧URL是否仍返回301、新URL是否被正常抓取、搜索结果中旧地址是否逐渐被新地址替代。不同搜索引擎的处理节奏不同，需要分别核查，不要用同一个时间预期套用所有平台。

如果发现旧URL仍返回200或404，先检查是否有缓存、CDN规则或服务器配置未刷新，再检查规则优先级是否被其他规则覆盖。如果跳转目标错误，及时修正规则，不要长期保留错误跳转。

下一步：导出旧站URL清单，按外链和流量排序，用curl -I逐条核对状态码与跳转目标，先修好高价值URL的301，再处理其余页面。