[{"data":1,"prerenderedAt":295},["ShallowReactive",2],{"blog-dev-queue-blocking-seo":3,"blog-prev-dev-queue-blocking-seo":108,"blog-next-dev-queue-blocking-seo":197},{"id":4,"title":5,"author":6,"body":7,"canonical":92,"category":93,"cover":92,"date":94,"description":95,"draft":96,"extension":97,"keywords":92,"meta":98,"navigation":99,"noindex":96,"ogImage":92,"path":100,"seo":101,"seoDescription":92,"seoTitle":92,"stem":102,"tags":103,"updated":92,"__hash__":107},"blog\u002Fblog\u002Fdev-queue-blocking-seo.md","跨部门卡住的 SEO 项目，问题多在开发排期","元析智能",{"type":8,"value":9,"toc":82},"minimark",[10,14,18,21,24,27,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79],[11,12,13],"p",{},"2026 年 7 月我们有个客户的 title 模板改动等了整整三周才上线。不是开发不配合，是这个需求在排期表上永远排在产品需求后面。SEO 项目卡住的地方，九成不在技术，在协调。",[15,16,17],"h2",{"id":17},"最常见的三种卡点",[11,19,20],{},"第一种，需求排不进去。开发团队的排期按季度定，产品需求占满，SEO 的改动只能插空。技术 SEO 的活往往看着小，实际要回归测试，一插就影响别的。",[11,22,23],{},"第二种，没有明确负责人。改 canonical 归谁管？内容团队、开发、还是我们？三方都以为别人做，结果两周没人动。",[11,25,26],{},"第三种，改完没验证。改动上线了，但没人检查线上效果，改错了要等下一次诊断才发现。",[15,28,30],{"id":29},"为什么-seo-需求总排不上","为什么 SEO 需求总排不上",[11,32,33],{},"因为它不紧急。产品需求影响收入，故障影响可用性，SEO 影响的是三个月后的流量，排序自然靠后。",[11,35,36],{},"还因为它的收益不好量化。跟开发说“这个改动能让抓取更顺”，对方没法判断值不值得排。换成“影响 1200 个产品页的收录”，就有分量了。",[11,38,39],{},"第三，很多 SEO 需求没有工单，只在群里说一句。口头需求最容易被遗忘。",[15,41,42],{"id":42},"我们怎么推进",[11,44,45],{},"把每个改动写成工单，五项内容：影响多少页面、预期收益、验收标准、预估工时、依赖谁。",[11,47,48],{},"工时必须我们自己估。写“需要开发 2 小时”比写“优化页面结构”有效得多，开发看着能排。",[11,50,51],{},"提前一个季度把大改动提进排期。等季度中再提，基本只能等下一季度。",[11,53,54],{},"找业务负责人，不直接找开发。开发的优先级来自业务，绕过负责人去催开发，短期可能有用，长期会被讨厌。",[15,56,57],{"id":57},"一次事故",[11,59,60],{},"2025 年我们图快，让一个开发朋友直接改了 robots.txt，想屏蔽测试目录。他写成了 Disallow: \u002F，全站被屏蔽了六个小时。",[11,62,63],{},"发现的时候是搜索流量掉了九成，但当天数据还没出来，是日志里蜘蛛不来了才察觉。",[11,65,66],{},"从那以后我们的规矩是：robots 和 canonical 这类全局配置，必须双人确认，改之前截图存档，改完立刻用抓取工具验证。",[15,68,69],{"id":69},"怎么和开发建立信任",[11,71,72],{},"信任靠小事积累。我们给自己定了几条：需求写清验收标准，改完自己先验证一遍，不把没把握的东西推给开发。",[11,74,75],{},"还有一条，出问题先自己查，不第一时间甩锅。robots 那次事故，我们先写了一份复盘，说明是我们的责任，开发才愿意继续配合。",[15,77,78],{"id":78},"一句话总结",[11,80,81],{},"SEO 项目最大的风险不是技术难度，是协调成本。把需求变成工单、把收益说成数字、把风险点控制住，项目就顺了。",{"title":83,"searchDepth":84,"depth":84,"links":85},"",2,[86,87,88,89,90,91],{"id":17,"depth":84,"text":17},{"id":29,"depth":84,"text":30},{"id":42,"depth":84,"text":42},{"id":57,"depth":84,"text":57},{"id":69,"depth":84,"text":69},{"id":78,"depth":84,"text":78},null,"行业观察","2026-08-08","一个 title 模板改动等了三周，一次 robots 误改让全站被屏蔽六小时。这篇写 SEO 需求怎么进开发排期、工单怎么写、找谁推进才有效。",false,"md",{},true,"\u002Fblog\u002Fdev-queue-blocking-seo",{"title":5,"description":95},"blog\u002Fdev-queue-blocking-seo",[104,105,106],"项目推进","开发协作","排期","Gj0stXUpmja4kntcFekdADlrc44PYKc4McKNN7lViHs",{"id":109,"title":110,"author":6,"body":111,"canonical":92,"category":185,"cover":92,"date":186,"description":187,"draft":96,"extension":97,"keywords":92,"meta":188,"navigation":99,"noindex":96,"ogImage":92,"path":189,"seo":190,"seoDescription":92,"seoTitle":92,"stem":191,"tags":192,"updated":92,"__hash__":196},"blog\u002Fblog\u002Fhelpful-content-core-integration.md","Helpful Content 并入核心后，内容站还怎么写",{"type":8,"value":112,"toc":177},[113,116,119,122,125,129,132,135,138,141,144,147,150,153,156,159,162,165,168,171,174],[11,114,115],{},"Helpful Content 在 2024 年 3 月并入核心更新后，\"为搜索而写\"这套彻底失效。内容站要活下来只有两条路：有产品支撑，或者有独家信息。我们选了第三条：不做纯内容站。",[15,117,118],{"id":118},"那个更新的实际影响",[11,120,121],{},"2024 年 3 月的核心更新把 Helpful Content 系统并入了核心算法。之前它是一个独立信号，后来变成核心的一部分，影响更直接。",[11,123,124],{},"我们看到的实际变化：靠关键词布局、靠内容数量堆出来的站，排名开始不稳。2024 年下半年到 2025 年，我们手上 5 个内容站掉了 3 个。",[15,126,128],{"id":127},"为搜索而写为什么失效","\"为搜索而写\"为什么失效",[11,130,131],{},"以前做内容的逻辑是：找一个搜索量大的词，写一篇覆盖这个词的文章，排上去，吃流量。",[11,133,134],{},"现在算法判断的不只是\"这个词有没有被覆盖\"，还有\"这篇内容是不是真的有用\"。判断依据包括作者是谁、有没有实测、有没有第一手信息、站本身有没有主题权威。",[11,136,137],{},"这些恰好是\"为搜索而写\"的内容最缺的。",[15,139,140],{"id":140},"两条活路",[11,142,143],{},"第一条，有产品支撑。内容围绕产品展开，讲怎么用、解决什么问题、和竞品的差异。这类内容有天然的第一手信息，因为只有你们自己知道产品细节。",[11,145,146],{},"第二条，有独家信息。比如行业数据、实测结果、内部经验。这些内容别人抄不走，因为源头在你这里。",[11,148,149],{},"两条都占，最好。只占一条，也能活。一条都不占，纯搬运和改写，基本没戏。",[15,151,152],{"id":152},"我们的选择",[11,154,155],{},"2025 年开始我们不接纯内容站。原因很简单：帮一个没有产品、没有独家信息、没有品牌的站做排名，投入产出比太低，而且随时可能被一次更新清空。",[11,157,158],{},"我们接的都是软件公司，内容围绕产品和用户问题展开。这类内容的生命周期长，抗更新能力强。",[15,160,161],{"id":161},"一个反例",[11,163,164],{},"2025 年 6 月我们接过一个内容站，行业垂直、文笔不错、更新也勤，就是没有产品和独家信息。启动前我们判断它最多撑半年。",[11,166,167],{},"前 3 个月排名确实起来了，第 5 个月一次更新掉了 70%，再没恢复。客户后来转做产品站，用原来的内容当素材，反而稳定了。",[11,169,170],{},"这件事之后我们不再接纯内容站，也不建议客户做。它的问题不是内容不好，是站本身没有被信任的理由。",[15,172,173],{"id":173},"一句判断",[11,175,176],{},"内容站不是不能做，是门槛变高了。你要么有产品，要么有别人拿不到的信息，要么有真实的行业身份。三样都没有，写再多也是给算法当分母。",{"title":83,"searchDepth":84,"depth":84,"links":178},[179,180,181,182,183,184],{"id":118,"depth":84,"text":118},{"id":127,"depth":84,"text":128},{"id":140,"depth":84,"text":140},{"id":152,"depth":84,"text":152},{"id":161,"depth":84,"text":161},{"id":173,"depth":84,"text":173},"内容运营","2026-08-07","Helpful Content 在 2024 年 3 月并入核心更新后，“为搜索而写”这套彻底失效。内容站要活下来只有两条路：有产品支撑，或者有独家信息。我们选了第三条：不做纯内容站。这个判断是怎么来的、反例长什么样，都写在这篇里，代价不小。",{},"\u002Fblog\u002Fhelpful-content-core-integration",{"title":110,"description":187},"blog\u002Fhelpful-content-core-integration",[193,194,195],"HelpfulContent","内容策略","核心更新","KhYpt36YBuW2oqusD1ih7w2daATc-1g0hRkPfLPT9t8",{"id":198,"title":199,"author":6,"body":200,"canonical":92,"category":283,"cover":92,"date":284,"description":285,"draft":96,"extension":97,"keywords":92,"meta":286,"navigation":99,"noindex":96,"ogImage":92,"path":287,"seo":288,"seoDescription":92,"seoTitle":92,"stem":289,"tags":290,"updated":92,"__hash__":294},"blog\u002Fblog\u002Fserver-response-crawl.md","服务器慢 1 秒，抓取频次掉多少：我们测了 4 个站",{"type":8,"value":201,"toc":274},[202,205,208,211,214,217,220,223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271],[11,203,204],{},"服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。",[15,206,207],{"id":207},"我们怎么测",[11,209,210],{},"2025 年 10 月到 2026 年 3 月，我们测了 4 个站，都是软件公司官网或文档站，页面 2000 到 1.5 万。测试周期每个站 6 周：前 2 周记录基线，中间 2 周改服务器，后 2 周观察。",[11,212,213],{},"记录三个数：TTFB、每日抓取请求数、核心页平均抓取间隔。数据来源是服务器日志加两边站长后台。",[15,215,216],{"id":216},"数据",[11,218,219],{},"站 A：TTFB 1.9 秒降到 0.5 秒，Googlebot 抓取量涨 55%，百度涨 38%。\n站 B：TTFB 1.2 秒降到 0.4 秒，抓取量涨 34%。\n站 C：TTFB 2.6 秒降到 0.6 秒，抓取量涨 61%，但花了 3 周才看到变化。\n站 D：TTFB 0.8 秒降到 0.3 秒，抓取量只涨了 12%。站 D 本来抓取预算就充裕，快一点没有额外收益。",[11,221,222],{},"结论：TTFB 超过 1.5 秒的站，改善空间大；本来就快的站，优化收益小。",[15,224,225],{"id":225},"为什么响应时间影响抓取",[11,227,228],{},"搜索引擎的抓取资源有限，它会优先抓\"划算\"的站。同样一秒钟，能抓 1 个页面还是 3 个页面，直接决定它给你多少抓取配额。",[11,230,231],{},"这不是惩罚，是资源分配。响应慢的站，抓取频次会被自动压低。",[15,233,234],{"id":234},"三个隐蔽的拖慢原因",[11,236,237],{},"第一，数据库慢查询。列表页每次请求都跑一次复杂的统计查询，TTFB 上不去。",[11,239,240],{},"第二，第三方脚本在服务端阻塞。有些站把统计、客服、AB 测试的脚本放在服务端渲染链路里，一个第三方接口慢，整页就慢。",[11,242,243],{},"第三，CDN 回源配置。CDN 缓存命中率低，每个请求都回源，TTFB 高得离谱。我们一个客户缓存命中率只有 31%，调完到 94%，TTFB 直接降了一半。",[15,245,246],{"id":246},"怎么改",[11,248,249],{},"先测：分页面类型看 TTFB，首页、列表页、详情页分别测，别只看平均值。",[11,251,252],{},"再改：数据库加索引、复杂查询做缓存、第三方脚本挪到客户端异步加载、CDN 缓存规则按内容类型配。",[11,254,255],{},"最后验证：改完等两周看抓取数据，别当天就下结论。抓取频次的变化有延迟，Google 一般 1 到 2 周，百度更慢。",[15,257,258],{"id":258},"一个提醒",[11,260,261],{},"TTFB 不是排名因素，它影响的是抓取效率。别把它和 CWV 混为一谈，CWV 是用户体验指标，TTFB 是服务器指标，两者相关但不等价。",[11,263,264],{},"先看抓取是不是瓶颈，再决定要不要投入服务器优化。抓取正常的站，优化 TTFB 的收益有限。",[15,266,267],{"id":267},"判断",[11,269,270],{},"服务器响应是技术 SEO 里最\"底层\"的一环，它不直接决定排名，但决定了搜索引擎愿不愿意多来。",[11,272,273],{},"如果你的站 TTFB 超过 1.5 秒，先修这个，再谈内容。",{"title":83,"searchDepth":84,"depth":84,"links":275},[276,277,278,279,280,281,282],{"id":207,"depth":84,"text":207},{"id":216,"depth":84,"text":216},{"id":225,"depth":84,"text":225},{"id":234,"depth":84,"text":234},{"id":246,"depth":84,"text":246},{"id":258,"depth":84,"text":258},{"id":267,"depth":84,"text":267},"技术SEO","2026-08-09","服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。测试方法和三个隐蔽的拖慢原因都在这篇，看完能判断自己的站要不要优化。",{},"\u002Fblog\u002Fserver-response-crawl",{"title":199,"description":285},"blog\u002Fserver-response-crawl",[291,292,293],"TTFB","抓取","服务器","dAeuSHqJsirOpumTL5Zvo9Ea9u9M4wJA2Cs_ooZJBHE",1794088103058]