当前位置:首页 >  站长 >  搜索优化 >  正文

全站死链监控:别让烂内链拖住蜘蛛的后腿

 2026-09-09 10:43  来源: 互联网   我来投稿 撤稿纠错

  一键部署OpenClaw

改版、删文章、换栏目,最先烂掉的不是页面而是内链。烂内链的代价常常被低估:用户点进去 404 是体验问题,更重的是蜘蛛顺着内链爬行时一遍遍撞墙,抓取预算被无谓消耗,深度页面的发现效率跟着下降。单页小站可以用 W3C 的 Link Checker 在线查,几个 URL 等一分钟就出结果;页面一多就得自己动手了。

自建监控的思路是个简化爬虫:从首页出发抓页面,提取站内链接,逐个请求验状态码,404、超时、5xx 全记下来,再顺着新发现的链接往外爬,直到全站扫完。加个线程池并发提速,但要压住并发数——扫描自己是别把自己扫挂了。

import re, requests
from concurrent.futures import ThreadPoolExecutor
from urllib.parse import urldefrag

HEADERS = {"User-Agent": "Mozilla/5.0 (compatible; linkcheck/1.0)"}
BASE = "https://www.网址 .com"

def check(path):
r = requests.get(BASE + path, headers=HEADERS, timeout=10)
return path, r.status_code

def get_links(path):
r = requests.get(BASE + path, headers=HEADERS, timeout=10)
r.raise_for_status()
links = set()
for href in re.findall(r'href="([^"#]+)"', r.text):
u = urldefrag(href)[0]
if u.startswith("/") and not u.startswith("//"):
links.add(u)
return links

主循环用一个待爬队列加已访问集合去重,发现死链就落名单。图片、CSS 这类资源链接会被 href 正则自然漏掉,不过死链监控的重点是页面级链接,够用了。真要连资源一起查,把 src 属性也抓出来丢进检查队列即可。

seen, bad, todo = set(), [], ["/"]
with ThreadPoolExecutor(max_workers=5) as pool:
while todo:
path = todo.pop()
if path in seen:
continue
seen.add(path)
try:
links = get_links(path)
todo.extend(links - seen)
except requests.RequestException as e:
bad.append((path, type(e).__name__))
continue
# 页面本身状态码验证(并发)
for p, code in pool.map(check, [path]):
if code >= 400:
bad.append((p, code))

print("共检查", len(seen), "个页面,死链", len(bad), "个")
for p, why in bad:
print("死链:", p, why)

验证环节别偷懒:脚本报出的死链逐条用 curl -I 复核一遍,排除掉脚本自己的网络抖动误报。确认是真死链后,修法和之前讲的一致——有替代内容的 301,没有的保持 404,同时回头修掉站内指向它的入口,这才是闭环。光清死链不修入口,下周再跑一遍又是一样一批。

# 复核脚本报告的死链
curl -sI https://www.example.com/old-tag/seo | head -1

# 挂进 crontab,每周一凌晨 4 点全站扫一次
0 4 * * 1 /usr/bin/python3 /opt/seo/linkcheck.py \
>> /var/log/linkcheck.log 2>&1

脚本扫完还能做一步交叉分析:拿爬虫见过的 URL 集合,和蜘蛛日志里撞 404 的 URL 清单对比。蜘蛛撞了、爬虫却从来没发现过链接的,说明入口不在站内,多半来自外链或搜索引擎缓存的旧地址——这类死点站内修不了,只能靠 301 接住,两份工具互相补盲区。

收尾划一下和断链建设的边界:之前写过一篇断链建设,那是去找别人网站上指向本站却失效的外链,属于外链资源回收;这一篇是守住自己站内的链接质量,属于内功。一外一内互不替代。W3C Link Checker 的正确用法是抽查新页面和小站全检,自建爬虫管全站例行监控,两件工具放在一个工具箱里正好。

相关阅读:全站死链扫描吃资源,跑的频率有讲究。《SEO 自动化总清单:日、周、月、季各该跑什么》把它安排在低峰时段的每周组,具体时间点总纲里给了现成排法。

申请创业报道,分享创业好点子。点击此处,共同探讨创业新机遇!

相关文章

  • 收录流量对照日报:一张 CSV 看清抓取、收录、流量三本账

    收录涨了流量没涨,或者收录掉了流量反而稳着——只盯单一指标的人迟早被这种背离搞糊涂。原因很简单:抓取、收录、流量是链条上三道独立的工序,蜘蛛来了不代表收进索引,收进索引不代表有排名,有排名不代表有人点。任何一道出问题,表象都像“SEO变差了”,但药方完全不同。解法是把三本账放进同一张表里天天对照。日

  • 收录批量核查:200 个 URL 别再一条条搜了

    发了200篇文章,过了两周想确认哪些被百度收了。到搜索框一条条敲site:查询,查到第30条手就废了。批量核查收录是每个内容站的刚需,但这件事有个必须先说清楚的边界:搜索引擎没有公开的收录查询API,任何批量查询本质都是在和对方的反爬机制打交道,所以脚本的正确姿势是慢、稳、粗查,快准狠交给官方平台。

  • 把 access.log 转成 CSV:awk 之外的第二条路

    前几篇的awk报表很顺手,但它有两个天花板:一是结果只能打印在终端上,要给不懂命令行的同事看、要丢进Excel做透视表,就得有个通用格式;二是复杂逻辑(多条件组合、正则提取、跨行关联)用awk写起来越写越拧巴。这时候就该Python上场了——把日志解析成CSV,一条命令跑完,后面随便怎么加工。解析N

  • 软 404:页面活着,收录死了

    上面那篇说404要从日志里挖,这一篇说一个日志挖不出来的更阴险的坑:软404。它的定义Google官方写得很清楚——一个URL返回的是200成功状态码,但页面内容却在告诉用户“这个页面不存在”,有时甚至是没有主内容的空页面。从HTTP协议看它一切正常,从内容看它已经死了。软404的常见诱因官方也列了

  • 从日志里挖出蜘蛛天天撞的 404 死点

    站改版半年了,站内链接自认清理得干干净净,蜘蛛却还在日复一日地撞404。这些死点从哪来的?旧外链指向被删的文章、搜索引擎库里缓存的旧URL、老sitemap的残留、站内漏改的某个入口——单靠人脑想,永远想不全。好消息是蜘蛛会把每一次碰壁都老老实实记在你的日志里,去日志里捞就行。思路是三步:从蜘蛛抓取

    标签:
    seo优化
    404死链

热门排行

信息推荐