索引膨胀是Google收进索引的URL里，掺了大量低价值、近重复、本就不该进去的页。它三重伤站：把抓取预算烧在垃圾URL上、用一堆薄页拉低整站质量基线（HCU之后这点最致命）、还让自己的页互相抢位。来源远不止筛选器——分页、排序参数、UTM、附件页、作者归档、站内搜索结果、薄标签页、JS路由、老活动页、staging泄漏都算。确诊靠site:量级、sitemap、GSC索引覆盖三者三角对照定位来源，处置按来源分类套noindex、canonical、410、robots、源头治理这张决策矩阵，先止血定靶再下手，绝不一上来robots一把梭。收缩后的恢复以周计、台阶式，别指望第二天。

有个做工具配件的电商客户，找保哥时一脸困惑：站就一万多个真实商品和内容页，Google site一下，显示收了八十多万。他以为这是好事——收得多不是覆盖广吗？真相正相反：那八十万里，真正有价值的不到二十分之一，剩下的全是按颜色、尺寸、排序、页码自由组合出来的参数URL，加上一堆没人会搜的附件页和空标签页。Google的爬虫每天大把时间花在抓这些垃圾上，真正更新的商品页反而要等一两周才被重新抓到，整站在那次核心更新后还莫名其妙掉了一截。这就是典型的索引膨胀，而且是被当成“收录好”误读了的那种，最坑。

这篇不重复站内已经写过的分面导航/筛选器URL组合爆炸怎么治那篇——那篇专攻筛选器这一个来源，本篇是站点级、覆盖全部膨胀来源的系统视角；也不重复站内那两篇专讲抓取预算十二项实操清单、Googlebot 2MB抓取上限的文章，那是单点优化向，本篇讲的是“整站索引为什么会膨胀、怎么按来源分类系统性收缩”的机制与决策。把这个搞懂，你就不会再把site:数字大当成好事，也不会一遇到膨胀就无脑往robots里加Disallow。

索引膨胀到底是什么？和抓取预算、收录是一回事吗？

这三个概念天天被混着说，混了就会开错药。先各归各位。

把“被索引”和“值得被索引”分开

很多人有个根深蒂固的错觉：被Google索引的页越多越好。这个错觉是索引膨胀的认知根源。被索引只说明Google把这个URL存进了它的库，完全不代表这个URL有价值、能排名、该存在。一个站健康的状态不是“尽可能多的页被索引”，是“该被索引的页都在索引里，不该进去的一个都没进去”。索引膨胀的本质就是后半句失守——大量本不该进索引的URL进去了。要理解为什么这会出问题，得先回到搜索引擎抓取、索引、排名这条链路是怎么运转的：抓取要花预算、索引要占评估、排名是相对竞争，每一环都是有成本的资源，往里塞垃圾URL，三环都跟着遭殃。

索引膨胀、抓取预算、收录，三个概念别混

说清楚边界，后面才不会开错药：

• 收录（indexing）：一个URL有没有被Google放进索引。它是个开关状态，不带价值判断。
• 抓取预算（crawl budget）：Google愿意花在你这个站上的抓取资源总量。它是膨胀“伤站”的受害者之一，不是膨胀本身。
• 索引膨胀（index bloat）：被收录的URL里，低价值/近重复/本不该进去的占比过高。它是个结构性质量问题，不是单纯数量问题。

关系是这样的：膨胀会烧掉抓取预算、会拖累索引质量，但它不等于其中任何一个，治理手段也不同。只盯抓取预算去优化，治标；只看收录数量，连方向都错了。本文针对的是膨胀这个结构问题本身。

膨胀的URL都从哪来？远不止筛选器

大多数人一说索引膨胀就只想到筛选器，其实那只是来源之一。把全部来源摊开，对照着排查自己的站：

来源大类	典型URL形态	为什么会失控	默认是否该进索引
筛选/排序参数	?color=&sort=&size= 自由组合	维度可叠加，组合数指数爆炸	绝大多数不该
分页序列	/page/2 /page/87 …	深翻页生成大量薄列表页	深分页基本不该
跟踪参数	?utm_ ?gclid ?fbclid	每条投放/分享生成一个新URL	不该（应canonical无参）
平台默认页	附件页、作者归档、日期归档、空标签页	CMS自动生成、没人管	多数不该
站内搜索结果	/search?q=… 被抓被链	用户每搜一次造一个可索引页	绝对不该
前端路由	JS框架把状态同步进URL	一个交互一夜造数万可索引URL	看场景，多数不该
历史遗留	老活动页、staging域、迁移残留	没人记得清理，长期挂着	不该

参数与分页排序类：和分面治理什么关系

这里要把和站内分面那篇的分工讲清楚。分面导航是参数类膨胀里最猛的一个特例——筛选器维度可自由叠加导致组合爆炸，站内已有专篇深挖；本文把它放回“参数类来源之一”的位置，和排序、分页、跟踪参数并列看，重点不在某一个来源怎么单独治，而在站点级怎么把所有参数类来源一起识别、一起决策。排序参数（同一批内容换个顺序）几乎是纯近重复，价值为零却最容易被忽略；深分页（第八十七页列表）是另一种薄页，没人会搜也没人会停留；跟踪参数则是每一次投放和社交分享都凭空造一个新URL。这三类加起来，量级常常比筛选器还大，但因为不像筛选器那样“看得见”，反而漏得更多。

平台默认生成类：CMS替你挖的坑

这一类最阴险，因为它不是你主动做错了什么，是建站平台默认行为替你生成的：WordPress默认开附件页（每张图一个独立URL）、作者归档、日期归档；很多主题默认让空标签页、空分类页可索引；站内搜索结果页一旦被内部链接或被抓到就进了索引。这些页的共同点是几乎没有独立价值、内容高度稀薄、数量却随站点规模线性甚至超线性增长。一个内容量中等的站，光附件页和空标签页就能占到被索引URL的一小半，绝大多数站长从来没意识到。

前端架构类：一行代码一夜造几万URL

这一类是这几年新增的大头。现代JS框架为了体验，默认会把筛选、排序、分页这些交互状态同步进地址栏，于是一个本来只是前端状态切换的动作，悄悄变成了一个可被抓取、可被索引的独立URL。开发同学完全没意识到自己在造SEO问题，因为在他视角那只是个路由。结果是上线后几周，site:数字莫名其妙翻几倍。这类问题必须在架构设计阶段就让SEO介入，等上线后再补，要么大改前端，要么靠下游手段擦屁股，成本差一个量级。

历史遗留类：没人记得的长期出血点

老活动页（三年前的促销专题，过期了没下线也没处理）、staging或测试子域被搜索引擎抓到收录、上一次迁移没清干净的残留URL——这些单看不起眼，长期挂着累积起来也是一笔。它们的特征是“没人对它负责”，所以治理时往往要专门排查一轮历史，靠日常监控发现不了。

索引膨胀到底怎么伤站？三条机制讲透

知道有膨胀还不够，得知道它具体怎么伤站，才有动力下决心治、也才知道治了能换回什么。

抓取预算被低价值URL烧光

Google每天分给你的站的抓取量是有限的，它由站点的整体健康度、服务器响应、内容更新频率等共同决定，不是你想要多少就有多少。当索引里塞满垃圾URL，爬虫的预算被大量花在反复抓这些没价值的页上，真正重要的新页、更新页反而排不上队，被重新抓取的间隔越拉越长。表现出来就是：你改了一个重要商品页，过了一两周线上还是旧的；新发的内容迟迟不进索引；GSC抓取统计里，每日抓取请求总量不低，但点开看抓的全是带参数的垃圾URL。这不是Google针对你，是你自己的垃圾URL把预算吃光了，好页在排队。

Google官方在抓取预算的说明里反复讲过一个意思：低价值的附加URL（分面导航、会话标识、站内搜索、无限空间类页面）会显著消耗抓取资源，拖慢站点重要内容被抓取和刷新的速度。这恰恰说明索引膨胀不是“收得多”的勋章，是抓取效率被结构性拖垮的病灶。

这个绞杀效应有个反直觉的放大点：站越大、膨胀越严重，它不是线性变糟而是加速变糟。因为大站本来就有海量真实页要抢有限预算，再叠几十万垃圾URL，好页被重抓的间隔会从几天恶化到几周，更新型业务（电商改价、内容站更新）受的伤最直接——你的运营动作和Google看到的版本之间，永远差着一两周的时差，所有基于“改了应该有效果”的判断都被这个时差污染了。

站点级质量基线被稀释，HCU之后最致命

这是三条里最重、也最容易被低估的一条。Google对内容的评估不只看单页，还有站点级整体质量信号。机制上它更像一个分类器而不是平均分：当一个站被索引的URL里低价值、近重复、薄页占比越过某个区间，整站会被往“这类站质量不行”的方向归类，这个归类结果作用到站内所有页，包括那些本来很优质的页。注意这里的关键是“占比”不是“数量”——你有一万个好页，但同时有七十万个垃圾URL被索引，Google看到的这个站的样貌是“信噪比极低”，好页淹没在噪声里。这就是为什么有的站做了一次核心更新后，明明优质内容一个字没动却整体掉量——不是好页变差了，是被一大堆膨胀出来的垃圾URL把整站基线拖到了重评的不利侧。

HCU这类站点级评估上线后，这条从“慢性病”升级成了“可能要命”。膨胀不再只是浪费抓取预算的效率问题，是直接威胁整站可信度的质量问题。它和内容衰退里讲的“弱页拖累强页”是同一个底层机制的两种表现：那边是弱内容拖累，这边是弱URL拖累，治理逻辑都一样——救单页没用，得从站点级把信噪比拉回来。很多团队掉量后第一反应是加产能写新内容，方向恰恰反了：在一个膨胀的站上加新页，等于往一个信噪比已经很低的池子里继续注水，新页自己也被拖着排不上来。

自我竞争与可引用性下降：AI时代的新增代价

近重复的膨胀URL还会让你的页自己跟自己抢。同一批内容换个排序、带个参数生成的多个URL，在Google眼里语义高度接近，它得在这些几乎一样的页里挑一个展示。问题是它挑的那个不一定是你想要的——可能是某个带丑参数的版本被选成了规范页，你精心优化的干净URL反而被判成副本不展示。信号被摊薄在一堆克隆页上，本该集中到一个权威URL的链接权重、点击数据、新鲜度全被稀释，正主页排名还不如膨胀前。这也是为什么有人“没做错任何事”排名却悄悄下滑——不是被罚，是自己的克隆页把自己挤下去了。

AI时代这条又多了一层、而且更狠的代价。当一个站充满近重复和薄页，AI搜索在判断“这个站能不能作为可信来源被抽取引用”时会系统性打折扣：信噪比低的站，模型既难定位到那个权威版本，也更倾向于绕开它去引一个更干净的源。传统SEO里膨胀是效率和质量问题，在GEO语境里它直接决定你能不能进AI的答案——一个被几十万垃圾URL稀释的站，连被AI看见正确版本的机会都在变小。把膨胀只当“浪费抓取预算”理解，已经跟不上现在的代价结构了。

怎么确诊一个站有没有膨胀？三角诊断法

凭感觉说“我站好像有点膨胀”没用，得定量确诊、还要定位到具体来源才能动手。

site量级、sitemap、GSC索引覆盖三角对照

这是最快的确诊法，三个数放一起看：你提交的sitemap里有效URL数（这是你认为该被索引的量）、site:语法返回的量级（这是Google大致收了多少，只看量级不抠精确值）、GSC索引覆盖报告里“已编入索引”的数。三者一对照，结论立刻出来：sitemap一万二、site:八十万、GSC已编入七十多万——膨胀确诊，而且严重。健康的站这三个数应该在同一量级、且“已编入”略大于等于sitemap有效数是正常的（含一些没进sitemap的合理页）。差出一个数量级，不用猜，就是膨胀。

日志按URL模式聚合，看抓取浪费占比

确诊之后要定位来源，最硬的证据在服务器日志里。三角对照只告诉你“胀了、胀得多严重”，不告诉你“胀在哪一类”，定位靠日志。把Googlebot的抓取记录按URL模式聚合——带?sort=的占多少、/page/深翻页占多少、/search?占多少、附件页占多少，做成一张“抓取请求按URL模式的分布表”。保哥处理那个电商客户时，日志一聚合，触目惊心：当月Googlebot约七成的抓取花在带排序和分页参数的URL上，约一成花在站内搜索结果和附件页，真正的商品详情页只分到不到两成预算。这张分布表是后面决定先治哪类的靶子，没有它，处置就是瞎打——而且它还顺带给了你处置后验证的基线，治理见效的第一个信号就是这张表里“好页占比”开始回升。

没有完整日志怎么办？退而求其次用GSC的抓取统计报告，它按响应、按文件类型、按Googlebot类型分了组，虽然不如原始日志细到URL模式，但“主机加载情况”和“抓取请求按目的（发现/刷新）”两块也能看出大致结构。再不行，用site:加路径片段(site:yourdomain.com inurl:sort)分段估各类膨胀URL的量级，糙是糙，确诊和定靶够用。工具次优不是不做诊断的借口，凭感觉直接动手才是膨胀治理最大的浪费。

哪些“未编入索引”是正常的，别瞎修

这里要和站内讲GSC的那篇划清分工。GSC索引覆盖报告里“已发现未编入”“已抓取未编入”“重复，Google选择了不同的规范网址”这些状态，在治理膨胀的语境里很多是正常甚至是好事——它说明Google自己识别出了近重复、主动没收，这正是你想要的结果，不该去“修”它让它被收。站内已有专篇讲GSC索引覆盖各状态到底什么意思、怎么读，本文只强调一个治理判断：膨胀治理的目标不是让所有URL都被收，恰恰相反，是让该不被收的稳定地不被收。把“未编入”当错误一律去修，是新手在膨胀治理里最常见的方向性错误，越修越胀。

确诊之后怎么处置？按来源分类的决策矩阵

这是这篇最该被收藏的部分。不同来源的膨胀，处置手段完全不同，用错工具要么没效要么误伤。对着这张矩阵按来源下药：

膨胀来源	推荐处置	为什么是它	怎么验证	反模式
排序/筛选近重复	canonical指向无参父页 + 源头不可爬	内容本质相同，靠规范化归并信号	GSC重复归并、参数URL退出索引	只加robots（挡抓不挡已索引）
跟踪参数	canonical到无参URL	同一页只是带营销参数	带utm的URL不再单独被索引	对每个参数单独建规则
深分页薄列表	noindex,follow 或 收敛分页深度	无独立价值但要保留爬行路径	深页退出索引、爬行不断	robots屏蔽导致权重传导断裂
站内搜索结果页	noindex + 不内部链接到它	无价值且无限可生成	/search 类URL清出索引	放任被内链而不处理
平台默认薄页	noindex 或关闭该功能	结构性无价值，源头可关	附件/空标签页退出索引	逐条删而不从源头关
历史遗留/已死页	410（确定不回来）或301到相关页	明确无价值，干脆利落清	旧URL彻底退出、无软404	留着404慢慢耗或随手301到首页
前端路由造的URL	架构层不把状态写进可索引URL	源头治理最彻底	新增可索引URL回到正常量级	上线后才靠下游手段补救

工具边界：robots、noindex、canonical各能干什么不能干什么

选错工具是膨胀治理翻车的头号原因，每个工具的边界必须清楚。站内已有专篇系统讲爬虫排除协议到底管什么、不管什么，这里只点治理膨胀时最致命的三条边界：robots的Disallow只挡抓取不挡索引——一个已经被索引的URL，你用robots屏蔽它，Google不再去抓，于是也读不到你后加的noindex，那个垃圾URL反而被永久冻结在索引里，越治越胀。noindex能让页退出索引，但被noindex的页仍然要被抓到才能读到这个指令，所以它不省抓取预算，治的是索引质量不是抓取浪费。canonical是软信号、是建议不是命令，只有当两个页内容确实高度近重复时Google才采信，内容真不同硬指canonical会被忽略。三个工具治的是不同的病，搞混了就是用退烧药治骨折。

处置顺序：先止血定靶，绝不一上来robots一把梭

顺序错了，再对的工具也出事。正确顺序是：先用三角诊断和日志定靶，搞清楚膨胀主要来自哪两三类、各占多少；再按矩阵对最大头的来源动手，能源头治理的优先源头治理（关掉平台默认功能、改前端别把状态写进URL），源头动不了的才用canonical/noindex这些下游手段；historical死页用410干净利落清掉。最忌讳的是一上来就往robots里狂加Disallow——这是新手最爱的动作，也是最容易把已索引垃圾页永久冻结、把CSS/JS也误屏蔽、把诊断路径自己掐断的动作。记住一个原则：robots是控制未来抓取的，不是用来清理已经在索引里的历史垃圾的。清存量靠noindex和410，控增量才靠robots和源头。

为什么源头治理永远优先于下游打补丁

同样治排序参数膨胀，A方案是给所有排序URL加canonical，B方案是让前端压根不把排序状态写进URL。两个看着都能解决，本质完全不同。canonical是下游补丁：URL照样生成、照样被抓（还在烧预算）、Google还得逐个抓到读到canonical再决定归并，是个持续消耗、且依赖Google采信的软过程。源头治理是把水龙头关了：URL根本不再产生，没有抓取消耗、没有归并延迟、没有“canonical被忽略”的风险。下游手段治的是已经流出来的水，源头治理治的是水龙头本身——能关龙头就别只顾着拖地。现实里很多源头确实动不了（改前端要排期、平台限制），那就下游手段顶着，但优先级排序必须清楚：源头能动一定先动源头，下游手段是源头动不了时的次优，不是默认选项。把这个优先级倒过来，是膨胀反复复发的根本原因——只拖地不关龙头，过两个月水又满了。

收缩之后多久能见效？恢复曲线的现实预期

治理动作下去，最考验耐心的是它不会第二天见效。机制决定了节奏：Google要重新抓到那些被你noindex或410的URL，才会把它们移出索引，而它重新抓一遍你成千上万的膨胀URL本身就要花数周到数月，越大的站越慢，而且越是低价值的URL它重访频率本来就越低，等于最该被清的恰恰被抓得最不勤。所以典型的恢复曲线是台阶式的，大致分三段：第一段（约前三到四周）site:量级几乎不动，因为处置过的页还没被重新抓到，这一段最熬人、也是误判“没用”然后推翻重来的高发区；第二段（约四到十周）索引数开始一段一段往下掉，同时抓取统计里好页被抓频率先回升——这个先升是方向对的最早信号；第三段（约三个月后）排名和流量才逐步跟上，因为站点级质量基线和抓取分配是滞后变量。

这意味着治理膨胀的KPI在前一两个月绝对不能看流量，只看两个先行指标：被索引URL总数有没有开始下降、日志里好页被抓占比有没有回升。这两个动了就说明方向对，流量是后面自然兑现的事。如果三四周后这两个先行指标完全没动，才需要回头排查，最常见的根因有两个：一是错用了robots屏蔽导致Google根本读不到你加的noindex（前面反复警告的那个坑），二是处置页返回了软404（页面看着像不存在但HTTP还是200），Google分不清到底要不要把它移出。还有个常被忽略的点：410比404退出索引更快更干净，确定不回来的死页用410，别图省事全留成404慢慢耗。这个慢是机制决定的，不是你做错了；预期管理没和老板/团队提前对齐的话，几乎一定会在第三段还没到、先行指标其实已经在动的时候，被一句“两个月了流量还没涨”给逼着推翻重来——前功尽弃往往不是因为方法错，是因为没扛住那个台阶。

索引膨胀治理最容易翻车的反模式有哪些？

这些坑保哥几乎在每个膨胀治理项目里都见过别人踩，列出来对照避开：

• robots一把梭清存量：把已索引的垃圾URL用robots屏蔽，结果Google读不到noindex，垃圾被永久冻结在索引里，是最高频也最致命的错。
• 把site:数字大当成收录好：方向性误判，越“优化”收得越多越胀，开头那个电商客户就栽在这个认知上。
• 不定靶就动手：没做三角诊断和日志聚合，凭感觉今天治这个明天治那个，资源撒胡椒面，三个月后膨胀照旧。
• 把GSC“未编入”一律当错误去修：Google主动没收的近重复本是好事，硬修等于亲手制造膨胀。
• 只清存量不堵源头：删了一批附件页，平台默认功能没关，过俩月又长出来，无限循环。
• 一刀切noindex误伤着陆页：把某类参数页全noindex，结果里面混着有真实搜索需求的着陆页，把好页一起杀了。
• 做完不监控就宣布胜利：膨胀是会复发的，前端一次发版、一个新插件，URL又开始爆，没有持续监控就是按下葫芦浮起瓢。

真实案例：一个电商站从八十万收缩到三万的复盘

回到开头那个工具配件电商客户。2024年初介入时，site:量级约八十多万，sitemap有效URL约一万二，GSC已编入约七十三万——膨胀确诊，严重。背景是北美中型站、年GMV两千多万美金、上一次核心更新后整站自然流量掉了约两成，团队一直以为是内容不够多，还在加产能写新页，方向完全反了。

第一步定靶：日志按模式聚合，发现Googlebot当月约七成抓取花在带?sort=和分页参数的URL上，约一成花在站内搜索结果和附件页，真正商品和内容页只拿到不到两成。靶子很清楚——排序参数和分页是最大头，站内搜索和附件页是第二梯队。

第二步按矩阵下药、按顺序来：排序和筛选近重复用canonical指向无参父页，同时让前端别再把排序状态写进可索引URL（源头治理）；站内搜索结果页统一noindex并撤掉所有指向它的内部链接；附件页和空标签页直接在平台层关掉功能；一批三年前的老活动页确认不回来，410干净清掉。全程没往robots里加一条针对已索引URL的Disallow——存量靠noindex和canonical让Google重新抓到后自然退出。

这中间差点出一个典型错误值得记。技术团队为了“快点见效”，提议直接在robots里把所有带?sort=的路径Disallow掉，理由是“不让它抓不就行了”。叫停了——那七十多万URL已经在索引里，robots一屏蔽，Google再也抓不到，也就永远读不到我们要加的canonical和noindex，这批垃圾会被永久冻结在索引里，膨胀不降反而锁死。正确做法恰恰相反：这些URL现阶段必须保持可抓，让Google抓到后读到canonical/noindex自然退出，等存量清干净了，再用robots和源头控制增量。这个先放后收的顺序反直觉但是机制决定的，顺序搞反，整个项目就废了。

第三步等和盯先行指标：前三周site:量级几乎没动，团队一度怀疑没用，保哥让继续盯日志——第四周开始，Googlebot抓商品详情页的频率从日均几千次回升到两万多次，这是第一个方向对的信号；第六周起被索引URL总数开始台阶式下降；大约第十周降到约三万（保留了商品、内容、必要的合理列表页），到第四个月稳定在三万出头。整站自然流量在第三到第五个月逐步回升，半年后比介入时高出约三成，团队没有多写一篇新内容，全部增量来自把抓取预算和站点质量基线从八十万垃圾URL里解放出来。这个案例最值钱的一课不是处置手段，是那句反直觉的认知翻转：收录不是越多越好，把不该被收的稳稳挡在索引外，比再写一百篇新内容对这个站有用得多。

常见问题解答

网站被索引的页越多越好吗？

不是。被索引只代表Google存了这个URL，不代表它有价值。健康状态是该收的都收、不该收的一个不进。低价值URL占比过高就是索引膨胀，反而伤站。

site:命令显示的数字能当索引量真值吗？

只能看量级不能抠精确值。它是个粗略估计，但用来做三角诊断够了：site:量级远大于sitemap有效URL和GSC已编入数，就是膨胀的明确信号。

用robots.txt屏蔽掉那些垃圾URL能解决膨胀吗？

清存量不能，还会更糟。robots只挡抓取不挡索引，已被索引的URL屏蔽后Google读不到你的noindex，反而被永久冻结在索引里。清存量靠noindex和410，robots只用于控制未来抓取。

索引膨胀和抓取预算是一回事吗？

不是。抓取预算是Google愿花在你站的抓取资源；索引膨胀是被收URL里低价值占比过高的结构问题。膨胀会烧掉抓取预算，但治理要针对膨胀本身，只优化抓取预算是治标。

GSC里大量“已抓取未编入”要去修吗？

治理膨胀时多数不该修。这常是Google主动识别出近重复没收，正是你想要的结果。把它一律当错误去修，等于亲手把垃圾URL推回索引，越修越胀。

站内搜索结果页要不要让Google收录？

绝对不要。用户每搜一次就生成一个新URL，无限可生成且几乎无独立价值，是典型膨胀源。统一noindex，并撤掉所有指向它的内部链接，别让爬虫发现它。

处理完索引膨胀多久能看到流量恢复？

以周到月计、台阶式。前几周几乎没变化（Google还没重抓到处置页），之后索引数逐段下降、好页抓取频率回升，流量改善更靠后。前两月看先行指标不是流量。

怎么防止索引膨胀反复发生？

堵源头加持续监控。关掉平台默认薄页功能、让前端别把状态写进可索引URL，并把被索引URL总量纳入定期监控。前端一次发版就可能让URL重新爆，发完不盯等于白治。