[{"data":1,"prerenderedAt":310},["ShallowReactive",2],{"blog-internal-link-depth":3,"blog-prev-internal-link-depth":107,"blog-next-internal-link-depth":194},{"id":4,"title":5,"author":6,"body":7,"canonical":91,"category":92,"cover":91,"date":93,"description":94,"draft":95,"extension":96,"keywords":91,"meta":97,"navigation":98,"noindex":95,"ogImage":91,"path":99,"seo":100,"seoDescription":91,"seoTitle":91,"stem":101,"tags":102,"updated":91,"__hash__":106},"blog\u002Fblog\u002Finternal-link-depth.md","500 页的站，每个页面都能 3 次点击到达吗","元析智能",{"type":8,"value":9,"toc":81},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78],[11,12,13],"p",{},"我们抽查过 30 个软件站，平均有 34% 的页面从首页点 4 次以上才能到。内链深度不是玄学，它直接决定抓取频次和排名。抽查方法很简单，补链的方式也就三种。",[15,16,17],"h2",{"id":17},"怎么抽查",[11,19,20],{},"三个办法。第一个，用爬虫工具跑全站，导出每个页面的\"点击深度\"。Screaming Frog 有这个字段，免费版也能看 500 个页面。",[11,22,23],{},"第二个，手动抽查 20 个页面：从首页开始，只通过可见链接，看几次能点到。这个方法笨，但最接近真实用户和蜘蛛的路径。",[11,25,26],{},"第三个，看日志。抓取频次高的页面，基本都是深度浅的页面。深度 4 以上的页面，抓取间隔通常是深度 2 的 5 倍以上。",[11,28,29],{},"我们给客户做诊断，一般三个办法都用，互相验证。",[15,31,32],{"id":32},"为什么深度重要",[11,34,35],{},"搜索引擎的抓取预算是按页面分配的。深度浅的页面，被发现得早、抓得勤；深度深的页面，可能几周才被抓一次，收录和排名都慢。",[11,37,38],{},"我们做过对比：同一个站，深度 2 的页面平均 3 天抓一次，深度 5 的页面平均 21 天抓一次。内容质量差不多，排名差距明显。",[15,40,41],{"id":41},"三种补链方式",[11,43,44],{},"第一种，加栏目索引页。把散落的页面按主题归类，每个栏目做一个索引页，首页链到索引页，索引页链到具体页面。一层就砍掉两个深度。",[11,46,47],{},"第二种，加相关推荐。每篇文章底部放 5 个相关链接，跨栏目也可以。这是最省力的补链方式。",[11,49,50],{},"第三种，改导航。把重要但藏得深的页面提到主导航或者页脚。页脚链接全站可见，对深度的改善最直接。",[15,52,53],{"id":53},"一个案例",[11,55,56],{},"2026 年 3 月我们给一个做安全软件的客户做诊断，800 个页面，深度 4 以上的占 45%。文档页尤其深，要从首页点 6 次才能到。",[11,58,59],{},"我们做了三件事：把文档按产品模块拆成 8 个索引页挂到导航；每篇文档加\"上一篇\u002F下一篇\u002F相关 5 篇\"；页脚加\"热门文档\"入口。",[11,61,62],{},"改完第 4 周，文档页的平均抓取间隔从 18 天降到 4 天，收录率从 52% 涨到 89%。排名变化慢一些，第 8 周开始有 20 多个词进前 20。",[15,64,65],{"id":65},"一个误区",[11,67,68],{},"不是所有页面都要往首页塞。深度控制在 3 以内是针对\"重要页面\"的，也就是有搜索需求、有转化价值的页面。",[11,70,71],{},"标签页、归档页、参数页，深度深一点没关系，它们本来就不该抢抓取预算。",[15,73,74],{"id":74},"一句判断",[11,76,77],{},"内链是技术 SEO 里投入产出比最高的一项，因为它不需要写内容，改的是结构。一个下午能加几十条链接，效果两周内能看到。",[11,79,80],{},"先抽查深度，再补链，别凭感觉。",{"title":82,"searchDepth":83,"depth":83,"links":84},"",2,[85,86,87,88,89,90],{"id":17,"depth":83,"text":17},{"id":32,"depth":83,"text":32},{"id":41,"depth":83,"text":41},{"id":53,"depth":83,"text":53},{"id":65,"depth":83,"text":65},{"id":74,"depth":83,"text":74},null,"技术SEO","2026-07-02","我们抽查过 30 个软件站，平均有 34% 的页面从首页点 4 次以上才能到。内链深度不是玄学，它直接决定抓取频次和排名。抽查方法、三种补链方式和一次改版后的数据都在这篇。先抽查再加链接，两周能看到变化。",false,"md",{},true,"\u002Fblog\u002Finternal-link-depth",{"title":5,"description":94},"blog\u002Finternal-link-depth",[103,104,105],"内链","站点结构","抓取","u81NcXxAHEqKayYI1AVxzSm2iqVwSaPpJZtpmBWospA",{"id":108,"title":109,"author":6,"body":110,"canonical":91,"category":92,"cover":91,"date":183,"description":184,"draft":95,"extension":96,"keywords":91,"meta":185,"navigation":98,"noindex":95,"ogImage":91,"path":186,"seo":187,"seoDescription":91,"seoTitle":91,"stem":188,"tags":189,"updated":91,"__hash__":193},"blog\u002Fblog\u002Fbing-webmaster-tools-index.md","必应站长工具的收录报告，被低估的第二个数据源",{"type":8,"value":111,"toc":175},[112,115,119,138,141,144,148,151,154,157,160,163,166,169,172],[11,113,114],{},"做英文站、做工具类软件的公司，必应值得单独建一个资源。它的站长工具在抓取细节和关键词数据上比 GSC 直接，适合做交叉验证。当然，它不能替代 GSC。",[15,116,118],{"id":117},"它比-gsc-多给了什么","它比 GSC 多给了什么",[11,120,121,125,126,129,130,133,134,137],{},[122,123,124],"strong",{},"索引浏览","按目录树展示收录情况，比 GSC 的 URL 分组更直观，能一眼看出哪个目录被收了、哪个目录一片空白。",[122,127,128],{},"URL 提交","的日配额比 GSC 高，新页面可以主动推，适合内容更新频繁的文档站。",[122,131,132],{},"关键词研究","自带搜索量和竞争度估算，不用再买工具。",[122,135,136],{},"站点扫描","是一份独立的技术审计，偶尔能发现 GSC 没提示的问题。",[15,139,140],{"id":140},"它少给了什么",[11,142,143],{},"索引数据延迟比 GSC 长，点击和展示的维度也少。必应的索引速度通常比 Google 慢一两天，新页面别指望当天进。它的 JS 渲染能力比 Google 弱、比百度强，SPA 站最好还是老老实实做服务端渲染。",[15,145,147],{"id":146},"_2026-年-2-月那次交叉验证","2026 年 2 月那次交叉验证",[11,149,150],{},"一个开发者工具站，GSC 显示 docs 目录收录 92%，必应只有 41%。我们以为必应抓取跟不上，用索引浏览按目录筛了一层，发现是分页页的 canonical 在必应侧没被识别，整批分页被当成重复内容。调整后一个月必应收录到 78%。",[11,152,153],{},"同一个问题在 GSC 里完全没暴露，因为 Google 处理 canonical 的方式不同。要不是有这个第二数据源，我们不会去查那条线。",[15,155,156],{"id":156},"怎么接入",[11,158,159],{},"验证域名的方式和 GSC 类似，可以用 DNS 记录或者 HTML 文件。接入后先提交 sitemap，再看索引浏览里已收录的目录。如果发现主域有多个子域，建议按子域分别建资源，否则收录数据会混在一起。",[11,161,162],{},"还有个实用的功能：抓取信息里能看到必应蜘蛛最近抓取的 URL 和状态码，遇到\"抓取失败\"的条目可以直接拿去修。",[15,164,165],{"id":165},"什么时候值得做",[11,167,168],{},"有英文站、客户在欧美、产品被开发者搜索的，必应优先级高。做外贸软件的，必应流量占总自然流量的比例常常在 5% 到 15% 之间，不算小。纯国内 to B 的站，优先级放低。",[15,170,171],{"id":171},"立场",[11,173,174],{},"多一个数据源不是为了多做一份报告，是为了交叉验证。两个工具都显示同一个问题时，才值得投入资源去改；只有一个显示异常，先怀疑工具差异。",{"title":82,"searchDepth":83,"depth":83,"links":176},[177,178,179,180,181,182],{"id":117,"depth":83,"text":118},{"id":140,"depth":83,"text":140},{"id":146,"depth":83,"text":147},{"id":156,"depth":83,"text":156},{"id":165,"depth":83,"text":165},{"id":171,"depth":83,"text":171},"2026-07-01","做外贸和工具类软件的站，必应的流量常被忽略。必应站长工具的索引浏览、URL 提交、关键词研究三个模块我们都会用，这篇讲它比 GSC 多给了什么、少给了什么。",{},"\u002Fblog\u002Fbing-webmaster-tools-index",{"title":109,"description":184},"blog\u002Fbing-webmaster-tools-index",[190,191,192],"必应","索引诊断","工具","VO_NMSoxyCoKDJXkNCsItS2PjPEBjT7FmJ9jgrqOTkg",{"id":195,"title":196,"author":6,"body":197,"canonical":91,"category":92,"cover":91,"date":299,"description":300,"draft":95,"extension":96,"keywords":91,"meta":301,"navigation":98,"noindex":95,"ogImage":91,"path":302,"seo":303,"seoDescription":91,"seoTitle":91,"stem":304,"tags":305,"updated":91,"__hash__":309},"blog\u002Fblog\u002Fthird-party-script-audit.md","第三方脚本治理，先砍掉不产生价值的那几个",{"type":8,"value":198,"toc":290},[199,202,206,209,212,215,218,221,224,227,230,233,236,239,242,245,248,251,254,257,260,263,266,269,272,275,278,281,284,287],[11,200,201],{},"2026 年 7 月我们给一个 SaaS 站清点第三方脚本，23 个域，占了主线程接近一半的时间。逐个查完，其中 9 个从上线到现在没有产生过任何转化，也没人说得清是谁加的。",[15,203,205],{"id":204},"先清点别先优化","先清点，别先优化",[11,207,208],{},"打开 DevTools 的 Network 面板，按域名分组，把第三方域列出来。再看每个脚本的体积、加载时机、执行耗时。",[11,210,211],{},"更省事的办法是用 Lighthouse 的第三方汇总，它会把每个域占用的主线程时间列出来，排序很清楚。",[11,213,214],{},"清点这一步最容易被跳过，但它是唯一能发现“没人知道这脚本干嘛”的步骤。",[15,216,217],{"id":217},"分三类处理",[11,219,220],{},"第一类，必须有。统计、客服、支付、登录。这些直接支撑业务，不能砍，但可以调加载方式。",[11,222,223],{},"第二类，有时用。A\u002FB 测试、热图、会话录制。项目期间开，项目结束关掉，别一直挂着。",[11,225,226],{},"第三类，可以砍。营销像素、聊天插件、推荐组件、社交分享按钮。这类东西装的时候都觉得有用，一年后没人记得。",[15,228,229],{"id":229},"加载时机怎么调",[11,231,232],{},"统计脚本用 defer，别阻塞。",[11,234,235],{},"客服插件改成用户点击或者滚动到一定位置再加载，首屏完全不加载。",[11,237,238],{},"A\u002FB 测试脚本尽量自托管，减少一次 DNS 和 TLS。",[11,240,241],{},"视频、地图、评论这类嵌入内容，用一个占位图代替，用户点击后再加载真实内容。",[15,243,244],{"id":244},"一个具体数字",[11,246,247],{},"客服插件是第三方脚本里最重的，常见体积 200 到 400KB，还要建立 WebSocket 连接。",[11,249,250],{},"我们给一个站把它改成延迟加载之后，主线程阻塞时间减少了 380 毫秒，首屏 LCP 提前了 200 多毫秒。",[11,252,253],{},"这个改动只花了半天，比重构业务代码划算得多。",[15,255,256],{"id":256},"治理要有规则",[11,258,259],{},"第一，新加任何第三方脚本要报备，写清用途、体积、加载方式。",[11,261,262],{},"第二，季度审计一次，把没产生价值的清掉。",[11,264,265],{},"第三，上线前设预算，第三方脚本总执行时间不超过 500 毫秒，超了要评审。",[11,267,268],{},"没有规则，脚本只会越来越多。三年后你会发现站上跑着四十个脚本，没人敢删。",[15,270,271],{"id":271},"一个常见的反对意见",[11,273,274],{},"“这个脚本是市场部要的”。这句话我们听过很多次。处理办法不是争论，是把主线程耗时和转化数据放在一起给对方看。",[11,276,277],{},"如果脚本确实在产生线索，留着；如果一年零转化，市场部自己也会同意关掉。",[15,279,280],{"id":280},"一个态度",[11,282,283],{},"第三方脚本治理是性能优化里性价比最高的一件事，因为它不需要改业务代码，只要做减法。",[11,285,286],{},"但它需要跨部门协调，因为每个脚本背后都有人负责。这也是它经常被搁置的原因。",[11,288,289],{},"我们的做法是先出一份清单，标出每个脚本的主线程耗时和最近一次带来的转化，让数据说话。清单摆出来，砍哪个不用我们开口。",{"title":82,"searchDepth":83,"depth":83,"links":291},[292,293,294,295,296,297,298],{"id":204,"depth":83,"text":205},{"id":217,"depth":83,"text":217},{"id":229,"depth":83,"text":229},{"id":244,"depth":83,"text":244},{"id":256,"depth":83,"text":256},{"id":271,"depth":83,"text":271},{"id":280,"depth":83,"text":280},"2026-07-03","一个站 23 个第三方脚本，9 个从没带来过转化。这篇写怎么清点、分三类处理、加载时机怎么调，以及上线前的准入规则，附一份季度审计清单。",{},"\u002Fblog\u002Fthird-party-script-audit",{"title":196,"description":300},"blog\u002Fthird-party-script-audit",[306,307,308],"第三方脚本","性能治理","页面体验","Z8hedxrnrsVt4sLlslJ3KOd9eErOUXUUFqjyw89RVg8",1794088104152]