[{"data":1,"prerenderedAt":283},["ShallowReactive",2],{"blog-site-architecture-by-intent":3,"blog-prev-site-architecture-by-intent":102,"blog-next-site-architecture-by-intent":187},{"id":4,"title":5,"author":6,"body":7,"canonical":86,"category":87,"cover":86,"date":88,"description":89,"draft":90,"extension":91,"keywords":86,"meta":92,"navigation":93,"noindex":90,"ogImage":86,"path":94,"seo":95,"seoDescription":86,"seoTitle":86,"stem":96,"tags":97,"updated":86,"__hash__":101},"blog\u002Fblog\u002Fsite-architecture-by-intent.md","软件站栏目怎么分：按产品、按场景还是按行业","元析智能",{"type":8,"value":9,"toc":76},"minimark",[10,14,18,25,31,37,40,43,46,49,52,55,58,61,64,67,70,73],[11,12,13],"p",{},"栏目分法要匹配用户的搜索意图，不是匹配公司的部门。软件公司最容易犯的错，是把组织架构图直接搬成网站导航——产品部有几个产品，导航就有几个栏目，用户从搜索进来之后一脸茫然。",[15,16,17],"h2",{"id":17},"三种分法各自适合谁",[11,19,20,24],{},[21,22,23],"strong",{},"按产品分","：适合产品线清晰、每款有独立卖点的公司。产品超过 6 个之后栏目会爆炸，而且用户搜的往往不是你的产品名。",[11,26,27,30],{},[21,28,29],{},"按场景分","：适合解决具体业务问题的工具，比如数据同步、报表自动化、合同审批。优势是天然匹配搜索词，劣势是需要内容团队持续产出场景页。",[11,32,33,36],{},[21,34,35],{},"按行业分","：适合垂直行业软件，医疗、制造、教育。行业词竞争小，但内容量需求大，每个行业至少要 10 页才撑得起来，不然就是薄页。",[15,38,39],{"id":39},"两个相反的案例",[11,41,42],{},"2025 年 9 月，一个 HR SaaS 原来按产品分了 9 个栏目，招聘、考勤、薪酬各 3 到 5 页。用户从搜索进来先落到产品页，然后找不到\"我这种规模的公司怎么用\"。改成按场景分——招聘流程自动化、多地考勤合规、薪酬核算——产品作为二级入口，6 个月后落地页自然点击涨 58%，跳出率降了 11 个百分点。",[11,44,45],{},"2025 年 11 月，一个工业软件客户反过来做才有效，按行业分（汽车、电子、能源）比按产品分好，因为采购搜的就是\"汽车行业 MES 系统\"。他们的产品名词在行业里并不通用，用户根本不知道搜什么。",[15,47,48],{"id":48},"判断标准",[11,50,51],{},"把 GSC 里有展示的词导出来，按三类分组：产品名、问题场景、行业。哪类词的数量和点击最多，主导航就按哪类做。这是数据决策，不是审美决策。",[11,53,54],{},"如果三类都差不多，用混合结构：主导航按场景，二级按产品，行业做成独立的落地页矩阵但不进主导航。我们给大多数 SaaS 客户都用这个结构。",[15,56,57],{"id":57},"结构落地的三个硬要求",[11,59,60],{},"每个栏目必须有稳定的归档页，能承接内链；面包屑层级要真实；栏目之间不能互相 canonical。上线后看点击深度，平均超过 4 层就说明结构没搭好。",[15,62,63],{"id":63},"改结构要付的代价",[11,65,66],{},"栏目一改，URL 全变，老链接全部要 301，内链要重排，sitemap 要重生成。我们做过一次场景化改造，涉及 400 个 URL，301 映射表做了三天，上线后两周流量掉了 15%，第 6 周才回到原来的水平。所以这个决定一年最多做一次，别反复调。",[11,68,69],{},"如果只是导航位置调整、URL 不变，成本几乎为零，可以小步试。",[15,71,72],{"id":72},"立场",[11,74,75],{},"别照搬竞品的导航。竞品有品牌词和直接流量，你没有。你的结构要让完全不知道你名字的人，靠搜索词就能落到对的页面。",{"title":77,"searchDepth":78,"depth":78,"links":79},"",2,[80,81,82,83,84,85],{"id":17,"depth":78,"text":17},{"id":39,"depth":78,"text":39},{"id":48,"depth":78,"text":48},{"id":57,"depth":78,"text":57},{"id":63,"depth":78,"text":63},{"id":72,"depth":78,"text":72},null,"技术SEO","2026-02-24","三种分法我们都试过。软件站的结构要按用户找东西的路径分，不是按公司组织架构分。这篇用两个客户的栏目改造，给出可执行的判断标准和混合结构。",false,"md",{},true,"\u002Fblog\u002Fsite-architecture-by-intent",{"title":5,"description":89},"blog\u002Fsite-architecture-by-intent",[98,99,100],"信息架构","站点结构","内链","Qf2EYZLUaQlI98msHwsmUmJ2qD0il-eCVlMDwanRZ8U",{"id":103,"title":104,"author":6,"body":105,"canonical":86,"category":175,"cover":86,"date":176,"description":177,"draft":90,"extension":91,"keywords":86,"meta":178,"navigation":93,"noindex":90,"ogImage":86,"path":179,"seo":180,"seoDescription":86,"seoTitle":86,"stem":181,"tags":182,"updated":86,"__hash__":186},"blog\u002Fblog\u002Flog-daily-digest-script.md","把抓取日志做成每日简报，六十行脚本的事",{"type":8,"value":106,"toc":167},[107,110,113,116,119,122,125,128,131,134,137,140,143,146,149,152,155,158,161,164],[11,108,109],{},"2026 年 3 月我们给三个站上了日志简报，每天早上 9 点一条消息推送到项目群，四个数字，六十行脚本。上线两个月，比之前做的那个交互式日志看板有用得多，因为看板没人打开。",[15,111,112],{"id":112},"简报只放四个数",[11,114,115],{},"蜘蛛请求总数，和过去 7 日均值比；各搜索引擎的占比，Google 和百度分开；新增 404 的数量；抓取最多的三个目录和最少的一个核心目录。",[11,117,118],{},"四个数之外的东西都不放。日志里能算的指标有几十个，全放进去就没人看了。我们的原则是：一条消息能在手机屏幕上读完，超过这个长度就是失败。",[15,120,121],{"id":121},"怎么算",[11,123,124],{},"统计窗口取前一天 0 点到 24 点，避开当天日志没写完的问题。蜘蛛请求要按 IP 反查验证，不能只信 UA，否则一堆假蜘蛛会把数字抬高。",[11,126,127],{},"和过去 7 日均值对比，波动超过正负 30% 的标红。这个阈值是试出来的：低于 30% 的波动基本都是正常起伏，天天标红等于没标。",[15,129,130],{"id":130},"脚本结构",[11,132,133],{},"读日志、筛蜘蛛、聚合、生成 markdown、推送到群机器人，五步。中间任何一步失败都要抛异常，不能静默跳过。",[11,135,136],{},"我们踩过一个坑：日志文件某天没轮转，脚本读到空文件，照样推送了一条“今日抓取 0 次”。第二天团队以为站挂了，查了半天。现在脚本会先校验文件行数，低于阈值直接报错。",[15,138,139],{"id":139},"数据不准的时候怎么发现",[11,141,142],{},"简报最怕数字全对但没人看。我们的办法是每天加一句备注，把和昨天差异最大的那项写出来，比如“百度蜘蛛请求掉了 42%”或者“新增 404 集中在 docs\u002Fv1 目录”。",[11,144,145],{},"写这句要两分钟，但团队会在群里接话。数字本身没人讨论，一句结论有人讨论。",[11,147,148],{},"还有一点，简报只发工作日。周末日志量本来就低，发出来只制造噪音，周一早上合并成一条就行。",[15,150,151],{"id":151},"为什么不做看板",[11,153,154],{},"看板的问题是没人主动打开。我们做过一个，数据比简报全，可交互，上线一个月后台访问记录不到 20 次，还都是我们自己点的。",[11,156,157],{},"群消息不一样，它推到你面前。有异常的时候大家会在群里讨论，没异常的时候看一眼就过。这个交互成本低得多。",[15,159,160],{"id":160},"用下来的感受",[11,162,163],{},"两个月里发现过两次真正的异常：一次是 CDN 配置改动导致百度蜘蛛全部被拦，一次是站点地图生成失败影响了新页面抓取。都是当天就发现了，没有拖到周报。",[11,165,166],{},"它不是诊断工具，只是提醒你去看。真要分析还是得回到日志和 GSC，但有人提醒和没人提醒，差别很大。",{"title":77,"searchDepth":78,"depth":78,"links":168},[169,170,171,172,173,174],{"id":112,"depth":78,"text":112},{"id":121,"depth":78,"text":121},{"id":130,"depth":78,"text":130},{"id":139,"depth":78,"text":139},{"id":151,"depth":78,"text":151},{"id":160,"depth":78,"text":160},"工具评测","2026-02-23","日志看板没人打开，群里每天一条简报却有人讨论。这篇写简报的四个数字、脚本结构、异常判定阈值，以及为什么别做交互看板。文末附阈值设置。",{},"\u002Fblog\u002Flog-daily-digest-script",{"title":104,"description":177},"blog\u002Flog-daily-digest-script",[183,184,185],"日志分析","自动化","简报","cp4JatvdKR5kPj8wtMXOz8m3PfnA_QFCGGCOvmXTOdo",{"id":188,"title":189,"author":6,"body":190,"canonical":86,"category":87,"cover":86,"date":272,"description":273,"draft":90,"extension":91,"keywords":86,"meta":274,"navigation":93,"noindex":90,"ogImage":86,"path":275,"seo":276,"seoDescription":86,"seoTitle":86,"stem":277,"tags":278,"updated":86,"__hash__":282},"blog\u002Fblog\u002Ffont-subset-maintenance.md","字体子集上线三个月就失效，问题出在维护上",{"type":8,"value":191,"toc":265},[192,195,198,201,204,207,210,226,229,232,235,238,241,249,256,259,262],[11,193,194],{},"字体子集化不是做完就完了。去年 9 月我们给一个 SaaS 官网做的子集，三个月后新上的产品文案里出现 17 个缺字，前端只能临时回退全量包，首屏字体从 280KB 涨回 2.3MB，之前的速度优化等于白做。",[15,196,197],{"id":197},"子集为什么会失效",[11,199,200],{},"子集是按\"生成那一刻页面上的字\"切的。市场部改一版文案、加一个客户名、发一篇带生僻词的博客，字符集就不够了。浏览器遇到缺字会用回退字体渲染，视觉上跳出一个字形不一样的汉字，比豆腐块好一点，但一样难看。",[11,202,203],{},"这个站先是客服收到反馈，说标题里有个字特别细。前端查了两天才定位到字体子集。临时方案是回退全量包，代价是所有人都变慢。",[15,205,206],{"id":206},"把字符集变成构建产物",[11,208,209],{},"我们的做法是把字符集从\"一次性脚本\"改成\"每次构建自动生成\"：",[211,212,213,217,220,223],"ol",{},[214,215,216],"li",{},"构建时从 CMS 拉全站文案和博客正文，统计去重字符",[214,218,219],{},"去掉 ASCII 和标点，剩下的中文字符交给自己写的子集脚本",[214,221,222],{},"在统计结果上留 5% 冗余，按常用字表补一批",[214,224,225],{},"产物随构建走，版本号和内容一起变",[11,227,228],{},"好处是文案更新会触发子集更新，不会悄悄缺字。",[15,230,231],{"id":231},"缺字监控",[11,233,234],{},"构建只能覆盖 CMS 里的内容，用户输入、第三方评论、搜索关键词都覆盖不到。我们加了一条前端监控：用 canvas 测量几个生僻字在自定义字体下的宽度，和回退字体对比，不一样就上报。",[11,236,237],{},"这个方案不完美，但能抓到大部分问题。上线两个月抓到 4 次缺字，都是编辑器里直接粘进来的内容。",[15,239,240],{"id":240},"一些具体数字",[11,242,243,244,248],{},"这个站子集后首屏字体 280KB，覆盖 4200 个字符，",[245,246,247],"code",{},"font-display"," 用 swap。首屏文字在 1.1 秒内用回退字体渲染，1.4 秒切换成自定义字体，CLS 控制在 0.02 以内。",[11,250,251,252,255],{},"回退字体用系统黑体，字宽差异小，切换不明显。如果换成宋体这种字形差别大的，就得配合 ",[245,253,254],{},"size-adjust"," 微调，不然整段重排。",[15,257,258],{"id":258},"我的建议",[11,260,261],{},"内容更新频繁的站，别做纯静态子集，做构建期自动生成。内容几乎不变的站，比如产品官网，手工子集加每季度复查也行，但要把复查写进流程，别靠记忆。",[11,263,264],{},"还有个更省事的方案：正文直接用系统字体栈，只在标题上用自定义字体。中文系统字体在 Windows 和 macOS 上都不难看，这一刀下去能省掉大部分字体问题。",{"title":77,"searchDepth":78,"depth":78,"links":266},[267,268,269,270,271],{"id":197,"depth":78,"text":197},{"id":206,"depth":78,"text":206},{"id":231,"depth":78,"text":231},{"id":240,"depth":78,"text":240},{"id":258,"depth":78,"text":258},"2026-02-25","子集按生成那天的文案切，三个月后新文案缺 17 个字，前端只能回退全量包，首屏字体从 280KB 涨回 2.3MB。把字符集变成构建产物，再加一条缺字监控。",{},"\u002Fblog\u002Ffont-subset-maintenance",{"title":189,"description":273},"blog\u002Ffont-subset-maintenance",[279,280,281],"字体加载","子集化","构建流程","iNigoUEjsCcEFimUiLFJgR_nMYydx8AAclNtXBeCrt8",1794088108113]