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

301跳转设置 - 日志中应该核对哪些字段

排查301跳转是否生效，最直接的方法是查看服务器访问日志。核心要核对的字段是：请求的原始URL、返回的状态码、响应的Location头、客户端IP与User-Agent、请求时间。其中状态码必须是301（或308，视场景而定），Location必须指向你预期的目标URL，这两项对不上，跳转就没按预期工作。

先看状态码字段：确认返回的是不是301

日志里的状态码字段通常紧跟在请求行之后，例如 "GET /old-page HTTP/1.1" 301。核对时注意区分几种情况：

• 返回200：说明旧URL仍直接输出内容，跳转规则没有命中。
• 返回302/307：这是临时跳转，搜索引擎可能保留旧URL，与301的语义不同。
• 返回404：跳转规则写错了匹配路径，请求根本没被重定向。
• 返回301：符合预期，继续核对目标地址。

如果日志中同一URL既有301又有200，通常意味着部分请求走了缓存，或规则匹配条件不完整。这属于"可能原因"，需要结合规则文件和缓存层进一步确认，不能直接断定是某一处出错。

再看Location响应头：目标地址是否指向正确

状态码正确不代表跳对了地方。Location字段记录实际跳转目标，格式类似 Location: https://example.com/new-page。核对要点：

1. 目标URL是否与你配置的一致，有没有多出或缺少斜杠、参数。
2. 是否出现了跳转链，即A跳到B、B又跳到C。日志里同一客户端短时间内连续出现多条301，往往就是链式跳转。
3. 是否跳到了带参数的版本，导致目标页被拆成多个地址。

跳转链会拖慢响应，也让权重传递打折。发现链条后，应把规则改为一步到位。

核对请求字段：谁在请求、请求了什么

排查时还需要看请求本身的记录：

• 原始请求路径：确认被访问的是不是你配置规则时写的那条路径，大小写、结尾斜杠都可能造成不匹配。
• User-Agent：区分真实用户和搜索引擎爬虫。有些跳转规则只对特定UA生效，日志能帮你判断爬虫是否真的拿到了301。
• 客户端IP：用于排除内网测试流量干扰，也便于按来源分析。
• 请求时间：配合规则上线时间，判断跳转是何时开始生效的。

一个可执行的检查动作是：在日志中筛选出目标旧URL的全部记录，按时间排序，观察状态码和Location是否在某个时间点之后才变成301。如果一直是200，说明规则未生效；如果从某时刻起变为301，说明规则已上线。

复查：跳转生效后还要确认什么

日志显示301且Location正确，只说明服务器层面跳转成立。接下来可以：

• 用命令行工具请求旧URL，确认返回头中的状态码与Location，与日志记录一致。
• 确认目标页本身返回200，而不是404或另一条跳转。
• 如果涉及robots.txt限制，注意抓取限制不等于索引移除，被robots挡住的URL搜索引擎可能仍保留在索引中，需要单独处理。

判断标准很简单：旧URL返回301、Location指向一个返回200的目标页、没有多余跳转链，这三条同时满足，才算跳转设置到位。

下一步：按上面字段顺序，从日志中筛出一条旧URL的完整记录，逐项对照状态码和Location，确认无误后再批量检查其余URL。