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