[{"data":1,"prerenderedAt":244},["ShallowReactive",2],{"blog-crawl-budget-diagnosis":3,"blog-prev-crawl-budget-diagnosis":125,"blog-next-crawl-budget-diagnosis":141},{"id":4,"title":5,"author":6,"body":7,"canonical":125,"category":126,"cover":125,"date":127,"description":128,"draft":129,"extension":130,"keywords":125,"meta":131,"navigation":132,"noindex":129,"ogImage":125,"path":133,"seo":134,"seoDescription":125,"seoTitle":125,"stem":135,"tags":136,"updated":125,"__hash__":140},"blog\u002Fblog\u002Fcrawl-budget-diagnosis.md","软件站抓取预算被浪费的 4 个地方和查法","元析智能",{"type":8,"value":9,"toc":116},"minimark",[10,14,19,22,25,33,37,48,64,67,71,78,91,94,98,101,104,107,110,113],[11,12,13],"p",{},"大多数软件公司站的抓取问题不是抓取不够，是抓取被浪费了。我们今年给 6 个软件公司站做日志分析，按百度蜘蛛和 Googlebot 的请求量算，平均 38% 的抓取花在了不该抓的 URL 上，真正会带来排名的产品页、文档页反而抓得很浅。下面是我们查出来的四类最常见浪费，以及具体的查法。",[15,16,18],"h2",{"id":17},"第一类参数和筛选页","第一类：参数和筛选页",[11,20,21],{},"产品列表页带筛选参数，是抓取浪费的大头。一个做项目管理软件的客户，产品列表页有状态、行业、规模三个筛选维度，组合出来的 URL 有 60 多种。百度蜘蛛每天来抓 800 次，其中 500 多次落在这些组合 URL 上，每个页面内容还差不多。",[11,23,24],{},"查法：把日志按 URL 里的问号参数分组，数每个参数组合的抓取次数，再看这些页面的收录和排名。如果某个组合抓了 50 次以上、排名在 50 名开外，基本就是浪费。",[11,26,27,28,32],{},"改法：给筛选页加 ",[29,30,31],"code",{},"noindex"," 或者用 robots.txt 屏蔽参数组合，只保留默认列表页。这个客户屏蔽后第 3 周，核心产品页的抓取频次从每周 2 次涨到每周 11 次。",[15,34,36],{"id":35},"第二类cms-后台和测试环境暴露在公网","第二类：CMS 后台和测试环境暴露在公网",[11,38,39,40,43,44,47],{},"说出来有点丢人，但这真的常见。我们接手的一个开发者工具站，robots.txt 里没屏蔽 ",[29,41,42],{},"\u002Fadmin","，Google 收录了 200 多个后台页面，还有一批 ",[29,45,46],{},"staging.example.com"," 的页面被收录。后台页面不会被用户搜到，但会分走抓取频次，也有安全风险。",[11,49,50,51,53,54,53,57,53,60,63],{},"查法：GSC 的索引报告里筛 ",[29,52,42],{},"、",[29,55,56],{},"?preview=",[29,58,59],{},"staging",[29,61,62],{},"test"," 这些词；百度搜索资源平台的收录量也能看个大概。日志里看这些路径的抓取占比。",[11,65,66],{},"改法：robots.txt 屏蔽 + 后台加登录鉴权 + 测试环境加 Basic Auth。已经收录的页面用 410 或 301 处理，别放那里不管。",[15,68,70],{"id":69},"第三类分页和标签页无限翻","第三类：分页和标签页无限翻",[11,72,73,74,77],{},"博客标签页、分页的 ",[29,75,76],{},"?page=99","、日历归档，是第三类。一个 SaaS 站的分页参数被蜘蛛翻到了第 87 页，后面全是空列表。这种页面抓一次是浪费，抓几百次就是灾难。",[11,79,80,81,53,84,53,87,90],{},"查法：日志里筛 ",[29,82,83],{},"page=",[29,85,86],{},"tag=",[29,88,89],{},"category="," 这些参数，看最大页码和抓取次数。GSC 里看这些页面的抓取频次。",[11,92,93],{},"改法：分页加上限（比如只保留前 10 页 index，后面的 noindex），标签页合并或者 noindex，日历归档直接去掉。列表页本身要保留，但别让蜘蛛无限翻。",[15,95,97],{"id":96},"第四类已经放弃的老页面和重复域名","第四类：已经放弃的老页面和重复域名",[11,99,100],{},"老站迁移、换域名之后，旧域名的页面如果还挂着，蜘蛛会继续抓。我们见过一个客户，旧域名没做 301，两个域名同时在线 8 个月，新域名收录量一直上不去。还有一种是文章改版后旧 URL 没处理，同一个内容挂两个地址。",[11,102,103],{},"查法：日志里按 host 分组，看有没有多个域名；按 URL 的模式看改版前的路径还有没有请求。GSC 的重复网页报告、百度的重复内容提示也能辅助判断。",[11,105,106],{},"改法：旧域名整站 301 到新域名，旧 URL 写规则跳转，别保留双份内容。改完在 GSC 里提交改版，百度那边用抓取诊断确认新 URL 可抓。",[15,108,109],{"id":109},"我们自己的检查顺序",[11,111,112],{},"先看日志总量和各路径占比，再对照 GSC 索引报告，最后才动手改。顺序反了容易拍脑袋。改完至少观察 3 周，抓取频次的恢复比排名快，别指望第二天就见效。",[11,114,115],{},"如果你们站日抓取量在 1000 次以下，先别研究抓取预算，先把内容做起来。抓取预算是流量上来之后才值得抠的细节。",{"title":117,"searchDepth":118,"depth":118,"links":119},"",2,[120,121,122,123,124],{"id":17,"depth":118,"text":18},{"id":35,"depth":118,"text":36},{"id":69,"depth":118,"text":70},{"id":96,"depth":118,"text":97},{"id":109,"depth":118,"text":109},null,"技术SEO","2025-09-05","我们给 6 个软件公司站做过日志分析，抓取预算平均有 38% 花在没用的 URL 上。这篇文章列出最常浪费抓取预算的 4 个地方，以及用日志怎么查、怎么改。",false,"md",{},true,"\u002Fblog\u002Fcrawl-budget-diagnosis",{"title":5,"description":128},"blog\u002Fcrawl-budget-diagnosis",[137,138,139],"抓取预算","日志分析","站点结构","y2yg1gFSRUpcAN5-1ElahpOo3Z4nsaSvEATrHZs4WFc",{"id":142,"title":143,"author":6,"body":144,"canonical":125,"category":126,"cover":125,"date":233,"description":234,"draft":129,"extension":130,"keywords":125,"meta":235,"navigation":132,"noindex":129,"ogImage":125,"path":236,"seo":237,"seoDescription":125,"seoTitle":125,"stem":238,"tags":239,"updated":125,"__hash__":243},"blog\u002Fblog\u002Flcp-hero-image-bottleneck.md","首图拖慢首屏，软件公司官网 LCP 卡住的三个真实原因",{"type":8,"value":145,"toc":226},[146,149,153,156,159,162,166,177,180,183,187,193,204,208,211,214,217,220,223],[11,147,148],{},"我们审计过 11 个软件公司官网，其中 8 个的 LCP 元素是首屏那张产品截图，不是文字标题。原因集中在三处：图按设计稿尺寸直接导出、首屏图被统一加了懒加载、首图写在 CSS 背景里。改完这三处，平均能从 4 秒出头压到 2.2 秒左右，不需要动服务器。",[15,150,152],{"id":151},"原因一图按设计稿尺寸导出","原因一：图按设计稿尺寸导出",[11,154,155],{},"去年 11 月接的一个项目管理 SaaS，首页 hero 图是 2400×1350 的 PNG，1.8MB，而它在页面上实际只渲染 720 像素宽。设计师给的 2 倍图，前端直接放了原图，没人算过这一张占了首屏流量的七成。",[11,157,158],{},"改成 1440 宽、WebP 质量 78，体积 180KB。同一张图，在笔记本上肉眼分辨不出差别。这个站的 LCP 从 4.1 秒降到 2.9 秒，只动了这一处。",[11,160,161],{},"查法很简单：Performance 面板里看 LCP 请求的 transfer size，再和 Elements 里这张图的实际渲染尺寸对一下。传输体积超过渲染面积所需的两倍，就是浪费。这个判断不需要工具，手算一下就行。",[15,163,165],{"id":164},"原因二首屏图被统一加了懒加载","原因二：首屏图被统一加了懒加载",[11,167,168,169,172,173,176],{},"很多模板给所有 ",[29,170,171],{},"img"," 统一加 ",[29,174,175],{},"loading=\"lazy\"","，图省事。首屏图懒加载的代价是浏览器不会在解析 HTML 阶段就拿它，要等布局算完、判断它进入视口，才开始下载。移动端这一步能拖 300 到 600 毫秒。",[11,178,179],{},"我们查过一个开发者工具站，LCP 元素明明是首屏的架构图，Lighthouse 里这个请求的发现时间排在第 9 位。把首屏那张图的 lazy 去掉，它从第 9 位提到第 2 位，LCP 从 3.6 秒到 2.4 秒。",[11,181,182],{},"判断标准：首屏内的图不要 lazy，首屏外的图必须 lazy。一个属性的事，值得单独检查一遍。",[15,184,186],{"id":185},"原因三首图是-css-背景图","原因三：首图是 CSS 背景图",[11,188,189,192],{},[29,190,191],{},"background-image"," 写在样式表里，浏览器要先下载 CSS、解析、匹配选择器，才知道有这么张图。这层依赖让它的发现时间比 HTML 里的 img 晚一个 RTT 以上。",[11,194,195,196,199,200,203],{},"一个安全工具站的首图是背景图，2.4MB。我们把它改成 ",[29,197,198],{},"\u003Cimg>"," 加 ",[29,201,202],{},"object-fit: cover","，顺手做了响应式尺寸，LCP 从 3.9 秒到 2.6 秒。如果非要用背景图，至少在 HTML 里加 preload，但维护成本更高，不如直接换标签。",[15,205,207],{"id":206},"先改图再谈别的","先改图，再谈别的",[11,209,210],{},"这三处的共同点是：改的是资源本身，不是加载策略。很多团队一上来就研究 CDN、预加载、HTTP\u002F3，方向反了。首图 1.8MB 摆在那儿，CDN 再快也得把这 1.8MB 传完。",[11,212,213],{},"顺序应该是：先把图减到该有的体积，再去掉阻碍发现的属性，最后才考虑链路优化。前两步能解决软件站七成的 LCP 问题，剩下三成才是服务端和协议的事。",[15,215,216],{"id":216},"一个我们常用的取舍",[11,218,219],{},"客户经常问，首图到底该放多大。我们的经验值是按容器渲染宽度的 2 倍出图，质量 75 到 80，WebP 优先。超过这个规格，画质提升用户看不出来，体积却线性上涨。遇到一定要放 3 倍图的设计需求，让设计师把纹理和高光做成渐变，比提高分辨率更省。",[11,221,222],{},"另一个容易忽略的点是首图的 alt 和尺寸属性。宽高写死能让浏览器提前占位，既避免 CLS，也让 LCP 记录更准。我们见过好几个站，首图没有 width 和 height，布局抖一下，LCP 时间跟着延后 200 毫秒。",[11,224,225],{},"最后提醒一句：改完图要清 CDN 缓存，再重新测。我们有一次改完等了两天没效果，最后发现是边缘节点还挂着旧的 1.8MB 版本。",{"title":117,"searchDepth":118,"depth":118,"links":227},[228,229,230,231,232],{"id":151,"depth":118,"text":152},{"id":164,"depth":118,"text":165},{"id":185,"depth":118,"text":186},{"id":206,"depth":118,"text":207},{"id":216,"depth":118,"text":216},"2025-09-06","审计 11 个软件公司官网，8 个的 LCP 元素是首屏产品截图。三个原因最常见：设计稿原图直出、首屏图被加懒加载、首图写在 CSS 背景里。改完平均从 4 秒压到 2.2 秒。",{},"\u002Fblog\u002Flcp-hero-image-bottleneck",{"title":143,"description":234},"blog\u002Flcp-hero-image-bottleneck",[240,241,242],"LCP","图片优化","首屏速度","ZiTxUQwWAqBk7wb8pbARG82nSvZ0shnpFHsE2jbZh_s",1794088112648]