什么是死链，为什么站长必须重视它
死链，简单说就是点击之后打不开的链接。访客点进去看到的是"404 Not Found"或者一片空白，轻则损失一次访问，重则让访客对你的网站产生"没人维护"的印象，直接关掉走人。对搜索引擎来说，死链的危害更大：蜘蛛顺着链接爬过来发现是 404，一次两次没什么，如果站内死链成百上千，搜索引擎会认为这个站内容质量差、维护不善，进而降低整站抓取频率和权重分配，这就是很多网站改版之后收录骤降的原因之一。
尤其是个人站长，网站经历过换域名、换程序、改 URL 结构、删旧文章之后，死链几乎是必然出现的。这篇文章就来讲清楚：死链是怎么产生的、怎么把站内死链全部找出来、以及针对不同类型的死链分别该怎么处理，让网站对访客和搜索引擎都保持友好。
死链是从哪来的
想治理死链，先要知道它们通常产生在哪些环节：
- 网站改版改变了 URL 规则。比如原来文章地址是 /post.php?id=123，改成伪静态 /123.html 之后，旧的动态地址全部失效，而搜索引擎索引里还存着大量旧地址；
- 删除了文章或栏目。直接删掉内容而没有做任何跳转，原来收录的地址就成了死链；
- 换域名或换目录。整站从旧域名迁移到新域名，外部网站和搜索引擎里留着的都是旧域名链接；
- 站内引用错误。模板改版时写错了链接，或者文章里引用了早已不存在的内部页面；
- 程序或插件生成的错误链接。某些统计代码、广告代码、分页功能在特定情况下会拼出错误的 URL。
搞清楚来源之后，处理起来才能对症下药。比如改版造成的死链适合做 301 跳转，而纯属拼写错误的链接直接改掉就行。
如何把死链全部找出来
找死链主要有三条路：日志分析、爬虫工具、搜索引擎站长平台。个人站长资源有限，最推荐从访问日志入手，因为日志里记录的是真实用户和搜索引擎蜘蛛实际访问过的地址，最有价值。
Nginx 默认的 access.log 里，每一行记录一个请求，第九个字段是 HTTP 状态码。用下面这条命令，就能统计出访问量最高的 404 地址是哪些：
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20其中 $7 是请求的 URL 路径，$9 是状态码。统计结果里排在前面的，就是被访问最多、最值得优先处理的死链。想看某个具体地址是不是真的返回 404，用 curl 验证一下状态码即可：
curl -I -s -o /dev/null -w "%{http_code}\n" https://www.example.com/old-page.html除了日志，还可以用 Xenu Link Sleuth 这类桌面爬虫工具对整站链接做一次体检，它会顺着站内链接逐页爬取并标出所有失效链接，适合改版后做全站检查。另外，百度搜索资源平台提供"死链提交"工具，Google Search Console 的"网页索引编制"报告里也会列出 Google 发现的 404 页面，这些都是官方渠道，处理完死链后应该去那里提交或确认。
看访问日志还有一个额外的好处：它能帮你区分死链的"热度"。有些 404 地址一天被访问几十次，说明是重要的旧链接，很可能还有外部网站在引用，应该优先做 301 跳转；有些 404 地址一年到头只有搜索引擎蜘蛛来过一两次，这种直接清理掉即可。判断的时候可以先用 awk 把爬虫的访问过滤掉，只统计真实用户碰到的 404，处理优先级就一目了然了。
处理策略：能跳就跳，不能跳就明确"死了"
找到死链之后，不要一律简单删除，而是按下面的原则分类处理：
- 内容还在，只是换了地址：用 301 跳转到新地址，把旧页面的权重传递给新页面；
- 内容删了，但有相似或相关的页面：301 到最相关的新页面，让访客和搜索引擎都能顺藤摸瓜；
- 内容彻底不存在了，也没有替代页面：让它返回真实的 404 状态码，并做好友好的 404 页面，引导访客去首页、栏目页或使用搜索；
- 确定永远不会再恢复的内容：可以返回 410 Gone 状态码，这比 404 更明确地告诉搜索引擎"此页面永久删除"，有助于搜索引擎更快地把它从索引里清除。
这里有一个非常重要的细节：处理跳转时，如果新旧地址的对应关系还没有最终确定，先用 302 临时跳转过渡，等规则稳定后再改成 301。因为 301 是永久跳转，浏览器和搜索引擎都会长期缓存跳转关系，一旦跳错目标，纠正的成本很高。
Nginx 下配置 301 跳转实战
个人站长绝大多数用的是 Nginx，下面给出最常见的两种场景配置。第一种：单条旧地址跳转到新地址，适合文章改版后手动维护一批规则：
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
# ssl 证书配置省略
location = /post.php {
return 301 /article/123.html;
}
location /old/ {
return 301 /new/;
}
}第二种：整站换域名，把旧域名的所有请求统一 301 到新域名对应路径，适合网站搬家场景：
server {
listen 80;
listen 443 ssl;
server_name old-example.com www.old-example.com;
# 旧域名的 ssl 证书配置省略
return 301 https://www.new-example.com$request_uri;
}这里用 $request_uri 保留原始路径，访客访问旧域名的 /about.html 会被原样跳到新域名的 /about.html，最大化保留已有权重。改完配置记得先测试再重载：
nginx -t
nginx -s reload还有一个和死链高度相关、却经常被忽略的场景：HTTP 与 HTTPS 之间的跳转。如果你的站点已经全站开启了 HTTPS，而搜索引擎索引里还残留着大量 http:// 开头的旧地址，一旦服务器没有把 http 请求 301 到 https，这些地址同样会变成死链。很多站长排查半天发现"页面明明在，就是打不开"，原因就在这里。所以启用 HTTPS 时，记得像上面的配置一样保留一条 http 到 https 的整站 301，别把 80 端口直接关掉。
404 页面的正确打开方式
死链处理的下半场，是让"该死"的链接死得体面。很多个人网站的 404 页面存在两个典型问题：一是返回了错误的 HTTP 状态码，二是页面内容空空如也。
先说状态码。有些站长为了让访客"感觉网站一切正常"，把 404 页面做成了 200 状态码，这叫软 404。搜索引擎看到 200，会认为这个地址是有效页面，继续收录、继续抓取，结果就是一堆内容雷同的无效页面堆积在索引里，稀释整站权重。正确的做法是让不存在的页面真实返回 404，Nginx 配置如下：
error_page 404 /404.html;
location = /404.html {
internal;
}如果你是 PHP 程序处理的 404（比如 Typecho、WordPress 的主题 404 模板），要确认程序最终输出的状态码确实是 404，而不是默认的 200。PHP 里可以这样显式指定：
http_response_code(404);验证方式很简单，对任意一个不存在的地址执行 curl -I，看返回的状态码是不是 404：
curl -I -s https://www.example.com/this-page-not-exist.html | head -1再说页面内容。一个合格的 404 页面应该包含：一句简洁的说明（页面不存在或已被移动）、指向首页的链接、热门栏目或最新文章的推荐、站内搜索框。这样访客虽然迷路了，但依然有路可走，跳出率不会太高。千万不要用 JS 自动跳转把访客强行带去首页，那会让搜索引擎分不清这个地址到底是有效还是无效。
建立死链监控的长效机制
死链治理不是一次性的活。网站持续更新，死链就会持续产生，所以建议把 404 统计做成一个定期任务。最简单的方式是写一条 crontab，每周跑一次日志统计并把结果发到邮箱：
0 3 * * 1 awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30 | mail -s "本周404统计" you@example.com注意：如果 Nginx 配置了日志切割，上面统计的只是当前日志文件，跨周统计前记得把切割出来的历史日志一起合并处理。收到统计邮件后，把新出现的、访问量大的 404 地址纳入 301 规则或者修正站内链接，形成"发现—处理—复查"的闭环。坚持两三个月，站内的死链会越来越少，搜索引擎对整站质量的评价也会随之改善——这在权重和收录上带来的回报，远比花力气多发几篇水文实在。