已发现但尚未编入索引，说明 Google 已经从站点地图或某条内链知道了这个 URL 的存在，但没有把它排进抓取队列——卡点在域名层面，不在这一个页面上。处理它的起点，是在 Search Console 的「页面」（旧版叫覆盖率）报告里，把「已发现 - 目前尚未编入索引」和「已抓取 - 目前尚未编入索引」当成两种不同的故障分开看：前者要改站点层面的抓取信号，后者要改页面内容。而这两组之外的那条「备用网页（有适当的规范标记）」，往往比状态本身更能说明问题，因为它直接反映 Google 有没有按你声明的 canonical 走。
我第一次真正把这几行拆开看，是在一个跑了几个月、收录一直上不去的巴西站上。那天早上我打开 Search Console，左侧点进「编制索引」下面的「页面」，最上面是一张上下起伏的折线图，下面那张表才是有用的东西。「未编入索引」那一栏展开，第一行就是「已发现 - 目前尚未编入索引」，后面跟着一个不小的数字，点右侧能看到一串示例网址。
我的第一反应是去点「重新提交站点地图」。这个动作我以前做过很多次，很少有用。站点地图是一个发现渠道，它把 URL 交给 Google，仅此而已——它不承诺抓取，更不承诺收录。如果 Google 已经知道了这批 URL 却不肯来抓，再交一遍，它知道的还是同一批 URL。
先把「已发现」和「已抓取」分开
这张表把 URL 分成四块：错误、有效（有警告）、有效、已排除。很多人看到「已排除」就发慌，其实里面相当一部分是你自己用 canonical 或 noindex 主动做出来的选择——分页的后续页、参数筛选页、标签聚合页、谢谢页。把这些一概当成问题清掉，反而会把已经正确的结构弄坏。
真正值得盯的是「未编入索引」下面那两行。
「已发现 - 目前尚未编入索引」的含义很具体：Google 知道这个网址存在，但还没有为它安排抓取。既然它连抓都没抓，你去改标题、加段落、调关键词密度，全都是白费力气。这一行指向的是域名整体：抓取队列的深度、服务器响应速度、站点整体的价值信号、内链能不能把重要页面托起来，以及你在站点地图里塞进了多少不值得抓的 URL。
「已抓取 - 目前尚未编入索引」是另一回事：Google 抓到了，看完之后决定不收。这时候问题确实在页面上——内容太薄、和站内别的页面高度重合、只是模板换个字段拼出来的、没有独立信息，或者根本没有别的页面指向它。这一类要动的是内容本身，重新提交解决不了，因为它已经看过一遍了。
「备用网页」那一行，是验 canonical 最快的地方
在「已排除」分组里看到「备用网页（有适当的规范标记）」，本身不算坏消息：它表示 Google 认定这个 URL 是另一页的副本，并且认可了你声明的 canonical。问题出在它出现在哪些 URL 上。如果出现的是你在站点地图里提交的、自以为应该被索引的那些，就说明这些页面从来没被当成主版本——你提交的是副本，不是正本。
还有一种相反的信号，叫「重复网页，Google 选择的规范网页与用户指定的不同」。这一条说明你的 canonical 没有被采纳，Google 自己另选了一个。两者的区别很关键：前一种多半是你自己声明错了，后一种是你声明清楚了但 Google 不同意。
看单个 URL，用网址检查工具里的「Google 选择的规范网址」对一下「用户声明的规范网址」就够了。但一个个查太慢。页面索引报告里的这条状态能一次给你一批样本，让你判断这是个别现象还是整站普遍现象——我遇到过整站 canonical 全部指向一个错误目标的情况，就是在这条状态里一眼看出来的，如果靠一个个查，可能要查到下午。
站点地图能做什么，不能做什么
先说边界。一个站点地图文件只接受同一个主机下的 URL。子域、别的域名，要各自分开提交，混在一起的那些 URL 会被直接忽略。提交有两条路：在 Sitemaps 报告里提交，或者在 robots.txt 里写一行 Sitemap: 指过去。两条都行，选一条稳定的路径就好，不用到处重复声明。
内容上，我现在的原则是：站点地图里只放我真正想被索引、返回 200、且 canonical 指向自己的 URL。标签页、筛选参数、分页的后续页、站内搜索结果页，全都不要放进去。你可能觉得多放一些能让它们更快被发现，实际上那是在稀释本来就有限的抓取预算——Google 会分出一部分精力去看那些你根本不想要的东西。
我实际的动手顺序
一，把「已发现」和「已抓取」两组的示例网址分别导出，存成两个文件，不要混在一起看。
二，从「已发现」里抽几个，逐个查：是不是返回 200、在不在站点地图里、canonical 指不指向自己、有多少条内链、从首页点几下能到、服务器响应是多少毫秒。
三，看这一整组是不是同一个模板出来的，比如全挂在某个目录下面。如果整组的形态高度一致，那基本是站点结构的问题，不是某一个页面的事。
四，对「已抓取」的那组看内容：和站内已有页面是不是撞车，是不是只是个列表页，有没有独立信息。该合并就合并，该 noindex 就 noindex，该补就补。
五，回到站点地图做减法。把不该被索引的 URL 移出去。这一步往往是我操作下来收益最大的一步，而且它不需要等任何东西。
六，记一张表：日期、两组各自的数字、这次做了什么动作。隔一段时间再比，而不是每天刷同一个页面。
有些情况它就是慢
新域名、刚上线的目录、外链稀少的站，抓取队列本来就浅。这里没有可以承诺的天数，变量太多，我见过同样的动作在不同站点上结果差得很远，所以我不会告诉你几天会好。
能确认的只有一件事：把站点地图收干净、把内链补上、把服务器响应压下来、把重复的模板页 noindex 掉，这几件事本身对站点没有坏处，无论结果快慢。反过来，在「已发现」这个阶段反复重交同一个站点地图、把没内容的页面成批塞进去凑数量、或者找第三方批量提交服务，要么完全没用，要么会把站点信号弄得更难看。
举个亲身例子：我们自己的一个荷兰语内容站（De Eetbare Tuin）上线头几周，页面报告里几乎全是"已发现 - 目前尚未编入索引"——域名新、外链少，抓取队列本来就浅，这是这类 .nl 新站的常态。当时做的就三件事：sitemap 只留该收录的 URL、新文章之间用正文内链接起来、服务器响应压到几百毫秒以内，剩下的交给时间。到第二批内容开始收录时，第一批基本已经跟进来了。
