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