[{"data":1,"prerenderedAt":278},["ShallowReactive",2],{"blog-redirect-chain-cleanup":3,"blog-prev-redirect-chain-cleanup":121,"blog-next-redirect-chain-cleanup":195},{"id":4,"title":5,"author":6,"body":7,"canonical":105,"category":106,"cover":105,"date":107,"description":108,"draft":109,"extension":110,"keywords":105,"meta":111,"navigation":112,"noindex":109,"ogImage":105,"path":113,"seo":114,"seoDescription":105,"seoTitle":105,"stem":115,"tags":116,"updated":105,"__hash__":120},"blog\u002Fblog\u002Fredirect-chain-cleanup.md","重定向链超过两次，抓取预算就白扔了","元析智能",{"type":8,"value":9,"toc":95},"minimark",[10,14,18,39,42,45,48,51,71,74,77,80,83,86,89,92],[11,12,13],"p",{},"重定向链是慢性病。它不报错、不警告，只是每个请求多花一次往返，每个链接多掉一点权重。我们的标准是：超过两跳，当问题处理。",[15,16,17],"h2",{"id":17},"链是怎么一年年长出来的",[11,19,20,21,25,26,25,29,25,32,25,35,38],{},"我做诊断时见过最长的一条是六跳：",[22,23,24],"code",{},"http:\u002F\u002Fexample.com\u002Fproduct-a"," → ",[22,27,28],{},"https:\u002F\u002Fexample.com\u002Fproduct-a",[22,30,31],{},"https:\u002F\u002Fwww.example.com\u002Fproduct-a",[22,33,34],{},"\u002Fproducts\u002Fproduct-a",[22,36,37],{},"\u002Fproducts\u002Fproduct-a\u002F"," → 最后才到带版本的落地页。每一跳都对应一次基础设施变更——上 HTTPS 留一层，从裸域切到 www 留一层，改目录再留一层。没人做整体收敛，就这么挂了一年多。",[15,40,41],{"id":41},"六跳改直连的那次",[11,43,44],{},"2025 年 8 月，一个 B2B 软件站的核心产品页就是上面那条链。日志里 Googlebot 对这个页面每天请求 4 次，其中 3 次花在跳转上，真正读到内容只有 1 次。百度蜘蛛更明显，有几天直接停在第二跳就走了。",[11,46,47],{},"改法很简单：在 nginx 层写一条规则，任何旧形态一次 301 到最终 URL，把中间层全删掉。改完第一周，最终页被抓取频次从每天 1 次涨到 4 次，两周后回到前 5。",[15,49,50],{"id":50},"怎么查",[52,53,54,62,68],"ul",{},[55,56,57,58,61],"li",{},"Screaming Frog 跑全站，看 ",[22,59,60],{},"Redirect Chains"," 报表，按跳数排序。",[55,63,64,67],{},[22,65,66],{},"curl -I -L"," 手动盯一个链接，看 Location 头一路跳过几次。",[55,69,70],{},"日志里按状态码 301、302 分组，看哪些路径请求量最大——请求量大的链，修复收益最高。",[15,72,73],{"id":73},"怎么改才不复发",[11,75,76],{},"重定向规则放在 nginx 或 CDN 层，不要写在应用代码里。应用层做重定向，业务一改版就丢规则，而且性能差一截。规则用正则收敛成一条主规则，再给少数特殊路径开白名单。",[11,78,79],{},"302 只给临时活动用，活动结束记得撤。长期挂 302 是最容易被忽略的一种，蜘蛛会一直去请求原地址。有个客户的活动页挂了 14 个月 302，活动早结束了，日志里蜘蛛还在天天抓旧地址，一个月白扔两千多次请求。",[11,81,82],{},"规则写法上，nginx 里优先用一条带正则的 server 级规则做兜底，再给确需保留的路径加 location 例外。CDN 层的回源规则也要同步检查，很多人只改了源站，边缘节点缓存着旧跳转，用户和蜘蛛看到的是两套结果。改完拿三种 UA 各测一次：桌面浏览器、手机浏览器、Googlebot，确认跳转次数一致。",[15,84,85],{"id":85},"多久复查一次",[11,87,88],{},"站点大改、换域名、上 CDN 之后各查一次。平时一个季度扫一遍。重定向链不会自己变好，只会越挂越多。",[15,90,91],{"id":91},"立场",[11,93,94],{},"改版时多花半天做重定向映射，比事后花三个月排查掉排名划算。我们给客户做迁移，301 映射表是必交付物，一张表列清楚旧 URL、新 URL、状态、上线日期，谁接手都能看懂。",{"title":96,"searchDepth":97,"depth":97,"links":98},"",2,[99,100,101,102,103,104],{"id":17,"depth":97,"text":17},{"id":41,"depth":97,"text":41},{"id":50,"depth":97,"text":50},{"id":73,"depth":97,"text":73},{"id":85,"depth":97,"text":85},{"id":91,"depth":97,"text":91},null,"技术SEO","2025-10-15","一个链接从 HTTP 跳 HTTPS、再跳 www、再跳新路径，四次重定向才到目的地。我们清过一条六跳的链，改直连后目标页抓取频次翻了四倍。这篇写链怎么长出来、怎么查、怎么改。",false,"md",{},true,"\u002Fblog\u002Fredirect-chain-cleanup",{"title":5,"description":108},"blog\u002Fredirect-chain-cleanup",[117,118,119],"重定向","抓取预算","日志分析","A8hFriWI3vIFk_2oJgg42phX9JCFHPbXnQfPm00PQTk",{"id":122,"title":123,"author":6,"body":124,"canonical":105,"category":183,"cover":105,"date":184,"description":185,"draft":109,"extension":110,"keywords":105,"meta":186,"navigation":112,"noindex":109,"ogImage":105,"path":187,"seo":188,"seoDescription":105,"seoTitle":105,"stem":189,"tags":190,"updated":105,"__hash__":194},"blog\u002Fblog\u002Fkeyword-volume-underestimated.md","关键词工具给的搜索量，软件行业普遍偏低",{"type":8,"value":125,"toc":175},[126,129,132,135,138,141,145,148,151,154,157,160,163,166,169,172],[11,127,128],{},"同一批词，Ahrefs 给 90，Semrush 给 140，百度指数显示 0，GSC 里实际曝光 420。这不是工具坏了，是软件行业的词太小众，工具的点击流样本撑不起来。我们现在的做法很固定：工具只用来排优先级，绝对数字一律用 GSC 曝光校准。",[15,130,131],{"id":131},"搜索量是怎么估出来的",[11,133,134],{},"Ahrefs 和 Semrush 主要靠点击流面板加上 Google Ads 的数据反推，词越小样本越少，误差越大。中文词又是另一套逻辑：5118 和爱站更贴百度的量级，但爱站把百度指数当搜索量用，指数是相对值，不是搜索次数。",[15,136,137],{"id":137},"我们的校准方法",[11,139,140],{},"取客户站 GSC 近 3 个月的查询数据，把每个词的实际曝光除以工具给的搜索量，算一个中位数系数。软件行业这个系数通常落在 1.5 到 3 之间，意思是工具低估了两三倍。有了系数，排序不变，但下个月能来多少流量的预估不会离谱。",[15,142,144],{"id":143},"别用搜索量算-roi","别用搜索量算 ROI",[11,146,147],{},"一个「CI\u002FCD 工具选型」月搜 100 的词，带来的试用可能比「免费代码托管」月搜 5000 的词多。前者是准备做决策的工程师和 Tech Lead，后者多半是来找免费资源的学生。B2B 软件按搜索量排优先级，一定把资源砸到最不转化的词上。",[11,149,150],{},"我们的排序权重是：搜索意图有没有采购或选型信号，竞品有没有在打这个词，搜索量，最后才是难度分。前三项靠人判断，工具只在最后一项帮上忙。",[15,152,153],{"id":153},"一个反常识的结论",[11,155,156],{},"有时候搜索量低是好事。月搜 50 到 200 的长尾词，SERP 里往往只有两三个像样的结果，一篇讲透的文档页就能排上去。月搜 5000 的大词，前十全是点评站、论坛和厂商官网，新站砸半年也进不去。",[15,158,159],{"id":159},"中文词和英文词分开排",[11,161,162],{},"英文词的量级三家工具差得不算远，中文词能差一个数量级。2025 年 9 月我拿同一批 40 个中文词在三个工具里查过，5118 给的总量是 Ahrefs 的四倍多。所以词表别混着算：中文走百度系工具加搜索资源平台，英文走 Ahrefs 加 GSC，两套系数分开维护。",[11,164,165],{},"还有个规律，工具对带品牌名的词给量很准，因为搜索量大、样本足；对纯长尾基本靠猜。排优先级时把品牌词和品类词分开，前者只看竞品抢了多少，后者才是内容能打的战场。",[15,167,168],{"id":168},"工具之外还有一个免费信号",[11,170,171],{},"百度搜索资源平台和 GSC 都有搜索词数据，这是唯一免费又真实的曝光来源。词表定稿前我会先翻这两个后台最近 28 天的查询，工具里搜索量高、后台却完全没有曝光的词，先放一边。反过来，后台有稳定曝光、工具显示搜索量个位数的词，一定要写。",[11,173,174],{},"所以看到工具给出个位数搜索量，别急着删词。先看这个词有没有人在 SERP 上认真做内容，没有人做，往往就是机会。",{"title":96,"searchDepth":97,"depth":97,"links":176},[177,178,179,180,181,182],{"id":131,"depth":97,"text":131},{"id":137,"depth":97,"text":137},{"id":143,"depth":97,"text":144},{"id":153,"depth":97,"text":153},{"id":159,"depth":97,"text":159},{"id":168,"depth":97,"text":168},"工具评测","2025-10-14","同一批词，三个工具给出 90、140 和 420 三种量级。软件行业的词太小众，工具样本撑不起来。我们现在的做法是工具只排优先级，绝对值一律用 GSC 曝光校准。",{},"\u002Fblog\u002Fkeyword-volume-underestimated",{"title":123,"description":185},"blog\u002Fkeyword-volume-underestimated",[191,192,193],"关键词工具","搜索量","B2B软件","EHiW-dzaZ7ajA92WpY1bSGQ1WP5UUt8tbwWFlMOWP-M",{"id":196,"title":197,"author":6,"body":198,"canonical":105,"category":106,"cover":105,"date":267,"description":268,"draft":109,"extension":110,"keywords":105,"meta":269,"navigation":112,"noindex":109,"ogImage":105,"path":270,"seo":271,"seoDescription":105,"seoTitle":105,"stem":272,"tags":273,"updated":105,"__hash__":277},"blog\u002Fblog\u002Finp-improvement-case-study.md","把后台筛选的 INP 从四百二十毫秒压到一百八十",{"type":8,"value":199,"toc":258},[200,203,206,210,213,216,220,223,227,230,234,237,240,243,246,249,252,255],[11,201,202],{},"今年 10 月我们给一个安全审计 SaaS 的后台做交互优化，P75 的 INP 从 420 毫秒降到 180 毫秒。这个产品每天有客户在里面点几百次筛选，卡不卡直接关系到他们愿不愿意续费。",[11,204,205],{},"问题集中在一个页面：客户列表。1200 条记录，七个筛选条件，每次改动都重新拉数据、重新渲染整张表。用户点一下复选框，页面要停半秒。销售在演示时也遇到过，鼠标点下去没反应，场面很难看。",[15,207,209],{"id":208},"先复现再动手","先复现，再动手",[11,211,212],{},"我们没有直接改代码，先按真实操作录了 20 次 Performance。结论很清楚：一次筛选交互里，主线程上有三个 300 毫秒以上的长任务，分别是数据深拷贝、全量重渲染、以及一个第三方埋点的同步上报。",[11,214,215],{},"顺带说个细节，客户自己一直说\"不卡\"，因为开发机是 M 系列芯片，而他们的客户用的是四年前的办公本。测 INP 必须用降速环境，或者直接看真实用户数据。",[15,217,219],{"id":218},"改动一列表虚拟化","改动一：列表虚拟化",[11,221,222],{},"1200 行只渲染视口内的 40 行，滚动时动态替换。这一项把重渲染时间从 380 毫秒压到 60 毫秒。虚拟化的代价是导出、全选、跨行拖拽这些功能要单独适配，我们花了三天补。",[15,224,226],{"id":225},"改动二把计算挪出事件处理器","改动二：把计算挪出事件处理器",[11,228,229],{},"原来的筛选逻辑在 onchange 里同步过滤数组、做深拷贝、算统计。改成先更新 UI 状态，计算放到 requestIdleCallback 里分批做，中间留一帧渲染。用户先看到勾选生效，结果稍后到。这个体验上的处理比纯性能数字更重要。",[15,231,233],{"id":232},"改动三埋点改成异步批量","改动三：埋点改成异步批量",[11,235,236],{},"那个第三方埋点在每次筛选时同步上报，一次 80 毫秒。改成 1 秒合并上报，用户交互路径上不再有它。",[15,238,239],{"id":239},"结果和一条教训",[11,241,242],{},"三处改完，P75 从 420 到 180 毫秒，P95 从 1100 到 340 毫秒。客户那边的反馈从\"卡\"变成\"还行\"。",[15,244,245],{"id":245},"落地时的协作问题",[11,247,248],{},"这类改动最大的阻力不是技术，是排期。虚拟化要改列表组件，筛选要改状态管理，埋点要跟第三方沟通，三件事分属三个人的活。我们的做法是先做一行能立刻验证的改动——把埋点延后，半天就上线，第二天客户能自己看到数据变化。有了这个信任，后面两周的排期才好谈。",[11,250,251],{},"另一个坑是回归测试。虚拟化之后导出 CSV、全选、行内编辑全都要重新走一遍。我们让客户的产品经理列了 14 个操作场景，逐个手点，漏一个就是线上事故。",[15,253,254],{"id":254},"一条教训",[11,256,257],{},"不要用开发机测 INP。我们坚持用 CPU 4 倍降速加 4G 网络复现，第一次测出来的数据比客户描述的还差。真实环境总是更差的那个，不会更好。另外 INP 改完不是立刻见效的，我们等了两周真实数据才稳定下来，因为长尾交互要攒够样本。",{"title":96,"searchDepth":97,"depth":97,"links":259},[260,261,262,263,264,265,266],{"id":208,"depth":97,"text":209},{"id":218,"depth":97,"text":219},{"id":225,"depth":97,"text":226},{"id":232,"depth":97,"text":233},{"id":239,"depth":97,"text":239},{"id":245,"depth":97,"text":245},{"id":254,"depth":97,"text":254},"2025-10-16","一个安全审计 SaaS 的客户列表页，1200 条数据七个筛选条件，点一下停半秒。虚拟化、把计算挪出事件处理器、埋点改异步三步做完，P75 从 420 毫秒降到 180 毫秒。",{},"\u002Fblog\u002Finp-improvement-case-study",{"title":197,"description":268},"blog\u002Finp-improvement-case-study",[274,275,276],"INP","性能复盘","SaaS后台","LLU_4zvtF7huMyfTTrOfWH84dF7njjzyWoG0KX32h-Q",1794088111621]