[{"data":1,"prerenderedAt":301},["ShallowReactive",2],{"blog-server-response-crawl":3,"blog-prev-server-response-crawl":111,"blog-next-server-response-crawl":206},{"id":4,"title":5,"author":6,"body":7,"canonical":95,"category":96,"cover":95,"date":97,"description":98,"draft":99,"extension":100,"keywords":95,"meta":101,"navigation":102,"noindex":99,"ogImage":95,"path":103,"seo":104,"seoDescription":95,"seoTitle":95,"stem":105,"tags":106,"updated":95,"__hash__":110},"blog\u002Fblog\u002Fserver-response-crawl.md","服务器慢 1 秒，抓取频次掉多少：我们测了 4 个站","元析智能",{"type":8,"value":9,"toc":84},"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],[11,12,13],"p",{},"服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。",[15,16,17],"h2",{"id":17},"我们怎么测",[11,19,20],{},"2025 年 10 月到 2026 年 3 月，我们测了 4 个站，都是软件公司官网或文档站，页面 2000 到 1.5 万。测试周期每个站 6 周：前 2 周记录基线，中间 2 周改服务器，后 2 周观察。",[11,22,23],{},"记录三个数：TTFB、每日抓取请求数、核心页平均抓取间隔。数据来源是服务器日志加两边站长后台。",[15,25,26],{"id":26},"数据",[11,28,29],{},"站 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,31,32],{},"结论：TTFB 超过 1.5 秒的站，改善空间大；本来就快的站，优化收益小。",[15,34,35],{"id":35},"为什么响应时间影响抓取",[11,37,38],{},"搜索引擎的抓取资源有限，它会优先抓\"划算\"的站。同样一秒钟，能抓 1 个页面还是 3 个页面，直接决定它给你多少抓取配额。",[11,40,41],{},"这不是惩罚，是资源分配。响应慢的站，抓取频次会被自动压低。",[15,43,44],{"id":44},"三个隐蔽的拖慢原因",[11,46,47],{},"第一，数据库慢查询。列表页每次请求都跑一次复杂的统计查询，TTFB 上不去。",[11,49,50],{},"第二，第三方脚本在服务端阻塞。有些站把统计、客服、AB 测试的脚本放在服务端渲染链路里，一个第三方接口慢，整页就慢。",[11,52,53],{},"第三，CDN 回源配置。CDN 缓存命中率低，每个请求都回源，TTFB 高得离谱。我们一个客户缓存命中率只有 31%，调完到 94%，TTFB 直接降了一半。",[15,55,56],{"id":56},"怎么改",[11,58,59],{},"先测：分页面类型看 TTFB，首页、列表页、详情页分别测，别只看平均值。",[11,61,62],{},"再改：数据库加索引、复杂查询做缓存、第三方脚本挪到客户端异步加载、CDN 缓存规则按内容类型配。",[11,64,65],{},"最后验证：改完等两周看抓取数据，别当天就下结论。抓取频次的变化有延迟，Google 一般 1 到 2 周，百度更慢。",[15,67,68],{"id":68},"一个提醒",[11,70,71],{},"TTFB 不是排名因素，它影响的是抓取效率。别把它和 CWV 混为一谈，CWV 是用户体验指标，TTFB 是服务器指标，两者相关但不等价。",[11,73,74],{},"先看抓取是不是瓶颈，再决定要不要投入服务器优化。抓取正常的站，优化 TTFB 的收益有限。",[15,76,77],{"id":77},"判断",[11,79,80],{},"服务器响应是技术 SEO 里最\"底层\"的一环，它不直接决定排名，但决定了搜索引擎愿不愿意多来。",[11,82,83],{},"如果你的站 TTFB 超过 1.5 秒，先修这个，再谈内容。",{"title":85,"searchDepth":86,"depth":86,"links":87},"",2,[88,89,90,91,92,93,94],{"id":17,"depth":86,"text":17},{"id":26,"depth":86,"text":26},{"id":35,"depth":86,"text":35},{"id":44,"depth":86,"text":44},{"id":56,"depth":86,"text":56},{"id":68,"depth":86,"text":68},{"id":77,"depth":86,"text":77},null,"技术SEO","2026-08-09","服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。测试方法和三个隐蔽的拖慢原因都在这篇，看完能判断自己的站要不要优化。",false,"md",{},true,"\u002Fblog\u002Fserver-response-crawl",{"title":5,"description":98},"blog\u002Fserver-response-crawl",[107,108,109],"TTFB","抓取","服务器","dAeuSHqJsirOpumTL5Zvo9Ea9u9M4wJA2Cs_ooZJBHE",{"id":112,"title":113,"author":6,"body":114,"canonical":95,"category":194,"cover":95,"date":195,"description":196,"draft":99,"extension":100,"keywords":95,"meta":197,"navigation":102,"noindex":99,"ogImage":95,"path":198,"seo":199,"seoDescription":95,"seoTitle":95,"stem":200,"tags":201,"updated":95,"__hash__":205},"blog\u002Fblog\u002Fdev-queue-blocking-seo.md","跨部门卡住的 SEO 项目，问题多在开发排期",{"type":8,"value":115,"toc":186},[116,119,122,125,128,131,135,138,141,144,147,150,153,156,159,162,165,168,171,174,177,180,183],[11,117,118],{},"2026 年 7 月我们有个客户的 title 模板改动等了整整三周才上线。不是开发不配合，是这个需求在排期表上永远排在产品需求后面。SEO 项目卡住的地方，九成不在技术，在协调。",[15,120,121],{"id":121},"最常见的三种卡点",[11,123,124],{},"第一种，需求排不进去。开发团队的排期按季度定，产品需求占满，SEO 的改动只能插空。技术 SEO 的活往往看着小，实际要回归测试，一插就影响别的。",[11,126,127],{},"第二种，没有明确负责人。改 canonical 归谁管？内容团队、开发、还是我们？三方都以为别人做，结果两周没人动。",[11,129,130],{},"第三种，改完没验证。改动上线了，但没人检查线上效果，改错了要等下一次诊断才发现。",[15,132,134],{"id":133},"为什么-seo-需求总排不上","为什么 SEO 需求总排不上",[11,136,137],{},"因为它不紧急。产品需求影响收入，故障影响可用性，SEO 影响的是三个月后的流量，排序自然靠后。",[11,139,140],{},"还因为它的收益不好量化。跟开发说“这个改动能让抓取更顺”，对方没法判断值不值得排。换成“影响 1200 个产品页的收录”，就有分量了。",[11,142,143],{},"第三，很多 SEO 需求没有工单，只在群里说一句。口头需求最容易被遗忘。",[15,145,146],{"id":146},"我们怎么推进",[11,148,149],{},"把每个改动写成工单，五项内容：影响多少页面、预期收益、验收标准、预估工时、依赖谁。",[11,151,152],{},"工时必须我们自己估。写“需要开发 2 小时”比写“优化页面结构”有效得多，开发看着能排。",[11,154,155],{},"提前一个季度把大改动提进排期。等季度中再提，基本只能等下一季度。",[11,157,158],{},"找业务负责人，不直接找开发。开发的优先级来自业务，绕过负责人去催开发，短期可能有用，长期会被讨厌。",[15,160,161],{"id":161},"一次事故",[11,163,164],{},"2025 年我们图快，让一个开发朋友直接改了 robots.txt，想屏蔽测试目录。他写成了 Disallow: \u002F，全站被屏蔽了六个小时。",[11,166,167],{},"发现的时候是搜索流量掉了九成，但当天数据还没出来，是日志里蜘蛛不来了才察觉。",[11,169,170],{},"从那以后我们的规矩是：robots 和 canonical 这类全局配置，必须双人确认，改之前截图存档，改完立刻用抓取工具验证。",[15,172,173],{"id":173},"怎么和开发建立信任",[11,175,176],{},"信任靠小事积累。我们给自己定了几条：需求写清验收标准，改完自己先验证一遍，不把没把握的东西推给开发。",[11,178,179],{},"还有一条，出问题先自己查，不第一时间甩锅。robots 那次事故，我们先写了一份复盘，说明是我们的责任，开发才愿意继续配合。",[15,181,182],{"id":182},"一句话总结",[11,184,185],{},"SEO 项目最大的风险不是技术难度，是协调成本。把需求变成工单、把收益说成数字、把风险点控制住，项目就顺了。",{"title":85,"searchDepth":86,"depth":86,"links":187},[188,189,190,191,192,193],{"id":121,"depth":86,"text":121},{"id":133,"depth":86,"text":134},{"id":146,"depth":86,"text":146},{"id":161,"depth":86,"text":161},{"id":173,"depth":86,"text":173},{"id":182,"depth":86,"text":182},"行业观察","2026-08-08","一个 title 模板改动等了三周，一次 robots 误改让全站被屏蔽六小时。这篇写 SEO 需求怎么进开发排期、工单怎么写、找谁推进才有效。",{},"\u002Fblog\u002Fdev-queue-blocking-seo",{"title":113,"description":196},"blog\u002Fdev-queue-blocking-seo",[202,203,204],"项目推进","开发协作","排期","Gj0stXUpmja4kntcFekdADlrc44PYKc4McKNN7lViHs",{"id":207,"title":208,"author":6,"body":209,"canonical":95,"category":96,"cover":95,"date":290,"description":291,"draft":99,"extension":100,"keywords":95,"meta":292,"navigation":102,"noindex":99,"ogImage":95,"path":293,"seo":294,"seoDescription":95,"seoTitle":95,"stem":295,"tags":296,"updated":95,"__hash__":300},"blog\u002Fblog\u002Fsitemap-lastmod-correct-usage.md","站点地图的更新日期乱写，等于告诉蜘蛛别来",{"type":8,"value":210,"toc":280},[211,214,218,221,224,227,235,238,242,245,249,252,255,258,262,265,268,271,274,277],[11,212,213],{},"lastmod 是\"这页什么时候真的变过\"的声明。全站都填当前时间，等于宣布每个页面每秒都在更新，搜索引擎会直接忽略这个字段，你就白白丢了一个让蜘蛛优先回来的信号。",[15,215,217],{"id":216},"_2026-年-5-月的对比测试","2026 年 5 月的对比测试",[11,219,220],{},"同一个站拆两组页面：A 组 lastmod 按内容真实修改时间写，B 组每次生成都填当天日期。观察 6 周。",[11,222,223],{},"A 组页面的重新抓取次数是 B 组的 2.3 倍；A 组新内容的平均收录时间 4 天，B 组 11 天。两组内容质量、内链条件都一样，唯一的变量就是 lastmod。",[15,225,226],{"id":226},"正确写法",[11,228,229,230,234],{},"只对真正改动的 URL 更新 lastmod，格式用完整的 ISO 8601 带时区，比如 ",[231,232,233],"code",{},"2026-05-12T10:30:00+08:00","。批量生成时按内容表里的实际修改时间戳映射，别用生成任务的执行时间。",[11,236,237],{},"注意时区。有的 CMS 用 UTC 存时间，输出时没带时区，搜索引擎会按自己的时区解释，可能把时间判到未来。",[15,239,241],{"id":240},"priority-和-changefreq-别调了","priority 和 changefreq 别调了",[11,243,244],{},"这两个字段现在基本被忽略。见过一些站花时间给每个页面调 priority，从 1.0 调到 0.8，指望影响抓取优先级。没意义，把时间花在内链上。",[15,246,248],{"id":247},"增量-sitemap-的用法","增量 sitemap 的用法",[11,250,251],{},"内容量大的站可以拆两份：固定 sitemap 放全量 URL，增量 sitemap 只放最近 7 天变动的 URL。搜索引擎对后者的读取频率通常更高，新内容被发现得更快。两份都在 sitemapindex 里声明。",[15,253,254],{"id":254},"别和发布日期混用",[11,256,257],{},"lastmod 是内容最后修改时间，不是发布时间。改个错别字也算修改，但要判断值不值得更新——只改了导航栏、换了张图，就别动 lastmod，不然又变成\"全站都在变\"。我们的标准是正文可见内容有实质变化才更新。",[15,259,261],{"id":260},"给-cms-加一行判断","给 CMS 加一行判断",[11,263,264],{},"生成器里加个判断：内容没变就不动 lastmod。这一行改动，比在 SEO 上做很多别的优化都直接。我们给客户交付时会把这条写进技术验收清单。",[15,266,267],{"id":267},"和抓取预算的关系",[11,269,270],{},"抓取预算是有限的配额。lastmod 可信的站，蜘蛛能用\"哪些页变了\"来决定先抓谁，效率高；lastmod 全是当天的站，蜘蛛只能按内链和权重盲抓，效率低。这个差异在小站上看不出来，几万页的站上非常明显。",[11,272,273],{},"我们做过一次实验：同一个站只修 lastmod 逻辑，不做其他改动，30 天后新页面的平均发现时间从 9 天降到 3 天。这是整个技术 SEO 里投入产出比最高的改动之一，可惜很少人做。",[15,275,276],{"id":276},"立场",[11,278,279],{},"sitemap 里真正有用的字段只有两个：loc 和 lastmod。把这两个做对，其他都是装饰。",{"title":85,"searchDepth":86,"depth":86,"links":281},[282,283,284,285,286,287,288,289],{"id":216,"depth":86,"text":217},{"id":226,"depth":86,"text":226},{"id":240,"depth":86,"text":241},{"id":247,"depth":86,"text":248},{"id":254,"depth":86,"text":254},{"id":260,"depth":86,"text":261},{"id":267,"depth":86,"text":267},{"id":276,"depth":86,"text":276},"2026-08-10","每次生成 sitemap 都把 lastmod 写成当前时间，是 CMS 的常见默认行为。搜索引擎发现这个字段不可信就会忽略它。这篇讲正确用法、增量拆分，以及一个 2026 年 5 月的对比测试。",{},"\u002Fblog\u002Fsitemap-lastmod-correct-usage",{"title":208,"description":291},"blog\u002Fsitemap-lastmod-correct-usage",[297,298,299],"sitemap","lastmod","收录","q2_vcS1lz1YcDwwvxtLPUvhgKzERg-sqvttTp33LPRA",1794088103010]