[{"data":1,"prerenderedAt":333},["ShallowReactive",2],{"blog-pagination-canonical-rules":3,"blog-prev-pagination-canonical-rules":147,"blog-next-pagination-canonical-rules":243},{"id":4,"title":5,"author":6,"body":7,"canonical":132,"category":133,"cover":132,"date":134,"description":135,"draft":136,"extension":137,"keywords":132,"meta":138,"navigation":139,"noindex":136,"ogImage":132,"path":140,"seo":141,"seoDescription":132,"seoTitle":132,"stem":142,"tags":143,"updated":132,"__hash__":146},"blog\u002Fblog\u002Fpagination-canonical-rules.md","分页页的 canonical 要指向自己，别指向第一页","元析智能",{"type":8,"value":9,"toc":122},"minimark",[10,14,18,21,24,80,88,91,95,98,101,104,107,110,113,116,119],[11,12,13],"p",{},"分页页 canonical 要指向自己，不要指向第一页。深层分页也别急着 noindex 或 robots 屏蔽，那是在切断内容发现链。这两个错误在软件站里特别普遍，因为模板大多是抄来的。",[15,16,17],"h2",{"id":17},"为什么不能指向第一页",[11,19,20],{},"第 2 页的内容不会出现在第 1 页。canonical 指过去，等于告诉搜索引擎\"第 2 页不用单独存在\"，它上面的长尾内容就永远没机会排名。我们见过一个站把 40 页分页全部 canonical 到第一页，结果第 2 到 40 页的内容完全没收录。",[15,22,23],{"id":23},"三种场景的配置",[25,26,27,43],"table",{},[28,29,30],"thead",{},[31,32,33,37,40],"tr",{},[34,35,36],"th",{},"场景",[34,38,39],{},"canonical",[34,41,42],{},"索引控制",[44,45,46,58,69],"tbody",{},[31,47,48,52,55],{},[49,50,51],"td",{},"标准列表分页",[49,53,54],{},"自指",[49,56,57],{},"都允许索引",[31,59,60,63,66],{},[49,61,62],{},"无限滚动",[49,64,65],{},"URL 不变即可",[49,67,68],{},"不生成新 URL",[31,70,71,74,77],{},[49,72,73],{},"筛选加翻页",[49,75,76],{},"指向无筛选的对应分页",[49,78,79],{},"交给 canonical",[11,81,82,83,87],{},"标准分页最简单：每页 canonical 指向自己，第 1 页也指向自己。第 1 页的 URL 要干净，别带 ",[84,85,86],"code",{},"?page=1","。",[11,89,90],{},"无限滚动如果每次加载都改 URL，用 history.replaceState 而不是 pushState，别让浏览器地址栏堆出一串页码。用 pushState 的站，蜘蛛会把每个滚动状态当成独立页面，抓取预算直接崩。",[15,92,94],{"id":93},"_2026-年-3-月那个模板站","2026 年 3 月那个模板站",[11,96,97],{},"一个电商 SaaS 的模板市场，1200 个列表页，每页 20 个模板。原来所有分页 canonical 都指向第一页，结果只有第 1 页的内容被收录，深层模板页拿不到内链权重。",[11,99,100],{},"改成自指、第 1 页 URL 规范化之后，两个月收录从 300 涨到 1100，模板详情页的自然点击涨 52%。改动只有模板里的一行配置。",[15,102,103],{"id":103},"分页页还要注意两件事",[11,105,106],{},"一是标题和描述。分页页的 title 要带上页码或内容范围，比如\"模板市场 - 第 3 页\"，别所有页共用同一个标题，否则蜘蛛分不清哪页是哪页。二是加载速度，分页页往往图片多，LCP 容易超标，图片懒加载和尺寸标注要做。",[11,108,109],{},"另外，分页页的 URL 形式只保留一种。有的站同时支持 \u002Flist\u002Fpage\u002F2 和 \u002Flist?page=2，两套都在线，就是重复内容。上线前统一成路径形式，旧的 301。",[15,111,112],{"id":112},"一个例外",[11,114,115],{},"超过 20 页的深层分页，内容价值确实低。这种可以 noindex，但保留页面上的链接——别用 robots 屏蔽，屏蔽了蜘蛛就爬不到后面的内容了。noindex 至少还能让链接权重流过去。",[15,117,118],{"id":118},"立场",[11,120,121],{},"分页是内容发现链的一部分，不是重复内容。把它当重复内容处理，等于把内链结构拆了。做 SEO 的人要能跟开发讲清楚：分页的 canonical 指向自己，这一条没有例外。",{"title":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131],{"id":17,"depth":124,"text":17},{"id":23,"depth":124,"text":23},{"id":93,"depth":124,"text":94},{"id":103,"depth":124,"text":103},{"id":112,"depth":124,"text":112},{"id":118,"depth":124,"text":118},null,"技术SEO","2026-05-02","分页页指向第一页、给深层分页加 noindex，这两个做法都在伤害收录。我们按三种分页场景给配置表，附一个 2026 年 3 月的模板站案例：收录从 300 涨到 1100。",false,"md",{},true,"\u002Fblog\u002Fpagination-canonical-rules",{"title":5,"description":135},"blog\u002Fpagination-canonical-rules",[144,39,145],"分页","收录","UDtpk6-AZFMQdkIm7wmKw3OszmynOJ5lrD0IrXTkm8g",{"id":148,"title":149,"author":6,"body":150,"canonical":132,"category":232,"cover":132,"date":233,"description":234,"draft":136,"extension":137,"keywords":132,"meta":235,"navigation":139,"noindex":136,"ogImage":132,"path":236,"seo":237,"seoDescription":132,"seoTitle":132,"stem":238,"tags":239,"updated":132,"__hash__":242},"blog\u002Fblog\u002Ffirst-48-hours-site-takeover.md","接站前 48 小时，我们只做这五件事",{"type":8,"value":151,"toc":224},[152,155,159,162,165,168,172,175,178,182,185,188,191,195,198,201,204,208,211,214,218,221],[11,153,154],{},"2026 年 5 月我们接手一个新站，前 48 小时没写一行方案，全花在五件事上。这两天做错顺序，后面三个月都在补窟窿。常见的错误是一上来就看关键词、给建议，结果改的东西客户那边根本没权限动。",[15,156,158],{"id":157},"第一件先把数据备份下来","第一件：先把数据备份下来",[11,160,161],{},"GSC 能导的数据全导一份，包括最近 16 个月的查询、页面、收录状态。百度搜索资源平台的数据也存一份。",[11,163,164],{},"为什么要备份？因为接手之后你可能改结构、改 canonical，出了问题要能对比改动前的状态。而且 16 个月之后老数据就没了。",[11,166,167],{},"顺手把日志要一份，至少最近 90 天。很多客户以为日志一直存着，实际只留 7 天。",[15,169,171],{"id":170},"第二件把权限和边界确认清楚","第二件：把权限和边界确认清楚",[11,173,174],{},"谁有网站后台权限、谁管服务器、开发排期谁批、内容谁审。这四件事不确认，后面每个改动都会卡住。",[11,176,177],{},"我们有一张权限表，每一项写清对接人和响应时间。见过最夸张的情况是：方案做完了，发现客户没有 GSC 的管理员权限，验证站点花了三天。",[15,179,181],{"id":180},"第三件跑一次完整爬虫","第三件：跑一次完整爬虫",[11,183,184],{},"爬全站，看状态码分布、标题重复、内链深度、canonical 指向、robots 屏蔽范围。这次爬取的结果是后面所有判断的底图。",[11,186,187],{},"注意用真实的 UA，遵守 robots，先小样本跑 200 页看服务器负载。",[11,189,190],{},"爬完存一份带日期的 CSV。三个月后再爬一次，对比就能看出改动有没有生效。",[15,192,194],{"id":193},"第四件读日志","第四件：读日志",[11,196,197],{},"确认搜索引擎到底抓了什么、抓了多少、哪些路径抓得多、哪些页面从来没被抓过。",[11,199,200],{},"重点看三件事：假蜘蛛占比、5xx 和 404 的分布、核心产品页和文档页的抓取频次。这三件事决定了技术侧先修什么。",[11,202,203],{},"如果日志拿不到，至少看 CDN 的访问日志，别跳过这一步。",[15,205,207],{"id":206},"第五件和客户对齐目标","第五件：和客户对齐目标",[11,209,210],{},"问三个问题：这个站现在最重要的一件事是什么、三个月后什么样算成功、哪些东西不能动。",[11,212,213],{},"第三个问题最容易被忽略。有的客户不允许改 URL，有的不允许动首页文案，有的要求所有页面必须带品牌名。这些约束不知道，方案做出来就是废纸。",[15,215,217],{"id":216},"为什么是-48-小时","为什么是 48 小时",[11,219,220],{},"时间再长，客户会觉得你一直在准备、没产出；时间再短，该确认的没确认，后面返工。",[11,222,223],{},"我们把 48 小时当做一个硬边界：两天内交一份三页的“现状与风险”备忘，不写方案，只写看到了什么。这个做法的好处是，客户在第三天就知道你有没有看懂他的站。",{"title":123,"searchDepth":124,"depth":124,"links":225},[226,227,228,229,230,231],{"id":157,"depth":124,"text":158},{"id":170,"depth":124,"text":171},{"id":180,"depth":124,"text":181},{"id":193,"depth":124,"text":194},{"id":206,"depth":124,"text":207},{"id":216,"depth":124,"text":217},"SEO","2026-05-01","接手一个站的头两天，别急着出方案。我们固定做五件事：备份数据、确认权限、跑一次爬虫、读日志、和客户对齐目标，之后才谈改什么。",{},"\u002Fblog\u002Ffirst-48-hours-site-takeover",{"title":149,"description":234},"blog\u002Ffirst-48-hours-site-takeover",[240,241,133],"诊断流程","接站","MqWZzKepLsj4XUQXb2LoNtw5SKZTVNkHMr6gOiOOZ7U",{"id":244,"title":245,"author":6,"body":246,"canonical":132,"category":133,"cover":132,"date":323,"description":324,"draft":136,"extension":137,"keywords":132,"meta":325,"navigation":139,"noindex":136,"ogImage":132,"path":326,"seo":327,"seoDescription":132,"seoTitle":132,"stem":328,"tags":329,"updated":132,"__hash__":332},"blog\u002Fblog\u002Fxml-sitemap-segmentation.md","大站 sitemap 怎么分片：5 万页站点的三条规则和一次失败",{"type":8,"value":247,"toc":315},[248,251,254,257,260,264,267,270,273,277,280,283,286,290,293,296,300,303,306,309,312],[11,249,250],{},"一个 5 万页的 SaaS 文档站，sitemap 之前只有 40% 的页面被收录。我们按内容类型拆成 18 个分片、给 lastmod 立了规矩，8 周后收录率到 78%。分片不是玄学，有三条能落地的规则。",[15,252,253],{"id":253},"我们接手的那个站",[11,255,256],{},"2025 年 11 月接的一个开发者工具客户，站点 5 万页左右：文档 3.2 万页、博客 6000 页、产品页 800 个、剩下的是一堆版本归档和参数页。",[11,258,259],{},"当时只有一份 sitemap.xml，5 万条 URL 塞在一个文件里，lastmod 全部写成抓取当天。Google Search Console 显示已发现 5 万条、已收录 2.1 万条，百度那边更差，收录不到 1.5 万。",[15,261,263],{"id":262},"规则一按内容类型分不按日期分","规则一：按内容类型分，不按日期分",[11,265,266],{},"第一版分片我们按月份拆，每个月一个 sitemap。结果证明这是错的：文档页和博客页混在一起，版本归档页和老文档混在一起，搜索引擎没法判断哪个分片值得优先抓。",[11,268,269],{},"第二版改成按内容类型拆：docs、blog、product、changelog、archive 五个大类，docs 再按产品模块拆成 12 份，一共 18 个分片，外面套一个 sitemap index。",[11,271,272],{},"改完第二周，GSC 里\"已发现\"从 5 万涨到 4.9 万（之前有一部分根本没被发现），文档页的抓取频次涨了 2 倍。",[15,274,276],{"id":275},"规则二单文件不超过-3-万条留余量","规则二：单文件不超过 3 万条，留余量",[11,278,279],{},"协议上限是单文件 5 万条，但我们建议控制在 3 万以内。原因很简单：文件越大，解析越慢，出错的概率越高。",[11,281,282],{},"这个站的文档分片每个控制在 1.5 万到 2 万条，18 个文件加起来不到 600KB。搜索引擎的抓取和解析都很顺。",[11,284,285],{},"还有一条：sitemap 文件本身不要做 gzip 之外的压缩，不要加登录鉴权，不要 301。我们见过一个客户把 sitemap 放在需要登录的 CDN 后面，蜘蛛拿到的是 403，白等了三个月。",[15,287,289],{"id":288},"规则三lastmod-只写真实更新时间","规则三：lastmod 只写真实更新时间",[11,291,292],{},"这个站的 lastmod 之前全写抓取当天，等于告诉搜索引擎\"所有页面每天都在变\"。结果搜索引擎不再相信这个字段，抓取优先级完全按别的信号走。",[11,294,295],{},"改成真实更新时间之后：只有内容实质变更的页面才更新 lastmod，模板调整、样式修改不算。改完第六周，GSC 里\"已发现未收录\"从 2.8 万降到 9000。",[15,297,299],{"id":298},"一次失败分片后忘了更新索引","一次失败：分片后忘了更新索引",[11,301,302],{},"第一版上线时我们只提交了 18 个子 sitemap，忘了更新 sitemap index 里的引用。搜索引擎三天没发现新分片，我们以为分片没用，差点回滚。",[11,304,305],{},"教训：分片上线后必须验证三件事——index 能访问、index 里的子文件都能访问、每个子文件里的 URL 都能打开。我们后来写了个脚本，每次发布跑一遍，5 分钟。",[15,307,308],{"id":308},"判断",[11,310,311],{},"sitemap 分片不是给搜索引擎看的\"提交动作\"，是给抓取排优先级的\"结构声明\"。内容类型清楚、文件大小可控、lastmod 可信，这三件事做到，收录率自然上来。",[11,313,314],{},"5 万页以下的站，其实一份 sitemap 就够。分片是给大站和内容类型复杂的站准备的，别为了\"看起来规范\"过度拆分。",{"title":123,"searchDepth":124,"depth":124,"links":316},[317,318,319,320,321,322],{"id":253,"depth":124,"text":253},{"id":262,"depth":124,"text":263},{"id":275,"depth":124,"text":276},{"id":288,"depth":124,"text":289},{"id":298,"depth":124,"text":299},{"id":308,"depth":124,"text":308},"2026-05-03","一个 5 万页的 SaaS 文档站，sitemap 之前只有 40% 的页面被收录。我们按内容类型拆成 18 个分片、给 lastmod 立了规矩，2025 年 11 月开始改，8 周后收录率到 78%。分片规则、失败教训和验证方法都在这篇。如果你也在管大站，这篇能省一次返工，少走三个月弯路。",{},"\u002Fblog\u002Fxml-sitemap-segmentation",{"title":245,"description":324},"blog\u002Fxml-sitemap-segmentation",[330,145,331],"sitemap","站点结构","1ntf9MrnCVdbtT39M-cGiU6X493sqN3_fTXMBioldAE",1794088106301]