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