Screaming Frog全站审计：12类问题排查清单

全站爬虫审计常被当成“装个Screaming Frog、跑一遍、看个红绿灯”的体力活，结果导出一堆CSV就卡住了，不知道下一步。它真正的价值不在导出多少报表，而在于把整个网站换成搜索引擎的视角重新看一遍——人眼一页页点，永远拼不出链接图的全貌；桌面爬虫能。一次像样的审计，考的是你能不能从爬取结果里，把抓取收录、重定向状态码、重复规范化、页面可提取性这四大类、十二小类结构性问题一个个定位出来，并且分清哪些必须改、哪些只是噪声。这篇给一套从配置到固化成季度制度、能复用好几年的完整流程。

全站爬虫审计到底解决什么GSC解决不了的问题？

先说一个很多人没想透的区别。Google Search Console给你的是“引擎已经怎么处理你的站”的结果——哪些页进了索引、哪些被判重复、哪些报了错。它是一份体检报告，但它不告诉你病灶之间的关系。桌面爬虫给你的是另一样东西：你这个站此刻的真实结构，链接怎么连、权重怎么流、哪条路通哪条路断。一个是结果，一个是结构，两者缺一不可。

举个最常见的场景。GSC的索引报告告诉你“已发现——尚未编入索引”有800个URL，你盯着这个数字干着急，因为它只给你一串URL，不给你这些URL之间的共性。把站爬一遍就清楚了：这800个里600个抓取深度都在第6层以下、平均要点6次才能从首页走到、内链入链数全部是1或0。结论一下子就出来了——不是内容质量问题，是结构问题，这批页被埋得太深，引擎算过抓取性价比之后懒得收。GSC让你看见症状，爬虫让你看见病因。

还有一类问题GSC根本不会主动报。孤儿页就是典型——一个页面没有任何站内链接指向它，但它在sitemap里、或者有外链进来，所以它能被收录、能有流量，可它在你的内链网络里是一座孤岛，权重灌不进去，你在后台翻菜单也永远翻不到它。这种页面GSC不会标红，因为对引擎来说它没坏；但对你来说它是一笔躺平的资产。要把孤儿页揪出来，唯一的办法就是拿爬虫从首页出发遍历一遍，再和完整URL清单做差集。

所以这件事的定位很清楚：全站爬虫审计是你定期给网站做的“结构性体检”，它和GSC、和服务器日志分析是三件互补的事，不是替代关系。GSC看引擎的判决，日志看爬虫的真实脚印，爬虫看你自己的结构。三者交叉，问题才无处可藏。

再补一个很多人忽略的点：爬虫审计是少数“做一次能管很久”的SEO投入。内容会过时、外链会波动、排名天天变，但一个站的结构性毛病——埋太深的目录、配错的canonical、失控的重定向链——一旦改对了，收益会持续好几年，而且它不挑行业、不挑流量大小。一个刚起步的独立站和一个十年老站，都该把它列进固定动作。这也是为什么本文不讲“怎么点按钮”，而讲“怎么从结果里读出病因、怎么把它做成制度”——前者查一下文档就会，后者才是审计真正的门槛。

Screaming Frog是怎么工作的？和Googlebot像在哪、不像在哪？

Screaming Frog SEO Spider是目前桌面爬虫里的事实标准，同类还有Sitebulb（更偏可视化和诊断建议）、以及云端的Lumar、OnCrawl、JetOctopus（偏大站和持续监控）。机制上它们是一回事：给一个起始URL，抓下来，解析出页面里所有的链接，再去抓那些链接，层层递归，直到没有新URL为止。这个过程和Googlebot遍历你的站，在“顺着链接走”这一点上是同构的。

正因为同构，爬虫能模拟出Googlebot眼里的你。它能告诉你：从首页出发，纯靠站内链接，到底能走到多少个页面；每个页面要走几步才到；哪些页面是死胡同；哪条链接断了。这套“可达性”视角，是审计的地基。

但要警惕，这个“像”是有边界的，把边界记清楚才不会误判。下面这张表把关键差异列出来：

这张表的实战含义是：爬虫能查出“结构通不通”，但查不出“引擎愿不愿意”。它告诉你某个页面可达、内链充足，但它不能替你判断引擎会不会因为抓取预算把它放掉——那得看日志。同样，默认不开渲染的爬虫，在一个重度依赖前端框架的站上会“瞎掉”，看到的是一具空壳。所以用爬虫的第一课，不是学按钮，是知道它的视野到哪儿为止。

开爬之前，爬虫该怎么配置才不跑偏？

很多人审计的结果不可信，问题出在第一步：配置没设，直接点了开始。默认配置跑出来的数据，经常是“对的工具、错的镜头”。一次审计开始前，至少要把下面几件事想清楚。

第一，渲染模式。如果你的站是传统服务端渲染，正文在HTML源码里就有，默认的纯文本抓取模式又快又准。如果是单页应用、或者关键内容靠脚本加载，必须切到JavaScript渲染模式，否则爬虫看到的页面和Googlebot渲染后看到的对不上，后面所有结论都建立在沙子上。判断方法很简单：右键随便一个内页“查看网页源代码”，如果正文文字在源码里搜得到，就是服务端渲染；搜不到、只有一堆div，就是客户端渲染。

第二，抓取范围。要不要抓子域名、要不要抓站外链接、要不要遵守robots.txt、参数URL抓不抓。这里有个反直觉的建议：审计时应该让爬虫无视robots.txt跑一遍。日常你当然要遵守robots，但审计的目的恰恰是要看清“被robots挡住的到底是哪些页、挡得对不对”——如果遵守robots，这些页根本不会出现在结果里，你就永远发现不了误屏蔽。所以审计跑两遍：一遍遵守、一遍无视，两份结果一对比，robots的真实影响就摊开了。

第三，爬虫身份和限速。用什么User-Agent抓（建议用Googlebot的UA，看到的更接近引擎视角），每秒抓几个、并发多少线程。这一条关乎别把自己的服务器爬崩——尤其是带WAF或CDN的站，并发太高会被当成攻击直接限流，跑出来一片429或503，那不是站的问题，是你把自己ban了。小站可以放开，大站和共享主机务必先压低速度试探。

第四，起点和补充清单。光从首页爬，只能爬到“内链可达”的部分；要看全貌，得把sitemap也喂给爬虫，甚至导入GSC里的全部已知URL。三个来源——首页遍历、sitemap、GSC清单——交叉起来，才是你这个站URL的完整宇宙。XML sitemap 在这里不只是给引擎看的，也是审计的一份关键输入。

抓取与收录类问题，怎么从爬取结果里挖出来？

配置妥当、爬完一遍，真正的活才开始。下面四个H2是审计的核心——四大类、十二小类问题，每一类我都说清楚“在哪个报表里看、看什么数字、怎么判断严重程度”。先从抓取与收录这一类讲。

孤儿页：有流量但没人链的资产

前面说过，孤儿页是站内零入链的页面。在Screaming Frog里，把sitemap和GSC的URL清单一起导入后，用它的爬取分析功能，能直接列出“在补充清单里、但首页遍历没碰到”的URL。这批就是孤儿页疑似名单。逐个看：如果是有价值的内容页却成了孤儿，赶紧从相关文章、分类页给它补内链；如果是早就该下线的旧活动页，该410就410。孤儿页本身不是病，放任不管才是。

保哥经手过一个跨境消费电子的独立站，审计时发现一批早年的产品评测文章成了孤儿页：文章本身写得不错、还零星有点外链进来，但当年发完之后博客改过版，导航和相关推荐的逻辑全换了，这批老文章谁也没链。结果就是它们孤零零挂在那里，排名一直在二三页晃，上不去也下不来。处理也不复杂——给每篇老评测从对应的产品分类页、从主题相近的新文章补上三五条语义自然的内链，把它们重新接回内链网络。这种活儿的回报往往被低估：你没新写一个字，只是把已经躺在那里的资产重新通上电。

抓取深度过深：埋得太深的页面

抓取深度，指一个页面距离首页的最短点击数。爬虫的报表里每个URL都有一个深度值。经验阈值：核心收录页面的抓取深度尽量压在3层以内，超过5层的页面被及时抓取和收录的概率显著下降。把结果按深度排序，如果发现大量商品页、文章页堆在第6、第7层，说明你的内链结构和分类设计出了问题——可能是分类太碎、可能是分页把内容越推越远。解法是做扁平化：加聚合页、加相关推荐、给重要页面更多的浅层入口。

robots与noindex误用：自己把自己屏蔽了

这是审计里最容易抓到“大鱼”的一类。前面说的“遵守和无视robots各跑一遍”，对比之后重点看两件事。一是robots.txt误屏蔽：有没有把该收的目录（比如某个产品线、某个内容专区）整个Disallow掉了——这种事在改版、迁移后特别常发，一行通配符写宽了，半个站就消失了。二是noindex误用：爬虫会把每个页面的meta robots指令读出来，筛一遍“带noindex的页面”，看看里面有没有本该收录的。保哥审过的站里，见过最离谱的一次是整个博客目录的模板被实习生加了一行noindex，挂了大半年没人发现，几百篇文章在索引里集体蒸发，流量曲线断崖式下跌却一直归咎于“算法波动”。这种问题，人眼翻一辈子后台也翻不出来，爬虫一遍就揪住。

重定向与状态码类问题，怎么逐一排查？

状态码是页面的“健康信号”。爬虫会把每个URL的响应码、跳转目标全列出来。这一类问题，详细的状态码语义可以另看 HTTP状态码完整图谱，审计里重点看下面三种。

重定向链与重定向环

重定向链，指A跳B、B又跳C这种多级跳转。每一跳都会损耗一点权重、增加一点抓取成本，引擎对超过若干跳的链条会直接放弃跟踪。重定向环更糟——A跳B、B又跳回A，页面永远打不开。在爬虫报表里筛“重定向链长度大于1”的URL，把它们的最终目标拉出来，全部改成一步直达。一个跑了十年、改版过四五次的老站，重定向链几乎是必然存在的，因为每次改版都在上一轮跳转上再叠一跳，从不收敛。审计时把它们一次拉平，抓取深度和效率会肉眼可见地改善。

内链指向404：站内的断头路

这是体验和抓取双输的问题：站内有链接指向一个已经404的页面。用户点了撞墙，爬虫顺着链接抓到一个死页、白白浪费一次抓取。爬虫报表里筛响应码404、再看它的“入链”报表，就知道是哪些页面挂着这条死链，逐个去源头页面修掉或删掉链接。这活儿不难，难在持续——内容一直在动，死链会一直新生，所以它必须是常态化的检测，不能指望一次审计一劳永逸。

软404：最隐蔽的一种

软404是指页面内容上已经“空了”（比如“该商品已下架”“没有找到相关结果”），但服务器还返回200 OK。引擎和爬虫从状态码上看它是健康的，实际上它是个空壳。这种页面靠纯爬虫不好直接判定，得结合两个信号：一是页面字数极低、二是正文里出现“未找到”“已下架”这类措辞。把低字数页面筛出来人工抽查，软404就现形了。处理原则：真没了就返404或410，别用200假装还在。

重复内容与规范化类问题，怎么精准定位？

重复是大站的通病，尤其是电商。爬虫在这一类上特别好用，因为它能批量比对成千上万个页面的标题、描述、内容指纹。

重复的title与meta description

爬虫会自动把全站的title、meta description做聚合，直接给出“完全重复”“缺失”“过长过短”的分组清单。重复的title是个强信号——它往往说明模板出了问题：某个区分变量（比如颜色、尺寸、城市）没有正确写进标题，导致几百个本该各异的页面共用一个标题。处理这类问题不是一个个改，是回去修模板规则，具体到标题在规模化场景下怎么生成，可以系统地看怎么把模板变量做对。

canonical错配

canonical标签告诉引擎“这一组重复页里，该收哪一个”。它一旦配错，杀伤力极大。爬虫报表里把每个页面的canonical指向都导出来，筛几种异常：canonical指向一个404或被noindex的页面、canonical指向链或环、整站所有页面的canonical都指向首页（这是模板写死的经典事故）。canonical的各种场景和冲突诊断，canonical标签机制那篇讲得更细，审计阶段你只需要用爬虫把“配错的那些”快速圈出来。

参数URL泛滥

筛选器、排序、追踪参数会生成海量的参数URL：同一个分类页，加上不同的排序和筛选组合，能裂变出几百上千个内容近乎相同的地址。爬虫一爬，这些参数URL会成片出现。它们的危害是稀释抓取预算——引擎把宝贵的抓取额度耗在这些近重复页上，真正的好页面反而抓不勤。审计时统计参数URL占总URL的比例，如果超过一个不小的份额，就要在源头治理：规范化、canonical、或robots收口。

页面质量与可提取性类问题，爬虫能查出哪些？

最后一类，是页面本身的质量信号。爬虫查不了“内容好不好”这种主观判断，但它能查出一批客观的、结构性的质量缺陷。

薄内容与近重复

爬虫会统计每个页面的字数。把全站按字数升序排一遍，排在最前面那一批极低字数的页面，就是薄内容嫌疑名单。注意这里要区分：有些页面天生字少（比如纯列表的分类页），那是正常的；真正的问题是本该有实质内容的详情页、文章页字数却低得可怜。另外，Screaming Frog有近重复检测功能，能算出页面之间的内容相似度，把相似度过高的页面成组拎出来——这批要么合并、要么差异化。

H1与标题层级问题

爬虫会抽取每个页面的H1。两种典型问题：一是H1缺失，页面没有主标题，引擎少了一个重要的主题信号；二是多个H1，模板设计混乱导致一页冒出好几个H1。把“H1缺失”和“H1多于一个”两组筛出来，基本都是模板层面的统一性问题，改模板比改页面高效得多。

结构化数据与alt缺失

爬虫能解析页面里的结构化数据，把带Schema报错、缺失关键字段的页面列出来。它也能统计图片的alt属性覆盖率，筛出alt大面积缺失的页面。这两项都属于“可提取性”——结构化数据帮引擎和AI更准确地理解页面、alt帮引擎理解图片。它们不像noindex那样会直接让你消失，但长期看，是页面在搜索结果里能不能拿到更丰富展现的差距。下面这张表，把本文讲的十二类问题汇总成一份可直接对照的排查清单：

爬完之后，先看哪些数字、哪些是噪声？

新手做完审计最容易翻的车，是被报表淹没——Screaming Frog跑完能给你几十个标签页、上百个指标，每一个看起来都很重要，于是一条都不敢漏，导出几十个CSV，然后彻底卡死。这里要立一个判断顺序。

第一优先级，永远是“会让页面直接消失或打不开”的问题：noindex误用、robots误屏蔽、重定向环、大面积404。这一类是急诊，发现一个修一个，不需要排期讨论。第二优先级，是“稀释和拖累”类：重定向链、参数URL泛滥、抓取深度过深——它们不会让你立刻死，但持续放血，排进当月计划。第三优先级，是“锦上添花”类：alt覆盖、结构化数据完善、H1规整——它们值得做，但不该挤掉前两类的资源。

至于噪声，要心里有数。爬虫报表里有大量黄色警告，很多是“可以这样、但不这样也没事”的提示，比如某个title比建议长度长了几个字符、某张图没设width。被这种黄灯牵着走，你会把时间全耗在不影响大局的小事上。审计的纪律是：先把红色的、成片出现的、有模板共性的问题清掉，再回头看零散的黄灯。一个问题如果只出现在三五个页面上，它大概率是个案；如果成百上千个页面一起中招，它一定是模板或规则问题——后者才是审计真正要捞的鱼。

大站爬不动、爬不完，怎么办？

桌面爬虫有个硬伤：它跑在你自己的电脑上，吃内存。站一大，几十万、上百万URL，默认的内存模式直接撑爆，爬到一半崩溃。这是很多人放弃桌面爬虫的原因，其实有解。

第一，切换存储模式。Screaming Frog有内存模式和数据库模式两种，数据库模式把抓取数据写到硬盘，能爬的规模大得多，代价是慢一些。爬大站，务必先切数据库模式。第二，分段爬。不要一次爬全站，按目录切——这次只爬 /products/、下次只爬 /blog/。分段的好处不只是降负载，还让问题定位更聚焦：商品区和内容区的毛病通常不一样，分开爬、分开看，结论更干净。第三，抽样爬。对一个结构高度模板化的大站，你不需要爬完每一个URL才能下结论——同一个模板生成的十万个商品页，毛病是一样的，爬其中有代表性的几千个，问题就暴露得八九不离十了。

第四，渲染要省着用。JavaScript渲染模式比纯文本抓取慢一个数量级、吃资源也凶。一个理性的做法是：先用纯文本模式快速全站爬一遍摸清结构，再只对“确实依赖渲染”的关键模板，小范围开渲染模式精爬。把渲染当手术刀用，不要当扫把用。

把爬虫接上GSC、日志、GA，能多看到什么？

单独一份爬取结果已经很有用，但它只是“结构”这一个维度。把它和别的数据源接起来，审计才从“看结构”升级成“看结构 × 现实”。Screaming Frog支持直接连接GSC、GA、PageSpeed等接口，把外部数据并到每一个URL上。

接上GSC，你能立刻回答一个关键问题：那些结构上没毛病的页面，引擎到底收没收、给没给曝光。一个页面爬虫看着内链充足、深度也浅，可GSC显示它零曝光，那问题就不在结构、在内容或竞争层面了。接上GA或分析工具，你能给每个结构问题标上“它影响的是不是有流量的页面”——同样是一条重定向链，挂在一个月十万访问的页面上和挂在一个早就没人看的旧页上，优先级天差地别。

最值得做的一组交叉，是爬虫 × 日志。爬虫告诉你“内链可达哪些URL”，日志告诉你“Googlebot这30天真实抓了哪些URL”，两个集合一对比，信息量极大：爬虫有、日志没有的，是引擎一直没去抓的页（可能太深、可能预算不够）；日志有、爬虫没有的，是引擎在抓一批你内链里根本不存在的URL（往往是参数页、是外链带进来的、是历史遗留）。这套交叉怎么做、日志怎么取怎么读，服务器日志分析那篇是专门讲的。一句话：爬虫负责“应该怎样”，日志负责“实际怎样”，两者之间的缝隙，就是你最该动手的地方。

审计查出的问题，怎么交付给研发才落地得了？

审计做得再细，结论只躺在一份CSV里，就等于没做。十二类问题里，绝大多数的修复都得研发动手——改模板、改重定向规则、改robots、改canonical逻辑。审计和研发之间这道交付的坎，跨不过去，前面所有的爬取都白费。这一段讲怎么跨。

第一，别把原始CSV直接甩给研发。一份导出的爬虫报表对研发来说几乎是天书——他不知道哪条最急、不知道根因在哪、不知道改完怎么算对。你要做的是翻译：把“全站1200个页面title重复”翻译成“商品详情页模板的title规则漏写了颜色变量，导致同款不同色的页面共用一个标题，预期改完这1200个页面标题各不相同”。给根因、给定位、给验收标准，研发才接得住。

第二，按“一个根因一张工单”来组织，绝不要按“一个页面一条问题”。审计最大的价值就是发现模板级共性——1200个重复标题背后是一个根因，开一张工单；不是1200个问题、开1200条。把成片的问题归并回它们共同的根因，工单数量会从几千条塌缩到十几张，研发的排期才排得动，你的审计成果也才不会因为“太多了根本改不完”被束之高阁。

第三，每张工单都带一个可量化的验收口径。“改完后重新爬一遍，重复标题的分组数应该从几百降到0”——有这一句，修复才有闭环；没有这一句，研发改完你也判断不了对没对。第四，修复之后必须复爬验证。这是审计闭环的最后一环，也是最常被省掉的一环。研发说改好了，不等于真的好了——可能只改对了一部分、可能改出了新问题。把出问题的目录重新爬一遍，拿数字去对验收口径，对上了才算关闭。所以记住：一次完整的审计是“爬取→定位→交付→修复→复爬”五步，少了最后一步，它就只是一次观光，不是一次工程。

多久审计一次？怎么把它固化成制度？

很多团队的审计是“出事了才做”——流量掉了、排名没了，慌慌张张爬一遍救火。这是最低效的用法。审计真正的价值在于预防，而预防靠的是节奏。

一个可落地的节奏建议是这样的：核心模板和关键目录，每个季度做一次全量审计；每次大改版、迁移、CMS升级之后，立刻做一次专项审计——改版后的审计不是可选项，是必须项，因为前面说的noindex误用、robots误屏蔽、重定向链失控，九成都是改版那一下埋进去的。日常则可以用云端爬虫（Lumar、OnCrawl这类）设持续监控，关键指标一旦异常就报警，不用等到季度。

更进一步，是把审计的结论沉淀成“可复用的检查清单”，而不是每次从零开始。本文那张十二类问题表，就可以直接当成你季度审计的基础清单——每一项，谁负责查、阈值是多少、查出来怎么处理、上一季度的数字是多少，全部写下来。审计一旦变成有清单、有阈值、有历史对比的固定流程，它就从一件“凭感觉、凭记忆”的体力活，变成了一项能沉淀、能交接、能看出趋势的工程。这套东西做一次能享受好几年——这正是技术SEO里性价比最高的一类投入。

桌面爬虫查不出的问题有哪些？

最后必须把工具的边界说清楚，免得你把它当万能。桌面爬虫是一台结构扫描仪，不是一位SEO专家。下面这些事，它做不了。

它判断不了内容质量。它能告诉你这页有2000字，但这2000字是真有信息量、还是AI灌水的废话，它一无所知。它判断不了搜索意图匹配——一个页面结构完美、字数充足，但如果它回答的根本不是用户在搜的那个问题，爬虫看不出来，只有人能看出来。它也判断不了竞争层面的事：你这个词为什么排不过对手，是对手内容更好、外链更强、还是品牌信号更足，这些都不在爬取结果里。

还有前面反复强调的：它默认看不到抓取预算的现实，看不到引擎对你的“意愿”，看不到个性化和地域差异。它给你的是一张精确的、此刻的结构地图。地图很重要，没有地图寸步难行；但看着地图决定往哪走、走得值不值，那是人的判断。爬虫负责把问题暴露得又快又全，排序、取舍、判断该不该改，永远是人的活。把爬虫用在它擅长的地方——一次性、批量、客观地暴露结构性缺陷；把判断留给自己。工具和人各司其职，审计才既高效又不跑偏。

把这篇收个尾。全站爬虫审计不神秘，它就是定期拿一台和Googlebot同构的扫描仪，把你的站重新看一遍。难的从来不是工具操作，而是三件事：配置时知道镜头该怎么调、读数时分得清病因和噪声、出结论后能把它交付下去并固化成制度。本文那张十二类问题表，你可以直接抄成自己的季度审计清单——填上谁负责、阈值多少、上一季的数字——从今天起，让审计成为一件有节奏、能沉淀的固定动作，而不是流量掉了才慌忙打开的救火工具。

常见问题解答

Screaming Frog免费版够用吗，什么时候必须上付费版？

免费版有500个URL的抓取上限，小站或单目录抽查够用。一旦要爬全站、要连GSC／GA、要用近重复检测和爬取分析功能，就得上付费版。判断标准很简单：站超过500个URL，或者需要交叉数据源，就该付费。

桌面爬虫和云端爬虫，该选哪个？

不是二选一。桌面爬虫适合按需深挖、一次性专项审计，灵活、上手快。云端爬虫适合持续监控、大站、团队协作和自动报警。成熟的做法是两者都用：云端管日常监控，桌面管深度排查。

爬虫要不要开JavaScript渲染模式？

看你的站。正文在HTML源码里就有的服务端渲染站，默认纯文本模式又快又准，不用开。关键内容靠脚本加载的站必须开，否则爬虫看到的是空壳。判断方法：查看网页源代码，搜得到正文就不用开。

爬一遍站会不会把服务器爬崩？

有可能，尤其是带WAF、CDN的站或共享主机。并发太高会被当成攻击限流。务必先把抓取速度和并发线程压低试探，确认服务器扛得住再逐步放开，别把自己ban了。

审计查出几百个问题，从哪个先动手？

按三级优先级：先修会让页面消失或打不开的急诊问题（noindex误用、robots误屏蔽、重定向环、大面积404）；再处理稀释拖累类；最后才是锦上添花类。成片出现、有模板共性的问题，永远优先于零散个案。

多久做一次全站审计比较合理？

核心目录每季度一次全量审计；每次改版、迁移、CMS升级后立刻做一次专项审计，这一次不是可选项。有条件的话再用云端爬虫做持续监控，关键指标异常即报警。

爬虫报表里那么多黄色警告，要全改吗？

不用。大量黄灯是“可以这样、不这样也行”的提示，被它牵着走会把时间耗在小事上。纪律是先清红色的、成片的、有模板共性的问题，零散黄灯回头再看。

权威参考资料