[{"data":1,"prerenderedAt":321},["ShallowReactive",2],{"blog-sitemap-lastmod-correct-usage":3,"blog-prev-sitemap-lastmod-correct-usage":109,"blog-next-sitemap-lastmod-correct-usage":206},{"id":4,"title":5,"author":6,"body":7,"canonical":93,"category":94,"cover":93,"date":95,"description":96,"draft":97,"extension":98,"keywords":93,"meta":99,"navigation":100,"noindex":97,"ogImage":93,"path":101,"seo":102,"seoDescription":93,"seoTitle":93,"stem":103,"tags":104,"updated":93,"__hash__":108},"blog\u002Fblog\u002Fsitemap-lastmod-correct-usage.md","站点地图的更新日期乱写，等于告诉蜘蛛别来","元析智能",{"type":8,"value":9,"toc":81},"minimark",[10,14,19,22,25,28,36,39,43,46,50,53,56,59,63,66,69,72,75,78],[11,12,13],"p",{},"lastmod 是\"这页什么时候真的变过\"的声明。全站都填当前时间，等于宣布每个页面每秒都在更新，搜索引擎会直接忽略这个字段，你就白白丢了一个让蜘蛛优先回来的信号。",[15,16,18],"h2",{"id":17},"_2026-年-5-月的对比测试","2026 年 5 月的对比测试",[11,20,21],{},"同一个站拆两组页面：A 组 lastmod 按内容真实修改时间写，B 组每次生成都填当天日期。观察 6 周。",[11,23,24],{},"A 组页面的重新抓取次数是 B 组的 2.3 倍；A 组新内容的平均收录时间 4 天，B 组 11 天。两组内容质量、内链条件都一样，唯一的变量就是 lastmod。",[15,26,27],{"id":27},"正确写法",[11,29,30,31,35],{},"只对真正改动的 URL 更新 lastmod，格式用完整的 ISO 8601 带时区，比如 ",[32,33,34],"code",{},"2026-05-12T10:30:00+08:00","。批量生成时按内容表里的实际修改时间戳映射，别用生成任务的执行时间。",[11,37,38],{},"注意时区。有的 CMS 用 UTC 存时间，输出时没带时区，搜索引擎会按自己的时区解释，可能把时间判到未来。",[15,40,42],{"id":41},"priority-和-changefreq-别调了","priority 和 changefreq 别调了",[11,44,45],{},"这两个字段现在基本被忽略。见过一些站花时间给每个页面调 priority，从 1.0 调到 0.8，指望影响抓取优先级。没意义，把时间花在内链上。",[15,47,49],{"id":48},"增量-sitemap-的用法","增量 sitemap 的用法",[11,51,52],{},"内容量大的站可以拆两份：固定 sitemap 放全量 URL，增量 sitemap 只放最近 7 天变动的 URL。搜索引擎对后者的读取频率通常更高，新内容被发现得更快。两份都在 sitemapindex 里声明。",[15,54,55],{"id":55},"别和发布日期混用",[11,57,58],{},"lastmod 是内容最后修改时间，不是发布时间。改个错别字也算修改，但要判断值不值得更新——只改了导航栏、换了张图，就别动 lastmod，不然又变成\"全站都在变\"。我们的标准是正文可见内容有实质变化才更新。",[15,60,62],{"id":61},"给-cms-加一行判断","给 CMS 加一行判断",[11,64,65],{},"生成器里加个判断：内容没变就不动 lastmod。这一行改动，比在 SEO 上做很多别的优化都直接。我们给客户交付时会把这条写进技术验收清单。",[15,67,68],{"id":68},"和抓取预算的关系",[11,70,71],{},"抓取预算是有限的配额。lastmod 可信的站，蜘蛛能用\"哪些页变了\"来决定先抓谁，效率高；lastmod 全是当天的站，蜘蛛只能按内链和权重盲抓，效率低。这个差异在小站上看不出来，几万页的站上非常明显。",[11,73,74],{},"我们做过一次实验：同一个站只修 lastmod 逻辑，不做其他改动，30 天后新页面的平均发现时间从 9 天降到 3 天。这是整个技术 SEO 里投入产出比最高的改动之一，可惜很少人做。",[15,76,77],{"id":77},"立场",[11,79,80],{},"sitemap 里真正有用的字段只有两个：loc 和 lastmod。把这两个做对，其他都是装饰。",{"title":82,"searchDepth":83,"depth":83,"links":84},"",2,[85,86,87,88,89,90,91,92],{"id":17,"depth":83,"text":18},{"id":27,"depth":83,"text":27},{"id":41,"depth":83,"text":42},{"id":48,"depth":83,"text":49},{"id":55,"depth":83,"text":55},{"id":61,"depth":83,"text":62},{"id":68,"depth":83,"text":68},{"id":77,"depth":83,"text":77},null,"技术SEO","2026-08-10","每次生成 sitemap 都把 lastmod 写成当前时间，是 CMS 的常见默认行为。搜索引擎发现这个字段不可信就会忽略它。这篇讲正确用法、增量拆分，以及一个 2026 年 5 月的对比测试。",false,"md",{},true,"\u002Fblog\u002Fsitemap-lastmod-correct-usage",{"title":5,"description":96},"blog\u002Fsitemap-lastmod-correct-usage",[105,106,107],"sitemap","lastmod","收录","q2_vcS1lz1YcDwwvxtLPUvhgKzERg-sqvttTp33LPRA",{"id":110,"title":111,"author":6,"body":112,"canonical":93,"category":94,"cover":93,"date":195,"description":196,"draft":97,"extension":98,"keywords":93,"meta":197,"navigation":100,"noindex":97,"ogImage":93,"path":198,"seo":199,"seoDescription":93,"seoTitle":93,"stem":200,"tags":201,"updated":93,"__hash__":205},"blog\u002Fblog\u002Fserver-response-crawl.md","服务器慢 1 秒，抓取频次掉多少：我们测了 4 个站",{"type":8,"value":113,"toc":186},[114,117,120,123,126,129,132,135,138,141,144,147,150,153,156,159,162,165,168,171,174,177,180,183],[11,115,116],{},"服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。",[15,118,119],{"id":119},"我们怎么测",[11,121,122],{},"2025 年 10 月到 2026 年 3 月，我们测了 4 个站，都是软件公司官网或文档站，页面 2000 到 1.5 万。测试周期每个站 6 周：前 2 周记录基线，中间 2 周改服务器，后 2 周观察。",[11,124,125],{},"记录三个数：TTFB、每日抓取请求数、核心页平均抓取间隔。数据来源是服务器日志加两边站长后台。",[15,127,128],{"id":128},"数据",[11,130,131],{},"站 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,133,134],{},"结论：TTFB 超过 1.5 秒的站，改善空间大；本来就快的站，优化收益小。",[15,136,137],{"id":137},"为什么响应时间影响抓取",[11,139,140],{},"搜索引擎的抓取资源有限，它会优先抓\"划算\"的站。同样一秒钟，能抓 1 个页面还是 3 个页面，直接决定它给你多少抓取配额。",[11,142,143],{},"这不是惩罚，是资源分配。响应慢的站，抓取频次会被自动压低。",[15,145,146],{"id":146},"三个隐蔽的拖慢原因",[11,148,149],{},"第一，数据库慢查询。列表页每次请求都跑一次复杂的统计查询，TTFB 上不去。",[11,151,152],{},"第二，第三方脚本在服务端阻塞。有些站把统计、客服、AB 测试的脚本放在服务端渲染链路里，一个第三方接口慢，整页就慢。",[11,154,155],{},"第三，CDN 回源配置。CDN 缓存命中率低，每个请求都回源，TTFB 高得离谱。我们一个客户缓存命中率只有 31%，调完到 94%，TTFB 直接降了一半。",[15,157,158],{"id":158},"怎么改",[11,160,161],{},"先测：分页面类型看 TTFB，首页、列表页、详情页分别测，别只看平均值。",[11,163,164],{},"再改：数据库加索引、复杂查询做缓存、第三方脚本挪到客户端异步加载、CDN 缓存规则按内容类型配。",[11,166,167],{},"最后验证：改完等两周看抓取数据，别当天就下结论。抓取频次的变化有延迟，Google 一般 1 到 2 周，百度更慢。",[15,169,170],{"id":170},"一个提醒",[11,172,173],{},"TTFB 不是排名因素，它影响的是抓取效率。别把它和 CWV 混为一谈，CWV 是用户体验指标，TTFB 是服务器指标，两者相关但不等价。",[11,175,176],{},"先看抓取是不是瓶颈，再决定要不要投入服务器优化。抓取正常的站，优化 TTFB 的收益有限。",[15,178,179],{"id":179},"判断",[11,181,182],{},"服务器响应是技术 SEO 里最\"底层\"的一环，它不直接决定排名，但决定了搜索引擎愿不愿意多来。",[11,184,185],{},"如果你的站 TTFB 超过 1.5 秒，先修这个，再谈内容。",{"title":82,"searchDepth":83,"depth":83,"links":187},[188,189,190,191,192,193,194],{"id":119,"depth":83,"text":119},{"id":128,"depth":83,"text":128},{"id":137,"depth":83,"text":137},{"id":146,"depth":83,"text":146},{"id":158,"depth":83,"text":158},{"id":170,"depth":83,"text":170},{"id":179,"depth":83,"text":179},"2026-08-09","服务器响应时间和抓取频次的关系，比大多数人想的直接。我们给 4 个站做了前后对比：TTFB 从 1.8 秒降到 0.4 秒后，Googlebot 抓取量平均涨 42%，百度蜘蛛涨 31%。测试方法和三个隐蔽的拖慢原因都在这篇，看完能判断自己的站要不要优化。",{},"\u002Fblog\u002Fserver-response-crawl",{"title":111,"description":196},"blog\u002Fserver-response-crawl",[202,203,204],"TTFB","抓取","服务器","dAeuSHqJsirOpumTL5Zvo9Ea9u9M4wJA2Cs_ooZJBHE",{"id":207,"title":208,"author":6,"body":209,"canonical":93,"category":94,"cover":93,"date":310,"description":311,"draft":97,"extension":98,"keywords":93,"meta":312,"navigation":100,"noindex":97,"ogImage":93,"path":313,"seo":314,"seoDescription":93,"seoTitle":93,"stem":315,"tags":316,"updated":93,"__hash__":320},"blog\u002Fblog\u002Fhomepage-video-weight.md","首页背景视频值不值得那两秒，我们算过账",{"type":8,"value":210,"toc":301},[211,214,217,220,223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298],[11,212,213],{},"2026 年 8 月一个客户的首页自动播放背景视频，12 兆，移动端 4G 下首屏 6 秒。市场部坚持要留，说品牌感靠它。我们最后改成点击播放，首屏回到 2.1 秒，视频还在，只是不再自动加载。",[15,215,216],{"id":216},"视频的成本不只是字节",[11,218,219],{},"字节是最直观的：12 兆的视频，4G 网络按 3 兆每秒算，光下载就四秒。",[11,221,222],{},"解码是第二层：手机解码视频吃 CPU，同时还要渲染页面，主线程被占，交互会卡。",[11,224,225],{},"内存是第三层：移动浏览器对自动播放的视频有内存限制，低端机经常直接不播，用户看到一块黑。",[15,227,228],{"id":228},"什么情况值得放",[11,230,231],{},"产品演示视频，用户点了会看，值得放，但别自动播。",[11,233,234],{},"品牌片，放在关于页或者首屏下面，用户想看会自己点。",[11,236,237],{},"氛围视频，比如抽象的光影流动，这类基本是自我感动，收益最低，成本最高。",[11,239,240],{},"我们的判断标准很简单：这段视频能不能回答用户一个问题。不能，就别放在首屏。",[15,242,243],{"id":243},"替代方案",[11,245,246],{},"用视频的第一帧做静态图，视觉上差不多，体积小几十倍。",[11,248,249],{},"如果一定要动，做三到五秒的无声循环，体积控制在 500KB 以内，并且用 poster 保证首帧立刻显示。",[11,251,252],{},"动效也可以用 CSS 做，几百字节的事，别为了一个渐变动画加载一个视频。",[15,254,255],{"id":255},"如果一定要放",[11,257,258],{},"用 preload=none，别预加载。",[11,260,261],{},"只放 poster，等用户交互或者滚到位置再加载视频。",[11,263,264],{},"移动端直接隐藏视频，给一张静态图。这条最有效，因为大部分流量和大部分性能问题都在移动端。",[15,266,267],{"id":267},"一个对比数据",[11,269,270],{},"改之前，移动端 LCP 5.2 秒，首屏视频占 12 兆。改成点击播放之后，LCP 2.1 秒，视频文件还在服务器上，想看的人照样能看。",[11,272,273],{},"转化数据没有变差。市场部最担心的品牌感，也没人反馈丢了。",[11,275,276],{},"这件事的难点不在技术，在沟通。把视频的字节数、加载时间、移动端占比摆出来，比讲技术道理有效。",[15,278,279],{"id":279},"移动端单独处理",[11,281,282],{},"同一个首页，桌面放视频、移动端放静态图，这个做法我们用了很多次。",[11,284,285],{},"用户不会因为手机上没有视频就觉得品牌差，但会在意打开要等六秒。",[11,287,288],{},"实现上用媒体查询或者服务端判断，别用 JS 判断，因为 JS 判断本身就要等脚本加载完。",[15,290,291],{"id":291},"一个规矩",[11,293,294],{},"我们给新站定了一条规矩：首屏不放自动播放的视频和音频，不放超过 500KB 的动画资源。",[11,296,297],{},"要放，走评审，说明为什么这段视频必须在首屏、为什么不能用静态图替代。",[11,299,300],{},"规矩定在前头，比上线后再砍容易得多。",{"title":82,"searchDepth":83,"depth":83,"links":302},[303,304,305,306,307,308,309],{"id":216,"depth":83,"text":216},{"id":228,"depth":83,"text":228},{"id":243,"depth":83,"text":243},{"id":255,"depth":83,"text":255},{"id":267,"depth":83,"text":267},{"id":279,"depth":83,"text":279},{"id":291,"depth":83,"text":291},"2026-08-11","一个 12 兆的背景视频让移动端首屏到了 6 秒。这篇算清视频的字节、解码和内存成本，写什么情况值得放、怎么延迟加载、以及改成点击播放后的效果。",{},"\u002Fblog\u002Fhomepage-video-weight",{"title":208,"description":311},"blog\u002Fhomepage-video-weight",[317,318,319],"视频优化","首屏","页面体验","ABcPPox_njcv_afb8oFr8f-AdAWlbsWDz6KVzV2M7Vg",1794088102967]