[{"data":1,"prerenderedAt":315},["ShallowReactive",2],{"blog-faceted-navigation-crawl":3,"blog-prev-faceted-navigation-crawl":122,"blog-next-faceted-navigation-crawl":209},{"id":4,"title":5,"author":6,"body":7,"canonical":106,"category":107,"cover":106,"date":108,"description":109,"draft":110,"extension":111,"keywords":106,"meta":112,"navigation":113,"noindex":110,"ogImage":106,"path":114,"seo":115,"seoDescription":106,"seoTitle":106,"stem":116,"tags":117,"updated":106,"__hash__":121},"blog\u002Fblog\u002Ffaceted-navigation-crawl.md","筛选参数把抓取预算吃光了：电商站的 5 个处理规则","元析智能",{"type":8,"value":9,"toc":94},"minimark",[10,14,18,21,24,28,31,34,38,49,52,56,59,62,66,69,72,76,79,82,85,88,91],[11,12,13],"p",{},"一个 B2B 电商站的筛选组合生成了 6 万多个 URL，抓取预算的 62% 花在参数页上，核心产品页一周才被抓一次。我们用 5 条规则把参数页从 6 万压到 800。",[15,16,17],"h2",{"id":17},"先算清楚参数页有多少",[11,19,20],{},"三个筛选维度各 10 个值，组合起来理论上是 1000 种；如果再叠加排序、页码、视图模式，实际 URL 能到几万个。",[11,22,23],{},"查法：从日志里把带问号的 URL 全提出来，按参数名分组，数每个参数组合的抓取次数和收录数。我们那个客户，日志里 62% 的抓取请求落在参数页，而这些页面的收录率只有 8%。",[15,25,27],{"id":26},"规则一只保留有搜索需求的组合","规则一：只保留有搜索需求的组合",[11,29,30],{},"不是所有筛选组合都值得收录。用关键词工具查\"产品词 + 筛选值\"有没有搜索量，有量的保留，没量的不收录。",[11,32,33],{},"那个客户 6 万多个组合里，真正有搜索需求的只有 800 个左右。",[15,35,37],{"id":36},"规则二参数顺序统一去掉无意义参数","规则二：参数顺序统一，去掉无意义参数",[11,39,40,44,45,48],{},[41,42,43],"code",{},"?color=red&size=1"," 和 ",[41,46,47],{},"?size=1&color=red"," 是两个 URL，内容一样。排序参数、追踪参数、会话参数，全部规范化或者屏蔽。",[11,50,51],{},"做法：服务端对参数排序，追踪参数用 canonical 合并，视图模式参数直接不走 URL。",[15,53,55],{"id":54},"规则三没有搜索量的组合用-robots-屏蔽","规则三：没有搜索量的组合用 robots 屏蔽",[11,57,58],{},"屏蔽的是\"组合页\"，不是\"单个筛选值页\"。比如颜色筛选可以收录，颜色 + 尺码 + 价格区间的三重叠组合就屏蔽。",[11,60,61],{},"robots 屏蔽的页面不会被抓取，也就不会浪费预算。代价是这些页面也拿不到排名，但它们本来也没有排名。",[15,63,65],{"id":64},"规则四筛选页要有独立价值","规则四：筛选页要有独立价值",[11,67,68],{},"保留下来的 800 个筛选页，不能只是列表换个顺序。我们给每个页面加了筛选条件说明、适用场景、相关产品推荐，让它有独立的内容价值。",[11,70,71],{},"这一步决定了收录之后能不能排上去。只靠参数组合的页面，收录了也是零展现。",[15,73,75],{"id":74},"规则五内链只指向有价值的筛选页","规则五：内链只指向有价值的筛选页",[11,77,78],{},"导航和列表页里的筛选链接，只链到保留下来的 800 个页面。无价值的组合不生成可点击链接，减少蜘蛛的发现路径。",[15,80,81],{"id":81},"结果",[11,83,84],{},"调整从 2026 年 1 月开始，做了 6 周。第 8 周看数据：抓取请求里参数页占比从 62% 降到 9%，核心产品页的平均抓取间隔从 7 天缩到 1.5 天，有排名的关键词从 1200 个涨到 3100 个。",[11,86,87],{},"询盘量第 10 周开始涨，两个月后比调整前高 40%。",[15,89,90],{"id":90},"一句判断",[11,92,93],{},"筛选页不是\"要不要收录\"的问题，是\"哪些组合值得收录\"的问题。先算清楚数量和需求，再决定屏蔽还是保留，别一刀切全屏蔽——那会丢掉真正有搜索量的长尾。",{"title":95,"searchDepth":96,"depth":96,"links":97},"",2,[98,99,100,101,102,103,104,105],{"id":17,"depth":96,"text":17},{"id":26,"depth":96,"text":27},{"id":36,"depth":96,"text":37},{"id":54,"depth":96,"text":55},{"id":64,"depth":96,"text":65},{"id":74,"depth":96,"text":75},{"id":81,"depth":96,"text":81},{"id":90,"depth":96,"text":90},null,"技术SEO","2026-06-22","一个 B2B 电商站的筛选组合生成了 6 万多个 URL，抓取预算的 62% 花在参数页上，核心产品页一周才被抓一次。我们用 5 条规则把参数页从 6 万压到 800，收录率和询盘都回来了。照着做能把参数页数量压掉 90%，还能把收录率拉回来。",false,"md",{},true,"\u002Fblog\u002Ffaceted-navigation-crawl",{"title":5,"description":109},"blog\u002Ffaceted-navigation-crawl",[118,119,120],"筛选参数","抓取预算","电商SEO","Rci4uxEa3PhEdxr9-z2RKNwbjuuZvV72GCr1U7bkajk",{"id":123,"title":124,"author":6,"body":125,"canonical":106,"category":107,"cover":106,"date":198,"description":199,"draft":110,"extension":111,"keywords":106,"meta":200,"navigation":113,"noindex":110,"ogImage":106,"path":201,"seo":202,"seoDescription":106,"seoTitle":106,"stem":203,"tags":204,"updated":106,"__hash__":208},"blog\u002Fblog\u002Fcms-migration-url-template.md","换内容管理系统不掉排名，URL 和模板先对齐",{"type":8,"value":126,"toc":189},[127,130,134,145,149,152,155,159,162,165,168,171,174,177,180,183,186],[11,128,129],{},"CMS 只是发布工具，掉不掉排名看迁移过程有没有保住三样东西：URL、模板结构、渲染方式。这三样任何一样变了，都要当成一次站改来对待，按迁移的规矩做，别当成\"换个后台\"。",[15,131,133],{"id":132},"一url-必须逐条映射","一、URL 必须逐条映射",[11,135,136,137,140,141,144],{},"旧 CMS 的固定链接结构是定死的，新 CMS 默认结构常常不同。别用自动规则猜，逐条映射一遍。我们见过最惨的一次，迁移脚本把文章 URL 从 ",[41,138,139],{},"\u002Fblog\u002Fpost-name"," 改成了 ",[41,142,143],{},"\u002Fblog\u002F2026\u002Fpost-name","，2000 篇文章全部换地址，301 也没做，两个月自然流量掉了一半。",[15,146,148],{"id":147},"二模板结构要对齐","二、模板结构要对齐",[11,150,151],{},"H1、正文、内链、面包屑、结构化数据的位置要一致。换主题之后最常见的问题：正文被塞进多个嵌套容器，正文长度看起来没变，但首屏只剩标题和目录；H1 被做成图片；面包屑从模板里消失。",[11,153,154],{},"2026 年 3 月一个 2000 页的站从 WordPress 迁到自研 CMS，URL 没变，但新模板把正文放进折叠组件。30 天后收录掉了 40%，修复只用了两周。",[15,156,158],{"id":157},"三渲染方式要确认","三、渲染方式要确认",[11,160,161],{},"新 CMS 自带的主题可能用 JS 渲染列表页和文章页。旧的如果是静态生成的，新旧渲染方式不一致，收录表现会差一截。迁移前用 curl 各拉一遍，对比初始 HTML。",[15,163,164],{"id":164},"对照检查表",[11,166,167],{},"迁移前爬旧站，记录每个页面的 title、H1、正文长度、内链数、结构化数据类型、状态码。迁移后用同样的规则爬新站，逐项对比。我们的脚本会输出差异页列表，按流量排序，先修高流量的。",[15,169,170],{"id":170},"迁移的时间窗口",[11,172,173],{},"选在流量低谷，比如季度末的周末。迁移前两周冻结内容改版，前一周把所有 URL 清单、重定向规则、新站爬虫报告都准备好。上线后一周内每天看日志和索引报告，异常当天处理。",[11,175,176],{},"我们给客户排的时间表：第 1 周准备，第 2 周上线，第 3 到 6 周观察，第 7 周复盘。整个过程 SEO 要参与，不能只在最后一天收到一个链接。",[15,178,179],{"id":179},"四个常见坑",[11,181,182],{},"旧站的重定向插件没导；标签和分类页的 URL 全变了；图片路径变了导致 404；RSS 和 sitemap 地址变了，订阅用户和蜘蛛都断了线。每一条都能在迁移前检查出来，只是没人愿意花那半天。",[15,184,185],{"id":185},"立场",[11,187,188],{},"换 CMS 之前先问一句：新站谁负责 SEO 验收。没有验收环节的迁移就是赌博，赌注是你积累了几年的收录和排名。",{"title":95,"searchDepth":96,"depth":96,"links":190},[191,192,193,194,195,196,197],{"id":132,"depth":96,"text":133},{"id":147,"depth":96,"text":148},{"id":157,"depth":96,"text":158},{"id":164,"depth":96,"text":164},{"id":170,"depth":96,"text":170},{"id":179,"depth":96,"text":179},{"id":185,"depth":96,"text":185},"2026-06-21","从 WordPress 换到自研 CMS、从自研换到 Headless，我们做过 4 次。掉排名基本不是 CMS 本身的问题，而是迁移时没对齐 URL、模板和渲染。附一份迁移前后对照检查表。",{},"\u002Fblog\u002Fcms-migration-url-template",{"title":124,"description":199},"blog\u002Fcms-migration-url-template",[205,206,207],"网站迁移","CMS","URL设计","zjkfN2lakH5QDTYAm6Lek9VCameqWBZoIj09nscSziM",{"id":210,"title":211,"author":6,"body":212,"canonical":106,"category":107,"cover":106,"date":304,"description":305,"draft":110,"extension":111,"keywords":106,"meta":306,"navigation":113,"noindex":110,"ogImage":106,"path":307,"seo":308,"seoDescription":106,"seoTitle":106,"stem":309,"tags":310,"updated":106,"__hash__":314},"blog\u002Fblog\u002Fjs-bundle-load-order.md","JS 包体拆完还是慢，问题在加载顺序",{"type":8,"value":213,"toc":295},[214,217,220,223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292],[11,215,216],{},"2026 年 7 月一个客户说包体已经拆过了，从 2.1 兆降到 600K，首屏还是 2.8 秒。我打开 DevTools 一看，600K 里有 400K 是首屏根本用不到的东西，只是被放在了主包里。",[15,218,219],{"id":219},"拆包解决的是什么",[11,221,222],{},"它解决下载量，让首屏不用等全部 JS 下完。但首屏时间不只取决于下载，还取决于解析、执行、以及依赖的先后顺序。",[11,224,225],{},"一个 300K 的包，在 4 倍 CPU 降速下执行要一秒多。拆成三个 100K 的包并行下载，执行时间没变。",[11,227,228],{},"所以拆包只是第一步，关键是让主线程上只跑首屏需要的东西。",[15,230,231],{"id":231},"三种常见的拆错",[11,233,234],{},"第一种，把首屏依赖拆进了懒加载。按钮点击才加载的组件里，包含了首屏渲染要用的工具函数，结果首屏卡住等它。",[11,236,237],{},"第二种，拆得太碎。几十个小 chunk，每个都要一个请求，HTTP\u002F2 下虽然能复用连接，但请求排队和依赖解析反而更慢。",[11,239,240],{},"第三种，vendor 全塞一个包。所有第三方库打成一个 1 兆的文件，首屏只用到其中一个，剩下全是白下。",[15,242,243],{"id":243},"加载顺序怎么排",[11,245,246],{},"首屏关键 chunk 用 modulepreload 提前拿，放在 head 里，让它和 HTML 并行。",[11,248,249],{},"非关键的用 defer，别用 async。async 的执行时机不确定，可能抢在关键脚本前面跑，造成页面空白。",[11,251,252],{},"runtime 和 manifest 内联到 HTML 里，省一个请求，也避免版本错配。",[15,254,255],{"id":255},"真正的大头往往不在业务代码",[11,257,258],{},"我们拆过十几个站，主包里最大的三样东西通常是：全量引入的工具库、图标库、polyfill。",[11,260,261],{},"工具库只用了两个函数，却把整个库打进来；图标库引了一千个图标，页面只用八个；polyfill 给现代浏览器也塞了一份。",[11,263,264],{},"这三样加起来能占主包的一半，砍掉比拆十次都有用。",[15,266,267],{"id":267},"怎么判断哪里该砍",[11,269,270],{},"用 bundle 分析工具看每个模块的体积占比，先砍排名前十的。",[11,272,273],{},"再用代码覆盖率看首屏执行了多少。我们见过首屏执行率 12% 的页面，意思是 88% 的 JS 白跑了。",[11,275,276],{},"最后在 4 倍 CPU 降速下测。桌面跑得欢的代码，在中端安卓机上可能是灾难。",[15,278,279],{"id":279},"一个可以立刻做的检查",[11,281,282],{},"打开 DevTools 的 Coverage 面板，录一次首屏加载，它会告诉你每个 JS 文件执行了多少、浪费了多少。",[11,284,285],{},"超过一半没执行的包，就是该拆或者该砍的。这个检查十分钟能做完，比看任何分析报告都直接。",[15,287,288],{"id":288},"一个判断",[11,290,291],{},"包体优化里，砍掉不用的代码比拆包收益大，排好加载顺序比压缩收益大，压缩只是最后一步。",[11,293,294],{},"很多团队把顺序做反了：先上压缩和 CDN，再研究拆包，最后才想起来问这些代码到底用不用。这个顺序应该倒过来。",{"title":95,"searchDepth":96,"depth":96,"links":296},[297,298,299,300,301,302,303],{"id":219,"depth":96,"text":219},{"id":231,"depth":96,"text":231},{"id":243,"depth":96,"text":243},{"id":255,"depth":96,"text":255},{"id":267,"depth":96,"text":267},{"id":279,"depth":96,"text":279},{"id":288,"depth":96,"text":288},"2026-06-23","一个站 JS 从 2.1 兆拆到 600K，首屏还是 2.8 秒。拆包解决下载，解决不了执行和依赖顺序。这篇写拆错的三种情况、关键 chunk 怎么排、真正的大头在哪。",{},"\u002Fblog\u002Fjs-bundle-load-order",{"title":211,"description":305},"blog\u002Fjs-bundle-load-order",[311,312,313],"JavaScript","代码分割","首屏","I_h685YtX-z_-Oh3_MV54zfZl_CDDd1Ub-Pr9GoR4QA",1794088104475]