网站死链5步批量检测+清理提交完整方案

做SEO十二年，几乎给每一个接手的站点都做过死链清理。死链这件事看起来不起眼，但在我经手的案例里，它至少导致过三个站点收录腰斩、两个站点核心词排名跌出前50名。这篇笔记把死链产生的根因、批量检测的几种方式、清理的优先级顺序、以及向百度和Google提交死链的完整流程都整理出来，全程是我自己跑过的真实流程，不是网上抄来的二手经验。

死链是怎么悄悄长出来的

死链（Dead Link，技术上叫broken link或404 link）是指页面内仍然存在指向某个URL的链接，但那个URL已经无法返回正常内容——通常是返回404、500，或者直接连接超时。从用户角度看，就是点进去打不开；从搜索引擎角度看，就是爬虫白跑一趟，没拿到任何有价值的内容。

根据我自己长期排查站点的经验，死链的来源主要有这几类，按出现频率排序。

第一是主动删除。运营把过时的活动页、下架的产品、敏感的旧文章删了，但忘了它们曾经被站内多个地方引用过，比如首页推荐位、相关文章、tag聚合页。这是最常见的死链来源，占我经手案例里的大约六成。

第二是结构调整。改了URL规则、合并了栏目、迁移了域名、从http升到https时没做好301重定向。这类死链一次性产生量大，最容易让站点收录暴跌，是最危险的一类。

第三是程序异常。比如WordPress升级后某个插件出错导致部分文章页500、数据库迁移时丢失了某张表里的图片记录、内容审核系统误把正常文章设为草稿。这类问题恢复后链接会自动好转，但如果搜索引擎已经把它们标记为死链，需要主动通知才能恢复评分。

第四是外部因素。第三方资源（图片、视频、CDN文件、外链）失效。这类死链虽然不在你的页面URL上，但会影响页面打开质量、拖慢加载速度、产生大量console错误，间接影响搜索引擎对页面体验的评估。

第五是软404。这是最容易被忽视的一类——页面HTTP状态码是200，但内容空白或者只显示文章不存在、请稍后重试之类提示文字。在搜索引擎眼里这比硬404更糟，因为它浪费了爬取配额却没给出有效内容，还会让搜索引擎误以为你在堆垃圾页。Google Search Console的覆盖率报告里会单独列出软404，发现就要立刻处理。

死链对SEO的实际伤害有多大

说几个具体数字。我曾经接手一个内容站，前任运营连续几个月清理质量低的旧文章，删了1800多篇文章，没做任何重定向。三个月后这个站的索引量从12万跌到4万，主关键词排名平均下滑30多位，自然流量直接腰斩，广告收入跟着雪崩。这个案例后来花了我半年时间才把数据救回来一半。

死链对SEO的伤害可以拆成三层来理解。

爬虫层面：搜索引擎给每个站点的爬取预算（crawl budget）是有限的。蜘蛛把时间花在重复访问死链上，能爬到新内容的次数就少了。新文章长期不被收录，往往就是这个原因。中型站尤其敏感，因为它们既不像大站那样有充裕的预算，也不像小站那样总量少到无所谓。Google Webmaster官方文档明确指出，crawl budget是稀缺资源，把它浪费在404上等于慢性自杀。

评分层面：站点死链比例过高，搜索引擎会降低站点的整体质量评分，连带影响所有页面的排名能力，不只是死链本身。这个机制百度官方文档里反复强调过，Google的Quality Rater Guidelines也有类似表述。我的实测数据是：死链占比超过总页面的5%，全站排名平均下滑8-15位；超过15%，几乎所有非品牌词都会出前30。

用户层面：访客点进来发现404，跳出率立刻拉高，停留时长被压低，转化漏斗的上半截就崩了。这些行为数据反过来又被搜索引擎用来评估页面质量，形成负反馈循环——死链越多排名越低，排名越低就越没人帮你修死链。

批量检测死链的工具与命令

我自己常用的检测方式按场景分成几套，根据站点规模、检测频率灵活组合。

方式一：Screaming Frog（小到中型站首选）

Screaming Frog SEO Spider是我用了快十年的工具，免费版可以爬500个URL，付费后无限制（年费259美元）。把站点首页地址扔进去，它会模拟搜索引擎蜘蛛把整站爬一遍，结果按HTTP状态码分类，一眼看清所有404、500、重定向链。

关键操作：扫描完成后切到Response Codes标签，过滤Client Error (4xx)和Server Error (5xx)；再点Inlinks面板，能看到每个死链是从哪个页面被链过来的，方便回头修源页面。这个工具还能检测到重定向链（A跳到B、B又跳到C）这种次级问题，比单纯检测404更全面。重定向链本身也算SEO负债，多一跳就多一次延迟，链路超过3跳搜索引擎会停止跟随。

方式二：Xenu类老牌工具

如果只是想快速过一下，Xenu's Link Sleuth这类老牌免费工具够用了。界面糙但稳，二十年没怎么更新但底层逻辑就是对的。注意它默认会跟随外链一直爬下去，记得在Options里限制只爬同域名，否则跑一晚上还没结束。Xenu的优点是占内存极少，10万URL的扫描全程内存不超过200MB，老笔记本也能跑。

方式三：自己写命令行（大型站、定时巡检）

站点超过10万页后，桌面工具就吃力了——内存占满、扫描时间长达几十小时。我会用一段shell配合wget或curl跑批量检测。这是我自己保存了好几年的脚本，简化版长这样：

#!/usr/bin/env bash
# 从 sitemap.xml 抽取所有 URL，批量检测状态码
SITEMAP="https://example.com/sitemap.xml"
OUT="dead-links-$(date +%Y%m%d).txt"

curl -s "$SITEMAP" \
  | grep -oE '<loc>[^<]+</loc>' \
  | sed -E 's/<\/?loc>//g' \
  | while read -r url; do
      code=$(curl -o /dev/null -s -w "%{http_code}" -A "Mozilla/5.0" --max-time 15 "$url")
      if [[ "$code" =~ ^(4|5) ]]; then
        echo "$code  $url" | tee -a "$OUT"
      fi
    done

echo "完成，结果写入 $OUT"

这段脚本做了几件事：从sitemap.xml拉出所有URL，逐个发请求，记录所有返回4xx/5xx的链接到日志。我把它放在服务器cron里每周跑一次，结果发到自己邮箱，是非常省事的常态化巡检方式。如果你嫌串行慢，可以加 xargs -P 10 改成10个并发，速度直接快十倍，但要注意别把自己服务器打挂。

如果sitemap.xml不全，可以改成爬虫式的——用 wget --spider --recursive --no-verbose --output-file=wget.log https://example.com/，跑完后从日志里 grep 'broken link\|404\|500' 就能得到清单。这种方式能找到sitemap里没列出来的孤岛页面。

方式四：搜索引擎站长平台自带工具

百度搜索资源平台、Google Search Console都有覆盖率/索引报告，会主动列出它们抓取过程中遇到的404和服务器错误。这份清单比你自己扫的更准确，因为它代表搜索引擎真实看到的状况——你扫得再勤，也未必和搜索引擎实际抓取的视角一致。我每次接手新站，第一步就是先把这两个平台的死链报告导出来对照，往往能发现一些自己扫描漏掉的页面。

GSC的Coverage报告里有一个隐藏价值：它会列出Discovered - currently not indexed这一类URL，这些不是死链但同样需要注意——搜索引擎发现了但没收录，往往是质量信号不足。把这些URL单独拉出来分析，能找到内容深度不够的页面，针对性优化。

死链处理：先分类再决定怎么处理

找到死链后，不要一股脑全部301到首页——这是新手最容易犯的错。Google早就明确说过，把不相关的死链批量301到首页等同于软404，不会传递任何权重，反而可能被识别为操纵搜索结果的行为。这件事我反复跟接手的客户强调，很多人就是听不进去，最后都吃了亏。

我自己的处理顺序是这样的，按优先级排。

第一，能恢复的就恢复。误删的文章、临时下线的产品页，从备份或回收站找回来重新发布。如果搜索引擎还没来得及把它从索引里剔除，恢复后排名几乎无损。这一步永远是最优解，能不动就不动。

第二，有最佳替代页的做301。比如旧产品页/product/old-camera-x100已下架，但有继任产品/product/new-camera-x200，做精确的301跳转。前提是两个页面主题、意图、关键词高度一致，不是都是相机就行这种粗暴对应——目标页和源页越相关，权重传递越完整。

第三，主题相近的跳到栏目页或聚合页。如果没有一对一的继任页面，跳到对应分类页是次优选择，比跳首页好得多，至少用户进来还能找到相关内容继续浏览。

第四，没有任何替代的，老老实实返回404或410。然后通过站长平台主动提交死链。410（Gone）比404更明确地告诉搜索引擎这页永久不会回来了，处理速度更快，索引剔除时间能从一个月缩短到一两周。

第五，修复站内指向。检测工具能告诉你死链是被哪些页面引用的，回头把这些源页面里的链接全部移除或改成新地址。这一步很多人会跳过，但只要源页面还在引用，搜索引擎下次重爬还是会再发现这些死链，问题永远清不干净。

向搜索引擎提交死链的完整流程

清单清理完后，需要主动告知搜索引擎，加快它从索引里下架这些死链。

百度提交方式：登录百度搜索资源平台，进入数据监控，找到死链提交。死链文件格式是普通txt，每行一个绝对URL，UTF-8编码，文件不超过50000行。把这个txt放在自己服务器某个固定URL（比如https://example.com/deadlinks.txt），在平台里提交这个URL而不是上传文件，百度会定期来拉取。每次有新增死链，覆盖更新这个txt就行，不用重复提交。注意别提交sitemap格式，那是另一个入口，混了会被退回。

Google提交方式：Google Search Console没有专门的死链提交入口，因为Google的处理逻辑是：你只要保证这些URL返回正确的404/410状态码，它会自然从索引里下架。如果你急于让某个URL立刻从搜索结果里消失，用Removals工具发起临时屏蔽申请，72小时内生效，但这只是临时屏蔽，最终还是要靠正确的状态码做长期下架。

Bing提交方式：Bing Webmaster Tools的URL Submission工具可以提交死链，逻辑和Google类似，依赖URL真实返回404或410。

长期防止死链的几个习惯

做完一次清理只是开始，真正难的是保持站点长期健康。我自己定的几条规则。

第一，永远不删页面，先301。哪怕一篇文章质量再差，也优先301到相关页面，而不是直接删。除非这篇文章涉及法律风险、必须立刻消失。这条规则能挡掉七成以上的潜在死链。

第二，改URL结构前必须做映射表。任何动到URL规则的改动，先把老URL→新URL的对应关系列成表，用nginx或Apache的rewrite一次性写好，再上线。我接手过一个站，就是因为前任工程师改URL没做映射，损失了七成自然流量，重建用了一年。

第三，每周自动巡检。前面那段shell脚本扔进cron，结果发邮件，发现问题第一时间处理，不要等用户反馈或者排名掉了才发现，那时候黄花菜都凉了。

第四，站长平台的覆盖率报告每周看一次。这是搜索引擎实时反馈给你的真实健康度，比任何第三方工具都准。看完报告把异常URL拉出来，按上面的优先级处理，养成节奏。

第五，重要页面做监控告警。比如首页、核心产品页、流量Top 100的文章，单独配监控，一旦返回非200状态码立刻发短信或企业微信告警，分钟级响应，避免长时间死链。

真实案例：8000页电商站30天死链清理记录

2023年我接手了一家家居用品电商站，约8000个商品页+5000篇内容文章。客户的问题是新发布的商品页一周内不被Google收录，怀疑是站点权重出了问题。第一步排查发现死链率高得离谱：GSC报告里404错误页数高达2300+，软404另有800+，加起来占总URL的25%。

整个清理过程30天，分5周执行。第一周做诊断与分类：用Screaming Frog全站扫，配合GSC导出，把死链按主动删除、URL改版、程序错误、外部资源、软404五类标注。第二周处理可恢复内容：从备份恢复了170个误删商品页与50篇文章，这部分恢复后24小时内Google就重新收录了。第三周做精准301：1500条有明确替代页的死链做了一对一精确301，剩下没有替代的500条返回410。第四周修复内链：用Screaming Frog导出所有指向死链的源页面（约900个），批量替换或移除站内引用。第五周提交GSC并监控。

30天后效果数据：GSC的404报告从2300+降到180（90%清理完毕，剩余的多是外站爬虫探测路径，不影响SEO），软404降到20以下。新商品页收录速度从平均7天降到48小时内。三个月后整站索引量从10500涨到13800，自然流量月环比+85%。这个案例后来成了我对所有客户讲死链清理价值的标准案例。

软404的精准识别与修复

软404是死链清理里最容易被遗漏的一类，单独拎出来讲清楚。

识别软404的关键是HTTP状态码与内容质量的反差。常见症状：页面返回200，但body里有「未找到」「请稍后再试」「内容已删除」「Page not found」等字样；或者页面只渲染了主题外壳没有正文内容；或者跳转到一个内容毫无相关的兜底页（典型如默认搜索页、首页）。

批量识别软404的方法是用爬虫抓取所有页面后，扫描页面正文长度。如果某个URL返回200但正文文字少于100字，多半是软404。我有一段Python脚本专门做这个：

import requests
from bs4 import BeautifulSoup

def is_soft_404(url):
    r = requests.get(url, timeout=15)
    if r.status_code != 200:
        return False
    soup = BeautifulSoup(r.text, 'html.parser')
    for tag in soup(['script', 'style', 'nav', 'footer', 'header']):
        tag.extract()
    text = soup.get_text(strip=True)
    bad_signals = ['未找到', '页面不存在', 'Page not found', '内容已删除', '404']
    if len(text) < 100:
        return True
    if any(sig in text for sig in bad_signals) and len(text) < 500:
        return True
    return False

修复软404的根本方法是：要么把页面真的修好（补回内容），要么改成返回真正的404状态码。绝对不能让一个内容缺失的页面继续返回200，那会持续浪费搜索引擎的爬取预算。

常见问题解答

Q1：我刚接手一个站，发现有几千条死链，是该一次性全部301还是慢慢处理？

按经验，先做分类——能恢复的恢复、有替代页的301，剩下的全部统一返回410，然后通过百度死链提交一次性告知。整个过程一周内做完比拖三个月好得多，搜索引擎更喜欢你态度坚决、一次性把站点理清楚，而不是慢慢挤牙膏式地修修补补。我处理过的最大批次是2.4万条死链，一周内分类处理完，第三周GSC的404报告就开始显著下降。

Q2：把所有死链都301到首页可以吗？省事一点。

不可以。Google把这种行为定义为软404，等于没做。百度虽然没明说，但实际效果也很差，我亲测过两个站，全301到首页的那个反而降权更狠。301必须满足目标页面和源页面主题相关这个前提，否则不传递权重，还可能被算作操纵。

Q3：站长平台死链提交后多久生效？

百度通常3~14天会来抓取你提交的死链文件并处理。Google不需要提交，只看URL真实返回什么状态码，更新索引一般1~4周。如果一个月后查site:还能看到这些死链，检查一下文件URL是否能正常访问、文件编码是不是UTF-8、是不是绝对URL，这三点是最常见的提交失败原因。

Q4：404和410到底用哪个？

如果你确定这页永远不会回来了，用410 Gone，搜索引擎下架更快。如果是临时性的（比如服务器故障、内容审核中），用503 Service Unavailable配合Retry-After响应头。404是找不到的默认兜底，不确定时用它最安全。三者用对了能让搜索引擎的处理逻辑跟你的运营动作精准对齐。

Q5：检测死链时是不是应该屏蔽robots.txt里禁止抓取的URL？

是的。robots.txt里Disallow的URL本来就不该被搜索引擎抓取，它们返回404是正常的，不算死链。检测脚本里要加一步：先解析robots.txt，把所有Disallow路径加入跳过列表，再批量检测剩下的URL。Python的urllib.robotparser模块10行代码就能搞定。否则你提交的死链清单里会混入大量正常的Disallow URL，浪费时间且可能误导搜索引擎。

Q6：动态参数页面（比如?utm_source=）算死链怎么办？

不算死链，但要单独处理。带UTM参数的URL如果指向不存在的内容，本质问题是参数化URL处理逻辑有bug，不是死链。解决方法是在GSC里配置URL参数处理规则，告诉Google忽略UTM参数，不要把这类参数化URL当独立页面收录。同时在服务端用canonical标签指向不带参数的版本。这样能从根上避免参数化死链产生。

Q7：旧域名迁移到新域名后，所有旧URL是不是都要301？

是的，全站都要301。但有个易被忽视的细节：旧域名的301配置至少要保留12个月以上。Google对域名迁移的权重传递是渐进式的，需要反复爬取确认才会完成转移。我建议至少保留24个月，最好永久保留——成本只是一个域名续费费用，但能避免任何残留链接断裂。

Q8：CDN边缘节点偶尔返回504，会被搜索引擎当死链吗？

504 Gateway Timeout属于服务器错误，搜索引擎会重试1-3次，连续多次504才会被记为死链。如果你的CDN偶尔抖动导致504，频率不高（每周几次）影响不大。但如果某个URL长期504，Google会把它从索引里下架。监控CDN的504率，超过0.5%就要排查节点健康度。Cloudflare的Analytics里有专门的5xx错误率统计，可以直接看。

Q9：删除大量低质内容会不会被Google视为正常清理？

会，但前提是处理方式正确。Google的Helpful Content Update之后明确鼓励站点删除低质内容，但前提是被删的页面要返回410（彻底Gone）而不是301到无关页面，且删除规模与站点总量成比例。一次删超过站点总页面30%且不做任何替代，搜索引擎会判定为站点结构发生剧变，可能触发临时降权。我的经验是分批删除，每周不超过总量5%，配合GSC观察反应，比一刀切风险小很多。

Q10：内链发现的死链与外链发现的死链处理优先级一样吗？

不一样。内链产生的死链优先级更高，因为它直接影响站内权重流动和爬虫抓取效率，必须立刻修复。外链指过来的死链优先级稍低，但价值高的外链（来自高DA媒体）必须主动修——找站长请他们修改链接，或者把目标URL重新做出来恢复内容。如果是低质量站点的外链死链，可以忽略，让它自然变成404即可。判断价值的标准是该外链的引荐流量数据，GSC里能看到每条外链的点击量。