爬十万个页面，Screaming Frog 配置先改五处

2025 年 12 月我们爬一个文档站，12 万个 URL，第一次跑完导出结果一看，8 万条是带参数的重复页，真正要看的没几页。不是工具不行，是配置默认值适合小站，大站照默认跑就是浪费时间。

第一处：渲染方式

默认不执行 JavaScript，抓的是源码。内容靠前端渲染的站，这么抓回来一片空白。开渲染之前先确认必要性，开了之后速度会慢好几倍，十几万页能跑到第二天。

我的做法是先关掉渲染快速跑一遍，看 HTML 里有没有正文。有就不开，没有才开，并且把渲染超时从默认的几秒调到 10 秒左右，否则异步加载的内容抓不全。

第二处：抓取范围

用包含和排除规则把范围框住，比爬完再筛有效。要排除的东西很固定：会话 ID、排序参数、日历归档、筛选参数、文件下载、后台路径。

我们那 12 万 URL 里，光带排序参数的就有 5 万多。加一条正则排除之后，实际需要爬的只剩 3 万出头。

第三处：限速和并发

默认并发对生产站有压力，尤其是共享服务器的小站。爬之前先跟运维确认能不能爬、什么时段爬。我们通常把并发降到 2，加上延迟，放在夜里跑。

曾经有一次没降速，把一个客户的电商站爬得响应变慢，第二天被运维投诉。从那以后，我们的规矩是先小样本跑 200 页，看服务器负载再放量。

第四处：robots 与 UA

要不要遵守 robots，取决于目的。做诊断时遵守，能真实反映搜索引擎看到的东西；做覆盖度检查时可以临时不遵守，但要标记出来，别把结果混着看。

UA 也建议改一下，带上自己的标识，万一爬出问题对方能找到人。

第五处：导出和存储

十万页以上，内存吃紧，结果文件也大。分批爬，按目录拆开，每批单独导出。导出时只留要看的列：状态码、标题、字数、内链数、canonical、索引设置。

爬完先看什么

结果出来别急着导全表，先看四组数：状态码分布、重复标题数、canonical 指向不一致的页数、内链深度大于 4 的页数。

第一次爬那个文档站，状态码分布里 200 占 78%，剩下的 22% 全是 301。301 集中在两个旧目录，说明改版时跳转没做干净。这种结论从全表里翻是翻不出来的。

还有个习惯，每次爬完把结果存一份带日期的 CSV，下次对比用。三个月后能看出抓取问题是在变好还是变坏，这比单次报告有用。

我现在的习惯是爬之前先写一句话：这次要回答什么问题。写不出来就别爬。工具跑得快不代表有意义，配置和目的不清，爬一百万页也只是生成一个巨大的 CSV。