页面能打开，怎样判断它是否已被 Google 收录？
一篇文章构建成功，中文和日文地址都返回 200，首页也出现了入口。此时说“已经发布”很有把握；说“Google 已经收录”却跨过了一个看不见的步骤。网页由我们自己的服务器提供，搜索索引由搜索服务维护，前一件事成功不会自动证明后一件事完成。
今天用谷米博客做一次公开、可复查的检查。它不是替网站宣布搜索排名，也不是从流量推断 Google 的内部状态。问题更具体：一个站长手里有哪些证据，各能支持到哪一步？ 检查时还发现两个确实失效的页面头部地址；我修正了这些公开信息，再区分“修好了信号”与“确认了收录”。
1. 先把“上线”拆成四个不同的问题
本地构建能证明源文件可以生成页面。公网请求能证明某个访问者在检查时取得了这个 URL 的响应。robots.txt、站点地图、页面头部和站内链接，能让我们检查是否向爬虫提供了可发现、可读取的线索。最后，是否已经进入 Google 的索引，是 Google 自己的记录。
这四层并不互相替代。Google 的说明把流程概括为发现与抓取、索引、在具体搜索中提供结果；并明确说即使符合基本要求，也不保证每个页面都会被抓取、索引或展示。Google Search Central：搜索如何运作
如果一个刚部署的页面返回 404，先修部署，暂时不用讨论内容质量。反过来，如果页面、地图、可抓取性都检查过，也只能说清除了一部分障碍；不能把这组公开测试伪装成“已收录”的截图。这条证据边界决定了排查顺序。
2. 一次有明确范围的现场检查
我在 2026 年 9 月 30 日、新稿发布前，从公网检查了 9 月 29 日的中文文章和对应日文文章。工具是 macOS 上的 Python 3.9.6 标准库；没有登录 Google，也没有请求公司的其他站点。完整公开信号检查脚本可以下载，使用两个同源 HTTPS 文章地址，不需要安装第三方包。
python3 search-discovery-audit.py --self-test
python3 search-discovery-audit.py \
https://gumi.ink/posts/2026-09-29-when-should-http-requests-retry/ \
https://gumi.ink/ja/posts/2026-09-29-when-should-http-requests-retry/第一条命令用固定样本验证解析器能识别正常页面头部、noindex 与缺失的规范地址，以及带 XML 命名空间的站点地图。第二条才请求公开网站。脚本会读取两篇文章、robots.txt、其声明的站点地图及页面头部声明的链接；单个响应最多读取 2 MB，最多跟随五个站点地图文件。它用 Python 的 robots 解析器模拟一次规则判断，不冒充 Googlebot 的实际抓取。
修复前观察到的不是“一切正常”，也不是“肯定没有收录”：
| 公开证据 | 修复前的实际结果 | 可以得出的结论 |
|---|---|---|
| 两篇文章 HTTP 状态 | 均为 200，语言分别为 zh-CN、ja-JP | 地址在当时能由公网读取 |
robots.txt | Allow: /，指向 sitemap-index.xml | 声明了一条可访问的地图入口 |
| 站点地图 | 索引指向 sitemap-0.xml；两篇 URL 都列在其中，并互相标为语言版本 | 网站提供了发现和语言关联线索 |
| 页面头部的地图链接 | 指向 /sitemap.xml，实际为 404 | 页面自己声明了一条坏链接 |
| 页面头部的 RSS 链接 | 指向 /feed.xml，实际为 404 | 页面宣称有一个并不存在的订阅源 |
| 规范地址和分享地址 | 无 canonical；两篇的 og:url 都写成首页 | 页面身份信息不准确或不完整 |
| Google 是否收录 | 本次没有读取 Search Console | 未知 |
这里最容易误判的是两个不同的地图地址：robots.txt 指向的真实地图是可用的，坏掉的是 HTML 头部另一条 /sitemap.xml 链接。因此，坏链接值得修，却不能据此宣称 Google 完全找不到这些文章。同样，RSS 链接失效直接影响想订阅的读者，也不能被拿来证明文章没有进入搜索索引。
3. 地图提供线索，不签发“收录证明”
站点地图最适合回答：“网站主动列出了哪些希望被发现的 URL？”谷米的地图索引包含一个实际地图，后者在检查时列出了包括这两篇文章在内的地址；双语对也带有 zh-CN 和 ja-JP 的对应关系。我们可以解析 XML，核对目标 URL 是否真的在 <loc> 中，而不是只看 /sitemap-index.xml 返回 200 就下结论。
Google 的站点地图文档把提交地图称为提示：这不保证 Google 会下载地图、抓取每个 URL，更不保证收录。内链也是发现路径；若新文章只存在于一个孤立文件、列表和其他页面都不链接它，不能只因为地图存在就假定它已经被访问。Google Search Central：创建并提交站点地图
这次两篇旧文章在站点地图中，博客首页还链接近期文章。这样的证据把“页面在部署时丢失、地图完全漏列”的可能性缩小了；它没有告诉我们 Google 何时读过地图。真正要看 Google 处理地图的情况，需要对应站点的 Search Console 报告。公开 XML 和所有人都能运行的检查脚本没有这个权限。
4. 200、robots 与 noindex 回答的是不同问题
robots.txt 告诉爬虫哪些路径可抓取；noindex 可以放在页面的 robots meta 标签或响应头，告诉支持该规则的搜索引擎不要收录。关键的反直觉处在于：如果先用 robots.txt 禁止抓取，Google 可能根本看不到页面里的 noindex。所以不能把 Disallow 当成可靠的“禁止索引”开关。Google Search Central：noindex
本次工具检查了 HTTP 状态、X-Robots-Tag 和头部的 robots、googlebot meta；在两篇样本里，没有读到 noindex，Python 的 robots 解析器也判定 Googlebot 可以访问。读者可以改脚本中的目标 URL，检查自己的文章是否出现直接的技术阻碍。
但这仍不是 Googlebot 从自己的网络环境成功访问的记录。服务器可以因访问来源、速率、时间或额外规则给不同客户端不同响应；JavaScript 渲染后的内容，也不是这段只读取原始 HTML 的脚本所能检查的范围。遇到“脚本看着正常、搜索平台仍报告抓取错误”，下一步应看 Search Console 的具体抓取和实时测试，而不是反复改变关键词。
5. 双语文章不该共用一个“代表地址”
谷米同一主题有中文和日文两份完整正文，各有自己的 URL。检查前，它们的 HTML 没有 canonical，而 og:url 全部指向首页。og:url 主要服务分享时的页面身份，它错成首页是一条可证实的模板错误；不能因此直接推断搜索排名受到怎样的影响。
本次模板修正采用每页自己的规范地址：中文指向中文，日文指向日文，同时让 og:url 与当前文章地址一致。不是把日文统一规范到中文首页或中文文章。Google 把规范地址视为偏好信号，最终仍可能选择不同版本；它也建议有 hreflang 时优先提供相同语言的规范地址。Google Search Central：指定规范地址
站点地图原本已经为这组文章列出了互相指向的语言版本。Google 接受在 HTML 头部、HTTP 响应头或站点地图中提供语言版本注释；这次没有为了“多加一处”而复制相同的 hreflang 设置到页面头部。保持一种已核对的映射，比让两套映射以后发生冲突更容易维护。Google Search Central：本地化页面版本
代码改动集中在博客共用模板，核心是根据当前路径生成页面地址，并修正公开链接：
const canonicalUrl = new URL(Astro.url.pathname, 'https://gumi.ink').href;
<meta property="og:url" content={canonicalUrl}>
<link rel="canonical" href={canonicalUrl}>
<link rel="sitemap" href="/sitemap-index.xml" type="application/xml">原先指向 404 的 RSS 声明已经移除。没有真正生成 /feed.xml，就不应继续向订阅软件广告它的存在。这是对错误声明的修复，不是建立了新的订阅功能，也不是对抓取频率的承诺。
6. 哪一项检查才回答“Google 已经收录”？
如果拥有对应站点的 Search Console 资源，使用 URL 检查工具，输入文章完整地址，看 Google 索引中的版本、抓取情况及 Google 选出的规范地址。再切换“测试实时网址”，看当前页面能否被访问和解析。两种视图针对不同时间：索引结果是 Google 已保存的状态，实时测试针对目前的页面；实时测试通过也不保证会被纳入索引。Search Console：URL 检查工具
这次没有访问该资源，所以既不能写“谷米已被收录”，也不能写“谷米未被收录”。公开脚本的输出特意保留 googleIndexStatus: unknown: Search Console not queried。修好模板、重新部署并验证公开页面，只能把技术层面的已知错误关掉；真正的索引状态仍需在拥有权限的报告中核对。
另一个常见捷径是搜索 site:gumi.ink，看能否找到文章。Google 自己提醒，已收录的 URL 也不一定出现在某次 site: 查询结果中；搜不到时，应使用 URL 检查工具进一步判断。把一次搜索结果页当成完整的索引清单，会重复犯“可见现象等于内部状态”的错误。Google Search Central：site: 搜索运算符
即使工具显示某页已被收录，它也未必会对你想到的关键词展示。那还涉及查询意图、页面主题、语言、内容质量等，不是再补一个 canonical 或再次提交地图就能证明改善的。本次现场检查只处理能直接验证的公开信号。
7. 按证据决定下一步，而不是重复“提交”
如果 URL 本身返回 404，或部署后的实际正文不是想发布的内容，先修构建、发布路径与服务器。若页面 200，但地图漏列或站内根本找不到入口，再检查路由、内链和地图生成。若 Google 的报告明确显示抓取受阻，回到 robots、访问控制、响应状态和具体抓取错误。若已经抓取却未收录，则应结合报告中的原因看重复页面、规范地址与正文价值，而不是假设发文频率不够。
还有一种情况是已收录但很少被读到。那时要看具体查询、落地页和读者行为，再讨论文章回答的问题是否清楚。单靠“今天访客少”无法反推抓取失败；同样，技术信号全部通过，也不能推出内容已经满足读者。测量对象变了，处理方法才应随之改变。
此次可复现脚本只检查两个同源 HTTPS 地址，站点地图文件数有上限，robots 判断使用 Python 标准库而非 Google 的实现，也不运行页面 JavaScript。它适合作为发布巡检的一部分，不是爬虫模拟器，更不是搜索排名检测器。修正前的失败样本与修正后的两种语言页面，都留在脚本输出里可重新检查。
最终答案很简单，却需要守住证据的边界：页面能打开，证明一次公网访问成功；地图和指令正确，证明网站提供了可发现、可抓取的线索；是否收录，要看搜索引擎自己的记录。 把这几句话分别写进检查报告，比一个笼统的“SEO 正常”更能指导下一次修复。
外部文档和公开网站检查日期：2026 年 9 月 30 日。文中“修复前”的数据来自当天部署前的公网请求；修复后的说明以本次部署与复查为准。