可索引性一键体检怎么用？页面被什么挡在索引外一次查清

摘要：可索引性一键体检把状态码、重定向链、robots.txt判定、meta robots、X-Robots-Tag、canonical这六处信号合并成一次请求，服务器以Googlebot的身份去抓，然后告诉你这一页能不能进索引。我们把它的后端接口逐条打了桩，主业是可靠的——robots规则组和最长匹配算得准，被拦时能把生效的那条规则原样端出来。

但有四处判定会给出与真实情况相反的结论：meta标签把content写在name前面，工具读不到noindex，直接放绿灯；X-Robots-Tag带爬虫名前缀时它照单全收，把只对某个爬虫生效的指令算到Googlebot头上；重定向目标写成相对路径时它会把你送到网站根目录，然后报一个并不存在的404；canonical只是域名大小写不同，它判你指向了别处。这四条都不是概率问题，是代码路径，本文给出每一条的复现方式和该怎么绕。

页面不被收录这件事，麻烦在于它没有报错。服务器不会给你发邮件，Search Console的提示往往滞后一两周，而页面本身在浏览器里打开一切正常。真正把它挡在外面的东西，一半藏在HTTP响应头里，另一半藏在你以为不会出问题的地方——比如一个上线时被顺手改掉的robots.txt，或者CDN配置里多出来的一行响应头。

保哥笔记的可索引性一键体检做的就是把这些散落的信号一次性收齐。这篇教程不打算复述它的界面，而是把它的判定逻辑逐条拆开：哪些结论可以直接信，哪些结论需要你再看一眼原始值，以及在什么情况下它会给出与事实相反的答案。

这款工具一次请求到底查了哪几层？

它的工作方式很直接：你给一个网址，服务器带着Googlebot的User-Agent去抓，不跟随重定向地逐跳走完整条链，再单独去根目录取一次robots.txt，最后把页面HTML里的几个关键标签解析出来。整个过程只发生在服务器端，跟你本地的浏览器、插件、登录状态都没关系——这一点很重要，因为很多掉索引的排查之所以绕远路，就是因为在自己浏览器里看到的和爬虫看到的不是同一份东西。

信号可以按“谁能挡住收录”分成三层，工具的结论也是按这个顺序推的。

把这张表记住，比记住工具的按钮位置有用得多。因为无论你用哪款工具，排查顺序都应该是从上往下：传输层没通，下面查了也白查；许可层被拒，归属层写得再漂亮也进不去。

工具最终会输出三种结论：可以被收录、能抓到但有需要确认的地方、无法被收录。前两种之间的界线其实挺微妙，后面会专门说。

它用Googlebot的身份去抓，这一点意味着什么？

工具发请求时带的User-Agent是Googlebot的标准写法。这个设计有它的道理，也有你需要知道的副作用。

好处是它能触发那些“按爬虫身份区别对待”的逻辑。有些站会给爬虫返回不带弹窗、不带同意条的精简版本；有些付费墙会对爬虫开放全文；还有些安全设备会专门给非浏览器UA一个验证页。用真实浏览器去看，这些差异全都看不见，而搜索引擎看到的恰恰是另一份内容。工具帮你站到了爬虫的位置上。

副作用有两个，都值得留意。

第一，声称自己是Googlebot但IP不是Google的，属于伪装UA。规矩一点的站会做反向DNS校验，发现对不上就返回403或者验证页。所以当你测别人的站拿到403时，先别急着下结论说对方屏蔽了搜索引擎，很可能只是它在拦冒充者。这时候换个思路：用普通浏览器UA的工具再测一次，两边结果不同就说明对方在做UA区分。

第二，如果某个站真的给Googlebot和普通用户返回了实质不同的内容，那是Google明令禁止的伪装行为，风险在站方而不在你。但作为诊断者，你至少能通过这个差异发现问题的存在——这在接手一个来路不明的老站时非常有用。

还有一个容易忽略的点：它抓的是不带任何Cookie、不带登录态、不带地域偏好的裸请求。会员可见的内容、按地区跳转的内容、A/B测试分流的内容，工具看到的都是默认分支。这跟爬虫的真实处境基本一致，但和你在自己浏览器里看到的往往不是一回事。

robots.txt这一块它算得准吗？

先说它做对的部分，这部分是这款工具最值钱的地方。

robots.txt的规则判定不是“谁写在前面听谁的”，而是一套有明确优先级的算法：先在文件里找适用于当前爬虫的规则组，找不到就退回通配组；然后把所有能匹配这个路径的规则挑出来，取路径最长的那一条；长度相同时，Allow压过Disallow。RFC 9309对这一点写得毫不含糊——最具体的匹配必须被采用，而最具体的定义是“字节数最多的那一条”。

我们拿本站被屏蔽的一个内部路径去打桩，工具的返回是这样的：判定为不允许抓取，命中规则原样输出为Disallow: /_audit，并且标明生效的规则组是通配组。这三样信息凑齐了，才叫可用的诊断——只说“被robots挡住了”而不告诉你是哪一行挡的，你还得回去在几百行文件里人肉找。

换成正常的文章页去测，它返回允许抓取、没有规则匹配这个路径，同时把robots.txt里声明的sitemap地址一并带回来。这几项都对。

顺带说一个很多人栽过跟头的细节：Disallow: /admin挡住的不只是后台，而是所有以admin开头的路径，/administrator-guide.html这种正常文章也会被一起拦掉。工具会把生效的规则原样打出来，你一眼就能看见是不是这条在作怪。这类“以为只挡了一个目录，实际挡了一片”的事故，在改版后的站上出现频率高得出奇。

robots.txt取不回来的时候，默认放行对吗？

这就要说到第一处需要你留个心眼的地方了。

工具取robots.txt的方式是：拼出根目录地址，发一次请求，只有返回200才把内容拿去解析，其余情况一律当成“没有robots.txt，默认全部允许”。界面上会老实告诉你“robots.txt返回404，视为全部允许”——文案是诚实的，问题在于这个默认对404成立，对500不成立。

RFC 9309把这两种情况分得很清楚。4xx属于Unavailable，规范允许爬虫在没有规则可依时抓取全站；而5xx属于Unreachable，原文的要求是爬虫必须假定完全禁止抓取，只有在这种状态持续足够长时间（规范举的例子是30天）之后，才可以退回到当作不可用来处理。

方向是反的。你的服务器如果正在闹脾气，robots.txt跟着一起返回503，工具会告诉你“视为全部允许，这一页可以被收录”，而Googlebot那边的实际反应是暂时把整个站的抓取停掉。这种时候你拿着一个绿灯去汇报“技术上没问题”，会很尴尬。

还有一个同源的问题：工具取robots.txt时不跟随重定向。而把robots.txt做301的站并不少见，尤其是那些把静态文件统一托管到CDN或者做了裸域到www归一的站。我们用同样的取法复现了一次——某个营销云平台的裸域robots.txt，不跟随重定向时拿到的是一个301和167字节的空壳，跟随一跳之后能读到的是356条Disallow规则。差别是从零条规则到三百多条规则。

规范这边的要求是明确的：爬虫至少应该跟随五次连续重定向，即使跨主机也一样，只要在五跳内拿到文件就必须按初始主机的上下文解析并遵守。所以当你测的站robots.txt有跳转时，工具给出的“没有规则限制”是个空判断，你得自己把最终地址取出来看一遍。

页面里的两处noindex，工具都读得到吗？

noindex可以写在HTML的meta标签里，也可以写在HTTP响应头的X-Robots-Tag里。工具两处都查，也都把原始值打了出来——但这两处的解析各有一个盲区，而且错的方向正好相反：一处该报不报，一处不该报却报。

meta robots的属性写反了，工具还认得出来吗？

这是本次实测里最该警惕的一条，因为它的错误方向是漏报——工具给你绿灯，而页面实际上被彻底屏蔽了。

我们放了一个探针页，页面头部只写了一行：

<meta content="noindex,nofollow" name="robots">

属性顺序反过来了，content在前，name在后。HTML规范对属性顺序没有任何要求，浏览器、解析器、搜索引擎都一视同仁，这行标签和常见写法在语义上完全等价，Google会老老实实地把这一页排除出索引。

工具的返回是：metaRobots为空字符串，noindex为false。翻译成界面语言就是“meta robots未设置”加上一个绿色的“可以被收录”。

根子在它的提取正则上——那条正则要求先出现name属性、后出现content属性，顺序一颠倒就匹配不上。同样的模式还用在description和canonical的提取上，所以这几项都存在相同的盲区。

什么样的站会把属性写反？比通常想象的多。模板里用变量拼标签的、SEO插件与主题各输出一半的、前端框架按对象键顺序序列化属性的，都可能生成这种顺序。它在源码里看着完全正常，肉眼也挑不出毛病，恰恰是最容易被工具漏掉的一类。

绕开的办法只有一个：结论显示绿灯但页面就是不收录时，回头在源码里直接搜noindex这个词，而不是相信工具那一栏的“未设置”。搜词的成本是三秒钟，省下的可能是两周的排查。

X-Robots-Tag带爬虫名前缀，会不会被算错？

上一条是漏报，这一条正好相反，是误报。

X-Robots-Tag这个响应头允许指定它只对哪个爬虫生效，写法是在指令前面加上爬虫名和一个冒号。Google的规范文档里就有这种用法的例子，含义是：只有名字对得上的那个爬虫才需要遵守，其余爬虫当它不存在。

我们的探针页发了这么一个响应头：

X-Robots-Tag: badbot: noindex

页面里的meta robots写的是index,follow。对Googlebot来说，这一页百分之百可以被索引——那条noindex是给一个叫badbot的爬虫看的。

工具的返回是noindex为true，结论直接跳到“无法被收录”。它对这个响应头的处理只有一步：在整个字符串里搜有没有noindex或者none这两个词，搜到就算数，完全不解析前面的爬虫名。

这个误报的杀伤力在于它会把你引向一次完全没必要的紧急排查。有些站会给采集类爬虫、AI训练爬虫单独下noindex或者noarchive指令，这在内容保护上是很常规的做法。工具一看见这行就报红，你以为线上出了大事故，翻半天配置才发现虚惊一场。

正确的读法是：X-Robots-Tag那一栏永远要看原始值。工具好在把原始值原样打出来了，你只要确认冒号前面写的是不是Googlebot，或者干脆没有前缀。有前缀且不是Googlebot，那条红色结论就可以忽略。

跳转与归属这两项，什么时候会给出相反结论？

许可层查完，还剩传输层的跳转链和归属层的canonical。这两项工具都能取到原始值，问题出在它拿到值之后的计算方式上——一个把相对地址算错了目录，一个把等价地址判成了不等价。

重定向目标写成相对路径，结论为什么会翻车？

这一条最隐蔽，因为翻车的样子看起来特别像“真的出问题了”。

HTTP的Location响应头允许写相对路径。老一点的PHP站里，header('Location: next.php')这种写法遍地都是；nginx和Apache的配置里也常见不带前导斜杠的目标。按照RFC 3986的相对引用解析规则，这种目标要相对当前请求的目录来解析——请求的是/tools/a.php，目标写b.php，那就是/tools/b.php。浏览器、curl、Googlebot都是这么算的。

我们的探针是一个放在/tools/目录下的页面，它返回302，Location头就一个裸文件名。工具跟踪重定向链的结果是这样的：

第1跳  302  https://example.com/tools/zzp3.php  →  zzp4.php
第2跳  404  https://example.com/zzp4.php

它把目标解析到了网站根目录，于是撞上一个不存在的地址，最终结论是“无法被收录：最终状态码是404”。而真实情况是这条跳转好好的，终点在/tools/zzp4.php，返回200。

代码里的处理是：目标不以斜杠开头时，直接把它接到“协议加主机名”后面，中间补一个斜杠。也就是说，只要目标是相对路径，请求URL的目录层级就被整个丢掉了。目录越深，错得越离谱。

这个坑的实际影响面比它看起来大。做迁移、做整站改版的时候，重定向规则往往是批量生成的，相对路径写法在批量规则里非常常见。你拿工具去抽查几条，看到一片404，很容易得出“重定向全写错了”的错误结论，然后去改根本没坏的东西。

判断方法很简单：看链条里那个“→”后面的目标，如果它不是以http开头、也不是以斜杠开头，工具算出来的下一跳地址就不可信，用浏览器实地走一遍才作数。

canonical只是域名大小写不同，为什么被判成指向别处？

这一条属于轻伤，但会让结论从绿灯降到黄灯，值得知道。

工具判断canonical是不是自指的方式，是把canonical的值和最终URL都去掉尾部斜杠，然后做字符串比较。相等就是自指，不等就提示“canonical指向了别的地址，意味着这一页把信号让给了目标页”。

我们的探针页写了一个只有域名大小写不同的canonical：

<link rel="canonical" href="https://ZhangWenBao.com/tools/zzp5.php">

返回结果里，canonical是带大写的那串，最终URL是全小写的那串，两者字符串不等，于是被判成指向别处，整体结论降级为“能抓到，但有需要确认的地方”。

RFC 3986说得很直白：scheme和host是大小写不敏感的，HTTP://www.EXAMPLE.com/和http://www.example.com/是同一个URI。所以这就是一个标准的自指canonical，一点毛病没有。

同一个比较方式还用在hreflang的自引用检查上，那里也是严格字符串比对。所以如果你的多语言标注里协议、主机名大小写、尾斜杠跟页面实际地址有任何一点写法差异，工具都会提示“缺少自引用”。这个提示不一定是错的——Google那边确实建议整组hreflang的地址写法保持一致——但它不能作为“标注无效”的判据。

顺带一提，如果canonical确实指向了别的页面，那才是需要认真对待的信号。canonical是提示不是命令，Google有权自选规范页，但一个程序错误地把全站canonical指向首页的站，掉起收录来是成片成片掉的。

robots拦截加noindex，为什么是个无效组合？

这个组合值得单开一节，因为它是排查里最反直觉的一处，而工具会专门提示它。

很多人的直觉是：既然想让一个页面彻底不出现在搜索结果里，那就双保险——robots.txt里禁掉，页面里再加个noindex。听起来很稳，实际上等于什么都没做。

原因在于两个机制的作用位置不同。robots.txt管的是“能不能抓”，noindex管的是“抓到之后要不要收”。你先用robots把爬虫挡在门外，它就永远读不到页面里那句noindex。而如果这个地址有外部链接指向它，搜索引擎知道这个地址存在，又被禁止抓取内容，最后可能给出一条没有摘要的结果——想藏的东西反而以最难看的方式露出来了。

正确做法是反直觉的那个：放开robots.txt，让爬虫进来，读到noindex，然后它才会把这一页从索引里拿掉。等确认已经掉出索引了，再决定要不要用robots封路。

工具会在同时检测到这两个信号时给出提示。这个提示是准确的，而且是那种“知道了就不会再犯”的知识点。

绿灯为什么不等于会被收录？

工具给出“可以被收录”的时候，它的准确含义是：在它检查的这六项信号里，没有发现阻断收录的东西。这是一个必要条件的结论，不是充分条件的结论。

可索引和已收录之间隔着好几道关。爬虫得先发现这个地址——没有内链、没有进sitemap的页面，可能压根没被抓过；抓到之后得判断内容值不值得存进索引，重复度高、篇幅极短、和站内其他页面高度雷同的页面会被抓了又丢；就算存进去了，还得排到用户能看见的位置才有意义。

所以看到绿灯却搜不到的时候，接下来该查的不是这六项，而是这几件事：

• 这一页有没有站内页面链接过去。一个页面如果只在sitemap里存在、站内没有任何入口，抓取优先级会低得可怜。
• sitemap里有没有它，lastmod是不是真实的。全站lastmod统一刷成今天，效果等同于没有这个字段。
• 内容跟站内已有页面是不是撞了。同一个主题写了三篇，通常只有一篇能拿到排名，其余两篇进索引也是陪跑。
• 是不是刚发布不久。新站或者权重不高的站，从抓取到出现在结果里隔上几周很正常。

反过来，看到红灯基本可以信，因为阻断信号的判定要么是状态码这种硬事实，要么是规则匹配这种可复算的逻辑。唯一需要复核的红灯就是上面说过的X-Robots-Tag带前缀那一种。

还有哪些掉索引的原因，六项信号一个都查不出来？

这六项查的是“有没有人明确禁止收录”。而现实里有一大类掉索引，根本没人禁止过，是搜索引擎自己决定不要了。这类原因工具查不出来，但恰恰是绿灯之后最该往下想的方向。

软404。页面返回200，内容却是“没有找到相关商品”或者一个空列表。状态码骗得过工具，骗不过搜索引擎——它会按内容判定这是个错误页，然后当成404处理。电商站的下架商品、搜索结果页、空标签页最容易变成这种。判断方法是把页面的正文部分单独看一眼，如果一个不知情的人打开会觉得“这页什么都没有”，那它多半已经被判成软404了。

被判为重复而合并。Google会自己选规范页，你的canonical只是众多参考因素之一。当站内有多个高度相似的页面时，它可能把你想要的那一页归到另一页名下。这种情况下工具会显示canonical自指、一切正常，而实际收录的是另一个地址。要确认只能靠Search Console的网址检查，那里会明确告诉你“Google选择的规范网址”是哪一个。

内容质量不够门槛。抓了、也进了索引，过一段时间又被清出去，这在大量自动生成的页面上很常见。参数组合页、按城市批量生成的落地页、只有几十个字的标签页，都是高危对象。这一层没有任何技术信号可查，只能从内容本身下手。

抓取预算耗在了没价值的地址上。站点规模上去之后，爬虫的时间是有限的。如果它每天大半的请求都花在筛选参数、日历翻页、无限滚动生成的地址上，真正重要的新页面就得排队。工具查单页正常，但整站的抓取节奏已经出了问题——这一层要看日志，看爬虫到底把请求花在了哪里。

所以完整的排查顺序应该是两段式：先用工具确认没有硬阻断，再往内容、重复、预算这三层去找。前一段有明确答案，后一段需要判断力，但顺序不能颠倒——在信号层还没排除的时候讨论内容质量，纯属浪费时间。

多语言站体检要多盯哪一项？

做外贸和出海的站，页面往往一式多份，中英法德各一套。这类站用可索引性体检时，有一项要单独盯：hreflang的自引用。

工具会把页面里所有的hreflang标注列出来，并检查里面有没有一条指向页面自己。缺自引用时它给出的提示是“多语言组会被判为无效”。这个提示的方向是对的——按Google的要求，每一个语言版本都必须把包括自身在内的全部替代版本列全，少了自引用，整组标注的可信度就打折。

但前面说过，工具做的是严格字符串比对。这意味着几种写法差异都会被误报成缺自引用：

• hreflang里写的是带www的地址，页面实际访问的是裸域。
• hreflang里带尾斜杠，页面地址不带，或者反过来。
• hreflang里是http，页面已经全站升到https。
• 主机名大小写不一致，前面那节说过的老问题。

这几种情况里，第一到第三种其实是真问题，值得改——Google确实建议整组标注用完全一致、且是各语言版本最终地址的写法，跳转地址和替代写法都会增加匹配失败的概率。只有第四种是纯误报。

实操上的建议是：多语言站不要只体检一个语言版本。挑三个语言版本各跑一次，把每一次输出的hreflang清单摆在一起比对，看它们是不是同一组地址、写法是不是一字不差。这个动作两分钟能做完，比出问题之后回头查一整套模板要划算得多。

还有一个多语言站特有的坑：有些站的语言切换是靠地域跳转做的，同一个地址对不同来源IP返回302到不同语言版本。工具的服务器在国内，它看到的永远是这个IP对应的那一份。测这类站时，工具能告诉你“这里有一个302”，但跳到哪里不代表Googlebot会跳到哪里。

掉索引应该按什么顺序排查？

把上面这些拼起来，就是一套可以照着走的顺序。这套顺序的逻辑是“先查不可见的，再查可见的”——因为可见的问题你自己早就看见了，能拖到需要排查的，往往都藏在看不见的地方。

改版和迁移之后最容易出事的是前三项，而且这三项有个共同特点：在页面上没有任何可见痕迹。新服务器的配置里带了一行noindex响应头、测试环境的robots.txt被一起发到了生产、CDN把某个目录整体拦了——这些都不会让页面看起来有任何异常。

保哥经手过一次跨境健身器材站的掉收录，页面正常、内容正常、sitemap正常，查到第三天才发现是CDN的一条边缘规则给整个产品目录加了noindex响应头。那次之后我们团队的排查清单就改成了先看响应头再看页面，顺序一换，同类问题的定位时间从天级降到分钟级。

独立站的哪几类页面最该定期体检？

把工具当成一次性的救火队用，收益有限。真正划算的用法是圈出几类高风险页面，改版后、上新后、换主题后各跑一遍。做电商和外贸独立站的，下面这几类值得列进固定清单。

分面筛选与排序参数页。这是重复内容与抓取预算的重灾区。正常做法是让筛选组合页保持可抓但把canonical指向主分类页，或者干脆用robots挡掉参数路径。两种做法各有取舍，但最怕的是两种都做了一半——canonical指向主页面的同时又被robots拦住，爬虫读不到那个canonical，归属关系永远建立不起来。用工具跑一个典型的筛选地址，两栏一起看，一眼就知道当前是哪种状态。

商品变体页。颜色、尺码各自一个地址的站，变体页通常应该把canonical指向主商品页。程序生成的canonical出错时，常见症状是全部变体指向同一个不存在的地址，或者指回自己导致大量近似重复。这一栏工具查得很准，值得每次上新后抽查几条。

缺货与下架页。下架商品该返回什么状态码，取决于它还回不回来。短期缺货保持200并说明补货时间；永久下架且有替代品的做301；彻底没了的用410。最糟的是返回200却渲染一个空白页面，或者跳转到首页——后者会让搜索引擎把这一批地址判成软404。工具能把最终状态码和跳转链一次给你看全。

分页序列。第二页往后的列表页要不要收录，各家策略不同，但至少要保证策略一致。常见事故是分页被noindex，同时又被当成通往深层商品页的唯一通道——爬虫顺着走进来，看见noindex掉头就走，深层商品自然抓不到。

促销落地页。活动期建站、活动后遗弃，是掉索引和死链的主要来源之一。活动结束后如果不处理，这批页面通常既没有内链也没有更新，属于典型的负资产。

保哥给一家做户外装备的独立站定过一份很朴素的检查节奏：每次上新后抽五个商品页和两个筛选页，每次改版后把这五类各跑一遍。工具本身就三十秒的事，难的是把它变成流程里固定的一步而不是出事之后的补救。

四个反直觉结论怎么记？

前面拆的四处判定偏差，光看一遍很难记住。把它们整理成“看到什么现象、该做什么动作”的形式，用起来更顺手。

规律其实挺清楚：凡是“没发现问题”的结论，都要留一分怀疑；凡是“发现了问题”的结论，先看它给出的原始值。这款工具的可贵之处在于它把原始值全都打出来了，没有藏在结论后面——只要你养成看原始值的习惯，上面这些偏差就都伤不到你。

它的边界在哪里，该配合哪些工具用？

这款工具明确做不到的几件事

把能力和边界说清楚，工具才用得踏实。这几条是它明确做不到的：

• 不执行JavaScript。抓到的是服务器返回的原始HTML。前端脚本注入的canonical、meta robots，这里一律看不见。好消息是搜索引擎首轮抓取看到的也正是这份原始HTML，所以这个限制反而让你看到了爬虫第一眼看到的样子。
• 不查这一页是否已在索引中。要确认这件事只能用Search Console的网址检查，那需要站点所有权验证，第三方工具做不到。
• 只支持公网地址。内网、本地地址、需要登录的页面都会被直接拒绝，这是防止服务端请求伪造的必要限制。
• 响应体积统计的是传输字节。它接受压缩传输，所以显示的大小是压缩后的，不是解压后的HTML真实体积。判断页面是不是过大时要留意这个口径差。
• 重定向链最多跟8跳。超过就报错退出。真实场景里超过3跳就该合并了，这个上限一般碰不到。

还有一条不算限制但值得知道：它每次只查一个地址。想批量体检得自己一条条来，这时候更合适的做法是先用日志或者爬虫软件圈出可疑的一批，再用它逐个确认细节。

配合哪些工具一起用效果更好？

可索引性只是收录链条的一环，前后各有一段路。

往前一环是robots.txt本身。你如果正在改规则，先在robots.txt生成器与验证器里把文件本身的语法和通配符逻辑过一遍，再用可索引性体检去验单个页面的实际判定结果，两边对得上才算稳。

往后一环是页面被发现的能力。一个页面就算所有许可信号都放行，站内没有任何链接指向它，抓取优先级依然低。这一层可以用孤岛页面检测的抽样口径去看看它在站内的入链情况——那篇里也拆了那款工具的数据口径，别拿它的数字直接下结论。

如果你要排查的是整批页面的头部标签质量，而不只是能不能收录，网页Head标签检查器覆盖的字段更全，两者的定位不冲突。

常见问题解答

工具说可以被收录，为什么搜索不到？

可索引是必要条件不是充分条件。它只保证没有信号在阻断收录，不保证爬虫已经发现这个地址、判定内容值得存进索引、并且给了排名。绿灯之后该查的是站内入链、sitemap覆盖、内容是否与站内其他页面撞题，以及页面发布了多久。

页面源码里明明有noindex，为什么工具说未设置？

大概率是meta标签的属性顺序反了。工具的提取正则要求name属性出现在content属性之前，写成content在前的话读不到值，会显示未设置并放绿灯。遇到这种矛盾，直接在源码里搜noindex这个词为准。

X-Robots-Tag报了noindex，一定是出事了吗？

不一定。这个响应头可以带爬虫名前缀，只对指定爬虫生效。工具不解析前缀，只要字符串里有noindex就判为阻断。看一眼原始值，如果冒号前面写的是别的爬虫名，那条红色结论对Googlebot不成立。

重定向链最后显示404，可信吗？

要看目标写法。目标是完整网址或以斜杠开头的绝对路径时可信；目标是相对路径时不可信，工具会把它解析到网站根目录，得到一个并不存在的地址。这种情况用浏览器实地走一遍才作数。

robots.txt返回500的时候，工具说全部允许对吗？

不对。RFC 9309把5xx归为不可达状态，要求爬虫必须假定完全禁止抓取，只有这种状态持续很久之后才可以改按不可用处理。工具把4xx和5xx放在同一个分支里当作允许，方向与规范相反。

canonical只是域名大小写不同，为什么被判成指向别处？

工具用的是去掉尾斜杠后的字符串比较，没有做主机名大小写归一。按RFC 3986，scheme和host大小写不敏感，这属于正常的自指canonical。同样的比较方式也用在hreflang自引用检查上。

robots屏蔽加noindex是不是双保险？

恰恰相反，等于什么都没做。爬虫被robots挡在门外就永远读不到noindex，页面反而可能因为外链而以无摘要的形式出现在结果里。正确顺序是先放开robots让爬虫读到noindex，等确认掉出索引之后再考虑封路。

它能替代Search Console的网址检查吗？

不能，两者定位不同。它查的是“这一页有没有被什么挡住”，不需要站点所有权，任何地址都能查，也能查竞品；网址检查查的是“Google那边现在是什么状态”，能看到实际收录情况和渲染结果，但只能查自己验证过的站。排查时先用前者定位阻断信号，再用后者确认索引状态。

权威参考资料