301重定向检查：追踪每一条重定向链

重定向检查工具能让你看到从点击链接到打开页面之间究竟发生了什么。你输入的每个网址，都会由Marqly的服务器在关闭自动跳转的情况下发出请求，因此每一次响应都被单独记录：状态码、它指向的Location头、耗时，以及与SEO相关的响应头。随后工具会跟随这个地址继续请求，最多跟随10次重定向，与Google抓取程序的默认上限一致。你会得到完整的重定向链、最终网址和状态，以及用通俗语言写成的提醒，涵盖循环、临时重定向、缓慢的跳转、丢失的跟踪参数，以及值得合并的链条。

如何检查重定向

1. 把网址粘贴到输入框里。需要批量检查时，一次最多粘贴10个网址，每行一个。
2. 如有需要，选择用户代理。默认以Marqly检查工具的身份发出请求；你也可以选择Chrome、iPhone Safari、Googlebot智能手机或Googlebot桌面版的用户代理，找出对浏览器、手机和爬虫区别对待的规则。
3. 勾选同时检查http/https和www/非www版本，可以一次测试同一地址的全部四种写法。这是确认网站只有一个规范主机名、且每个变体都能一步到达它的最快办法。
4. 点击检查重定向。每个网址都会有自己的卡片，包含结论、提示和逐跳的链条。
5. 用复制结果得到文字报告，用下载CSV得到每跳一行的电子表格，或用复制分享链接发出一个能重新运行同一次检查的链接。

如何阅读检查结果

每张卡片的开头依次是最终状态码、你输入的网址、重定向次数、总耗时和最终网址。其下是提示，标出值得注意的地方：错误（循环、超出上限的链条、以404结束的链条）、警告（临时重定向、meta refresh、从https降级到http、被丢弃的查询参数、最终页面上的X-Robots-Tag: noindex）和中性说明（末尾斜杠或www的变化、迁移到另一个域名、缓慢的跳转）。

链条表按顺序列出每一次请求。状态是服务器返回的HTTP状态码。网址是被请求的地址，其下方是这一跳让客户端接下来去往的地方；当服务器发来的是相对路径的Location时，这里已经解析成了绝对地址。时间是服务器返回这一跳响应头所用的时间。展开任意一行的Headers，可以看到Location、Cache-Control、Content-Type、X-Robots-Tag、Link（可在其中声明canonical）、Strict-Transport-Security、X-Redirect-By（WordPress和部分插件会在这里表明身份）以及Server。Cookie的值永远不会显示，只显示设置了几个。

301、302、307、308：各种重定向代码是什么意思

HTTP在RFC 9110第15.4节中定义了这些重定向状态码。区分它们的是两个问题：这次迁移是不是永久性的？客户端在跟随重定向时，能不能更改请求方法（例如把表单的POST变成GET）？Google的HTTP状态码文档说明了它的抓取程序和索引系统如何处理每一种。

对于普通页面，内容永久搬家时用301：改了网址别名、合并了文章、迁移了域名、切换到HTTPS。原网址还会回来时用302或307，比如维护页面、短期活动或测试。方法很重要时用308，例如API接口或接收POST请求的表单，因为RFC 9110允许客户端在301和302上把被重定向的POST改成GET，而在307和308上禁止这样做。

meta refresh和JavaScript重定向

Google的重定向指南建议尽可能使用永久性的服务器端重定向。它把即时的meta refresh当作永久重定向，把有延迟的当作临时重定向，并且只在服务器端重定向和meta refresh都无法使用时才建议用JavaScript重定向，因为渲染可能失败。本检查工具会跟随meta refresh标签和Refresh头并加以标注，但不会执行JavaScript。

什么是重定向链，为什么有害？

重定向链就是跳转超过一次的路径：http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/。链条很少是有意为之的。它们是在网站迁移到HTTPS、选定www偏好、更换CMS、重命名栏目，并且对旧的重定向再做重定向而不是改写它们的过程中，一层一层堆起来的。每一层单独看都没问题，叠在一起问题就出现了。

• 速度。每多一跳，页面开始加载前就多一次完整的请求，而跳到新主机名还要多一次DNS查询和一次TLS握手。“时间”一列显示了每一跳的代价。
• 抓取。Google表示其抓取程序默认最多跟随10次重定向，其“网页索引编制”报告会把过长的重定向链、重定向循环以及链条中错误或空的网址列为重定向错误。Google的网站迁移指南建议直接重定向到最终目的地，并指出串联重定向会增加延迟，而且并非所有用户代理和浏览器都支持很长的链条。
• 其他客户端。RFC 9110指出，早期的HTTP规范曾建议最多五次重定向，一些客户端可能仍然执行类似的固定上限，所以Googlebot能容忍的链条，对其他软件仍可能失效。
• 脆弱性和数据丢失。每一跳都是又一条可能被编辑、删除或被覆盖的规则。重建网址的某一跳可能悄悄丢掉查询字符串，UTM标记就是这样在数据分析看到之前消失的；当原始网址里的某个参数在最终网址里缺失时，检查工具会提醒你。

如何修复重定向链

1. 找到最终网址。把旧网址放进检查工具运行，复制链条中的最后一个网址。
2. 让第一次重定向直接指向最终网址。如果A跳到B、B又跳到C，就把A的规则改成直接去C，同时保留B → C，供仍然持有B的人使用。在重定向映射表或插件里，搜索那些目标本身又是另一条规则来源的规则。
3. 合并协议和主机名的规则。最常见的链条是http → https之后再接非www → www。写一条规则，一步把所有变体都送到规范写法，就像这个nginx示例：

# One hop from every variant to https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate lines omitted
    return 301 https://www.example.com$request_uri;
}

4. 在源头更新链接。把内部链接、canonical标签、hreflang标注和XML站点地图改成最终网址；Google的网站迁移指南要求把内部链接更新为新网址。重定向应该用来接住来自别处的旧链接，而不是承载你自己的导航。
5. 保留重定向。Google建议尽可能长时间保留重定向，通常至少一年。合并链条是重新指定目标，而不是删除旧规则。
6. 重新测试。再次运行同样的网址，最好勾选变体选项，确认每一个都能一步到达200页面。

修复重定向循环

循环是指链条回到了它已经访问过的网址，因此永无止境；浏览器会显示“重定向次数过多”的错误。常见原因是两个层面互相矛盾：CDN通过HTTP访问源站，而源站强制使用HTTPS；网络服务器里的末尾斜杠规则与应用程序里相反的规则互相较劲；或者www规则同时设置在DNS级别的转发和网站本身里。请查看网址又跳回去的那一跳；它的Server和X-Redirect-By头往往能告诉你是哪一层发出的。有些循环只在没有Cookie时才会出现（同意弹窗或登录重定向），对已有Cookie的访问者没有影响；检查工具不发送Cookie，所以也能把这类循环暴露出来。

批量检查重定向

一次粘贴最多10个网址，每行一个，即可一次运行检查；重复项会被去掉，每个网址都有自己的结果。CSV导出每跳占一行，并重复输入的网址，所以你可以按状态筛选、按跳数排序，或把文件交给负责重定向规则的人。如果是一批旧书签或文档里的链接，先用书签文件查看器把网址提取出来，再用死链检查工具（每次可检查25个网址）找出哪些已经失效。对于整个网站，请用爬虫或服务器日志找出被重定向的网址，再用Googlebot用户代理在这里抽查重要的几个。

HTTPS、www和末尾斜杠

大多数网站应该只在唯一的一种协议加主机名的组合上提供内容，其他所有写法都以永久重定向、一步跳转到它。变体选项会用相同的路径检查http://example.com、https://example.com、http://www.example.com和https://www.example.com，并报告这四个是否都落在同一个网址上，以及各自需要几跳。提示会指出链条后段才发生的HTTPS升级、在www与非www之间来回切换不止一次的链条，以及只是增删末尾斜杠或改变字母大小写的跳转，这些都很容易并入第一次重定向。

为什么结果可能与浏览器不同

如果你的浏览器去了别的地方，通常是因为它记住了某些东西。RFC 9110允许缓存301，所以浏览器可能跳过一条旧的重定向，或者继续执行你已经删掉的那一条。浏览器一旦见过某个网站的HSTS头（或者该网站在HSTS预加载列表中），就会在任何请求离开你的电脑之前，在内部把http://升级为https://。Cookie、你的语言和你的位置也会触发各自的重定向。检查工具每次都从零开始，报告服务器实际发送的内容，这正是对爬虫和首次访问者有意义的视角。

检查工具的工作原理

每一跳都是由Marqly在Cloudflare上的服务器发出的GET请求，重定向设置为手动，因此在检查工具记录下来之前，什么都不会被跟随。每个主机名都会被解析，并且必须指向公网地址；私有网络、localhost和云元数据地址会被拒绝，即使链条中途有一次重定向指向它们。每一跳有6秒超时，整条链在20秒或10次重定向后停止，页面正文会被丢弃，只有最终HTML页面的前64 KB例外，这部分会被扫描以查找meta refresh。不会存储任何内容：结果只存在于你的浏览器标签页里。

在分享一个经过重定向或短链接服务的链接之前，请先用URL清理工具去掉多余的跟踪参数。如果你在制作推广链接，UTM生成器可以生成它们，而本检查工具能确认这些参数在每一跳之后依然保留。最终页面加载出来之后，可以用Open Graph检查工具查看它提供的标题、描述和社交预览。