[{"data":1,"prerenderedAt":361},["ShallowReactive",2],{"blog-blog-audit-300-posts":3,"blog-prev-blog-audit-300-posts":115,"blog-next-blog-audit-300-posts":229},{"id":4,"title":5,"author":6,"body":7,"canonical":99,"category":100,"cover":99,"date":101,"description":102,"draft":103,"extension":104,"keywords":99,"meta":105,"navigation":106,"noindex":103,"ogImage":99,"path":107,"seo":108,"seoDescription":99,"seoTitle":99,"stem":109,"tags":110,"updated":99,"__hash__":114},"blog\u002Fblog\u002Fblog-audit-300-posts.md","一个 300 篇的博客站，审完只留了 78 篇","元析智能",{"type":8,"value":9,"toc":87},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84],[11,12,13],"p",{},"2026 年 6 月我们审了一个五年的老博客站，300 篇文章。最后建议：留 78 篇，并 96 篇，删 84 篇，改 42 篇。客户第一反应是“删这么多流量不会掉吗”，两个月后流量比审之前还高 6%。",[15,16,17],"h2",{"id":17},"这个站的问题在哪",[11,19,20],{},"三个。主题散，12 个不相关的方向都写过；重复多，同一个主题写过三到五篇；没有承接，大部分文章跟产品线对不上。",[11,22,23],{},"五年前写行业观察，三年前写产品更新，去年开始跟风写关键词。每年的方向都不一样，导致整个站没有主题。",[15,25,26],{"id":26},"留的标准",[11,28,29],{},"只有一条：有排名或有外链，且能对上现在的产品线。",[11,31,32],{},"78 篇里，56 篇有排名，22 篇有外链但没排名。这两类都值得留。",[15,34,35],{"id":35},"并的操作",[11,37,38],{},"96 篇合并成 31 篇。合并的原则是同一核心词、同一读者、同一结论。",[11,40,41],{},"先选主文，补齐内容，再 301。这个过程我们花了三周半，比预期慢，因为要给每篇主文补材料。",[15,43,44],{"id":44},"删的顾虑怎么处理",[11,46,47],{},"客户怕删了掉流量。我们给了两组数据：这 84 篇过去 12 个月总曝光占全站 1.7%，总点击占 0.9%。",[11,49,50],{},"删完第一周流量掉了 4%，第三周回升，两个月后比原来高 6%。删掉的是抓取预算里的噪音，不是流量。",[15,52,53],{"id":53},"结果",[11,55,56],{},"三个月后，收录页面数从 210 到 160，但有效收录比例从 52% 到 78%。抓取频次涨了，日志里每天被抓的页面从 300 多降到 180，每页被抓次数上升。",[11,58,59],{},"客户最直观的感受是：写新文章之后，收录速度快了。",[15,61,62],{"id":62},"教训",[11,64,65],{},"内容不是资产，只有被搜到的才是资产。一个站写五年，能留下四分之一就算不错。",[15,67,68],{"id":68},"审计之后怎么写新内容",[11,70,71],{},"老站审计完之后，新内容的选题全部从“留下”的那 78 篇里长出来：给它们补簇页、补对比页、补文档。",[11,73,74],{},"这样写出来的内容自带内链和已有权重，起来得比从零开新题快。",[15,76,77],{"id":77},"一个成本参考",[11,79,80],{},"300 篇的审计，我们两个人做了 11 个工作日。客户自己内部又花了 5 天做决策和沟通。",[11,82,83],{},"如果你们站不到 100 篇，三天能做完。别拖，越拖越贵。",[11,85,86],{},"我们现在给客户做年度复盘，都会顺带看一眼“无效页面占比”。超过 60% 的，先审计再扩写。",{"title":88,"searchDepth":89,"depth":89,"links":90},"",2,[91,92,93,94,95,96,97,98],{"id":17,"depth":89,"text":17},{"id":26,"depth":89,"text":26},{"id":35,"depth":89,"text":35},{"id":44,"depth":89,"text":44},{"id":53,"depth":89,"text":53},{"id":62,"depth":89,"text":62},{"id":68,"depth":89,"text":68},{"id":77,"depth":89,"text":77},null,"内容运营","2026-10-09","2026 年 6 月我们审了一个五年的老博客站：留 78 篇、并 96 篇、删 84 篇、改 42 篇。客户最担心删了掉流量，实际两个月后流量比审之前还高 6%。",false,"md",{},true,"\u002Fblog\u002Fblog-audit-300-posts",{"title":5,"description":102},"blog\u002Fblog-audit-300-posts",[111,112,113],"内容审计","复盘","博客运营","BeXglAleqx5QaAGL5FMO3tEWCjC1SBagwwp3Y_vHgqE",{"id":116,"title":117,"author":6,"body":118,"canonical":99,"category":217,"cover":99,"date":218,"description":219,"draft":103,"extension":104,"keywords":99,"meta":220,"navigation":106,"noindex":103,"ogImage":99,"path":221,"seo":222,"seoDescription":99,"seoTitle":99,"stem":223,"tags":224,"updated":99,"__hash__":228},"blog\u002Fblog\u002Fweak-network-testing.md","弱网测试只开 3G 降速，会漏掉一半问题",{"type":8,"value":119,"toc":208},[120,123,127,130,133,136,139,142,145,148,151,154,157,160,163,166,169,172,175,178,181,184,187,190,193,196,199,202,205],[11,121,122],{},"2026 年 10 月我们做了一组弱网测试，同一个页面，三种配置，首屏时间从 1.8 秒到 4.1 秒。差异不是页面本身的问题，是测试条件不同。只用 DevTools 的 3G 降速，会漏掉一半真实问题。",[15,124,126],{"id":125},"devtools-降速只模拟了两件事","DevTools 降速只模拟了两件事",[11,128,129],{},"它限制了带宽和往返延迟，就这两件。",[11,131,132],{},"它不会模拟丢包。真实弱网环境下丢包率能到 1% 到 3%，一次丢包触发重传，时间就多出好几百毫秒。",[11,134,135],{},"它也不会模拟手机的 CPU 压力。真机上页面在加载，还有其他应用在后台，CPU 不是满血状态。",[15,137,138],{"id":138},"真实弱网的三个特征",[11,140,141],{},"第一，高延迟。4G 在信号弱的地方，往返延迟能到 200 到 400 毫秒。",[11,143,144],{},"第二，丢包。基站的负载、电梯、地铁、地下车库，都会造成间歇性丢包。",[11,146,147],{},"第三，带宽波动。同一个位置，人一多，速度掉一半。",[15,149,150],{"id":150},"我们用的三种配置",[11,152,153],{},"第一种，3G 快速，带宽 1.6 兆，延迟 150 毫秒。用来测基本可用性。",[11,155,156],{},"第二种，4G 弱信号，带宽 1 兆，延迟 400 毫秒，丢包 1%。这个最接近地铁和商场。",[11,158,159],{},"第三种，自定义慢速，带宽 400KB，延迟 600 毫秒。用来测极端情况，看页面会不会直接崩。",[11,161,162],{},"我们的验收标准是第二种通过即可，第三种只做参考。",[15,164,165],{"id":165},"用真机做真实弱网",[11,167,168],{},"DevTools 的模拟再准，也比不上真实环境。",[11,170,171],{},"最简单的办法：手机开热点，笔记本连上去，用系统工具给热点限速。测出来的数据比 DevTools 更接近实际。",[11,173,174],{},"更真实的做法是走到地铁、电梯、商场这些地方打开页面，录屏。看哪一步卡住。这种方法不能量化，但能发现一些数据里看不出的问题。",[15,176,177],{"id":177},"弱网下先看什么",[11,179,180],{},"先看请求数量。弱网下每个请求都要一个来回，请求少的页面天然占优。",[11,182,183],{},"再看首屏资源体积。超过 1 兆的首屏资源，弱网下基本要等三秒以上。",[11,185,186],{},"最后看有没有串行依赖。CSS 里有 @import、JS 里动态加载 CSS，这类串行在弱网下会被放大好几倍。",[15,188,189],{"id":189},"一个成本很低的改进",[11,191,192],{},"请求数是弱网下最敏感的因素。我们给一个站把首屏的七个图标字体合成一个 SVG 精灵图，请求从七个变成一个，弱网首屏快了 400 毫秒。",[11,194,195],{},"这个改动一天能做完，不用改设计。弱网优化里，减少请求的收益通常比压缩体积大，因为每个请求都要一次来回。",[15,197,198],{"id":198},"一个态度",[11,200,201],{},"弱网测试的意义不是追求极端环境下的完美，是知道自己的页面在什么条件下会崩。",[11,203,204],{},"大部分软件公司的客户里，有一部分人就是在弱网环境下访问的，可能是出差、可能在客户现场。",[11,206,207],{},"对这些用户来说，首屏晚两秒可能就关掉页面了。这个损失在报表里看不到，但真实存在。",{"title":88,"searchDepth":89,"depth":89,"links":209},[210,211,212,213,214,215,216],{"id":125,"depth":89,"text":126},{"id":138,"depth":89,"text":138},{"id":150,"depth":89,"text":150},{"id":165,"depth":89,"text":165},{"id":177,"depth":89,"text":177},{"id":189,"depth":89,"text":189},{"id":198,"depth":89,"text":198},"技术SEO","2026-10-08","我们把同一页放在三种弱网配置下测，首屏差了 2.3 秒。DevTools 的降速只模拟网络，不模拟丢包和真实手机的处境，这篇写我们的替代测法。",{},"\u002Fblog\u002Fweak-network-testing",{"title":117,"description":219},"blog\u002Fweak-network-testing",[225,226,227],"弱网测试","页面体验","移动端","6A-BcrO1X4nN_D1bYIQBUJfQlMjiZET3Jj5ZyeM2nYE",{"id":230,"title":231,"author":6,"body":232,"canonical":99,"category":100,"cover":99,"date":351,"description":352,"draft":103,"extension":104,"keywords":99,"meta":353,"navigation":106,"noindex":103,"ogImage":99,"path":354,"seo":355,"seoDescription":99,"seoTitle":99,"stem":356,"tags":357,"updated":99,"__hash__":360},"blog\u002Fblog\u002Fcontent-production-pipeline.md","内容生产流水线：从选题到发布的 7 个环节，每个环节卡在哪",{"type":8,"value":233,"toc":342},[234,237,240,243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,291,294,297,300,303,306,309,312,315,318,321,324,327,330,333,336,339],[11,235,236],{},"内容团队效率低，通常不是写得慢，是环节之间互相等。我们把生产拆成 7 个环节：选题、关键词、大纲、初稿、审稿、发布、复盘，每个环节定负责人和产出物。",[15,238,239],{"id":239},"七个环节",[11,241,242],{},"选题：确定写什么，产出是一个标题加一句为什么写。",[11,244,245],{},"关键词：确定目标词和词群，产出是一张关键词表。",[11,247,248],{},"大纲：确定结构，产出是 H2\u002FH3 和每节要点。",[11,250,251],{},"初稿：写成可读的稿子，产出是 1500 到 4000 字的 Markdown。",[11,253,254],{},"审稿：事实、结构、语言三层检查，产出是修改意见和终稿。",[11,256,257],{},"发布：排版、配图、内链、提交收录，产出是线上页面。",[11,259,260],{},"复盘：发布后 30 天看数据，产出是一条结论。",[15,262,263],{"id":263},"每个环节的负责人",[11,265,266],{},"选题和关键词：内容负责人。",[11,268,269],{},"大纲：写手和内容负责人一起定。",[11,271,272],{},"初稿：写手。",[11,274,275],{},"审稿：内容负责人加一个业务同事。",[11,277,278],{},"发布：运营。",[11,280,281],{},"复盘：内容负责人。",[11,283,284],{},"关键不是谁做，是每个环节都有明确的人，别出现\"大家都以为别人会做\"。",[15,286,287],{"id":287},"最容易卡住的环节",[11,289,290],{},"第一个卡点，大纲。写手等大纲，内容负责人没时间定，一等就是三天。",[11,292,293],{},"解法：大纲用 30 分钟的会一次定完，当场确认，别来回改。",[11,295,296],{},"第二个卡点，审稿。稿子压在一堆事后面，一周没人看。",[11,298,299],{},"解法：固定审稿时间，比如每周二、周四上午，其他时间不接审稿。",[11,301,302],{},"第三个卡点，发布。排版和配图拖延，稿子写完三天才上线。",[11,304,305],{},"解法：发布包给运营，写手写完就交，别等排版。",[15,307,308],{"id":308},"我们的流水线怎么跑",[11,310,311],{},"每周一上午定选题和大纲，周二到周四写初稿，周五统一审稿，周一批量发布。",[11,313,314],{},"2025 年 10 月我们把流程定下来，一篇文章从选题到上线 7 到 10 天，同时跑 4 到 6 篇，产能稳定在每周 3 篇。",[15,316,317],{"id":317},"一个提醒",[11,319,320],{},"流水线的目的是减少等待，不是把人变成机器。写手需要思考时间，审稿需要判断时间，这些别压缩。",[11,322,323],{},"我们一般给每篇留 1.5 天的缓冲，防止突发情况卡住整条线。",[15,325,326],{"id":326},"我们用什么工具",[11,328,329],{},"不用复杂的系统。一张在线表格管选题和状态，一个共享文档放终稿，一个日历排发布时间。",[11,331,332],{},"工具越简单，越容易坚持。我们试过两个内容管理系统，最后都回到了表格，因为团队宁愿用熟悉的工具。",[15,334,335],{"id":335},"一句判断",[11,337,338],{},"内容产能的瓶颈，往往不在写，在交接。把交接规则定清楚，同样的团队能多产出 30%。",[11,340,341],{},"流程不用复杂，一张表、几个固定时间点就够。",{"title":88,"searchDepth":89,"depth":89,"links":343},[344,345,346,347,348,349,350],{"id":239,"depth":89,"text":239},{"id":263,"depth":89,"text":263},{"id":287,"depth":89,"text":287},{"id":308,"depth":89,"text":308},{"id":317,"depth":89,"text":317},{"id":326,"depth":89,"text":326},{"id":335,"depth":89,"text":335},"2026-10-10","内容团队效率低，通常不是写得慢，是环节之间互相等。我们把生产拆成 7 个环节：选题、关键词、大纲、初稿、审稿、发布、复盘，每个环节定负责人和产出物。流程、卡点和一个跑顺的案例都在这篇，流程表可以直接抄。",{},"\u002Fblog\u002Fcontent-production-pipeline",{"title":231,"description":352},"blog\u002Fcontent-production-pipeline",[358,359,100],"内容流程","内容团队","lOq75rW301Dnk9g-21bHDlwMnf0LYrqihUm274jrrJU",1794088100959]