三周前发了一篇文章，Google 搜不到。你敲了 site:你的域名/这个 slug/，零结果。Search Console 显示「URL is unknown to Google」或者「Discovered - currently not indexed」。下面是我实际在用的排查顺序，从 5 分钟搞定的配置问题，一直排到「这是几个月的内容问题」。从上往下走，遇到第一个不通过的步骤就停下来修。
一句话总结
- 先跑 URL Inspection。实时测试里的「Crawl allowed?」和「Indexing allowed?」两行，10 秒就能解决大多数配置 bug。
- 接着按顺序查：sitemap 里有没有、有没有内链、HTML 是不是服务端渲染的、canonical 标签、Crawl Stats 趋势。
- 「Discovered - currently not indexed」几乎都是爬取优先级问题，不是 bug：Google 知道这个 URL 存在，只是还没判断它值得爬。
- 重复申请收录没有任何用。手动配额大约是每个资源每天 10-12 个 URL（截至 2026 年 6 月）。
- 如果第 1-6 步都过了，又等了 30 天，那要修的是站点权威和内容质量，不是某个设置。没有更快的路。
到底是什么原因
Google 不爬新页面，原因分三类：
| 原因 | 占比 | 修复速度 | 在哪发现 |
|---|---|---|---|
| 配置屏蔽（robots、noindex、canonical 写错） | 约 5% | 几分钟 | URL Inspection 实时测试 |
| 不在 sitemap 或没有内链 | 约 25% | 几小时 | sitemap 文件 + 代码库 grep |
| 爬取优先级 / 站点权威低 | 约 70% | 几周到几个月 | Crawl Stats 趋势 + 页面质量 |
多数独立开发者在前两类上耗几个小时，却从不正视第三类。这个区分很关键，因为修法完全不同：配置 bug 是一行代码的事，而爬取优先级低是内容和链接的问题，Search Console 里没有任何按钮能抄近路。
把两个状态分清楚也有帮助。Discovered - currently not indexed 是说 Google 发现了这个 URL（通常是通过 sitemap），但还没去爬，这是爬取预算的信号。Crawled - currently not indexed 更严重：Google 抓取了页面、读了内容、然后选择不收录，这指向内容质量或重复问题。本清单针对前一种；后一种看文末的链接。
怎么确认是这个问题
- 几周前发的新页面，
site:查询里搜不到。 - Search Console 报「URL is unknown to Google」或「Discovered - currently not indexed」。
- 同站的老页面收录正常。
- Crawl Stats 报告显示整体爬取活动稳定，只是不爬这些 URL。
如果老页面也在掉，那是另一种（全站）问题，本清单修不了。
排查清单
按顺序走。修一处然后等，比一次改五处、不知道是哪条管用要快。
1. 跑 URL Inspection 实时测试
在 Search Console 顶部的检查栏粘贴 URL，点 Test Live URL。读两行：Crawl allowed? 和 Indexing allowed?。任一显示 No，就是配置 bug。常见元凶：
/robots.txt里有一条Disallow规则匹配到了这个路径。- 页面上有
<meta name="robots" content="noindex">标签，或者X-Robots-Tag: noindex这个 HTTP 头。 - canonical 指向了别的 URL（第 5 步讲）。
修好 bug，点一次 Request Indexing，继续往下。别因为这步太基础就跳过。它 10 秒就能抓到最常见的故障，很多人偏偏耗一下午才想起来跑它。
2. 确认 URL 在 sitemap 里
在浏览器里打开 /sitemap.xml，搜 slug。不在的话，bug 就在你的 sitemap 生成器。sitemap 里只放 200 OK、canonical、可收录的 URL：塞满重定向、404、noindex 页面的 sitemap 会浪费爬取预算、稀释信号。修好之后，到 Search Console 的 Sitemaps 重新提交。
有两个属性值得弄对（截至 2026 年 6 月）：
| 属性 | Google 用不用？ | 该怎么做 |
|---|---|---|
<lastmod> | 用，前提是一直且可验证地准确 | 设成真实的最后修改日期；别给没改过的页面每天刷新 |
<priority> | 不用，忽略 | 删掉，没用 |
<changefreq> | 不用，忽略 | 删掉，没用 |
假的或每天乱跳的 lastmod 比不写还糟。Google 会拿它跟页面真实的修改历史对比，对不上就不再信这个值。
3. 确认 URL 有内链
grep -r "the-slug" . 你的代码库或构建产物，数出现次数。结果是 0 或 1，这页基本就是孤儿页，而 Google 很少爬孤儿页。从首页或一个 hub 页，加上两篇相关文章连过去。内链是你能直接控制的、最强的爬取优先级杠杆，远胜过反复提交 sitemap。
4. 确认 HTML 是服务端渲染的
看页面源代码（不是 DevTools 里渲染后的 DOM）。正文是否真的出现在原始 HTML 里？Googlebot 会渲染 JavaScript，但纯客户端内容是在一条更慢、更低优先级的队列里被爬的，这对新页面是最不该有的负担。
| 框架 | 默认渲染方式 | 新页面的 SEO 风险 |
|---|---|---|
| Astro、Hugo、Eleventy | 静态 HTML | 无 |
| Next.js（SSG/SSR）、Nuxt、SvelteKit | 服务端渲染 | 用 SSG/SSR 时无风险 |
| Create React App、Vite SPA、纯 CRA | 纯客户端 | 高；正文不在源码里 |
框架能做静态导出或 SSR 的话，内容页就用上。
5. 确认 canonical 标签
看源码，找 <link rel="canonical" ... >。href 必须等于你想被收录的那个确切 URL，包括结尾斜杠和协议。很大一部分「页面不收录」其实是「canonical 指到了别处，于是 Google 收录了那个 URL、丢掉了这个」。独立页面用自引用 canonical 才是对的。
6. 看 Crawl Stats 趋势
去 Settings -> Crawl stats。看过去 90 天的总爬取请求数和平均响应时间。两个信号要紧：
- 爬取请求曲线持平或下降，说明 Google 在给整站降权，这几乎总是内容质量的信号。
- 平均响应时间应该贴近 100 毫秒。一旦爬到接近 1,000 毫秒，Googlebot 会为了保护你的服务器而限流，新页面就得等更久。在同一份报告里看 Host status 有没有可用性错误。
服务器响应慢，是少数能靠工程而非内容解决的爬取问题。加缓存、用 CDN、砍掉最慢的数据库查询。
7. 全过了，那就是权威问题
如果第 1-6 步都干净，又等满了 30 天，这页就是卡在爬取优先级上。没有设置能修这个。杠杆按影响力排序：
- 从高流量页面给受影响 URL 加更多内链。
- 来自其他站点的外链。
- 整体内容深度和独特性真正提升，让 Google 抬高全站的爬取预算。
这个慢，没有捷径。打算好持续发真正有用、内链充足的页面，而不是死磕一个 URL。
常见错误
- 跳过 URL Inspection 实时测试。 这是整个流程里收益最高的 10 秒，偏偏是大家最常跳过的一步。
- 反复重提交 sitemap。 sitemap 影响发现，不影响爬取优先级。首次提交后，再提交什么都不会变。
- 去设
priority和changefreq。 Google 已公开确认两者都忽略。花时间调它们就是浪费。 - 申请收录点五次。 系统会去重。每个资源每天大约只有 10-12 次手动申请配额；对同一个 URL 狂点会烧掉配额、换来一句「Quota exceeded」，却不会让它更快被爬。
- 发一堆薄的程序化页面还指望被爬。 Google 很擅长识别「为了页面而页面」，会把它们扔进「Discovered - currently not indexed」。
- 想用重定向链或隐藏链接骗 Google。 没用，还可能招来全站惩罚。
这篇适合谁
已经有 30+ 已发页面、有一批具体新 URL 不被爬、而站内其余部分收录正常的人。
这篇不适合谁
全新站、目前一个页面都没收录——那是另一种问题，看新站提交指南。如果 Google 已经爬了页面但拒绝收录（「Crawled - currently not indexed」），要修的是内容质量、不是爬取，看 Crawled - currently not indexed 怎么办。
FAQ
- 会不会是我忽略的 robots.txt 问题？: 会，第 1 步就能抓到。URL Inspection 实时测试会明确报这个 URL 是否被禁止爬取或收录。做其他任何假设之前先跑它。
- 我用 Next.js / Astro / Hugo，要担心 JS 渲染吗？: Astro 和 Hugo 输出静态 HTML，不用担心。Next.js 用 SSG 或 SSR 也没问题。纯客户端 React（CRA，或没有 SSR 的 Vite SPA）有风险，因为正文不在原始源码里；先修这个。
- 一个页面卡多久就该认定它卡住了？: 第 6 步过了之后，等 30 天。然后把它当作站点权威问题处理，转去发更多内链充足、质量更高的内容，别死磕这一个 URL。
- 申请收录点五次有用吗？: 没用。手动配额大约是每个资源每天 10-12 个 URL（截至 2026 年 6 月），系统还会对重复申请去重。提交一次、等、看结果。
- 要不要用 Indexing API 强推？: Google 官方只支持把 Indexing API 用于
JobPosting和BroadcastEvent类页面。拿它推普通文章违反条款，也不可靠；URL Inspection API（每个资源每天 2,000 次调用）是用来检查的，不是批量提交的。