[{"data":1,"prerenderedAt":342},["ShallowReactive",2],{"blog-second-article-chance":3,"blog-prev-second-article-chance":127,"blog-next-second-article-chance":244},{"id":4,"title":5,"author":6,"body":7,"canonical":111,"category":112,"cover":111,"date":113,"description":114,"draft":115,"extension":116,"keywords":111,"meta":117,"navigation":118,"noindex":115,"ogImage":111,"path":119,"seo":120,"seoDescription":111,"seoTitle":111,"stem":121,"tags":122,"updated":111,"__hash__":126},"blog\u002Fblog\u002Fsecond-article-chance.md","同一个话题别人写过了，第二篇还有机会吗","元析智能",{"type":8,"value":9,"toc":99},"minimark",[10,14,19,22,25,28,32,35,38,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87,90,93,96],[11,12,13],"p",{},"关键词被大站占满，不代表不能写。我们判断\"第二篇有没有机会\"看三个信号：SERP 里有没有旧内容、有没有没被覆盖的子问题、我们有没有独家素材。",[15,16,18],"h2",{"id":17},"先看-serp-的年龄结构","先看 SERP 的\"年龄结构\"",[11,20,21],{},"如果前 10 名里有 5 篇以上是两年前的文章，说明这个题的更新需求存在，第二篇有机会。",[11,23,24],{},"如果前 10 名都是近半年更新的，说明竞争激烈，除非有独家，否则别碰。",[11,26,27],{},"我们 2026 年 3 月做过一个统计：软件类关键词里，前 10 名平均有 3.2 篇是两年前的。这个比例不低，说明\"旧内容\"是常见机会。",[15,29,31],{"id":30},"信号二有没有没被覆盖的子问题","信号二：有没有没被覆盖的子问题",[11,33,34],{},"把前 10 名的标题和小标题拆开，看哪些用户问题没人回答。",[11,36,37],{},"一个典型例子：所有讲\"日志管理\"的文章都在讲工具对比，没人讲\"日志量上来之后成本怎么控\"。这就是空白。",[15,39,41],{"id":40},"信号三我们有没有独家素材","信号三：我们有没有独家素材",[11,43,44],{},"独家素材包括：实测数据、客户案例、内部踩坑、原创调研。",[11,46,47],{},"有独家，第二篇能写得比第一篇好；没有独家，第二篇就是\"换个说法再写一遍\"，搜索引擎不需要。",[15,49,50],{"id":50},"三种可以写第二篇的情况",[11,52,53],{},"第一种，SERP 老旧。前 10 名里超过一半是两年前的，且内容有明显过时（工具下架、价格变了）。",[11,55,56],{},"第二种，有空白子问题。用户真正关心的问题没人讲，或者讲得很浅。",[11,58,59],{},"第三种，我们有独家案例。客户愿意公开的使用数据、踩坑记录，这些别人拿不到。",[15,61,62],{"id":62},"三种不该写的情况",[11,64,65],{},"第一种，前 10 名都是大站的旗舰内容，更新频繁、数据完整、外链多。硬碰是浪费。",[11,67,68],{},"第二种，话题本身没有搜索需求，只是\"看起来该写\"。",[11,70,71],{},"第三种，写了也没法承接。用户看完这篇文章，没有下一步动作可做。",[15,73,74],{"id":74},"我们写第二篇的做法",[11,76,77],{},"第一步，先选题角度，不选关键词。同一个词，找一个别人没写过的角度。",[11,79,80],{},"第二步，标题明确\"第二篇\"的差异。比如别人写\"日志管理工具对比\"，我们写\"日志管理成本怎么算：3 个真实账单\"。",[11,82,83],{},"第三步，内链到自己的相关文章，形成主题集群。",[15,85,86],{"id":86},"一个例子",[11,88,89],{},"\"API 监控\"这个词，前 10 名全是工具对比。我们 2025 年 12 月写了\"API 监控告警太多怎么办\"，讲告警降噪，用的是三个客户的真实数据。",[11,91,92],{},"上线 6 周排到第 8，因为这个词下的子问题没人认真写过。",[15,94,95],{"id":95},"一句判断",[11,97,98],{},"第二篇的机会不在\"写得更全\"，在\"写得更准\"。找一个别人没回答好的问题，用独家素材回答它，比重新写一遍大而全的指南有效。",{"title":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107,108,109,110],{"id":17,"depth":101,"text":18},{"id":30,"depth":101,"text":31},{"id":40,"depth":101,"text":41},{"id":50,"depth":101,"text":50},{"id":62,"depth":101,"text":62},{"id":74,"depth":101,"text":74},{"id":86,"depth":101,"text":86},{"id":95,"depth":101,"text":95},null,"内容运营","2026-07-04","关键词被大站占满，不代表不能写。我们判断“第二篇有没有机会”看三个信号：SERP 里有没有旧内容、有没有没被覆盖的子问题、我们有没有独家素材。三种可以写、三种别写的情况都在这篇，看完能判断一个词值不值得做第二篇。",false,"md",{},true,"\u002Fblog\u002Fsecond-article-chance",{"title":5,"description":114},"blog\u002Fsecond-article-chance",[123,124,125],"内容选题","竞争分析","信息增益","q58FmhznOTr8Hs1Us4Pi33tLECWoz7JgWPErIw3XD88",{"id":128,"title":129,"author":6,"body":130,"canonical":111,"category":232,"cover":111,"date":233,"description":234,"draft":115,"extension":116,"keywords":111,"meta":235,"navigation":118,"noindex":115,"ogImage":111,"path":236,"seo":237,"seoDescription":111,"seoTitle":111,"stem":238,"tags":239,"updated":111,"__hash__":243},"blog\u002Fblog\u002Fthird-party-script-audit.md","第三方脚本治理，先砍掉不产生价值的那几个",{"type":8,"value":131,"toc":223},[132,135,139,142,145,148,151,154,157,160,163,166,169,172,175,178,181,184,187,190,193,196,199,202,205,208,211,214,217,220],[11,133,134],{},"2026 年 7 月我们给一个 SaaS 站清点第三方脚本，23 个域，占了主线程接近一半的时间。逐个查完，其中 9 个从上线到现在没有产生过任何转化，也没人说得清是谁加的。",[15,136,138],{"id":137},"先清点别先优化","先清点，别先优化",[11,140,141],{},"打开 DevTools 的 Network 面板，按域名分组，把第三方域列出来。再看每个脚本的体积、加载时机、执行耗时。",[11,143,144],{},"更省事的办法是用 Lighthouse 的第三方汇总，它会把每个域占用的主线程时间列出来，排序很清楚。",[11,146,147],{},"清点这一步最容易被跳过，但它是唯一能发现“没人知道这脚本干嘛”的步骤。",[15,149,150],{"id":150},"分三类处理",[11,152,153],{},"第一类，必须有。统计、客服、支付、登录。这些直接支撑业务，不能砍，但可以调加载方式。",[11,155,156],{},"第二类，有时用。A\u002FB 测试、热图、会话录制。项目期间开，项目结束关掉，别一直挂着。",[11,158,159],{},"第三类，可以砍。营销像素、聊天插件、推荐组件、社交分享按钮。这类东西装的时候都觉得有用，一年后没人记得。",[15,161,162],{"id":162},"加载时机怎么调",[11,164,165],{},"统计脚本用 defer，别阻塞。",[11,167,168],{},"客服插件改成用户点击或者滚动到一定位置再加载，首屏完全不加载。",[11,170,171],{},"A\u002FB 测试脚本尽量自托管，减少一次 DNS 和 TLS。",[11,173,174],{},"视频、地图、评论这类嵌入内容，用一个占位图代替，用户点击后再加载真实内容。",[15,176,177],{"id":177},"一个具体数字",[11,179,180],{},"客服插件是第三方脚本里最重的，常见体积 200 到 400KB，还要建立 WebSocket 连接。",[11,182,183],{},"我们给一个站把它改成延迟加载之后，主线程阻塞时间减少了 380 毫秒，首屏 LCP 提前了 200 多毫秒。",[11,185,186],{},"这个改动只花了半天，比重构业务代码划算得多。",[15,188,189],{"id":189},"治理要有规则",[11,191,192],{},"第一，新加任何第三方脚本要报备，写清用途、体积、加载方式。",[11,194,195],{},"第二，季度审计一次，把没产生价值的清掉。",[11,197,198],{},"第三，上线前设预算，第三方脚本总执行时间不超过 500 毫秒，超了要评审。",[11,200,201],{},"没有规则，脚本只会越来越多。三年后你会发现站上跑着四十个脚本，没人敢删。",[15,203,204],{"id":204},"一个常见的反对意见",[11,206,207],{},"“这个脚本是市场部要的”。这句话我们听过很多次。处理办法不是争论，是把主线程耗时和转化数据放在一起给对方看。",[11,209,210],{},"如果脚本确实在产生线索，留着；如果一年零转化，市场部自己也会同意关掉。",[15,212,213],{"id":213},"一个态度",[11,215,216],{},"第三方脚本治理是性能优化里性价比最高的一件事，因为它不需要改业务代码，只要做减法。",[11,218,219],{},"但它需要跨部门协调，因为每个脚本背后都有人负责。这也是它经常被搁置的原因。",[11,221,222],{},"我们的做法是先出一份清单，标出每个脚本的主线程耗时和最近一次带来的转化，让数据说话。清单摆出来，砍哪个不用我们开口。",{"title":100,"searchDepth":101,"depth":101,"links":224},[225,226,227,228,229,230,231],{"id":137,"depth":101,"text":138},{"id":150,"depth":101,"text":150},{"id":162,"depth":101,"text":162},{"id":177,"depth":101,"text":177},{"id":189,"depth":101,"text":189},{"id":204,"depth":101,"text":204},{"id":213,"depth":101,"text":213},"技术SEO","2026-07-03","一个站 23 个第三方脚本，9 个从没带来过转化。这篇写怎么清点、分三类处理、加载时机怎么调，以及上线前的准入规则，附一份季度审计清单。",{},"\u002Fblog\u002Fthird-party-script-audit",{"title":129,"description":234},"blog\u002Fthird-party-script-audit",[240,241,242],"第三方脚本","性能治理","页面体验","Z8hedxrnrsVt4sLlslJ3KOd9eErOUXUUFqjyw89RVg8",{"id":245,"title":246,"author":6,"body":247,"canonical":111,"category":112,"cover":111,"date":331,"description":332,"draft":115,"extension":116,"keywords":111,"meta":333,"navigation":118,"noindex":115,"ogImage":111,"path":334,"seo":335,"seoDescription":111,"seoTitle":111,"stem":336,"tags":337,"updated":111,"__hash__":341},"blog\u002Fblog\u002Ftopic-hub-page-structure.md","专题页怎么组织：一个入口带二十篇，别做成第二支柱页",{"type":8,"value":248,"toc":322},[249,252,255,258,261,264,267,270,273,276,279,282,285,288,292,295,298,301,304,307,310,313,316,319],[11,250,251],{},"支柱页按知识组织，专题页按任务组织。这两个混着做过一次，专题页写成了第二支柱页，结果两个页面都不排。2026 年 3 月我们给一个客户重做了一个“系统迁移”专题页，八周带来 27 个咨询。",[15,253,254],{"id":254},"专题页是什么",[11,256,257],{},"围绕一个任务、一个阶段或一个事件组织的聚合页。比如“从自建迁移到云”“出海合规”“大促前的容量准备”。",[11,259,260],{},"它的判断标准不是覆盖了多少知识，是能不能帮人完成一件事。",[15,262,263],{"id":263},"跟支柱页的区别",[11,265,266],{},"支柱页回答“这个领域有哪些问题”，专题页回答“我要做这件事，先看什么”。",[11,268,269],{},"支柱页的结构是问题树，专题页的结构是任务路径。路径上有先后顺序，问题树没有。",[15,271,272],{"id":272},"一个专题页该有什么",[11,274,275],{},"五块：任务入口（三到五条路径，按情况分）、按角色分的内容（采购看什么、技术看什么）、一份清单或模板、两三个案例、一个明确的下一步动作。",[11,277,278],{},"五块缺一块，页面就会显得空，读者看完不知道干什么。",[15,280,281],{"id":281},"具体那个例子",[11,283,284],{},"客户的专题页叫“迁移到云上日志平台”，入口按“数据量大小”分三条路径，每条路径链到三篇具体的迁移教程。",[11,286,287],{},"页面中间放了一份迁移检查清单，可以下载。底部是三个不同规模的迁移案例。",[15,289,291],{"id":290},"url-和生命周期","URL 和生命周期",[11,293,294],{},"放 \u002Ftopics\u002F 下，不要放 \u002Fblog\u002F。专题页是有生命周期的，一般 12 到 18 个月，过期了要下线或者改成常青页。",[11,296,297],{},"我们建议每个专题页写一个复查日期，到期看一次：还成立就更新，不成立就并进支柱页。",[15,299,300],{"id":300},"内链怎么走",[11,302,303],{},"专题页链到簇页和文档，簇页不一定链回专题页。专题页是入口，不是中心。",[11,305,306],{},"如果簇页也链回专题页，整组会变成两个中心，权重分散。",[15,308,309],{"id":309},"一年做几个",[11,311,312],{},"两个就够。专题页需要素材、案例、设计配合，做多了每个都做不深。",[11,314,315],{},"我们的判断是：只有当一件事有明确的先后步骤、有多个角色参与、能做出一份可下载的东西时，才值得单独做专题页。",[11,317,318],{},"专题页做得好，带来的咨询质量比博客高。因为搜索它的人已经在计划做一件事，不是在看概念。",[11,320,321],{},"反过来，如果一个词搜的人只是想知道“是什么”，别给他做专题页，浪费设计资源。",{"title":100,"searchDepth":101,"depth":101,"links":323},[324,325,326,327,328,329,330],{"id":254,"depth":101,"text":254},{"id":263,"depth":101,"text":263},{"id":272,"depth":101,"text":272},{"id":281,"depth":101,"text":281},{"id":290,"depth":101,"text":291},{"id":300,"depth":101,"text":300},{"id":309,"depth":101,"text":309},"2026-07-05","支柱页按知识组织，专题页按任务组织。混着做过一次，专题页变成第二支柱页，两个都不排。这篇写专题页该有什么、跟支柱页的区别，以及什么情况下该做。",{},"\u002Fblog\u002Ftopic-hub-page-structure",{"title":246,"description":332},"blog\u002Ftopic-hub-page-structure",[338,339,340],"专题页","内容架构","页面组织","SxHQ8Rtktsd1nlAWL-pSG09Lnr0a95oIx4po9xhqf8M",1794088104121]