自然搜索可见度依赖多个独立系统。Google 必须先发现 URL、决定抓取、收到可用 Response、渲染必要 JavaScript、处理页面、选择 Canonical，最后才可能针对查询展示。通过一个阶段从不保证通过下一个阶段。
不要一开始就“请求索引”。先判断问题属于发现、爬虫访问、Server Response、渲染、Indexability、重复、Canonical 选择、内容价值还是查询相关性。每个阶段需要不同证据和修复。
从 URL 到搜索结果的 Pipeline
Google 把 搜索 概括为抓取、索引与展示三个阶段，但技术排查应拆开其中的 Transition。URL 可以已知却未抓取、已抓取却未正确渲染、已处理却未被选为 Canonical，或已经索引却不针对你检查的 Query 展示。
| 阶段 | 活动或决定 | 最佳证据 | 常见错误结论 |
|---|---|---|---|
| 发现 | Google 知道 URL 存在 | 内部链接、Sitemap、Redirect、外链 | “放进 Sitemap 就已抓取” |
| 抓取排程 | Google 决定是否与何时请求 | Log、Crawl Stats、Last Crawl | “已知就会马上抓取” |
| 获取 | Crawler 请求 URL 与 Resources | HTTP Response、Header、Timing | “浏览器能开，Googlebot 也一定能开” |
| 渲染 | HTML 与 JavaScript 产生最终 Document | Source 与 Rendered HTML | “Google 会看到所有 Client State” |
| 索引处理 | 分析内容、指令和重复页 | Page Indexing、URL Inspection | “200 就保证收录” |
| Canonical 选择 | 相似 URL 中选择代表 | Declared 与 Selected Canonical | “Canonical 是命令” |
| 展示 | 已索引页可能针对 Query 被选择 | Page/Query Performance | “Indexed 就会排名” |
从最低技术资格开始
Google 的最低技术要求是：Googlebot 没有被阻挡、页面使用 HTTP Success 正常运作，并包含可索引内容。这些只能让索引“有可能”，不能保证抓取、收录或排名。
- 准确首选 URL 公开并能正常 Resolve。
- 对应 Host 的 robots.txt 允许 Googlebot。
- 最终页面稳定返回 HTTP 200。
- Mobile 上有完整可用的主要内容。
- Meta Robots 与 X-Robots-Tag 没有意外 noindex。
- 重点内容不依赖 Login、Consent 或 Interaction。
- Declared Canonical 有效并与页面一致。
- 内容没有违反 Spam 或 Legal Policy。
发现需要长期可抓取路径
Google 通过已知页面、标准链接、跳转、Sitemap 和外部链接发现 URL。Sitemap 是清单，不是 Navigation 替代。重点页面应从相关 Hub 获得普通 Anchor Link，不需提交 Form 或触发 Script Event。
通过网站架构指南与内部链接指南连接服务、Topic Hub 与Supporting 篇文章。
| 发现来源 | 作用 | 审核问题 |
|---|---|---|
| 带有效 Destination 的普通 Anchor | 主要持续路径 | 用户能从 Indexable Hub 到达吗？ |
| XML Sitemap | 首选 URL 清单提示 | URL 是 Final、Canonical、200 吗？ |
| Redirect | 旧路径或变体指向它 | 目标相关且直接吗？ |
| 外部链接 | 独立发现与引用 | 是否没有 Access/Route Error？ |
| JavaScript 注入 Anchor | 渲染后可能有效 | Rendered HTML 有真实 href 吗？ |
| Button、onclick、Fragment Route | 发现不可靠 | 能改成标准 Route 与 Anchor 吗？ |
已发现不等于马上抓取
发现后，Google 会用算法决定抓取哪些 URL、频率以及 Host 可承受的数量。排程受 Crawl Demand、Host Capacity、更新、重要性、重复与整体 URL Inventory 影响，没有适用于每页的固定频率。
“Discovered – currently not indexed”代表 URL 已知但尚未获取。应先加强真正内部重要性、Server Reliability 与 Inventory Quality，不要只反复人工提交。
| 信号或情况 | 可能影响 | 正确处理 |
|---|---|---|
| 相关内部链接 | 更清楚的重要性与发现 | 从适合 Hub 链接 |
| 准确 Sitemap/lastmod | 更干净的排程提示 | 只在实质修改后更新 |
| 稳定快速 Server | 提高安全抓取能力 | 按 Template 监控 Latency 与 5xx |
| 大量重复/Filter URL | 抓取分散到低价值清单 | 控制 URL Generation 与 Canonical |
| 需求低或内容未变 | 较少重新抓取 | 不要制造无意义更新 |
| 网站迁移或上线 | 短期改变 Crawl Demand | 直接 Redirect 与新 Sitemap |
robots.txt 管理请求，不负责移除索引
robots.txt 告诉合规 Crawler 在准确 Protocol、Host 与 Port 下可以请求哪些 URL。它不是 Index-removal 或安全工具。Blocked URL 仍可能因其他页面链接而被发现，并以有限信息出现，因为 Google 无法抓取内容或读取 noindex。
公开页若需离开 搜索，应允许抓取并使用 noindex、返回正确 4xx，或以 Authentication 保护私人内容。详见Sitemap 与 robots.txt 指南。
| 目标 | 正确控制 | 原因 |
|---|---|---|
| 减少低价值 URL Space 抓取 | robots.txt 加 URL Generation Control | 阻止合规 Crawler 请求 Path |
| 排除仍可访问 HTML | Robots Meta noindex | Crawler 能获取并读取规则 |
| 排除 PDF/非 HTML | X-Robots-Tag noindex | 通过 Response Header 生效 |
| 移除已删除 URL | 404/410 | 说明资源不存在 |
| 保护机密内容 | Authentication/Authorization | 防止未授权获取 |
HTTP Response 决定进入怎样的处理
| Response | 抓取与索引意思 | 审核动作 |
|---|---|---|
| 200 | 内容可进入处理；不保证索引 | 检查内容价值与 Directives |
| 301/308 | 永久搬迁信号 | 一次到相关 Final 200 |
| 302/303/307 | 临时 Routing | 确认来源应长期保留 |
| 304 | 沿用之前抓取版本 | Validator 反映真实内容变化 |
| 404/410 | 资源不存在并可离开索引 | 故意移除时保留 |
| 429 | Server Overload 信号 | 处理负载与 Retry |
| 5xx、Network、DNS | Host 无法稳定服务 | 持续或大量发生要紧急处理 |
| 200 加空白/错误内容 | 可能被视为 Soft 404 | 返回真实状态或恢复内容 |
浏览器成功不代表 Crawler 一定成功
CDN Rule、Firewall、Bot Protection、Geolocation、Cookie、Device Detection、Redirect 与间歇 Origin Failure，都可能让 Googlebot Smartphone 获得和一般用户不同的结果。
- 准确 Requested URL、Final URL 与所有 Redirect Hop。
- HTTP Status、Header、Content Type 与 Response Time。
- 正确 Host 与 Crawler 的 robots.txt 结果。
- JavaScript 执行前的 Source HTML。
- Rendered HTML 与重点 Loaded Resources。
- Mobile Content、Metadata、Canonical 与 Schema 一致。
- 重复抽样以发现间歇 5xx 或 CDN 差异。
- Server Log 确认 Crawler 进入正确 Application。
渲染是独立排查层
Google 使用较新的 Chromium 并能执行 JavaScript，但渲染增加 Scripts、API、CORS、CSP、Client Routing、Hydration 与 Resource Availability 等依赖。重点内容不应等待 Click、Swipe、Typing、非必要 Consent 或 滚动 Event。
Source HTML 若已包含主要内容、Heading、Crawlable Links 与稳定 Metadata，对用户和 Crawler 更稳健。SSR 或 Static Generation 只有在 Delivered HTML 正确，而且 Hydration 没有替换成 Error State 时才有帮助。
| 层级 | 比较内容 | 失败例子 |
|---|---|---|
| HTTP Response | Status、Header、Raw Body | 200 App Shell 无主要内容 |
| Source HTML | Title、H1、Link、Canonical、Robots | API 失败后才加入 Metadata |
| Rendered DOM | 最终内容与 Anchor | Hydration 移除 Server Text |
| Resources/API | JS、CSS、Image、Data | Blocked API 产生空白页 |
| Indexed View | 上次处理的版本 | Live Fix 尚未进入 Index Data |
Mobile Content 是索引基线
Google 使用网站 Mobile Version 进行索引与排名。Responsive Design 通常最容易维持一致，但任何配置都应在 Mobile 提供等效主要内容、Metadata、Structured Data、Images 与 Index Controls。
Mobile Accordion 可以使用，只要内容存在 Rendered Page 内。重点内容只有互动后才加载，并不是可靠的索引方式。
- 主要文案、Heading 与重点链接等效。
- Title、Description、Robots 与 Canonical 符合相同意图。
- Structured Data 描述相同可见实体。
- 图片保留 Alt 与可访问 URL。
- 没有 Mobile-only noindex、nofollow 或 Block。
- Lazy-loaded 主要内容不需用户 Interaction。
索引是分析与选择
抓取与渲染后，Google 会处理 Text、Image、Video、Title、Alt、Structured Data、Language、Locale 与其他信号，分析主要内容、识别重复，并可能储存被选 Canonical 与 Cluster。不是每个已处理页面都会索引。
技术有效的 200 页面仍可能因重复、Canonical 不一致、类似 Soft 404、缺少独特价值或没有被系统选择而不收录。反复提交不会让没有差异的页面变强。
| 索引关卡 | 健康状态 | 需要排查 |
|---|---|---|
| Index Permission | 没有意外 noindex | Meta/Header 或 Staging Rule 冲突 |
| 主要内容 | 有用、可见、符合 Template | 空白、薄弱、重复或 Error-like |
| Canonical | 一致 Final 200 偏好 | 目标 Redirect、noindex 或错误 |
| Language/Locale | 页面与 Alternate Cluster 一致 | 部分翻译或混合语言 |
| Mobile/Render | 重点内容渲染后仍存在 | API/Interaction 隐藏内容 |
| 网站上下文 | 相关 Hub 与链接支持页面 | Orphan 或近似重复 Route |
Canonical 选择发生在索引过程
Google 会把相似页面归组并选择代表。Redirect 与 rel=canonical 是强偏好信号，Sitemap 则较弱；内部链接、HTTPS 与内容相似度也会影响。声明目标不等效或证据冲突时，Google 可以选择其他 Canonical。
改变 URL 或合并页面前，先阅读Canonical 与跳转指南。
| 观察状态 | 通常意思 | 行动 |
|---|---|---|
| Alternate with proper Canonical | 预期的重复集中 | 确认是有意决定 |
| Duplicate without selected Canonical | 没有明确声明的变体归组 | 统一首选 URL 信号 |
| Google chose different Canonical | 其他 URL 更像代表 | 比较内容与全部信号 |
| Page with redirect | Source 不是可索引目标 | 单独检查 Final Target |
| Canonical Target not indexed | 目标本身有其他问题 | 从第一个失败阶段排查 |
索引与展示是不同结果
页面被索引只代表有资格出现，不保证排名。用户搜索时，Google 会评估相关性、质量、语言、地点与设备，搜索 Feature 也随 Query 改变。
如果 URL Inspection 显示已索引但没有 Impression，应检查 搜索 Intent、Demand、Competition、Usefulness、Internal Context 与 Measurement，而不是默认归因抓取。使用搜索 Intent 指南与SEO Measurement 指南。
| 证据 | 能证明 | 不能证明 |
|---|---|---|
| URL 已索引 | Google 储存被选页面表示 | 针对目标 Query 排名 |
| Impression | 结果在某情境展示 | Click 或 Conversion |
| Click | 用户选择结果 | 访问一定有价值 |
| Organic Session | Analytics 记录访问 | 与 Search Console 完全一致 |
| Lead/Conversion | 定义的业务行动发生 | 只有 SEO 造成结果 |
理解 Page Indexing，不要追求全部 100%
| 状态 | 意思 | 优先规则 |
|---|---|---|
| Discovered – not indexed | 已知但未抓取 | 重点 Cohort、发现与 Inventory |
| Crawled – not indexed | 已获取但未选择 | 价值、重复、Canonical、Soft 404 |
| Excluded by noindex | 索引规则已读 | 只有应公开时才修 |
| Blocked by robots | 不能获取内容 | 需要访问或读取 noindex 时修 |
| Page with redirect | 来源到其他位置 | 有意 Routing 时正常 |
| Alternate/Duplicate | 选择了另一个 Canonical | 有意变体时正常 |
| Server Error | Host/Page 返回 5xx | 持续或大量时紧急 |
| Soft 404 | 200 内容却像缺失或错误 | 恢复内容或返回真实状态 |
按实际用途使用 Search Console
| 工具 | 最适合 | 重要限制 |
|---|---|---|
| Page Indexing | 已知 URL 的 Pattern 与 Totals | Example List 只展示部分 |
| URL Inspection Index Data | 一个准确 URL 上次处理状态 | 基于上次 Crawl/Index Cycle |
| Live Test | 修复后的当前 Fetch/Render | 不测 Duplicate Cluster 或保证索引 |
| Sitemaps | Fetch/Parsing 与 Submitted Inventory | 提示，不是批准 |
| Crawl Stats | Host、Request、Response、Type、Purpose | 高级报告，Example 不完整 |
| Performance | Query、Page、Country、Device | Canonical Attribution 与 Privacy 影响数字 |
| Removals | 暂时隐藏自有 URL | 不是永久 Index/Canonical 方案 |
按照正确顺序阅读 URL Inspection
- 检查准确首选 URL，包括 Protocol、Host、Path 与 Slash。
- 确认 Google 是否知道 URL，并记录 Last Crawl。
- 检查 Crawl Allowed、Page Fetch 与实际 Response。
- 检查 Indexing Allowed 与 Robots Rules。
- 比较 User-declared 与 Google-selected Canonical。
- 查看可用的 Discovery 与 Sitemap 关联。
- 运行 Live Test 验证当前 Response 与 Render。
- 比较 Indexed Evidence 与 Live Result，不要混为一谈。
- 修复产生问题的 Template 或 Routing Rule。
- 实质修复后请求一次索引，并监控整个 Cohort。
Crawl Stats 与 Server Log 回答不同问题
Crawl Stats 按 Host、Response、File Type、Purpose 与 Googlebot Type 汇总，Example URL 并不完整。Server/CDN Log 提供 Request-level Evidence，但不能证明页面已经索引或排名。
| 问题 | 最佳证据 | 注意 |
|---|---|---|
| Googlebot 到达 Host 吗？ | Crawl Stats 与 Verified Logs | 必要时验证真正 Googlebot |
| 哪些 Response 增长？ | Response Group 加 Logs | Spike 可能来自上线 |
| 哪些 URL Pattern 消耗请求？ | 完整 Server/CDN Logs | Sample Report 不是 Inventory |
| Redirect 增加多少请求？ | Hop-level Logs/Crawler | 每个 Hop 分开计算 |
| URL 被索引吗？ | URL Inspection Index Data | 有 Crawl Log 不等于索引 |
| 可见度改变吗？ | Performance by Cohort | GSC 与 Analytics 数字不同 |
大部分网站不需要高级 Crawl Budget 项目
Google 把 Crawl Budget 管理定位给非常大型或经常更新的网站。Search Console 也说明少于大约一千页面的网站通常不必担心 Crawl Stats 层级优化。一般服务网站更应关注技术清晰与内容价值。
大型 Ecommerce、Marketplace、Publisher 与 Faceted Site 才可能需要深入控制。Crawl Budget 由 Crawl Capacity 与 Crawl Demand 共同形成。
| 网站情况 | 优先级 | 常见行动 |
|---|---|---|
| 小型服务网站 | 低 Crawl Budget Concern | 修 Broken Link、Error、Orphan、Duplicate |
| 新网站 | Discovery 与 Value | Strong Hub、Links、Clean Sitemap |
| 大型 Faceted Ecommerce | Inventory 与 Logs | 控制组合与 Empty State |
| 经常更新 Publisher | Freshness 与 Capacity | 准确更新与 Stable Server |
| 迁移 | 短期 Demand 与 Redirect | One-hop Map、New Sitemap、Both Hosts |
| 持续 5xx/Network Error | Capacity Emergency | 先修 Infrastructure |
从来源控制 URL Inventory
不要只靠 Search Console 反复清理 Infinite Filter、Session ID、Calendar、Internal 搜索 或 Duplicate Path。应阻止不必要 URL 产生或被链接，定义 Canonical、返回真实 Status，只公开有目的 Route。
SEOWithJack 当前 Build 把 710 个 HTML Document 与 459 个 Indexable Sitemap URL 分开，保留 27 个 WordPress 原文章路径，并审核每个内部 Target。这是刻意设计：Public File、Redirect Response 与 Indexable Canonical 是相关但不同的清单。
| 清单 | 应包含 | 应排除 |
|---|---|---|
| Crawlable Graph | 有用公开页面与资源 | Broken 与 Event-only Route |
| Indexable Canonical Set | 独特最终 搜索 Page | Redirect、noindex、Error、Duplicate |
| XML Sitemap | 首选 200 Canonical URL | Parameter 与 Retired URL |
| Redirect Map | 每个旧 Source 与 Outcome | 未知 Catch-all 决定 |
| QA Crawl | 全部 Template、Locale、Edge Case | 只抽 首页page |
抓取与索引上线关卡
- 每个目标 Landing Page 有稳定 Final URL 与 HTTP 200。
- 每个 Production Host 都有可用 robots.txt 并允许必要抓取。
- Staging 临时 noindex 没有带入 Production。
- Source 与 Rendered HTML 有等效主要内容与 Metadata。
- Mobile 有相同重点内容、链接与 Structured Data。
- Canonical、hreflang、内部链接与 Sitemap 使用 Final URL。
- 移除路径返回相关 Redirect、404 或 410，而不是 Error Page 加 200。
- Redirect 没有 Loop 或可避免 Chain。
- Custom 404、Form、Phone 与 WhatsApp 正常。
- 上线后用代表页面完成 URL-level Inspection。
- 监控 Server、Indexing Cohort 与 Conversions。
根据阶段排查故障
| 症状 | 第一个检查阶段 | 第一份证据 |
|---|---|---|
| URL 不在任何报告 | 发现 | Internal Link 与 Sitemap |
| 已发现未抓取 | 排程/Inventory | Importance、Server、URL Growth |
| 抓取失败 | 获取 | Status、DNS、Firewall、Logs |
| Live Page 对 Google 空白 | 渲染 | Source vs Rendered/API |
| 已抓取未索引 | 索引处理 | Value、Soft 404、noindex、Duplicate |
| 选择其他 Canonical | Canonical Cluster | 三个 URL 与信号比较 |
| 已索引无 Impression | 展示/相关性 | Page-query Intent |
| 迁移后下跌 | Routing/Transfer | New/Old Cohort、Redirect、Log |
| 有流量但 Lead 下跌 | 转化 | Form、Call、WhatsApp、Events |
应该淘汰的抓取与索引误解
- “提交 Sitemap 就保证抓取与索引。”
- “反复请求 Indexing 会更快。”
- “HTTP 200 就代表已收录。”
- “Indexed 就一定针对目标关键词排名。”
- “robots.txt 能防止 URL 出现在 搜索。”
- “Google 一定等待所有 JavaScript Request。”
- “Live Test 会显示索引中的 Canonical 决定。”
- “每个未索引 URL 都是 SEO Error。”
- “网站必须让全部 Discovered URL 达到 100% Indexing。”
- “小企业网站也需要高级 Crawl Budget 操作。”
- “修改发布日期就保证重新抓取。”
- “Server Log 能证明页面已索引与排名。”
常见问题
抓取与索引有什么不同？
抓取是请求 URL 与 Resources；索引是处理获取到的内容、指令、重复与信号，决定可能储存和代表的页面。
Google 多久会索引页面？
没有固定时间。Google 表示重新抓取可能需数天到数周，而且请求不保证索引。
Sitemap 会保证索引吗？
不会。它帮助发现和表达首选 URL，但页面仍要通过访问、处理、Canonical 与质量决定。
为什么已抓取却未索引？
常见原因包括重复、选择了其他 Canonical、内容价值不足、Soft 404、渲染问题或系统未选择储存。
robots.txt 阻挡后 URL 还能索引吗？
URL 有时会根据外部信息出现，因为 robots.txt 阻挡获取而不是发现；Google 也无法读取页面 noindex。
noindex 能节省 Crawl Budget 吗？
noindex 必须先抓取才能读取，也可能继续重访。它是索引控制，不是 Infinite URL 主要修复。
每次修改都要 Request Indexing 吗？
不需要。只用于少量重点新页或实质修复；一般发布依靠 Crawlable Links 与干净 Sitemap。
Index Data 与 Live Test 有什么不同？
Index Data 是 Google 上次处理视图；Live Test 检查当前 Fetch/Render，但不重现全部索引决定。
需要优化 Crawl Budget 吗？
小型或中型服务网站通常不用；只有大型、频繁更新或 Faceted Inventory 真正造成延迟时才考虑。
自然流量下跌先检查什么？
先分开技术可用性、Index Coverage、Canonical 改变、Ranking/Query Demand 与 Conversion Tracking。
官方参考资料
- Google: how 搜索 works
- Google crawling and indexing overview
- Google 搜索 technical requirements
- Search Console Page indexing report
- Search Console URL Inspection
- Google: request a recrawl
- Google: JavaScript SEO basics
- Google: crawlable link best practices
- Google: robots.txt introduction
- Google: robots meta and X-Robots-Tag
- Google: canonicalization explained
- Google: build and submit a Sitemap
- Google: HTTP status codes for crawling
- Google: troubleshoot crawling errors
- Search Console Crawl Stats report
- Google: crawl budget management
- Google: mobile-first indexing best practices
- Search Console data limitations
分享受影响 URL Cohort、Search Console 状态、近期发布与 Server Evidence，我们可以先区分发现、获取、渲染、索引、Canonical 与查询相关性问题。
Google 排名如何演变：从 PageRank 到现代搜索系统2026年9月2日
Google AI 内容与 SEO：什么被允许、什么是垃圾内容，以及怎样安全发布2026年9月2日