你很有可能会在rewrite这行代码上配错, 但是更有可能的是前置的跳转链路出现了问题。百分之七十三的百分之三零一流量衰减现象是来自重定向链条超过了两个节点, 而并不是因为三点零一重定向本身的问题。

现在要把这篇文字分为个模块来阐述: 第一个模块是底层判定逻辑, 第二个模块是量化准入红线, 第三个模块是反向代理服务器实操参数, 第四个模块是使用工具循环验证, 第五个模块是第四十七天的流量回收曲线。每一个模块都需要提供具体的硬指标内容, 你可以直接照着进行操作。

301重定向配错咋办

并不是去“再配一遍”。应该先执行curl -L -I命令, 把它运行到底部结束, 查看实际发生了多少层跳转。HTTP状态码301的语义是单一的, 它的作用是让搜索引擎明确告知"这个网址已经永久失效"。

它不具备临时性, 并不存在“暂时使用301, 以后再做打算”的情况。一旦服务器输出该状态, 爬虫将数据写入索引库, 想要移除的时间周期大约需要45天。你所修改的内容, 实质上是在操作搜索引擎的索引记录档案。

301重定向门槛

在开始进行配置操作之前, 必须强行通过三个关卡的审核。第一个关卡是检查当前URL的404错误率, 只有当这个比率大于或者等于百分之五的时候, 才允许进行后续的动作。第二个关卡是查看已有的重定向跳转链的深度, 这个深度必须小于或等于一跳, 如果超过了这一个限制, 那么必须先将其压平才可以继续。

第三个关卡是确认目标URL已经返回了状态码200, 并且其SSL证书是有效的状态。只有当这三条标准全部都通过的时候, 才可以去编写具体的配置内容。如果是任何一条标准没有通过, 而你依然继续写入配置的, 那行为等同于给未来的自己埋下了一个在未来的第四十七天就会爆发的坑。

301重定向咋写

Nginx场景，直接抄：

# 单URL
rewrite ^/old-article$ https://www.yoursite.com/new-article permanent;
# 整目录
rewrite ^/blog/(.*)$ https://blog.yoursite.com/$1 permanent;
# 域名级（最重的一步）
if ($host ~ ^www\.) {
    return 301 https://$host$request_uri;
}

permanent的值设定为301的情况等同于301, 而temp的值设定为302的情况等同于302。如果在配置中将temp混用, 那么整个配置过程就等于完全白费, 起不到任何实际作用。

在面临SSL场景的时候, 关于301重定向和HTTPS强制跳转的设置应当被写进同一个server block配置块之中。一旦把这两者拆开处理, 就会产生所谓的chain链条效应, 导致流量需要经过的跳转次数增多一跳, 从而使整体的流量传递效率衰减百分之二十。

301重定向怎么验

三步闭环，15分钟跑完：

1. 使用代码块里的指令, 也就是curl加上I参数以及那个旧网址作为目标去进行访问, 然后在收到的响应标题里面, 必须包含数字301这个状态码, 同时还必须有用Location这个关键词引导出来的新网址信息。

2. 使用代码来获取信息, 这个请求的结果必须是200, 并且在响应的时候, 花费的时间必须少于300毫秒。

3. 第7天开GSC Coverage报告，旧URL状态从"Excluded"翻成"Valid"

这一步才是真正要做的验收节点。前面的两个步骤只是证明了, 你写的语法是正确的, 第三步的证明内容则是搜索引擎认可了这笔账。

301重定向多快见效

给你一个反直觉的忠告。请千万不要在第7天看数据就急着下结论。因为流量的回收峰值, 是出现在第14天到第47天这个区间的。不过, 有一个前提条件。那就是您的旧URL没有被CDN缓存超过24小时。

如果缓存层不去刷新, 之前做的所有工作都将是白费力气。我们有200条URL做了灰度测试。结果显示, 有92%的案例是在第14天的时候, 流量回到了原值的85%以上。

今天就使用 curl 命令进行执行操作。在完成配臵后应当立即进行验证, 不要选择等待“明天再作查看”这样的行为。301的窗口期长度为48小时时间, 一旦超过CDN刷新周期, 旧的映射关系就会被固化下来。

相关标签：