[{"data":1,"prerenderedAt":351},["ShallowReactive",2],{"blog-http-header-seo":3,"blog-prev-http-header-seo":142,"blog-next-http-header-seo":235},{"id":4,"title":5,"author":6,"body":7,"canonical":126,"category":127,"cover":126,"date":128,"description":129,"draft":130,"extension":131,"keywords":126,"meta":132,"navigation":133,"noindex":130,"ogImage":126,"path":134,"seo":135,"seoDescription":126,"seoTitle":126,"stem":136,"tags":137,"updated":126,"__hash__":141},"blog\u002Fblog\u002Fhttp-header-seo.md","HTTP 头也能做 SEO：X-Robots-Tag 与 Link 头的三个用法和坑","元析智能",{"type":8,"value":9,"toc":115},"minimark",[10,14,18,21,24,27,31,39,42,45,49,56,59,62,66,72,75,78,85,88,91,94,97,100,103,106,109,112],[11,12,13],"p",{},"页面里的 meta 标签不是唯一入口，HTTP 头也能控制索引、传 canonical、声明多语言。X-Robots-Tag 和 Link 头用得对，能解决一批页面里改不了的问题。",[15,16,17],"h2",{"id":17},"头信息能干什么",[11,19,20],{},"2025 年 12 月我们在一个客户站上用过一次：整站 3000 多个 PDF 文件没法改页面标签，只能靠头信息统一控制，这是头信息最典型的场景。",[11,22,23],{},"三个常见用途：控制页面索引和抓取、声明 canonical、声明 hreflang。",[11,25,26],{},"好处是不用改页面 HTML，服务器层就能统一配置。坏处是不直观，出了问题不好查。",[15,28,30],{"id":29},"x-robots-tag-的三个用法","X-Robots-Tag 的三个用法",[11,32,33,34,38],{},"第一，给非 HTML 文件加 noindex。PDF、图片、JS 文件没法写 meta 标签，只能靠头。我们给一个客户的 PDF 白皮书加了 ",[35,36,37],"code",{},"X-Robots-Tag: noindex","，索引里的 PDF 数量从 3000 降到 200。",[11,40,41],{},"第二，给整类路径统一加规则。比如测试环境、预览环境、下载目录，用服务器配置统一加 noindex，比逐个页面改可靠。",[11,43,44],{},"第三，给特定爬虫设规则。可以指定 UA，比如对某个爬虫单独加 nofollow。",[15,46,48],{"id":47},"link-头canonical-和-hreflang","Link 头：canonical 和 hreflang",[11,50,51,52,55],{},"HTTP 头里可以写 ",[35,53,54],{},"Link: \u003Chttps:\u002F\u002Fexample.com\u002Fpage>; rel=\"canonical\"","，效果和页面里的 canonical 标签一样。",[11,57,58],{},"hreflang 也可以放在头里，适合那些页面 HTML 不好改的站。",[11,60,61],{},"但注意：头里的 Link 和页面里的标签同时存在时，要保证指向一致，冲突了搜索引擎可能两个都不认。",[15,63,65],{"id":64},"一个坑多个头指令冲突","一个坑：多个头指令冲突",[11,67,68,69,71],{},"我们见过一个客户，服务器统一加了 ",[35,70,37],{},"，页面里又写了 canonical 指向主页面。两个指令一个说\"别收录\"，一个说\"收这个\"，搜索引擎会按 noindex 处理，canonical 白写。",[11,73,74],{},"还有一种：CDN 缓存了旧的 X-Robots-Tag，页面改了但头没变，索引状态一直不更新。",[15,76,77],{"id":77},"怎么查",[11,79,80,81,84],{},"用 curl 看响应头是最直接的：",[35,82,83],{},"curl -I https:\u002F\u002Fexample.com\u002Fpage","。",[11,86,87],{},"重点看三个：有没有 X-Robots-Tag、有没有 Link 头、有没有和页面标签冲突。",[11,89,90],{},"批量查的话，用爬虫工具导出响应头列，或者写脚本跑一遍核心页面。",[15,92,93],{"id":93},"一个建议",[11,95,96],{},"头信息适合做\"批量、统一\"的规则，不适合做单页的精细控制。单页控制还是用 meta 标签，直观、好排查。",[11,98,99],{},"用头信息之前，先想清楚会不会和页面标签冲突。冲突是这类问题最常见的来源。",[15,101,102],{"id":102},"判断",[11,104,105],{},"这套东西我们一般只在页面标签改不了的场景用，不主动扩大使用范围。头信息最大的问题是不可见：你在页面源代码里看不到它，出问题要查服务器和 CDN。",[11,107,108],{},"还有一个小提醒：头信息改完要清 CDN 缓存。我们踩过这个坑，服务器配置改了，CDN 还返回旧头，查了一天才发现。",[11,110,111],{},"HTTP 头是技术 SEO 的进阶工具，用得好能解决一批麻烦，用不好会制造更难查的问题。",[11,113,114],{},"如果你不确定，先用 curl 看一遍现状，再决定动不动。",{"title":116,"searchDepth":117,"depth":117,"links":118},"",2,[119,120,121,122,123,124,125],{"id":17,"depth":117,"text":17},{"id":29,"depth":117,"text":30},{"id":47,"depth":117,"text":48},{"id":64,"depth":117,"text":65},{"id":77,"depth":117,"text":77},{"id":93,"depth":117,"text":93},{"id":102,"depth":117,"text":102},null,"技术SEO","2026-10-16","页面里的 meta 标签不是唯一入口，HTTP 头也能控制索引、传 canonical、声明多语言。X-Robots-Tag 和 Link 头用得对，能解决一批页面里改不了的问题；用错会互相冲突。用法、冲突场景和查法都在这篇，最后附了一个判断标准和两个踩过的坑。",false,"md",{},true,"\u002Fblog\u002Fhttp-header-seo",{"title":5,"description":129},"blog\u002Fhttp-header-seo",[138,139,140],"HTTP头","X-Robots-Tag","canonical","3oD2Y3p6i3poEeQZjX07PY1EHzr0QA3QJrrsoqaKmEw",{"id":143,"title":144,"author":6,"body":145,"canonical":126,"category":223,"cover":126,"date":224,"description":225,"draft":130,"extension":131,"keywords":126,"meta":226,"navigation":133,"noindex":130,"ogImage":126,"path":227,"seo":228,"seoDescription":126,"seoTitle":126,"stem":229,"tags":230,"updated":126,"__hash__":234},"blog\u002Fblog\u002Falgorithm-update-client-letter.md","算法更新那周，我们给客户发一封什么信",{"type":8,"value":146,"toc":216},[147,150,153,156,159,162,165,168,171,174,177,180,183,186,189,192,195,198,201,204,207,210,213],[11,148,149],{},"2026 年 10 月初有好几个站的数据同时出现波动，我们的项目群里当天就有人问是不是算法更新了。这种时候客户最需要的不是解释，是知道你在看、你在做什么。我们固定会发一封信，但不在第一天发。",[15,151,152],{"id":152},"先判断是不是算法更新",[11,154,155],{},"三个信号：多个不相关的站同时波动；波动集中在内容型页面而不是技术型页面；GSC 里没有安全或手动操作消息。",[11,157,158],{},"反过来，如果只有一个站波动，先查技术。部署记录、日志、robots、canonical，这四样排一遍，能排除掉大部分“假算法更新”。",[11,160,161],{},"时间点也要对。算法更新通常有官方的确认或者行业里大量讨论，如果你只是自己一个站掉，大概率不是。",[15,163,164],{"id":164},"什么时候发信",[11,166,167],{},"第一天不发。第一天的数据往往还没稳定，发出去容易自己打脸。",[11,169,170],{},"第三到第五天发。这时候趋势大致清楚，能说清掉了多少、哪些页面受影响。",[11,172,173],{},"发之前先自己看一遍数据，至少要能回答两个问题：掉了多少、集中在哪些页面。答不上来就先别发。",[15,175,176],{"id":176},"信里写五段",[11,178,179],{},"第一段，事实。过去五天自然搜索点击从多少掉到多少，涉及哪些页面类型。",[11,181,182],{},"第二段，我们查了什么。排除技术原因，确认没有手动操作，对比了同行业的其他站。",[11,184,185],{},"第三段，我们在做什么。正在观察、正在整理受影响页面的清单、正在复盘内容质量。",[11,187,188],{},"第四段，建议客户不要做什么。不要急着改标题、不要批量删页面、不要加外链。这三件事在波动期做，只会让判断更难。",[11,190,191],{},"第五段，下次同步时间。给一个具体日期，比如下周三，别写“有进展会及时同步”。",[15,193,194],{"id":194},"三句不能说的话",[11,196,197],{},"第一句，确定是某某算法更新。除非官方确认，否则不要下断言，说错了后面很难圆。",[11,199,200],{},"第二句，两周内会恢复。恢复时间没人能保证，承诺了就是给自己挖坑。",[11,202,203],{},"第三句，这是行业普遍现象，跟我们无关。哪怕是真的，这句话听起来就是在推责任。",[15,205,206],{"id":206},"之后的四周做什么",[11,208,209],{},"第一周观察，记录每天的数据。第二周整理受影响页面清单，按流量损失排序。第三周做内容质量复盘，看这些页面有没有共同问题。第四周出调整计划。",[11,211,212],{},"大部分算法波动会在四到六周内稳定。稳定之后再看要不要动内容，比在波动期乱改有效。",[11,214,215],{},"信的作用不是安抚，是让客户知道过程可控。这一点比结论重要。",{"title":116,"searchDepth":117,"depth":117,"links":217},[218,219,220,221,222],{"id":152,"depth":117,"text":152},{"id":164,"depth":117,"text":164},{"id":176,"depth":117,"text":176},{"id":194,"depth":117,"text":194},{"id":206,"depth":117,"text":206},"SEO","2026-10-15","波动第一天别发信，第三到第五天再发。这篇写怎么判断是不是算法更新、信里写哪五段、哪三句话绝对不能出现，以及之后的四周做什么。",{},"\u002Fblog\u002Falgorithm-update-client-letter",{"title":144,"description":225},"blog\u002Falgorithm-update-client-letter",[231,232,233],"算法更新","客户沟通","预期管理","2GNeB9f4boWSy_F_HgGOOWgTqCCOVRv0YscBjbJcAfg",{"id":236,"title":237,"author":6,"body":238,"canonical":126,"category":127,"cover":126,"date":340,"description":341,"draft":130,"extension":131,"keywords":126,"meta":342,"navigation":133,"noindex":130,"ogImage":126,"path":343,"seo":344,"seoDescription":126,"seoTitle":126,"stem":345,"tags":346,"updated":126,"__hash__":350},"blog\u002Fblog\u002Fhttp2-migration-pitfalls.md","老站迁到 HTTP\u002F2，先把这四个坑填了",{"type":8,"value":239,"toc":331},[240,243,246,249,252,256,259,262,265,269,272,275,278,282,285,288,291,295,298,301,304,307,310,313,316,319,322,325,328],[11,241,242],{},"2026 年 10 月我们给一个跑了八年的官网做协议升级，配置本身半小时搞定，后面的调整花了两周。协议换了，之前十几年的优化习惯要跟着改。",[15,244,245],{"id":245},"迁移本身很简单",[11,247,248],{},"服务器支持、证书配好、开 ALPN，基本就完事。云服务和 CDN 现在默认都支持 HTTP\u002F2，很多站其实早就开着了，只是没注意。",[11,250,251],{},"怎么确认？看 DevTools 的协议列，显示 h2 就是 HTTP\u002F2。命令行也能看，curl 带 --http2 参数。",[15,253,255],{"id":254},"坑一域名分片失效","坑一：域名分片失效",[11,257,258],{},"HTTP\u002F1.1 时代为了绕过并发限制，把图片、JS、CSS 拆到多个子域名。",[11,260,261],{},"HTTP\u002F2 支持多路复用，一个连接就能并发，分片反而变成负担：每个域名要单独 DNS、单独 TLS，多花几百毫秒。",[11,263,264],{},"我们这次把六个静态域名合成了两个，首屏的连接建立时间少了 400 毫秒。",[15,266,268],{"id":267},"坑二资源合并要重新考虑","坑二：资源合并要重新考虑",[11,270,271],{},"以前把十几个 CSS 合成一个大文件，减少请求数。",[11,273,274],{},"HTTP\u002F2 下请求不贵了，合并反而伤害缓存。改一个组件，整个大文件的缓存全部失效。",[11,276,277],{},"我们的做法是按页面拆分，首屏一份、其余按路由分。改一个页面不影响其他页面的缓存。",[15,279,281],{"id":280},"坑三服务端推送已经被放弃","坑三：服务端推送已经被放弃",[11,283,284],{},"HTTP\u002F2 的服务端推送（Server Push）当年被当成优势，现在主流浏览器已经移除支持。",[11,286,287],{},"还在用 push 的配置要清掉。它不但没收益，还可能造成重复下载，反而更慢。",[11,289,290],{},"替代方案是 preload，浏览器支持稳定，行为可预期。",[15,292,294],{"id":293},"坑四cdn-和中间层不支持","坑四：CDN 和中间层不支持",[11,296,297],{},"源站升级了，CDN 还是 HTTP\u002F1.1，用户端就享受不到。",[11,299,300],{},"还有反向代理、WAF、负载均衡，任何一层不支持，整条链路就退回旧协议。",[11,302,303],{},"迁移前逐层确认，从源站查到边缘节点。查的方式很简单，逐层用 curl 看返回的协议版本。",[15,305,306],{"id":306},"迁移后怎么验证",[11,308,309],{},"看三个数：首屏资源加载完成时间、连接建立时间、总请求数。",[11,311,312],{},"对比迁移前后各测三次。我们这次的改善主要来自连接数减少，首屏时间从 2.4 秒降到 1.9 秒。",[11,314,315],{},"再看真实用户数据。CrUX 里没有协议维度，但 LCP 的变化能反映出来，按地区分组看更明显，网络条件差的地区改善更大。",[11,317,318],{},"还有个细节值得记住：HTTP\u002F2 下单个大文件的下载主要受带宽限制，多路复用省的是排队时间。所以迁移之后该做的是减少总字节，不是继续拆文件。这两件事方向不同，别搞混。",[15,320,321],{"id":321},"一个判断",[11,323,324],{},"HTTP\u002F2 的收益和页面资源数量直接相关。一个只有五个请求的简单页面，迁移前后几乎没差别。",[11,326,327],{},"资源多、第三方多的站收益明显，尤其是以前用域名分片的站。",[11,329,330],{},"升级本身不难，难的是清理旧习惯。这件事没人会主动做，通常要等一次性能审计才会被发现。",{"title":116,"searchDepth":117,"depth":117,"links":332},[333,334,335,336,337,338,339],{"id":245,"depth":117,"text":245},{"id":254,"depth":117,"text":255},{"id":267,"depth":117,"text":268},{"id":280,"depth":117,"text":281},{"id":293,"depth":117,"text":294},{"id":306,"depth":117,"text":306},{"id":321,"depth":117,"text":321},"2026-10-17","协议升级本身不难，难的是升级之后旧的优化手法全部失效。这篇写域名分片、资源合并、服务端推送和 CDN 兼容四个坑，以及迁移后的验证方法。",{},"\u002Fblog\u002Fhttp2-migration-pitfalls",{"title":237,"description":341},"blog\u002Fhttp2-migration-pitfalls",[347,348,349],"HTTP2","协议升级","页面体验","JJszBGJyjINUoTMIZY_rAAYun_QNdsj5k1cq5z99cqY",1794088100738]