2026-09-20 我们把 robots.txt 声明的四张 sitemap 全量 47 条 URL 用 Googlebot UA 逐条扫了一遍：非 200 为 0、带 noindex 为 0。但同一天 GSC 报的 6 条 404，没有一条落在这 47 条里——出问题的全在 sitemap 之外。本文把这 6 条分成三类定性，讲清「索引面」和「被引面」为什么不是一回事，并给出可照抄的四步自查与两个会让你读出假结论的坑。
做 GEO 的人几乎都会先问一句：我的内容，AI 引擎到底能不能拿到？
这问题通常被翻译成一串配置动作——放行 AI 爬虫、写对 robots、提交 sitemap。这一层我们写过专门的配置指南（见文末延伸阅读），本文不重复，只答之后那半个问题：配好了，怎么验？验出来长什么样？
我们拿自家的站做了一次，结论挺反直觉：
sitemap 全绿，不代表站点没问题——出问题的，全在 sitemap 之外。
很多人把「被搜索引擎收录」和「被 AI 引擎引用」当成一件事的两种说法。二者相关，但看的 URL 集合大小不同：
三个面不重合，是本文所有麻烦的来源。一条历史地址现在返回 404，它在「你声明的面」上根本不存在——扫 sitemap 一万遍也扫不出来；但它在引擎记着的面上活得好好的，一旦出现在某个 AI 回答的引用位上，用户点过去拿到的就是 404。
所以自查只扫 sitemap 不够，必须把引擎那侧的失败面拉过来对账。
口径写死，下面每个数字都按它读：
| 项 | 值 |
|---|---|
| 执行方 | 苏州智码航科技有限公司（自有站点自查，利益相关先摆这里） |
| 时间 | 2026-09-20（PDT） |
| 对象 | 自有域名 zhimahang.com 及其子路径站点 |
| 站点侧方法 | 取 robots.txt 声明的全部四张 sitemap，带 Googlebot UA 逐条请求，同时扫 noindex |
| 站点侧样本量 | 四张合计 47 条 URL，全量，无抽样 |
| 工具 | 本机 curl（mac 本地执行），非第三方 SaaS 读数 |
| 引擎侧方法 | Google Search Console（资源 sc-domain:zhimahang.com）后台读数 |
| 引擎侧区间 | 2026-06-27 ~ 2026-09-18，⚠️ 报表滞后约 2 天，⛔ 不能拿它判 09-19/09-20 的动作 |
⚠️ 两侧不是同一时刻的快照：站点侧是 09-20 当晚的实时请求，引擎侧是截至 09-18 的报表。对账必须记住这个时差，否则容易把「引擎记的旧快照」误读成「站点现在坏了」。
四张 sitemap 逐张拆：
| sitemap | URL 数 | 非 200 | 带 noindex |
|---|---|---|---|
/yinjen/sitemap.xml | 33 | 0 | 0 |
/sitemap.xml | 2 | 0 | 0 |
/stride/sitemap.xml | 5 | 0 | 0 |
/sail/sitemap.xml | 7 | 0 | 0 |
| 合计 | 47 | 0 | 0 |
口径重复一遍：2026-09-20 本机实测、Googlebot UA、四张 sitemap 全量 47 条、非 200 为 0、noindex 为 0。
扩面这步不能省：上一期（2026-09-13）只扫了 /yinjen/sitemap.xml 那 33 条，因为那是「内容那张」；本期才把四张全扫。robots 声明几张就得扫几张，只扫一张等于默认另外三张没问题。
到这一步，站点侧全绿。然后麻烦才开始。
同一份 GSC 报表（数据区间 2026-06-27 ~ 2026-09-18）里：
「未编入 25」单看没有意义，必须按原因拆：
| 原因 | 条数 | 我方判读 |
|---|---|---|
| 未找到 (404) | 6 | 🔴 逐条定性，见第五节 |
| 网页会自动重定向 | 9 | 未逐条取 URL（本期没做，如实记） |
| 被「noindex」标记排除了 | 1 | 已处置，见第六节 |
| 备用网页（有适当的规范标记） | 1 | 🟢 预期行为，不是故障，见第七节 |
| 已抓取 - 尚未编入索引 | 7 | Google 系统侧，未逐条取 URL |
| 被屏蔽（401 未授权请求） | 1 | 🟢 API 子域返 401 是正确行为，不需要修 |
| 重复网页，用户未选定规范网页 | 0 | — |
| 已发现 - 尚未编入索引 | 0 | 🟢 抓取侧无积压 |
6+9+1+1+7+1 = 25，与头数自洽。
「未编入索引」本身不是健康指标。 上表至少两格（规范标记归并 1 条、401 那 1 条）是我们希望它就长这样的；0 条「已发现-尚未编入索引」反是好消息。⇒ 把 25 当成「25 个待修的 bug」是最常见的误读：它是分类表，不是任务清单。
更正（2026-09-23）：本节初版把 A、B 两类判为「站内某个环节正在生成不存在的 URL」，依据是它们的上次抓取日期很新（09-18）。发布后我们逐条查了服务器访问日志和站内代码历史，这个判据和结论都不成立：B 类那条 -en 地址 2026-06-28 真实上线过、随后撤下，是历史残留；A 类两条在站内当前找不到任何来源。Google 对撤下已久的地址同样会定期重试，「抓取日期新」不能说明站内还有来源。本节与第九、十、十一节已按查证结果改写。本次自查信息量最大的一格，逐条列出（「上次抓取」为 GSC 记录日期）：
| # | URL | 上次抓取 | 类别 |
|---|---|---|---|
| 1 | zhimahang.com/$ | 2026-09-18 | 🟡 A 类：带字面量 `$`，站内当前无来源 |
| 2 | yinjen.zhimahang.com/$ | 2026-07-30 | 🟡 A 类：旧子域 ＋ 同样带 `$` |
| 3 | zhimahang.com/yinjen/articles/geo-conversion-tracking-en | 2026-09-18 | 🟡 B 类：短暂上线过、已撤下的旧地址 |
| 4 | zhimahang.com/developers | 2026-09-03 | 🟡 C 类：缺 `/yinjen` 前缀的历史地址 |
| 5 | zhimahang.com/articles/public-geo-experiment-issue-2 | 2026-09-01 | 🟡 C 类：同上 |
| 6 | zhimahang.com/about | 2026-07-22 | 🟡 C 类：同上 |
三类要分开定性——成因不同，查法也不同。
$（2 条）/$ 不是正常路径。第一反应是模板变量没被求值就输出了——${...} 这类占位符只剩一个 $ 漏了出来。
但这只是假设，要拿站内证据验。我们对全站当前的页面链接、四张 sitemap、结构化数据（JSON-LD）和 llms.txt 逐一检索，没有任何一处产出 `/$`；站内代码与提交历史里也没有这个字面量链接。在我们留存的服务器访问日志里（主域自 2026-06-06 起），zhimahang.com/$ 第一次被请求是 2026-07-07（PDT），来自 Google 的 GoogleOther 抓取器，没有来源页（Referer）。
⇒ 判读：站内当前无来源；最初是从哪里被发现的，未定位。 对不存在的地址返回 404 是正确响应，⛔ 不为了让报表变干净去做跳转。
geo-conversion-tracking-en 看上去像是在真实存在的 geo-conversion-tracking（讲 GEO 转化链路埋点那篇）末尾多拼了个 -en——本文初版就是这么判的。查访问日志后，这个判断被推翻：这个地址 2026-06-28（PDT）真实上线过、返回 200，Google 的抓取器当时就来访问过。那时我们的发布流程让英文版单独发一条 -en 后缀的文章，随后改成「同一条文章 ＋ ?lang=en」，这条随即撤下——存活至少约 7 分钟、不超过约 1 小时 41 分钟，确切撤下时刻没有记录。此后它一直返回 404，Google 定期回来重试，GSC 记下的 09-18 就是其中一次。
⇒ 判读：历史残留，不是站内缺陷。
所以 A、B 两类都不是「站内某个环节正在生成不存在的 URL」——本文初版的这个结论不成立。它们和 C 类一样，都属于下面说的第②种。
这三条共同点是缺 `/yinjen` 前缀——站点结构后来改成子路径形态，它们是改之前的老地址。
⇒ 判读：Google 记着的历史 URL ≠ 当前站点故障。 GSC 的 404 列表混着两种东西：① 你现在还在生成、却指向不存在页面的链接——这是缺陷，要修；② 引擎早年记住、现在仍会定期回来再试的老地址——正常，不构成故障。
区分判据是「站内当前还有没有地方产出这条地址」，不是「它 404 了没有」，也不是「上次抓取日期新不新」。 B 类就是反例：撤下将近三个月，09-18 仍被抓取。两类都 404，但只有第一类要动手；查法是对站内当前的页面链接、sitemap 和结构化数据做全文检索，必要时翻访问日志，看这条地址第一次出现在什么时候、有没有来源页。
我们自己就撞上了一次第①种：本文初版末尾「延伸阅读」里的三条站内链接把路径多写了一层 /yinjen，渲染出来的路径里 yinjen 连着出现了两次，一发布就在产出新的 404。按上面的判据做站内检索，直接命中了来源。已修正。被「noindex」排除的那 1 条是 zhimahang.com/geo-check/，GSC 记录的上次抓取 2026-09-02、首次检测 2026-09-04。我们 09-15 已把该页的 noindex 摘掉，本次 Googlebot UA 实测返回 200、noindex 命中 0 ——GSC 报的是 09-02 的旧快照，与站点现状不是一回事。这就是第二节「两侧时差」的实例。
顺着这条查出一个没人登记过的缺口：
`geo-check/` 不在任何一张 sitemap 里。
robots.txt 声明了四张（/sitemap.xml、/yinjen/sitemap.xml、/stride/sitemap.xml、/sail/sitemap.xml），这页一张都没进；GSC 网址检查里「发现 · 站点地图」那栏显示的正是无 / 临时性提取错误。
⇒ 这正是第一节「三个面不重合」的具体形态：一个已经决定开放抓取的页面，在「我们主动声明的面」上不存在，只能靠手工提交进队列，而不是靠 sitemap 被稳定重新发现。已登记为站点改动待办，⛔ 同样不宣布它已改好。
?f= 归因参数被「归并」，是预期行为，不是故障「备用网页（有适当的规范标记）」这一格是本期新出现的，只有 1 条：
| URL | 上次抓取 | 首次检测 |
|---|---|---|
zhimahang.com/?f=yt6 | 2026-09-08 | 2026-09-14 |
?f=yt6 是我方的归因参数链接（区分站外投放的回流来源）。Google 抓到后按规范标记把它归并到主页，因此不单独编入索引——这正是我们想要的结果。归因参数是标记流量来源的，不是让引擎把主页存成 N 个副本。⛔ 不需要修，也不需要点「验证修正情况」——没有东西可修。
🔵 附带一条正面信息：它说明带 `?f=` 的归因链接确实在站外被抓到了，归因层是活的。
⇒ 这一格提醒：GSC 把各种「不编入索引」放在同一标题下，其中一部分是你自己设计出来的。 看到新格子，第一步是判类，不是先去修。
两条都是我们实际踩出来的（坑一在本期 09-20 的扫描里，坑二在上一期 09-13 的扫描里），不写进来，上面所有数字都不可复现。
本次扫描中 zhimahang.com/sail/cases 首轮返回 `000`（连不上/握手失败），重试即 200、noindex 0。本机同类 TLS 瞬断本周共记录 3 次：2 次在 09-20 当晚（本次扫描这 1 次，加同晚的一次线上复核），1 次在 09-17（一次推送接口调用）。
⇒ 判定：本机到站点的瞬时 TLS 失败，不是站点故障。
⇒ 由此定下一条纪律：单条失败必须重试后才判死。 按首轮结果记账，结论就会变成「47 条里有 1 条不可达」——一个纯由本机网络抖动制造的假故障，还会让人去查根本不存在的问题。
⚠️ 这条的射程只到本次这批扫描：它说明的是「我方 09-20 本机网络侧有已知抖动」，⛔ 不构成对站点可用性的一般性结论。
\?，写错会静默全返回 000从 sitemap 里剥 <loc> 标签取 URL，正确写法是：
sed -E 's#</?loc>##g'注意 `-E`（扩展正则）。若在 macOS 自带的 BSD sed 上按 BRE 写成 \?，它不会报错——会把 \? 当字面量，标签剥不干净，拿去请求的「URL」里带着尖括号残片，curl 全部返回 `000`。
⇒ 这是本文里最危险的坑，失败形态是静默的：你会得到一张「47 条全部不可达」的表，看着像重大事故，实际是一行 sed 写错了。⇒ 通用判据：一批结果「整齐划一地失败」时，先怀疑自己的管道，再怀疑被测对象。
不依赖特定工具，命令行跑得完：
noindex 的页面，对索引面等于不存在，只看状态码会漏。第 4 步最容易被跳过，也最有价值。 前三步只证明「我声明的那些还活着」；只有第 4 步能告诉你声明之外还有什么。对账结果一句话说完：
GSC 那 6 条 404 和 1 条 noindex，没有一条落在当前的 47 条 sitemap URL 里。
观察到的： 2026-09-20 本机实测下，四张 sitemap 全量 47 条 URL 在 Googlebot UA 下非 200 为 0、带 noindex 为 0；同期 GSC（区间 2026-06-27~2026-09-18）报已编入索引 68、未编入 25，其中 404 有 6 条，与那 47 条零交集。
判读： 站点「主动声明的那一面」是干净的；GSC 那 6 条 404 全在声明之外，逐条查证后没有一条是站内当前产出的——B 类是 06-28 短暂上线过的旧地址，C 类是改版前的老地址，A 类在站内当前找不到来源。（初版此处判为「指向一个正在产出错误链接的环节」，已更正，见第五节。）
⛔ 以下几件事本文都不成立：
只从 SEO 运维看，本文是一份巡检记录。放到 GEO 语境里，它回答的是更前置的一问：当一个 AI 引擎准备在回答里引用你时，它手上那条 URL 是从哪来的？
不来自你的 sitemap，来自引擎自己积累的那份地址表——里面混着你当前的页面、改版前的老地址、只短暂上线过就撤下的地址，以及来源已经查不到的地址。
所以「被引用」至少要过两道：内容得被选中（大多数 GEO 讨论的焦点），以及那条被选中的地址得真能打开（这道几乎没人查）。第二道失败时，症状不是「没被提到」，而是「被提到了，但点过去是 404」——从提及率读数上完全看不出来，因为提及确实发生了。
这也是我们把它固定成每周一次的原因：真正要修的是站内正在产出的坏链接，它可能随任何一次发布冒出来——本文初版自己就带了三条（见第五节）。每周把新出现的 404 逐条对一遍站内来源，才能尽早发现、尽早修。
出处与口径：站点侧数字来自 2026-09-20（PDT）在 mac 本机用 curl 对我方自有生产站点的实测（Googlebot UA、四张 sitemap 全量 47 条 URL、无抽样）；引擎侧数字来自 Google Search Console 资源 sc-domain:zhimahang.com 后台读数，区间 2026-06-27 ~ 2026-09-18，报表滞后约 2 天。第五节 A、B 两类的查证另用了我方服务器访问日志（主域自 2026-06-06 起留存）与站内代码提交历史，查证日期 2026-09-23（PDT）。边界见第十节。
苏州智码航科技有限公司的引见 YinJen（zhimahang.com/yinjen）：桌面应用，覆盖 12 个 AI 引擎，Visibility Score 打分，段落级优化建议。创作者版 ¥29.9/月，14 天免费试用。
本文数据来自作者所属公司对自有站点的一次自查（站点侧为 2026-09-20（PDT）本机 curl 实扫，引擎侧为 Google Search Console 后台读数），文字由 AI 辅助创作、作者审校发布。
Data in this article comes from a self-check of the author's company's own website (site side: local curl requests on 2026-09-20 PDT; search-engine side: Google Search Console readings). The text was drafted with AI assistance and reviewed by the author before publication.
-en 旧地址，就是它当年单独发过、随即撤下的英文版）引见(YinJen)的生成式引擎优化(GEO)研究与实战团队,长期监测内容在 ChatGPT、Claude、Gemini、Perplexity、豆包、DeepSeek 等主流 AI 引擎中的引用与可见度。本系列均为一手实操记录。
了解引见如何帮你做 GEO →