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」是最常见的误读：它是分类表，不是任务清单。
本次自查信息量最大的一格，逐条列出（「上次抓取」为 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 类：站上从来没有过的 slug |
| 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 条）/$ 不是正常路径，正常的链接生成流程产不出这个形状。它更像模板变量没被求值就输出了——${...} 这类占位符只剩一个 $ 漏了出来。
关键在日期：zhimahang.com/$ 上次抓取是 2026-09-18，很新。⇒ 某处正在产出错误链接，不是历史残留：历史残留的特征是抓取日期越来越旧（如那条 07-30 的旧子域），而不是本月还在被抓到新的。
geo-conversion-tracking-en 从未在我们站上存在过。英文版走 ?lang=en 查询参数，不存在任何 `-en` 后缀的 slug 形态。上次抓取同样是 2026-09-18。
⇒ 这不是「删掉的老页面」，而是一个被拼出来的地址——正确的 slug 是站上真实存在的 geo-conversion-tracking（讲 GEO 转化链路埋点那篇），末尾多拼了个 -en。
A、B 两类合看指向同一结论：站内某个环节正在生成不存在的 URL。 这是本次自查唯一一条「站点侧真缺陷」线索，也是它区别于单纯扫 sitemap 的全部价值——这三条，一条都不在那 47 条里。
⇒ 处置：不销账，登记为「疑似链接生成缺陷，待定位来源」，追查方向是 GSC 该 URL 详情页的「引荐来源网页」＋ 站内全文检索。⛔ 不宣布它已修好。
这三条共同点是缺 `/yinjen` 前缀——站点结构后来改成子路径形态，它们是改之前的老地址。抓取日期分别是 09-03、09-01、07-22，没有一条在本月持续变新。
⇒ 判读：Google 记着的历史 URL ≠ 当前站点故障。 GSC 的 404 列表混着两种东西：① 你现在还在生成、却指向不存在页面的链接——这是缺陷，要修；② 引擎早年记住、现在仍会定期回来再试的老地址——正常，不构成故障。
区分判据是「上次抓取日期还在不在变新」，不是「它 404 了没有」。 两类都 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 条零交集。
判读： 站点「主动声明的那一面」是干净的；问题全在声明之外——带字面量 $ 的地址与不存在的 -en slug 各有一条在 09-18 仍被抓到，指向一个正在产出错误链接的环节。
⛔ 以下几件事本文都不成立：
只从 SEO 运维看，本文是一份巡检记录。放到 GEO 语境里，它回答的是更前置的一问：当一个 AI 引擎准备在回答里引用你时，它手上那条 URL 是从哪来的？
不来自你的 sitemap，来自引擎自己积累的那份地址表——里面混着你当前的页面、改版前的老地址，以及某个模板不小心生成出来、从来没存在过的地址。
所以「被引用」至少要过两道：内容得被选中（大多数 GEO 讨论的焦点），以及那条被选中的地址得真能打开（这道几乎没人查）。第二道失败时，症状不是「没被提到」，而是「被提到了，但点过去是 404」——从提及率读数上完全看不出来，因为提及确实发生了。
这也是我们把它固定成每周一次的原因：A、B 两类「正在产出的缺陷」，判据是抓取日期还在不在变新，而这个判据必须有历史读数才能用——只做一次，你分不清哪条是新的。
出处与口径：站点侧数字来自 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 天。边界见第十节。
苏州智码航科技有限公司的引见 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.
引见(YinJen)的生成式引擎优化(GEO)研究与实战团队,长期监测内容在 ChatGPT、Claude、Gemini、Perplexity、豆包、DeepSeek 等主流 AI 引擎中的引用与可见度。本系列均为一手实操记录。
了解引见如何帮你做 GEO →