[{"data":1,"prerenderedAt":316},["ShallowReactive",2],{"blog-pagination-seo-rules":3,"blog-prev-pagination-seo-rules":111,"blog-next-pagination-seo-rules":210},{"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\u002Fpagination-seo-rules.md","rel=next 没用了之后，分页页面怎么做技术 SEO","元析智能",{"type":8,"value":9,"toc":85},"minimark",[10,14,19,22,25,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79,82],[11,12,13],"p",{},"Google 早就不把 rel=next\u002Fprev 当收录信号，很多站的分页配置还停在五年前。2026 年 4 月我们给 8 个内容站重做了分页逻辑，核心是三件事：可抓取、有上限、尾部别急着 noindex。",[15,16,18],"h2",{"id":17},"rel-nextprev-的现状","rel next\u002Fprev 的现状",[11,20,21],{},"Google 2019 年就宣布不再把 rel=next\u002Fprev 当作索引信号。它现在只是把分页页当成普通页面处理，靠链接发现后续页。",[11,23,24],{},"百度对 rel=next\u002Fprev 的支持也有限，更多还是看页面之间的链接关系。",[11,26,27],{},"所以配置分页时，别把精力花在加标签上，把精力花在\"链接能不能被爬到\"上。",[15,29,30],{"id":30},"分页的三个目标",[11,32,33],{},"第一，让搜索引擎能发现深层的列表内容。第二页之后的条目，如果没有链接路径，等于不存在。",[11,35,36],{},"第二，别让分页页占满索引。一个 100 页的分页列表，前 5 页有价值，后面 95 页是重复内容。",[11,38,39],{},"第三，别让分页吃抓取预算。我们见过一个站，抓取请求的 30% 落在 page=20 之后的空列表上。",[15,41,42],{"id":42},"我们的做法",[11,44,45],{},"第一，分页链接用普通的 a 标签，href 指向真实 URL，别用 JS 点击加载。这是最基本的，但很多站做不到。",[11,47,48],{},"第二，给分页设上限。列表超过 10 页的，只保留前 10 页可抓取，后面的页面返回 404 或者用 robots 屏蔽。具体留几页，看内容量和用户行为，我们一般按\"前 3 页有点击\"来定。",[11,50,51],{},"第三，分页页的标题加页码，描述别复制第一页。重复的标题和描述会让搜索引擎判定为重复页。",[11,53,54],{},"第四，canonical 指向自己，不要指向第一页。分页页是独立页面，canonical 到第一页等于告诉搜索引擎\"这些都是第一页\"，深层内容就废了。",[15,56,57],{"id":57},"一个反常识的做法",[11,59,60],{},"很多教程说\"分页页全部 noindex\"。我们不同意。",[11,62,63],{},"分页页是发现深层内容的路径，noindex 之后，搜索引擎虽然还能顺着链接爬，但优先级会降低。我们的做法是：前几页保留 index，尾部页面才处理。",[11,65,66],{},"一个内容站按这个做法调整后，第 4 页之后的文章收录率从 22% 涨到 61%。",[15,68,69],{"id":69},"一个案例",[11,71,72],{},"一个做行业资讯的客户，列表页有 60 多页，之前每页都加 noindex。结果第 10 页之后的文章基本不收录。",[11,74,75],{},"我们改成：前 5 页 index，第 6 页之后 noindex 但保留链接，同时把所有文章的发布时间和分类归档页补上。两个月后，老文章收录量涨了 3 倍。",[15,77,78],{"id":78},"判断",[11,80,81],{},"分页不是\"要不要收录\"的二选一，是分层处理：头部页面给权重，尾部页面给路径。",[11,83,84],{},"别抄五年前的教程，先看你的分页现在到底被爬了多少、被收了多少，再决定怎么改。",{"title":86,"searchDepth":87,"depth":87,"links":88},"",2,[89,90,91,92,93,94],{"id":17,"depth":87,"text":18},{"id":30,"depth":87,"text":30},{"id":42,"depth":87,"text":42},{"id":57,"depth":87,"text":57},{"id":69,"depth":87,"text":69},{"id":78,"depth":87,"text":78},null,"技术SEO","2026-06-02","Google 早就不把 rel=next\u002Fprev 当收录信号，很多站的分页配置还停在五年前。2026 年 4 月我们给 8 个内容站重做了分页逻辑：可抓取、有上限、尾部不 noindex。三个目标、具体做法和一个反常识结论都在这篇。这套做法我们用了两年，8 个站都跑通了。",false,"md",{},true,"\u002Fblog\u002Fpagination-seo-rules",{"title":5,"description":98},"blog\u002Fpagination-seo-rules",[107,108,109],"分页","抓取","站点结构","0ivLfnbd3p5hGJAF0MUWc97e4LSMe0LxC58RnTb6p44",{"id":112,"title":113,"author":6,"body":114,"canonical":95,"category":96,"cover":95,"date":199,"description":200,"draft":99,"extension":100,"keywords":95,"meta":201,"navigation":102,"noindex":99,"ogImage":95,"path":202,"seo":203,"seoDescription":95,"seoTitle":95,"stem":204,"tags":205,"updated":95,"__hash__":209},"blog\u002Fblog\u002Fhreflang-pipeline-validation.md","多语言站 hreflang 落地：从生成到校验的流程",{"type":8,"value":115,"toc":189},[116,119,122,125,128,131,134,147,155,159,162,165,168,171,174,177,180,183,186],[11,117,118],{},"hreflang 要工程化，别靠人工。页面超过 200 个，手写一定漏，而且漏了不会报错。我们现在的做法是生成器加校验脚本，接进发布流程，漏了就不让上线。",[15,120,121],{"id":121},"三种实现位置",[11,123,124],{},"HTML head 里的 link 标签、HTTP 响应头、sitemap 里的 xhtml:link。我们统一用 HTML head 加 sitemap 双写，两处必须一致，冲突时以 HTML 为准。非 HTML 资源（PDF 白皮书之类）才用响应头。",[15,126,127],{"id":127},"生成器怎么设计",[11,129,130],{},"输入是页面 ID、语言、地区、这个页面有哪些翻译版本，输出是每个语言版本页面上的完整 link 标签组。数据来自内容库里的翻译关联表，不是从 URL 字符串猜。这点很重要：URL 规则一改，猜出来的关系就全错了。",[15,132,133],{"id":133},"三条校验规则",[135,136,137,141,144],"ol",{},[138,139,140],"li",{},"每个页面必须包含自身语言的 hreflang，自引用不能缺。",[138,142,143],{},"A 指向 B，B 必须指向 A，双向关系。",[138,145,146],{},"一个语言组里 x-default 有且只有一个。",[11,148,149,150,154],{},"再加两条容错：指向的 URL 必须返回 200 且不是 noindex；语言代码必须在合法列表里，",[151,152,153],"code",{},"en-UK"," 这种拼错要拦住。",[15,156,158],{"id":157},"_2025-年-11-月那次接入","2025 年 11 月那次接入",[11,160,161],{},"一个出海 SaaS，14 个语言、8000 个翻译页面。原来人工维护 sitemap 里的 hreflang，抽查发现漏了 23%。接入生成器后，校验脚本全量跑一遍 8 分钟，一次通过；新增语言版本的上线时间从两天缩到半天。",[15,163,164],{"id":164},"发布流程",[11,166,167],{},"语言版本上线，生成器写入 hreflang，校验脚本跑，通过才允许发布。失败时输出具体页面和缺失的语言，直接给到开发。这套流程跑了一年多，没再出现过整组失效的问题。",[15,169,170],{"id":170},"校验脚本长什么样",[11,172,173],{},"输入是爬虫导出的全站 HTML，输出是三张表：缺自引用的页面、单向指向的页面、语言组合法但 URL 异常的页面。用 Python 加正则就能写，一百行以内。我们把它做成 CI 里的一步，每次构建失败会直接指出哪个页面、缺哪个语言，不用人去翻源码。",[15,175,176],{"id":176},"什么时候不值得做",[11,178,179],{},"只有两三个语言版本、每个版本页面不多的站，别上这套工程。HTML head 里手写一组 link 标签就够，维护成本比写脚本低。语言版本超过 5 个、或者翻译页面超过 500 个，再考虑生成器。",[11,181,182],{},"还有一个判断：如果某个语言版本的内容只是机翻、没有本地化，先把内容补齐再谈 hreflang。语言组里塞一堆机翻页，搜索引擎会整组降低信任，比不配更糟。",[15,184,185],{"id":185},"立场",[11,187,188],{},"没有校验脚本的 hreflang 等于没有 hreflang。配错了搜索引擎不会提醒你，只会安静地展示错的语言版本，然后你以为是内容问题。",{"title":86,"searchDepth":87,"depth":87,"links":190},[191,192,193,194,195,196,197,198],{"id":121,"depth":87,"text":121},{"id":127,"depth":87,"text":127},{"id":133,"depth":87,"text":133},{"id":157,"depth":87,"text":158},{"id":164,"depth":87,"text":164},{"id":170,"depth":87,"text":170},{"id":176,"depth":87,"text":176},{"id":185,"depth":87,"text":185},"2026-06-01","hreflang 难的不是语法，是上千个页面的一致性。我们把 hreflang 做成生成器加校验脚本，接进发布流程，新增语言版本不会再漏。这篇给具体做法和三条校验规则。",{},"\u002Fblog\u002Fhreflang-pipeline-validation",{"title":113,"description":200},"blog\u002Fhreflang-pipeline-validation",[206,207,208],"hreflang","多语言","工程化","mIdVFHXIROXmsqQ4Qb7qxEDoOcsHGJZaKpRBm2Omoug",{"id":211,"title":212,"author":6,"body":213,"canonical":95,"category":96,"cover":95,"date":305,"description":306,"draft":99,"extension":100,"keywords":95,"meta":307,"navigation":102,"noindex":99,"ogImage":95,"path":308,"seo":309,"seoDescription":95,"seoTitle":95,"stem":310,"tags":311,"updated":95,"__hash__":315},"blog\u002Fblog\u002Fdomestic-cdn-selection.md","海外 CDN 在国内慢在哪，选型先看三个指标",{"type":8,"value":214,"toc":296},[215,218,221,224,227,230,233,236,239,242,245,248,251,254,257,260,263,266,269,272,275,278,281,284,287,290,293],[11,216,217],{},"2026 年 6 月一个客户的官网放在海外 CDN 上，国内打开首字节 1.1 秒。换回国内节点之后，同一个页面降到 240 毫秒。这不是 CDN 好坏的问题，是路径的问题。",[15,219,220],{"id":220},"跨境链路的三个问题",[11,222,223],{},"第一，物理距离。数据包来回一趟就是 150 到 200 毫秒，TLS 握手要两三个来回，光建立连接就 400 毫秒。",[11,225,226],{},"第二，国际出口拥塞。晚高峰丢包率能到 5%，TCP 一丢包就退避，速度断崖式下降。",[11,228,229],{},"第三，DNS 解析。海外 DNS 在国内解析慢，有时还会被解析到不合适的节点。",[15,231,232],{"id":232},"国内选型的三个指标",[11,234,235],{},"第一，首字节时间。这是用户能感知到的等待，比下载速度重要。目标 300 毫秒以内。",[11,237,238],{},"第二，丢包率。跨网访问时，丢包率超过 1% 体验就开始明显变差。",[11,240,241],{},"第三，跨网延迟。电信、联通、移动三网之间的延迟差很多，要选多线或者 BGP 的节点。",[15,243,244],{"id":244},"备案是前提",[11,246,247],{},"国内 CDN 需要域名备案。没有备案，只能用海外节点，这是硬门槛，绕不过去。",[11,249,250],{},"有些公司用香港节点过渡，延迟比美西好，但比国内节点还是差一截。用户主要在国内，早晚要备案。",[15,252,253],{"id":253},"国内海外双线怎么搭",[11,255,256],{},"主域名走国内 CDN，海外用户解析到海外节点。用智能 DNS 按地域分流，一套代码两个入口。",[11,258,259],{},"注意两件事：一是证书要覆盖两个入口，二是 hreflang 和 canonical 别写死成单一域名，否则搜索引擎会分裂。",[11,261,262],{},"如果海外流量占比很低，可以不做双线，先把国内的体验做好。",[15,264,265],{"id":265},"怎么实测",[11,267,268],{},"用多个城市的节点跑 ping 和 mtr，看每一跳的延迟和丢包。mtr 比 ping 有用，因为它能看到具体哪一跳出问题。",[11,270,271],{},"再看真实用户数据。CrUX 里可以按国家筛，国内用户的 TTFB 和 LCP 分布能直接反映问题。",[11,273,274],{},"第三方测速平台也能用，但要看它有没有国内节点，只有海外节点的平台测出来的数据没参考价值。",[15,276,277],{"id":277},"不能备案时的过渡方案",[11,279,280],{},"如果暂时不能备案，可以先做两件事：把字体、图片、JS 这些静态资源放到国内能访问的对象存储上，主站 HTML 仍然在海外；再用 preconnect 提前把连接建起来。",[11,282,283],{},"这两件事不涉及备案，能抢回一部分时间。但 HTML 本身的往返省不掉，体验只能改善一半。",[11,285,286],{},"所以过渡方案只能撑一阵，真要做国内市场，最后还是得备案加国内节点。",[15,288,289],{"id":289},"一个明确的态度",[11,291,292],{},"用户主要在国内，就别用海外 CDN。这句话我说过很多次，还是经常看到软件公司的官网挂在海外服务上，国内打开要三四秒。",[11,294,295],{},"他们的理由是开发方便、海外客户多。可以理解，但官网是给客户看的，客户的体验优先。一套双线配置多花两天，换来的是国内用户不再流失。",{"title":86,"searchDepth":87,"depth":87,"links":297},[298,299,300,301,302,303,304],{"id":220,"depth":87,"text":220},{"id":232,"depth":87,"text":232},{"id":244,"depth":87,"text":244},{"id":253,"depth":87,"text":253},{"id":265,"depth":87,"text":265},{"id":277,"depth":87,"text":277},{"id":289,"depth":87,"text":289},"2026-06-03","一个站换回国内 CDN，首字节从 1.1 秒降到 240 毫秒。这篇写跨境链路的问题、国内选型的三个指标，以及国内海外双线怎么搭。",{},"\u002Fblog\u002Fdomestic-cdn-selection",{"title":212,"description":306},"blog\u002Fdomestic-cdn-selection",[312,313,314],"CDN","国内访问","页面体验","bQSsakkIdQgKH-1Mc9VT0NGwsiCQmxwGt_e9Xm0pofs",1794088105113]